The LA Fox Developer Newsletter

September 1995

10 Tips for Terrific GUIs

(Reprinted from Computer Week)

‘It was horrible,” says Mark Hanna, a former COBOL

programmer called into rescue an overly colorful graphi-

cal user interface (GUI) requisition system for the

Oklahoma state parks. “The colors slapped you in the

face. Red was used fora message box on one window

and as a background for the next. There was no

continuity between screens.”

To avoid such GUI nightmares, COBOL programmers

making the client/server leap must learn not only the

GUI environment and tools but also good GUI design

principles. Hanna, president of Hanna and Associates,

Inc., a consultancy in Edmond, OkIa., has seen it all,

from screens that looked like 3270 screens with func-

tion keys instead of clickable button objects to screens

so busy that no “white space” was left.

What does Hanna recommend to overcome all the bad

GUI designs he’s seen? “Put your hands in your

pockets,” Hanna says. “Don’t code. Do design work.

The only way to make a good GUI is to do the design

work up front. Start with the users and end with the

coding.

The following tips can help you become a better GUI

developer and give you an edge over other procedural

programmers making the transition

Create windows. You don’t have to cram all the fields

onto one window as you would with a 3270 screen. Put

pick lists, messages and field-dependent information

on subwindows. “It’s a big leap for character-oriented

programmers to pull information off one window and

put in another, but when the information isn’t used

much, itworks well,” says Jo-Ann DriscolI, an education

specialist at Powersoft Corp. in Concord, Mass.

Make screens clean. “Keep shapes and objects to a

minimum and the number of colors low,” says Steve

Douty, general manager at ETI International, Inc. in

Sunnyvale, Calif. Screen objects should be balanced

with white space.

Be consistent. Use the same font and size for related

buttons. Keep the actions the same. UIf standards are

not followed within an application, it will be very difficult

for users to become accustomed to the program,”

Douty says.

tina out wnat users will use. You're designing a

screen to help someone get a job done, not to try out

all the objects. “I’ve developed some really clever

screens with nice displays and then had the users say

they don’t need all the extra stuff,” says Fred Schuff, a

formerCOBOL programmer nowworking as a contract

GUI programmer.

Start with a white board. Instead of spending time

prototyping in the GUI environment, hand-draw two or

three versions of the most important screens. It’s

quicker than coding, and you won’t get attached to

designs that aren’t optimal. “Users really enjoy using

white board screens to circle things they like or don’t

like,” says Christine Comaford, president of Corporate

Computing, Inc. and developer of a GUI design dass

in Bannockbum, Ill.

Be considerate. Limit the number of fonts and font

sizes to three or four per window. Avoid the use of

italics and serif fonts because they tend to break up on

the screen. Use color sparingly “We recommend

neutral colors forthe background,” Driscoll says. “Avoid

the combinations of red on green or blue on yellow

because your eyes will go crazy”

Keep the keyboard involved. Allow for keyboard

control of the screen as well as mouse control. “Too

often the mouse is used to the exclusion of the key-

board, andthen you’re stuckifyou sitdown ata PCwith

a broken mouse,” says Edwin DiGiambattista, project

manager at Chubb Advanced Training, a division of

the Chubb Institute in Parsippany N.J.

Pick a naming standard. Design a naming conven-

tion for your objects, variables and routines and stick

with it. GUI systems tend to have numerous modules

and objects, rather than just one large program, that

must be modified for a name change. “I’ve become

much more rigorous in enforcing my naming conven-

tions,” Schuff says. “For every half hour you can save

by cutting corners, it will cost you an hour later on.”

Don’t be an inventor. Examine commercial GUI prod-

ucts and use them. “You can learn a lot by interviewing

the users on what they like or don’t like about the

Windows applications,” Douty says.

Keep it short. You don’t have to gather user require-

ments all at once. “We recommend that developers do

two four hour sessions with users to collect require-

ments. That’s enough information to start designing,”

Comaford says.

Page 6