Designing XMetaL’s Conditional Text Feature

[dropcap]W[/dropcap]hen I served as interaction designer for the XMetaL development team (2004 – 2009), we executed a variety of initiatives to bring the capabilities of XML into greater use in the market. XMetaL Author is a native XML editor with a UI resembling a word processor. One such initiative was adding a new feature, called Conditional Text, to XMetaL Author.

XML, a family of markup languages similar to HTML, has a variety of capabilities that are valued in the world of document publishing. For example, documents written in XML can be rendered as both web pages and as formal books or brochures.  Whereas HTML + CSS have a limited ability to adapt to varying screen sizes through responsive web design, XML can be used to create versions of a document that differ dramatically in layout and in content, such as customized versions of an operations manual for different models of a tractor.

The concept of Conditional Text is to add metadata to a document so that, for example, the sentence “Press Ctrl+S” appears in the Windows version of a software manual and the sentence “Press Command+S” appears in the Macintosh version of the manual. With the appropriate metadata, the XML would look something like this:

It is possible, in theory, to use any text editor to add this metadata to any XML document, but it is difficult to manage on a practical scale unless the application is designed to support the practice of Conditional Text. I suggested that we develop a Conditional Text feature for XMetaL Author, and as the sole user experience specialist on the team, I led the design work for this feature.

The Design Process

Other applications with Conditional Text features already existed, however we set a goal of making ours much better, while ensuring that content conformed to precise cross-vendor data exchange standards.

I developed my understanding of users’ goals and tasks for this feature, and my understanding of technical constraints, from a variety of sources including:

• Brainstorming with our team’s customer-facing staff.

• Meetings with real users. This feature was intended for a specialized professional audience, so we sought input and feedback only from people who had a real need for this feature. We met and talked via WebEx sessions, on-site visits, and email conversations.

• Reading the technical specification for DITA, a standard XML language that was starting to become popular in 2005, when we were designing the Conditional Text feature. DITA formed the technical basis for our initial implementation of Conditional Text. For cross-vendor data exchange, the user’s input needed to be stored as fully DITA-compliant XML. We also decided to architect the feature to support arbitrary XML languages.

I started creating low-fidelity paper mockups early in the process, and iterated and completed the design in parallel with research and user feedback sessions.

Research Findings

Here are some things we learned from customer/user feedback:

• Mental models: Users thought about conditions in terms of what they wanted to include, e.g. they spoke about printing a document “customized for Europe”. This was the opposite of how the programmer-oriented DITA standard was written. The DITA standard required a file specifying what to exclude, e.g. saying “not for North America, not for South America, not for Asia, and not for Africa” in order to get a version for Europe.
• Data model and scalability requirements: From observing actual data sets, we learned how organizations versions of documents could be modeled in terms of conditionality, and how many conditions they needed.
• Multi-user issues: As it was common for multiple authors on a team to contribute to a document, it was critical for all team members to record metadata about conditional text in a consistent way. Teams did not want some team members recording the intended audience for a document as “Europe” and others as “European” because it would lead to more complex processing and/or errors down the line.
• Terminology: Users mostly called the feature “conditional text” even though it would be more accurately described as “conditional content” as it could be done to images. We also observed other synonyms for “conditional text” that people were using, to keep in mind for future training and marketing projects.

User-Centered Task Modelling

Throughout the process of understanding user goals and tasks, we tried to develop a view of tasks that was user-centered rather than system-centered. The following example illustrates the difference between a user-centered and a system-centered task model.

When an application involves a data-exchange standard such as XML, a common pitfall is to assume that the user thinks of their tasks in terms of creating and editing the pieces of data defined in the standard. For example,  a constraint of XML is that only whole elements can be made conditional, and we could have assumed that the user had in mind that they wanted to “create elements” and “conditionalize elements”. However, we realized that it would be insufficient to model tasks this way – it would be more appropriate to recognize that users want to conditionalize things like sentences, images, and table rows. Users often want to conditionalize a single sentence, which is generally not tagged as its own element.

Some very technical DITA users might know that to conditionalize one sentence, they would need to put a set of <ph> tags around the sentence and then conditionalize the <ph> element, however this would require an extra step. Less technical users would have no idea they needed to do this extra step, and they would fail at the task.

[dropcap]T[/dropcap]o streamline the workflow and eliminate this cause of task failure, I asked the developers if they could automatically add <ph> tags around selected text. We also realized that it wouldn’t be appropriate to always add <ph> tags around selected text. For instance, if the user selected an entire <p> element (i.e. an entire paragraph), conditionalizing the <p> itself would yield cleaner XML, which our users value. For other reasons (I will spare you the boring explanation), we also needed to give the user a few more options to clarify their intention of what element they wanted to conditionalize.

I designed an Apply/Remove Conditions dialog with a drop-down for selecting the range of content to conditionalize, and an algorithm for populating the drop-down so that most of the time, it would default to what the user most likely wanted.

 

Final UI Designs

After many rounds of iteration with user and team feedback, our design for the feature employed one configuration file and three dialog boxes.

To make it easier for teams to standardize their spellings of the attribute values used for Conditional Text, we let users define them in a configuration file that they could copy to each workstation. We found that users really appreciate anything that would help them configure multiple machines the same way.

UI for Making Content Conditional

UI for Displaying Conditional Text

Authors need a way to keep track of what conditions applied to what parts of their document. At the time we designed this feature, a popular commercial product with a similar feature used a variety of bright text colors for different conditions. E.g. you could put a sentence that was for Europe-only in red text, and put a sentence that was for Asia-only in blue text. A problem with this approach was that documents with text in many colors were very hard to read.

With a constraint that styling for conditional text had to be implemented using CSS2, I designed a set of styles using pastel background highlighting. They were easier on the eyes than text coloring.

Whereas the syntax for Conditional Text needed to be standardized across a team, we let individual authors choose their own settings for styling conditional text. That way, authors could choose styling that gave the best balance of readability and differentiation, for the particular subset of the team’s conditions that were used in their current document.

UI for Printing/Publishing Documents

In the dialog box for setting options for generating a PDF or HTML version of the document, I added a button bringing up a Show/Hide Conditional Text dialog box.

To align with the way users think, I designed this dialog box to let the user say what variations they wanted to include, and had the system use that information to create the file that the system needed, saying what content to exclude.

Results

The Conditional Text feature was immensely popular with customers and users. When I trained users on XMetaL Author, they were often relieved that for such a powerful feature, it was surprisingly easy to use. It became a mainstay of product demos and self-guided tours for its user-friendliness and its ability to quickly illustrate value. Companies that are currently authoring DITA XML with XMetaL Author include NetApp, Citrix, VMware, and Cisco Systems.