Paper 166

GUI KISSes: Tips and Strategies for Interface Design

John A. Quarantillo, Westat Inc., Rockville, MD

ABSTRACT: This paper discusses Graphical User Interface (GUI) design. It is tempting for developers to build an interface using too many bells and whistles. Such an interface, although technically appealing and challenging, can be difficult to develop and mai ntain, but most important, difficult to use. The acronym KISS (Keep It Simple, Stupid) applies well to interface design. A simple, effective interface should be designed with the users needs taking first priority. Specific topics addressed include: which types of screen controls to use and when, keyboard and mouse support, designing with portability in mind, and testing. The audience level is beginner, and will focus more on the strategies used than actual code to implement such interfaces. INTRODUCTION: GUI Design has come a long way in the past few years. What is now possible and sometimes commonplace was previously unthinkable, or unaffordable. With the availability of integrated design environments, developers today can quickly and effectively produce simple graphical front ends to complex databases. The tips and strategies discussed here are the result of eight years of development using a variety of packages including SAS software (SAS/FSP FSEDIT procedure and SAS/AF with and without FRAME entries), Microsoft Access, and Borland Delphi. A variety of front and back end configurations were developed, based on client needs and which products were the best fit to the problem at hand and the staff available. ASSIMILATE: A good systems analyst is able to take a problem and digest it, absorb the problem, learn about it, grasp it, and fully understand it. This is an often overlooked or minimized step in the development of an interface. Developers and analysts might be well versed in the system requirements from the systems point of view, but they must also look at things from the users perspecti ve. Before the first screen is drawn, the developers need to understand fully the way in which the interface is to be used. It is too easy for developers to second-guess the users while meeting all the back end systems requirements. In most cases the guesswork falls short. Yes, there are many details about a system that the users arent aware of and need not be, but they are well versed in how they want and need to do things. If the designers arent aware of the full system requirements, from the front (user perspective) and the back (system perspective) they are certain to fail in designing an interface. SIMULATE: When designing an interface, sometimes the best approach is to simulate the current environment. If this is a system that is to be used to collect data from hard copy, the best design for an input screen is one that most closely resembles the currently used paper form. If you are designing a billing system, make the screen look like the old invoices. If you are collecting employee job histories, make the screen look like the companies employment records. If you are collecting death certificate information, make the screen resemble t he actual certificates. The benefits reaped by designing an interface in this manner are incredible. These benefits are so large, that if the current paper system has historically different layouts of the same hard copy data forms, it is worthwhile to develop multiple input screens to match each historical revision of the data form. In the previous death certificate example, if you are building a system to collect data from a number of different states it might be worthwhile to design a separate screen for each state that has a different format for their certificate. If the system being developed is a replacement of a current computerized system, this approach is still valid, but to a point. Obviously the current system has shortcomings, because it is being replaced. In this case, the goal of the developers is to simulate the feel and appearance of the existing system, while enhancing its overall performance. By keeping the overall feel of the existing system, the training and transition periods will go much more smoothly. HOMOGENIZE: Effective data systems have a similar feel throughout the entire system. The users find comfort and familiarity when the same basic menu options appear on all screens, and in the same space. Certainly some screens will have menu options unique to that screen, but the basic menu options should appear exactly the same and in the same order throughout the system. The following is a good example that will illustrate the need to homogenize. A large system was developed to collect medical information in a clinical trial study. The main portion of the system was designed, developed and implemented by a large team of programmers that communicated closely and set the standard that on all menu screens, the hotkey x would be used to exit that menu and move up one level in the system. The problem surfaced when a separate pro grammer was given the task of developing a data transmission module to add in to the system. This programmer was not aware of the standards and conventions set by the main team. In the data transmission portion of the system the hotkey e was used to exit that menu and move up one level in the system. This seems like a minor issue, but was compounded by the fact that on one of the menus the hotkey x was used to begin the exchange data portion of the system, which could take sometim es more than an hour to run. Another point to consider is color. Color can be useful to alert the user to problem areas. Color can also be useful to indicate to the user which part of a system they are in. Careful consideration must be taken when using color. First, if the system is to be ported to another platform, the developers must ensure that the color scheme used is functional on the platform intended for use. Certain color schemes that offer bright contrast in a Microsoft Windows environment might prove to be virtually unreadable on an MVS mainframe. Second in the Windows environment, if the developers use system default colors such as background, and buttonface, they might be quite surprised what their interface looks like when a creative user ventures into Control Panel and changes the color scheme to fit their taste. It is recommended that developers avoid using these system defaults. Choosing a good color scheme, and hard coding the interface to that scheme is the best way to prevent these problems.

