Don't Click It
A former colleague of mine at the University recently sent along a link to dontclick.it, a Web site that bills itself as an experiment in new user interface concepts. I found the site intriguing, and recently spent some time working through its material and thinking about the consequences of this approach for the user. The following article uses dontclick.it as a springboard for thinking about some of the essential principles of Web user interface design.
The premise of dontclick.it is to entirely replace the action of clicking the mouse button with UI widgets that can be activated by simply dragging and hovering the cursor over the desired element. This unconventional behaviour is accomplished on the Web using Flash animations. As expected with most Flash sites, the graphic design is clean and appealingly simple. In terms of content, the site provides some background information regarding the intent of the experiment, as well as a number of prototype "click-less" interface widgets and interactive elements. My sense of the site overall is that it was perhaps developed as a project for a college-level design course. While the writing and overall conceptual premise strike me as lacking depth and sophistication, it's an interesting forum to start thinking a bit about the nature of current GUI design. I suggest you check it out for yourself before reading on.
If dontclick.it was intended as a model for new approaches to user interface design, there are a number of key areas where I feel it is ineffective, often falling short of even being useable. Foremost among these is the fact that the design is entirely based around the mouse. This a priori assumption that the mouse is the only option for user input is a profound miscalculation, particularly in the case of the Web. The site designers have neglected the possibility that their users won't be using a mouse exclusively to navigate the site. Indeed, consistent keyboard access is one area where the Web excels in terms of useability, and even the most able users are accustomed to using a blend of keyboard and cursor input. Beyond that, visitors using portable or handheld devices, people with motor impairments, and those of us who already spend too much time making the painfully repetitive movements required by the mouse simply won't be able to use the dontclick.it interface.
The lack of flexibility and adaptability of the design—particularly in its inability to accommodate a variety of input devices—represents a major step backwards and is ultimately a serious barrier to broad usage. In effect, the design is dead in the water from the beginning because of its mouse myopia.
Still, let's go ahead for a moment and try to follow the logic of the site's designers. Let's assume that all of our users are only ever going to use the mouse. Given this, it seems worthwhile to look at what benefits the mouse button provides for to the user, and ask ourselves if the dontclick.it approach offers any improvements.
The mouse click is a very direct and unambiguous control mechanism. Button widgets in most traditional GUIs provide a real-world metaphor to which the user can apply existing expectations about their behaviour. It should be simple; you press a button to activate it. On the other hand, dontclick.it replaces the mouse click with timer-controlled cursor hovering. A user needs to move the mouse over the abstract widget—which may or may not be recognizable as a control—and wait several seconds until the GUI responds to the command. The result of activating a dontclick.it control is a long animation sequence in which the widget shifts out of the way to expose new controls which were previously not visible.
Exploring this behaviour more closely, the dontclick.it site contains a section called the "ButtonLab" which presents a number of proposed click-less interface controls. It allows the user to experiment with the buttons and also describes some benefits and drawbacks for each. I think that this section is the most important aspect of the site, and can provide some insight into the underlying problems of the design. I applaud the site's authors for their ability to provide some considered self-criticism, and I'll use their own words to outline several of the underlying problems.
Drawback #1:
"Chances are high that you unintendedly [sic] activate a button by accidentally moving your mousepointer over it."
Clearly it is very easy to unintentionally trigger a control or selection within dontclick.it. The key here is the fact that the user interface elements are time-based and constantly shift around the screen, moving completely out of the user's control. To make matters worse, an accidental selection in this interface will inevitably involve waiting for a tediously slow animation to complete fully before being able to go back and correct the mistake.
This heavy use of animation is, as far as I can tell, a workaround for the lack of distinct pages or layers in the UI. Every widget exists in a limited, two-dimensional space, and the navigation mechanism is closely coupled to the page content. Unlike traditional scroll bars which are positioned to the side of the content, in this navigation space the cursor regularly gets in the way of actually reading the site's content. Often, an attempt to move the cursor out of the way in order to see the content unobstructed will cause the section to be deactivated, further slowing down the time it takes to use this site.
A case in point here is the survey questions which randomly pop up on the site, requiring a response from the user. The click-less interface makes this into a dangerous kind of modal dialog box, because it can easily be activated accidentally by a user who doesn't move their cursor out of the way quickly enough. My sense is that any survey results they've collected probably reflect this accident-prone design more than any meaningful statistics.
Drawback #2:
"The user has to be initially shown how to activate a button since this kind of navigation is not obvious."
As mentioned above, buttons don't behave like this in the real world. By continuing to use iconic buttons, while actively preventing them from being pressed, the site ignores all of the real-world knowledge a user brings to the situation. Given the complexity of all modern GUIs, why further confound the user with controls that look like what they expect, but don't behave like anything they've ever used before?
Drawback #3:
"This concept of navigation slows down the speed at which content is activated and thus ready for consumption."
Timing is important. Although the dontclick.it experiment is clever and well-decorated, it is tiresome and time-consuming to use. Efficiency of the user is a first principle of user interface design, yet the dontclick.it site requires them to slow their normal rate of productivity down to a glacial pace.
Furthermore, there's no consistency throughout the site in terms of timing conventions. Some UI elements shift very quickly, while others—such as the buttons in the ButtonLab—require painfully slow wipes to activate.
The Autopilot section of the site is truly a great idea. It records the first twenty seconds of a previous user's session, providing a document for how new visitors to the site respond to the interface. In nearly each case, the recordings show a user desperately scrubbing the mouse across the screen in an attempt to find familiar Web user interface cues. Watching just how little is accomplished in twenty seconds due to the glacial but eye-catching animations is indeed enlightening.
It's a curious exercise to see how Fitts' Law is applied (or not) throughout the dontclick.it interface. As a refresher, human interface guru Bruce Tognazzini defines Fitts' Law as "the time to acquire a target is a function of the distance to and size of the target."
Based on this, I like the fact that some of the icons and controls of dontclick.it are large, obvious, and thus easily aquired. But there's a deeper problem that once again relates to the heavy use of animation. Generally, when a dontclick.it control is activated, it causes all of the elements to shift radically across the screen in order to make room for a new set of navigation controls. As a result, the user is constantly chasing widgets across the screen, none of which is ever close to the current position of the cursor. The lack of any screen boundaries within the browser sandbox—a problem inherent with the Web—makes it even more time-consuming to acquire a target.
In the end, I think the problem with the dontclick.it experiment is that the site's authors were asking the wrong questions. As they put it, the core question that the site attempts to answer is "do we miss the click?" Given the simplicity and lack of ambiguity of the mouse, this doesn't strike me as the most insightful of questions in regards to Web user interface design.
With all the exciting developments in standards-based rich Web interfaces—especially AJAX and Google Maps-style interfaces—and the distinct need to improve Web useability and standards overall, why not start with the basics? Start with questions like "am I using the existing standards to their fullest extent?" and "is my site clear, accessible, and useable all visitors?"
Okay, so this article hasn't so much been about the potential for a click-less interface, nor was it really about the dontclick.it Web site. But it has provided an opportunity to consider—in a rather preliminary way—the nature of the graphical user interface and its relationship to the mouse itself. Although I use a computer with only one mouse button, and feel like one is more than enough, the whole issue seems topical given the popularity of multi-button mice and the recent announcement from Apple of their first such mouse.
As a summary, I'll leave you with my top five concerns with the notion of a click-less interface, at least as implemented by dontclick.it:
Questioning Existing "Habits"
The premise of dontclick.it is to entirely replace the action of clicking the mouse button with UI widgets that can be activated by simply dragging and hovering the cursor over the desired element. This unconventional behaviour is accomplished on the Web using Flash animations. As expected with most Flash sites, the graphic design is clean and appealingly simple. In terms of content, the site provides some background information regarding the intent of the experiment, as well as a number of prototype "click-less" interface widgets and interactive elements. My sense of the site overall is that it was perhaps developed as a project for a college-level design course. While the writing and overall conceptual premise strike me as lacking depth and sophistication, it's an interesting forum to start thinking a bit about the nature of current GUI design. I suggest you check it out for yourself before reading on.
The Mouse, A Priori
If dontclick.it was intended as a model for new approaches to user interface design, there are a number of key areas where I feel it is ineffective, often falling short of even being useable. Foremost among these is the fact that the design is entirely based around the mouse. This a priori assumption that the mouse is the only option for user input is a profound miscalculation, particularly in the case of the Web. The site designers have neglected the possibility that their users won't be using a mouse exclusively to navigate the site. Indeed, consistent keyboard access is one area where the Web excels in terms of useability, and even the most able users are accustomed to using a blend of keyboard and cursor input. Beyond that, visitors using portable or handheld devices, people with motor impairments, and those of us who already spend too much time making the painfully repetitive movements required by the mouse simply won't be able to use the dontclick.it interface.
The lack of flexibility and adaptability of the design—particularly in its inability to accommodate a variety of input devices—represents a major step backwards and is ultimately a serious barrier to broad usage. In effect, the design is dead in the water from the beginning because of its mouse myopia.
Still, let's go ahead for a moment and try to follow the logic of the site's designers. Let's assume that all of our users are only ever going to use the mouse. Given this, it seems worthwhile to look at what benefits the mouse button provides for to the user, and ask ourselves if the dontclick.it approach offers any improvements.
The mouse click is a very direct and unambiguous control mechanism. Button widgets in most traditional GUIs provide a real-world metaphor to which the user can apply existing expectations about their behaviour. It should be simple; you press a button to activate it. On the other hand, dontclick.it replaces the mouse click with timer-controlled cursor hovering. A user needs to move the mouse over the abstract widget—which may or may not be recognizable as a control—and wait several seconds until the GUI responds to the command. The result of activating a dontclick.it control is a long animation sequence in which the widget shifts out of the way to expose new controls which were previously not visible.
Self-Described Drawbacks
Exploring this behaviour more closely, the dontclick.it site contains a section called the "ButtonLab" which presents a number of proposed click-less interface controls. It allows the user to experiment with the buttons and also describes some benefits and drawbacks for each. I think that this section is the most important aspect of the site, and can provide some insight into the underlying problems of the design. I applaud the site's authors for their ability to provide some considered self-criticism, and I'll use their own words to outline several of the underlying problems.
Drawback #1:
"Chances are high that you unintendedly [sic] activate a button by accidentally moving your mousepointer over it."
Clearly it is very easy to unintentionally trigger a control or selection within dontclick.it. The key here is the fact that the user interface elements are time-based and constantly shift around the screen, moving completely out of the user's control. To make matters worse, an accidental selection in this interface will inevitably involve waiting for a tediously slow animation to complete fully before being able to go back and correct the mistake.
This heavy use of animation is, as far as I can tell, a workaround for the lack of distinct pages or layers in the UI. Every widget exists in a limited, two-dimensional space, and the navigation mechanism is closely coupled to the page content. Unlike traditional scroll bars which are positioned to the side of the content, in this navigation space the cursor regularly gets in the way of actually reading the site's content. Often, an attempt to move the cursor out of the way in order to see the content unobstructed will cause the section to be deactivated, further slowing down the time it takes to use this site.
A case in point here is the survey questions which randomly pop up on the site, requiring a response from the user. The click-less interface makes this into a dangerous kind of modal dialog box, because it can easily be activated accidentally by a user who doesn't move their cursor out of the way quickly enough. My sense is that any survey results they've collected probably reflect this accident-prone design more than any meaningful statistics.
Drawback #2:
"The user has to be initially shown how to activate a button since this kind of navigation is not obvious."
As mentioned above, buttons don't behave like this in the real world. By continuing to use iconic buttons, while actively preventing them from being pressed, the site ignores all of the real-world knowledge a user brings to the situation. Given the complexity of all modern GUIs, why further confound the user with controls that look like what they expect, but don't behave like anything they've ever used before?
Drawback #3:
"This concept of navigation slows down the speed at which content is activated and thus ready for consumption."
Timing is important. Although the dontclick.it experiment is clever and well-decorated, it is tiresome and time-consuming to use. Efficiency of the user is a first principle of user interface design, yet the dontclick.it site requires them to slow their normal rate of productivity down to a glacial pace.
Furthermore, there's no consistency throughout the site in terms of timing conventions. Some UI elements shift very quickly, while others—such as the buttons in the ButtonLab—require painfully slow wipes to activate.
Mouse Movement Recording
The Autopilot section of the site is truly a great idea. It records the first twenty seconds of a previous user's session, providing a document for how new visitors to the site respond to the interface. In nearly each case, the recordings show a user desperately scrubbing the mouse across the screen in an attempt to find familiar Web user interface cues. Watching just how little is accomplished in twenty seconds due to the glacial but eye-catching animations is indeed enlightening.
If the Glove Fitts
It's a curious exercise to see how Fitts' Law is applied (or not) throughout the dontclick.it interface. As a refresher, human interface guru Bruce Tognazzini defines Fitts' Law as "the time to acquire a target is a function of the distance to and size of the target."
Based on this, I like the fact that some of the icons and controls of dontclick.it are large, obvious, and thus easily aquired. But there's a deeper problem that once again relates to the heavy use of animation. Generally, when a dontclick.it control is activated, it causes all of the elements to shift radically across the screen in order to make room for a new set of navigation controls. As a result, the user is constantly chasing widgets across the screen, none of which is ever close to the current position of the cursor. The lack of any screen boundaries within the browser sandbox—a problem inherent with the Web—makes it even more time-consuming to acquire a target.
Asking the Wrong Questions
In the end, I think the problem with the dontclick.it experiment is that the site's authors were asking the wrong questions. As they put it, the core question that the site attempts to answer is "do we miss the click?" Given the simplicity and lack of ambiguity of the mouse, this doesn't strike me as the most insightful of questions in regards to Web user interface design.
With all the exciting developments in standards-based rich Web interfaces—especially AJAX and Google Maps-style interfaces—and the distinct need to improve Web useability and standards overall, why not start with the basics? Start with questions like "am I using the existing standards to their fullest extent?" and "is my site clear, accessible, and useable all visitors?"
Summary
Okay, so this article hasn't so much been about the potential for a click-less interface, nor was it really about the dontclick.it Web site. But it has provided an opportunity to consider—in a rather preliminary way—the nature of the graphical user interface and its relationship to the mouse itself. Although I use a computer with only one mouse button, and feel like one is more than enough, the whole issue seems topical given the popularity of multi-button mice and the recent announcement from Apple of their first such mouse.
As a summary, I'll leave you with my top five concerns with the notion of a click-less interface, at least as implemented by dontclick.it:
- The user interface elements move significantly outside of the user's control. Targets shift when you get close to them, requiring slow, large-scale mouse gestures to accomplish basic functions.
- Because the navigation mechanism is so closely bound up with the content, the cursor consistently gets in the way of actually reading the content, unlike with a scroll bar. In many cases, an attempt to move the cursor out of the way will have the drastic effect of deactiviting the current section of the site, thus slowing the process of reading down to a frustrating crawl.
- Animations are slow to respond to the position of the cursor, and there is no way to easily cancel an operation as you can with a mouse click. This makes it very easy accidentally activate or deactivate a navigational element, requiring the user to wait for the animation before being able to correct the mistake.
- Important dialog boxes can be activated accidentally based on the position of the mouse alone, without any input from the user.
- Unlike a click-based interface, it's entirely impossible to navigate without the mouse.
posted by Colin Clark at 5:30 PM
