An Obvious Observation


I’ll take a break this week from the steady march of progress in developing an XML workflow to reflect on one of the major challenges in doing so. It’s so obvious you might not consider it. It also may be impossible to avoid or correct.

To illustrate what I’m talking about, I’ll share with you my relationship with Illustrator. In my job, I sometimes have to go in and make text corrections in Illustrator files. Sometimes I have to do a color correction or figure out why a particular file won’t rip. I have a technical relationship with Illustrator. I know what the buttons and menus and palettes are for.

When I was in college I took some art classes to round out my liberal arts degree. I had of course taken art all throughout my education as this was during the time when schools still had funding for and interest in things like art and music. By the time I was in that college class it wasn’t as if I’d never put smudgy art pencil to paper before. Of course the results were consistent with my previous attempts. It turns out my brain doesn’t have the upgrade required to transform 3-D reality to a 2-D surface via smudgy pencil. Or any pencil for that matter. In one particularly annoying episode, my art teacher physically moved my hand to show me how a particular curve was supposed to look. I think it was the top of a pot. My version looked like something Picasso whipped up during his cubist period in an absinthe haze. That’s not what the teacher was looking for.

So, now, I don’t need a smudgy art pencil, I can use Illustrator. That should solve my problem! The computer will fix everything! Computers make everyday tasks so much more convenient. Have you figured out the obvious observation? Illustrator won’t do jack for me BECAUSE I CAN’T DRAW. Blank computer screen or blank paper, doesn’t matter, I can’t draw so anything I do will look wrong.

And here’s the crazy part. I can take classes, read books, go to seminars, do anything, but in the end, based on prior experience and my gut feeling, I’m not going to be able to draw. I understand the concept, I just can’t do it.

In a class discussion once someone made the comment that they couldn’t play the piano. The teacher said that was not correct–it’s not that the kid couldn’t play the piano, it’s that the kid didn’t know how to play the piano. The implication is that with proper training the kid could eventually learn how to do it. That’s nice and all, but what if the kid didn’t have the manual dexterity or the mental upgrade needed to transform dots on a music staff to sounds coming out of an instrument? If it was that easy wouldn’t we all be concert pianists, or in my case, expert artists?

The same issue arose with some of our writers when we implemented XML. They’re good writers, and they understood the concept of XML, but for whatever reason they were unable to transform the idea they wanted to get across into a content model. The could see the available tags, but didn’t know how to go about assigning them to their words. It wasn’t a question of training or facility with the software, it was a deeper disconnect that no amount of practice or help could fix. They’d always end up with files that needed to be cleaned up by someone else. And in the process, they were discouraged, annoyed, and slowed down, causing frustration.

So what do you do if you’re working with a person, or are the person, so frustrated by the XML workflow? All you can do is support them the best you can. Maybe they’ll have a breakthrough.

If you or your colleague never has that breakthrough, like I never did with drawing, then all the support may help reduce some frustration, but you’ll still need to clean up those files after they’re done with them. I’d recommend  building this step into your workflow from the beginning. If it clicks with everybody, then maybe you can drop it later. But if you start with the expectation that every writer is going to be able to tag content correctly all the time, you’re going to have problems with staffing and schedule. And that’s the most obvious observation: expect success but prepare for less.

Advertisements

6 Responses

  1. You make a great point—creation and categorization are two very different jobs. It’s the difference between an author and a librarian. Sometimes we’re asking people to be both.

    If all else fails, you can physically take the author’s hand and move the cursor to the right tag 😉

  2. I’m pretty sure there’s an HR rule against taking authors’ hands.

  3. It’s not exactly library science (apologies to rocket scientists for stealing their catchphrase). There are two parts to the XML workflow when it comes to content: “What is this granular bit of content?” and “Where does it belong in the document structure?” It’s the micro and macro views, and Eric makes a really important point. It takes a special set of skills to do both.
    A possible aid to the author is to separate the document structure from granular content categorization by implementing a user interface that either isolates the user from the grand structure (only allowing the author to work on one small segment of the document at a time), or relays the document structure in a “bookmap” metaphor. Granted, either method would only be viable if the document’s structure were locked down and absolute before authoring began, so I guess we can throw those out right now. </sarcasm>
    For folks with a design/production background, it seems like it’s easier to make the leap. We’ve all used bookmaps to determine the gross divisions of content. We’ve used paragraph and character styles in conjunction with prototypes to assign certain presentational attributes to specific bits of content based on categorization and intent.
    I think editors actually have had the skills all along. They create the bookmaps that create and apply the overall structure of the document. They check the design and produced pages against the author’s intent to ensure that content is correctly categorized by its presentation. The author is sometimes isolated from this process by the editor, so it may be a huge leap from visual differentiation to explicit categorization, but all editors should have to do is click their heels three times and say, “There’s no place like <[root]>…” 🙂

  4. In theory, that is. Also, I don’t really wanna know who the Scarecrow would be in that Wizard of Oz metaphor, ’cause I’ve got the sneaking suspicion it may be me. 🙂

  5. When I was teaching FreeHand (back in the day…) at the BCAE, I always started each new class off with the caveat that I would be teaching them to use the software, not how to actually draw; it wasn’t an art class. I’d throw in some tips on how to look at things in a different way, maybe, such as trying to see how many geometric shapes make up a single object, but as you pointed out, some people will never see things that way.

  6. […] and Pieces VIII: Training and Documentation Posted on June 2, 2009 by Eric Damitz I wrote a post awhile back where I confessed to my ineptitude with drawing. I said no amount of training would […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: