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:
Pedestrian crossing lights that have two people instead of one:
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.
Mozilla is an organisation that always seems to be doing innovative things with their documentation. One of the experimental functions it has introduced to its Kuma wiki platform for the Mozilla Developer Network (MDN) documentation is an experimental PUT API that makes it possible to create and update articles remotely.
Mozilla suggests a number of ways it can be used:
You can create a page for your project and update content in certain sections from automated build, testing, and deployment scripts. This can help you keep your community up to date with your project’s progress.
If your project offers documentation alongside source code, you can push HTML renderings into a subsection of MDN. This lets you maintain docs in a way that’s appropriate for your team’s workflow, while still contributing to MDN and allowing localizers to translate the content.
Fro example, Mozilla’s programmers are able to write scripts that automatically generate articles based on contents of header files they’re creating. The API uses HTTP, which means software engineers (and other writers) effectively have the freedom to use the application environment and libraries of their own choice.
Kuma itself is an open source platform written by Mozilla in Python, using the Django framework. Contributors can fork the Kuma repository on Github, make changes to the content, and push the revised content back to the wiki.
It will be interesting to see if this succeeds, and if this type of platform extends further out than its use for developer documentation.
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.
“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.”
Peter J. Bogaards posted a link on Twitter yesterday to an article and a press release on how IBM is adopting a design-led approach to software design.
“IBM Design Thinking is a broad, ambitious new approach to re-imagining how we design our products and solutions … Quite simply, our goal — on a scale unmatched in the industry — is to modernize enterprise software for today’s user who demands great design everywhere, at home and at work.” (Phil Gilbert, general manager, IBM Design)
I understand the IBM Design Thinking approach will affect everything it does: product development, processes, innovation, and, interestingly, the technical documentation/user assistance associated with products. Both design and traditional technical communication share the same goals – to deliver something that is very usable, robust and aesthetically pleasing – so it makes sense to have the two teams aligned closely.
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?
At 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.
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.
At the UAEurope 12 conference, SAP’s Keren Okman quoted a shocking statistic: that the average mobile or tablet app* is used an average of just 3-4 times by a user.
The issue of “app abandonment” is one that is likely to be of greater concern for software developers in the future, as they invest ever increasing amounts of time and money into developing apps for tablets and mobile devices.
Keren said SAP’s response has been to get their Technical Authors involved in writing the product descriptions displayed in app stores. This is the information people read before deciding to purchase. They plan to rewrite these descriptions and provide more guidance on how to use the produce before customers get started.
In the same way that developers are now considering a “mobile first” strategy when they develop new software and web sites, we may be seeing the beginnings of a “Help first” strategy as well.
A “Help first” strategy is where developers abandon the belief in the totally intuitive app (one that sells itself, requires no online Help and only needs limited support) and recognises the limitations of mobile operating systems require Help/User Assistance to be designed into the application from the very outset of the project planning.
To prove this, developers can use A/B testing to reduce app abandonment and evaluate how much User Assistance is needed.
Unfortunately, if app developers leave the planning for Help to the end, then their app has probably already failed.
*App is a term used for software applications for mobile and tablet devices.
Over 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.