Some software applications enable users to configure and customise the screens and workflow to suit their situation, so wouldn’t it be nice if the user documentation could adapt to suit each individual user’s situation?
Let’s outline a couple of use cases:
- There’s a bug tracking application that works for a range of different programming languages. Some people may use to debug Python, others may use it to debug C++. When the Python users read the documentation, they want to see Python code examples. Equally, the C++ users want to view C++ examples.
- There’s an Enterprise Resource Planning application that organisations can customise to suit their business. An organisation removes some screens and fields, and it only wants users to see Help content that’s relevant to their situation.
A software vendor can offer this type of solution in a number of ways. Below are three popular approaches:
Where the application can identify the changes that have been made to the system
In this scenario, the link to the Help content can be used to control what Help information appears. The link to the Help contains parameters such as:
- www.example.com/Help/GettingStarted?var1_programminglanguage=Python
- www.example.com/Help/GettingStarted?var1_programminglanguage=C++
The software application detects the configuration and inserts the parameters into the link. The Help content itself is stored in a Content Management System (CMS) that uses these parameters to provide content dynamically – embedding Python or C++ code examples into the page, depending on the parameters sent to the CMS.
Where the application can identify the individual users
Another approach is have each user login to an application, and use a directory to identify and control which Help pages they seem. If the organisation is already using the Lightweight Directory Access Protocol (LDAP), the application can integrate with that list of names. This approach works well for company systems and intranets, where you need restrict access to particular individuals or groups. It also works well if you want to customise the content based on whether someone is a beginner or a power user, or if they are located in a particular country or subsidiary.
The Help content itself is stored in a Content Management System (CMS). Topics (or collections of pages) contain metadata that categorises the content by audience type, management level, level of complexity etc. The CMS uses the LDAP and page metadata to filter the content and, again, provide content dynamically.
Where the users want to control what they see
Another approach is to let the user decide what information they to see. The Help system filters and hides the content, based on the user’s preferences profile. The Help content can be stored in a CMS or a Web-based Help system (generated from a Help Authoring Tool such as Flare or RoboHelp).
The problem with approach is, in some scenarios, the hidden content isn’t hidden from the search engine (it can mean the quality of the search results are poor) or from someone looking at the source code (so it won’t work for confidential information).
How do you do it?
Use the comments box below to share your thoughts.
Leave a Reply