Re: [cross-project-issues-dev] Notes from a Heretic: Why do we have the

[Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>]

John Arthorne wrote:
>
> I guess this question comes down to whether we expect the EPP packages
> to satisfy the vast majority of users. Packages are like the /table
> d'hote/at a restaurant, whereas the Ganymede update site is like
> ordering /a la carte/.

I like the "table d'hote" (menu) verus "a la carte" metaphor.
Unfortunately, even with p2M6, there is no real "a la carte",
it is more like going to a supermaket, where you can
buy all the ingredients and some convenience food.
If you are lucky you select some "convenience food",
if you are unlucky you get some ingredients which make
so sense. If you are a cook you can get the right
ingredients and mixing them together to create some
tasteful food....

Ok, I don't want to stress the restaurant metaphor too much, but
I think, as of now we are missing a few things:

- Plugins and features coming from one update site
  are often related, therefore, the update sites should
  be represented in the update manager views as roots of the
  feature tree.

- There should be super-update sites: update sites that represent
  a set of update sites (instead of having either on update site
  for all or let users find the update site (exercise: use google
  and try to find the CDT update site)).

- Features are *technical* associations of plugins. Users need
  representation of what they want (something that fits to the user
  mental model). The packaging project shows quite nicely how this
  works. We have had a similar discrepancy between eclipse
  release numbers and the technical versions of plugins. Until
  eclipse 3.2, all plugins got the release version number
    http://www.eclipse.org/equinox/documents/plugin-versioning.html
  What is missing is a distinction of *user* features versus
  *technical* features. Some features make no sense to be installed
  on their own. Those are purely technical features. The packaging
  project is closer to *user* features but I think that the update
  manager should provide something at this level.

- Features should have an icon, explanation, web-page etc available
  from the update UI.
  It should be easy for the user to see the difference between
  "ingredients" and "convenience food".  Just think of an online
  supermarket, where you see a list of items they sell, with no
  additional information, but some facts from the "nutrition facts".
  Some of our "nutrition facts" are:
    APL, ARM, ATL, BATIK, BPEL, BPMN, DSDP, DSF, EMF, GEF, IP-XACT,
    JET, JST, JST, JVMTI, Jakarte, OCL, PDE, QVT, QVT, RSE, SCA,
    SDO, SOA, SVN, TPTP, WSDL, WST, XSD, Zest, Mint, log4j
  I wonder how many people on the list know *all* of the terms?
  And those are the terms that we expose to the eclipse users
  when choosing the Ganymede features... How can you expect get
  anything reasonable from such a shop????? I would go to a shop
  where I see a nice picture of the food I want to buy and a
  list of convenience food and maybe some suggestions what
  fits to my oder (like some dip with the chips I have chosen).

- The installation should distinguish between features and plugins
  installed for different reasons:
  - features a user has explicitly chosen
  - features that are pulled in by dependency
  I should only see the features I have installed and the implicit
  dependencies should be marked as implicit and when I uninstall
  a explicitly installed feature, the implicitly installed features
  should disappear.

- And features themselves should have a "tag" if they are user
  features or automatically installable features. In fact, I think
  features should only be there to allow the user to choose "roots"
  that are not picked up by automatic plugin dependency analysis...



Michael