Jump to: navigation, search

Equinox/p2/UIWG Walkthrough 2

< Equinox‎ | p2
Revision as of 13:51, 1 October 2008 by Susan franklin.us.ibm.com (Talk | contribs) (Some thoughts)

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
    • 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
  • 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
    • Should install and update be collapsed into a single operation
      • See bug Bug 244872
      • Quick poll of what others thought, some agreement that they are indeed different
      • Tasks of easily/quickly upgrading what I have vs. looking for new stuff are different tasks and 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

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.

  • 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
    • Clearly the default feature-based metadata generation isn't helping to solve the same complexity users had with UM
    • Need something in the metadata that lets us "look up" at what's installed to help filter out things that don't matter