slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Outline PowerPoint Presentation
Download Presentation
Outline

Loading in 2 Seconds...

play fullscreen
1 / 38

Outline - PowerPoint PPT Presentation


  • 58 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Outline' - prince


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
outline
Outline
  • Modified rating scale
  • Heuristic evaluation
modified rating scale
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
explicit interactor tree add
Explicit interactor tree add
  • Must ensure interactor tree gets added in order to see anything.
  • Beginners get baffled.
explicit interactor tree add1
Explicit interactor tree add
  • Must ensure interactor tree gets added in order to see anything.
  • Beginners get baffled.
  • Rating?
explicit interactor tree add2
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
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 errors1
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 errors2
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
Bad constructor abstractions
  • The Swing API keeps improving with abstractions such as the setDefaultCloseOperation method for the JFrame
  • However, several annoyances persist …
bad constructor abstractions1
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 abstractions2
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
Dependence on call order
  • Methods that depend on other certain actions to have been made need to be well documented
dependence on call order1
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 order2
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 order3
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
Method call collisions
  • Some methods override each other
  • setSize and pack
  • Javadoc says packaffects the size, but that’s more obscure; rename to packToPreferredSizeperhaps
method call collisions1
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?
method call collisions2
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
a line for every attribute
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 attribute1
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 attribute2
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 heuristics2
Other heuristics
  • Javadoc: +3 for Documentation
other heuristics3
Other heuristics
  • Javadoc: +3 for Documentation
  • Language counterparts
other heuristics4
Other heuristics
  • Javadoc: +3 for Documentation
  • Language counterparts: +4 for Match
  • SwingUtilities.invokeLater:
other heuristics5
Other heuristics
  • Javadoc: +3 for Documentation
  • Language counterparts: +4 for Match
  • SwingUtilities.invokeLater: -2 for Error prevent
  • Panes
other heuristics6
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 heuristics7
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
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)
conclusion
Conclusion
  • Still not too bad
  • Object-oriented is the way to go
  • Can create a wide variety of GUIs