Equinox/p2/UIWG Walkthrough 2

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

• Step back and attempt to define user personas, solicit community input
  • Equinox p2 UI Use Cases
• Draw conclusions based on these personas and workflows
• Develop mockups addressing these concerns
  • Equinox p2 UI 3.5 workflows

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