TCUK12: Internationalisation as an accessibility issue

Addressing internationalisation and accessibility issues are two complementary ways to make technical communications (as well as products and web sites) more inclusive. Attend a panel discussion at TCUK in October to find out what pitfalls internationalisation and globalisationcan bring and what others have done to address them.

The panelists

The panel brings together four internationally experienced technical communicators:

• Karen Mardahl is TCUK’s keynote speaker of this year’s accessibility stream. She believes in encouraging technical communicators to develop their skills and knowledge to strengthen their role in any organisation, but especially to do their part in making products and services more inclusive for all people. Living and working in Denmark, she has experienced the subtle challenges of negotiating technical communications in an international, intercultural context first-hand.
• Robert Hempsall is a specialist information designer whose international clients, such as international airlines and telecommunicartions companies, require forms, bills and letters designed for efficient localisation and maximum accessibility.
• Ray Gallon is currently an independent consultant, specializing in the convergence of user guidance and usability for international companies such as General Electric Medical Systems, Alcatel, and Ilog-IBM. Ray is currently a member of the international board of directors of the Society for Technical Communications (STC) and past president of the STC France chapter. He shares his life between the Languedoc region of France and the city of Barcelona, Spain.
• I will be moderating the panel and insert the occasional anecdote or lesson learned from my experience of 13 years of writing software documentation in English that is accessible and useful for users all across Europe.

The topics

The focus of the panel will be a dimension which frequently shuts out wide ranges of customers and users: National borders and the languages and cultural conventions they denote. Internationalization is an accessibility issue in user interfaces and documentation. In several ways, it affects whether you can reach your customers and how well.

For example, in documentation (and user experience design as a whole), language can be:

• Inclusive when it is comprehensible to customers who speak English as a Second Language
• Exclusive when it relies on specific cultural conventions, idioms or references, including common items, such as date and time Readability can be

The presentation of examples and entry forms can be:

• Inclusive when they support different international conventions
• Exclusive when they are limited, for example, to 5-digit zip codes

How to distinguish corresponding strategies?

• Localization: The adaptation of product and documentation to a specific market, a locale.
• Internationalization: The presentation of product and documentation that enables efficient localization in different cultures and languages.

Our panel discussion discusses these issues and more with examples and suggestions how to make technical communications more inclusive in terms of language and culture and hence more successful internationally.

If you know additional questions or topics of internationalisation as an accessibility issue, please leave a comment.

Top 3 reasons to do a language edit

There are several good reasons to do a language edit and most have to do with the overall quality and usability of your documentation. That’s the lesson I learned while editing our upcoming Release Notes for language.

The language edit is the unloved stepchild of the tech writing process: It is frequently last in line and gets less attention than the actual writing and the content review. Yet it really impacts the quality of the documentation, precisely because it occurs so close to publication. Here are three benefits of a language edit.

Correct, clear and consistent language

The most obvious benefit is to ensure that the language in the document is correct, clear and consistent. This is why you do it in the first place. And it is especially important if the documentation is written by several authors. Even if you have a really good and detailed style guide, you’re bound to get different ways to interpret it – to put it benevolently…

Ensuring clear language requires a language editor who is well-versed in the subject – but not so steeped in it as subject-matter experts (SMEs) who may review content who often have too much of an insider’s view and won’t spot potential misunderstandings. (Many SMEs are also uncomfortable with reviewing language, either because they lack the skills or because it distracts them from the review they should be doing.)

Ensuring consistent language requires an editor who reads across the complete document – instead of distributed authors and reviewers who work on a chapter each. Most chapters I encountered had their distinct style, but the differences between chapters couldn’t have been greater if they had been in entirely different documents. This seems to be a stylistic issue at first, but it spills over into the other two reasons for a language edit, so follow me on to the next item which is…

Consistent structure

Our standard operating procedure for writing Release Notes contains a standard structure which each entry should follow. Essentially, it looks like this:

• Summary of enhanced or new feature
• User benefit of feature
• Prerequisites of feature
• How to use feature
• Results and next steps of feature

Depending on the scope of an enhancement, some of these structural elements per entry are optional. A new menu option may be self-explanatory enough, so we don’t need to point out the user benefit, and there are no special prerequisites. The whole entry may be but two sentences long.

