Re: Step-by-step instructions for a variable GUI?

["Chuck Martin" <cm -at- writeforyou -dot- com>]

This involves rethinking what constitutes user assistance.

Horn1: The user assistance must be tied to the "presentation layer," not the
underlying executable files.

Horn2: Thought 1: They're actually reading the docs! Yay! Thought 2: Why
isn't the product designed so that users can infer how to use it from the
design itself?

Horn 3: See Horn 1.

Horn 4: See Horn 1.

When you're offering applications on a variety of devices, the applications
have to be designed to be as self-documenting as possible--as do the devices
themselves. Once you've polished a design, then you create embedded user
assistance to guide users through their tasks without having to leave the
application interface.

Then you design a 2nd layer of user assistance, one-off, for any differences
in existing GUIs.

Question: How can a "presentation layer" be designed so that it will run on
devices not yet invented? Answer: Only if those future devices adhere to
current presentation technologies. If that's the case, architect the content
to be device-neutral. If not, then your company will have to rework that
presentation layer, which gives you an opportunity to work in tandem and
provide reconfigured user assistance.

That's just a start; it's too early in the morning to go a whole lot deeper.

Chuck Martin


"Jim Shaeffer" <jims -at- spsi -dot- com> wrote in message news:214791 -at- techwr-l -dot-  -dot-  -dot- 

How do you document step-by-step instructions for an ever-changing GUI?

The horns of the dilemma:

Horn 1: We are moving our software products to a "3-tier architecture". Tier
1 is data, tier 2 is the executables, tier 3 is the presentation layer. The
strategy is that the independent presentation layer will allow our software
to run anywhere and everywhere (desktops, laptops, tablet PCs, hand helds,
PDAs, cell phones and devices that haven't been invented yet).

Horn 2: Our users need detailed, step-by-step instructions for every task
they can perform while using our software. They complain that we don't give
them enough step-by-step procedures, and they have amply demonstrated their
need for them over the years. Further, it is obvious that there is no such
thing as too much hand holding or too great a level of detail.

Horn 3: Our user documentation is in the form of context sensitive Help
files. Traditionally, Help files are tied to executables. Our plan, is that
the executables will remain constant while the GUI (presentation tier)
adapts itself to any and every delivery device.

Horn 4: The strategy of the independent presentation layer is part of our
plan to get our software to be installed and used by people who are even
less technical than our current user population.

I'm looking for both conceptual and technical advice. None of this stuff is
due yesterday, so this is a planning issue, not an emergency.

Thanks in advance,
Jim Shaeffer (jims -at- spsi -dot- com)






^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.