TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
--- Goober Writer <gooberwriter -at- yahoo -dot- com> wrote:
>
> So, a thin client app and a fat client app can both
> perform the same function, but engage the user and
> even use an environment or medium in different ways.
>
Yes, yes and yes. Yet you miss the point. In the
original post it was suggested that a User Manual be
written to document functionality.
Hmmmm. From the perspective of User Centered design,
usability is formulated by abstracting functionality
into a application that will meet the needs of a User
Profile. Take your text/Braille example. The content
does not change, only the interface and the delivery
method. With an application, the functionality may not
change, but FAT and WEB APP interfaces are different.
Now see the app as layers. The presentational layer is
what the user interacts with. The application reacts
according to programmed behavior, not functionality.
WEB APPS are not vertical like FAT APPS. That is they
are very hard to document top down. Never
underestimate the power of the hyper link. Screens
(WEB PAGES) can jump and drill in any direction. FAT
APP dialogs are generally limited to a few dialogs
deep, then you close them and start again in another
direction.
User Manuals explain the behavior of an application is
completing tasks. Tasks may have any number of
functions within them. The user does not know this.
They know that to complete a task they must proceed
and the the application will behave as such.
Hence using a User Manual as the basis for development
is a sure fire way to waste time and money. Much
information required by the developer is not shown in
a User Manual. Rather create the warts and all "As
Built" document, if you have the time and the budget.
Which somebody said they did not have. Alternately use
UML, like I think Mike suggested.
But if the FAT APP is dead in 18 months, I would not
bother with writing a User Manual for Engineers and
Developers. Again, I am not saying that another
document/tool is not required. Certainly your will
have to study the functions of the FAT APP so that you
can recognize them under the WEB APP. But don't close
your mind about how the function will be implemented
at the behavioral level.
Sean Wheller
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search http://shopping.yahoo.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.