However, it is a matter of judgment how many details and customer guidance we want to provide. For a team of distributed authors, this is almost impossible to agree upon before hand. A language editor can help to ensure consistent structure. This may require consulting with the author about missing structural elements, but if they’re quick to respond, it is well worth the effort.

Raising documentation standards and value

While you are talking with authors about missing elements, this is a good chance to offer feedback about recurring issues. I’ve noticed that some authors have their “favorite” mistakes. One has missed a guideline in the style guide and keeps repeating the same small mistake. Another may have a larger misunderstanding, whether it’s about topic types, the use of personas, etc.

The language editor not merely improves a document, but in the process also performs a thorough audit of current documentation practices. So she or he can help to ensure adherence to documentation standards and raise the value of the documentation you publish. A language edit is often the last chance to ensure your final document feels and works as it should and lives up to your corporate and documentation standards. Omit it at your own peril.

For more about editing, see my earlier post “Editing for tech writers“.

- Do you do language edits? What benefits do you get from them? Which shortcomings made you wish you had done one? Please leave a comment.

Find out how users use your documentation

Asking good questions of your users is essential to know how your customers use your documentation. This is part 2 after my post about using a survey to get to know your audience. The introductory paragraphs are identical to last week’s post, so feel free to skip ahead to the two paragraphs before the next heading.

A recent thread at Technical Writing World got me thinking about user surveys and revisiting two posts from 2010 where I wrote about obvious, but not so helpful questions and how to segment users and survey your documentation.

You can get all kinds of answers from your users, but depending on your questions, I find some answers more helpful than others. Jakob Nielsen’s position about usability makes a lot of sense to me:

Pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior.

But if we cannot observe users, we have to rely on what they say – and try to ask them questions which yield useful answers. If you include an odd number of set answers in your survey, you can slice up the results (instead of having to deal with freewheeling answers), and users have a chance to select the option in the middle if they want to.

- Here are some questions that can help you to find out how successful your documentation is. Note that it doesn’t simply ask customers what they want. Instead, the questions can help you to determine which deliverables and which topic types (such as concepts and procedures) need improvement.

There are obviously other and better ways to determine user behavior, from usage analytics to user-generated content – but many technical writers don’t have the mandate or means to simply use them. These ideas are for them.

How do you use the documentation?

Do you use the documentation…

• To set up & configure <our product>
• To operate <our product>
• To learn about the business
• Not at all

When you need help, where do you normally seek information?

• I look in <product> online help
• I look in <product> user manuals
• I ask a colleague
• I call customer services
• Other

How frequently do you use <our product> online help?

• Daily
• A few times a week
• A few times a month
• Once a month or less
• Never

How frequently do you use <our product> user manuals?

• Daily
• A few times a week
• A few times a month
• Once a month or less
• Never

How successful are you with the documentation?

Can you find the information you need in the documentation quickly and easily?

• No, not at all.
• More or less.
• Yes, very much so.

Is the documentation that you find accurate and complete?

• No, not at all. | More or less. | Yes, very much so.

Is the documentation clear and easy to understand?

• No, not at all. | More or less. | Yes, very much so.

Does the documentation help you achieve your task?

• No, not at all. | More or less. | Yes, very much so.

Does the documentation provide sufficient theoretical and business background?

• No, not at all. | More or less. | Yes, very much so.

Are you satisfied overall with <our product>’s documentation?

• No, not at all. | More or less. | Yes, very much so.

Your turn

Which questions do you use to find out whether your documentation hits the spot? Feel free to leave a comment.

A user survey helps you to know your audience

Asking good questions of your users is essential to know the audience of your documentation.

A recent thread at Technical Writing World got me thinking about user surveys and revisiting two posts from 2010 where I wrote about obvious, but not so helpful questions and how to segment users and survey your documentation.

You can get all kinds of answers from your users, but depending on your questions, I find some answers more helpful than others. Jakob Nielsen’s position about usability makes a lot of sense to me:

Pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior.

But if we cannot observe users, we have to rely on what they say – and try to ask them questions which yield useful answers. If you include an odd number of set answers in your survey, you can slice up the results (instead of having to deal with freewheeling answers), and users have a chance to select the option in the middle if they want to.

Find out who your users are

If you write for different markets, audiences or countries, it’s important to distinguish user profiles and their answers. It will help you understand the answers in context of questions such as the following.

Which edition/version of <products> do you use most (please select only one)?

