Who killed the inactive button state?

Inactive buttons used to be a popular form control, but all that's changed in recent years. Chuck McQuilkin examines a handful of modern forms to dissect their new approaches.

In December of 1972, distraction killed 101 people. A flight crew became so absorbed with changing a lightbulb that they didn’t notice no one was flying the plane, not even the autopilot. The crew ignored multiple warnings including a 0.5 second buzz, an amber warning indicator and the beeping of the radio altimeter, all of which indicated that their plane was precipitously falling from the sky. Warning messages could not overcome their distraction.

Inactive button states – often a stand-in for “noisy” error messages – are just as bad. As Donald Norman once wrote “the best way [to] prevent user error is to make sure that the user cannot make errors in the first place or that the effects are easily reversible.” Inactive states and error messages are our tools of the trade to that end, but both have their shortcomings. Each disrupts the user and has the capability to break their flow. Online, where distraction is high (and time and attention are scarce) interfaces that lack inactive states can help designers minimize errors with less interruption.

Going grey

Everyone who’s used a computer long enough is familiar an error message, but what exactly is an inactive state? Simply, graphical user interfaces (GUIs) are composed of widgets, many of which can be enabled or disabled at any given moment. Disabled, “inactive” widgets are often presented in a lighter color or visually obscured in some other way.

Inactive states are vestiges of software rather than effective interface elements in their own right. The typical greyed-out menu item, for example, is as old as the desktop metaphor itself:

Photo of a legacy Apple Operating System

Is this useful information?

Inactive states seem harmless, but they pose a(n often infuriating) problem to users who can’t readily figure out why they’re presented the way they are. Inactive elements cannot “speak” for themselves and can therefore never explain why they’re inactive. This introduces a real potential for confusion into our designs.

Fortunately for the denizens of the web, though, inactive interface elements have become increasingly less common. This probably something to do with the proliferation of modal interface design.

Mommy, where do modes come from?

A mode is a change in the method of operation of a device or piece of software. Modes and inactive states are related because designs that incorporate inactive states are perceptually “less” modal.

Consider Apple’s Activity Monitor, which displays inactive buttons when no process is currently selected:

You can probably guess what this application looks like when you select a process. Activity Monitor’s two modes are communicated by way of its button states. In direct contrast to this is Dropbox’s interface. Dropbox eliminates inactive states altogether, instead opting to display file-specific buttons directly next to the currently selected file.

When the user de-selects the file, the options disappear:

Which interface feels more cluttered to you? More difficult? There are certain trade-offs between hiding controls and displaying inactive buttons. Personally, Dropbox’s approach feels more intuitive than Activity Monitor’s because of the use of progressive disclosure.

Back in 2000, user interface pioneer Jef Raskin suggested that “[modes] are a significant source of errors, confusion, unnecessary restrictions and complexity in interfaces.” Modal windows are the most common place we find modes on the web today. They’re hard to miss because they inactivate and grey-out the entire web page or application. This design paradigm is intrusive and it often fails to explain (there’s that pattern again) to users why they cannot access the rest of the interface.

As a consequence, modern websites have begun to substitute overlays or dialog-like windows that don’t obscure the content underneath. Dropbox’s sign-in dialog is a good example:

Alternate approaches

A toggle switch makes it easy to understand that a particular item is unavailable, but it still doesn’t help the user know why.

Apple’s latest operating system, iOS, has led the way in eliminating inactive buttons. Given the fact that iOS apps are confined to a single window and that they lack menu-bars, the OS is almost designed to eliminate them. When inactive elements are required, though, Apple recommends using a built-in switch that combines the grey inactive desktop metaphor with the physical metaphor of a toggle switch.

Always active buttons

The web of the mid-90s had a love affair with inactive submit buttons. Greyed out on page load, they would immediately become active once the user had filled in all required form fields. More recently, though, designers have opted for alternate solutions.

If you go to Google’s iconic search page and click “I’m feeling lucky” before you’ve entered anything in the search box, you’re likely in for a surprise. Instead of an error message or an inactive state Google’s presents you with gallery of homepage doodles:

Over on Twitter’s homepage page things are even more interesting. Click Twitter’s sign in button without entering anything into the form, and you are taken to the login page. Smart. The login page’s sign in button lacks an inactive state. It simply does nothing if you try to submit a blank form.

