|[eclipse.org-planning-council] Re: [ui-best-practices-working-group] Improving Project UIs for Ganymede|
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.
Mike Milinkovich wrote:
Back to the top