On Tue, May 26, 2015 at 2:42 AM, Josh Triplett <j...@joshtriplett.org> wrote: > First, while I'm extremely impressed by the huge variety of UI design > ideas that GNOME has experimented with, and many of them have been quite > successful, I think GNOME needs some mechanism to recognize when an idea > isn't working or doesn't really appeal to the majority of users, and say > "well, that was a fun experiment, but let's drop it". For instance, I > rather strongly suspect many GNOME 3 users would sigh with relief if > alt-tab went back to "switch windows" and alt-` became a > backward-compatibility synonym. As far as I can tell, though, design > ideas only really tend to get dropped when they get replaced with some > other, newer design idea; for instance, the notification tray gave way > to the excellent new notification mechanism in the latest release of > GNOME. > > I think it would make sense to have a convenient way to float design > experiments as extensions or branches, rather than as part of mainline > GNOME, until they become less experimental. And in the meantime, I > think we need a way, as a community, to decide that a UI experiment was > unsuccessful and should be reverted.
I just want to say that these two paragraphs is just full of win. There is absolutely needed a mechanism that lets us figure out when something is not working. In GNOME, I think we have problems with either 1) communicating how features are implementing in GNOME 2) communicating how features (if you want to call them that) are removed in GNOME. When features are removed, they do cause regressions and it is important that at least we have some kind of historical reason why we removed it in the first place. While people might object to the removal or adding, that doesn't matter, only that there is a story. Maintainers who remove or add features should provide good notes to the release team on why something was removed or added so that we can provide a good story to the story. I sometimes feel that we don't take into account users who use our systems. Maintainers might have a vision of the end state, but end users may not and when the story is murky it leaves people with vivid imaginations to tell the story. sri _______________________________________________ foundation-list mailing list foundation-list@gnome.org https://mail.gnome.org/mailman/listinfo/foundation-list
