Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox p2 UIWG Walkthrough"
(→Discussion Notes from Walkthrough) |
(→Discussion Notes from Walkthrough) |
||
| Line 36: | Line 36: | ||
** We'll probably have affordances for more states so the icon should probably be the color one | ** 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. It knew where to look. Putting repo management on user's shoulder through checkboxes is a step backward. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=234213 Bug 234213] | * Update manager hid a lot of the site management when searching for updates. It knew where to look. Putting repo management on user's shoulder through checkboxes is a step backward. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=234213 Bug 234213] | ||
| − | ** | + | ** Install view should show the user (in properties, tooltip, etc.) what site something originally came from so they'd know where to look for updates |
| − | ** If we retain that | + | ** If we retain that relationship (today we don't), we could be smarter searching for updates so that user doesn't need to know at all |
* Things that can take quite some time are modal and prevent user from working | * Things that can take quite some time are modal and prevent user from working | ||
** Software Updates... dialog should not be modal [https://bugs.eclipse.org/bugs/show_bug.cgi?id=221755 Bug 221755] | ** Software Updates... dialog should not be modal [https://bugs.eclipse.org/bugs/show_bug.cgi?id=221755 Bug 221755] | ||
** Progress dialog after clicking Install... can take a long time, it should not be blocking. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=236495 Bug 236495] | ** Progress dialog after clicking Install... can take a long time, it should not be blocking. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=236495 Bug 236495] | ||
| − | * User is used to 4 different kinds of dialogs in Eclipse (status, selection, preferences, wizard) | + | * User is used to 4 different kinds of dialogs in Eclipse (status, selection, preferences, wizard) with well-known button locations. The update dialog doesn't fall into any category, so user doesn't know what to do. |
| − | ** Update Manager had wizard presentation, it was straightforward | + | ** User expected that checking boxes and selecting "Close..." would have retained selections so they could open dialog again and perform the install [https://bugs.eclipse.org/bugs/show_bug.cgi?id=235288 Bug 235288] |
| + | ** 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) | ** Update Manager also had manage configuration dialog (different looking) | ||
| − | ** Would moving "Install..." to the bottom of available features page make it more familiar | + | ** Would moving "Install..." to the bottom of available features page make it more familiar, or having an "Apply" Button |
** Where would "Update..." and "Uninstall..." go | ** Where would "Update..." and "Uninstall..." go | ||
| + | ** Consider integrating a task list so user can perform actions (install, uninstall, update) that get added to a task list and then one push of "Apply" button will do what they wanted | ||
* General discussion of organization of "Installed and Available" | * General discussion of organization of "Installed and Available" | ||
| − | ** | + | ** There are inconsistencies in these views (standard selection vs. check selection, etc.) |
| − | ** Should one view lead to another? User opens installed view and can push button to open available? | + | ** Should one view lead to another? User opens installed view and can push button to open detail about what's available? |
| − | ** | + | ** Why isn't the information in Help>About integrated into the install view? |
| + | ** Should Installed and Available 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 ) | ** 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 ) | ||
| + | ** Consider an advanced, full-fledged view that shows everything integrated (installed, what's available, etc.) and lets user filter many different ways | ||
| + | *** Lots of ways to filter, for example just see maintenance updates vs. major releases | ||
* The differences in margins, spacing, button sizes make the UI look unpolished | * The differences in margins, spacing, button sizes make the UI look unpolished | ||
Revision as of 15:54, 25 June 2008
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.
- 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.
- Detailed references
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?
- How to integrate repo management into workflows
- 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. Bug 210583
- If affordance is going to show installed vs. not installed, don't rely solely on color Bug 216032
- 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. It knew where to look. Putting repo management on user's shoulder through checkboxes is a step backward. Bug 234213
- Install view should show the user (in properties, tooltip, etc.) what site something originally came from so they'd know where to look for updates
- If we retain that relationship (today we don't), we could be smarter searching for updates so that user doesn't need to know at all
- Things that can take quite some time are modal and prevent user from working
- Software Updates... dialog should not be modal Bug 221755
- Progress dialog after clicking Install... can take a long time, it should not be blocking. Bug 236495
- User is used to 4 different kinds of dialogs in Eclipse (status, selection, preferences, wizard) with well-known button locations. The update dialog doesn't fall into any category, so user doesn't know what to do.
- User expected that checking boxes and selecting "Close..." would have retained selections so they could open dialog again and perform the install Bug 235288
- 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, or having an "Apply" Button
- Where would "Update..." and "Uninstall..." go
- Consider integrating a task list so user can perform actions (install, uninstall, update) that get added to a task list and then one push of "Apply" button will do what they wanted
- General discussion of organization of "Installed and Available"
- There are inconsistencies in these views (standard selection vs. check selection, etc.)
- Should one view lead to another? User opens installed view and can push button to open detail about what's available?
- Why isn't the information in Help>About integrated into the install view?
- Should Installed and Available 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 )
- Consider an advanced, full-fledged view that shows everything integrated (installed, what's available, etc.) and lets user filter many different ways
- Lots of ways to filter, for example just see maintenance updates vs. major releases
- The differences in margins, spacing, button sizes make the UI look unpolished