John Gruber at Daring Fireball:

Joel Spolsky recommends not disabling menu items in context where they can’t be used:

Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.

…
Spolsky’s suggestion is also predicated on the assumption that the user is stupid. Better is to assume that the user is clever and curious and will be able to figure out for themself why a certain command is currently disabled.

I don’t normally post “work related” things here, but daring fireball doesn’t have comments or anything that i can find, so i can’t comment there to disagree, so i’ll do it here! I generally agree with the things John posts, but in this case, i think he’s wrong, at least for some kinds of applications. I’d break the apps into a few categories, one based on frequency of use, and one on complexity.

High frequency+low complexity: Firefox, Internet Explorer, Safari, or any other web browser. You probably use it every day. If the back button is disabled, you know why. if the stop button is disabled, you know why. Fine, let them be disabled like Gruber wants.

On the opposite corner of the frequency+complexity graph are the products I work on. They are used for analysis and visualization of gene expression data (Rosetta Resolver), mass spectrometry based proteomics data (Rosetta Elucidator), or genetics data (Rosetta Syllego). They are used by people to analyze billions of datapoints which were generated by multi-million dollar instruments that ran continuously for weeks, after weeks of design, planning, biology and chemistry. (Yeah, all of our products have Rosetta at the beginning, and they also have longer names, like “The Rosetta Resover System for Gene Expression Analysis”, in the same way that Excel isn’t “Excel”, it is “Microsoft Excel”, but i digress…)

Some people use use our products every day, making them high complexity+high frequency. Their job might be to use our products and other statistics tools to analyze data, and that’s all they do. For those people, would be fine if some of the buttons or menu items are disabled when they don’t apply, because they know intimate details of how the system works.

But a lot more of out users are low frequency users: they might use one of the apps for a couple weeks to analyze data they have spent months gathering, get their results, write their paper, and then not use the app again for several months while they start planning and generate data for the next big thing they are doing. During that time, there might have even been a major upgrade to a new version of the application. When they want to perform a task, and the menu item is disabled, they don’t have time to be “clever” and try to “discover” why that the button that does their complicated thing isn’t enabled. They are too busy trying to cure cancer or some other thing to spend time trying to solve the mystery of why their menu item is non-obviously disabled. It is better to pop up a dialog telling them that some of 11,000 things they are looking for are still loading, and let them choose if they should be excluded from what they are trying to do or if they want to wait until later.

The alternative is a disabled button and a call to customer service, where a brilliant PhD user tries to explain to a support analyst that they can’t get their favorite tool to turn on.