Ken Howe's GUI Standards

Welcome to Ken Howe's Graphical User Interface Standards. This set of articles and tips deals with standards you should follow when designing user interfaces for your application. The articles are listed by date last modified and the OS column informs you if this standard is a general standard for all operating systems or if it is specific to a certain operating system. If you have a tip or article to share with other developers then please eMail me the details and I will add it to the site. Title OS Date(m/d/y) Title Bars and Icons All 5/27/2001 Keyboard Control All 12/4/99 Size is Everything All 8/1/99 Field Prompts All 7/11/99 Visual Cues All 4/10/99 Practical Use of Colour Win 3/7/99 About Ken Howe's GUI Standards N/A 3/7/99

Title Bars and Icons

Windows title bars have lots of uses for the users of our Applications in addition to the obvious ones of dragging and minimize etc they can be used to allow the user to easily identify which window out of a set of windows they require. As developers we can help the users by using a strict convention for the text in those title bars. The most obvious first choice is to include the name of the function the window performs, this easily allows the user to find the type of window they require. When the user has multiple windows of the same type open as is frequently the case in MDI applications, the window name is not enough to identify which window they want. Again we can help the users out by including one or two of the key fields from the data being displayed on the window in the title bar. When adding the data items to the window name there is a choice to be made, should the window name go first or last in the title. For example Word 97 used the convention of: Microsoft Word - C:\The\Name\Of\Your\Document.doc Which is great and has both pieces of information but the problem being that when the text is truncated as is frequently the case all you see is: Microsoft Word - C:\The\Name\Of\Y... Which is not very useful if you have 10 document all open at the same time. We can see that Microsoft agreed as in Word 2000 they swapped the sequence around so that the Document name appears before the Application Title. This works well in the case of Word but frequently in database applications the text of the key

data items can get long and when concatenated with the window title can become unwieldy for the user. Therefore the ultimate solution is to use a combination of the title bar and the window icon. If possible choice a different icon for each type of window in your application. The users can then associate the icon with the function and you can remove the function of the window from the title bar. Leaving just the identifying data as the title bar.

Keyboard Control
You may think this is an obvious topic that does not need a mention, but you would be surprised at how many applications (including commercial) I have used that the keyboard functions of the user interface do not work at all or do not work well. Follow these standards to make sure your user interface is keyboard friendly. Tab Order You would be amazed at the number of applications where the tab order of the controls on the user interface does not follow a consistent flow around the window. Imagine using the file open dialog in windows but instead of the nice flow you expect the focus shifts from the file name to the list of drives to the open button to the list of files etc. This would be very frustrating and annoying for your users. Make sure the tab order of your form flows around the controls in the order that the user expects, if this sequence is not obvious ( it normally is ) then ask the user! Another aspect to consider is the focus starting point, a lot of the time the top left hand corner is the best starting point but in the file save dialog the filename is the start location which is probably where you want it to be. Again ask your users. One last thing is to make sure you do not have a tab order on things that do not make sense, for example you may have used a group box to logically group a few edit fields together for the user, but this group box does not need to be part of the tab sequence. Accelerators This is the feature of windows that allows users to use the ALT key and a letter to jump to a field or menu. The user knows which key to use because one of the letters on the field or menu is underlined. The most important thing is to make sure you add these to your interface, it is very annoying to keyboard users to have to tab through 20 fields or scroll through 10 menu items using the cursor keys just because you where too lazy to add accelerators to the fields and menu items. When you are adding accelerators you should start with the menu, if you are using words on the menu that are also in other applications then check to see what accelerators are used in those applications and where possible make yours the same. It would be very annoying if your application used i for the accelerator on the File menu when all the other applications in the world use F. Next you should add accelerators to each item on the sub menus. Make sure there are no

duplicates and start with the most commonly used menu items first. These most common items should have the first letter on the first word as the accelerator. Then move on to your windows. The golden rule is that you cannot use any accelerators that have been used by the menu. Then follow the same rules as the the menu items, start with the most important fields, if you do not know what these are then ask the user. Use the first letter of the the first word of the most frequently used items and then work your way backwards. For complex or large windows I normally have a piece of paper with the alphabet written on and tick them off as I go. Consistency is also key, if you have a Search button on 10 windows in your application but 5 accelerators use S, 3 use E and the rest use H then the user does not gain as much benefit as if they where all same letter. One last not is that any default or cancel buttons do not need accelerators, the user will 99.9% of the time use the Enter button and the Escape button so you can use those valuable two letters else where in your windows. Views and Panels These are new additions to the GUI interface arsenal and are a method for splitting a window into multiple resizable sections each dealing with a slightly different aspect to the application. These can be a great productivity aid for the user BUT make sure there is a keyboard equivalent to the mouse for changing the focus between the views.

