TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Is your software a Windows application or a web-based application? Ours is
web-based.
<dmbrown -at- brown-inc -dot- com> wrote in message news:269227 -at- techwr-l -dot- -dot- -dot-
>
> > Has anyone used embedded help in their software UIs? What were your
> > experiences with developing and implementing it? Have you gotten
positive
> > feedback from users on this feature?
>
> With the help of a "true believer" developer, I finally got help embedded
> in the application pages about 16 months ago.
>
> I was able to move a lot of verbiage (critical stuff you really *needed*
to
> know) out of the "app" portion of the page and into the help portion, a
> narrow panel down the right side of the window.
>
> On a few pages, help might obscure the ends of long filenames, for
example,
> and we knew expert users didn't need help; so we made it easy to hide the
> help, giving the app full use of the entire window, and to display it
> again. Your preference (showing or hidden) was retained across sessions.
>
> It was great. I could use the same dynamic content mechanism in the help
> files as we used in the app code to guarantee the help documented
precisely
> what was displayed in the app page.
>
> People got the info they needed, expert users didn't have to wade through
> wordy text to get to the controls, and the help didn't need a lot of extra
> verbiage to provide context. Heck, lots of people didn't even realize it
> was help.
>
> Of course, that meant that only a few people said "yes" when asked whether
> they used the help. As a result, the help has been moved back into a
> secondary window in the upcoming release.
>
> Marketing says they want to use the entire window for app controls, but
> there's not enough time in the schedule to actually redesign 90% of the
> existing pages, so only 15 or 20 new pages and a dozen or so reworked
pages
> will actually use the full width of the window.
>
> The cost for those few pages? In that same limited schedule, in addition
> to documenting new and changed features, I have to rewrite scores of help
> files to accommodate all possible cases: "If your account has the
> so-and-so feature, use the Womble button to frub the jamowitz." "Talk to
> your account manager for information about adding the Womble feature to
> your account." "Some of the following features are optional and may not
be
> available to you."
>
> <sigh>
>
> >
> > We're debating this possibility and wanted to know other companies'
> > experiences before deciding to proceed. We're a two-person team, so
we're
> > not sure whether this would be out of reach, considering that we would
still
> > need to create traditional online help and manuals.
>
> We did include PDF manuals, but did not have a separate help system in
> addition to the embedded help.
>
> I'll use embedded help again, wherever given the opportunity.
>
> --David
>
>
>
>
>
>
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
