Outline

1
(No Transcript)
2
Outline

• Modified rating scale
• Heuristic evaluation

3
Modified rating scale

• -4 usability catastropheimperative to fix
  before
• -3 major usability problemimportant to fix
• -2 minor usability problemlow priority
• -1 cosmetic problem onlyneed 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.

6
(No Transcript)
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

13
(No Transcript)
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
• Whats 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
• Whats 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
• Whats 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 thats
  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 thats
  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 thats
  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

24
(No Transcript)
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

28
(No Transcript)
29
(No Transcript)
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