This homogenization requires a bit of communication among the design and development teams. The best approach is to set standards early, make them known to all the design and development teams and ensure that all involved stick to these standards. EMPOWER: An effective interface will give the user the ability to quickly and easily do what they want with the data. An important facet of interface design is to choose the proper screen controls to fit the type of data. GUI interfaces can include a vast array of screen controls that allow the user to enter and view information almost instantaneously. Certain types of data fields or columns lend themselves to specific screen controls. Generic terms are used here to describe screen controls, as each package has its own special naming conve ntion. There are many other types of controls, but the important thing to keep in mind is to use the control best suited to the data or task. Another point to consider when choosing controls is overall appearance of the screen. Screens should be organized in a logical, straightforward manner. Care should be taken to avoid screens that look cluttered. Unfortunately (for developers) users are quite varied in their wants and needs. It is important to keep in mind these different types of users when designing an interface. Many users are quite savvy, and flit about the screen with a combination of hotkeys, mouse clicks, and keystrokes. Other users plod along never bothering to find or use any shortcuts. Still others seem to suffer from Murophobia (the fear of mice). Users who are good typists usually prefer hotkeys and keystrokes to any mouse use. They contend that moving from the keypad to the mouse slows them down. Building an interface that supports most, if not all these types of users is highly important. Platform issues arise here, as mouse input is not always supported. A well-implemented interface will allow the user to perform the same action using any and all input devices. The best way to achieve this full empowerment for all types of users is to create a triple redundant command interface that builds in mouse commands, hotkeys, and visual buttons to perform all basic and important tasks. SUPPORT: Even if you follow all the suggestions previously mentioned, your interface will still require some kind of ongoing support. The first facet of support is documentation. If youve designed your system correctly, you need to relay the information to the users. The best method to do this is a users guide. Many systems even go the extra mile by building in online help. Either way the users need to know what to expect from the system, and need to know how to use the system. If you dont tell them about the shortcuts they wont fin d them. If you dont tell them how to use certain controls, they may not input data correctly. The next phase of support is the testing phase. Testing to most developers is the process of zipping through the application and declaring that it works. The problem with this is developers dont think or act like users. It is p aramount that testing be performed by someone other than the person that developed the system. Optimally potential users or persons at the same level of expertise should perform the testing. It is not uncommon that after initial feedback from testing developers are forced to reconsider some assumptions made during the design process, and rework a significant portion of the system. The last phase of support is maintenance. After a system has passed internal testing, and perhaps beta testing by consumers, the system is released into production. At this point the system has entered maintenance mode. This is an ongoing process of communication between the developers and users. When a problem arises, the developers evaluate it and decide if the problem is worthy of delivering an upgraded version of the interface. CONCLUSION: By following the aforementioned strategies, developers can design and implement effective and useful interfaces that are simple to design, develop, use and maintain.

Microsoft Access Graphical User Interface Design Tips

