thoughts on usability, coding and other nerd topics
Matthew Paul Thomas explains different aspects of usability, writing:
August 10th, 2008 / Tags: usability, learnability, efficiency, memorability, safety, satisfaction / TrackbackEvery so often, in a software project’s mailing list, bug tracker, or wiki, I see someone suggest a change they claim will “improve usability”. This is an unhelpful choice of words. It’s unhelpful because usability involves multiple components.
Daniel J. Wilson points out that Curio supports spatial searching.
This is a Curio document:
As soon as I start typing a search word, Curio starts making non-matching elements transparent:
Safari and Firefox use similar solutions. This is how it looks in Safari:
In an excellent article titled “Does Mess really Exist”, Keith Lang of plasq writes:
Instead of seeing a mess, humans are good at seeing a ‘complex system with lots of clues’.
This applies even more if the mess in question is of their own creation. Lang argues that we should allow for some amount of messy design in our user interfaces. While I agree, I think it’s even more important to allow users to make their own mess.
When I wrote about spatial thinking, I showed this picture of my desk:
This is a mess, but it’s also perfectly organized. Even though it’s messy, I always know where to find what. It’s not a random mess, it’s a spatially organized pile of things. This is how humans think; not in alphabetical categories, but in spatial1 categories.
So how does this apply to computers? This is a typical folder in Mac OS X, shown as a list sorted by name:
This looks tidy. But actually, it’s very hard to find and identify things in this view. What’s styles.css? What’s “Untitled”? Where are my notes for the timesheet entry UI for our operations site? In order make this list usable, we need to introduce hierarchy.
Or, alternatively, turn it into a mess. Here’s the same folder, in a messy state:
While this looks less useful than the linear list at first glance, it actually is more useful. I know perfectly well where I put every file. I know what context the files relate to by their position, and I can now see that “Untitled” is a picture of me, and that styles.css contains styles for a redesign of our operations site, and that my UI draft is near the other documents detailing the redesign of the operations site.
So the second screenshot is more usable, even though it looks messy and somewhat random. How can that be?
When things are homogenous, every item has the same visual importance. Nothing stands out; the user can’t orientate himself. It’s easy to get lost in a city where every building looks exactly alike; landmarks help us figure out where we are. The same applies to user interfaces.
One man’s mess is another man’s perfect order. My files aren’t unordered just because they look messy. They look messy because they are organized in two-dimensional space. Since I know where I put everything, and since the files are sorted topically, I can easily find everything I need and identify files based on nearby files.
Now that we’ve established that messy organization can help users, we need to find out how we can help users make a mess. There are several things we can do.
Many applications actually prevent their users from making a mess. On the iPhone, you can’t freely place your application icons. On each screen, you have to start from the top left and add applications linearly. Even if Apple doesn’t want to let users position applications freely, why not allow for empty “slots” between applications?
If your application only has a list view, think about adding a two-dimensional view which supports free placement of your items on a 2D plane.
Allow users to color and resize items individually, so they can represent things like importance, making important things red and big, and unimportant things grey and small.
After users have made a mess, it’s important to safeguard that mess for them. Every pixel counts; never move anything except when the user explicitly wants something to be moved. Since users identify files by their position and looks, don’t touch these attributes.
If you allow users to make a mess of their data, you need to support and respect this mess. For example, Mac OS X allows users to make a mess of their windows. You can have windows all over the place, overlapping each other. To help users manage this mess, Apple provides Exposé, which zooms and moves windows, showing them at the same time next to each other. It respects you organization and puts them back exactly where they were before you invoked Exposé, but it also respects your organization while it’s invoked. Instead of simply distributing the windows on the screen, Exposé tries to reflect your organization. Windows typically don’t move very far when you activate Exposé, which helps you find the window you’re looking for.
This is my screen:
And this is my screen with Exposé activated. Notice how all windows remain near where they were in the screenshot above, making it easier to find the window the user is looking for:
Exposé doesn’t always work perfectly. It tends to minimize zooming instead of optimizing for placement. In this screenshot, I’ve put pictures of me to the left of the screen:
When activating Exposé, I get this:
While this does allow me to see all windows at once, it breaks my spatial organization and forces me to reorientate myself. Even though I put all pictures of me on the left of the screen, they are now distributed all over the screen.
Exposé does the right thing and attempts to respect the user’s messy organization, but sometimes fails because it tries to keep windows as large as possible, instead of trying not to move them too far.
Most modern operating systems are terrible at supporting search in spatial environments. As soon as you start searching, they revert to list views. There is one part of Mac OS X which has spatial searching: The System Preferences.
Searching doesn’t switch to a list view. Instead, it highlights potential search results in their normal location.
A similar search feature could be implemented to point out specific files in a messy pile of files.
Being messy is good. Allow for some level of mess in your UI design, and even more important, let the user create a mess with his “stuff.” Protect and support the user’s mess.
One final thing to consider is that “messy” organization starts to break down with huge numbers of files. iTunes organizes so many files that it is almost impossible to organize them spatially. There are ways around this, such as zoomable interfaces,2 but unfortunately, no popular modern operating system supports such paradigms out of the box.
A few weeks back, I wrote an article explaining how anyone can (nay, should!) run cheap and simple usability tests. Back then, I wrote this:
Even if you don’t have any external way of recording a usability test, it should at least be possible to keep some kind of screen capture application running which can also record input from the computer’s microphone.
I didn’t point out any specific screen recording applications. Although there are quite a few of these applications available for Macs, all of them have certain quirks which can get a bit annoying when running usability tests. None of these applications are aimed specifically at people running usability tests.
Or rather, I should say there were no Mac screen recording applications aimed specifically at people running usability tests; because now, there is one: Clearleft’s Silverback.1
Silverback is described as “a guerrilla usability testing app for people who design and build websites.” This is quite a strange description. I’m not sure why it is described as a “guerilla” application,2 and I’m also not sure why is is targeted at “people who design and build websites.” It’s just as suitable for people who create native applications.3
What the application does is actually rather basic: It records a computer’s iSight and screen. What makes Silverback interesting is that it does so in a way which makes it perfectly suitable for certain types of usability tests.
After launching the application, you are greeted by the extremely well designed main application window.
It is obvious that a lot of thought (and, presumably, testing) has gone into the design of Silverback’s user interface. To start working with Silverback, simply set up the application or site you want to test, open Silverback, click on “New Project”, name the project, and click on “New Session.” You can now enter the test subject’s name, add a few notes, adjust the camera, and hit “Start Session” when you’re ready.
This wil dim the screen. At this point, you can invite your test subject, prep them for the test, and tell them to hit space to start.
During the test, you can use your Apple Remote to add chapter marks or pause and restart the test. Setting chapter marks is a good idea if you notice an issue during the test; to make sure you remember why you made each chapter mark, you should also keep a written log while the test is running.
Once the test is done, the screen and iSight recordings can be exported as a picture-in-picture QuickTime movie, but can not be viewed immediately within Silverback itself. The exported video will show mouse clicks visually, but you can’t add your notes to the chapter marks. You will have to keep track of them separately.
Silverback takes one particular piece of usability testing and makes it dead simple. Until now, recording the screen during a usability session required using tools which were meant for different tasks like producing screencasts. Silverback, on the other hand, is dedicated to usability testing, and does this particular job extremely well.
You’re required to stay with the test subject —
In order to use Silverback, you are basically required to look over the test subject’s shoulder during the whole test. Having somebody constantly looking at your screen while you’re using an application can be annoying or even intimidating and thus influence the test results. Test subjects are often already somewhat nervous as it is, so we try to avoid such situations in our tests.
If you leave the room or move away from the test subject’s computer you can’t set chapter marks anymore. Silverback does not support remote testing. You can not run tests where the tester is in a different room or sitting far apart from the test subject.
Optimally, Silverback would come as two different applications, one for the tester and one for the test subject. The application running on the tester’s computer would show the test subject’s screen and allow the tester to add chapter marks with notes while the test is running. Unfortunately, such a solution could potentially harm Silverback’s simplicity.
Clearleft’s response to this is that such a feature would add complexity and development time and cost to the app, as it would require two-way voice chat as well as streaming the test subject’s screen and possibly iSight camera.
You can’t watch existing test sessions inside Silverback —
While being able to export test sessions as QuickTime movies is extremely important,4 there is no reason why it must be the only way of watching them. Since Silverback already keeps track of your projects and sessions, why not let me watch them within Silverback, where it is possible to dynamically switch between the two pictures as the situation requires?
Clearleft explains:
The screen data is stored as data rather than video, so requires compiling time before viewing. That means there’s no way of getting an instant playback within Silverback. In the beta, we showed a preview of only the iSight video (thinking that was better than nothing). We removed that from the release version as it turned out that this confused people, who were expecting a preview of what would be exported.
You can’t annotate Chapter Marks —
While it’s great that you can add chapter marks to your movie, you can’t add text to the marks. You will have to keep a separate log outside of Silverback, detailing what each chapter mark meant.
If you’re doing basic over-the-shoulder usability tests already, Silverback is an awesome application which makes your job so much easier. If you’re doing more sophisticated usability tests, Silverback is probably not yet of much use. Fortunately, Clearleft is considering adding remote tests, but strangely, they have “no plans” for allowing users to watch sessions within Silverback. If you can’t watch sessions within Silverback, the project and session management features become a bit pointless; why have these features if you have to store and manage the watchable session videos somewhere else?
Paul Annett from Clearleft told me:
If enough people want remote testing and previewing within the app, we’ll be sure to consider it
Having said that, Silverback is still a good, very clean first version of a potentially great application. It’s not yet suitable for every type of usability test, but the things it does, it does very well.
Silverback works in Tiger and Leopard and costs 50 bucks, which is a minuscule amount compared to other usability applications and makes it affordable for anyone. What’s more, 10% of profits are donated to saving the gorillas.
Nick Finck wrote a great review of Silverback on blueflavor.com, while Harry Brignull wrote one on 90percentofeverything.com. astheria.com has some inital impressions. mondaybynoon.com has another review. Jochen Wolters has yet another one. There’s a screencast on vimeo.com. Garrett Dimon has a conversation with Clearleft’s Andy Budd.
Note: This blog post was updated with some comments from Paul Annett, Senior Designer at Clearleft.
The application’s fantastic icon was designed by Jon Hicks, by the way ↩
Paul Annett explained it to me, writing “We’ve taken [the guerilla] analogy and used it in terms of usability testing - with Silverback runs in the background without the participant noticing, and allows quick and dirty usability testing. It’s not designed to be expensive and fully comprehensive. Also, guerilla allows us to make a great pun about gorillas.” ↩
And actually, the “for people who design and build websites” claim has now disappeared from silverbackapp.com, but the twitter page still says “Usability testing software for web designers.” ↩
Many usability tests require creating a movie with some of the issues found and solutions implemented, a kind of executive summary/usability ad. This movie is typically shown to management to explain the importance of usability testing and to show them that the money spent running all these tests is not wasted, but is used to improve the product in very real, tangible ways. Sometimes, such movies are also shown to engineering/R&D in order to convince them that the changes made to the user interface improved the application for end users, and to get them to buy into usability testing. ↩
In an essay titled “Welcome to iPhone: Your Crappy Mac of Tomorrow, Today!”, Mike Ash of Rogue Amoeba writes:
Code signing is used pretty much only for evil on the iPhone, and it could easily shift that way in Mac OS X as well.
In a response, Michael Tsai of C-Command Software writes:
I think most of what Apple has done is defensible.
Yes, the things Apple has done are defensible. They did these things for good reasons. Unfortunately, not good enough reasons. Apple’s reasons are not user reasons, they are content provider reasons. Pandering to content providers may help a platform in the short run, but the decreased usability which invariably results from such moves1 is incredibly harmful in the long run.2
Addendum: Matt Legend Gemmell disagrees, writing:
Fact is, pandering to content providers provides fucking content. It’s a continuing negotiation process between Apple and these providers, and we all know that Apple is about as politically bleeding-heart-liberal in its views on DRM as it possibly can be without gross fiduciary irresponsibility.
Given that Apple doesn’t even provide the option of selling non-DRM’d, unsigned or self-signed iPhone applications, I have to wonder about Apple’s “bleeding-heart-liberal” views on DRM. And pointing out that Apple is a business does not imply that they can’t be criticized for their actions just because said actions may make them money.
Still, the point about content providers being able to force Apple into providing DRM’d solutions is correct, and I should have spent more time discussing different aspects of this issue. I apologize for my poorly reasoned, one-dimensional blog post (in my defense, I mainly wrote it so I could link to Mike Ash’s and Michael Tsai’s posts) and resolve to do better in the future :-)
Maintaining the balance between DRM and usability is not easy, and I tend to agree with the notion that Apple historically did a swell job of it.
Finally, as somebody who has to maintain an application which provides an SDK, I understand the issues involved in providing stable APIs. I have absolutely no problems with Apple keeping parts of the iPhone’s API private if they are not yet mature enough for public consumption.
| more... |