DOC PREVIEW
Penn CIT 597 - GUI Design

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

GUI DesignHMI designDifferent needs“Intuitive” designPrinciple of Least SurprisePassive GUI elementsActive GUI elementsFeedbackMinimize effortSimple designwGetGUI v1.0FileMatrixProgressive disclosureUser testingThe EndJan 14, 2019GUI Design2HMI 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 simplicity3Different 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 mistakes4“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 work5Principle 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 reason6Passive 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 effect7Active 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 Of) 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...8Feedback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 them9Minimize 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 box10Simple 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 now11wGetGUI v1.012FileMatrix13Progressive 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.14User 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 design15The


View Full Document

Penn CIT 597 - GUI Design

Documents in this Course
DOM

DOM

21 pages

More DOM

More DOM

11 pages

Rails

Rails

33 pages

DOM

DOM

21 pages

RELAX NG

RELAX NG

31 pages

RELAX NG

RELAX NG

31 pages

RELAX NG

RELAX NG

31 pages

RELAX NG

RELAX NG

31 pages

Rake

Rake

12 pages

Ruby

Ruby

58 pages

DOM

DOM

21 pages

Tomcat

Tomcat

16 pages

DOM

DOM

21 pages

Servlets

Servlets

29 pages

Logging

Logging

17 pages

Html

Html

27 pages

DOM

DOM

22 pages

RELAX NG

RELAX NG

30 pages

Servlets

Servlets

28 pages

XHTML

XHTML

13 pages

DOM

DOM

21 pages

DOM

DOM

21 pages

Servlets

Servlets

26 pages

More CSS

More CSS

18 pages

Servlets

Servlets

29 pages

Logging

Logging

17 pages

Load more
Download GUI Design
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view GUI Design and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view GUI Design 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?