Slashdot Mirror
Gnome 2.6 Usability Review
TuringTest writes ""The user-centric UI webzine" UserInstinct has published a usability overview of the latest version of the GNOME desktop. While their conclusions and recommendations are not mind-blowing, it includes two interesting appendices with a survey of new users (and their reactions to the system) and a list of common tasks of modern computer users with a commentary on how Gnome performs in each one. Note that usually You Only Need to Test With 5 Users (this report tests 4), you need to test additional users when an interface has several highly distinct groups of users and thus the conclusions in this review should not be taken as definitive."
It's good to see a fairly unbaised, objective look at an open source product on Slashdot. Many times, we see either a "OMG Open Source = good" or a "I couldn't even get it installed, this sucks!" in place of an actual review. In this instance, it seems as though the reviewers actually tried to make this a fair review. They used users with different experience levels to get an overall picture of the usability of Gnome 2.6. While they could have used more than one user for each stereotype for statistical reasons, it seems at though they have done a decent job in their review. It is reviews like this that show us what to work on.
http://www.linspire.com/RunLinspireFlash.php
I plan to create the outstanding *fixes* for correcting the buttonorder in the upcoming days
Since when does being an "expert to Unix" imply that you want your buttons in Microsoft order rather than Apple order?
0 1 - just my two bits
In any menuing system, there is no rule that says that the menu has to be a true tree. There's nothing stopping you from having a main menu of "What are you here to do today?", and having the most popular functions being placed in more than one position on the interface.
Doing it that way might lead to a more confusing set of decisions at design time, but the user will more often than not find themselves one click away from what they want to do next if you do it right. Afterall, it's easier to find any given option if it's "hidden" in three places instead of just one.
This reminds me of when a friend proclaimed that he hated Linux (KDE to be specific), because it "feels like a shoddy copy of Windows"... It's funny for me to hear that from a Windows user, because that's how Mac users have felt for the past 10+ years in regard to Windows (shoddy copy).
Seriously though, I really don't believe an OSS project could have the focus or resources to take on the task of keeping up with Apple's design. They might get the "look" right, but the "feel" is something much much harder to grasp. In the end all you'd have would be a dock clone, and a clunky interface. The Mac OS has always thrived on having the best UI consistency and a very intuitive feel, which is something that Linux just can't really compete with.
Unix and Windows are much more similar to eachother than they are to the Mac OS. For one, both Win and *nix hide programs down deep in an arcane directory structure that you aren't expected to learn (you can, but most don't). On a Mac, you are expected to navigate the file system to access what you need (if you want to open an App for example, you open the Finder, go to the Applications folder and then open your app). Win and *nix don't really expect you to have to move to where you want ago, hence the usage of the Start menu and Shell PATHs which give quick access to what you need.
An OSS project that copied the Mac would really be copying the Finder and the directory structure. In order to get the Mac feel down pat, you'd have to make the directory structure much more browse-friendly than it is. You can't expect grandma to navigate to usr, bin, and then select from a long list of programs what she wants. Unless a developer/distro with some major clout (i.e. one that wouldn't be completely shunned by the Unix world) decided to revamp the directory structure (or hide the standard tree in favor of a simpler user oriented one), I would recommend that *nix Desktop Environment developers stick the Windows-esque start bar clones that they already have.
For now, if you want the Mac look and feel in a Unix environment, your only and best option is OS X.
Currently, the HIG (see above) is made available to developers for voluntary adherence. If more resources were made availCurrently, the HIG (see above) is made available to developers for voluntary adherence. If more resources were made available, the GNOME project could start a certification program to document compliance with the standard. This would allow users to seek out certified applications and know that these applications would integrate well with their existing desktops.able, the GNOME project could start a certification program to document compliance with the standard. This would allow users to seek out certified applications and know that these applications would integrate well with their existing desktops.
Horrible idea. None of the good desktop interfaces out there have *ever* required certification. We know that it is not necessary to produce an easy-to-use desktop. Further, this will discriminate against those people that do not have money to pay certification fees, slow development of applications (as individual versions would have to each be certified), and slow evolution of the HIG itself. I am opposed, and think that any attempt to formalize a certification process as part of GNOME would simply lead to bad feelings, loss of good will for GNOME, and project fragmentation.
Unfortunately, those who were not were just as quickly lost and confused. To maintain the abstraction, we recommend that it be removed from the view of the new user and kept in the application menu.
There were a number of suggestions like these -- hiding advanced functionality. While this is a reasonable approach -- the terminal is still in the applications menu, and easily available and easily found by non-novice users -- it is also extremely important not to work too hard to hide functionality. One of the largest problems with GNOME 2.x (IMHO, of course) is that significant and valuable functionality has been hidden or deprecated in the name of more basic "easy to use" features. This includes two of my favorite pet peeves:
* Viewport support (someone apparently decided that it was "confusing" to allow the user to have a window partly on one viewport and partly on another, so it was replaced with a number of virtual desktops). As a result of this technical decision, sawfish (which is not the newbie-recomended GNOME WM in any event) underwent significant negative technical change.
* User-rebindable accelerators. In GNOME 1, unlike every other GUI that I know of, accelerator keys attached to menu items can be simply and easily rebound by highlighting a menu item and tapping the desired key combination. This is a phenomenally powerful feature that demonstrated that the OSS world really *does* enjoy new ideas and significantly improved the GNOME user experience. It meant, for the first time, that the user was not bound by the decisions of the application developer. KDE has a similar-but-not-identical feature that allows *some* menu item accelerators to be globally rebound (frankly, I'd like to see the synthesis of these two featurs). Anyway, some usability person decided that this could be confusing to a new user (fine, I'll buy that) and the solution presented was to entirely disable this feature and requires manually adding a line to a text file on a per-user basis, instead of simply providing a toggle button in an "Advanced..." dialog or something similar. As a result, few users know about or take advantage of this functionality.
A remedy is needed for this situation. The answer could be an installation application that can speak to all of the popular distributions. It could be built in such a modular way as to allow new backends and functionality.
This is a good idea, and should have been done a while ago. It's a bit disheartening to think that this will likely have a very limited subset of functionality and be used by most users, though.
A solution to this problem that allows for applications to be downloaded from webpages an
May we never see th
The recommendations don't follow from the user experience. Several don't necessarily follow, but I'll present the dominant problem here:
/etc/issues, and I edited it. It worked. I rebooted. It went away. It took me the longest time to figure out that an fucking script in /etc/rc.something/ was overwriting it. The information was stored in two places. I overwrote the wrong one, and boom. I was fucked. I stopped using Red Hat precisely because of the complex configuration scripts, which made the system fragile and ultimately, easy to break and difficult to use.
Maintain the Abstraction from the Underlying System
This is almost universally the wrong approach -- this is what Windows tries to do, and MacOS avoids. The key is to make the underlying system simple, and make the UI reflect that.
The problem with abstracting the two is that it leads to bit rot. At some point, the Windows registry will think a file is in one location, whereas the file is actually in another. Or the UI will misunderstand the way that the 5 options in the configuration file should be presented as 2 options in the UI. Or there will be some underlying binary configuration file, with some option that's not available in the GUI, that somehow gets flipped, breaking the whole system.
You very strongly don't want an abstraction. On the Mac, installing an application (I haven't use OSX, so my knowledge is based on the older versions) is as easy as dragging the folder onto the hard drive. To erase, you wipe it. On Windows, if you wipe an app like that, it'll leave bits and pieces of itself scattered throughout the registry, links in menus, DLLs in system folders, and dozens of other places. Worse, the uninstaller will often no longer work. Most clueless users, if they try to erase an application the wrong way, will end up with a semibroken system, since there are different levels of abstraction that do not maintain consistency.
The whole Windows (and increasingly, GNU/Linux) approach of abstracting out underlying complexity is flawed. The trick is to eliminate the underlying complexity, and have a single set of simple structures that the GUI tools (or the users manually) operate on.
When I first used Red Hat in '96, the types of issues that threw me were: I wanted to change the login text. I grepped for the old login text, found
This shows up a huge number of places -- especially in a heterogenous environment like GNU/Linux, you often have multiple configuration tools. I can download a half dozen Apache configuration tools. Very often, if you run one, then switch to another, the thing no longer works, since they edit different options in different ways.
One way to implement this (presented in an oversimplified fashion) is to first design what you want the UI to look like. Once you know, you design the underlying structure to match. This is the opposite of what most GNU/Linux and Windows developers do, where they try to engineer the most flexible underlying structure possible, and then develop a UI on top of that. This doesn't necessarily lead to less flexible underlying structures -- it's just that to have a good UI, you want to give some thought to the user experience when designing the engine, and especially, the configuration files.
I'm beginning to get very frustrated by these usability studies because they all tend to make the same false assumption that "familiarity for new users" == "usability for all users."
This is simply NOT true. Usability is a complex quality, and it is the result of compromises among often conflicting goals such as discoverability of options, reduction of keystrokes/clicks for common tasks, customizability where common base cannot be established, compatibility with competing interfaces, humaneness of interface after long-usage, accessibility, internationalization, etc. etc. How quickly New Users can discover and perform tasks is only one dimension of the usability scale, and one that's not even all that important except in a setting like public access kiosks or Internet cafes.
Different OSes approach this problem differently, and where as Mac OS X has chosen to compromise all the goals with an emphasis on discoverability and tolerance after long usage, Windows has chosen to place a different emphasis on sacrificing flexibility for complex tasks in favor of making simple, repetitive tasks easy to accomplish. Both approaches have their advantages and disadvantages.
The traditional strength of the various Linux desktop systems has been flexibility and customizability, with less emphasis on the other issues. I'm not suggesting that the needs of new users whose primary OS is not Linux in settings like Kiosks and labs should not be taken into consideration, but it should not be the ONLY consideration.
Usability studies like this one emphasize the needs of new users with Linux as a secondary OS over everything else. Take this as an example:
These extra areas (the desktop-reveal button, the workspace switcher, the file manger icon, the terminal icon, and the running application button in the top right) could be removed by default...
This is the sort of recommendation that makes sense for kiosk machines (simplify the UI as much as possible and go for task-orientation), but it doesn't make sense for long-term usability. Removal of these features means that users will have to discover them and add them back in, and that plays into one of the weaknesses of the current Linux desktops: discoverability is relatively poor. This is a very shortsighted and pointless recommendation for a desktop system that is also meant to be used as a primary desktop system for many home users.
I wish usability studies would really think about what usability is, over all and long-term, rather than just "can new users in a hurry get an email written?"