Outline Modified rating scale Heuristic evaluation Modified rating

Outline • Modified rating scale • Heuristic evaluation

Modified rating scale • • • -4: -3: -2: -1: 0: +1: +2: +3: +4: usability catastrophe—imperative to fix before major usability problem–important to fix minor usability problem–low priority cosmetic problem only–need not be fixed not a real usability problem or merit cosmetic merit minor usability merit major usability merit usability excellence

Heuristic Evaluation of Swing

Explicit interactor tree add – Must ensure interactor tree gets added in order to see anything. – Beginners get baffled.

Explicit interactor tree add – Must ensure interactor tree gets added in order to see anything. – Beginners get baffled. – Rating?

Explicit interactor tree add – Must ensure interactor tree gets added in order to see anything. – Beginners get baffled. – Rating: -2 for Visibility

Informative runtime errors • Incompatibilites with AWT addressed with quick exits and error printlns • Exception in thread "main" java. lang. Error: Do not use javax. swing. JFrame. set. Layout() use javax. swing. JFrame. get. Content. Pane(). set. Layout() instead

Informative runtime errors • Incompatibilites with AWT addressed with quick exits and error printlns • Exception in thread "main" java. lang. Error: Do not use javax. swing. JFrame. set. Layout() use javax. swing. JFrame. get. Content. Pane(). set. Layout() instead • Rating?

Informative runtime errors • Incompatibilites with AWT addressed with quick exits and error printlns • Exception in thread "main" java. lang. Error: Do not use javax. swing. JFrame. set. Layout() use javax. swing. JFrame. get. Content. Pane(). set. Layout() instead • Rating: +3 for Error recovery

Bad constructor abstractions + The Swing API keeps improving with abstractions such as the set. Default. Close. Operation method for the JFrame - However, several annoyances persist …

Bad constructor abstractions + The Swing API keeps improving with abstractions such as the set. Default. Close. Operation method for the JFrame - However, several annoyances persist … - Rating?

Bad constructor abstractions + The Swing API keeps improving with abstractions such as the set. Default. Close. Operation method for the JFrame - However, several annoyances persist … - Rating: -2 for Flexibility

Dependence on call order - Methods that depend on other certain actions to have been made need to be well documented

Dependence on call order - Methods that depend on other certain actions to have been made need to be well documented - What’s wrong with the following snippet? button. set. Bounds(10, 10, 10); frame. set. Visible(true); frame. get. Content. Pane(). add(button);

Dependence on call order - Methods that depend on other certain actions to have been made need to be well documented - What’s wrong with the following snippet? button. set. Bounds(10, 10, 10); frame. set. Visible(true); frame. get. Content. Pane(). add(button); Rating?

Dependence on call order - Methods that depend on other certain actions to have been made need to be well documented - What’s wrong with the following snippet? button. set. Bounds(10, 10, 10); frame. set. Visible(true); frame. get. Content. Pane(). add(button); Rating: -4 for Error prevention

Method call collisions - Some methods override each other - set. Size and pack - Javadoc says pack affects the size, but that’s more obscure; rename to pack. To. Preferred. Size perhaps

Method call collisions - Some methods override each other - set. Size and pack - Javadoc says pack affects the size, but that’s more obscure; rename to pack. To. Preferred. Size perhaps - Rating?

Method call collisions - Some methods override each other - set. Size and pack - Javadoc says pack affects the size, but that’s more obscure; rename to pack. To. Preferred. Size perhaps - Rating: -2 for Error prevention

A line for every attribute - Programming at the toolkit level implies an extra line of code for every attribute and pack - Tradeoff: attributes explicitly set, but hard to see the context … - set. Size

A line for every attribute - Programming at the toolkit level implies an extra line of code for every attribute and pack - Tradeoff: attributes explicitly set, but hard to see the context … - Rating? - set. Size

A line for every attribute - Programming at the toolkit level implies an extra line of code for every attribute and pack - Tradeoff: attributes explicitly set, but hard to see the context … - Rating: +3 for Aesthetics - set. Size

Other heuristics - Javadoc

Other heuristics - Javadoc

Other heuristics - Javadoc: +3 for Documentation

Other heuristics - Javadoc: +3 for Documentation - Language counterparts

Other heuristics - Javadoc: +3 for Documentation - Language counterparts: +4 for Match - Swing. Utilities. invoke. Later:

Other heuristics - Javadoc: +3 for Documentation Language counterparts: +4 for Match Swing. Utilities. invoke. Later: -2 for Error prevent Panes

Other heuristics - Javadoc: +3 for Documentation Language counterparts: +4 for Match Swing. Utilities. invoke. Later: -2 for Error prevent Panes: -1 for Consistency Layouts hard to author

Other heuristics - Javadoc: +3 for Documentation Language counterparts: +4 for Match Swing. Utilities. invoke. Later: -2 for Error prevent Panes: -1 for Consistency Layouts hard to author: -3 for User control

Summary • • • Visibility of system status (1 bad) Match of system & real world (1 good) User control and freedom (1 bad) Consistency and standards (1 bad) Error prevention (3 bad) Recognition rather than recall (not used) Flexibility and efficiency of use (1 bad) Aesthetic and minimalist design (1 good) Error recovery (1 good) Documentation and help (1 good)

Conclusion • Still not too bad • Object-oriented is the way to go • Can create a wide variety of GUIs