Slashdot Mirror
Nicholas Petreley Slams Gnome
FreeLinux writes "Mainstream computer rag ComputerWorld, has posted a review of Gnome 2.6 by Nicholas Petreley. This opinion piece review, titled Living Down to a Low Standard, positively lambastes Gnome 2.6 over the new spatial Nautilus and Gnome's design choices. The review is quite the opposite to a previously reported review from PCWorld, last month. While this latest review is bound to be a polarizing and heavily debated issue (read flamebait), it is important in that this review will be seen by so many mainstream readers and corporate types who may have been considering Gnome."
Gnome has been regressing for quite some time, and now this latest fiasco of multiple window browsing serves to show how its' developers are out of touch with the intended userbase.
This begs the question; Why was the default setting for this feature changed to something that would hinder the user, after Gnome has been developed for so long?
I would really like one of the Gnome developers to answer that here.
user@host$ diff
The button ordering is not because of left-to-right reading. As you tried to explain, that doesn't make much sense anyhow.
The truth is, it is just easier to *spatially* find the buttons. Yes, that spatial stuff again. As with spatial Nautilus, human minds are in fact very, very good at managing spatial locations. Ars Technica in its Spatial Finder write up noted that even an expert programmer's ability to comprehend paths and abstract concepts is entirely dwarved by even a child's spatial recognition and manipulation ability.
With the buttons on the right of the dialog (which is how every well design OS/app works, independent of how the buttons are ordered) you are always able to spatially locate the button group in relation to the dialog itself. Just look in the bottom right corner, and there you have them. (The right alignment may be due to the fact that we read left-to-right, and thus our eyes find it easier to look in the bottom right after reading the text above.)
The reasoning for using Cancel/Action (*not* OK - there is never an OK button in properly designed GNOME apps. Explained below.) is just an extension of that same design/layout that even KDE and Windows use. Finding things is easier using spatial locations. Finding the button group as a whole is easy because its in the bottom right corner. Putting the main action button in the very bottom right thus makes it even easier to find. This has been tested, extensively, by both GNOME engineers (Sun and Ximians folks; both do a lot of usability testing) and the Apple folks, who do things the same way for similar reasons.
Regarding the OK buttons, it's just a matter of usefulness and safety. "OK" is 100% meaningless. OK what, exactly? The same thing with Yes/No: yes what, no what? You can change the meaning of OK/Cancel in any dialog you see, and the only way to tell the different is to read the whole text (which is often poorly written itself). By avoiding the term OK, and using the actual action the button does (Save, Quit, etc) you remove ambiguity. It increases safety, as well; say you usually see dialog A when doing some task, in which the OK button does what you need. Then after an upgrade, or maybe after some data corruption you're unware of, dialog B pops up instead. Due to habit, you don't even read the text, you just click OK. But oops, this OK did something else, something you didn't want to happen. Or maybe you expected something to happen (like saving) that didn't, but you have no idea it didn't happen. By labelling the buttons something other than OK, it's much less likely you'll just click the button and not notice something is different. Your eyes look directly at the button to aim for clicking, unlike the dialog text which you just skip over out of habit. If the button text changes, you'll notice. Cancel is also better defined in the GNOME/Apple HIGs. Cancel only shows up in dialogs caused by user action. Cancel does nothing other than cancel that action. No other side effects.