[eclipse.org-planning-council] Re: [ui-best-practices-working-group] Im

["Kevin McGuire (eclipse)" <eclipse@xxxxxxxxxxxxxxxxxxxxx>]

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 30^th 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 30^th

§  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