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 UI Use Cases"

(Please add your input about these or other personas)
Line 71: Line 71:
  
 
* In addition to Ellen, I'd like to add Arthur.  Arthur is our customer who has bought/acquired(!) our commercial RCP app.  He had to use NSIS to install it (something had to ensure he had a JRE and Bonjour) but after that he will never come back to our website to check for the latest version.  Instead, when updates are available, a small, unobtrusive dialogue box will appear.  If he chooses to 'Install updates', then without any further interaction his app will be incrementally updated (just the plugins which have changed, keeping the xfer size down) and restarted automatically.  The behaviour will be almost identical to the brilliant Sparkle framework available on the mac - no fuss, no confusion, just end user bliss...
 
* In addition to Ellen, I'd like to add Arthur.  Arthur is our customer who has bought/acquired(!) our commercial RCP app.  He had to use NSIS to install it (something had to ensure he had a JRE and Bonjour) but after that he will never come back to our website to check for the latest version.  Instead, when updates are available, a small, unobtrusive dialogue box will appear.  If he chooses to 'Install updates', then without any further interaction his app will be incrementally updated (just the plugins which have changed, keeping the xfer size down) and restarted automatically.  The behaviour will be almost identical to the brilliant Sparkle framework available on the mac - no fuss, no confusion, just end user bliss...
 +
===Please add your input about these or other personas===
 +
Please include your name and project so we can contact you for further information.  We're looking for input about missing users and tasks, or information to flesh out the existing personas.  Consider this a brainstorming area, we'll clean it up later.
 +
* [Joe Developer, Example Project Comment] - my users are like Ellen, except they aren't in a highly controlled environment.  But they don't care to know about the details of their installation and will generally update when told.
 +
* Mike Haller, Platform/RCP Application - our users are like Ellen, they are in a highly controlled environment and don't update until told. In half of the environments, they even have no permission to install updates on their local disk. Initial installation of a new feature using an update site or updates of existing features still require too many steps/clicks and looks complicated, which annoys Ellen. My Ellen is not required to know about local/archived/remote update sites, features and versions. The product used by my Ellen is built and released by Laurel :)
 +
 +
* In addition to Ellen, I'd like to add Arthur.  Arthur is our customer who has bought/acquired(!) our commercial RCP app.  He had to use NSIS to install it (something had to ensure he had a JRE and Bonjour) but after that he will never come back to our website to check for the latest version.  Instead, when updates are available, a small, unobtrusive dialogue box will appear.  If he chooses to 'Install updates', then without any further interaction his app will be incrementally updated (just the plugins which have changed, keeping the xfer size down) and restarted automatically.  The behaviour will be almost identical to the brilliant Sparkle framework available on the mac - no fuss, no confusion, just end user bliss...
 +
 +
*Miles Parker, PDE/Plugin Developer. (This is a recent and very typical user fro me.) Herbert is a developer and technologist (university researcher for example) who has experience in a broad variety of tools and platforms. He has used Eclipse a bit in the past, and may use JDT on a regular basis, but he has had a bad experience in the past w/ update experience. He does understand software imperfections and is not afraid to look under the hood. But he also has a level of expectation about how software should work. When something goes wrong, he wants to know why and what can be done about it; to be presented with all of the information he needs to know to diagnose an issue in a simple and orderly way. The challenge with Herbert is that he has limited time and a long memory. If he gets over aggravation threshold I'll lose him as potential user.  And of course for every user that requests help there are probably 5 who I'll never hear from. (One possible functional improvement that occurred to me is to have ability to send feedback to plugin developers on p2 issues so that we can get notified when failures occur.) Selected quotes from "Herbert":
 +
 +
"I'm setting this up on a [windows] box (which is just about the worst development platform on earth btw...thank God for a jvm and eclipse :) ) ... i do have an os x box, ubuntu linux, and solaris..running as well...  Thank you for the detail on Eclipse as i've yet to make a major switch to Ganymede;  I have an extensive Europa setup that i didn't want to goon.  Moreover, i'm used to....dumping features and plugins:  I'll have to wise up on the  new Ganymede install MO... "
 +
 +
