Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Improving Project UIs for Ganymede

Although I agree with the general desire (shared by all projects, I think) to find ways to improve the overall UI/user experience when using the simultaneous release, particularly at the intersection of projects, I think I need to point out that mandating a UI checklist without providing any resources (via foundation, membership or wherever) to help address these issues effectively disfavors participation by smaller and newer projects.  It makes it more difficult for them to get distribution through participation in Ganymede, and subsequent simultaneous releases, and therefore adoption.

The projects that are already resource 'rich' (i.e. those run/controlled by respective corp members...I know...I know...they don't feel rich) will have relatively little difficulty meeting these goals (at least as they are now), and their representation on the Board and enforcement policy is already clear.  OTOH, the small projects, in many cases independently run, will have relatively little ability to a) participate in setting the guidelines; b) doing the design and other UI work necessary to meet the requirements; c) monitoring other projects for overlap, inconsistency, etc.; d) performing the other work needed for ganymede participation, etc.


Ed Merks wrote:

I agree with everything you said, except for the comment that goodwill has
not been working well.   I believe that goodwill is the fundamental force
that drives our community forward and that it's coercion that has the
scalability problems.  Consider the implication of Kevin's concern about
the value of checklist enforcement relative to its cost as evidence of
that.  The fact that we haven't achieved perfection to date is not an
indication that goodwill is not working well and it should be clear that we
will get no further in our process improvements without a significant
supply of goodwill from the Ganymede participants.  Maybe I'm the
particularly stubborn sort, but I refuse to be coerced and bristle at the
first signs of it.  The foundation doesn't fund us to work specifically on
usability improvements and ought not to give the appearance of attempting
to coerce that.  Sorry Mike, I 'm not implying you didn't act with the
community's best interests at heart...

So forget the dictates from above and let's just put goodwill into action.
The idea of having UI reviews with our peers---open reviews to which all
are invited---led by a few gifted experts, would seem like a really cool
thing.  It would give many of us a chance to see projects in action that we
might not otherwise see, we could learn from the good ideas and mistakes of
others, and would benefit from understanding how outsiders perceive our
UIs.   For this year I think we should encourage but not require something
along these lines, and based on our assessment of the value, we could turn
this into a stronger requirement for future release trains.  So let's learn
how to do this in a way that provides the most value and avoids the
potential for this degrading into worthless checklist policing.  And for
goodness sake, let's not do this in May when it's too late to make design
changes so that all we can do is cry about  the spilled milk.  Let's do it
early next year when it can still make a real difference.

I'm quite sure that most of us want our UIs to be excellent even more so
than does the foundation, so let's tap that positive energy so that people
who don't participate will feel left out.  It was an excellent party; too
bad you didn't make it; we did invite you.  :-P

Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)

             "Mik Kersten"                                                 
             Sent by:                                                   To 
             ing-council-bounc         "''"    
             es@xxxxxxxxxxx            < 
             10/03/2007 03:34          ui-best-practices-working-group@ecl 
                                       RE: []  
             Please respond to         Improving Project UIs for Ganymede  

(sorry about the length, first paragraph sums most of it up)

In my opinion the spirit of what Mike and EMO suggest is a very important
and necessary direction.  If we can't come up with some basic conventions
for the producers of Ganymede UIs to follow, how can we expect users to be
happy consuming them?  It's amazing that we deliver on time each year, and
the press differentiates us by comparing us to Microsoft's frequent slips.
But in the end we are judged by the usability of what we collectively
deliver.  Microsoft has an internal process for enforcing UI guidelines,
they deliver software that is very usable (while we all like to nitpick,
their UI consistency is impressive and their UIs are de facto usable).  We
are now in the same order of magnitude of LOC as their offerings, yet we
have no UI guidelines that we consistently follow.  The Eclipse SDK has set
an amazingly high bar for UI quality, and provided us with a great set of
guidelines.  I think it would be a shame not figure out some way to
encourage consistency and following the good examples of Platform.