Many people rush into designing the User Interface for their Access database before thinking about layouts, formats and usability. The following tips from David McQueen may greatly assist when considering all of the options available: This is my primary role in designing Access applications, and having been drafted in plenty of times to "have a look" at some of the forms and reports that have been designed by others, I think that I am able to hand a bit of advice to others. 1. Users love forms designed in Tahoma 8. I know this old hat to many developers but I am amazed by the amount of screens I come across with a combo of Times New Roman and Bauhaus. 2. Design reports with Title, Date, UserName and Printed Time in the Header preferably. 3. Think of the dumbest user ( I know that sounds insulting, but...) possible and ensure that even they can easily read what is on the screen. 4. Ensure that the design pattern is consistent across the software. For example if you double click to open an item on one list ensure that you can do the same on another form. 5. Use colour sparingly. Stick to the gray/blue backgrounds and limit the extensive use of colour. If there are items such as required fields on a form, use one background colour for all of these fields, e.g. yellow 6. Ensure a consistent easy navigation between screens/modules. I prefer to have a consistent top toolbar wherever the user is in the software, or if users don't like that to have a consistent sidebar/treeview. 7. Type error trapping/required input fields and match them to a dialog box. Nothing worse than a user seeing "Error 76a..blah, blah" when a standard procedure has gone belly up. 8. Keep screens as uncluttered as possible and please, please, please.....ALIGN the controls on the form. 9. For objects that are not applicable to a certain user or process, just gray them out/disable them, rather than deleting them. It helps especially when users have made a mental image of what the screen should look like. 10. Ensure that data in fields is justified appropriately. Right for numbers (integers) and Left for strings.

User Interface Design Tips, Techniques, and Principles

A fundamental reality of application development is that the user interface is the system to the users. What users want is for developers to build applications that meet their needs and that are easy to use. Too many developers think that they are artistic geniuses they do not bother to follow user interface design standards or invest the effort to make their applications usable, instead they mistakenly believe that the important thing is to make the code clever or to use a really interesting color scheme. Constantine points out that the reality is that a good user interface allows people who understand the problem domain to work with the application without having to read the manuals or receive training. User interface design important for several reasons. First of all the more intuitive the user interface the easier it is to use, and the easier it is to use and the less expensive to use it. The better the user interface the easier it is to train people to use it, reducing your training costs. The better your user interface the less help people will need to use it, reducing your support costs. The better your user interface the more your users will like to use it, increasing their satisfaction with the work that you have done. In this article I discuss: 1. 2. 3. Tips and Techniques UI Design Principles Concluding Remarks

1. Tips and Techniques

The following tips and techniques that I have learned over the years should prove valuable:

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

Consistency, consistency, consistency. I believe the most important thing you can possibly do is ensure your user interface works consistently. If you can double-click on items in one list and have something happen, then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your user interface enables your users to build an accurate mental model of the way it works, and accurate mental models lead to lower training and support costs. Set standards and stick to them. The only way you can ensure consistency within your application is to set user interface design standards, and then stick to them. You should follow Agile Modeling (AM)s Apply Modeling Standards practice in all aspects of software development, including user interface design. Be prepared to hold the line. When you are developing the user interface for your system you will discover that your stakeholders often have some unusual ideas as to how the user interface should be developed. You should definitely listen to these ideas but you also need to make your stakeholders aware of your corporate UI standards and the need to conform to them. Explain the rules. Your users need to know how to work with the application you built for them. When an application works consistently, it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each feature in an application step-by-step. Navigation between major user interface items is important. If it is difficult to get from one screen to another, then your users will quickly become frustrated and give up. When the flow between screens matches the flow of the work the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system needs to be flexible enough to support their various approaches. User interface-flow diagrams should optionally be developed to further your understanding of the flow of your user interface. Navigation within a screen is important. In Western societies, people read left to right and top to bottom. Because people are used to this, should you design screens that are also organized left to right and top to bottom when designing a user interface for people from this culture? You want to organize navigation between widgets on your screen in a manner users will find familiar to them. Word your messages and labels effectively. The text you display on your screens is a primary source of information for your users. If your text is worded poorly, then your interface will be perceived poorly by your users. Using full words and sentences, as opposed to abbreviations and codes, makes your text easier to understand. Your messages should be worded positively, imply that the user is in control, and provide insight into how to use the application properly. For example, which message do you find more appealing You have input the wrong information or An account number should be eight digits in length. Furthermore, your messages should be wo rded consistently and displayed in a consistent place on the screen. Although the messages The persons first name must be input and An account number should be input are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be The account number must be input to make the two messages consistent. Understand the UI widgets. You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way you can learn how to use widgets properly is to read and understand the user-interface standards and guidelines your organization has adopted. Look at other applications with a grain of salt. Unless you know another application has been verified to follow the user interfacestandards and guidelines of your organization, dont assume the application is doing things right. Although looking at the work of others to get ideas is always a good idea, until you know how to distinguish between good user interface design and bad user interface design, you must be careful. Too many developers make the mistake of imitating the user interface of poorly designed software. Use color appropriately. Color should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. You also want to use colors in your application consistently, so you have a common look and feel throughout your application. Follow the contrast rule. If you are going to use color in your application, you need to ensure that your screens are still readable. The best way to do this is to follow the contrast rule: Use dark text on light backgrounds and light text on dark backgrounds. Reading blue text on a white background is easy, but reading blue text on a red background is difficult. The problem is not enough contrast exists between blue and red to make it easy to read, whereas there is a lot of contrast between blue and white. Align fields effectively. When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. I have always found the best way to do so is to left-justify edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right-justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen. Expect your users to make mistakes. How many times have you accidentally deleted some text in one of your files or deleted the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err is human, so you should design your user interface to recover from mistakes made by your users.
3

