Re: GUI issues

[William Swallow <WSWALLOW -at- COMMSOFT -dot- NET>]

Of course you have to make the right type of noise to be heard. We all have
a finite wavelength we can receive; the rest is either ignored or bounced
back (usually in a tighter wave).

Bill Swallow
Technical Writer
Billing Concepts
Albany NY
(518) 433-7698
mailto:william -dot- swallow -at- billingconcepts -dot- com
http://www.billingconcepts.com

> -----Original Message-----
> From: Donald Le Vie [SMTP:dlevie -at- VLINE -dot- NET]
> Sent: Wednesday, July 07, 1999 11:38 AM
> Subject:      Re: GUI issues
>
> 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=
> > =
> >


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=