Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 530

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-includes/cache.php on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-includes/theme.php on line 623
blog.gkaindl.com » Motion Perception and Interface Design

blog.gkaindl.com

nerd nouveau

Motion Perception and Interface Design

When you are designing a software interface, you have to take a lot of human factors into account that are somewhat difficult to describe. If you’ve ever done this before, you have probably fought with spongy requirements such as “easy to use”, “easy to learn” or “pretty to look at”.

However, there’s a whole other class of parameters you have to take care of: The way human perception works. The good thing about this class of design issues is that there are some tangible results from the fields of biology and psychology to draw from.

One interesting feature of this class is that you cannot “re-learn” or “un-learn” the natural ways your perceptive system works. As an example, you cannot un-learn to see color. Color perception is already hard-wired into your eyes and brain, and there is nothing that you can do about it.

Another feature of human perception, and the one I’m going to write about, is a strong bias towards perceiving motion. You may have noticed that your field of view magically gravitates towards areas of motion. For example, let’s think of a squirrel sitting on a tree. While it is sitting still, you may not even notice it, but as soon as it starts moving, you can spot it immediately. In fact, motion perception works very well even in your extended field of view, i.e. your peripheral view: You can even see very small motions to the far left or right of your head, without looking directly.

Of course, this behavior of our perceptive system is rooted in evolution: If you’re living in a world full of deadly animals and hostile tribes, seeing motion quickly (and therefore being able to react) is a useful ability. You want to dodge that club before it hits you on the head, even if it’s coming from the side. Nowadays, while the chances of being clubbed by a savage are considerably lower, we use the same mechanisms to be able to track a mouse pointer on the screen (Really, isn’t it amazing that we immediately know where the tiny thing is as soon as we move the mouse?).

Now when we design interfaces, we have to keep this strong bias of our visual system towards motion in mind.

Moving objects distract from non-moving objects

It’s as simple as that. However, that doesn’t mean it’s also simple to get it right. Moving interface elements are a good way to get a user’s attention, so the question is: Do we really want to draw attention to the moving element?

Save dialog in OS X

Pic. 1 - Dialogs in OS X
(Click thumbnail to zoom)

Let’s take a look at how modal dialogs are displayed in MacOS X. Rather than just appearing out of nowhere, there’s a cool “roll-out” effect (see Pic. 1). By using a motion effect to show the dialog, you get two things for free: First, your attention is immediately caught by the dialog while it’s still being rolled out. Since the effect takes some time (maybe a 3rd of a second), your cognitive system has enough time to evaluate the situation: You see which application window the dialog is coming from, you are prepared to be faced with a dialog before its even there (since the motion already caught your attention) and, best of all, if you happen to only glance at your monitor when the dialog rolls out, the motion effect is long enough to allow you to clearly pin-point its position. If the dialog just appeared without a motion effect, you would register the motion (i.e. the dialog popping up), too, but it would be too short to give your brain enough time to process the event: You may end up confused, knowing that “something just happened”, but you are not sure what, since you just registered a motion, but didn’t have enough time to bring it to the center of your view in time.

Mail.app Screenshot

Pic. 2 - Mail.app
(Click thumbnail to zoom)

The dialogs work great, however, the situation becomes a lot different when not distracting the user from non-moving content is a priority, but it’s still necessary to give feedback in another interface element that may currently not be the user’s focus. I think that Apple’s Mail application does a great job at this.

When we’re checking our mail, we’re focusing mainly on the text-area where the currently opened email is displayed. There may be a lot of mail to read, or an email may be particularly long. It’s possible that we are focused on this area for quite a while. However, Mail.app still has to check for new mail in the background. In fact, some people set it to check for new mail every minute!

Now we have a dilemma: We want to enable the user to read their email without any distractions, but we still feel the need to give the user some sort of feedback when the application is checking for new mail in the background. Mail.app solves this in a very elegant way.

Any moving element in the mail interface will distract the user from focusing on the mail text-area. But the question is, are we interested at all wether Mail.app is checking our inbox while we are already reading mail? In fact, we aren’t. So what Mail.app does is this: When we bring the application to the front or are navigating through the mail source list, it displays a little “pie chart”-like progress indicator next to a mailbox name while it is fetching data. It’s a very small and subtle use of motion. Rather than relying on the standard, fast-spinning progress indicator, the Mail.app indicator moves through only 2 or 3 frames. That’s very little motion, enabling us to focus on the text-area while still having a bit of motion feedback about the progress in our extended field of view.

Even better, if Mail.app already is the front-most application and we are not navigating the source list, Mail.app gives no visual feedback at all while it is checking for new mail in the background. Instead, if new mail is available, all messages will be added to the inbox together once they’ve been downloaded. This minimizes the distraction through motion to a single event: When the mail actually appears in the inbox! No useless “Hey, I’m downloading in the background while you are reading your mail” spinners.

However, if downloading email takes a long time and there’s currently nothing to display in the inbox (because the email subjects are still on the server), Mail.app shows the normal, fast-spinning progress indicator, signaling to the user that it is heavily working on getting the email. In this case, there’s nothing we could be distracted from.

Obviously, Mail.app handles all cases very well: It gives feedback when it’s downloading messages and we’re actually interested in it, but it lets us focus on the text-area when we want to, without distracting us with moving interface elements. Fabulous!

NetNewsWire screenshot

Pic. 3 - NetNewsWire feed refresh
(Click thumbnail to zoom)

Another favorite application of mine is NetNewsWire. As an RSS reader, it faces a similar dilemma as Mail.app, but I think that it is not resolved as elegantly here (see Pic. 3).

