[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ui-best-practices-working-group] Improving Project UIs for Ganymede
|
As the "manager" in question in Kevin's note, I should say that I believe
strongly in the value of the UIWG, as a venue for interchanging ideas about
Eclipse UI design and best practices. I also think that it is an excellent
place for developers to bring specific, thorny UI problems, so that they
can get the benefit of the wider perspective of the community. I do not
believe, however, that it should be a source of "UI policing". This runs
counter to the spirit under which the group was enacted, and is likely to
be unsuccessful for the reasons Kevin indicates.
McQ.
"Kevin McGuire
(eclipse)"
<eclipse@xxxxxxxx To
guireclan.net> mike.milinkovich@xxxxxxxxxxx, User
Sent by: Interface Architecture Working
ui-best-practices Group
-working-group-bo <ui-best-practices-working-group@ec
unces@xxxxxxxxxxx lipse.org>
cc
eclipse.org-planning-council@eclips
26/09/2007 04:17 e.org
PM Subject
Re:
[ui-best-practices-working-group]
Please respond to Improving Project UIs for Ganymede
User Interface
Architecture
Working Group
<ui-best-practice
s-working-group@e
clipse.org>
Mike, there seems to be the desire to have a concrete checklist for
validating our UIs, something clear cut that you can walk down and say "yes
they did this" or "no they failed to do so". Like an API specification.
The "UI Healthometer".
While I applaud the board's recognition that our UI state of affairs is
poor and that something needs to be done, I believe the checklist approach
can at best trivially improve the UI quality, but more likely change
nothing, and in the meantime cause much swirl with lost time and energy.
Specifically, I have the following issues with this approach:
1. Can't both be quantifyable and useful
For the checklist to be unarguable (and thus can be validated), it ends up
being simplistic. To be more, it ends up being vague and unverifiable. Our
"Do's and Don'ts" list wasn't designed to be policed, and I don't believe
it can be transformed such.
2. Nobody has the time
Projects like WTP and TPTP are huge. A one hour walk through, with time for
discussion, barely touches the surface. Even if I thought the checklist
would provide value (which I don't), that's not enough time to demonstrate
and verify compliance. I've discussed this with my manager and he is not
signing up any more of my time to devote to the UIWG.
3. Doesn't address the real problem
I am going to assume that the current UI problems result from a team not
believing UI quality is a priority vis-a-vis their other requirements, or
that the team lacks folks with strong UI skills. How does the
checklist/verification approach help either of these? I suppose in the
first case its a statement of importance, but I doubt it will change their
trade offs. In the second case, it does not increase the skill level.
The reviews are valuable because they help to address the skill shortage
issue, and because good UIs result from peer discussion, learning and
doing. I'm happy to participate in the calls because I believe that
building a community of "UI like minded folk" contributes to the overall
solution.
But to be clear, as a member of the UIWG, I am not signing up to police any
component's adherence with any checklist, because I don't believe its our
role, because I don't believe its of any real value, and finally because I
think it makes the process adversarial rather than collaborative.
The UIWG calls and reviews are only one hour every two weeks with some time
in between for email. The impact is important but modest given this
investment. If the board really wants to tackle this problem, I'd suggest
they hire a UI skilled person to act as a resource to the various projects,
someone whose job it is to spend real time with them one on one.
Yours,
Kevin McGuire
Mike Milinkovich wrote:
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
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
