dita-help message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: topic (as requested): what's different about OLH?
- From: "Bruce Nevin (bnevin)" <bnevin@cisco.com>
- To: <dita-help@lists.oasis-open.org>
- Date: Mon, 29 Mar 2010 17:28:24 -0500
First, a question about SC process. Any issue
identified by a SC goes to the TC, and its resolution is by one or more of
-
DITA 1.3
- OTK
- Tools vendors
So it seems to me the
SC focus is on problem definition, with some recommendations how it might be
resolved, but without implementation detail. Is that the consensus about
process?
I raised the question
"What's different about OLH?" This has two aspects, input and output so to
speak:
- Presentation and manipulation in the authoring environment.
-
Rendering of DITA topics as OLH (OT & other XSL/FO).
In both cases, how do
we create the nonlinear or multilinear organization of topics in OLH (and in Web
content)? That's the more specific question that I
raised.
______________________________________
The following may be
more discursive than you want. Just stick with the above if that's
appropriate.
The discussion that I
mentioned was with a colleague who champions a system for single sourcing OLH
from FrameMaker book files. It turned out that his preference is to RTFM and learn the product,
after which he says a Help system has nothing useful to say to him. (He
complained that the OLH focused on doing small modular tasks and assumed he knew
what the application was for. Apparently he never found the overview topic. Or
maybe there wasn't one.) Give those users a PDF book, I say.
But teaching is only one function of
documentation. Other users want just the bit of information they need, and then
they want you to get out of their face so they can get on with it. Think of a user with some knowledge and skill
doing something unfamiliar, or needing to refresh memory about something seldom
done. And even with instruction, there are different cognitive styles and
different learning styles. One metaphor that has been used is of search parties,
one combing the woods with a long line systematically beating the brush, the
other in helicopters, scanning for likely places then zooming in to look close
up. I don't have the same learning style as my
friend studying the manual so that a new tool can't surprise him.
Much is made of
minimalism. But terse is better until and unless more is better. Progressive
disclosure accommodates different levels of knowledge, skill, and (let's be frank)
intelligence. The converse is also true. More is better unless and until
less is better, or terse is better. As with instruction and learning, one size
definitely does not fit all. Writers have
to put themselves in the
readers' shoes--all of those several
rather different pairs of shoes. Progressive disclosure is easier on line, where the
information can expand to a virtual 100 pages if that user needs that much on
that occasion, but other users don't have to wade through 100 pages to find just
the bit that is needed. And progressive disclosure is only part of the solution,
because the problem is not just start terse and add more if they ask for it,
it's a problem of showing only what's relevant at that point. That's where
embedded help tries to go.
Another valid
criterion for good OLH is to maintain the reader's context. Rollover, expanding
text, secondary windows (if necessary), and other methods keep the reader rooted
to their starting point if they start drilling down through links. That said,
users generally have developed relevant skills in navigating the web, so they're
less likely to get confused and lost in link-land these days.
UI design works hard
to be 'intuitive' and make documentation unnecessary. The failure points of this
effort are somewhat unpredictable by user and by occasion. It's at those points
that quick access to relevant information is needed--for those users for whom
the UI fails to make it obvious what to do.
I don't know if it's
cognitive style, or bad prior experiences, or what, maybe a self-image thing
about 'admitting' that you need help. Or like my colleague who I described at
the outset, the guy who studies the manual to master the product first and says
that Help has nothing useful to tell him. Fred, the engineer I worked with on a
network management product, was at a customer site. The user was stuck. Fred
suggested he try the Help. Bang, there was a short topic with the answer to his
question, right in front of him. "Ah, I can never find what I want in these
things!" said he, and closed the window. If users don't click the Help link or
the F1 key, the information stays in the Help ghetto. Hence, the need to
distribute the information throughout the UI so that it's just part of how the
UI works, rather than separate 'documentation'.
Quick access to relevant information is the grail. So
criteria for OLH might include:
- Rapid access (t <
30s)
- to 'relevant'
content, where `relevant' means
- My questions are
answered.
- I better
understand how to use the product.
- with the proviso
that if my question is based on
misconceptions, the content responding to them should lead me to reframe
the question in a more appropriate way and look
again.
How can the TC, the OT, and tools vendors collaborate
to get all that from DITA?
/Bruce
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]