• Users of “smaller” editions judge your product and company by the help they need from the documentation: If they get started quickly and find information easily, they will be more likely to recommend your product and upgrade to “bigger” editions.
• Make sure you assign feedback correctly and don’t mistake criticism of older versions for feedback on your more recent efforts.

For how long have you worked in the industry? <or:> For how long have you worked with <products like ours>?

• In B2B markets, novices might need more conceptual help than seasoned pros.
• Experienced users can often offer more qualified feedback of your documentation in comparison to that of competitors.

For how long have you worked with <our product>?

• Novice users rely more frequently on “Getting started” documentation
• Experienced users can offer more reliable feedback on reference documentation.
• Experienced users (especially if they are loud or many) require a comfortable change path when product usability changes. Remember the opposition to Microsoft Office 2007 ribbons by heavy users of previous versions.

How frequently do you use <our product>?

• Infrequent users probably rely more on finding more basic information – and finding it again.
• Frequent users may need more detailed information.

- What other questions should we ask about our users to ensure we put their answers into the right context? Please leave a comment.

Art vs. online: 2 dimensions of curating

Curating is a cool word, or trendy jargon, for what happens in web technologies and in art museums, but they are fundamentally different activities.

In this post, I want to add an alternative view to Rachel Potts who recently wrote about “When software UX met museum curation“. Where Rachel emphasises similarities, I’d like to focus on the differences, especially as they relate to art museums.

Your artefacts

One serious limitation and difference in curating at art museums, compared to anything in software and online, is that you need to care for original, unique works. If you mount a special exhibition, you need to procure them to begin with. And sometimes you cannot get them, no matter how much you want them in the show to present an artist or an era in history or to make your case.

• Some works don’t travel because they’re fragile or because the insurance is too costly or because they’re centerpieces in the collection that owns them.
• Some owners won’t lend works to you, because you cannot satisfy security requirements or because you’re too small a museum or because they don’t like your director.
• Some works are simply lost.

Of course, you can always do with fewer or lesser works or, in the case of historic artefacts, with copies, but that invariably hurts the critical response and your attendance.

"Stalking Christina" - other people regarding my favorite painting

Your objectives

Another difference is that for many art museums “enabling users to learn” is one objective among many. And several other objectives are, unfortunately, at odds with it:

• Some pieces are too sensitive to light or touch or movement to allow more than very few people to experience them.
• Some museums need to please or placate donors (who may influence what’s shown and what not) and trustees (who may influence what gets paid for and what not).
• Some museums don’t have the means: They lack the manpower to accommodate visitors more than a few hours per week. Or they don’t have the expertise to allow them to learn well.

Your audience

A third difference is that art museums who put on ambitious, critically well-regarded exhibitions find that attendance is surprisingly low. The reason is simple and disappointing: Many people don’t want to be enabled to learn in art museums. They don’t want to learn new things, much less have their beliefs challenged. Instead, many people visit an art museum, because of the way it makes them feel:

• Many go to be in the presence of beauty or to be awed. Hence the success of any show whose title mentions a best-selling artist or any of the words “Impressionist”, “Gold” or “Gods” – even if the title is far-fetched and the show mediocre at best. “Dinosaurs” gets kids, and anything that flies or shoots gets their dads.
• Some go to feel cool. Hence the success of after-work parties in modern art museums.

The words

Roger Hart once told me, it’s futile to try to stop linguistic change. And the web is a great change agent of language:

• How many kids today know that women warriors (or a river) gave their name to an online store?
• The German language has known about “email” for centuries (though we only spell it thus after a recent change in orthography); in English, it’s known as “enamel”.

But if language is to represent the real world, I advocate to respect the differences within one word, such as curating. Conflating two similar activities into the same word cheapens our experience of the stuff that surrounds us.

Proving the benefit of consistency in tech comm

To ensure efficiency and accessibility of technical communications, use consistent, common formatting, for example, for interface elements. What sounds obvious to many technical communicators is actually proven in academic studies. This post is for people looking for proof that consistency has a benefit in technical communications.

I’m taking my cue from a question that appeared in a LinkedIn group:

[I need to] find studies or tests that show that it is value-adding to have consistent formatting on e.g. User Interaction elements (such as buttons or handles) in your instructive documents. Can anyone share studies or tests in this area?

I can offer an answer on two levels:

• The general benefits in terms of human perception
• The particular benefits of consistent documentation

The neuroscience of consistency