Twitter’s sign up form behaves a bit differently. If you try to submit Twitter’s sign-up form without filling in any fields you get three error messages in red near the email, password and username fields. Rather than becoming a grey inactive button, the “create my account” button
shakes back and forth. At least in the West, the quick shake of the button is enough by itself to clearly communicate “no.”

Communicating an inactive state with a gesture

A subtle art

Buttons miming human gestures might seem odd, but it’s increasingly par for the course. Dan Eden has put together a demo page with all the different ways CSS3 can be used to enable designers to communicate to users with gestures rather than words.

Finally, some designers are going as far as providing additional information within their inactive buttons. For example, Google Chrome displays broken plugin icons over content rendered inactive by missing or disabled plugins. These icons don’t just communicate that something is inactive, they attempt to explain why.

Communicating an inactive state with a shape

Although user experience design plays a crucial role in making online commerce efficient, rarely does a mistake within a web interface have life or death consequences. There are certainly lots of ways for designers to deal with errors. As Norman wrote in n for “noisy” error messages – are just as bad. As Donald Norman once The Design of Everyday Things: “The critical thing is to approach the topic as a cooperative endeavor between person and machine…with misconceptions on either side.”

Go ahead and experiment with eliminating redundant error messages and inactive states. Let your users explore, skip ahead and break things. Just always remember to include an “undo!”

About the Author

Chuck McQuilkin

Chuck is a user experience designer with RPA in Santa Monica. He is also recent AD graduate of the VCU Brandcenter and has experience as an art director and web designer. His other car is a mountain bike. You can follow him on twitter at @chuckmcquilkin.

Related Articles