Much later: "here's some quick notes on the install:..Use the Ganymede Discovery Site to install GMF, not the update site recommended by the GMF page --- dependency errors abound otherwise and you'll have no chance..Install [Dependency] using the archive option....their update site is vaporware at the moment..  [Dependency 2] -- initially reports "no update site found" then i refresh and it shows up...then eclipse crashed with some bs error...After a restart i get a single clean [My Plugin] folder that then installs flawlessly.The eclipse plugin manager is incredibly unstable and buggy; i've decided that i hate it at the moment :)"
 +
 +
I include the quotes *not* to pile on but to give some insight into user's debugging and evaluation process.
  
 
== Scenarios ==
 
== Scenarios ==

Revision as of 16:50, 18 August 2008

This page captures thoughts about the kinds of users using the Eclipse SDK p2 UI and the things these users are trying to do.

Background

One goal in building the Eclipse 3.4 p2 UI was to simplify the number of steps and concepts for a less technical user of Eclipse. We often called this user "the RCP app" user and were somewhat influenced by "Samantha," a design persona developed by Mary Beth Raven to use in the UI design for some Lotus products (see Lotus personas). We also often discussed "current UM users" - the more technical Eclipse SDK users who want to closely manage their configuration and want to know the detailed ramifications of a provisioning operation.

As we made design and implementation tradeoffs to meet the 3.4 schedule, it became rather cumbersome to discuss some of these tradeoffs given we had not developed a vocabulary for talking about these personas. (For an example of the swirl, see Bug 224472).

To that end, we'll develop some simple personas to use in discussing the various scenarios and problems/improvements. Rather than interviewing a sample user base, I'm using bug reports, mailing list traffic, walkthroughs, and other feedback to define these users initially, and I welcome any and all help to iterate on these. Note that I'm not focusing on the personal (age, hobbies) and background (education) info of the users initially. If there is interest in further developing these personas, by all means please contribute.

The personas are defined in terms of the Eclipse SDK and products built on top of the SDK. We realize that some RCP app users don't fit these definitions at all, and alternate UI's will be built where appropriate in certain product. The UI class libraries are being designed to support reuse of the building blocks and different levels of integration/composition. But that is a topic for another page...

Any similarity between the persona names and real Eclipse SDK users is completely coincidental

Eclipse SDK Personas

Steve

Steve is a power user of the Eclipse C++ and device tooling. He has intimate knowledge of underlying OS and device technology, and Eclipse is only one of many tools he is using in his job. (What others?) He does write the occasional bug report against Eclipse and keeps tabs on the availability of function that he cares about. He updates to new milestone builds when the new function appears, and he might even take an integration build or maintenance branch build in order to test or verify a bug report he cares about. He wants to keep things simple and does not routinely browse for new plug-ins, although he might add a plug-in that he read about if he felt it would help his day-to-day tasks. He doesn't really care how his Eclipse system is composed as long as the platform is performing well and he can provide the information needed in a bug report to help figure out a problem.

Things Steve needs to do regularly:

  • Check for updates when he hears of a bug fix or build he is interested in.
    • He is watching for different kinds of updates (milestone build, I-build, patch, etc.)
    • He needs to be able to quickly determine which update is important, needs to sift through what's available to find the specific one he wants.
  • Submit information in bug reports about exactly what version of Eclipse he is running

Things Steve does occasionally:

  • Install a plug-in he read about on the web

Karen

Karen is a committer on the Eclipse SDK project. She updates Eclipse to every integration build, and often takes nightly builds when needed for collaboration. She wants to have complete control over any additional bundle/plug-in being installed into her configuration. She has never used an update UI, preferring to unzip a clean build and copy her developer tools on top of the installation. She would like to switch over to using the p2 update technology for the good of the project, but doesn't quite trust it. She wants an easy way to configure her system from scratch.

Things Karen does regularly:

  • Download and unzip eclipse builds, run a script to install tools

Karen won't use the p2 UI until she can be sure she is able to control the exact set of bundles to be installed, and ideally this should be done in one simple step.