14. Justify data appropriately. For columns of data, common practice is to right-justify integers, decimal align floating-point numbers, and to left-justify strings. 15. Your design should be intuitable. In other words, if your users dont know how to use your software, they should be able to determine how to use it by making educated guesses. Even when the guesses are wrong, your system should provide reasonable results from which your users can readily understand and ideally learn. 16. Dont create busy user interfaces. Crowded screens are difficult to understand and, hence, are difficult to use. Experimental results show that the overall density of the screen should not exceed 40 percent, whereas local density within groupings should not exceed 62 percent. 17. Group things effectively. Items that are logically connected should be grouped together on the screen to communicate they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group them and/or you can put boxes around them to accomplish the same thing. 18. Take an evolutionary approach. Techniques such as user interface prototyping and Agile Model Driven Development (AMDD) are critical to your success as a developer. 2. UI Design Principles Lets start with the fundamentals of user interface design. Constantine and Lockwood describe a collection of principles for improving the quality of your user interface design. These principles are: 1. The structure principle. Your design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and separating unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure principle is concerned with your overall user interface architecture. The simplicity principle. Your design should make simple, common tasks simple to do, communicating clearly and simply in the users own language, and providing good shortcuts that are meaningfully related to longer procedures. The visibility principle. Your design should keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs dont overwhelm users with too many alternatives or confuse them with unnee ded information. The feedback principle. Your design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users. The tolerance principle. Your design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonable. The reuse principle. Your design should reuse internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.

2. 3.

4. 5.

6.

3. Concluding Remarks The user interface of an application will often make or break it. Although the functionality that an application provides to users is important, the way in which it provides that functionality is just as important. An application that is difficult to use wont be used. Period. It wont matter how technically superior your software is or what functionality it provides, if your users dont like it they simply wont use it . Dont underestimate the value of user interface design nor of usability. Effective developers find ways to work closely with their stakeholders. I'm a firm believer in the AM practice Active Stakeholder Participation where your stakeholders do much of the business-related modeling using inclusive modeling techniques. Furthermore, they should be involved with your user interface prototyping efforts as well.

User Interface Flow Diagrams (Storyboards)

