Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Equinox/p2/UIWG Walkthrough 2"

< Equinox‎ | p2
(To do's)
 
(6 intermediate revisions by the same user not shown)
Line 27: Line 27:
 
Same disclaimers as last time.  I didn't capture the names of who said what, and I'm sure I missed some things.  The discussion was fast and furious and I tended to jot the things down that were new to me or captured a new angle on something.  I'm sure I overlooked some important things, please help me fill them in.  I've grouped comments underneath the agenda items where it fit even though the discussion didn't really follow this format
 
Same disclaimers as last time.  I didn't capture the names of who said what, and I'm sure I missed some things.  The discussion was fast and furious and I tended to jot the things down that were new to me or captured a new angle on something.  I'm sure I overlooked some important things, please help me fill them in.  I've grouped comments underneath the agenda items where it fit even though the discussion didn't really follow this format
  
* Are the personas/use cases representative
+
=== Are the personas/use cases representative ===
**Agreement that there is a wide range of user experience, especially the RCP user (Ellen) who just wants to update what she has vs. the low level user (Laurel or Dave)..?
+
*Agreement that there is a wide range of user experience, especially the RCP user (Ellen) who just wants to update what she has vs. the low level user (Laurel or Dave)..?
***Linux update tools represent this difference - simple "one click" tools that simply upgrade everything vs. the more detailed package management software
+
**Linux update tools represent this difference - simple "one click" tools that simply upgrade everything vs. the more detailed package management software
**We noticed we weren't using the persona names and our discussions of "the RCP user," "the advanced user" again showed us that we need a better vocabularly
+
*We noticed we weren't using the persona names and our discussions of "the RCP user," "the advanced user" again showed us that we need a better vocabularly
**One of the biggest problems is that different products based on Eclipse have different user models of what "the product" is.  So this needs to be captured in the personas.  Do I have an SDK?  Do I have Ganymede?  And this info needs to flow through the use cases, and for different users the level of detail is different
+
*One of the biggest problems is that different products based on Eclipse have different user models of what "the product" is.  So this needs to be captured in the personas.  Do I have an SDK?  Do I have Ganymede?  And this info needs to flow through the use cases, and for different users the level of detail is different
**Novice just wants to update what they have, simple version numbering, no concern with "the overwhelming number of features" that comprise their product
+
*Novice just wants to update what they have, simple version numbering, no concern with "the overwhelming number of features" that comprise their product
  
* Are the new workflows better and for whom?
+
=== Are the new workflows better and for whom? ===
**There was some agreement that the "install new software..." workflow is improved by virtue of being able to go back after you resolve and change what you want to get
+
*There was some agreement that the "install new software..." workflow is improved by virtue of being able to go back after you resolve and change what you want to get
**The install and update workflows will be more improved if we can deselect the things that don't resolve at a minimum and possibly explain the problem.  It's a regression that we don't at least mark the problematic IU's (update manager did this)
+
*The install and update workflows will be more improved if we can deselect the things that don't resolve at a minimum and possibly explain the problem.  It's a regression that we don't at least mark the problematic IU's (update manager did this)
**The drilldown into more detail for what is installed or being updated is still an important thing lacking ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=224472 Bug 224472])
+
*The drilldown into more detail for what is installed or being updated is still an important thing lacking ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=224472 Bug 224472])
**However, users are getting more detail than they need. For example, version numbering is way more detailed than many users care about  
+
*However, users are getting more detail than they need. For example, version numbering is way more detailed than many users care about  
 +
*For the casual user, the relationships between things they are installing and the requirements are hard to understand and force them to understand too much implementation detail.  This is more than just a workflow issue, step back and consider the user's mental model of the system and how things are being presented to them
  