Many projects do this already in various ways, and I don't see coming up
with a "small set of rules" as being prohibitively difficult.  If the best
we can do for Ganymede is to have a very basic set of rules that will still
be better than nothing, and we can evolve them further next year.  For
example, imagine one or more projects breaking the following "don't":

* Don't duplicate functionality contributed by another Ganymede project.

Mylyn could have accidentally done this for Europa because we had our own
Network Settings preferences and these were duplicated with WTP and then
provided by Platform, so we removed ours in time (we may not have if we
weren't watching the other UIs, and having both around would have caused a
lot of user confusion).  Similarly having two toolbar buttons that do the
same thing (e.g. open a web browser) makes the overall UI look goofy.  If
don't have some review process in place we will end up with usability
blunders of this sort.  For example, the Mylyn project can keep up with the
UI changes in the EPP distributions that we're a part of, but there's no
we can monitor all of the other projects' UI evolution, and they're likely
not monitoring us closely enough to know what we are going to add.  A
overview of each of the projects' UI contributions for Ganymede could
identify those points of overlap.  Having top-10 style guidelines drive
an overview could ensure that it's focused on the most relevant and
ostentatious potential problems.  While identifying overlap is just one
of guideline item, it is a start, and there are other very straightforward
ones that are not being followed across the board (e.g. using menu path
conventions, limiting action set visibility).

In terms of arguments against, I think that some very good points were
presented, but in my opinion they are not a good enough reason to throw the
baby out with the bathwater.

* It's too late to add to the list of requirements at this point in the
Ganymede game, and good will is better than coercion (Ed).  Good will has
not been working well enough and has scalability problems.  If it is really
too late then this could be made an opt-in mechanism to start, where a
project chooses to follow the guidelines, which could also address some of
the policing complaints, but in the long run I'm with Mike on a "strong
application of a small set of rules" as long as we have consensus on the

* Checklists will at best trivially improve UI quality and at worse cause
more lost energy than benefit, and there isn't time to enforce or provide
consultation/review (Kevin).  I know that for Mylyn this would not be the
case.  The UI review we had recently was phenomenally useful and took a
single conference call participants' time.  If other Ganymede project
representatives were part of the discussion it would have been even more
useful.  If it were directed by a checklist of agreed upon conventions it
would have helped us ensure we got feedback on all the key spots where
could be a better or more standard way of doing things, because we have
trouble keeping track of them all even though I have read the entire UI
Guidelines (e.g. getting pointer to a common Forms control we hadn't known
about, menu paths, etc.).  For Mylyn this all results in better usability
and fewer bug reports in the end, hence value to our project.  I really
Kevin's statement that "good UIs result from peer discussion, learning and
doing" and I think that if we don't end up with some kind of Ganymede forum
for this kind of discussion, and a lightweight mechanism for capturing the
most common conventions and violations, then we are missing an important

Maybe I'm in the minority, but I see a discussion, review, and guideline
mechanism as a very big service that Ganymede coordination can offer
projects that aren't otherwise willing to go through the full UI guidelines
in detail (on Mylyn we did that, and still benefited significantly from a
review).  I know companies that pay large amounts of money to get
consultation and UI checklists from a similar caliber of expertise that's
available to us all within the Ganymede community.  I realize that there
details that need to be worked out ranging from resources to enforcement,
but overall it would be a shame if we could not come up with some kind of
lightweight and beneficial process to make the overall Ganymede UI cohesive
and usable.


Mik Kersten
Project Lead,

-----Original Message-----
[] On Behalf Of
Mike Milinkovich
Sent: Wednesday, September 26, 2007 6:34 AM
To: 'Ed Merks'; ''
Cc: ui-best-practices-working-group@xxxxxxxxxxx
Subject: RE: [] Improving Project UIs for


I do not and can not disagree with anything you've said here. I thought
and hard about pushing on this. But the simple fact of the matter is
that we
have to do this for the good of Eclipse. We've talked and talked about
to do about improving the UI fit and finish for the release train. This
is a
relatively small but concrete step that we can take. It is time to
*do* something.

