Re: [dita-help] Layering in Help Systems

[Scott Prentice <sp@leximation.com>]

Yes .. Happy New Year to you all!

I think that it would be nice to be able to handle all elements of a 
specific type with a specified treatment .. however, I think that we'd 
also need the ability to override that treatment for specific cases as 
well as being able to apply that treatment in an ad-hoc manner. I tend 
to think of these Help-specific treatments to ranges of content as 
"functional formatting" .. as opposed to just applying some visual 
properties, we need to be able to apply some sort of event-driven 
properties and formatting.

I'd like to think that this could be done with minimal (or no) 
additional structural elements. Perhaps this can be thought of as a 
special type of filtering, and we can add a "uacontrol" attribute to all 
elements that would allow ad-hoc application of this user assistance 
formatting as well as supporting the overriding of a global setting. 
Perhaps we could add a prolog section that allowed the user to define 
settings that could be applied to an entire topic (as well as child 
topics), and a similar topicmeta or bookmeta section that would apply 
settings to all topics within a map.

It seems like we need to come up with a list of all possible 
Help-specific formatting that we'd like to be able to manage, then see 
what type of mechanism would be needed to control that formatting.

The only situation that I can think of off hand that might require an 
additional element would be some way to group sibling elements. 
Although, I really don't like the idea of introducing a special 
"help-group" element whose only purpose is to apply some special 
Help-specific treatment to a range of elements. It seems like you'd be 
able to group these elements using an existing element. One of the core 
aspects of DITA is modularity and reuse, and if we do things to craft 
the content in a very Help-specific manner, we would be working against 
that premise.

Cheers!

...scott


Matthew Ellison wrote:
> Greetings Tony, and Happy 2009 to you too!
>
> Thanks for starting the new year with such an interesting question.  I
> believe that information layering is a very important technique in user
> assistance since our aim is to make the best possible use of the (usually
> quite restricted) screen real estate that we have available.  Also, hiding
> information and making it available only "on request" is a great way of
> keeping Help topics concise and more inviting, especially for novice users.
>
> I think it is possible to create a fairly rigid set of rules for when
> information layering should be applied.  In response to your example: I
> would say that, having established a convention for presenting footnotes,
> this convention should be applied consistently throughout.  The only
> argument I can think of against using a popup in a specific instance would
> be if the amount of information displayed was too large -- but then, in that
> case it probably wouldn't have been appropriate to mark it up as a footnote
> in the DITA source.
>
> Taking your other example of glossary terms, there is an argument for only
> implementing an expansion link for the *first* occurrence of a specific
> glossary term within any given topic.  All of the Help Authoring Tools that
> support glossary term linking provide this as an option.  They also
> typically enable "ad hoc" glossary term linking, but I don't see any good
> reason for this.
>
> Other examples of information types that might be implemented as layers are:
>
> -- Images: these take up valuable space within a user assistance window and
> are often omitted altogether -- however, it might be a good idea to make
> them "user selectable".  Arguably it is less possible or desirable to apply
> this as a rigid rule since there are likely to be specific images (perhaps
> icons and buttons) that are critical to the effectiveness of the user
> assistance and should not be layered
>
> -- Tips: If layered, then they should have a meaningful and explicit hotspot
> or trigger (not simply the word "Tip" since this provides no clue as to the
> nature or relevance of the information)
>
> -- Examples
>
> -- Task sub-steps
>
> -- Task main steps in cases where multiple tasks are chunked into a single
> topic -- this rule could be difficult to implement since it would not make
> sense to layer task steps in the more usual case of a task topic consisting
> of a single set of steps.
>
> Having said the above, my primary aim when applying information layers
> within user assistance is to ensure that the entire topic (beginning and
> end, but not necessarily all the detail in between) can be displayed to the
> user without scrolling being required.  If the topic consisted *only* of a
> short example, then it would not make sense (from a usability perspective)
> to layer it.  On the other hand, if a topic consisted of six headings, then
> it might make sense to layer the content of those six sections irrespective
> of the nature of the information.  This suggests that, purely from the
> perspective of usability, a Help-centric "layering" element might be useful.
> However, on balance I would not be in favour of this due to the lack of
> structure and predictability that this would introduce.
>
> Best regards,
>
> -Matthew
>
> -----Original Message-----
> From: Tony Self [mailto:tself@hyperwrite.com] 
> Sent: 06 January 2009 08:39
> To: dita-help@lists.oasis-open.org
> Subject: [dita-help] Layering in Help Systems
>
> Greetings Colleagues, and Happy 2009! 
>
> I'm interested in everybody's thoughts on whether layering features in Help
> systems can be applied globally based on semantic mark-up, or whether there
> is a need for "ad hoc" layering. By layering, I mean features such as
> popups, expansion links and dropdown links. By "ad hoc", I mean an author
> choosing that this lump of text would be best presented to the user in a
> dropdown, for example.
>
> As an example, let's say we render a footnote <fn> in the HTML output from a
> DITA collection as a popup. Can we apply a rule that says "in all cases (for
> this Help system), <fn> elements will be rendered as popups"? Or will there
> be an instance where we need to say "oh, THIS <fn> needs to be treated
> differently". If we further assume that a transformation process somehow
> links any <term> elements with a corresponding glossary entry into an
> expansion link to that glossary entry, can we safely way that this will
> happen in all instances within the help system?
>
> I'm trying to explore whether we actually need different semantic elements
> for "Help" features. It would be philosophical sound if we could avoid
> having help-centric DITA elements that ended up embedding presentation
> information in the content. Or having some type of DITA mark-up that only
> applied to Help systems.
>
> What do you all think?
>
> Regards
>
> Tony Self
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>