* Misc ideas
+
=== Misc. discussion ===
**MS Office Installer does a reasonable job of negotiating the problem of different product configurations and letting users see their view of what they are installing, and drill down into detail as needed
+
*MS Office Installer does a reasonable job of negotiating the problem of different product configurations and letting users see their view of what they are installing, and drill down into detail as needed
**Should install and update be collapsed into a single operation
+
*Why are install and update considered separate operations
***See bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=244872 Bug 244872]
+
**See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=244872 Bug 244872]
***Quick poll of what others thought, some agreement that they are indeed different
+
**Quick poll of what others thought, those who commented said they see them as different
***Tasks of easily/quickly upgrading what I have vs. looking for new stuff are different tasks and users
+
**Tasks of easily/quickly upgrading what I have vs. looking for new stuff are different tasks and different users
***Problem may be how to identify what is an update, may be different in different user models/install scenarios (see also [https://bugs.eclipse.org/bugs/show_bug.cgi?id=245299 Bug 245299])
+
**Problem may be how to identify what is an update, may be different in different user models/install scenarios (see also [https://bugs.eclipse.org/bugs/show_bug.cgi?id=245299 Bug 245299])
** Users may not really care about sites, but right now sites are the only way to group things that relate to each other.  So if there is a better mechanism in p2, what is it?  If there is not, then the site view is still important
+
* Users may not really care about sites, but right now sites are the only way to group things that relate to each other.  So if there is a better mechanism in p2, what is it?  If there is not, then the site view is still important
** Is there a way for product configurators to plug-in their own view of the world as far as what a user sees in the sites and what they are updating/installing (yes, see IQueryProvider in the current code, this is evolving right now).  The idea is you can define your own taxonomy and still use the basic UI components
+
* Is there a way for product configurators to plug-in their own view of the world as far as what a user sees in the sites and what they are updating/installing (yes, see IQueryProvider in the current code, this is evolving right now).  The idea is you can define your own taxonomy and still use the basic UI components
** Need a better way to filter out available software that doesn't apply.  I don't need the Mylyn C++ bridge if I don't have C++, but a novice user might select "all things Mylyn" and then drag in part of the C++ environment by accident.  This isn't just a "show me the requirements/dependencies" issues.  We need a way for the metadata to describe that Foo is not important if Bar is not installed.   
+
* Need a better way to filter out available software that doesn't apply.  I don't need the Mylyn C++ bridge if I don't have C++, but a novice user might select "all things Mylyn" and then drag in part of the C++ environment by accident.  This isn't just a "show me the requirements/dependencies" issues.  We need a way for the metadata to describe that Foo is not important if Bar is not installed.   
*** Today p2 can resolve an installation into a "technically perfectly correct" install as far as requirements go, but the user ends up with half of a C++ environment tacked onto their IDE when all they wanted was Mylyn
+
** Today p2 can resolve an installation into a "technically perfectly correct" install as far as requirements go, but the user ends up with half of a C++ environment tacked onto their IDE when all they wanted was Mylyn
 +
 
 +
=== Other discussion points ===
 +
 
 +
Notes from others attending the meeting that I missed.  Please include here and I'll try to fold them back in to the summary
  
 
== Some thoughts ==
 
== Some thoughts ==
Line 57: Line 62:
 
** We should give product configurators a way to specify the install roots at build time so this matches up with their site views of the world
 
** We should give product configurators a way to specify the install roots at build time so this matches up with their site views of the world
 
* Feature-based metadata generation isn't helping to solve the same complexity users had with UM features
 
* Feature-based metadata generation isn't helping to solve the same complexity users had with UM features
 
__TOC__
 
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 UI 3.4 workflows]] 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 ==
 
* 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.  [https://bugs.eclipse.org/bugs/show_bug.cgi?id=210583 Bug 210583]
 
** If affordance is going to show installed vs. not installed, don't rely solely on color [https://bugs.eclipse.org/bugs/show_bug.cgi?id=216032 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.  [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 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 [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]
 
* 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 [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)
 
** 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".  Does user know what to do?
 
** 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?
 
** Does user really care to see these together?  Aren't the kinds of things you do with your installation different than when you are looking for stuff?
 
** Why isn't the information in Help>About integrated into the install view? [https://bugs.eclipse.org/bugs/show_bug.cgi?id=224472 Bug 224472]
 
** 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 with view buttons across the top
 
*** Show only what's installed, or only updates, or everything
 
*** Lots of ways to filter, for example just see service level/maintenance updates vs. major releases
 
* The differences in margins, spacing, button sizes make the UI look unpolished
 
 
== Conclusions/To-do's ==
 
* A one-hour walkthrough is often only enough time to surface the important questions
 
* Consider coming back to discuss specific issues now that participants have context
 
* Work on mock-ups/proposals that address the issue of overall organization (what tasks is user doing and what do they need to see to do them?)  Post to wiki when available and contact UIWG to revisit issue.  Ideas include:
 
** Separate installed and available view and layer them.  For example, installed view that expands into view of what's available
 
** Fast path for simple case (check for updates...)
 
** Merge the installed/available view into one view that allows filtering
 
 
The examination of these workflow issues is being tracked by [https://bugs.eclipse.org/bugs/show_bug.cgi?id=236740 Bug 236740], but design discussions and ideas will be captured in [[Equinox p2 UI Use Cases]].
 
 
== Other thoughts ==
 
 
Notes from others attending the meeting that I missed.  Please include here and I'll try to fold them back in to the summary if it makes sense.
 
  
 
== To do's ==
 
== To do's ==
*Attendees will leave their feedback in the discussion of the wiki page for the workflows
+
*Attendees will leave their feedback in the [[Talk:Equinox_p2_UI_3.5_workflows | Discussion page]] for the workflows
 
*We may come back to UIWG again, depends on how much progress we can make off-line
 
*We may come back to UIWG again, depends on how much progress we can make off-line

Latest revision as of 16:51, 1 October 2008

p2 UI Walkthrough Eclipse UI Best Practices Working Group 10/2/2008

The discussion will be the most productive if the participants are already familiar with the p2 UI and issues discussed at the last walkthrough (p2 UIWG First Walkthrough).

To-do's from last walkthrough

  • Work on mock-ups/proposals that address the issue of overall organization (what tasks is user doing and what do they need to see to do them?) Post to wiki when available and contact UIWG to revisit issue. Ideas include:
    • Separate installed and available view and layer them. For example, installed view that expands into view of what's available
    • Fast path for simple case (check for updates...)
    • Merge the installed/available view into one view that allows filtering

What we've done since then

Discussion topics

  • Are the personas representative (note we are not attempting to define personas during the call, but rather determine if more work is needed and how to get better input)
  • Are the conclusions reasonable
  • Are the new workflows better and for whom?

Notes from the meeting

Same disclaimers as last time. I didn't capture the names of who said what, and I'm sure I missed some things. The discussion was fast and furious and I tended to jot the things down that were new to me or captured a new angle on something. I'm sure I overlooked some important things, please help me fill them in. I've grouped comments underneath the agenda items where it fit even though the discussion didn't really follow this format

Are the personas/use cases representative

  • Agreement that there is a wide range of user experience, especially the RCP user (Ellen) who just wants to update what she has vs. the low level user (Laurel or Dave)..?
    • Linux update tools represent this difference - simple "one click" tools that simply upgrade everything vs. the more detailed package management software
  • We noticed we weren't using the persona names and our discussions of "the RCP user," "the advanced user" again showed us that we need a better vocabularly
  • One of the biggest problems is that different products based on Eclipse have different user models of what "the product" is. So this needs to be captured in the personas. Do I have an SDK? Do I have Ganymede? And this info needs to flow through the use cases, and for different users the level of detail is different
  • Novice just wants to update what they have, simple version numbering, no concern with "the overwhelming number of features" that comprise their product

Are the new workflows better and for whom?

  • There was some agreement that the "install new software..." workflow is improved by virtue of being able to go back after you resolve and change what you want to get
  • The install and update workflows will be more improved if we can deselect the things that don't resolve at a minimum and possibly explain the problem. It's a regression that we don't at least mark the problematic IU's (update manager did this)
  • The drilldown into more detail for what is installed or being updated is still an important thing lacking (Bug 224472)
  • However, users are getting more detail than they need. For example, version numbering is way more detailed than many users care about
  • For the casual user, the relationships between things they are installing and the requirements are hard to understand and force them to understand too much implementation detail. This is more than just a workflow issue, step back and consider the user's mental model of the system and how things are being presented to them

Misc. discussion

  • MS Office Installer does a reasonable job of negotiating the problem of different product configurations and letting users see their view of what they are installing, and drill down into detail as needed
  • Why are install and update considered separate operations
    • See Bug 244872
    • Quick poll of what others thought, those who commented said they see them as different
    • Tasks of easily/quickly upgrading what I have vs. looking for new stuff are different tasks and different users
    • Problem may be how to identify what is an update, may be different in different user models/install scenarios (see also Bug 245299)
  • Users may not really care about sites, but right now sites are the only way to group things that relate to each other. So if there is a better mechanism in p2, what is it? If there is not, then the site view is still important
  • Is there a way for product configurators to plug-in their own view of the world as far as what a user sees in the sites and what they are updating/installing (yes, see IQueryProvider in the current code, this is evolving right now). The idea is you can define your own taxonomy and still use the basic UI components
  • Need a better way to filter out available software that doesn't apply. I don't need the Mylyn C++ bridge if I don't have C++, but a novice user might select "all things Mylyn" and then drag in part of the C++ environment by accident. This isn't just a "show me the requirements/dependencies" issues. We need a way for the metadata to describe that Foo is not important if Bar is not installed.
    • Today p2 can resolve an installation into a "technically perfectly correct" install as far as requirements go, but the user ends up with half of a C++ environment tacked onto their IDE when all they wanted was Mylyn

Other discussion points

Notes from others attending the meeting that I missed. Please include here and I'll try to fold them back in to the summary

Some thoughts

There is plenty of improvement to be made in the UI, but there are also fundamental issues in how we package things, how we generate metadata, the sites we build, etc. that make things hard on the end user.

  • Why is Eclipse SDK in my Installed Software view when the sites I'm connected to don't even show an Eclipse SDK?
    • We should give product configurators a way to specify the install roots at build time so this matches up with their site views of the world
  • Feature-based metadata generation isn't helping to solve the same complexity users had with UM features

To do's

  • Attendees will leave their feedback in the Discussion page for the workflows
  • We may come back to UIWG again, depends on how much progress we can make off-line

Back to the top