[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-help] Layering in Help Systems
Thanks for your thoughts, Matthew. You raised a particularly interesting point about auto-linking of glossary terms, and the argument for only implementing an expansion link for the *first* occurrence of a specific term. I don't think that would present too much of a problem in a processing routine, because XSL-T (or probably more correctly XPath) has a facility for picking out the first instance of an element. Tony -----Original Message----- From: Matthew Ellison [mailto:matthew@ellisonconsulting.com] Sent: Tuesday, 6 January 2009 9:31 PM To: dita-help@lists.oasis-open.org Subject: RE: [dita-help] Layering in Help Systems 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]