[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-planning-council] Improving Project UIs for Ganymede
|
Mik,
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"
<beatmik@xxxxxxx>
Sent by: To
eclipse.org-plann <mike.milinkovich@xxxxxxxxxxx>,
ing-council-bounc "'eclipse.org-planning-council'"
es@xxxxxxxxxxx <eclipse.org-planning-council@eclip
se.org>
cc
10/03/2007 03:34 ui-best-practices-working-group@ecl
AM ipse.org
Subject
RE: [eclipse.org-planning-council]
Please respond to Improving Project UIs for Ganymede
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
(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,
and
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
we
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
way
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
simple
overview of each of the projects' UI contributions for Ganymede could
identify those points of overlap. Having top-10 style guidelines drive
such
an overview could ensure that it's focused on the most relevant and
ostentatious potential problems. While identifying overlap is just one
type
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
rules.
* 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
UI
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
there
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
like
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
opportunity.
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
are
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
--
Mik Kersten
Project Lead, http://eclipse.org/mylyn
> -----Original Message-----
> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of
> Mike Milinkovich
> Sent: Wednesday, September 26, 2007 6:34 AM
> To: 'Ed Merks'; 'eclipse.org-planning-council'
> Cc: ui-best-practices-working-group@xxxxxxxxxxx
> Subject: RE: [eclipse.org-planning-council] Improving Project UIs for
> Ganymede
>
> Ed,
>
> I do not and can not disagree with anything you've said here. I thought
> long
> 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
> what
> 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
> actually
> *do* something.
>
> And, as Bjorn pointed out, to our knowledge the list for Ganymede is
> still
> TBD.
>
>
> > -----Original Message-----
> > From: Ed Merks [mailto:merks@xxxxxxxxxx]
> > Sent: Wednesday, September 26, 2007 7:42 AM
> > To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-planning-council
> > Cc: eclipse.org-planning-council@xxxxxxxxxxx; eclipse.org-planning-
> > council-bounces@xxxxxxxxxxx; ui-best-practices-working-
> > group@xxxxxxxxxxx
> > Subject: Re: [eclipse.org-planning-council] Improving Project UIs for
> > Ganymede
> >
> > Mike,
> >
> > Keep in mind that groups who have already signed up under the
> existing
> > set
> > 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
> > requirements
> > seems okay and certainly has happened in the past, upgrading the set
> of
> > requirements for an already established agreement, particularly the
> > must
> > dos, requires the consent of all parties involved. So to my
> thinking,
> > it's
> > already past the time to add must do requirements for the current
> > cycle.
> > 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
> a
> > set
> > of requirements, it should be in a position to review those
> > requirements
> > first rather than put in place a requirement to conform to a
> > yet-to-be-established check list. That would definitely be putting
> > the
> > cart before the horse.
> >
> > So while I agree that this is an extremely important issue and that
> > taking
> > action is a good thing, the timing is very poor. Out of respect for
> > the
> > committer community, it's best that the board not be seen to be
> > operating
> > on a schedule that's out of step with the development cycle that
> drives
> > the
> > committers. Plans have already been made by many groups, and what
> you
> > propose is a change of plans. I believe that many groups will be
> more
> > than
> > happy to cooperate with these guidelines so a focus on encouraging
> > cooperation rather than on forcing cooperation is far less likely to
> be
> > met
> > with a backlash. I can assure you my team and I will do the best we
> > can
> > 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)
> >
> >
> >
> >
> >
> > "Mike
> > Milinkovich"
> > <mike.milinkovich
> > To
> > @eclipse.org> <eclipse.org-planning-
> > council@eclip
> > Sent by: se.org>,
> > eclipse.org-plann <ui-best-practices-working-
> > group@ec
> > ing-council-bounc lipse.org>
> > es@xxxxxxxxxxx
> > cc
> >
> >
> > Subject
> > 09/26/2007 12:02 [eclipse.org-planning-council]
> > AM Improving Project UIs for
> > Ganymede
> >
> >
> > Please respond to
> > mike.milinkovich@
> > eclipse.org;
> > Please respond to
> > "eclipse.org-plan
> > ning-council"
> > <eclipse.org-plan
> > ning-council@ecli
> > pse.org>
> >
> >
> >
> >
> >
> >
> > The EMO would like to suggest the following course of action for the
> > Ganymede release with respect to user interface issues. I believe
> Bjorn
> > will be adding this to the agenda of the Planning Council meeting at
> > EclipseWorld.
> >
> > Background and Motivation
> >
> > · The Eclipse Board of Directors has added ??encourage
> > improved usability and out-of-box experience in the projects??
> as
> > a
> > strategic goal for 2008.
> > · Everyone agrees that we want to improve the UI ?fit
> and
> > finish? for the projects in the release train.
> > · The current UI Guidelines document in draft is a
> large
> > document. It is over 80 pages of suggestions, guidelines, etc.
> > · There is no consensus that this ?UI Guidelines?
> > document
> > will be updated in time to be effective for Ganymede.
> > · What does appear to be possible for Ganymede would be
> > the
> > ?...strong application of a small set of rules.?
> > o The group has already created a draft list of the
> ?top
> > ten
> > dos? and the ?top ten don?ts?
> > · There does appear to be a consensus that the UI WG
> can
> > help
> > projects if they bring their UI to the WG for review.
> >
> > Action Items
> >
> > To make progress for Ganymede, the following action items will be
> > required
> > 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?
> and
> > a
> > ?top-YY list of don?ts? (the ?UI Checklists?) by November
> > 30th
> > § 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
> > Ganymede
> > projects during Q1 and Q2 ?08.
> > § This scheduling will be prioritized by the 0,
> +1,
> > +2
> > grouping of the projects, i.e., they will review
> the
> > 0
> > projects first, then the +1s, then the +2s, etc.
> > · The Planning Council will need to pass the following
> > rules
> > for inclusion in Ganymede projects.
> > o Ganymede projects *must* comply with these ?UI
> > Checklists?.
> > o Ganymede projects *should* attempt to follow the
> draft
> > UI
> > guidelines wherever possible.
> > o Ganymede projects *must* undergo a UI review with the
> > UI
> > Working Group and demonstrate compliance with the UI
> > Checklists
> > 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
> > mike.milinkovich@xxxxxxxxxxx
> >
> > blog: http://milinkovich.blogspot.com
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