Human perception favors consistency. The mind groups things easier, faster and with more confidence, if they’re consistent and have something in common.

Gestalt law of similarity: The mind groups similar elements into collective entities, from Wikipedia.

Psychological studies have shown two principles by which human perception groups things: Proximity and similarity. For a comparison of these two principles and further references, see Han, S., Song, Y., et al. (2001). Neural substrates for visual perceptual grouping in humans. Psychophysiology, 38, 926-935. Han and colleagues actually quote several studies that “proximity is a more salient cue than similarity.”

In technical comunications texts, we usually can’t practically lump all names of windows or fields across all topics together to show they’re related.

But we can resort to similarity to help readers understand that we mean a GUI element at each occurrence. If we always write their names in bold, for example, readers will recognize that similarity across topics and learn to scan for it (whether they’re aware of it or not). If we always mark up GUI elements somehow, sometimes in bold, sometimes in italics, readers are more likely to wonder if the different markup has a meaning – and they won’t be able to scan the text as quickly and reliably.

For more psychological research and how it applies to technical communications, refer to Chris Atherton‘s excellent and accessible article “What and where?” in ISTC’s Communicator quarterly, Spring 2011, pp. 28-29.

Studies of applied consistency

So much for the theory. But does consistency, for example in formatting GUI elements, have an actual benefit in documentation?

One very good resource to argue for such consistency is the Research-Based Web Design & Usability Guidelines. This 292-page tome sets out “to provide quantified, peer-reviewed Web site design guidelines”. It was published by the US Department of Health and Human Services in 2006 and is available for free download, as a book and as individual chapters.

Chapter 11 on “Text Appearance” has a couple of applicable guidelines:

#2 Format common items consistently

Common, recurring items, such as telephone numbers, time records, button and window names should be formatted consistently, according to expert recommendations in: Ahlstrom, V. & Longo, K. (2001). Human factors design guide update (Report number DOT/FAA/CT-96/01): A revision to chapter 8 – computer human interface guidelines.

#4 Ensure visual consistency

Visual consistency, including the appearance of characters in interfaces, reduces user errors. “Studies found that tasks performed on more consistent interfaces resulted in (1) a reduction in task completion times; (2) a reduction in errors; (3) an increase in user satisfaction; and (4) a reduction in learning time.” The quoted studies include:

• Adamson, P.J. & Wallace, F.L. (1997). A comparison between consistent and inconsistent graphical user interfaces. Jacksonville: University of Northern Florida, Department of Computer and Information Sciences.
• Eberts, R.E. (1997). Cognitive modeling. In: G. Salvendy (ed.), Handbook of Human Factors and Ergonomics, 2nd ed., New York: John Wiley & Sons.
• Ozok, A.A. & Salvendy, G. (2000). Measuring consistency of web page design and its effects on performance and satisfaction. Ergonomics, 43(4), 443-460.
• Schneider, W., Dumais, S.T. & Shiffrin, R.M. (1984). Automatic and control processing and attention. Varieties of Attention. New York: Academic Press, 1-27.
• Schneider, W. & Shiffrin, R.M. (1977). Controlled and automatic human information processing: detection, search and attention, Psychological Review, 84, 1-66.

Specifically, Ozok and Salvendy in 2000 confirmed the earlier studies that visually inconsistent interfaces lead users to poorer performance and more errors, see the summary in the Human Factors International newsletter.

- I hope this little field trip into academia can help you to prove that consistency not merely seems somehow desirable and logical, but has actually cognitive benefits proven in studies.

Framing tech comm: O’Reilly vs. Dangerfield

Technical communication is perceived in many different ways, some more constructive than others. Luckily, the framing of tech comm is the result of a dialogue/feedback loop, so we can help to shape how we come across.

Tim O’Reilly on the future

Consider Tim O’Reilly, quite a visionary technical communicator. He works to create “The Missing Manual for the Future“. O’Reilly explains it by quoting William Gibson: “The future is here, it is just not evenly distributed yet.” So we technical communicators can help to distribute the future evenly – a pretty noble mission to be on.

Or consider Kathy Sierra whose Kick Ass Curve taught me that my documentation can help users look good and suck less.

- Of course, just because I find cool quotes on the web doesn’t mean my work and I actually help to “distribute the future” (what does that really mean, anyway?) or help a single user suck less. But it’s the attitude that counts. These ideas inspire me. They give me a sense of the best I can aspire to with my documentation.