Laurel

Laurel is a developer of modeling products for Eclipse, using Eclipse Modeling Tools as a base for her work. She is an active participant in the Eclipse community, keeping up-to-date on release planning and being a vocal submitter and commenter in bugzilla. She prides herself on being among the first to try out a new release of a plug-in and blog about it. She frequently installs plug-ins to check them out, and has submitted several bugs against Update Manager (and p2) to help simplify tasks. She has a good working knowledge of the various Eclipse components and projects. While she is not too concerned with the underlying mechanics of the install (directory locations, etc.), she does want to know what components are being installed and why. For example, if she wanted to install a plug-in that required an upgrade to GEF, she would want to know this, because she's informed about the different versions and their impact on her environment.

Things Laurel does regularly:

  • Install new plug-ins found on the web
    • She wishes she could do this in one step rather than Add Site, Browse, Install
  • Check for updates to what she has
    • She wants to check for updates to underlying components, not just the things explicitly installed
  • Uninstall plug-ins after trying them out
  • She rarely restarts Eclipse after an install or uninstall because she does it so often

Dave

Dave is an IT specialist in charge of internal deployment of a commercial product based on the Eclipse SDK. He wants to try out any and all updates or add-ons to the Eclipse environment before deciding whether to deploy them. He is conservative in deploying new functionality. He currently supports three different configurations of the product, based on his user's day to day work. He maintains an internal update repository for deploying approved Eclipse updates, patches, or add-ons. It is vital that Dave can configure the product so that users cannot update or add plug-ins from any other sources. He configures Eclipse to use automatic updating. Most of Dave's users aren't familiar with the Eclipse community. Those that are sometimes install and maintain their own Eclipse SDK, but Dave does not support these installs and generally discourages it.

Things Dave does regularly:

  • Debugs problems in user installs, relying on configuration information from the platform
  • Needs to quickly identify which configuration a user is using, which updates they applied

Things Dave does occasionally:

  • Evaluates new plug-ins for inclusion in the standard installation
    • Add update sites found on the web
    • Downloads software into staging sites for internal test installs (rather than installing from external sites)

Ellen

Ellen is one of Dave's users. She uses a product based on the Eclipse SDK and doesn't have any idea what Eclipse is. She updates her software when instructed to and otherwise doesn't care about the composition of her product.

Things Ellen does occasionally:

  • When Ellen receives an update notification, she clicks the popup and updates the software, but only if she has seen an announcement from Dave that an update is available and should be installed.
  • If Ellen has a problem with her software, she contacts support. She needs to be able to communicate what versions of things are installed in a way that will make sense to Dave.

Please add your input about these or other personas

Please include your name and project so we can contact you for further information. We're looking for input about missing users and tasks, or information to flesh out the existing personas. Consider this a brainstorming area, we'll clean it up later.

  • [Joe Developer, Example Project Comment] - my users are like Ellen, except they aren't in a highly controlled environment. But they don't care to know about the details of their installation and will generally update when told.
  • Mike Haller, Platform/RCP Application - our users are like Ellen, they are in a highly controlled environment and don't update until told. In half of the environments, they even have no permission to install updates on their local disk. Initial installation of a new feature using an update site or updates of existing features still require too many steps/clicks and looks complicated, which annoys Ellen. My Ellen is not required to know about local/archived/remote update sites, features and versions. The product used by my Ellen is built and released by Laurel :)
  • In addition to Ellen, I'd like to add Arthur. Arthur is our customer who has bought/acquired(!) our commercial RCP app. He had to use NSIS to install it (something had to ensure he had a JRE and Bonjour) but after that he will never come back to our website to check for the latest version. Instead, when updates are available, a small, unobtrusive dialogue box will appear. If he chooses to 'Install updates', then without any further interaction his app will be incrementally updated (just the plugins which have changed, keeping the xfer size down) and restarted automatically. The behaviour will be almost identical to the brilliant Sparkle framework available on the mac - no fuss, no confusion, just end user bliss...

Please add your input about these or other personas

