RoboHelp is a Help authoring tool (HAT) created by the eHelp Corporation and now owned by Adobe Systems. The software is used by technical writers to create computer help files (documentation) in various formats.
As a consultant I get called in after the wreck to figure out what went wrong. Across a wide range of industries and products, the same problems recur again and again. In this presentation, I’ll show you what these common problems are and simple ways to avoid them.
Here are 10 things that users want to do in a help system – or a library or a department store… Some of them are kind of obvious, but I think it helps to consider all of them and how they relate to functions and options in a help system. Which ones you want to offer depends on your users, your product and your tech writing resources.
Nothing brings content modeling to life like launching a shiny new site: teasers fit neatly without any awkward ellipses, images are cropped perfectly for different screen sizes, related content is wonderfully relevant. The content strategy comes to life, and all is right with the world. But for years, my joy was short lived—because it would only take a couple weeks for things to begin to fall apart: teasers would stop teasing, an image would get scaled oddly, and—I won’t lie—I’d even start seeing “click here” links. Don’t despair. There’s a better way to get your content guidelines adopted in the real world: put them right where they’re needed, in the CMS itself.
This panel discussion will explore a specific project conducted by the Mercer Engineering Research Center (MERC) in which existing MERC-designed United States Air Force print-based training was rapidly converted to web-based training. Specific issues discussed are differences in design strategies for print and web instruction, development and authoring approaches, rapid prototyping, usability testing, project management concerns, and lessons learned.
This article provides an overview of the latest trends in software user assistance based on surveys, interviews, and observations by the author and other experienced user assistance professionals. The article defines the key terminology, highlights the most important issues and elements, and offers both short and long-term predictions for the field. The article will appear in four installments. The next installment will be in February.
I believe that phone conversations for customer support have been studied quite a bit -- looking for phrases that sound like triggers for anger, avoiding long pauses, and when one party overtakes a phone conversation, it's relatively easy to detect when that's happening. But with Twitter, you could have long pauses intentionally as asynchronous, IM-like conversations happen when someone gets up from their desk and returns after a business meeting, for example. Neither party is angry about that long pause, it's just an understood agreement in the Twitter medium that you may or may not be immediately responsive. How does that time factor change the 'agreement' for a support exchange?
I spent the past week in California, interviewing with various companies. In preparation for each interview, I studied each company’s documentation as best I could. I noticed two main trends. Some companies group all their documentation together into one massive site. The sites usually have a robust table of contents and include help for most of the company’s products. In contrast, other companies segment out their help into smaller sites. For example, a company might have an HTML file that opens a tripane help for each of their 25 products.
The mindset in which most technical communicators write help is sometimes fundamentally flawed. Consider the following two stories and the different approaches and mindsets each writer takes toward the project.
Context-sensitive help is a practical way to cut down on customer support expenses and add more value to documentation. By providing more complex, context-sensitive help, the usability of the help increases while call center phone calls decrease.
No matter how well you design your User Interface, there will be times when your user would need assistance. User Assistance Model forms an integral part of Information Architecture for any application. The assistance includes print documentation, embedded help and online help.
What I really like about the Help system is the layering of information achieved with the DHTML expanding hotspots. I think these represent a big step forward in terms of usability from the previous version of the Help, and it's a technique that I expect to see many other Help authors emulate.
This article explores the role of user assistance in providing domain-centric online Help--rather than Help that simply explains obvious user interactions with well-designed user interfaces--and provides a pattern for and examples of expert guidance.
What we consider to be good technical writing often reflects an American cultural perspective. One facet of this cultural orientation is that technical writing tends to use a low-context style. Most notably, we tend to write user assistance as if users have never seen the user interface we are explaining. Secondly, we tend to write user assistance as if users have never even used software before. But users rarely go to Help before they have tried to accomplish a task on their own first, and most users today have extensive experience using software and are familiar with the standard ways of interacting with user interfaces. So a user interface is a high-context artifact—one a user has already seen before reading our documentation and that uses rules and conventions the user already knows.
Users turn to help to look for a specific question, just as someone consults an encyclopedia for a specific question. No one reads the entire encyclopedia/manual, nor is anyone expected to. Well-written encyclopedias allow users to find information through indexes, tables of contents, alphabetical organization, and search fields.
Many software products have multiple supported releases deployed on customer sites. Documentation teams are often required to maintain documentation for all supported releases.
Google’s operating system for mobile phones, Android, includes barcode scanning capabilities. There’s free, open source software available, which means it’s easy to create your own barcodes that link to your support text, contact information, images, videos or specific Web pages on your site. There’s also a free open source library available for creating your own barcode scanning application (this will be the case with the iPhone, too).
In the transition to online documentation, one of the communicator’s most effective tools can be a hardcopy document. Providing your users with a printed manual that introduces them to your product and your online documentation might be just the thing they need to get started using both. To create an effective hardcopy document, you must begin by gathering feedback, analyzing your audience, and setting your goals. You can then use that information to determine what to include, what to exclude, and what to call your hardcopy document.
Computerized Medical Systems needed to develop content-sensitive online help for a UNIX-based application. We found that this could be done using standard HTML, with each help topic in its own file and displayed in a web browser. With careful planning, we were able to create a map of the applications coded pages to our help files, giving us context sensitivity. We were able to add both keyword and full-text search capabilities. Site management is done using a source control system and a set of link check and HTML validators.
Master Pages, a new concept introduced in Adobe RoboHelp 8, intends to provide flexibility in controlling the layout of topics, where in an author may separate the actual content from the layout of the output and may do it from a single place. In Adobe RoboHelp 8, a user may use Master Page as a Layout and Styling canvas where one may put basic HTML elements to be used for Layout purposes.
Many technical communicators are tasked with converting user manuals and other documentation written in Adobe FrameMaker into online help using eHelp (formerly Blue Sky) RoboHelp. The problems they face concern not only going from FrameMaker to RoboHelp but also how to put the content in a form that is effective for online help. The solution is not difficult, provided the writer follows a methodical approach.
RoboHelp is a top application for developing online help. It is also used for developing Web-based help, such as JavaHelp and RoboHelp's WebHelp. Besides being used for online or Web-help, RoboHelp can also be used to develop simple tutorials.