Rodney Dangerfield on respect

Photo by Jim Accordino, CC-BY-3.0 via Wikimedia Commons

Or consider these assessments:

• “No one reads the documentation.”
• “Nobody cares, but we gotta have it.”
• “This manual is unusable.”

They seem to be rather common, I sometimes even hear them from tech communicators who graduated from RDSP, the “Rodney Dangerfield School of Professions”. The school is named for its patron saint and his motto “I don’t get no respect, I tell ya…“. RDSP graduates tend to accept criticism, when they hear it often enough, not when they find it fundamentally and immutably true.

Actually, it’s worth finding out in a customer survey how many people do read the documentation – and while you’re at it, try to find out how customers use it and what they expect to find it. Maybe only a few care, but if a company cares enough to do documentation at all, they might as well do it right – and yes, you can get documentation done right on the 80/20 rule. And a manual that’s deemed unusable can be made better and clearer.

Tech communicators on their work

Most of the time, my work speaks for itself. But sometimes it cannot stand up against prejudice and misguided judgements. Then it needs my help. I don’t mean making excuses about a late spec or a review that fell through. I mean moving the critic into the position of the generic customer who reads my documentation and finds it useful.

And when I engage with my readers, whether they are colleagues or customers, they are frequently surprised how much thought goes into my documentation. They marvel that

• Documentation that offers less of a narrative is actually easier and faster to use in the majority of cases when customers look up specific questions.
• Many users welcome the separation of concepts and procedures, because they read concepts just once, but need to refer to clear, bare-bones procedures repeatedly.
• What has recently beefed up our marketing material is actually lifted verbatim from the documentation.
• When they find a mistake, I can tell them immediately what I will do to fix it and when it will be rolled out to customers.

This dialogue/feedback loop gives my work the chance to earn respect by virtue of its benefits. And it allows me to follow the goals that O’Reilly and Sierra have inspired in me.

Your turn

What’s your experience? Does it work to enlighten colleagues and customers just how cool your documentation actually is? Does it help? Please leave a comment.

Keeping your documentation stakeholders happy

Don’t forget your stakeholders and their practices as you improve and change documentation. – That was the humbling lesson I learned (once again) as I presented our revamped documentation to non-tech comm colleagues.

Reporting on progress

The company I work for currently moves its documentation towards more structured writing and topic-based authoring. We’ve already rolled out redefined processes and several topic-based user manuals, so it was an opportunity to present to  non-tech comm colleagues what we’d done already, why and how we did it, and what else was in store. I talked about topic-based authoring and how it’s chunked, task-oriented, reusable, and independent of delivery format. Then I talked about the benefits and challenges:

• For users, topic-based help can be updated more frequently, it is easier and faster to use online, though it breaks the narrative flow
• For everyone working on our module, it means easier contributions
• For the company, it allows to leverage* content after one-time migration efforts

* I know “leverage” is not a verb, but there were managers present who love the word…

I thought I was pretty clever for presenting how cool the new documentation was not primarily for writers, but for users, my colleagues and the company as a whole. And it did go over well on the whole. But there was…

The thing about trains

The most contentious issue turned out to be an unexpected use of the documentation: Current user manuals sometimes contain flowing prose walk-throughs of sample setups with many screenshots. When they are written well, they are nice to read. And allegedly users like to print out the PDF files and read them on the commuter train.

The problem of prose

There are several problems with the narrative manuals for users:

• They are hard to use and search in, unless you want to know exactly the one thing they are describing.
• Any sample setup is bound to miss what they need by a little or even a lot, because our product is highly configurable (you can even customize field names in windows).

There are problems for writers as well:

• The prose is really hard to update when functions or processes change because the narrative flow may require small or large changes in several places.
• The screenshots take longer to update and localize than mere text.

I gave these reasons, invited colleagues to check out the manuals done in the new fashion and cited survey findings that most of our users consult the documentation when they have a specific problem, though very few actually read manuals end-to-end.

But the ultimate lesson for me was that I could focus on our mission all I want, I also need to address the change with my stakeholders not only in rational terms, but also in terms of their habits and expectations.

Your turn

Do you think the customer is always right, even if he asks for documentation that is harder to maintain and harder to use in most cases? How can you promote change among stakeholders which you are sure will benefit everyone in the long run? Please leave a comment.

