Really Strategies
RESOURCE CENTER
“Really Strategies provides us with the third-party expertise we need.”
USATODAY.com
Making Friends With XML Editors
Mar 2003Commercial XML editing software is in its third and fourth generations, and users have had plenty of time to develop their opinions about it. This past month, we interviewed XML editor users with varying amounts of experience. Our investigation revealed strong feelings, and we found more complaints than compliments.
What are users feeling?
Has anyone heard an author or editor exclaim, "Boy, I really love XMetal" (or Epic or XMLSpy for that matter)? We spoke with several users of XML editors and heard just the opposite. Why is this, when at some point we've all heard people proclaim strong, enthusiastic liking for software like Quark, or Excel, or Outlook, or, yes, sometimes even Word or WordPerfect? What is it about software and human interaction that creates a feeling of like or dislike?
What's the point anyway?
Of course, while interesting, these are not the questions that really matter.
Software like XML editors is meant to help people be more productive in their jobs. Because structured content is important in the content lifecycle, organizations look for tools that allow authors and editors to accept new responsibilities in their workload yet still maintain efficiency. XML editing software is, in many cases, the only reasonable option for non-technical staff who need to work according to a DTD or schema. Things get murky when a technologically "correct" solution is perceived to be unnecessarily difficult by its users. Subsequently, users feel burdened rather than empowered by software.
So, we should be asking: What success factors can publishers use to measure the effectiveness of software, specifically XML editors? What can publishers do to ease the pain associated with XML editors when it genuinely leads to lost productivity? If you talk in detail to your users, you might find that their statements about not liking a particular tool are actually their way of answering these questions that really do matter.
So what's not to like?
Compositors, database administrators, content licensees, and managing editors will all extol the virtues of structured content. Even end users appreciate the importance of structured content (although they don't realize it!)—useful new products are produced and fast retrieval of information is facilitated. Unfortunately, users responsible for creating structured content sometimes have negative feelings about the steps that result in that structured content. Here are some reactions we heard in our recent conversations:
- "It's too bulky. It takes too many clicks to do things."
- "I never liked the SGML environment."
- "People don't think about structure and content as being linked together."
- "I hate XML editors. I use a text editor."
- "It's a useful tool but has some idiosyncrasies."
- "I've come to terms with its goofiness."
This is not to say that users reject the importance of delivering XML (or, in some cases, SGML). No one we spoke with debates the importance of XML in his or her organization. In fact, everyone ended our conversations by saying, ultimately the job is getting done and they are successful at delivering structured content.
For some authors, using XML software feels like they are losing flexibility. Additionally, there is something about the psychology of the blank page that promotes excitement, a challenge, a natural process. Typically, authors write, format, and edit—in that order. A screen marked up with tags can feel confusing and unnatural. It interferes with the creative phase of authoring.
For editors, simple editorial changes can involve more steps than would be necessary in a word processor. Depending on the complexity of the mark up and the DTD or schema, a simple cut-and-paste job can be more involved than the four keystrokes it would take in a word processor.
What are some answers?
Continuing to extol the virtues of structured content just isn't enough. Identifying the obstacles that decrease authors and editors' productivity may seem like another thing that sure would be nice but another way to load more work into already busy schedules. However, you might be surprised at the results you can achieve.
- Simplify your DTD/schema. If you speak with your editors, you may discover that they have already invented some clever ways to work around restrictions that exist in the DTD.
- Spend more time on software configuration. Today's XML editing software allows for considerable customization and automation.
- Invest in training. The importance of a structured training approach cannot be overstressed. The difference between throwing someone into the fire and learning from mistakes and providing them with a formal methodological approach to using new tools is vast.
(For more suggestions, see this month's other article, "Only You Can Make XML Editing Easier.")
Training is valuable for many reasons. A formal training environment not only teaches the details of how to use software but also provides an excellent forum to discuss the business drivers that mandate new approaches and tools. Generally, if people understand the reasons behind the change, there will be fewer barriers to acceptance.
Whatever choices you make, do so deliberately. Understand the pros and cons of your decisions and identify those solutions that work for your business. Don't expect authors and editors to rave about XML editing software but do expect them to use their new skills and knowledge as a productivity tool. And if they claim that it takes them longer to do their job, it's worth the time investment to understand why.
