Test Drive A Hybrid Workflow

You never know where inspiration will come from. Yesterday it came to me in the form of a traffic jam slowing my ride to work. Sitting on the commuter bus, mired in “bumpa-ta-bumpa”, I stared out the window. Life on pause. I imagined the lake of gasoline that was fueling all these cars, puffing out their tailpipes, melting Greenland. Then a shiny red Toyta Prius rolled by. It had a good vibe, like a forward-thinking, best alternative in an otherwise unworkable situation. A hybrid.

This was definitely a sign from the cosmos that it was time to talk about the hybrid XML-InCopy workflow I’d been playing with since last year. I had planned to finish off the cookbook project tonight, but this idea overtook it in my brain. I offer it up now in case any of you out there is stuck in a traffic jam of a publishing workflow, with a line of products and file formats in each other’s way, slowly crawling ahead while the clock ticks ticks ticks.

The point of a hybrid workflow is to combine the virtues of XML and InCopy to give you speed and efficiency that is otherwise impossible. Single-source authoring means multiple print and/or Web products derive and arrive simultaneously from the same set of keystrokes. You author and edit in XML, transform when necessary, and use InCopy to preview your print layouts, where space is finite and styling matters, as you go.

I know there are people out there who have written amazing scripts, or developed plug-ins or workflow systems that can accomplish what I’m going to show you better, faster, with more goodies. But as always, I write about what can you do with the off-the-shelf tools and garden variety skills. Or if you don’t currently possess those skills, you can come by them without completely re-wiring your brain. Perhaps someday Adobe will release the equivalent of an electric car, XML authoring as part of the Creative Suite, and we’ll all be merrily speeding down the Cross-Media Expressway. What follows is my idea of how to do today. And it works. So hop in the hybrid and take it for a spin.

The Pitch

With a W3C XML Schema as the foundation of your workflow, you can develop multiple print and online products simultaneously, and achieve efficiency and savings through content re-use with off-the-shelf tools.

The Tools

To do this you’re going to need InDesign CS3, InCopy CS3, and the Altova MissionKit For XML Developers. The MissionKit is an XML Developer’s equivalent of the Adobe Creative Suite. It’s three applications that work in concert to for the creation and transformation of XML files: XMLSpy, StyleVision, and MapForce. This is a Windows-only package. There is no Mac version, so if you kneel at the altar of Jobs like I do, you need emulation software like Parallels. Syncrosoft’s oXygen is an alternative that runs on the Mac, but only if you don’t need a lot of help writing XSLT. I do. MapForce gives you graphical creation of XSLT, or as I call it, XSLTW (XSL with Training Wheels). I’m not trying to do a commercial for Altova, but their stuff is the only stuff that I know works for everything we’re trying to do.

Step 1: Planning

This is the big one. Map out all your content. Depending on the complexity of your content, this can be a tough job, so you only want to do it once. Spend enough time to get it right, since everything flows downhill from here. Every screw-up or oversight at this stage will echo throughout the workflow in some combination of time, aggravation, or cost. And everyone needs to know that once this is done, there’s no changing the structure, at least not for anyone who wishes to remain with the company.

Your map should show every piece and where it fits into the overall scheme of your project. Map every recombination, and every dependency. Leave no stone unturned. This part can be a real eye opener. If you survive with your sanity intact, you will understand your content better than ever before and maybe discover new ways of using it.

Reverse engineer your own content. Cut up books and move the pieces around as they would move in the digital realm. Follow the life of a lowly paragraph as it appears throughout your product line. Once you grasp the details, you can answer the first key question. What kind of schema best suits your needs: a custom built-from-scratch schema or a generic format? Do you have the time and money to make the former? Do you have the flexibility for the latter? A bad fit might cost you more in the long run. Investigate DocBook and DITA. If you go generic, skip to step 3.

Step 2: Build the Schema File

With the understanding that you gained by mapping your content, you can now build an XML Schema that will guide your authoring, transformation, and output. Why a Schema? Why not a DTD? I have nothing against DTDs. In fact, they are more appropriate for describing book-like things. Schema excel at describing data more than documents. In fact, I love DTDs so much, the other day on the highway I was passed by someone with the license plate 736 DTD, and I thought “hey, that’s cool.” Then I felt the urge to slap myself for being such a geek.

I say use Schema purely because the Altova tools support Schema in ways that they don’t support DTDs. Namely, you can graphically create a Schema in XMLSpy. I feel a little hypocritical because this is the same tool-based thinking I dissed in a previous post. But facts is facts, and until I find another tool that can do this workflow end-to-end with a DTD, I’m sticking to my story. Actually, if you must have a DTD, there is a workaround: build a Schema, then use XMLSpy to convert the Schema to a DTD.

Step 3: Create Authoring Templates

Using StyleVision you take your Schema and apply styling to it to make a user-friendly authoring template. This is something the oXygen can do too. You choose from CSS properties to apply fonts, spacing, and position to your elements. You can make pop-up menus for standardizing choices, and clickable links to insert required elements.

Step 4: Develop Layout Templates

Import sample XML files into InDesign, structure and style it. Set up styles to tags mapping. Make use of the Story Editor to be sure your tagging remains intact and whitespace characters are where they belong.

Step 5: Distribute Authoring Template

Let the writers have at it.

Step 6: Import XML Files into InDesign

And when you do, be sure to maintain the live link, so the XML file appears in the Links panel.

Step 7: Export to InCopy

BUT tell everyone that the InCopy files are untouchable! Hide them. Instead, InCopy users drop the InDesign file onto InCopy to open it directly.

Step 8: Editors Do the InCopy Two Step

Check out the appropriate stories from the InDesign layout. Show the Links panel to see the XML file. Edit in the XML file, save it. Go back to the Links panel and update the link to the XML file. Magic! You have your cake (XML) and eat (publish) it too.

The fact that this works at all is a complete accident–the unintended consequence of 3 InCopy capabilities: access to the links palette (intended for the management of placed images), the ability to use an InDesign layout for preview (so one story can be simultaneously linked to both an XML file and a .incx file), and the ability to maintain a live link to to text files (meant for Word and spreadsheets). Sometimes things just fall into place.

Editors can do some work, like styling, and working with boilerplate (untagged) content in the layout file. But they must understand the fundamental truth that anything they do between the tags in the layout will be wiped out the next time the XML file is saved. Stuff outside the tags, in whitespace elements, remains.

At the end of the day, when all is said and done, you still have intact XML files, with the most up-to-date content, ready to be flowed into whatever template or media you need.

Bonus Points

At any point in this workflow you can use MapForce to create XSLT to transform your content, making it fit another purpose. You don’t need automated workflow systems or scripts to make that transformation happen now that InDesign supports XSLT. Examples of what you can do with XSLT: Making HTML for Web presentation, making PDF, making alternative print products by gathering or sorting content according to attributes, making NIMAS files.

Math Doesn’t Add Up

All this is great, but it will not work for you if you need MathML. The only ways to get MathML in and out of InDesign involve scripted solutions, or customized versions of 3rd party plug-ins like MathMagic. I hope that some day InMath, which has always been my favorite equation editor for InDesign, will add MathML support. Design Science’s MathType speaks fluent MathML, and you can place those equations (in EPS format) into an InDesign layout. PowerMath also exists for InDesign but I haven’t tried it out. Note to self: I should do a future post comparing all the different ways to do math in InDesign.

Next Steps

My next project (if ever stop spending all my free time blogging) is to experiment with Office Open XML. Since the new version of Office has XML underlying every file format, why not exploit that, and author in Word, transform OOML to your Schema, then import in InDesign, Web, etc. It should work like a charm, and it’ll probably have authors and editors breathing a sigh of joyful relief that the XML authoring tool they have to use is Word. It may not be the electric car, but it’s pretty close to one of those that runs on old french fry oil. Mmmm, I could go for some fries right now.

Advertisements

Family Cookbook 2.0

Now that all our Easter eggs have been consumed, let’s continue on with that XML theme with a little project to illustrate the joy and pain of bringing old content into the brave new world of cross-media publishing. The goal is to take the files from old print project, languishing on some dusty CD in the basement, and give them new life as spiffy Web content.

The content we’re going to work with is a cookbook. And yes, I did hear that collective groan from across cyberspace. If you’ve read anything about XML and publishing, you know that all XML demos are based on cookbooks. I think it’s a law or something. Actually, I really did want to update the cookbook and put it online, so I grabbed it for this demo.

I’ll break the demo up over a few posts since it’s too much to digest in one sitting. It hurt to write that one, but I couldn’t help myself.

The cookbook was a personal project. I made it when my son Ethan was a baby, to say thanks for all the help everyone gave my wife and I at the time. I was also inspired by the memory of a great-grandmother, Nana Mac, a legendary cook who never wrote down any of her recipes.

plish-nanamac.jpg

Now they’re all gone with her. I wished that my kids could be connected in a some way, to the great people who came before them. So I sent out a request to all family members to submit their favorite recipes and any interesting stories that went along with them. I got a nice response, 54 recipes from 28 people.

I transferred all the recipes from hand-written index cards, or copied and pasted from e-mails into a Quark layout. Like my fellow Southeastern MA native, Emeril Lagasse, I kicked it up several notches. I probably went overboard, with not one but two indices, a forward and a dedication, and of course drop shadows on every page “burned” with ShadowCaster. I figured out the imposition and printed 30 copies of the pages on my Epson Stylus Color 740i, which matched my Bondi Blue iMac. The Epson still cranks out pages today. Never fed it an OEM ink cart either. The inkjet gods must be smiling on me. I bound the books, using a cordless drill and hand-bent staples. Ouch! Talk about old world craftsmanship! Could have used one of these sweet book staplers. Then again, maybe I should’ve just gone to Kinko’s. But the whole point was to do it all myself on the cheap. The book came out quite nicely, if you forgive the slight shingle of the pages, and the fact that I didn’t laminate the covers, so they get a bit smudgy in the kitchen.

