| Re: [eclipse.org-planning-council] Improving Project UIs for Ganymede |
|
Although I agree with the general desire (shared by all projects, I
think) to find ways to improve the overall UI/user experience when
using the simultaneous release, particularly at the intersection of
projects, I think I need to point out that mandating a UI checklist
without providing any resources (via foundation, membership or
wherever) to help address these issues effectively disfavors
participation by smaller and newer projects. It makes it more
difficult for them to get distribution through participation in
Ganymede, and subsequent simultaneous releases, and therefore adoption. The projects that are already resource 'rich' (i.e. those run/controlled by respective corp members...I know...I know...they don't feel rich) will have relatively little difficulty meeting these goals (at least as they are now), and their representation on the Board and enforcement policy is already clear. OTOH, the small projects, in many cases independently run, will have relatively little ability to a) participate in setting the guidelines; b) doing the design and other UI work necessary to meet the requirements; c) monitoring other projects for overlap, inconsistency, etc.; d) performing the other work needed for ganymede participation, etc. Scott Ed Merks wrote: 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 |