OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

user-assistance-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hello, everyone.

I'm here as an independent. However, I am a Microsoft Help MVP*, and I have
had some connection to other HATT/Single-Source tool vendors. I currently
consult on single-source and XML publishing and CMS processes, as well as
content internationalization.

Great start, Scott. I would second marbux's call for some means by which
users can annotate topics or include online information. Maybe some way to
include RSS feeds or some other mechanism for subscriptions in an area
distinct from the primary help content? I'd want businesses to be able to
delimit their information if only to offer protection against liability.

I'd like to elaborate on a number Scott's requests:

- Popups and other developer-defined window types

BB: I'd expand this to include other dynamic behaviors--inline expansions,
embedded objects, one-to-many topic linking, and behaviors that we can't
imagine right now. 

- Support for all (many?) languages

BB: A big yes on this. One of the biggest problems I have with large clients
is finding help solutions that support their full language set. The solution
needs to support UTF-8 in all functionality (search, index sorting, glossary
sorting, UI). With only a few exceptions I can think of (WebWorks Help, and
er... okay, one exception), most tool vendors have really done a poor job of
meeting this need. I'd be happy to work on specs for a configuration file
that would include this such as locale-specific stop-word lists and UI text.

Regarding Paul's post on graphical callouts: I think enough is being done
for scalable vector graphics in the XML space that such work for the
specific purpose of user assistance would be redundant. We should focus on
supporting whatever graphic standards are available. I also think that, for
internationalization purposes, it might be counterproductive to encourage
text callouts and instead work to standardize means for encouraging
multipurposing. For example, say we capture a path to a graphic (SVG or some
other XML-based standard) and callout in an container element with an
associated legend. Callout numbers could be used to associate regions of an
image with the text of the legend. Depending on the needs of an
application/help developer, the figure could be displayed as either a
graphic with a tabular legend or a graphic with hotspots and popups--maybe
even blow outs of the images. Lots of things we could do here. What we
should focus on is not the functionality but the markup required to enable
the functionality.


Bill Burns
Burns Technical Communications
Microsoft Help MVP
wdburns@cableone.net 

*not an employee but an external help resource who mediates among the help
development community, tool vendors, and Microsoft




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]