15 Comments

  • Rob T. Reply

    The big advantage of an inactive button state (Activity Monitor) over the contextual buttons (Dropbox) is that the inactive states let the user know something can be done, as opposed to dropping them in a bling user interface with no idea what they’re looking at, or what they can do. In Activity Monitor, the dimmed buttons will lead people to making the logical leap that they might want to click around to see how to activate the buttons over the Dropbox interface, which to a new user, looks like a list of files, similar to what they’d see in the Finder/Explorer/Browser, with no expectation that there’s anything extra to be found by clicking on a file. Granted, the original dimmed menu item (OS 7) wasn’t as helpful because you had no idea how to enable that button, but having visible and dimmed buttons does lead the user to explore a bit as opposed to having no obvious interactions. Either way, though, it’s a lot better than an active button that pops up an error dialog box if you try to access it without the proper context (I’m looking at you Windows).

  • Jai Reply

    In most cases, I’d agree that the inactive state is more confusing than useful… though, I wonder if there are times that the inactive state tells you something you wouldn’t know otherwise… as in “there is this other option/mode that you wouldn’t even know was here without exploring”. There is likely a balance to be had based on the situation/delivery method.

  • Rob T. Reply

    As long as we’re on the topic of User Experience, a Preview Comment button would have let me catch that “bling” that’s supposed to be “blind”.

  • Flavio Curella Reply

    I agree that inactive states contribute to cluttering UIs and their use has down-sides, but I still think that they have some advantages in some cases, like in menus and such.

    For example:
    * they show to the user what *could* be possible – they provide affordance
    * they keep the interface (in menus, this means the order of the menu items) consistent so that the user can memorize where each item is.

  • Chad Burt Reply

    There is a lot of good rationale here, and it has certainly made be think carefully about some of the work I’m doing right now. After some thought though, I don’t agree that eliminating inactive button state is often a good idea.

    Inactive menu items, buttons, etc give an indication to the user that actions will be made available when the application is in a certain state. For many use cases these can be important affordances. It can be frustrating to not know what that state is, but tooltips or other features can indicate that. Furthermore, inactive buttons are often related simply to selection state, and I think this is commonly understood (I’d love to see some research).

    Let me take another perspective on your dropbox example. I’m looking at the list of files and I’m not sure how to share something. I may be able to right-click and get a context menu, but that isn’t commonly supported on the web. I could guess that buttons will appear when I click on a file, but that might just trigger the (potentially slow) loading of the file or a new page. My only option is to play around blindly and see what happens. This seems far worse than dealing with “clutter”, which is really just a problem with execution.

  • Scott B Reply

    Seems the decision to have inactive action elements should be guided by relevant and contextual affordance rather than the single-minded approach of removing every unavailable action from view.

    • Chuck McQuilkin Reply

      Well said. I agree that the design decisions surrounded inactive button states are complex and need to be solved on a case by case basis. Dropbox’s new interface isn’t going to work for everyone, but it’s interesting that they tried something different.

  • Vesa M Reply

    I have found that to kill or not inactive controls is a very tricky decision. Some people get more confused about controls disappearing with the state than having something visible but not functioning. (and another way around).

    For example in Dropbox case I just witnessed 15 min of struggle of a person trying to find out where to find file revisions. (Nothing in the new design hints to how the list elements function, clicking file name downloaded the file and did not result with tools).

    If I would be a millionaire I would fund a research to find out demographics on who’s brains work better with vanishing controls and who’s with disabled.

  • mpt Reply

    The only reason Dropbox’s sign-in overlay doesn’t “obscure the content underneath” is that, on most of their pages, there isn’t anything underneath. When there is, it does. But that has nothing to do with inactive buttons.

    The iOS switch widget is roughly the mobile equivalent of a checkbox. Maybe the grey color scheme misled you, but it is just as tappable when in that “OFF” state as in the “ON” state. So that has nothing to do with inactive buttons either.

    And the Google Chrome plugin icon is not a button at all. You may be thinking of its progenitor in Netscape, which was clickable and took you to the page to download the relevant plugin. But that has nothing to do with inactive buttons either.

    It’s a shame this article was confused by those unrelated elements. A relevant, recent, and simple example to start off with would have been Firefox’s Forward button – which since version 10, disappears altogether instead of becoming inactive. Good thing? Bad thing? That would have been an interesting discussion.

    But since you started with a screenshot of classic Mac OS, why not mention its Balloon Help system, an early form of tooltips? Apple’s guidelines told developers to add a balloon not just for active controls, but inactive ones too: “Not available because you do not have permission to alter this file”, “Not available because this monitor does not support color”, and so on. Microsoft had similar guidelines for Windows 98 and 2000. Why did they both change their minds? As you showed with Activity Monitor, it isn’t because they stopped using inactive buttons.

  • Becker Reply

    I think both methods are issues of discoverability. We should ask ourselves which method is more effective in telling the user, ‘this is the state my application needs to be in for this particular feature to be available’. Using the Firefox Forward button as an example, is it more effective for to present the user with the forward button without going back to a previous page or is it more effective for the user to discover that they have the ability to undo their this action when they have reached this state? Personally, I am a fan of having features appear only in states they are applicable. I also feel that not being able to find the button for a particular feature can be just as frustrating as trying to get the application into a state that activates the button for said feature.

  • martin sandstrom Reply

    the Submit comment on this site would benefit from getting a Twitter-button treatment ;)

    Even though I gotta say I prefer a dimmed out, inactive button before an active one that does nothing. It’s all about affordance.

  • Aaron Reply

    In my opinion inactive button states can be just as confusing as them not being there, when they are greyed out etc, you often just end up wondering why that is.

  • Ankur Jalota Reply

    For the purposes of dropdown menus and toolbars, I think it would be more useful to have a mechanism to communicate why it is disabled – like placing a tooltip adjacent to the disabled item.

    If one tries to eliminate disabled states too much, you end up having an interface where the user has to hunt for functionality everywhere.

  • David Hamill Reply

    The context and frequency of use are pretty vital considerations here. An approach that works for an interface that will be heavily used may not be as applicable to one that is used infrequently.

    On a different point, I’ve worked on many websites that use inactive buttons for the primary function of the page because a sequence of events is required before it can be pressed. Often such buttons shouldn’t actually be inactive, they should just (arguably) look as though they are.

    Let’s take the Twitter example. The button does nothing if you press it without filling out the fields. This is probably acceptable because the form is so simple. But if it were less straightforward a form, doing so would be annoyingly unhelpful. Pressing an inactive button can be a signal that the user doesn’t actually understand what’s expected of them. So it’s an opportunity to identify these people and give them some advice. In such cases the user should be told what they need to do before they should press the button.

Leave a Comment on This Article