When redundancy is good: Online help navigation

Redundant navigation can help users find what they’re looking for.

Redundancy in documentation is usually bad: When you have the same content (in different words) in two places, you pay twice for localization – yet you probably only remember to update one of the items. So you risk inconsistencies, extra costs and general havoc.

Not so when it comes to navigation! Redundant navigation can offer your users different paths to get to the one place where they find what they need. The reason this works is because users want to do different things at different times in your help system. (See my earlier post “Top 10 things that users want to do in a help system“.)

Tom Johnson’s recent post got me thinking about this when he asked for “Examples of Help Systems that Provide Users with Multiple Entry Points?” His approach is a bit different, however, from what I have in mind. Tom thinks about “adding metadata to help topics so you can sort them into different arrangements for different audiences”.

My idea is to offer a few additional entry pages with layers of pointers to get users to the appropriate part of the help system quickly. Only some of the options require tags on topics.

Here’s a design I once did for the rather comprehensive online help navigation of an asset management system, we’re talking several thousand topics. (Click on the image for a larger version.)

The idea is that different personalities of users come to the help with different kinds of questions:

• Some users focus on their roles and approach the system from that angle, whether they work in front, middle or back office of a bank or asset management company.
• Other users focus on the task they need to execute – which in an asset management system can be boiled down to five main types of tasks.
• And some users expect to find certain forms of documentation, such as release notes, tutorials, manuals.

Depending on your choice, you would get through 1 or 2 more selection screens until you wind up at a specific help topic. And you could take different paths to get to the same topic.

For example, if you wanted to set up a fund, you would need to get to the topic “Set up a fund definition”. Of course, you wouldn’t know that. But you could get there in various ways.

For example like this:

1. I’m working in: Back Office
2.  > Fund accounting
3.  > I need to set up fund accounting
4.  > Set up a fund definition

Or like this:

1. I want to: Set up static data
2.  > For a fund
3.  > Set up a fund definition

Or like this:

1. Show me: Tutorials
2.  > How to set up SimCorp Dimension
3.  > Fund accounting
4.  > Set up a fund definition

So the idea is to anticipate some of the most common questions and approaches users have to the system and to make the right entry points easy to find. This does not to offer so many paths through the forest of topics as to confuse users, but only signposts to topics we expect every user will hit (as long he is using a particular module at all.

Your turn

Could you, would you use such a help portal that offered different paths or would you bypass it in favor of the tabel of contents on the left and the search? Do you know other help systems that use such a structure? Please leave a comment.

A pattern library for user assistance

Rob Houser is working on a Pattern Library for User Assistance (UA): At WritersUA, he proposed to collect examples for patterns in (embedded) user assistance to help teams and managers with whom UA professionals collaborate to better understand the benefits and value of UA. Among UA experts, it can help to establish and exchange standards by deducing principles and concepts from them.

Rob Houser at WritersUA

UA patterns can be organized by the task they support, whether it is helping users to get started in a new application or task or to assist them in the correction of errors. A fairly well-known example of the first case is Internet Explorer’s help text that appears when you open a new, empty tab. Such a pattern can support users in:

• Understanding conceptual information what has happened, what options the user has, when to use this function and why.
• Make decisions by providing context, reference information about rules as well as hints for best practices.
• Solve problems by describing the problem, showing how to fix it, give background information, if available, and show how to avoid the problem in the future, if possible.

Such a library will be really helpful, because it will fill the gap between very formalized, but abstract topic types (concept, task, reference) as DITA models them and the wide variety of UA that’s actually “out there”.

With a community effort of collecting and annotating patterns, such a library can be a qualified, curated collection of best practices in UA that can help tech writers write better help faster by following tried and proven examples.

So I agree with Rob’s approach and think such a pattern library would benefit a lot of people. Personally, I can’t wait to start and deduce the underlying principles and concepts of sucessful UA patterns. While examples can be instructive, I prefer to work in more abstract terms. This would also square better with the general approach in UA to separate content from style. After all it shouldn’t matter whether UA is provided in the actual user interface (where real estate is often scarce, esp. in mobile applications), in a tooltip or in a separate window.

Chuck Martin also blogged about this interesting session. I’ll be following Rob’s efforts and report when there’s new developments.

Your turn

Is this something that would help you as a tech writer or UA professional? Would it be instructive to have annotated examples of best practices in user assistance? Please leave a comment.