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

[Scott Prentice <sp@leximation.com>]

I guess my intent in bringing this up is that it seems to me that in 
order to develop a realistic UA data model, it might be good to know the 
capabilities of the mechanism that presents that content. I suppose 
that's not a real requirement, but from my perspective the two are very 
inter-related. Let me throw out a question .. if we do develop an 
XML-based UA data model (UAML?), are you (we?) thinking that this format 
would be an intermediate data model (which is then transformed into 
XHTML) or the format of the actual content that is delivered to the end 
user?

If this is an intermediate format, then I could see the conversion tools 
providing this as a target output format, and our job would be to 
develop transformations from this UAML format into HTML that can be 
digested by the existing Help delivery mechanisms. Or, if this format is 
delivered to end users as XML, it would seem that it could only be 
presented by XML-enabled browsers (but this would have considerable 
limitations given the current state of browsers today). Or .. we 
(someone) could develop a browser (UA app) that could digest UAML and 
present it appropriately. Is there another scenario for the use of a 
UAML data model? I think that before we can really discuss what would be 
nice to implement in UAML, we need to decide how this would be put into 
use.

No .. I don't have any developers to devote to the development of a UA 
browser at this point, but perhaps once a solid spec is developed, we 
may find support from companies that would benefit from the development 
of such an application.

...scott


Paul Prescod wrote:
> It sounds like you've thought about this in quite some detail. Can you
> outline the next steps? Coming up with the specs would be hard, but
> implementing would be much harder. Who would do that? Do you have
> programmers on board?
>
> Whatever the answer, I'm skeptical that OASIS is a good home for a
> software definition project. OASIS should define the standards behind
> the software. And the standards should be implementable by multiple
> software products otherwise they aren't truly standards. If there is
> strong interest in the project you describe then we should probably move
> it to SourceForge.
>
>   
>> -----Original Message-----
>> From: Scott Prentice [mailto:sp@leximation.com] 
>> Sent: Saturday, May 06, 2006 3:35 PM
>> To: user-assistance-discuss@lists.oasis-open.org
>> Subject: [user-assistance-discuss] The "Ideal" User 
>> Assistance Application?
>>
>> Hi...
>>
>> I've had a number of conversations with various people on 
>> this subject .. initially I was very excited about the idea 
>> of developing an XML-based UA delivery app that would provide 
>> all of the features lacking in the other available apps. This 
>> using some common schema and internal XSLT parsing that would 
>> generate the topics and navigation (TOC, index,
>> ??) on the fly. Although I still think this would be an 
>> interesting project, I think it may have some shortcomings 
>> when used for medium to large projects (namely performance). 
>> 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. This eliminates the 
>> need to choose one data model as the "UA Standard" and moves 
>> back to the concept of generating the (XHTML?) files from 
>> your source using XSLT or some conversion process.
>>
>> 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. Some of 
>> the features I'd like to see are ..
>>
>> - This UA app should be natively compiled (C++?), requiring 
>> no external components
>> - Supports both compiled and uncompiled content delivery from 
>> local and/or remote locations
>> - Familiar content navigation elements such as TOC, Index, 
>> Search, and Bookmarks
>> - Content filtering based on user type (or other metadata)
>> - Provision for context-sensitive topic access
>> - Popups and other developer-defined window types
>> - Built-in update mechanism for both compiled and uncompiled 
>> content options
>> - Support for all (many?) languages
>> - more I'm sure ...
>>
>> In my mind, it is very important that this UA app be as 
>> self-contained as possible. Otherwise, it is very difficult 
>> for content developers to be able to rely on their content 
>> being rendered properly (or at all). 
>> This is a problem for current UA apps that are Java-based, as 
>> well as those that rely on the user's default or installed browser.
>>
>> It seems that with Microsoft's recent announcements at the 
>> WritersUA conference .. (1) "Vista Help" will not be 
>> available to content developers; (2) WinHelp will not be 
>> supported in Vista; (3) They are looking for community 
>> feedback as to what we want for UA delivery .. 
>> this is an idea time for these discussions to be coming about.
>>
>> Not to take this too far, but I could see leveraging mozilla 
>> for the content rendering, and clucene as the search engine. 
>> This could probably become a mozilla.org project, since 
>> really, this is just a very custom web browser. Mozilla 
>> provides the environment for plugin development, and already 
>> has some nice update capabilities.
>>
>> What do you think?
>>
>> ...scott
>>
>> Scott Prentice
>> Leximation, Inc.
>> www.leximation.com
>> +1.415.485.1892
>>
>>     
>