plish-cookbookcover.jpg

I undertook this project in the spring of 2000. Those were the days when the wooly mammoth known as Quark XPress 4, roamed the Earth and dominated the publishing world with a 90% market share. Yes, there was a new thing called InDesign, but I laughed at it. Version 1.0 would launch, sort of. Everything else I tried to do with it caused it to crash. I mocked it as Illustrator with multiple pages. When InDesign 2.0 came out I quickly changed my tune. But that’s a story for different day.

Thus for our current project we have the dusty old Quark 4.04 file and a couple of pieces of art. Nowadays, I pretty much bleed Adobe Red (Pantone 485). I don’t own or know the versions of Quark XPress after 4.11. This is a problem for a few reasons, not the least of which is, if I upgrade all my machines to Leopard, I’ll be without Classic support, and thus without Quark. There is a workaround: have a partition running Tiger/Classic, but that’s like having to keep a second stereo in the living room to play your 8-track tape collection. Perhaps it’s time to upgrade. I must at least check out, if not actually buy XPress 7. I’m looking forward to it, but with the same feeling when you meet up with an old friend you haven’t seen in years: a mix of curiosity and unease. What’s changed? Will we still get along? Does he still remember the secret handshake (keyboard shortcut)? For now, we’ll attempt the Extreme Cookbook Makeover with InDesign CS3, Syncro Soft’s Oxygen, and Dreamweaver.

One last a stupid question: Why is it when I type “Dreamweaver”, I hear the song from ’70s? “Ooohh, dreeeeem weavahhh, I believe we can reach the morning liiight.” Maybe it was Wayne’s World that resurrected those dying neurons. But I am suspicious there’s also a K-Tel Records commercial playing endlessly in some dark corner of my mind. That would explain a lot. Hopefully my curse will not now become yours. OK, this blog is over 3000 words old, let’s finally do stuff.

CookBook Makeover

Step 1: The Conversion Drop Ye Olde XPresse File onto InDesign CS3. On my vintage G4, 40 seconds goes by before the Open progress bar appears. Tempting to go play on the Web, but in the interest of science I will ignore my ADD instincts and wait it out. For about a minute we get the “Converting Regular Spreads” message. Hmmm. What exactly is a “Regular” spread? Does this mean there are “Irregular” spreads? “Atypical” spreads? “Highly Unusual” spreads? I’d hate to have InDesign tell me it was converting “Unprecedented” spreads. Then again, that seems a little exciting. I have seen this dialog box a hundred times, without ever really comprehending it. Do I care enough to Google? Apparently so, and here’s the answer: “Regular” spreads are document pages, the ones that actually get printed in the book, as opposed to “Master” spreads which hold master pages. Hoping for something more interesting weren’t you? So was I, but we move on.

Next up, Warnings. “Shadow attribute not supported for characters.” OK, I don’t remember ever shadowing characters, but I’ll take your word for it, InDesign. Go on. “Missing Fonts.” No surprise here. Almost all the files I ever open were created at another time in another place, so this is my default state of existence. I was born missing fonts, man. I could load the entire Adobe Font Folio, add everything from Linotype, ITC, and ImageClub and somehow I’d still be missing FranklinGothicDemiCaramelMacciato.

What I really need is a preference like this:
plish-pinkenough.png

Alas there’s not, so we dismiss, and we’re in. Let’s take a look around.

plish-cookbookconvert.gif

All the recipes have the title and chef in inline text frames, like they did in the XPress file. To InDesign, that content is out of the flow of the story. So merging content is one hurdle to clear before we export the XML. Everything seems styled; that’s good. Thanks, Y2K self. Hmmm, the ingredients are in 2 columns. That might need to be cleaned up before I apply tags. There are a few scraps of whitespace trash lurking here and there, but I think we can make a go of it.

Since we’re starting with a converted XPress file, I am reminded of a neat InDesign feature which may be of some use to people. Normally if you choose InDesign > About InDesign… you get the lovely InDesign Purple (DIC 2618 or 40c100m) Credits window, with the version number. But if you add the Command key, you get an info-packed window called Adobe InDesign Component Information.

plish-idcomponent.gif

All the supertechy details of your document’s existence are laid bare, including whether or not it was converted from Quark XPress or PageMaker, all the versions of InDesign (including the build number) that touched the file, whether it is crash-recovered, opened with missing plug-ins, etc. It’s like doing a DNA test on your InDesign file. This info has helped me in the past with troubleshooting, in terms of hunting down what was causing a file to crash, and where in fact a file came from.

Note that like in the screen grab, Write Log File is grayed out until you save the document. If open this window with no document open, it still works, you just get the top of the dialog filled out with info about InDesign’s state for troubleshooting application problems instead of document problems.

OK, that’s all for now. Next time we’ll do text clean-up and tagging.