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

[Scott Prentice <sp@leximation.com>]

I completely agree .. all excellent points.

My speclet really only addressed a possible "application" which could be 
used as a connection point between a client-based application that 
requires documentation and the associated documentation. Exactly what 
(or where) that documentation is .. is completely up to the content 
developer. To address your request for web-based content, was why I want 
the content for the UA app to be either/both local and remote 
(web-based) and compiled or uncompiled. The UA app that I describe is 
purely a souped up web browser with some UA-specific hooks. Developing 
this UA app provides a consistent container for application developers 
to host their UA content .. wherever and whatever it happens to be. I'd 
imagine that we could build some plugins for this app that would make it 
easier for content developers to build online communities within their 
Help as well as other cool stuff.

If a web browser is all that's needed, then there's no reason for 
someone to use this (or any other) UA app.

Cheers!

...scott



marbux wrote:
>
>
> On 5/6/06, *Scott Prentice* <sp@leximation.com 
> <mailto: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>