When refreshing the feeds, no matter wether the refresh has been requested by the user or not, NetNewsWire displays a progress bar in the bottom left corner of the interface. Additionally, as new feed items are being downloaded, they appear in the source list immediately: This happens by changing the “Unread items” amount next to the feed name in the source list as well as applying a font color to it (blue in case of my screenshot).

Let’s assume I’m refreshing the feeds manually: In this case, NetNewsWire succeeds at conveying to me that it’s downloading news items. I can literally watch the items appear in my source list, and I can track its progress by looking at the bar.

When we look at the alternate case, i.e. an automatic refresh while I’m reading my news, the problem becomes obvious: Lots of distraction by motion. First, we have the progress bar. It’s placed close enough to the text-area so that it becomes hard not to be distracted by it while reading a news item, especially given the fact that progress bars on the Mac have an additional “moving liquid” effect.

In the same vein, there is a lot of motion in the source list: As items get downloaded for each feed, the “Unread” count goes up, being changed multiple times during the downloading, and the feed names change into their “Has unread items” color. In short, the whole left part of the NetNewsWire interface exhibits a lot of motion during a background refresh while I’m trying to read the news.

To my mind, the best case to solve this was to take a look at Mail.app: If a refresh has not been requested by the user, they are probably not interested in the progress bar. Just download all new items, then let them appear in the source list at once. In this case, there would just be a single window of distraction during a background refresh, i.e. the appearing of the new items, as opposed to the way it currently works, in which an automatic refresh makes it hard to continue reading news while it is in progress. Having a preference item to change this would be awesome!

Disco screenshot

Pic. 4 - Disco smoke
(Click thumbnail to zoom)

Another application that shows how much motion can be distracting is Disco. While I want to stay out of the whole UI controversy surrounding it, it is obvious that the “Smoke” effect is quite distracting: It’s an animation that covers a big area and consequently draws a lot of attention to it. In fact, I find it hard to concentrate on another document while Disco is smoking on the same screen. Fortunately, Disco has a preference item to turn off the “Smoke” effect.

However, the tricky thing here is that everybody (including myself) actually enjoys looking at the “Smoke” animation, but at the same time, it’s too distracting to have it on during every-day disc burning. Obviously, I want to do something else while waiting for the disc to finish. Thusly, the “Smoke” effect is actually happening at the wrong time from a user interface design perspective, as it appears exactly then when the application does not need my attention. On the other hand, it’s a fun idea from an interaction design perspective (which is another thing than interface design). Roxio’s Toast, on the other hand, only displays a progress bar, which is a good trade-off between not being too distracting (as it’s a rather small area of motion) while still offering some feedback about the burning process (But, as previously said, the Disco “Smoke” effect can be turned off, too).

IGN.com screenshot

Pic. 5 - IGN.com - Video ads
(Click thumbnail to zoom)

Of course, such considerations are not only limited to application-, but also apply to web design, for example. Pic. 5 is a screenshot of IGN.com, a popular gaming-related website. On the front page, there’s a large image area in which video ads are displayed. This makes it very hard to explore the rest of the homepage, such as the various links to sub-sections, the headlines and other elements, especially considering that they are shown in a rather small font. The eye constantly gravitates towards the video wall. Text-based ads, while probably not generating as much revenue, would be the better choice from a design perspective. It clearly shows that, because motion bias is hard-wired into our brains, there’s no such thing as “just ignoring the video ads”.

As a last example, let’s have a look at Wii Play, specifically the mini-game “Find Mii”, where you have to find various combinations of Miis, such as which Mii is appearing twice in a scene.

I usually rock at this game (and for some reason, I really like it), but that changes quickly as soon as I’m playing with my girlfriend. In multi-player mode, there are two pointers on the screen, and each player has to click the Miis competitively. However, while I usually keep my pointer at the bottom of the screen until I’ve spotted the right Mii to click, she sweeps the screen all the time. This throws me off completely, as the constant, rapid movement on the screen is distracting me heavily from the actual scenery (see Pic. 6).

Wii Play Screenshot

Pic. 6 - Wii Play Multiplayer
(Click thumbnail to zoom)

Naturally, this is part of the game mechanics in this case, allowing you to move your pointer in a way that is especially annoying to the competitor, but it’s also an excellent example of how motion perception can be distracting from another task.

To bring this exceptionally long post to a conclusion, it is quite important to understand the strong bias towards motion perception in the human cognitive system and to take it into account during the interface design process. It is something that we cannot “unlearn”. You cannot assume that the users will just ignore the unnecessary animation if they find it distracting, or that they will not look at the flashy video ads anyways. It’s just not the way our brains work.

About

Hi, how are you? My name is Georg Kaindl, and I'm a twenty-something from Vienna, Austria. During the day, I'm a CS student at the Vienna University of Technology, but at night, I turn into an independent software developer for the Macintosh platform, social nerd, lazy entrepreneur and intuitive researcher.

I like to write about everything that matters to considerate technology enthusiasts, but humbly retain the right to go off-topic from time to time.

My posts are licensed under a Creative Commons Attribution 3.0 License.

Contact

You can reach me by email if you have something to say that's not related to a blog post or that you don't want to have publicly available as a comment to a post.

However, you'll have to prove that you are human! Even though I personally like robots very much, I'm less of fan of SPAM. It's just a simple riddle to solve, but a SPAM bot won't cut it!

To get my email address, take the word before the .com in my domain name first (Hint: The word you are looking for starts with a "g" and ends with an "l"). Next, simply attach @mac.com to this word.

Boom, there's my email address. Simple, isn't it?

Powered by WordPress

Comments RSS

Entries RSS