User interface prototypes are an excellent means of exploring your user interface, but unfortunately it is easy to quickly become bogged down in the details of the user interface and not see the bigger picture. Consequently, you often miss high-level relationships and interactions within your systems UI. User interface-flow diagrams also called storyboards, interface-flow diagrams, windows navigation diagrams, and context-navigation maps enable you to model the high-level relationships between major user interface elements and thereby ask fundamental usability questions. Figure 1. A UI flow diagram In Figure 1 you see the start at a user interface-flow diagram, called a Navigation diagram in RUP, for the university system. The boxes represent major user interface elements, modeled as you would instances/objects, and the arrows represent the possible flow between them, modeled as you would transitions in activity diagrams. For example, when you are on the Desktop screen, you can use the Students Icon to take you to the Search for Students screen. Once you are there, you can either go back to the desktop (going back is always assumed) or go to the Student Profile screen. User interface-flow diagrams are typically used for one of two purposes. First, they are used to model the interactions that users have with your software, as defined in a single use case. For example, a use case can refer to several screens and provides insight into how they are used. Based on this information, you can develop a user interface-flow diagram that reflects the behavioral view of the single use case. Second, as you see in Figure 1 they enable you to gain a high-level overview of the user interface for your application. This overview is effectively the combination of all the behavioral views derived from your use cases, the result being called the architectural view of your user interface (Constantine and Lockwood 1999). I prefer to take the high-level overview approach, also referred to as the architectural approach, because it enables me to understand the complete user interface for a system. Because user interface-flow diagrams offer a high-level view of the interface of a system, you can quickly gain an understanding of how the system is expected to work. It puts you in a position where you can validate the overall flow of your applications user interface. For example, does the flow
4

make sense? I am not so sure. Why cant I get from Seminar Details to Professor Information? When you are viewing the inform ation for a seminar, isnt it possible you might want to view the information for the instructor of that seminar? Furthermore, user interface-flow diagrams can be used to determine if the user interface will be usable. If there are many boxes and many connections, it may be a signal to you that your system is too large for people to learn and understand.

User Interface Prototypes

User interface (UI) prototyping is an iterative analysis technique in which users are actively involved in the mocking-up of the UI for a system. UI prototypes have several purposes: As an analysis artifact that enables you to explore the problem space with your stakeholders. As a requirements artifact to initially envision the system. As a design artifact that enables you to explore the solution space of your system. A vehicle for you to communicate the possible UI design(s) of your system. A potential foundation from which to continue developing the system (if you intend to throw the prototype away and start over from scratch then you dont need to invest the time writing quality code for your prototype).

As you see in the activity diagram depicted in Figure 1 there are four high-level steps in the UI prototyping process. The first step is to analyze the user interface needs of your users. User interface modeling moves from requirements definition into analysis at the point you decide to evolve all or part of your essential user interface prototype into a traditional UI prototype. This implies you convert your hand-drawings, flip-chart paper, and sticky notes into something a little more substantial. You begin this process by making platform decisions which in effect is an architectural decision. For example, do you intend to deploy your system so it runs in an Internet browser, as an application with a windows-based graphical user interface (GUI), as a cross-platform Java application, or as a mainframe-based set of green screens? Different platforms lead to different prototyping tools, for a browser-based application, you need to use an HTML-development tool, whereas a Java-based application would require a Java development tool and a different approach to the user interface design. Figure 1. UI prototyping process. Figure 2. Essential user interface. Figure 3. Screen sketches.

