B
Y D O R T E J A C O B S E N
This article outlines the challenges Damgaard A/S faced when designing the help system for its integrated enterprise software, AXAPTATM . As opposed to most other help systems, it was an absolute requirement that help information could be modified. The primary reason for this is that practically no solution is sold out-of-the-box; every installation is tailored to suit the exact needs of the end-user. Additionally, market feedback on our mature product strongly indicated that software modifications should always go hand-in-hand with help information modifications.
The present solution has an integrated third-party editor and viewer and allows for modifications to existing text, as well as the creation of new help topics.
Market demands and expectations are not static for either software or the accompanying help system. We are currently considering the pros and cons of establishing an interface to a standard HTML Help tool rather than having an integrated editor.
Developed by the Danish company Damgaard A/S, AXAPTA consists of a standard business application, with a number of country-specific options to comply with local legal demands on items such as tax reports. The business application comprises functionality within areas such as trade, financial, logistics, production, and warehouse management, and supports several languages and currencies. Since the initial release in 1998, AXAPTA has been marketed and sold through a European and North American re-seller network of about 150 business partners. The re-sellers supply customer-specific AXAPTA solutions for almost all branches of the industry. This means that practically no AXAPTA solution is sold out-of-the-box, but is always modified to suit the exact needs of the specific company.
Figure 1 shows an example of a dialog in the standard application. An example of a dialog from a customized version is shown in Figure 2.
Figure 1 - Standard dialog
Figure 2 - Modified
dialog
If a dialog does not suit a specific customer, or if the customer needs new features, new dialogs can be added.
This is possible because a complete AXAPTA license includes a full development environment with open source code. Additionally, all dialogs in AXAPTA can be modified during runtime.
And what does all of this technical and marketing stuff have to do with the help system?
This has a lot to do with the help system because it is precisely these characteristics that pose special help system challenges. For example:
- When business partners modify a standard dialog, they need to be able to modify the help information for that dialog as well.
- When business partners adds a new dialog, they need to be able to add help information as well.
- Help information must be displayed in the language in which the application is currently running.
Of course, it almost goes without saying that access to modifying help information must be easy and user-friendly.
As the development environment with accessible source code is available and used by all partners, the product has (at least) two distinctly different types of users:
- The end-user who uses the business application, and
- The application/developer/user who uses the development environment.
This means that the help system must embrace two potentially very different types of information.
To meet the challenges outlined in the previous section, AXAPTA has a built-in third-party HTML editor and viewer. The editor is used in-house in the development department to write the standard help information. It is also shipped with the system to enable business partners to add their own help.
The help texts are saved in the application's database and a security system ensures that the texts shipped with the system can never be deleted. However, if rewrites have been created for/by the individual customer, they will always be displayed instead of the standard text.
The help system is used for end-user help information as well as for application developer help.
Microsoft's Internet Explorer is used for viewing help.
The help viewer is opened when the user has a dialog open, and presses F1. When no dialog is open, a help page with information about the help system is displayed.
Figure 3 - Help viewer
Help information for developers is typically reference type information, for example, on the classes and methods available in the development environment. A lot of the information is static and can be auto-generated, for example the syntax of methods, including parameter names and types.
Figure 4 - Developer reference help
Provided that the user has permission to modify the help texts, the viewer toggles from view mode to edit mode when the user clicks the Edit button.
The editor has basic editing features, like paragraph and font formatting, and supports toggling between normal text and HTML source. The latter is an advantage if you need to do some formatting that is not readily available through a menu.
The editor is a standard component with a user interface developed in-house to suit the needs of the writers.
Figure 5 - Help editor
This means that new features can be included when the need arises.
- When a developer creates a new dialog in the application, an empty help page for that dialog is automatically created.
- A help page for a dialog offers the possibility to attach "What's this?" information to all dialog fields.
- When the application is modified, for example by removing a field from a dialog, the help information is automatically modified as well.
- The application's general access control also applies to help system information: If a user does not have access to a feature, then there is no access to that feature's help information either.
- Help information is saved in a database to provide the security system with extensive possibilities for access control.
- The original help information cannot be deleted but can be replaced by the distributor's/user's own text.
- Help information added by the distributor is saved in a separate file.
- When the user presses F1, the appropriate help page opens in view mode.
- A toolbar button switches from view to edit mode.
- Access to edit mode is system controlled and requires a special user profile.
- An index is generated online.
- Links to external WinHelp and HTML Help files are possible.
- Appearance is controlled by a cascading style sheet. The style sheet can be modified or replaced by another one.
- Facilities to search the help information.
At the time of writing, we are releasing AXAPTA version 2.1 -- a little less than two years after the first release. Although less than two years is a very short lifespan for a product, our complete user assistance concept was defined at an even earlier stage. One of the design decisions was to implement the help system as previously discussed. Another one was to have a comprehensive user's guide and a getting started guide in print. The guides focus on the "how-to's" of business processes but are aimed at different stages in the user's work with AXAPTA. As it turns out, both guides have grown quite voluminous, and recent customer feedback indicates that the sheer volume may now be a problem. Customer feedback and usability testing also indicate that two sources of information, online and print, may also be a problem. This is primarily because the user cannot search globally in all of the available user assistance material, and so can never be sure that all of the information is available.
As part of a general usability focus, we are re-examining our user assistance concept. Some of the issues we are currently debating are:
- Ease of use
Users do not necessarily always find it easy or intuitive to use our help system. Some of the reasons are that standard navigational controls (like table of contents, full text search, and proper indexing) are missing, and the layout does not conform to standard HTML Help layout. It is simply not familiar to current Windows users.
- Context-sensitivity
The user gets context-sensitive help when a dialog opens and F1 is pressed; however, it is still out of context because the context is limited to the current form. Typically the user really requires help on the current process.
- Searchability
Help information is not globally "searchable." This is not because of any flaws or defects in the help system, but rather because some of the information the user would expect to see online is only in the printed manuals.
While deliberating the impact these issues might have on our existing help system and on our user assistance concept, we also need to focus on the advantages that our custom help system has provided to ensure that we do not lose more than we gain. For example, the system automatically generates and updates syntax information.
Right now the most feasible path forward seems to be modifying our help system to interface with a standard HTML Help authoring tool. The interface would be a map file with topic IDs and map numbers. Our current help system creates a new, empty help topic when the developer creates a new dialog. With a map file interface, the help system would create an entry in a map file instead. The map file would then be used with the HTML Help authoring tool to provide context-sensitive information for window-level help. The context-sensitive topics would be part of a standard Microsoft HTML Help file with all the standard navigational features.
Interfacing to a standard authoring tool through a map file still leaves some control with the internal help system. This might be utilized to retain the feature of having automatically generated information written directly to an HTML file named according to the information in the map file.
To obtain full, global searchability, the current hardcopy manuals would have to be converted into HTML Help files. The context-sensitive topics would be part of those online help files.
All of these considerations are still in their infancy, and the direction outlined above may not be the one we choose to pursue. Findings from usability tests and market feedback, however, definitely indicate that there is room for improvement. Nothing is static within the world of software, and the accompanying user assistance must be sure to follow suit.
Damgaard Development A/S has a Peer Showcase at the WinWriters Online Help Conference, San Diego, March 5-9, 2000. You are most welcome to visit us. To learn more about Damgaard or our products, please see our Web site: http://www.damgaard.com/. You can reach Dorte Jacobsen at dja@dk.damgaard.com.
Volume 3, # 1