One obvious point is that even if you had a single dictator of usability with infinitely good judgment, they could not make good decisions without knowing whether the goal of GNOME is (for example):
a) a UI for unix sysadmins/developers accustomed to previous unix/linux versions b) a UI for people accustomed to Windows looking for a cheaper or more secure Windows replacement that is drop-in (the same from a training/UI standpoint) c) a UI that is new and different and offers distinct advantages for another target audience, such as consumers Until then, every UI decision implicitly encodes a choice of target audience / macro gnome goal, whether one of those three examples or some other example. What happens by default is that the individual UI decisions are made individually, some working toward one of those goals, some working toward another. Result: not good. I know I keep pointing this out, but it's not like it's been fixed. www.gnome.org still says front and center that GNOME provides "a desktop" as if that narrows anything down meaningfully. My view is that GNOME-the-current-codebase should explicitly be b) with a set of concessions to a) - that is the de facto reality for many UI decisions, though not all. And GNOME-the-project could be expanded to include *partly distinct codebases* - whether OLPC or Maemo or similar - covering c), and possibly even "a desktop" that is c), but different from today's desktop codebase. i.e. a dare-to-be-different desktop codebase that shares some stuff with the current codebase but not everything. With the big picture so vague, debating the details of the menus or control panel is just a waste of time (made even more sad by the fact that these details have been debated, and changed back and forth in a kind of brownian motion, for shockingly close to a decade). Havoc _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