While youre determining the needs of your stakeholders you may decide to transform your essential user interface prototypes, if you created them to begin with, with sketches. Figure 2 depicts an essential UI and Figure 3 a sketch of two potential screens or HTML pages based on that prototype. Transform really isnt the right word here seeing as Im using a completely different modeling technology now (a whiteboard instead of paper) so in effect Im replacing the essential UI prototype with the sketches. I chose to split the prototype in two for cohesion issues I prefer screens that fulfill a single purpose, in this case capturing basic student information and enrolling a student in seminars respectively. This is arguably a design issue (theres a fine line between analysis and design which youll cross all the time). The sketches provide a final level of detail than the paper prototypes do, it is much easier to get a feel for how the screen will be implemented from than it is from Figure 2, although the sketch isnt as flexible because its hard to shift widgets from one part of the diagram to another whereas with the paper it is very easy. As you iterate through UI prototyping you will often discover information better captured in other artifacts. Thats okay, y ou can follow the AM practice Iterate to Another Artifact and capture that information in the proper place. It also points to the importance of the AM practice Create Several Models in Parallel you often need to work on several things at once to get the job done. Agile software development is an evolutionary process, so this is normal. Once you understand the UI needs of your stakeholders the next step is to actually build a prototype. Using a prototyping tool or high-level language you develop the screens, pages, and reports needed by your users. With the user interface platform selected, you can begin converting individual aspects of your essential UI prototype into your traditional UI prototype. You may want to create sketches such as you see in Figure 3 or go straight to a concrete implementation, such as the HTML page depicted in Figure 4. The sketches are more inclusive, your stakeholders can be actively involved in creating them, although the actual HTML page is much closer to working code (your primary goal). Figure 4. Concrete UI prototype (HTML page).

It is critical to understand that you dont need to create a prototype for the entire system. It is very common to prototype a small portion of the user interface, perhaps a single screen or HTML page, before moving on to implementing it. Remember, agile developers work in an evolutionary manner the dont need to define everything up front before moving on. Sometimes you will need to prototype a large portion of your system, perhaps as part of an envisioning exercise or perhaps even to help define the system scope so that you can obtain project funding. After a version of the UI prototype is built, it needs to be evaluated by your stakeholders to verify that it meets their needs. Sometimes this is as easy as asking someone to spend a few minutes to look at what youve built and other times its as complicated as scheduling a meeting so that you can demonstrate the software to a group of people. I prefer the first approach. When evaluating a UI prototype Ive always found that the following questions provide me with significant feedback: What is good about the UI prototype? What is bad about the UI prototype? What is missing from the UI prototype?

After evaluating the prototype, you may find you need to scrap parts of it, modify parts, and even add brand-new parts. You want to stop the UI prototyping process when you find the evaluation process is no longer generating any new ideas or it is generating a small number of not-soimportant ideas. Otherwise, back to exploring your stakeholders UI needs.

Data Driven User Interface Design

Recently, I am responsible for a project to design a web application which automates many operational tasks that are carried out manually now. One of the challenges for this project is the dynamic nature of the user interface. Based on different types of the client and the different features the client subscribes, the user interface needs to display different widgets. Its expected that the types of clients and client features will undergoing constant change in the future releases. Traditionally, those requirements will be addressed by: Build in the logics in the user interface layer, specifically in JSP page with JavaScript. Update the UI logic as the requirement changes in future releases. The drawbacks are obvious. We end up with JSP page cluttered with business logics. Hopefully, with the help of the carefully designed tag libraries, page wont get too ugly. Nevertheless, the constantly modifications of the JSP pages for each release require significant development and testing time. Not to mention about the difficulty to test and the possibility of screw-up some of the logics. Carefully examining the situation, I found patterns of the requirements. For each type of the client, there is a list of client features. For each client feature, a list of properties needs to be captured. Although the features and properties vary from one client type to another, these two patterns remain. I was able to design a simple data model to reflect those two relationships. Everything that needs to be displayed in the GUI can be configured in database first. For example, a client feature requires three properties, one String value, one Boolean value and one chosen from a list. In database, I can put three records for those properties storing their label name, type (text, checkbox, and select list) and other cosmetic information like length of text box. Then, I have the back-end server reads those meta data and feed them to the GUI. In stead of hard code the logics, the GUI use JavaScript to process the meta data and generate the layout on the fly based the meta data. For the above example, the JavaScript in the GUI will iterate through a list of three java beans, each containing the label, the type, the length and other cosmetic information about the widget and create the widget accordingly. It worked nicely to resolve the challenges I am facing. I can, in a sense, program my GUI layout flexibly by entering different data in the database. Every time, I need to add a new type of client, or a new feature or several new properties, I add a bunch of records in to th e database and Walla, I have the GUI layout I want. The advantages of this type of data driven GUI design derive from the simple fact that data is much easier to change than the codes. In additional to a shorter development cycle, data driven GUI design also maintains the basic patterns (type-feature-properties) I identified since those patterns are coded. It eliminated the need to copy and paste codes, which frequently lead to errors. The codes are easier to maintain too. As long as I document down the data model, another developer can change the GUI layout as much as he wants without having to understand my GUI codes. Extending the thinking to larger extend, whenever a strong repetitive pattern is found, we should think about ways to break o ut the fixed (doesnt change much over the time) logics and the flexible (frequently changing) logics. Implement the fixed logics in codes and represent the flexible logics in data, either in relational database or in XML format. By doing so, we get a stable and yet flexible architecture, well prepared for the future dynamics. Reference: Thoughts about GUI layout techniques

