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.
Subject:Re: Naming conventions From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Wed, 7 Aug 1996 11:06:06 -0700
At 10:37 AM 8/6/96 -0500, Meredith Townley wrote:
>There has been a small debate in the office over how "screens" should be referenced in the documentation. I'm curious as to what others call what I refer to as screens. The debate includes calling them screens, dialogs, and windows. What is the norm or proper term and are the three terms above the same?
Meredith,
You didn't specify the platform for your gui application, and that makes
a difference. In general, it's best to stick with the terminology that the
OS/GUI platform uses.
Screen is pretty much out of use now. It was widely used in DOS-based
applications when the application took up the entire screen. However,
if your gui opens various windows in different locations on the screen,
you'd do well to use 'screen' location as a way to locate the window.
A Window is a major program interface element. Typically, windows stay
open until you specifically close them. In Windows, only the program's
main window can have a menu bar. Secondary, or child, windows are those
things that appear within the main window, can be resized, mimimized,
and closed. Secondary windows can have toolbars, but cannot have menus --
in Windows. Other GUIs do this differently (so, in OS/2, for example, you
can have a menu in a secondary window. You see secondary windows in MDI
(multiple document interface) applications, like the Windows file manager.
In some applications, windows are divided into several panes. Panes can
usually be resized, but cannot be closed independently. They're stuck in
the window.
Dialog boxes, or dialogs, create a dialog between the program and the
user. They are generally not resizeable or minimizable and close
automatically when the user clicks OK (or some other button). Whether
you call these dialogs or dialog boxes depends on your audience. More
technical users will prefer 'dialog' as it's less wordy, but novice
and occasional users will be more comfortable with 'dialog box'.
Those dialog boxes that do not allow you to do anything else in the
program until they are attended to are called 'modal'. It is not
necessary (or, probably, even advisable) to introduce this term to
a non-technical audience, but be prepared to describe the behavior
of a modal dialog.
You may be tempted to aviod the 'technical' terms, especially if your
audience is novice or non-technical. However, introducing non-standard
terminology isn't a good idea (and lots of usability professionals on
the utest list will back me up on this) because users build on standard
terminology to gain an understanding of the environment and the programs
that run on it.
Sue Gallagher
sgallagher -at- expersoft -dot- com
-- The _Guide_ is definitive.
Reality is frequently inaccurate.
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-
