3 Problems with Context Sensitive Help Today
Time and again we are approached by technical communications experts asking if it is possible to create Context Sensitive Help (aka CSH or contextual help) using the Iridize training platform. The first time this happened I had to look up Context Sensitive Help, as the term was completely new to me. When it happened again and again it got me thinking:
- Is there something missing with existing context sensitive help systems?
- Can our own training platform provide a better solution to any of the existing problems that technical writers currently face in this arena?
In my research, I naturally came across the existing solutions in this field. I was able to quickly identify the key players: Adobe Robohelp, Madcap Flare, Proprofs (formerly Help iQ) and Webworks ePublisher.
Setup and Developer Dependency
All four existing solutions require very tight collaboration with a developer. So much so that the documentation for all of the solutions added a special planning section quoting something along these lines: “Creating CSH is mostly a joint effort between you and the software developer.” Or, put less subtly: “This is going to be a very long and bumpy ride – buckle up!”
Once the setup is complete, if the writer wants to update a certain CSH element s/he can do that without a developer’s help. However, if a new CSH element is needed or one needs to be removed – back to the developer it is. If you are wondering why after initial setup your CSH comes to a full stop and remains in a state of stagnation – this is the reason.
On the user’s end of things, things aren’t looking much brighter. In order to access contextual help, the end user has to actively request help in one of the following ways:
- Press F1
- Click a Help button
- Click a question mark icon
All of these options move the user further away from his help. Any additional click makes it is less likely your end-users will actually see the contextual help, or even seek it.
Yes, Context! I strongly believe that context sensitive help solutions today are lacking in context, which is ironic, given the, er, context. The following definition is taken from Adobe RoboHelp. A context-sensitive Help (CSH) topic provides information about the user interface of an application relative to the task a user performs. The definition implies that the only relevant context in question is the page/section the user is currently on. It completely ignores the user’s context. For instance:
- Is the user a veteran or novice user?
- Did the user just complete a related task?
- Is this the first, second or tenth time the user is performing this task?
All of these questions relate to the user as the focus of context, the context in this case being – the user’s experience on the application, her history, her actions, her behavior and any issues she may be having. Currently, Context Sensitive Help that only addresses elements the user is engaged with at that moment are merely an expansion of mouse-over help one can see when hovering over an element.
A New Approach to Context Sensitive Help
In 2016, this can’t be the best we can do. Context Sensitive Help needs to expand its definition to include the user’s context in the application; it needs to be more accessible, flexible and DIY for content and support specialists and it needs to be pro-active, rather than reactive and overlooked by passive and discouraged users. Technology has come a long way since this:
Technical writers and content strategists are in a much more powerful position today, to recruit technological innovations as help solutions, to be integrated into live software and provide context sensitive, interactive, proactive help to users.
Looking for a sustainable context sensitive help solution?