The main point I want to get across in this email is that while code changes get an r+ to ensure integrity etc, the design of UI does not. Now I'm just an outsider so I may be wrong in this, but even if I am I still don't think design reviews conducted separately within each project is enough.
My idea is that before committing any changes to UI, GNOME developers need some sort of central infrastructure (mailing list, bugzilla?) where they submit their design for approval and a GNOME-wide committee would r+ it before it gets committed. I'm not talking about "design by committee" btw which doesn't work, just a bunch of people, probably from this mailing list, who are trained in the HIG etc. and are able to make such decisions and offer improvements, much like how code review works. My point is that this team will be reviewing UI, not actually doing it themselves, that's still the developer's job. I think this is needed because the HIG, while helpful, is quite brief (I believe there was another thread on this list suggesting splitting it into two books and bulking it up.) To me it's either very vague "direct manipulation is preferred" or very specific "use 6/12 px spacing", but if you're looking for guidance on what would work best for, say, a video editor the HIG falls short. I think some sort pool of "goto guys" would be appropriate for this kind of thing. I'm sure there are people on this list that would certainly volunteer. The advantages I can see are: * The team has direct influence in each project, as opposed to publishing guidelines and hoping people listen. * The team has an overview over all of GNOME and would be in the best position to ensure consistency across projects * Developers can shift the burden of design to someone else (assuming that they are better coders than designers). Of course they don't have to and well thought out UIs will get r+ immediately, and good developers will eventually be trusted to make good decisions. * The HIG will improve over time with experiences from real world applications. The disadvantages I can see are: * A review process can lead to delays in development * The team would need to be all on the same page for it to be effective. (I don't think this list would work - it's too large) * The team could become overwhelmed, although I don't think this is an issue as UI changes happen less frequently than code changes. Other considerations: * The team would have to be quite small, just enough to cope with the workload. They're not so much working together than sharing the burden around. A developer could choose from any number of senior developers to get an r+ but ultimately only one person needs to look at the patch. * They would need to be able to respond quickly and hence would need to be well versed in the GNOME philosophy etc. This all may seem a bit redundant with the increasing awareness about the importance of usability, and developers do try to do the right thing. But I think this approach is worthwhile due to the "central brain" effect and goes towards that top-down approach that design really needs but often lacks in bottom-up open source development. What are your thoughts! _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
