2. Outline Modified rating scale Heuristic evaluation

3. 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

4. Heuristic Evaluation of Swing

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

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

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

9. 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

10. 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?

11. 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

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

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

15. 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

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

17. 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);

18. 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?

19. 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

20. 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

21. 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?

22. 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

23. 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 …

25. 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?

26. 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

27. Other heuristics -Javadoc

30. Other heuristics -Javadoc

31. Other heuristics -Javadoc: +3 for Documentation

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

33. Other heuristics -Javadoc: +3 for Documentation -Language counterparts: +4 for Match -SwingUtilities.invokeLater:

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

35. 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

36. 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

37. 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)

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