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.

Advertisements

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 illustrated

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

Person reading by a track in a railroad station

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.)

Example for redundant navigation in complex online help system

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 explains the pattern library for user assistance

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.

When tech comm does other teams’ work

Should documentation be expected to do the job of other teams and departments to make up for their shortcomings?

That was the essential question in an interesting conversation I once had with a fellow tech writer. It’s basically a twist on the general idea that you often have to pick two of the three: High quality, speed, low cost.

The writer said she had changed her way of writing user manuals to include fewer screenshots, because some of them were not essential to the described task, and they’re difficult to translate and update.

Less than efficient reuse

Her manager didn’t exactly appreciate her efforts to create similarly useful documentation more efficiently, but objected to the new manual. He asked her to use more screenshots as before, arguing they were necessary for three additional purposes of the manual:

  • Sell the product – though dedicated sales materials are also available.
  • Double as self-study training material – though training is also available.
  • Make up for poor usability where the software isn’t so intuitive in some places.

She is totally capable of creating documentation that can also be used for these purposes. (Apparently, the company didn’t have a content strategy which easily allows to share contents between sales, training and documentation.) But it’s just difficult to do it all when she faces pressure to limit cost and throughput time at the same time.

Possible reactions

During the conversation, my position was that her company can’t reasonably expect her to make documentation more efficient while she continues to make up for other shortcomings. (This ties in with the “Two words every (lone) writer should know“, which are “Later” and “No”.)

Then I thought that maybe her manager doesn’t actually know which tasks an efficient technical writer does best (if you can even generalize that) and what to expect from the sales, marketing and training teams. In this case, it might even be an opportunity to clean up processes beyond just documentation (though this easily gets presumptuous).

Your turn

What do you think? Have you been expected to do things that got in the way of your efficiency and that were really the tasks of other teams? How can we writers deal with that? Any ideas? Please leave a comment.