Difference between revisions of "Equinox p2 UIWG Walkthrough"

From Eclipsepedia

Jump to: navigation, search
(Discussion Topics)
Line 8: Line 8:
 
* [[Equinox p2 UM workflows]] shows the scenarios in the Eclipse Update Manager that were used to set goals for improving the user experience.
 
* [[Equinox p2 UM workflows]] shows the scenarios in the Eclipse Update Manager that were used to set goals for improving the user experience.
 
* [[Equinox p2 User Interface]] shows the same scenarios in the new p2 UI and compares aspects of the design to the UM design.
 
* [[Equinox p2 User Interface]] shows the same scenarios in the new p2 UI and compares aspects of the design to the UM design.
 +
* Detailed references
 +
** [[Equinox p2 UI Plan]]
 +
** [[Update Manager and p2 Compatibility]]
  
 
== Discussion Topics ==
 
== Discussion Topics ==
Line 26: Line 29:
 
* Other update UIs that are done well
 
* Other update UIs that are done well
  
== Detailed References ==  
+
== Discussion Notes from Walkthrough ==
* [[Equinox p2 UI Plan]]
+
(I didn't capture the names of who said what, and I'm sure I missed some things.  These are the points that I took away from the walkthrough, and I've annotated existing bug numbers for issues brought up where applicable).
* [[Update Manager and p2 Compatibility]]
+
 
 +
* The black and white icons for available software imply that you need to do something to enable them. 
 +
** If affordance is going to show installed vs. not installed, don't rely solely on color
 +
** We'll probably have affordances for more states so the icon should probably be the color one
 +
* Update manager hid a lot of the site management when searching for updates.  Putting repo management on user's shoulder through checkboxes is a step backward. 
 +
** We should show the user (in properties, tooltip, etc.) where something came from
 +
** If we retain that information, we could be smarter searching for updates so that user doesn't care
 +
* Current dialog should not be modal
 +
* Progress dialog on resolution can take a long time, it should not be blocking, needs to use background support
 +
* User is used to 4 different kinds of dialogs in Eclipse (status, selection, preferences, wizard) and the update dialog doesn't fall into any category.  Would moving the buttons around help with this?
 +
** Update Manager had wizard presentation, it was straightforward
 +
** Update Manager also had manage configuration dialog (different looking)
 +
** Would moving "Install..." to the bottom of available features page make it more familiar
 +
** Where would "Update..." and "Uninstall..." go
 +
* General discussion of organization of "Installed and Available"
 +
** Already inconsistencies (selection models are different)
 +
** Should one view lead to another?  User opens installed view and can push button to open available?
 +
** Is there interaction between these two?  Should they actually be shown together
 +
** 90% case is user just wants to check for updates of what they have.  Need fast way to do that which doesn't require seeing installed or available (ie...same behavior they get when automatic updating is on and they click on update affordance )
 +
* The differences in margins, spacing, button sizes make the UI look unpolished
 +
 
 +
 
  
  
 
[[Category:Equinox p2|UIWG Walthrough]]
 
[[Category:Equinox p2|UIWG Walthrough]]

Revision as of 15:31, 25 June 2008

Contents

p2 UI Walkthrough Eclipse UI Best Practices Working Group 6/25/2008

Prep/Homework

The discussion will be the most productive if the participants are already familiar with both the Eclipse Update Manager UI and the p2 UI.

Discussion Topics

  • Are we ready to tweak/fix problems in the current UI or do we need to step back and reexamine the overall organization and metaphor?
    • Is "browsing" vs. task-oriented "search" wizard a better metaphor for finding content (esp. given performance issues, user wait time)?
    • Does eliminating modality improve the metaphor?
    • Is the juxtaposition of "installed" and "available" working?
  • Known problem areas and possible solutions
    • How to integrate repo management into workflows
      • Presentation of large numbers of repositories for browsing
      • Selection of repositories for updating (solution might be to do smart picking for the user)
    • Unfolding of detail for installation contents
      • Balancing the simple view with more detail for advanced users
      • Is a tree view the best presentation for selectively exposing detail about the installed software?
  • Specific UI improvements that could be made (style-guide type issues: wording, button organization, etc.)
  • Other update UIs that are done well

Discussion Notes from Walkthrough

(I didn't capture the names of who said what, and I'm sure I missed some things. These are the points that I took away from the walkthrough, and I've annotated existing bug numbers for issues brought up where applicable).

  • The black and white icons for available software imply that you need to do something to enable them.
    • If affordance is going to show installed vs. not installed, don't rely solely on color
    • We'll probably have affordances for more states so the icon should probably be the color one
  • Update manager hid a lot of the site management when searching for updates. Putting repo management on user's shoulder through checkboxes is a step backward.
    • We should show the user (in properties, tooltip, etc.) where something came from
    • If we retain that information, we could be smarter searching for updates so that user doesn't care
  • Current dialog should not be modal
  • Progress dialog on resolution can take a long time, it should not be blocking, needs to use background support
  • User is used to 4 different kinds of dialogs in Eclipse (status, selection, preferences, wizard) and the update dialog doesn't fall into any category. Would moving the buttons around help with this?
    • Update Manager had wizard presentation, it was straightforward
    • Update Manager also had manage configuration dialog (different looking)
    • Would moving "Install..." to the bottom of available features page make it more familiar
    • Where would "Update..." and "Uninstall..." go
  • General discussion of organization of "Installed and Available"
    • Already inconsistencies (selection models are different)
    • Should one view lead to another? User opens installed view and can push button to open available?
    • Is there interaction between these two? Should they actually be shown together
    • 90% case is user just wants to check for updates of what they have. Need fast way to do that which doesn't require seeing installed or available (ie...same behavior they get when automatic updating is on and they click on update affordance )
  • The differences in margins, spacing, button sizes make the UI look unpolished