Re: [user-assistance-discuss] The "Ideal" User Assistance Application?

[marbux <marbux@gmail.com>]

On 5/6/06, Scott Prentice <sp@leximation.com> wrote:
x---snip---x


> There is something to be said about
> the current paradigm (used by most UA apps) of defining the topics, and
> navigation elements as static files that reference each other as needed,
> then wrapping that up in a nice package.


x---snip---x

Along these lines, a goal that I can see for this group is to come up
> with the specs for a new platform independent, open source, user
> assistance application. This UA app would provide all of the features
> that content developers expect and rely upon as found in the current
> Help delivery options, but implements the features properly and
> completely.


x---snip---x

<rant>

Another something that could be said about the current paradigm is that it
serves the interests of those who benefit financially from developing  Help
systems far better than it does the needs of software end users. I disagree
that compiled, static pages are the way forward. Help systems can not, in my
opinion, mature appreciably until they become much more accessible for end
users to contribute their lessons learned.

There is a clear trend emerging, fuled to a great extent from the open
source development community, to create online Help systems based on wiki or
content management system software, enabling end users to far easily
contribute content. Compare that trend, for example, with the limited
participation in the Linux Documentation Project, which insists on HowTo
authors learning the vagaries of DocBook.

I strongly favor that trend and would very much like to see it extended
farther. I have spent far too many hundreds of hours answering the same
technical support questions over and over again. It is common wisdom now
that end user online communities generally do a far better job these days
than Help systems in meeting most end users' technical support needs, and
far less expensively than professional support staff.

Web app WYSIWYG editors are increasingly being married with wikis and CMS
apps, reducing the need for end users to learn markup to edit web documents.
E.g., Bitflux Editor and Kupu, both of which validate content against
RelaxNG.

At the same time that , there have been some creative advances in wiki
synchronization characterized by GetWiki, which powers Wikiinfo.

". . . users of both Wikipedia and
Wikinfo<http://www.getwiki.net/wiki.php?title=Wikinfo>(Internet-Encyclopedia)
can easily see the visual user
interface <http://www.getwiki.net/wiki.php?title=User_interface>differences.
Also, Wikinfo may be the first large Wiki site to use the
XML <http://www.getwiki.net/wiki.php?title=XML>export Mediawiki 1.1.0, and
now GetWiki 1.0, now offers. This feature allows a Wiki site to have instant
access to the latest version of a Wikipedia article, and in this case, use
that GNU FDL content to build differing viewpoints and alternate connections
of thought."

<http://www.getwiki.net/getreal.htm>.

So there is no great technological barrier to automagic synchronization of
Internet-based Help systems with local versions for offline use. There is a
similar lack of barriers to maintaining a Help system on an intranet server
and synchronizing it as needed with laptops. Help systems are not by
necessity bound to client systems.

Help desk personnel could annotate feature *and* office-specific web pages
rather than building FAQs with no corresponding link to the application.
Help systems could be editable to add hyperlinks to particularly helpful
sites on the web that are specific to the problem encountered, e.g.,
feature-specific web support forums.

Perhaps we might even someday see application error messages that include
hyperlinks to context-sensitive Help web pages corresponding to the
individual error messages. Because of the easy editing, an intranet
administrator could decide to automatically refer certain context-sensitive
Help calls to various off-site contractors web sites. E.g., a
context-sensitive call from a particular feature might link to content
initially generated on a developer's public web site, while a
context-sensitive call from an error message could be redirected to a Help
system maintained by experts in troubleshooting, who could update the
relevant Help pages as they become aware of and resolve issues.

Web apps have also matured to the point where some CMS now enable automagic
caching of externally linked web pages for use if a web site is offline when
needed.  Likewise, with the workflow engines now available in many CMS,
prepublication moderation of content submitted by end users is easy.

End users with particular expertise, e.g., in a company's document
formatting requirements, can have their knowledge brought into the Help
system far more easily.

A breakthrough Help system would be dynamic and web based rather than
updated only when software revisions are issued. It would feature easily
configurable automatic synchronization of content between -- and across --
all levels, so Joe User can share his custom Help page with anyone he wishes
and have the benefit of Help pages generated by others.

And most of all, it would be easy to use and to contribute to. Help systems
should not be so difficult to use that they are the near-exclusive realm of
professional Help authors. It's time for Help systems to make an
evolutionary jump.

Obviously, I am somewhat less than convinced that the existing Help paradigm
is worth salvaging.

</rant>