Different people are able to control a pointer with different degrees of accuracy. Several things can affect this, including the hardware that is used and the person’s physical ability to use their hand and fingers. A person’s level of practice and confidence using the hardware and software in question is also a major factor.
Often (though certainly not always), geeks are able to manipulate a pointer with a high degree of accuracy. This is largely a result of practice, both in using a pointer and in using the specific software too. We’re happy ducking and weaving the little arrow when necessary. Habit tells us where the click target that we want will be. This often makes geeks quite tolerant of software which requires a high-degree of pointer control. We don’t mind nested menus or tiny close buttons.
A high level of pointer control is not a sure thing though, and a user interface which requires a high level of pointer control will frequently be an extremely painful thing to use. People using it will frequently make errors. Some of these will be minor, such as sending the pointer to the wrong place. Others will be major, such as clicking the wrong target. And the preponderance of low quality pointing devices means that peoples’ pointer control is often lower than it used to be. Netbooks are a major factor here. Their touchpads can be extremely low quality.
GNOME 3 has been designed to ensure that it can be used by those who have a low level of pointer control, either because they are not well practised at using pointing devices or our software, because they might not have good control over the hand and fingers, or because they are using low quality hardware. This is one way in which GNOME 3 is easier to use than GNOME 2.
Launching applications in GNOME 2: can be tricky
One way that the pointer control demands of GNOME 3 were lowered was by avoiding the use of submenus. These present a number of challenges to those with low pointer control, including abrupt changes in the direction of pointer movement and narrow click targets. Considering that submenus were the principle way in which applications were launched in GNOME 2, this was a bad situation indeed.
Launching applications in GNOME 3: big isolated click targets
Another aspect of the GNOME 3 design which lessens its pointer accuracy demands is the removal of the minimize and maximize buttons from titlebars. Users with a low level of pointer control will often accidentally select small targets which are grouped closely together, as is often the case with window controls. This is particularly dangerous when one of those buttons – close – has potentially destructive consequences. In GNOME 2, if someone wanted to minimize and missed the target, they could easily lose their work. This is no longer the case in GNOME 3, since maximization occurs by dragging a window’s titlebar.
Maximising in GNOME 3: the pointer can stay well away from the close button
There are many other aspects of the GNOME 3 design that make it easy to use for those with a low level of pointer control: the hot corner, the use of the windows button, the ability to quickly perform a lot more actions without the need of a keyboard, and more.
Last weekend, I conducted an experiment to test the difference between the pointer control demands of GNOME 2 and GNOME 3. I borrowed a friend’s netbook (a Dell Mini 10) – which has a low quality touchpad – and attempted a range of tasks using both GNOME 2 and 3 (using Fedora 14 and 15). To lower my ability to control the pointer even further, I only used my left hand (I’m right handed). I launched applications and switched between windows using the pointer. I maximized, unmaximized, and closed windows.
Though I could accomplish all the tasks I wanted to with GNOME 2, the experience was not ideal. I would typically overshoot targets in the panel menus. Changing the pointer’s direction of travel when navigating submenus required a separate swipe of my finger and was also prone to minor errors. Using the window controls was particularly difficult. It was rare that I could land the pointer on the target with my first attempt. I’d overshoot or head in slightly the wrong direction. And then I’d have to head back again.
Things were undoubtedly better with GNOME 3. Window selection under GNOME 3 was a dream: I just hit the hot corner or windows key and then had nice big thumbnails to click on. I always hit the window I wanted first time. Interacting with notifications was also really easy, thanks to their occupying a large swath of the bottom screen edge. Window management was also much easier with GNOME 3, largely because those three little buttons had gone. The big close button was an easy click target, and I could easily drag the window’s titlebar to maximise or unmaximise without the risk of hitting the close button.
Usability isn’t linear, and the same interface isn’t consistently usable in all situations. Though I do think GNOME 3 is generally more usable, some of its usability improvements only really shine through in particular situations. Pointer control is a good example of this: if you’re an experienced user using a high-precision pointing device, the chances are that you won’t notice some of the improvements in GNOME 3. That doesn’t mean that there aren’t many people who will benefit from these changes though.
As far as I know 
I understand you point of view, but I think the height of windows in Gnome 3 can be reduced without out of your goal. Actually, majority of laptop are sold with a 1366×768 pixels (16/9) screen if it have a size < 15". And for netbook it can have only 1024 x 600 pixels. The new Gnome 3 default theme making windows too height. 😦
Hey Paradoxe: the title bar height is a bug, and a fix is in the works. 🙂
Thank you Allan. 😉
“Launching applications in GNOME 3: big isolated click targets”
True, except for one important target visible in that image: the “Applications” tab. When I use my touchpad, I have a very hard time hitting that thing. Even with my mouse, it is not an easy target.
Its height is too low. And the width may vary. (The Portuguese word «Aplicações» is slightly shorter than the English word “Applications”)
If it had twice its current height, it would be a much easier target. There is enough space between the “Windows” and “Applicaions” tabs and the top bar.
I don’t know if there is a bug on this matter already.
BTW, Great Article!
(Sorry my English. Not a native speaker.)
António: totally agree. That’s something I want to see fixed.
Here’s a problem that I haven’t seen discussed before:
Every now and again I click on something on the screen, but just as I start to click, something else will pop up in place, and I will click that instead. The same can happen if the thing that you were going to click disappears or moves. This has potentially destructive behaviour, as with the problem that you’re talking about.
For example, I type a draft message in my chat application. I don’t want to send it yet, and leave it. I am then looking at something such as a download progress window that closes of its own accord. I go to click on it, to cancel perhaps, but it disappears as I’m click and my click goes through to the chat window and sends the message that I didn’t want sent.
Obviously that’s quite a specific example, but with out current paradigm of windows, it’s very hard to solve.
I was going to comment on this one as well. One of the things that annoys me in Gnome3 is that when I click the network manager button and move my mouse down I may accidentally move it to the side first and as such see my network menu switched for the sound menu.
Dextro: I’m surprised you’ve experienced that. Vertical pointer movements aren’t generally prone to horizontal slippage. This is exactly the same behaviour that you find in any menu.
What you say is technically correct, except that requiring users to do a drag motion can also be a difficult action for people with certain disabilities. The current actions suffering form requiring dragging are maximizing and moving a window to a new workspace.
The solution is obviously the window menu but right now it sucks, would be nice to be able to click something (a button on the opposite of the close? right click on the menu? dunno…) and have a large horizontal button overlay with easy to hit targets for the different actions, WITH WORKSPACE PREVIEWS for the workspace moving.
I believe this is one of the big areas lacking in finish for gnome 3 for people who are not 100% able on the mouse.
dbrodie: agreed. This is a real problem. You can double click to maximize/unmaximize, but it’s still a problem for accessing workspaces.
One target that got harder to hit in GNOME3 is the resize border. The snap-to-resize feature works nicely for maximization, but when you don’t want maximixed nor half screen windows the experience is frustrating.
This is also being discussed at:
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Congratulations on the amazing work you all have done with GNOME3. I admit I was doubtful at first but after a few hours I found myself pretty satisfied with the new achievements. I realized that minimizing windows was just a bad habit that can be replaced with pressing Alt-Tab or exploring the Activities Overwiev.
I encountered some difficulties while trying to make the systray area appear. I think it may be due to the fact that I spend most of the time in the upper part of the screen, thus the right bottom corner is somehow “difficult” to reach. Moreover, labels in the systray area don’t seem to have the proper affordance as I keep clicking on the icons (that requires more pointer control). Would be interesting to make the whole icon+label thing look more like a button. Don’t know, just thinking aloud. 🙂
Nice blogpost!
Would be interesting to make the whole icon+label thing look more like a button.
It is supposed to work like that. While notifications will work, the required GTK+ change to make it work for legacy tray icons as well was not backported to the stable branch until 3.0.9 – no idea what distribution you are using, but you can expect the next GTK+ update to fix the issue …
Everything works very well until you connect an external monitor. Then the magic lower right corner (to show notifications) becomes a 5×5 pixels target almost impossible to hit (you always overshoot and go over to the other screen). Also (but this is just an annoyance) the shadow of maximized windows goes over to the other screen and while it is “correct” from a logical standpoint it doesn’t feel right.
Did all the gnome shell designer use just 1 monitor? 😀
Federico: sounds like a bug. Can you report it please?