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: GUI issues From:Donald Le Vie <dlevie -at- VLINE -dot- NET> Date:Wed, 7 Jul 1999 10:37:59 -0500
Sean:
I've used "Secrets of Effective GUI Design" by Mark Minasi and Cooper's book
(quoted below) as references in the past when I was involved with GUI
projects. Keep making noise...
Donn Le Vie
Integrated Concepts
P.S. You may want to make this your mantra: "[Programmers] cannot
successfully be asked to design for users because...inevitably, they will
make judgments based on the difficulty of coding and not on the user's real
needs."
Alan Cooper, "About Face: The Essentials of User Interface Design"
> -----Original Message-----
> From: Brierley, Sean [SMTP:Brierley -at- QUODATA -dot- COM]
> Sent: Wednesday, July 07, 1999 10:36 AM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: GUI issues
>
> Hallo:
>
> Are any of you software tech writers involved in assisting with the GUI of
> your software (beyond finding typos)?
>
> My previous experience was that programmers jealously guarded this arena
> and
> wanted no input. However . . .
>
> . . . I am finding quite a few issues at my current company and have made
> noise (I do that). I'm not really getting anywhere other than a polite
> "yes,
> take notes, we must have a meeting on that . . ." with one exception: I
> pitched a minor fit because there are no guidelines for making minor GUI
> changes, such as renaming buttons, tabs, etc., and adding and deleting
> buttons and the like from the GUI. Part of my point was that even though
> such changes did not affect the operation and stability of the software
> function, such changes should be made a big deal to prevent just anyone
> from
> casually making such changes. To help make my point, I noted the eight
> hours
> of capturing screens that I had to re-do because one button was changed
> and
> another added in (no function was added). I further suggested that the GUI
> should become unchangeable, or set in stone, at some defined and
> *announced*
> point prior to shipping--and I recommended that such a date be more than a
> week before shipping <vbg>. Since then, I have been asked my opinion on
> two
> last-minute changes to software I'm not yet documenting <vbg>. This seems
> to
> be symptomatic of small software companies that boast a "flat" management
> structure (rather than hierarchical). Thoughts and experiences in this
> area
> are welcome.
>
> Anyway, my point here is not to rant and rave but to ask: what do you
> think
> is a reasonable limit on the number of words and characters used to label
> a
> GUI feature, such as a button, tab, text field, etc? Can anyone offer a
> reference tome on this (I couldn't find any info in the Windows Interface
> Guidelines for Software Design, but might have missed it)? I'm thinking
> along the lines of three words and 25 characters at most. Thoughts?
>
> Grazie.
>
> Sean
> sean -at- quodata -dot- com
>
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000=
> =
>