Il giorno mer, 23-02-2005 alle 15:01 -0400, Lex Spoon ha scritto:
> I don't know if this has been posted before, but Matthew Thomas has
> posted a seering review of open-source UI designs which hits close to
> home for us.
> 
> 	http://mpt.phrasewise.com/2002/04/13

It's a good article, albeit it's becoming somewhat old. Open source
project like Gnome and Mozilla Firefox have shown that usability and
open source can live together.

> What can we do to avoid the fate of Mozilla's UI?  Do we need a UI tsar
> to avoid disaster?  Or, is there a way to make entire UI's be swappable
> in and out, so that people can make up UI's in a decentralized way and
> thus let the market work it out?

I don't think we are doomed to the fate of Mozilla's UI, even if we
don't have a UI tzar to impose his vision on the others. I think that
the usability team should produce both _reasonable_ guidelines and
suggestion, and also patches to implement those suggestions. The
suggestions should be reasonable, so that noone can oppose them without
pondering them too, and they should come with patches attached, so that
everyone can see and evaluate "hands on" the advantages and
disadvantages of those suggestions.

> Here's a bit of flamage copied from the article:
> 
> "As in a professional project, in a volunteer project there will be
> times when the contributors disagree on a design issue. Where
> contributors are paid to work on something, they have an incentive to
> carry on even if they disagree with the design. Where volunteers are
> involved, however, it's much more likely that the project maintainer
> will agree to add a user preference for the issue in question, in return
> for the continued efforts of that contributor. The number, obscurity,
> and triviality of such preferences ends up confusing ordinary users
> immensely, while everyone is penalized by the resulting bloat and
> reduced thoroughness of testing."

The explosion of options is something that can and should be avoided.
Options should exist to provide reasonable alternatives, not to avoid
design decisions.

	Giovanni