1 / 38

Heuristic Evaluation of Swing Explicit Interactor Tree Add

This heuristic evaluation assesses the Swing Explicit Interactor Tree Add feature, highlighting usability problems and errors, and suggesting improvements for better user experience.

agoldberg
Download Presentation

Heuristic Evaluation of Swing Explicit Interactor Tree Add

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Outline • Modified rating scale • Heuristic evaluation

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

  3. Heuristic Evaluation of Swing

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

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

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

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

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

  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 • Rating: +3 for Error recovery

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

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

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

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

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

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

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

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

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

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

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

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

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

  23. Other heuristics • Javadoc

  24. Other heuristics • Javadoc

  25. Other heuristics • Javadoc: +3 for Documentation

  26. Other heuristics • Javadoc: +3 for Documentation • Language counterparts

  27. Other heuristics • Javadoc: +3 for Documentation • Language counterparts: +4 for Match • SwingUtilities.invokeLater:

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

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

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

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

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

More Related