Next are three related recommendations that have to do with creating content – what we used to call writing…
17. [SUITABLE] – Ensure that content is suitable for use in a mobile environment.
The W3C says “Users in a mobile context are often looking for specific… information, rather than browsing.” This is also true of online material from tech comm., especially online help.
For example, people don’t browse online help; they read it for specific information they need to do some task. But this may not be true of other types of online material. For example, you may create online procedure manuals for use in the field. In such manuals, users might browse the content or read larger chunks than they would in online help because there’s more to know or learn about the subject.
So this recommendation requires analyzing our content in order to determine:
• What parts don’t apply to the mobile output’s functional environment. You’d remove those parts by conditionalizing them out for the mobile output – e.g. single sourcing. For example, information about configuring an application for a printer might be useful in large-screen online format but irrelevant for mobile.
• What parts don’t apply to or aren't crucial for the mobile output’s usage environment – “need-to-know” versus “nice-to-know”. You’d remove the latter from the mobile output by using conditional build tags. For example, you might create an online shopping guide to single malt scotch that showed each brand’s label in the large-screen version. However, while showing the label might still be nice in the mobile output, there isn’t enough room on the screen so you’d decide to hide it and use the space for more appropriate content.
18. [CLARITY] – Use clear and simple language.
This should be a given in tech comm.; write in clear and simple language... The reality is that we often don’t. The passive voice is used by us rather than active voice. We address “the user” rather than “you” and get tied up in gender-neutral writing like “The user... They…” and “he/she…”
If you know your content will be single sourced to mobile devices, change your writing style now to short and simple. If you have a lot of legacy content, this may require more work than you can afford and you may decide to leave the legacy content as is. However, it may be worth a quick look at that legacy content to see if there are any simple writing fixes that offer a quick payoff for a low investment. For example, can you replace the phrase “… enables you to…” with “… lets you…”, as in “This feature enables you to…” with “This feature lets you…” This sounds trivial, eliminating six characters out of the twenty-seven original ones, but consider that that’s a 22% reduction in that one phrase.
I’ll add that if you know you’re heading toward mobile output, consider getting an editor to do traditional tasks like copy-editing in order to shorten and simplify your content for mobile in particular, and any writing in general. If you’re an editor, doing a before-and-after edit might be a way to sell your services to companies that are moving toward mobile output and have large amounts of textual content.
19. [LIMITED] – Limit content to what the user has requested.
This recommendation suggests that content may have to change dynamically in response to user requests. This suggests the presence of a database on the server that reconfigures the content in real-time. That capability is starting to become available for tech comm., currently in AuthorIT’s Aspect product (http://www.author-it.com/index.php?page=aspect), but is still an enterprise-level product and thus not cheap.
To a degree, however, we can limit the content to what user request by making the most rigorous possible use of topic-based authoring – writing the content in small chunks and giving those chunks the clearest possible titles, index entries, search synonyms, and other retrieval mechanisms that our authoring tools support.
In summary, if you’ve written the content tightly, used topic-based authoring rigorously, and identified what content applies to what functional and usage environments, then you should be on track to support single sourcing to mobile. And the points in the previous sentence are simply good writing anyway, mobile or not.
More to come…
No comments:
Post a Comment