Size is Everything
Although the contents of this article may seem obvious to some people, you would be surprised at the number of Windows that I see which although functionally correct look a complete disaster just because the developer did not take the time to get the sizes correct. Buttons The first thing is buttons, try to keep the width of a button to a minimum, the prompt should be meaningful but where possible keep it less than 20 characters, use tool tips to add extra narrative if required. The golden rule of buttons is to make sure the width and height of ALL buttons on the same window are the same. All buttons in your application MUST be the same height, and if possible make them all the same width. All controls should be lined up and buttons are no exception, most development tools provide a facility to do this automatically so use the tool, don't use your own judgement. If you have a dialog with buttons on the bottom then right align them with the edge of the rightmost button aligned with the right most edge of the right most control on the window. Data Lists The height of a header in a list of data that has a scrollbar should match exactly the height of an arrow header of the scroll bar, even one pixel either way looks very ugly. Try to make any data

in the row have a pixel above and below for clearance, this will aid readability for the user. Make sure the right number of rows fits perfectly for the data list height, increase the size of the list a single pixel at a time and run the window, when a new row appears the size of the list is correct. Make sure the data fits the width of the control, only use horizontal scrolling when you REALLY HAVE TO. Fields Make sure all of the fields on the window have the same height, unless the field allows a large description and wraps at the edge of the control. Where possible make a vertical lists of fields all the same width, if two or more fields are much shorter than the rest, double them up on a single line and right align then edge of the field to match the longer fields. Make all the single line field prompts horizontally centered with the control, all other prompts should be aligned the same number of pixels from the top edge as the horizontally aligned prompts. Dropdown Lists Make sure all dropdown lists have the same number of items available for selection and that the number of rows shown fit exactly, no little blank spaces where half a row could fit. Eight is a good number as it does not obscure too much of the display but allows the user a good view of the data. In PowerBuilder this can be achieved by setting the number of rows attribute in the properties of the edit control. You should not use horizontal scrolling in a dropdown list. You can however make the width of the dropdown wider then the width of the dropdown control, this is especially useful when you want to show extra fields in the dropdown that are not displayed in the edit field. In PowerBuilder use the width property to increase this. Summary Follow these simple rules and your interface will look slick and give your application a professional look.

Field Prompts
In a previous article on the use of colour in applications, I recommended not using colour for special meanings in your application, for example red backgrounds for mandatory columns. If you followed those guidelines your application will look more professional but you will have lost the indication to the user of which columns are mandatory. As an alternative way of gently prompting users of a columns nature we can use the field prompts with a subtle change. The basic rule is that all prompts for field should not have an ending character. For example a lot of people always end prompts with a colon : . By removing

this colon from the ends of prompts we can then use this character and other characters to infer a meaning to the user. In a data entry window you can leave all non mandatory columns with no prompt and add a colon to all fields that are mandatory. This is a very effective way of prompting the user as to which fields are mandatory, that not only looks professional but does not stop colour blind people from gaining the same information. With this basic idea we can extent it further to include other meanings and prompts for the user. For example we can include the wildcard character at the end of a prompt where the entry field allows wildcard entry (for example on a search window), by making the prompt the same character as the wildcard character we not only let the user know that they can enter a wild card but also what the wildcard character is. These are two great uses for field prompts, you could extend them slightly but I would not recommend using more than 3 or 4 different prompts. As always consistency is they key so make sure you use the prompts consistently throughout all your windows and applications.

Visuvisual Cues
When using an application there often little features that can aid a user in performing a task, for example on a spreadsheet you can click in the little gap between the header of each cell and drag to enlarge and decrease the size of the cell to the left of the gap. Like all visual operations there is normally a manual method for performing the same operation. But the visual operation is simpler and quicker for the user and they can save time by using this feature. However the visual operation is only quicker for the user if they know its there! So this article deals with how we can inform the user that these little features are available and how we an do this in a standard manner. There are many ways of informing the user that a feature is available, you can add details in the help file or the manual, mention the feature in training, but relatively few people receive training on custom applications and even less read help files and manuals. Your application should be able to inform the user about the feature or at least give them an indication that there may be some special feature that they may know about.

Pointers
The easiest way to alert the user to a feature is by changing the pointer to something other than the standard mouse pointer. To go back to our earlier example of a spreadsheet, the most common way of informing the user about the cell resize feature is to change the pointer to a West East pointer when the mouse is moved over one of the header gaps. To be fair the user has to move the mouse over that location to find out about it but in the general course of using the application they will move the mouse around the screen to click on items and to access

