GUI Design 24-Feb-19

HMI design There are entire college courses taught on HMI (Human-Machine Interface) design This is just a very brief presentation on some of the most essential points The goal is (usually) to make the design: “Intuitive”--that is, it behaves as the user expects Simple--not cluttered Complete--that is, it lets the user do everything that the program is capable of doing From CIT591, day one: A program is elegant if it combines power with simplicity

Different needs Someone who uses the program only occasionally wants to be able to figure out how to use it Simple controls Clear, descriptive labels Help files Frequent users want to minimize effort Few button clicks, little typing No long sentences that must be read You should know what audience you are designing for Compromises may be necessary, but with care you can design an interface that isn’t too bad for either group Nobody likes an interface that encourages mistakes

“Intuitive” design An interface is intuitive if a new user grasps immediately how to use it It is impossible to make a very specialized task intuitive to someone who doesn’t understand the underlying principles For example, 3D animation programs Very few programs are of this nature What is “intuitive” varies from person to person However, most computer users have some common expectations as to how common controls work

Principle of Least Surprise The Principle of Least Surprise says that the GUI should do the least surprising (= most expected) thing Users have strong expectations about how GUI elements, such as Buttons, work Users also have strong expectations about how and when files are opened and saved, and a host of other things Anything that we “take for granted” in an interface should not be violated without very good reason

Passive GUI elements When text is entered, it just sits there until the user does something more--entering text does not cause something to happen For example, there may be an OK button to use the text Exception: Very simple forms with only a text field may respond to the Enter key (even if an OK button is present) Checkboxes (squares) and radio buttons (circles) accept information from the user but don’t take any actions Selection lists (for example, to choose a language) accept information but don’t themselves do anything with it Exception: Lists that modify the view (such as the font or the alignment) may have an immediate, visible effect

Active GUI elements The most common active GUI element is the Button When you click a button, you expect something to happen Buttons that only make settings for future use should not be Buttons Menu items may be either active or passive Menu items that are just settings should have a checkmark in front of them when “turned on” Menu items that change their labels (such as On or Off) are just confusing Does On mean the feature is on, or you have to click it to turn it on? Menu items that open a dialog box to get more information should end in an ellipsis (...), for example, Font...

Feedback Everything the user does in a GUI should result in feedback as to whether it worked Example: Checkboxes get checked, radio buttons get “pushed,” typing shows up in text areas, etc. Clicking a button should either show the results, display a message that the action occurred, start a “progress bar” going, or pop up a dialog box that says what went wrong Items that cannot be used at the moment should be made inactive (so that they are visibly “grayed out”) This also solves the problem of what to do if the user clicks on one—it can’t happen Items that cannot be used at the moment should not be removed, which will cause the user to waste time looking for them

Minimize effort One common measure of the effort required to do something is “mouse clicks” Example: Compiling a program in BlueJ vs. Dr. Java For example, if the user’s action is successful, provide feedback, but don’t pop up a dialog box with a message such as “Your file has been saved. [OK]” Many editors use an asterisk or dot next to the name of any unsaved file If the user’s action is not successful, make sure that the feedback is highly visible This is a good place to use a dialog box

Simple design Windows that do everything are too cluttered to use easily For example, you should not put your preferences and your working elements in the same window One ambulance company used a single window for maintenance information, keeping track of which employees were on duty, and dispatching ambulances Separate concerns—present windows that give the user the right tools for what they are working on now

wGetGUI v1.0

FileMatrix

Progressive disclosure Simple design does not mean less control The Principle of Progressive Disclosure says to hide complexity until it is needed For example, look at the Preferences... menu on almost any large program You don’t see all the possible settings at once Settings are grouped according to what the user is probably trying to do—change the appearance, set security levels, etc.

User testing Most important in GUI design, even for experienced designers, is user testing Have a classmate or friend try out your program Watch as they do it Do not tell them how to use it; let them figure it out If your test user cannot figure something out, explain how to do it; but make a note of the problem, and fix it Even a minimal amount of user testing can greatly improve the design

The End