Outline

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 packaffects the size, but that’s more obscure; rename to packToPreferredSizeperhaps

21. Method call collisions • Some methods override each other • setSize and pack • Javadoc says packaffects the size, but that’s more obscure; rename to packToPreferredSizeperhaps • Rating?

22. Method call collisions • Some methods override each other • setSize and pack • Javadoc says packaffects the size, but that’s more obscure; rename to packToPreferredSizeperhaps • 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) • Recognitionrather 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