menus so very soon after starting to use the application they will see a sudden flicker of the mouse Practicalpointer to a different style. This visual cue is picked up bybehold it doesthey return their Use of spot to see if the same thing happens. Lo and the user and and the west Colour mouse to the same east arrows give an indication of what type of function can be performed. The user can then experiment and and quickly they learn the cell resize feature without reading a help file or manual and no training. We can use this concept in our own application to let the user know about some visual features or some hidden feature which may not be obvious or readily apparent. For example a lot of applications have a feature similar to a list view where you can click on a column header to sort the result set by that column. But how does the user know this feature is available? A solution is to include a small key on the column that the data is currently sorted but its still not obvious to the user that they can click on a header to sort the data. Setting the mouse to a pointer with the same small key included when the mouse hovers over a header at least gives the user a visual cue that there is more to the header than meets the eye. Drag and Drop is another feature that most users do not realise is available to them, especially in custom applications, where you normally include left and right assignment buttons to perform the same task. By changing the pointer to a regular pointer with arrows pointing in the drag and drop direction will at least give the user a fighting chance to know they can drag and drop items.

More Pointers
The following images are some examples of standard pointers you can use in your application to give the user a visual cue that your application will let them perform an action with the mouse that they may not know is available:

General Drag Drop Magnify Click To Sort

Drag East West Resize Panel East West Resize East West

Drag North South Resize Panel North South Resize North South

Draw Here Click Here or Hyperlink Right Mouse Button

Slider East West

Slider North South

If you have any standard pointers that you have designed then please send them in to share with other developers.

I always say you can spot a Visual Basic application by the gratuitous use of colour. Just because you can make the windows controls in your application any colour you choose does not mean you should! I am not advocating the removal of all colour in your applications, but by a consistent use of a limited number of colours and using other methods for visual cues such as borders and pointers which will be the topic of other articles your application can be made to look and feel much more professional. When was the last time you saw a Microsoft application with green text entry fields multicoloured buttons. You get the picture. Enough of the soap box, now on to the topic at hand.

Windows Colour Constants

The first mistake a lot of people make is not to make use of the windows predefined colours,

Windows Background Windows Text Application Workspace Button Face

Although some times you may perform some development work for a company who specify the colours for all elements of the interface. Where they do not make sure you use the predefined constants for these windows defaults. There is nothing worse than using an application that has sometime used the predefined standards and other times used what was the standard for their machine. Picture the window on the users machine who has the windows background colour specified as mint and the application window with half the fields defined as white and half defined as windows background! It may have looked fine in development but at run time yuck! When you are testing your application, set all the windows default colours to some wacky values then you will quickly and easily spot the invalid use of these colour

When To Use Which Colour

The following list describes common situations and the colours that should be used in those All windows backgrounds should be Button Face. All command button backgrounds should be Button Face and the text should be Window Text. Editable fields should have a background colour of Windows Background and the text should be Windows Text with a 3D lowered border. Do not use any other colours for special meanings for example; all red fields are mandatory. What if your user is colour blind and cannot see the red? A future article will describe a more universal solution to this problem. The same goes for Listboxes, Checkboxes, Radio buttons and all the other standard controls. Non Editable fields should have a background of Button Face to indicate to the user that

the field is not editable. If you just disable the field they will try to click into it. A List of multiple columns that are not editable but are used for selection purposes should have a background of Windows Background and a text colour of Windows Text with Dark blue being used to indicate the selected row. If multiple rows can be selected then blue indicates a selected row and a dashed rectangle indicates the current row. The header row of the list should be windows background with Windows Text for the text and a 3D raised border. A list of multiple editable columns should have a background colour of Button Face and should follow the normal edit field rules described above for the editable columns. Group boxes should always be 3D lowered with white and dark Grey for the high and lo lights of the rectangle. Not Windows Background and Application Workspace as some applications use yuck! The text should be Windows Text. Tab pages should be Button Face. Not a different colour for each tab! Where possible any custom icons or images used in the application should stick to the basic windows 16 colours and make sure the background colour of the image is correctly masked to match the background colour of the are underneath the image. For example if you have a company logo with a Grey background on your logon window with a Windows Background for its colour then anyone who does not use Grey for their windows background will see an ugly Grey border around your image. Following these simple colours consistently will help to give you application a more professional look and feel which the tired eyes your users will appreciate, of course there us much more to a professional looking GUI but that's a topic for another article.

About Ken Howe's GUI Standards

These series of articles are about standards for graphical user interface design (as the name suggests!). They come from years of developing user interfaces for countless applications and windows. Watching users interacting with applications, reading books on user interface design and reading articles such as the Microsoft Window 95 style guidelines. They also come from years of reviewing interfaces design by other people and pointing out simple mistakes that can really make a difference to the look and feel of the application. The graphical user interface of your application will make or break the application. It is the only part of your application the users sees, the fact that you have brilliant code behind the scenes with a partitioned design and the fastest business objects are important to you but if the user cannot understand how to operate your application they are all for nothing. You can spend days designing some really slick new visual interface component but if the user does not even realise they can interact with it then you have wasted your time. All these problems can be overcome with some simple rules and guidelines and by following the basic rules, make it simple, intuitive and consistent. This series of tips is development tool independent, they apply equally well to PowerBuilder as to Visual Basic or any other tool that is used for developing graphical user interfaces.

http://www.pbdr.com/guistd/index.htm