Whenever possible, I try to test user interfaces with real users. This gives me a much better sense of what people don’t understand, which helps me write better help. I don’t generally have the resources to run concerted usability studies, but even observing a single user can be very enlightening.
After reading Jakub’s “Killing Mode Switch” post, I was concerned about how discoverable this would be. I decided to do a quick test of our current overview. My test subject was a college-educated but non-technical Windows/Office user. I sat her in front of an empty workspace and said “Open the System Monitor application from the Activities overview.” Note that I was very exact in my language, because that’s how we say it in the help. I’m testing our instructions as much as I’m testing the UI. I also intentionally chose an application that you need to scroll to access.
She immediately saw and clicked Activities. She didn’t know about the hot corner. I think that’s OK. A hot corner on a target you click anyway is easily accidentally discovered. She then scrubbed the icons on the dash, reading the tooltips. So there’s a +1 that users readily recognize the dash as where application launchers live. Of course, I didn’t give her an application that’s in the dash, so it wasn’t there.
I watched her mouse and eye/head movement as best I could. She did seem to look off to the right, where the workspace thumbnails live, but she didn’t activate them with the mouse. After looking for a couple seconds, she clicked on Applications. She scanned what was there for a moment, realized she had to scroll, and found and launched System Monitor. I didn’t time it, but it seemed like around ten seconds total.
She said afterwards that she was confused at first because she didn’t realize that Windows and Applications were “tabs” (her word) and that she could click on them. This seems to be a trend. At the Open Help doc sprint, a user didn’t realize she could click the “Account disabled” button next to Password in the Users settings panel. This is even in spite of the fact that she had just read the help instruction telling her to do so. It doesn’t look like a button. It doesn’t look clickable.
Pretty is good. But I fear that some of the prettiness is coming at the cost of discoverability. I realize I’m working with a very small sample size here, but the general notion of affordance of clickability is not new.
I don’t know how discoverable Jakub’s new design will be. The “…” button at least looks clickable, but I don’t know that its meaning is clear. (Phil and I will probably have a long argument about what the heck to call that thing in the help.) I really doubt people will grok the pager dots on the right. In fact, I’m not even sure how they work. But I can only speculate at this point.
I really encourage people to do these kinds of quick tests on real users. Just grab a random person and ask her to do a simple task. It takes a few minutes out of your day. You might be surprised at what people don’t see.
Disclaimer: I’ve only taken a single undergraduate Human Computer Interaction class, so I wouldn’t consider myself a ‘usability expert’. It was a pretty good class, though. 🙂
Disclaimer 2: I’m not ‘hip’ to the terminology used in Gnome 3 to describe the various UI elements, so forgive me if I’m using the wrong words.
It’s also useful to ask users during these tests to explain their mental process/thoughts while going about a task (rather than after). This is not to create a dialog between you and the tester (since you do not want to bias his/her behavior), but so you can link the user’s thought process to his/her actions. Ideally, you’ll be able to record the session too, but that’s a whole ‘nother topic.
As for the issue with “Windows” and “Applications”, you are exactly right; it’s an issue with affordance (http://en.wikipedia.org/wiki/Affordance). They do not afford clicking because they do not appear like an object that would be ‘pushed in’. I had the same issue when I first booted up Gnome 3 not too long ago.
The “…” button is a nice concept, but it is grouped in with the application buttons, so users may assume that:
* It launches an application.
* Its position can be moved around like the other applications in the menu.
* It can be removed like the other applications in the menu.
…among other things, for sure.
If we can differentiate it somehow from a regular application button and make it feel like a permanent part of the menu, it could work. By being a part of that menu, the button would be grouped in with the application buttons (so the idea is that it would communicate, “my functionality involves applications!”), but it would not look like a regular application button (so users won’t think it *is* an application).
Anyway, I’m looking forward to more UI advances in Gnome 3. Let me know if I can help in any way with my limited usability knowledge, and nonexistent artistic skills. 🙂
All great points, thanks. I do see the value in having users vocalize their thoughts, although I wonder if it will slow them down. In many cases, I’m also interested in how quickly they get things done.
I definitely think there’s a potential that people will think the “…” button is just another application launcher. Apps have all sorts of funky icons with crazy metaphors. Who’s to say I don’t have an “Ellipsis” program? One solution might be to make the button non-square. The ellipsis is wider than it is tall anyway, so why not just make the button shorter? Since all app launchers are square, that might make it more clear that the dots are something else.
I think it would benefit to make the button have a different ‘style’ in addition to ‘shape’. The boundaries between application launchers is not explicitly shown (before rolling over, anyway), so it may look odd to have a button in the style of an application launcher, but with a smaller height. Many icons are square in shape, but the ellipsis is not, so it’s possible some users will assume that the launcher size adapts to the size and shape of the icon, and that the ellipsis is still a program (Disclaimer 3: I’m a programmer, so I’m far from a ‘normal’ user).
Perhaps we can even add direction to the icon used for this, to imply that something is going to appear in the center of the screen. Here’s a proposal:
* Change “…” into an arrow pointing to the right (->).
* Make it into a glossy button [explicit boundaries, with lighting effects to make it look ‘raised’ and like a button] with height the size of the icon.
* Align it with the bottom border, or perhaps integrate it into the bottom border somehow? This will set it apart from the application launchers.
* When clicked, the applications will “slide” out, like a tray, and the arrow button will reverse direction ().
* If the user does something (launch an application or something) that makes the application icons disappear, the arrow will reverse direction to its default state (->).
I’d mock something up if I had the skills, but I don’t! Hopefully this makes some sort of sense. 🙂
It could also be a few launchers put together in a stack. Sort of like the way cards in a game of solitaire are arranged to indicate multiple cards.
I totally agree, and I made sure to let him know my feelings about it (although not very concisely). I honestly like the prior graphical improvements to those ‘tabs’ that were made recently. It made them more discoverable, more obvious to click on, and the little arrow below made it obvious that one was activated at the time, and which one.
I honestly prefer that method, and I don’t think most users will be happy with a … for long. I don’t see it as a metaphor that will catch on very quickly, and if it did I’m not sure if it’s the right metaphor. Of course, for what it is, I can’t imagine a much less distracting, yet clear representation of ‘etc.’ or ‘more stuff’ than three dots.
I just don’t like it because it’s like putting text directly into the dock, which is for icons (even though it’s technically an icon). I generally don’t like to see text there unless I’m mousing over something, even if the text is obvious and symbol-like. There are obviously some trade-offs, but I think we need to discuss this point a lot more before we make a lasting decision for 3.2.