And, as Bjorn pointed out, to our knowledge the list for Ganymede is

-----Original Message-----
From: Ed Merks [mailto:merks@xxxxxxxxxx]
Sent: Wednesday, September 26, 2007 7:42 AM
To: mike.milinkovich@xxxxxxxxxxx;
council-bounces@xxxxxxxxxxx; ui-best-practices-working-
Subject: Re: [] Improving Project UIs for


Keep in mind that groups who have already signed up under the
of must dos did so with the basic and reasonable assumption that the
set of
must dos itself was fixed for Ganymede.  So while downgrading
seems okay and certainly has happened in the past, upgrading the set
requirements for an already established agreement, particularly the
dos, requires the consent of all parties involved.  So to my
already past the time to add must do requirements for the current
We should settle for should dos for the current cycle given the poor
timing.   It also seems to me that for the planning council to impose
of requirements, it should be in a position to review those
first rather than put in place a requirement to conform to a
yet-to-be-established check list.   That would definitely be putting
cart before the horse.

So while I agree that this is an extremely important issue and that
action is a good thing, the timing is very poor.  Out of respect for
committer community, it's best that the board not be seen to be
on a schedule that's out of step with the development cycle that
committers.  Plans have already been made by many groups, and what
propose is a change of plans.  I believe that many groups will be
happy to cooperate with these guidelines so a focus on encouraging
cooperation rather than on forcing cooperation is far less likely to
with a backlash.   I can assure you my team and I will do the best we
to conform not only to the must dos but also to the should dos.

Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)

   >             <
             Sent by:        >,

             09/26/2007 12:02          []
             AM                        Improving Project UIs for

             Please respond to
             Please respond to

The EMO would like to suggest the following course of action for the
Ganymede release with respect to user interface issues. I believe
will be adding this to the agenda of the Planning Council meeting at

Background and Motivation

      ·         The Eclipse Board of Directors has added ??encourage
      improved usability and out-of-box experience in the projects??
      strategic goal for 2008.
      ·         Everyone agrees that we want to improve the UI ?fit
      finish? for the projects in the release train.
      ·         The current UI Guidelines document in draft is a
      document. It is over 80 pages of suggestions, guidelines, etc.
      ·         There is no consensus that this ?UI Guidelines?
      will be updated in time to be effective for Ganymede.
      ·         What does appear to be possible for Ganymede would be
      ?...strong application of a small set of rules.?
            o   The group has already created a draft list of the
            dos? and the ?top ten don?ts?
      ·         There does appear to be a consensus that the UI WG
      projects if they bring their UI to the WG for review.

Action Items

To make progress for Ganymede, the following action items will be
by November 30th from the UI BP WG and the Planning Council:

      ·         UI Best Practice Working Group
            o   The UI BP WG must finalize its ?top-XX list of dos?
            ?top-YY list of don?ts? (the ?UI Checklists?) by November
                  §  Note that this can change in the future, but we
need a
                  frozen list for the Ganymede release cycle.
            o   The UI BP WG will schedule reviews with all of the
            projects during Q1 and Q2 ?08.
                  §  This scheduling will be prioritized by the 0,
                  grouping of the projects, i.e., they will review
                  projects first, then the +1s, then the +2s, etc.
      ·         The Planning Council will need to pass the following
      for inclusion in Ganymede projects.
            o   Ganymede projects *must* comply with these ?UI
            o   Ganymede projects *should* attempt to follow the
            guidelines wherever possible.
            o   Ganymede projects *must* undergo a UI review with the
            Working Group and demonstrate compliance with the UI
            to the satisfaction of the WG.
                  §  UI WG concurrence with this compliance will be a
                  Ganymede Release Review check item

Mike Milinkovich
Executive Director
Eclipse Foundation, Inc.
Office: +1.613.224.9461 x228
Mobile: +1.613.220.3223

_______________________________________________ mailing list
_______________________________________________ mailing list
_______________________________________________ mailing list

_______________________________________________ mailing list

Back to the top