[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [user-assistance-discuss] The "Ideal" User Assistance Application?
Hi All, What a great idea to establish a discussion group! I'm not sure which direction you want to take this, but I thought I would include a bit of a wish list. I've worked on a couple of XML-based help projects for different companies, with varying degrees of success. We went this route because traditional help products just didn't do what we needed them to do. This is by no means an exhaustive list, but I would love to see these things possible in one, easy-to-use app: Ability to embed help in the form One of the best quotes I heard about typical online help is that it's like a 2 year old standing in front of the TV, blocking what you most want to see. It's difficult for a user to follow steps when they have to switch back and forth between the app and a separate help window. For this reason, we wanted to embed help in the app. A couple of apps I worked on had context-sensitive content displayed in a frame, on either the right or left side of the main application window. As users navigated through the app, the help content changed. Another allowed users to call field-level help through popped text-bubbles. Both options were called on a click event, and were well received by users. Another displayed help content in the form itself. In all cases we used xml since it allowed us to carve up the help into pieces, and pull what we needed where we needed it. However, we had to develop our own tools to make this work. Since we also included help on controls, it was a difficult, and ugly process. Providing animated help Some things are just really difficult to describe in words, but easy to demonstrate. We wanted to provide animated images to show how to work with some of the controls (like sorting a column). We also wanted to provide training that could be called directly from Help. We used flash demos that were called by a click event on the control, from the field, or from the Help files. Depending on the demonstration, it would either appear in an embedded frame, or in a pop-up window. These animated clips were also pulled together in a separate training tutorial. Ability to have end-users write help Many of the products I've written help for, have varying elements of configuration. In some cases, users could create their own forms and configure the look and feel of the app. This meant that the shipped product beared little resemblance to the configured product, and our clients needed to write their own help. We created a simple UI that allowed users to write their own embedded help, which was then translated to xml that conformed to our schema. Users could also change the stylesheet to provide their own "branding". Generating help to various outputs (single-sourcing) Embedded help worked great when users were looking for information on a specific field or control, but when they needed more general information, using a small frame, or bubble, in the app wasn't practical. We needed to display the embedded help in either a more traditional web-page format, or generate a paper guide. XML allowed us to provide both, since we could use a simple query to determine what should be included and how it should be formatted, and the combination of xml and stylesheets meant we could single-source. This also allowed us to generate guides and web-based help that was specific to the clients' configuration. Bonus! Searching for content This was tricky on 2 fronts. First, clients needed to be able to find information outside of the embedded help. We needed to build our own tool that would let users search for information, and organize the results in a standard format that made sense outside the context of the UI. Second, we were also challenged internally by maintaining the system. We couldn't easily find content in the mass of xml files, which made it difficult to edit and update content. We used a document reader to conduct searches, but it was very slow. Sharing application elements Often the companies I worked for had very short development cycles, and UI changes were made near the end (since from a code perspective, the change held little risk). This often meant that icons and UI elements changed just before shipping, and we had a mad rush to update all of the screenshots. We solved this by sharing graphics, and other elements, with the application. If the developer changed an icon, it would automatically be updated in the documentation. If a UI element was moved, the embedded help moved with it. If a field label changed, it would automatically be updated in the documentation. Some writers aren't very technical Part of the success of these help systems depended on the technical ability of the writer. In some organizations I worked in, technical writers weren't very technical - even hand-coding an HTML page was a challenge. Changing requirements, and the multiple tools required to make these systems work, was completely overwhelming for many. Schema, DTD, XML, XSL - finding someone with a comfort level with all of these, and who is comfortable working with the myriad of tools to make them all work together, is a huge challenge; especially for smaller organizations with 1 or 2 writers. We were never able to co-ordinate all of the tools and formats we used into a user-friendly format. Take me there Often, when a user finds help on how to accomplish a task, they then need to figure out how to get to the right location in the app. We wanted to provide a link that would do this, but we never could get this to work - too many possibilities in our app, and too many technical issues - but it would have been really cool! Am I just dreaming? Barbara Irwin Eclipsys Corporation Email: barbara.irwin@eclipsys.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]