Adobe released the latest version of RoboHelp last week, and we’ve taken it for a quick spin around the block. It’s called RoboHelp (2015 Release), but we’ll call simply call it RoboHelp 2015.
Last week, I visited Gamescom in Cologne. Gamescom is the largest exhibition and trade fair for computer games in Europe, with over 335,000 people attending this five day event. We visited for social rather than business purposes, but it led me to reflect on the work we and others have done in writing documentation for the games industry.
Google has updated Chrome in build 27 to include conversational voice search, and this feature extends to the Help pages.
According to TechCrunch, it transcribes your queries in real time. It also lets you use natural language, asking Google straightforward questions and getting straightforward answers, both read back to you by dictation and in actual Google search results.
Based on a few initial tests, for South East English accents, it works really well.
One of the graphs posted in yesterday’s blog showed the number of people searching for IPad Help.
Here is the graph:
For a product that “just works”, there is an increasing number people searching the Web for iPad Help. However, part of that increase can be put down to the increasing number of iPad sales:
What we can conclude is that even users of products as simple and intuitive to use as the iPad search the Web for Help on how to use it. If you decide not to provide that Help, then users are likely to get the information from someone else – either in a forum, a YouTube video, blog, Web site etc. Places generally, outside of your control.
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.
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.
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.