Reducing app abandonment

Posted on Thursday, 28 June, 2012 by ellis

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.

Does looking at online Help make users forget?

Posted on Wednesday, 27 June, 2012 by ellis

Treasury at Petra, Jordan 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.

More: Scientific American article

Cherryleaf Web site maintenance

Posted on Monday, 25 June, 2012 by ellis

The Cherryleaf web site will be down for a little while on Monday, in order to compete a software upgrade. The blog will be unaffected.

Measuring the value of Help in desktop applications

Posted on Wednesday, 20 June, 2012 by ellis

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.

Why Technical Authors make the best Project Managers for Agile projects

Posted on Tuesday, 19 June, 2012 by ellis

Red Gate Software’s Dominic Smith mentioned in his presentation at UAEurope conference that the company had found Technical Authors were ideally suited to take on the role of Project Manager for small Agile software development projects. In fact, Red Gate had morphed most of its Technical Authors into to a hybrid Project Manager role.

Dominic made a strong case why Technical Authors made good Agile software project managers:

They are focused on the user
They understand the user
They understand a lot of the technological aspects
They are used to delivering projects on time
They are more extravert and people-orientated than programmers (yes, this is broad generalisation)
They ensure User Assistance isn’t forgotten in the project plan, and that it is considered from the very start
They can provide a business focus to the project, and are able to kill projects that don’t make business sense any more.

Do you agree?

Disclosure: Red Gate is a client of ours.

Towards Flow-Based User Assistance

Posted on Tuesday, 19 June, 2012 by ellis

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.

Cherryleaf XML DITA workshops October 2012 – your opinion needed

Posted on Monday, 18 June, 2012 by ellis

We’ve arranged for Dr. Tony Self to host a few training workshops in London this October. Tony is based in Australia, and he also known as Dr. DITA, as he has a PhD in DITA and is the author of The DITA Style Guide.

We’d love your feedback on which XML and DITA training courses we should offer:

Should we offer an introduction to DITA, or is everyone now familiar with it?
Do you want to know more about publishing from XML?
Is there an aspect of XML and DITA you’d like to know more about
What course would you want to attend?

Do let us know!

Any user guide, as long as it’s black

Posted on Monday, 18 June, 2012 by ellis

At last week’s UAEurope conference (and in this season’s Communicator magazine), Dr. Tony Self suggested how car manufacture can be an allegory for the technical communication profession.

Henry Ford revolutionised car manufacture when his production line replaced the method where cars were hand-made by artisans. Famously, Henry Ford offered the Model T in “any colour… so long as it is black”.

There are parallels in technical communication. Many technical communicators are still clinging to hand-crafted documentation, creating custom layouts and “tweaking” formatting, when new modular methods are vastly more efficient. The age of offering documents in any “colour” the customer wants is over. And just as car manufacture has long since moved to automation, technical communication too must embrace automation, with XML providing the technology platform to make this possible.

I think there is even more we can learn from car manufacturers.

While the Model T was initially a success, Ford was slow to replace it with a new model, and by 1930 the company had been overtaken by General Motors. Ford, had, in effect, created a very efficient process for creating something that almost nobody wanted. The process was inflexible and it took them a year to introduce the successor, the Model A. So perhaps, technical communicators need to make sure what they produce efficiently is what their customers actually want.

In addition to learning from Alfred P. Sloan (the head of General Motors at the time), we can also learn from today’s car manufacturing processes. Today, many manufacturers use Lean manufacturing. Lean focuses on stripping out waste – if something does not add value to the customer, then it is eliminated. In other words, Technical Communicators need to quantify and demonstrate the value of their documentation to the customer, if they want to use car manufacturing as their model for the future.

Rethinking technical communications, rethinking Technical Authors

Posted on Friday, 8 June, 2012 by ellis

Our June newlsetter contains a links to a flurry of articles on rethinking technical communications. We’ve added comments to a number of these articles, and I thought it might be worth summarising our thoughts on the likely future for technical communication.

Today, many products are not always “technical”

A lot of technology today is part of day-to-day life. It can be mundane, almost a commodity. This means some of the principles, business benefits and techniques in the world of technical communication are not relevant. For these products, we need a new approach, new business benefits (of which there are many) and different techniques.

Even in easy-to-use, intuitive products, there is still a need for user assistance, and many products still have it. It’s often in many different places, under different names, and it may not have been written by a Technical Author.

We also need to determine which products are technical and which products are no longer technical. For example, we may need to adopt the traditional approach for Systems Administrator related functions and a new approach for end users.

We can measure the value of technical documentation if we put it on the Web

Web analytics, A/B testing, user ratings and user comments can give us a much richer insight into the value of user documentation. From our research into the view of Technical Publications departments in UK technology companies, the only ones who could quantify their value to the business were those who had their content on the Web.

Resistance to change is often from outside the Technical Publications department

Others can have a perception as to what user documentation looks like, and can feel that anything new might adversely affect training or support revenues.

Just because there’s a need for user documentation, there’s no guarantee Technical Authors will do it

Others may claim it’s part of their job role, and new job functions may appear.

Commentary rather than conversations

Conversations are essentially oral – they have a rhythm, they repeat. I know a number of traditional storytellers, and I suspect their approach may be a better model: there is a “teller” of the information who often responds to questions and feedback from the audience as the story is told. The differences between conversation and commentary are: there’s a primary teller; the core information stays the same, but it can adapt to the audience. Writing and speaking differ – writing is much more succinct and efficient.

There is light at the end of the tunnel

For Technical Authors that change the approach they take (if it’s not working), either through skunkworks projects or officially approved pilot projects, low cost technology is available that can deliver a different type of user assistance. The move to mobile may well force significant change onto the User Assistance – a healthy shove towards new approaches.

A help system with 3 million readers, 800K edits and 3K comments