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.
dmbrown -at- brown-inc -dot- com
> I was talking about designing a web app to *function* (again, from the
> user's point of view) just like an existing desktop app...
> ...buttons, fields, windows, and the like have the
> same names; list boxes offer the same selections; radio buttons and
> checkboxes offer the same alternatives; and so on.
This is exactly what you shouldn't do. Fat client design is different from
thin client design. A Windows app is made of windows, dialog boxes, and
menus, whereas a web app is made of pages, forms, and links. I have never
seen a web app successfully migrate their windows and dialogs one-for-one to
pages and forms. But I have seen lots of failed attempts to do so.
The other option is to fall back on the Windows API and run little Windows
programs inside IE. This is actually not a bad option for many corporate
applications. But it's not a web application, it's basically just Windows
components delivered over http and wrapped in some perfunctory html.
I remember when shops tried to migrate their mainframe apps to Windows, and
they designed a bunch of windows that looked like their old terminal
screens. They didn't realize they needed a new model. Same problem migrating
from Windows to Web.
The problem with IE apps (the problem for documentation anyway) is that you
can never specifically refer to a form or page, the way you can identify a
window or a dialog. A web app is supposed to have a URL for all web
resources.
But in an IE app, if all data is dynamically presented in a single html page
(or asp page), what is the address of that page? How do you refer to it in
documentation? Sure, I've found workarounds, none of them perfect. Sometimes
I fall back on a narrative or pictorial approach just to tell a user how to
navigate to a specific point in the application.
Mike O.
Purveyor of fine rubbish and horsefeathers since 1997
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.
