Outline Modified rating scale Heuristic evaluation

Modified rating scale -4:usability catastrophe—imperative to fix before -3:major usability problem–important to fix -2:minor usability problem–low priority -1:cosmetic problem only–need not be fixed 0:not a real usability problem or merit +1:cosmetic merit +2:minor usability merit +3:major usability merit +4: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.setLayout() use javax. swing.JFrame.getContentPane().setLayout() 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.setLayout() use javax. swing.JFrame.getContentPane().setLayout() 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.setLayout() use javax. swing.JFrame.getContentPane().setLayout() instead Rating: +3 for Error recovery

Bad constructor abstractions +The Swing API keeps improving with abstractions such as the setDefaultCloseOperation method for the JFrame -However, several annoyances persist …

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

Bad constructor abstractions +The Swing API keeps improving with abstractions such as the setDefaultCloseOperation 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.setBounds(10, 10, 10, 10); frame.setVisible(true); frame.getContentPane().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.setBounds(10, 10, 10, 10); frame.setVisible(true); frame.getContentPane().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.setBounds(10, 10, 10, 10); frame.setVisible(true); frame.getContentPane().add(button); Rating: -4 for Error prevention

Method call collisions -Some methods override each other -setSize and pack -Javadoc says pack affects the size, but that’s more obscure; rename to packToPreferredSize perhaps

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

Method call collisions -Some methods override each other -setSize and pack -Javadoc says pack affects the size, but that’s more obscure; rename to packToPreferredSize 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 -setSize and pack -Tradeoff: attributes explicitly set, but hard to see the context …

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

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

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 -SwingUtilities.invokeLater:

Other heuristics -Javadoc: +3 for Documentation -Language counterparts: +4 for Match -SwingUtilities.invokeLater: -2 for Error prevent -Panes

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

Other heuristics -Javadoc: +3 for Documentation -Language counterparts: +4 for Match -SwingUtilities.invokeLater: -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