Common sense isn’t always common

Here’s some examples from Munich of what might seem to obvious and common sense to the one audience, but not to others.

Traffic lights that have four lights, with the symbols , O, I and K:

Munich traffic lights

Pedestrian crossing lights that have two people instead of one:

Munich traffic lights

The second set of lights is still comprehendible (hold the hand of the person next to you, whilst you’re waiting to cross the road ūüėČ ), but the first set didn’t make sense to even the (non-Bavarian) German members of our party.

The sad case of GDS and the tax manuals

The UK’s Government Digital Service has been doing great¬†work in putting¬†users’ needs before the needs of government, so it was a shock to see the revised tax manuals the GDS and HMRC published¬†recently.

In the GDS blog post,¬†First HMRC manual on GOV.UK ‚Äď give us your feedback, Till Worth explained:

“HMRC has built a new publishing system which makes it easier for its tax experts to update and maintain the content of the manuals. Tax agents, accountants and specialists need to be able to see the tax manuals exactly how HMRC publishes them internally, so the GDS team knew we couldn‚Äôt touch the content. We did create a new design for the manuals to make them more user-friendly and bring them in line with GDS design principles.”

From what I can see, there’s been two changes:

  1. New look and feel
  2. Changes to the navigation and search

Continue reading

The ideal length for instructional screencast videos

Screencast videos have become a popular means for delivering “how-to” information. One of the questions developers must address is, how long should you make your screencasts?

Axel Luterh SAPAt last weeks’s tekom conference, I saw an interesting presentation by¬†Melanie Huxhold and Dr¬†Axel Luther of¬†SAP on how they develop screencasts for SAP’s products (Produkt- und Lernvideos als ideale Erg√§nzung¬†zur klassischen Dokumentation).¬†In their presentation, Melanie said they had determined the ideal length for their videos by sending out a questionnaire to users, asking them what they preferred.

Continue reading

The over optimistic user

On Dara O’Brien’s Science Club (BBC 2) this week, neuroscientist Dr Tali Sharot explained “Optimism Bias”, suggesting that our brains may be hard-wired to look on the bright side.

Here is her TED presentation on the Optimism Bias:

Nearly everyone is optimistic they will never get divorced, and they are an above average driver, when statistically that’s just not possible. It seems reasonable to infer that users of software are ¬†also over optimistic, believing they are an average or above average user in their ability to use an application.

This has an implication for those developing user documentation and training. It seems likely that most people will believe they don’t need to read the documentation (or receive training) when they actually do.

Does looking at online Help make users forget?

Treasury at Petra, JordanOver the weekend,¬†Dr Chris Atherton suggested I look at “the doorway effect”.¬†You may well have experienced walking through a doorway and then finding you’d forgotten why you’d stood up in the first place.

Researchers at the University of Notre Dame have discovered your brain is not to blame for your confusion about what you’re doing in a new room Рthe doorway itself is.

 

 

From Scientific American:

The researchers say that when you pass through a doorway, your mind compartmentalizes your actions into separate episodes. Having moved into a new episode, the brain archives the previous one, making it less available for access.

The doorway can be a virtual doorway as well as a physical doorway.¬†The researchers’ experiments involved¬†seating participants in front of a computer screen running a video game.

So is this effect also happening when users need to leave a screen in a software application and read Help – be it delivered as a .CHM file, on a Web site or on paper?

The solution? If we deliver User Assistance (Help) in a way that it is actually located¬†within¬†the application screens, not only can we minimise the need for users having to go through a virtual door, we can also embed the learning into the users’ specific situations.

More: Scientific American article

Measuring the value of Help in desktop applications

One of the challenges for Technical Authors is quantifying the value of what they produce. For example,¬†how can you tell how many people are reading online Help when the software is installed on someone’s desktop computer? One application mentioned in passing as last week’s UAEurope conference, ApplicationMetrics, might be able to provide the answer.

ApplicationMetrics collects usage and platform data, behind the scenes. It’s a product that is no longer being developed any more, but you can still download it. It may enable you to collect “operational funnel” data that’s similar marketing funnel data – test and track whether users are going to the help and resolving their issues.

 

Towards Flow-Based User Assistance

Flow theory is a psychological concept that is gaining interest in e-learning. It is a concept that should be also considered in the fields of User Assistance and Technical Communication.

Flow is akin to sportsmen being “in the zone” – flow is the situation where people are¬†happiest when they are completely engaged in a task.

Online Help has been traditionally interruptive – people have to¬†subconsciously admit they have failed and need to seek assistance from a Help file, Web page or user guide. The adoption of the term “User Assistance”, instead on online Help, is part of movement towards new models for minimising the situations where users get stuck, helping them quickly should that happen.

The conditions necessary to achieve the flow state include:

  • Having clear goals
  • Direct and immediate feedback
  • The right balance between the user’s ability level and the task
  • An activity that is intrinsically rewarding.

Flow-based User Assistance complements concepts such as adaptive content, as it implies content should adapt dynamically¬†to explain information in the most suitable way. It also complements ideas such as affective assistance, conversation and community based documentation, in that these may be a more suitable “tone of voice” in certain circumstances.

In practice, this means that User Assistance is likely to be embedded into the User Interface – for example, helping explain what certain concepts mean, and what makes a good choice.

It is a very good approach to take if you are developing apps for mobile phones or tablets. This is, in part, because the iOS operating system has limited multitasking capabilities – you have to interrupt one activity in order to do another.

To adopt a flow-based approach, User Assistance must be planned and considered from the very start of any software project. As it is not a bolt-on to the application, it cannot be left to the end of the project. Guidance text becomes located in numerous different places.

The reward for taking this approach is that users get stuck less often, enjoy the application more and become more capable users, perhaps even at peak performance.

Introducing the Head Up Display. Say hello to the future of the menu

The Ubuntu operating system is to replace its application menus with a ¬†“head-up display” (HUD) box. According to Mark Shuttleworth, Lead design and product strategy person at the company behind Ubuntu:

We can search through everything we know about the menu, including descriptive help text, so pretty soon you will be able to find a menu entry using only vaguely related text (imagine finding an entry called Preferences when you search for ‚Äúsettings‚ÄĚ).

 

One of the comments states:

I suspect that applications will need to give help documentation a more significant place in the development of the application than it currently enjoys. Help seems the logical place to embed command discovery in such a system especially in connection with a capacity for fuzzy searches.