Please include your name and project so we can contact you for further information. We're looking for input about missing users and tasks, or information to flesh out the existing personas. Consider this a brainstorming area, we'll clean it up later.

  • [Joe Developer, Example Project Comment] - my users are like Ellen, except they aren't in a highly controlled environment. But they don't care to know about the details of their installation and will generally update when told.
  • Mike Haller, Platform/RCP Application - our users are like Ellen, they are in a highly controlled environment and don't update until told. In half of the environments, they even have no permission to install updates on their local disk. Initial installation of a new feature using an update site or updates of existing features still require too many steps/clicks and looks complicated, which annoys Ellen. My Ellen is not required to know about local/archived/remote update sites, features and versions. The product used by my Ellen is built and released by Laurel :)
  • In addition to Ellen, I'd like to add Arthur. Arthur is our customer who has bought/acquired(!) our commercial RCP app. He had to use NSIS to install it (something had to ensure he had a JRE and Bonjour) but after that he will never come back to our website to check for the latest version. Instead, when updates are available, a small, unobtrusive dialogue box will appear. If he chooses to 'Install updates', then without any further interaction his app will be incrementally updated (just the plugins which have changed, keeping the xfer size down) and restarted automatically. The behaviour will be almost identical to the brilliant Sparkle framework available on the mac - no fuss, no confusion, just end user bliss...
  • Miles Parker, PDE/Plugin Developer. (This is a recent and very typical user fro me.) Herbert is a developer and technologist (university researcher for example) who has experience in a broad variety of tools and platforms. He has used Eclipse a bit in the past, and may use JDT on a regular basis, but he has had a bad experience in the past w/ update experience. He does understand software imperfections and is not afraid to look under the hood. But he also has a level of expectation about how software should work. When something goes wrong, he wants to know why and what can be done about it; to be presented with all of the information he needs to know to diagnose an issue in a simple and orderly way. The challenge with Herbert is that he has limited time and a long memory. If he gets over aggravation threshold I'll lose him as potential user. And of course for every user that requests help there are probably 5 who I'll never hear from. (One possible functional improvement that occurred to me is to have ability to send feedback to plugin developers on p2 issues so that we can get notified when failures occur.) Selected quotes from "Herbert":

"I'm setting this up on a [windows] box (which is just about the worst development platform on earth btw...thank God for a jvm and eclipse :) ) ... i do have an os x box, ubuntu linux, and solaris..running as well... Thank you for the detail on Eclipse as i've yet to make a major switch to Ganymede; I have an extensive Europa setup that i didn't want to goon. Moreover, i'm used to....dumping features and plugins: I'll have to wise up on the new Ganymede install MO... "

Much later: "here's some quick notes on the install:..Use the Ganymede Discovery Site to install GMF, not the update site recommended by the GMF page --- dependency errors abound otherwise and you'll have no chance..Install [Dependency] using the archive option....their update site is vaporware at the moment.. [Dependency 2] -- initially reports "no update site found" then i refresh and it shows up...then eclipse crashed with some bs error...After a restart i get a single clean [My Plugin] folder that then installs flawlessly.The eclipse plugin manager is incredibly unstable and buggy; i've decided that i hate it at the moment :)"

I include the quotes *not* to pile on but to give some insight into user's debugging and evaluation process.

Scenarios

These are old 3.4 scenarios brought forward from Equinox p2 User Interface. These will be rewritten/reorganized based on input about the users.

Scenario 1: Check for updates of current system

Frequency and type of update is different for different users

Scenario 2: Browsing for cool add-ons using the Eclipse Update UI

How often does this really happen?

Scenario 3: Found something cool on the web to install into Eclipse

Scenario 4: What do I have?

(Needs to be fleshed into more scenarios...why am I wondering what I have? Is there a configuration problem? Do I need disk space? Do I need detail about a specific subcomponent?)

Scenario 5: Unobtrusive automatic updating

Scenario 6: Something is screwed up after updating or installing something

(Depending on the user, this might map to revert, or uninstall, or debug the actual problem, or start from scratch...need to consider different personas)

Back to the top