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
(Discussion topics)
Line 28: Line 28:
  
 
* Are the personas/use cases representative
 
* Are the personas/use cases representative
**Agreement that there is a wide range of user experience
+
**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)..?
 +
**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 idea of underlying features
+
**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 workflow will be more improved if we can deselect the things that don't resolve at a minimum and possibly explain the problem
 
**The workflow will be more improved if we can deselect the things that don't resolve at a minimum and possibly explain the problem
**The drilldown of info for what is installed is still an important thing lacking
+
**The drilldown of info for what is installed or being updated is still an important thing lacking
 
**Users are getting more detail than they need. For example, version numbering is way more detailed than many users care about  
 
**Users are getting more detail than they need. For example, version numbering is way more detailed than many users care about  
 +
 +
* Misc ideas
 +
**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
 +
* 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
 +
* 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
 +
  
  
 
== Some thoughts ==
 
== Some thoughts ==
 
There are fundamental conceptual issues that are making the update UI hard on the end user and they have more to do with how we are packaging things and the metadata we are generating than the actual workflows in the UI.
 
There are fundamental conceptual issues that are making the update UI hard on the end user and they have more to do with how we are packaging things and the metadata we are generating than the actual workflows in the UI.

Revision as of 14:31, 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)..?
    • 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 workflow will be more improved if we can deselect the things that don't resolve at a minimum and possibly explain the problem
    • The drilldown of info for what is installed or being updated is still an important thing lacking
    • Users are getting more detail than they need. For example, version numbering is way more detailed than many users care about
  • Misc ideas
    • 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
  • 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
  • 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


Some thoughts

There are fundamental conceptual issues that are making the update UI hard on the end user and they have more to do with how we are packaging things and the metadata we are generating than the actual workflows in the UI.

Back to the top