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.

Advertisement

5 steps from legacy documentation to topics

To move to topic-based authoring, you need to convert existing documentation into topics. The efforts shouldn’t be underestimated, but it’s actually a pretty straightforward process. I’m describing how to convert sections in manuals, but it’s much the same for most content, whether it’s FAQs, wiki articles, training materials, etc.

Prerequisites

• Some knowledge of topic-based authoring. You should know the topic types you will use, for example, concepts, tasks and reference topics.
• Have a tactical framework. Ensure you know the documentation structure you aim for and how you will get there in a project. Consider for example the Top 4 tactics to structure legacy documentation.
• A style guide to which your documentation complies definitely helps.

1. Identify topic type(s) per section

Define each section in your manual as one of your topic types, for example, concept, task or reference.

If topic types are mixed…

A common problem at this point is that you may have topics that mix topic types. For example, your topic contains concept information and task information. Or task information and reference information. For details, see When topics don’t quite work.

2. Re-chunk sections to make them topics

Redistribute your content so each section becomes a topic:

1. Cut out everything in a section that doesn’t fit the selected topic type and put it aside.
2. Ensure that the topic that remains:
• Is either a concept or a task or a reference.
• Presents only one idea.
• Has only one purpose.
• Can stand alone, in context with others.
3. Take the content you have cut out and put aside and do one of the following:
• Integrate it into an existing topic where it fits better.
• Create a new topic for it.
• If it’s not relevant, throw it away. 🙂

If topics are too complex…

A common problem at this point is that you can end up with one or several topics that are too complex. Then you can try the following:

• If you can describe a topic’s content as two separate, but related ideas, turn it into two sibling topics.
• If you can fully summarise a topic’s content only as a very complex idea, turn it into a parent topic and create children topics for it.
• If it’s a long procedure with more than 10 main steps in a top-level numbered list, try to cut it into two topics approximately in the middle.

3. Re-sequence your topics

Re-arrange the sequence of your topics, so they flow nicely when users read not just one or two of them, but need to learn a complete setup or operational process.

1. Verify that your topics are in the best possible sequence and re-arrange them if necessary. You might want to try these categories:
• Setup, in the sequence of tasks.
• Operations, in the sequence of tasks.
• Reference topics, in alphabetical order.
• Concept topics can either appear as a section of their own, ordered from the large/general to the small/particular, or among the other topics as appropriate.
2. Verify that your topics are complete and add topics, if necessary:
• Do you have concept topics for all major elements in your task topics which explain what these elements are?
• Do you have task topics for all concept topics which explain how to set up and operate the elements

If the topic sequence doesn’t flow nicely…

A common problem is that the topics don’t flow as nicely once you have chunked them into stand-alone pieces. In this case, add some “glue” topics which orient readers and ensure a good flow, for example, at the beginning of chapters in books. Consider including these glue topics only in print deliverables; maybe they are not necessary in your online help.

4. Rewrite headings to guide readers

Often your legacy section headings work in the context of your manual, but don’t give users enough orientation when they read just one or two topics. Rephrase them so users can quickly dip in and out of your documentation. Keep these guidelines in mind:

• Reflect the user’s need or goal in the heading.
• Phrase headings so users know what’s in the topic when they see only the heading in a link in another topic.
• Try to make headings unique so there’s no confusion when they appear in search result lists.

5. Add links between related topics

Ensure that your topics have links or cross-references between all related topics:

• Do your concept topics link to corresponding task topics – and vice versa?
• Do your task topics include or link to prerequisites and next steps?
• Do your task topics link to corresponding reference topics?

Your turn

Do you find these steps helpful? Have you converted documentation into topics before? Please leave a comment.

Cheat sheets for Flare keyboard shortcuts

Harness MadCap Flare’s mighty, but daunting user interface with one of three cheat sheets of keyboard shortcuts for MadCap Flare.

We are starting to use Flare to get serious about single-sourcing and re-using our topics. I’ve been using Flare before, but I still don’t always know where to find a certain function or how to quickly open one of its many window panes. This is where keyboard shortcuts come in handy. Of course, I’m not the first user to find them helpful, so you can choose from three different cheat sheets:

The official full monty

The official shortcut reference in PDF by MadCap contains two lists of shortcuts, one sorted by tasks, the other sorted by shortcuts. The annotated tables fill a total of 14 pages. That’s good for an exhaustive reference, but less useful for a cheat sheet to keep next to the keyboard.

The quickie

This 1-page quick reference in PDF is by Scott DeLoach, a MadCap Certified Instructor for Flare who has written the MadCap Flare Certified Test Review + Developer’s Guide, MadCap Software’s Flare Training Guide, and other Flare Guides.

The new homegrown

This is my own new 2-page quick reference in PDF, mashed up from the two previous sources:

Click to download the 2-page cheat sheet in PDF.

It’s 1 page with all shortcuts listed by Flare element and 1 page with all shortcuts listed by action. If you’re using Flare, I hope you find it helpful.

Writing to create context to think – and work

The skill of technical communication is to create a context in which other people can work. – This concise insight helps me to stay focused on my users and their tasks, even if it’s not totally original.

I came to it via an article by Tim O’Reilly in his Financial Times article “Birth of the global mind” where he quoted Edwin Schlossberg:

The skill of writing is to create a context in which other people can think.

 

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.

My tcworld11 presentation “Getting ahead as a lone writer”

You can download the PDF slides to my presentation “Getting ahead as a lone writer” at tekom/tcworld in Wiesbaden on 19 October 2011:

My tcworld presentation "Getting ahead as a lone writer". Click to download the PDF.

For alternative formats and versions, see

• Getting ahead as a lone author, the article from ISTC’s Communicator.
• Getting ahead as a lone author, my TCUK presentation which is a little more verbose and may work better if you didn’t attend the session.

The presentation itself went very well, I think: It felt a bit strange at first to be presenting in English to what seemed to be largely a German audience. But the questions and answers session at the end showed that for many the language barrier was not a problem.

I want to thank the attentive and helpful venue staff and sound technician for their professional, attentive help! They made me feel welcome and in good hands.