Something that strikes me is the difference between talking to someone who knows theoretically how things should work and someone who's actually been doing the work itself. We're in the (un?)enviable position of being on both sides for many of our clients, coming up with new ideas that should work - and then being asked to implement them. It's an exciting place to be!
If you want to meet a bunch of people who do just this, I'd really recommend the Oxford XML Summer School. Even the pub crawls are inspirational, and it's a truly humbling and exciting experience. We only managed a couple of days this year as it clashed with other stuff, but 2013 should see us back for the full week. Plus, what's more romantic than sharing two single beds in a dorm room with your beloved?
It's been really interesting to look back at 2012, and see all the tricks and tweaks that we used to do in the days of film are coming back into use. For example, using galley proofs to check text (using a default styled XSL-FOoutput for example). Given the lack of support for round-tripping between XML and GUI DTP programmes, this is currently the only way that you can simultaneously attempt to develop a new and complex digital product whilst also getting the content editorially correct. We're still convinced that XSL-FO can produce proofs that are as good quality as those produced by InDesign and their ilk. We've done a lot of work on this but resources haven't stretched to achieve this lofty goal - yet. Hopefully in 2013 we'll break the back of this one!
I've started to keep a list (outside of my head) of what is fiddly and what is not fiddly to fix in an XML-first workflow because it is a TOTALLY different paradigm for non-programmers. Things that are simple in DTP can be hugely complex, e.g., adding chapter headings into a Notes section is not fiddly, it's three lines of XSLT; whereas something like changing one ordered list type from numbered to lettered list when all others are numbered (very fiddly: need to introduce a new formatting rule which doesn't currently exist). What's the solution here? It can only be communication at point of request, and experience. What can you do in your office to achieve this? You could start keeping a list specific to your publication, but only if you get feedback from your programmers (usually contractors, who attempt to do your bidding and swear out of the client's earshot). Another argument for DIY!
We've also been experimenting with getting complex EPUBs to work properly outside iBooks Author. We see a lot of publishers struggling with creating multiple EPUB files for different suppliers (which can be costly in terms of production and administration), or suffering with substandard EPUB files that are aimed at the lowest common denominator reader. Wouldn't it be nice to have a single EPUB file that can work for enhanced readers, simple e-ink readers, and mobi-based readers too? And which you can also export seamlessly as HTML to your website? It does take a lot of work at the "back end" of things, but we've come up with a few tips and tricks you might like to start to ask your suppliers to do (or - even better - DIY!). One of the best of these is the under-used element <epub:switch>, which I am going to let Nic write about, because it's his baby :) We're also using media-queriesand display:none in CSS to let us cover more cover more platforms with a single file.
We're usually thinking about these sorts of things here at Corbas Towers (and sometimes in Paris, Oxford, or elsewhere), but instead of going on about it here, I'm going to get back to JFD-ing it and see what you lot think.
Do you want more of this? Keep in touch!
Peace and goodwill - em x