Apple - User Experience - Our Definition

"User experience" encompasses all aspects of the end-user's interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features. In order to achieve high-quality user experience in a company's offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.
6

Good examples of GUI design for business-oriented, heavy data-entry (CRUD) applications
Where can I find examples of very well produced enterprise-y software that have: Standarized use of lookup/search screens. (User gets asked for Client ID, doesn't know it but can look it up from a popup window that returns it) Standarized usability/LaF conventions Would be nice to see samples ranging from simple CRUD screens to very complex process-oriented GUIs for applications like CRM/ERP/Financial/Risk assessment etc. Basically GUIs with a high amount of entry fields that define certain business process.

Good, consistent use of keyboard shortcuts. Good keyboard form navigation Standarized form validation

+ 12 vote I don't have any examples to point to. In truth, many of these screens may be hard to find on the web for the simple fact that most of them tend to be "ugly". These kinds of screens are rarely pretty. I can offer some tips, from long history working with these things. 1. Consistency. Make everything "work the same", and work the same all the time. Basically, you should be able to do your entry looking at the form, not the screen. All those flashes and subtotals and colors are nice after they keyed the form in, but not during entry itself. There you basically need audio alerts to let them know "something is wrong". The classic "ticky-ticky-ticky-ticky-beep-beep-beep-beep" scenario as the user discovers that they entered a field wrong 4 fields back. The users aren't quite blind, but they're not going to be looking at your screen. The data is on the form. It's better to work modally, and STOP THEM for ERRORs than let them keep going. For large forms, scanning all of that information and looking for errors after the fact is very difficult. Stop them when they're wrong so they can fix it and move forward rather than coming back to fix it at the end. The more business rules and validation and enforcement you can have on the form, the better. Popups, alerts, pickers, if it needs their attention, modal modal modal. They're not working with clay here. They're not authoring the great american novel or modeling the global economy. Summarize the results for spot checks. For example, keying in an order, they should be able to look at the order total and line item count to see if they got the order in "correctly" as a sort of checksum rather than having to scan their entry field by field. Most workflows have an inevitable cross check phase where they go through their entry to verify the data, but that should be after the "raw keying" of the data. People work faster when they're in a "bulk entry" mode rather than spot checking each one, each time they key it in. It's breaks their rhythm. Make detecting and correcting the exceptions easier after basic validation and keying is done. If some fields are more important than others (and you know which ones those are), visually highlighting them on the screen AND on the paper form works wonders. If the forms and such are designed well (both the computer forms and the paper entry forms), errors should be difficult to enter (like the wrong customer, or wrong item, etc.). You might have a typo in some notes or special instructions, but, not so much everywhere else. If they miskey an item or amount, odds are the order won't total properly so the simple checksum will help them catch it. Going back to "consistency", make sure things like pickers and such all operate the same. Try to keep the special functions to a minimum, as it simplifies training and lets users just "flow" in to their work. 5. Keyboard shortcuts and navigation are a requirement, not an option. A real pain point here can be detail areas (i.e. table structures). You may need a shortcut to enter and exit the table strcutures. You may have seen a lot of examples where you can "Tab" in to the table, but not tab back out. Have a dedicated "meta-tab" key to move in and out of sections. Requiring the mouse to navigate out of a section is a no no. 6. Have a single hot key for pickers. Ideally, they won't have to use these too often. Maybe for customer lookup, most of the other codes they're inevitably memorize or they'll be keyed on the entry form. Make the pickers filterable. 7. Scrolling is the devil. Scrolling is evil. No Scrolling! Paging better than scrolling because "fields don't move", they're always "in the same spot" on the screen. How often have you "scrolled" and had to search to pick up "where you started" before the scroll to regain context. Even for pick lists paging works very well because the page change lets them know they actually "did something" visually. Many times you scroll a row and "gee did I really?" Single line scrolling can be too subtle. For large entry forms, multi-pages beats long, scrolling treatises every day of the week. If your forms are that big, make sure you have a hot key to move forward and backwards through the form, and make sure there is some context information on each page (customer name, order number, whatever...simple header). 8. Robust querying. "Query by example" as it's known is one of the best mechanisms (i.e. they fill it the form "what they know" and forms come back). Folks need to find data by just crazy criteria, if most every field is queryable, this lets them do that without you second guessing what they will or won't need. Informix 4GL used to have a spectacular QBE system ( > 04/01/09 for dates after Apr 1 2009, 12345|23456 for item codes 12345 or 23456). A good QBE expression will most likely not validate in a typical field, it's a special case. (Which is why you rarely see QBE today, it takes too much work -- but it is OH so nice.) 9. Remember, users don't know WHY or HOW they do things, they only know WHAT to do. They know "when I want to do A, I hit key Y" they don't know WHY it's Y, where Y is located, the keys X an Z might do similar things to A because they're grouped together. No, they don't know your command taxonomy. They don't know your abstractions. They know to do A, hit Y. Want to Bold a word? Type Ctrl-B. Maybe Ctrl-I to italicize a word is obvious to you because of the mnemonic, it's not to most users. Maybe the Ctrl-B and Ctrl-I are on the Format menu, nicely grouped. Doesn't matter. Ctrl-B == Bold, how do I do Italics? The downside of these interfaces is training. They do take training in order for them to be used. But, in truth, for any reasonably complicated business, the user is going to need training on far more than just the keying process anyway. The entry screen isn't going to teach them the business policies, business rules, etc. You can enforce these in the application, but the user is going to need to know them on their own anyway. But that's OK, because in the long run it's simply more efficient. The game here is getting the data from the user efficiently and presenting it to them in a consistent way. I won't say "logical" way, as, while logic may be logic, it may not be the users logic. So, you can be logical if you want, call it what you want, but be consistent to your users. Another anecdote, we used to 10 key return data. This tended to be just lists of number, like an item code and a quantity. For our purposes it's faster to simply have the users key this data twice in a row than anything else. It catches typos, transpositions, etc. Combined with batch checksums makes the keying go that much faster. These guys only looked at the screens when they started, when they finished, and if they got an error. Finally, no matter what, your screens and procedures WILL change. Whatever form you're using this year, will change next year. That's just reality, so, FYI, be ready for it. Good luck with your project. 4.

2.

3.

I am a fan of the http://www.37signals.com/ suite. I find their forms and GUI's to be well thought out. link|edit|flag

answered May 7 '09 at 3:48

Yes, they're very well produced, but they don't really have the kind of screens I'm looking for (the ones you see in complex CRM/ERP apps mainly) Camilo Daz May 9 '09 at 22:27 @Camilo: Maybe you should consider 37signals' Getting Real (gettingreal.37signals.com) approach given that there seems to be a lot of complexity in your apps. Getting Real will help you design effective and useful UI that keeps users happy. cottsak May 12 '09 at 5:54