Effective Screen Design

"Successful screen design is based on how well the developer knows both the user and the data." Unfortunately, the resulting screen designs were essentially no different than the forms. Designing a computer screen is essentially no different than designing a paper form. But since most of today's developers have little experience in forms design perhaps it is time to review some of the basic elements of good design. As to senses, there is little point in devising an elaborate color scheme if the user may be colorblind. Again, know thy intended user. The objective, therefore, in good screen design (and forms design) is to make something that is easy to use (intuitive; requiring little interpretation and confusion) and effective for collecting data and displaying information. Although the following discussion can be applied to screens as used in some character based operating systems, it is primarily concerned with Graphical User Interfaces (GUI) as used in today's popular operating systems. The only problem was that it lacked standards, whereby one GUI implemented program did not behave in the same manner as another GUI program. Fortunately, standards started to appear in the late 1980's with IBM's CUA standards (Common User Access) which provided a detailed list of design standards for developing a GUI based program. (NOTE: CUA was an important part of IBM's System Application Architecture standards - SAA). DESIGN CONSIDERATIONS Today there are some pretty slick tools to quickly build screens. Regardless of their capabilities, a developer should be cognizant of three basic design considerations: Layout, Data Entry, and Support: The objective here is to make the screen "clean" and consistent. Too much detail makes the screen cluttered and abrasive to the end-user. When designing your screen, consider eye movement, eye strain and, where appropriate, add magnification. Alignment - there should be some simple symmetry to the screen. Disjointed alignment of fields, text, and images tends to alienate users. There should be a comfortable amount of spacing not only around the edge of the screen, but between sections of the screen. Because GUI windows can be resized (either maximum or to a height and width devised by the user), consider how the screen will look in either form. Borders are useful for defining sections on the screen, but be careful they do not become overbearing and distracting. Zoning - this refers to the establishment of sections within the screen. This is useful if different types of users are going to be accessing the same screen, or if different sections serve distinctly separate purposes (thereby not confusing one with another). In a GUI window, notebook tabs can be useful. Flow - there should be an obvious flow to the screen that will naturally catch the user's eye and prompt him/her in the proper direction. Also understand that the tab order of the keyboard provides direction for the user. Type Fonts - use common fonts familiar to users. Commonly accepted fonts include Arial, Courier, Sans Serif, and Times Roman. Colors - can be helpful for highlighting sections, accenting required field entries, or for general appearance. Be sensitive to color contrasts so the user can adequately read the screen. Headings - screen headings should be placed in a standard position for easy identification by the user. A formal name and, where appropriate, a screen number should be clearly visible to the user. Keyboard/mouse relationship - if in the event a computer mouse either breaks down or is simply not available, the user should still be able to execute the screen using simple keyboard commands. CUA standards are particularly useful in this regard. Data Entry The proper entry of data is just as important as the physical layout of the screen. Regrettably, many designers take a superficial approach to data collection and, consequently, a lot of time is spent later on cleaning up data in the data base. Considerable time can be saved with a little effort here in screen design. Your objective, therefore, is to produce a screen that will collect "clean" data (as opposed to "dirty" data that will have to be corrected later on). Before embarking on screen design, the developer should be intimate with the data specifications. This can be obtained either from a good data dictionary/repository, or from the physical data base design. Basically, the developer is looking for the data element's: Length - the maximum number of characters which may be assigned to a data element. Fill Character - the character to be used to complete a field when the data item to be placed in the field is shorter than the maximum length, e.g., blank, zero, X, etc. Void Character - the character to be used when a data item's value is unknown or nonexistent, e.g., blank, zero, X, etc. Unit of Measure - the representation of numeric data, e.g., area, volume, weight, length, time, energy rate, money, etc. Precision - for numeric data, the number of significant digits in a number. Scale - for numeric data, the placement of the decimal point. Validation Rules - the specific values which the data element may assume, including default values. Generated data - quite often it is necessary to show computations based on primary values being inputted by the user. Program Label - although this will not be visible to the user inputting the data, the developer must understand how the data element is referenced in the data base. Mandate certain field entries be completed before allowing processing to continue. This can be done by: forcing the focus of the window to the field(s) requiring entry; attaching a "hot" color to required field entries (red) and; pop-up messages to prompt the user of problem entries. Automatically enter default values into field entries; this saves time for the user (as well as forcing proper entries). Check characters entered and automatically adjust accordingly. For example, automatically upshift or downshift characters - this is particularly useful when entering State Postal Codes (upshift), and entering e-mail addresses (downshift). Also, reject certain character entries and check formats. Make active use of selection lists, thereby forcing the user to select a choice from a prescribed list as opposed to typing an entry. This "personalizes" the screen for the user. Where applicable, provide for data entry using voice/speech-type dictation. Finally, format the collected data to suit the targeted physical data base. By making data entry "foolproof" you will be saving a lot of time and effort for the end-user, the DBA, and yourself. To minimize user confusion, be sure to include sufficient Help text and messaging facilities into the screen. Too often I have seen screens with little support in this regards. Again, CUA standards should be observed whenever possible. The various sections of the screen sections (if multiple sections). Field entries - showing the name of the field entry, input specifications, along with some sample and suggested entries. If a generated value is displayed, explain how it is computed (from other field entries). "Help" push buttons on the screen are helpful, but everything should be related to the F1 Help key, particularly field entries. Messages Good screen design requires a developer in tune with his intended audience and who can create a simple and effective solution that is easy for the user to execute, yet promotes the collection of "clean" data. No. 03 - "Creating Universal Systems" - Dec 20, 2004. http://www.phmainstreet.com/mba/ss041220.pdf Above all else, the developer should observe all pertinent design standards when creating screens. REFERENCES For vendor CUA (Common User Access) Standards, see: IBM http://www-306.ibm.com/ibm/easy/eou_ext.nsf/publish/558 Microsoft http://msdn.microsoft.com/library/default.asp?URL=/library/books/winguide/fore.htm Apple http://developer.apple.com/documentation/index.html Sun http://docs.sun.com/app/docs/doc/802-6490 For a description of the "Playscript" procedure language, see: No. 38 - "The Language of Systems" - Aug 22, 2005 http://www.phmainstreet.com/mba/ss050822.pdf