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 graphical 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 function 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 keyboard, 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 convention 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 conventions,” 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 products 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 requirements all at once. “We recommend that developers do two four hour sessions with users to collect requirements. That’s enough information to start designing,” Comaford says.

Page 6