Fog Creek Software
Discussion Board

Is there a term for this?

We have a dialog where you need to check some list items before clicking a 'Generate' button to execute calculations on the checked items.

I set it up so that the button would be disabled if no items were selected, and would enable when items were checked.

My manager suggested we enable the button, and warn if no items were selected.  I don't want to do that -- I'd rather rename the button 'Generate Checked Items' than create what I'd call 'User Interference' (as opposed to User Interface').

Does User Interference sound good, or is there another name?

Frank "Grimey" Grimes
Friday, August 20, 2004

I like your manager's comment. It annoys me when an button or menu item that I want to press is disabled, and I can't figure out what I must do to enable it: by enabling it, you have an opportunity to present a helpful dialog ("I realize that you've just pressed the button, but really you should select some items first before this will have the effect you desire").

Christopher Wells
Friday, August 20, 2004

"pissing people off" is the normally accepted term, though there does need to be a term for it, lots of people here are keen on the 'here is a tit-bit of information about the software I sell / support / develop I have just discovered and I now think that the users, who probably know a lot more about the software than I do, should have a message box inflicted on them every time this particular sitiation arises, even though I have got one after about 8 months and they will probably get 50 a day' approach to UI design which I think it strongly related to what you are talking about

Harvey Pengwyn
Friday, August 20, 2004

Don't disable a damn thing.  If the SOB user clicks the damn generate button and nothing is checked simply pop up a Message Box saying 'No items selected.'  Then, when they click the ok button on the msgbox they default back to the screen.

Was that so difficult Grimes?
Friday, August 20, 2004

Actually I agree with the OP.

While the first time this may be annoying (ie why can't I click the button...). If a user uses this more then once and is presented with a dialog box for every becomes annoying.

However I do agree anothe way could be found.
It is 2am in the morning here, so don't take my suggestion with too much seriousness, it could be crap when I wake up!

However about some sort of display on the form that makes the user aware of what is needed to continue. I mean really, we all deal with this sort of disabled button when we install programs (ie the 'next' button is so often disabled until we fill in the required fields).

Aussie chick
Friday, August 20, 2004

If the 'Generate' button performs its generation, after which the user continues down the form before clicking 'OK' to close it, the disabling is fine.  If 'Generate' effectively closes the form, then it needs to be enabled, and a messagebox stating something along the lines of "You have no items selected for generation - Please select at least one item before clicking 'Generate', or just click 'Cancel' to exit this task".

Greg Hurlman
Friday, August 20, 2004

I don't know if such a term exists, but User Interference indicates that the User is causing the interference, to me at least.

I much prefer disabling buttons that don't do anything. In this case, a simple "Select one or more items for calculation" message would help the user along, instead of having to close pop-ups every time they did something inappropriate.

In my experience, it's much better to help the User using information on the panel itself, instead of correcting them through error/warning messages. Getting many of these messages can quickly frustrate a user.

Friday, August 20, 2004

The Generate button does close the dialog.

I think there is something wrong with giving the user an option to do something you know is an error well in advance.

Clicking a button that won't do something doesn't help the user get their work done.  Another message box telling them they did bad doesn't help them get work done.

My opinion is if there is ambiguity, then there's problem with the dialog, and it shouldn't be pushed off to users.

I thought about renaming the button, but I hate long buttons.  I will likely add a text message about checking items before clicking generate.

Frank "Grimey" Grimes
Friday, August 20, 2004

We have actually thought of having an 'enable the buttons and menu items then tell me why the action can't be done' mode in our software.

Sometime the actions and the conditions for them being enabled can be quite esoteric.

Then, of course,  there is the danger that the users won't find / won't be told about / won't read about the mechanism for changing the mode and be annoyed for ever after that this is the way it works...

Harvey Pengwyn
Friday, August 20, 2004

Get rid of the "Generate" button.  Instead, show the results alongside the list.  When the user checks a list item, immediately update (or start updating if it's a long operation) the results based on the new selection.

rob mayoff
Friday, August 20, 2004

Disable the button, but when you hover over it, pop up a tooltip "You Need to Enter some Info First".

No messageboxes, it's 2004.

Friday, August 20, 2004

If it doesn't take ages to refresh the screen, the suggestion about doing away with the button entirely is the right one.

Otherwise, this is easy... have something selected by default. Then if the user unchecks all boxs, and the button is greyed out, it's obvious what is necessary to re-enable the button.

I'm never a fan of giving users a button or menu that _looks_ like it does something, when in fact, it presents a message saying "You can't do that".

Rob VH
Friday, August 20, 2004

I agree with Alex.  Disable the button, but explain why its disabled with a tooltip.  When less savvy users get messageboxes, they sometimes think the software is broken.  That probably has a lot to do with the Windows sounds, and that they will hear the same obnoxious noise if they prematurely click the Generate button as they do when they get the illegal operation error right before they shut down and lose 3 hours of work. (Assuming they have speakers turned up, and it always seems like less savvy users play music CD's on their computer.)

"User Interference indicates that the User is causing the interference"

Not necessarily.  In football, Pass Interference does not refer to the pass interfering with the receiver.  I think User Interference is clever enough.  Grimey should blog about it and preserve himself some credit for coining the phrase.

Clay Whipkey
Friday, August 20, 2004

No argument there Clay I just meant that that's the first thing that jumped in my head.

How many phrases do we need that mean "Bad Design"? ;-)

Friday, August 20, 2004

Aussie Chick says:
> If a user uses this more then once and is presented
> with a dialog box for every mistake...
> it becomes annoying.

I should think if the user is so stupid as to get the same warning message over and over again, he/she really needs it. My vote goes for the boss. Enable it and pop up a Msgbox for dummies.

Friday, August 20, 2004

Electrify mice so users can be severley punished for to omanty stupid clicks....

Friday, August 20, 2004

or to omanty typos  :)

Friday, August 20, 2004

Without seeing your screen, I have yet another suggestion:
"Hide the button until the user has checked off the items"

But the best thing would be to get some users to try the form and see what they do.

Friday, August 20, 2004

I think virtually any UI designer would tell you that users should be prevented from performing the task (i.e., the button should be disabled) rather than presented with an error message after clicking it.

I'd go further and wager you could pick up any decent usability book and it would include this recommendation, thus bolstering your case.

Or try this. Open the Save dialog in Word, Excel, etc. Delete the file name. Notice that the Save button is now disabled, because you can't save a file without a filename.

Having an apparently active button that doesn't actually do anything except insult the user is a recipe for frustration. Don't do it.

John C.
Friday, August 20, 2004

What great topic here.

I see nothing wrong with giving the user a dialog box.

In the case of the button being disabled, then I do think that “most” users will learn that to highlight a box, something “has” to be done, but then how do they discover this answer?

The example showed (word’s “save as” dialog) being disabled might not be a fair comparison, as you talking about users navigating a menu hierarchy (but then again, it might be a fair comparison!!). Navigating a menu hierarchy is a different UI problem then that of a button on a form…but they certainly share many same concepts.

However, one can easily make the case that if you did click on the save as with no document, a message explaining that you need to create a document likely would be far more user friendly then simply confusing the user as to why the save as button is broken. Further, you could at that point actually ask the user if they want to create a document (or save a blank document!). This is far more user friendly then some poor sop who has to now figure out why the save-as button is broken.

So, the best case for keeping the button enabled is that you can then take action and DEAL WITH the reason as to why the action cannot be taken.

So, you can help the user create a that new document, or perhaps offer a dialog to select all options

    No category’s selected…report on all of them?
                      (yes)              (no)

So, the advantage here is that you can take action based on a user mistake, where if you disable the button, then you can’t help the user much at all. You might have some lame bubble help, but that is passive helping the user…not active helping the user.

Further, depending on your development tools, context driven menu bars might be a pain…and thus I would accept some dialog box explain why the option/feature can’t be used (but even better then the dialog is to have the code deal with “why” the button can’t be used!).

If you disable the buttion, then you don't have to write code to explain the problem, or write code to deal with the problem.

I think often a button is disabled to save programmer and development time, not because it is a better UI.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Friday, August 20, 2004

But it's not the *user's* mistake that they don't know what to do.  It's the programmer's mistake they didn't provide the right affordances (to steal terminology from Joel's writings).  It's 'wrong' to push the programmer's bad design to the user.

After discussing this with some others, we have figured out the real problem: the Generate button is in the wrong place.  The checkedlistbox is on the left in a column, and Generate is bottom right where you'd normally find OK/Cancel.  (Right column contains settings for the list items).

I'm currently refactoring the UI to correct this.  Yes, it'd be easier at this point to put in the message box, but I'm not against a wall on time, and I can't let myself take the easy road out.

Frank "Grimey" Grimes
Friday, August 20, 2004

Users learn things easier if the behaviour is consistent to other things they experience.

What happens on your TV if you use the remote to change to the channel you are already on?  The TV just does it and doesn't comlpain  that is where you already where.

Press an elevator button for a floor you are already on?  The elevator goes nowhere, but doesn't compain.

Press the radio station button to the station you are already on?  What happens, nothing.

Click the save icon on a file that hasn't changed.  No error messages. It just saves anyway.

All these behaviours emphasize to the user that *they* are in control.  So if they 'generate' on an empty list.  Go ahead and generate and come back with an empty report.  Unless some really serious errors are going to result from generating off an empty list, just go ahead and do it.

Friday, August 20, 2004

LH, your examples all differ from OP's problem in one very important aspect: The TV station, elevator, radio station and saved file don't change - nothing new, nothing different yet desired; but pressing the button creates (generates) an empty report - something new, useless and unwanted.

I prefer disabling the button.

Friday, August 20, 2004

I didn't see it in this thread, but is there a way to back out of this dialog without generating anything?  I would agree that disabling the button without putting something else is bad form.  I don't agree with the tooltip because they take time before they display, and people don't wait before pushing a button like that.

If it's invalid to press "Generate" with nothing selected, then disable the button and give them an alternate button that says "Cancel" or "Back" or something like that they can use to escape.

If it is valid to press "Generate" with no data, then disable the button and put a check box that says "Generate with no data" or something similar that enables the button, while still having the "Cancel" or "Back" button.

That's my $0.02.  And probably about worth that much.

Friday, August 20, 2004

What about disabling the button, and then taking whatever text you were going to put in the message box and put it right next to the button?  Now nobody is bothered by message boxes popping up, and nobody is confused about why the button is disabled.

Friday, August 20, 2004

Things I've learned:

1.  Less than half of users will read a block of text that explains what to do, and those are usually the ones that would have figured it out just fine without the text.

2. In a debate about disabling vs messageboxing, half will prefer disabling, the other half will prefer the messagebox, and the last half will come up with thirty alternative suggestions.

3. You're going to piss off somebody no matter which way you go.  The best compromise is to be more or less orthoganal with other dialogs in your app, go for consistency.  With any luck, most users who will figure things out after one or two attempts.

van pelt
Friday, August 20, 2004

Personally, I always think it's better to err on the side of generating a message box and annoying repeat users.  Your choice is to leave someone sitting there scratching their head going "huh" and I never think that's a good solution. 

Take my opinion and a quarter and you still can't buy a coffee at Starbucks though!

Friday, August 20, 2004

>> After discussing this with some others, we have figured out the real problem: the Generate button is in the wrong place. <<

I was going to ask what the proximity between the list and the button was.  If it's way over on the other side of the dialog, then there's no visual clue to the user that the unchecked list and the greyed-out button are related in some fashion.

If you have ever played Myst, there are a series of switches on the island which must be thrown before a big event can happen.  Every time you throw one, there is some feedback (either visual, auditory, or both) that you're on the right path. 

You want to do the same thing with your dialog -- give the user the idea that the two are related, and positioning the button by the list does that.

Friday, August 20, 2004

If you look at any standard Windows "Options" dialog (with OK, Cancel, Apply), the Apply button is usually disabled until you update an input control.

It's easy to do. In VB, I usually do it like this:

Private Property Let ChangesMade(bNew as Boolean)
    cmdBtn(fciCmdApply).Enabled = bNew
End Property

Private Property Let ChangesMade() as Boolean
    ChangesMade = cmdBtn(fciCmdApply).Enabled
End Property

Private Sub txtFld_Change(Index As Integer)
    If mbLoading Then Exit Sub
    Select Case Index
    Case fciTxtSomeSetting
        ChangesMade = True
    End Select
End Sub

Private Sub ApplyChanges()
    If Not ChangesMade Then Exit Sub
'  Save the changes
End Sub

Friday, August 20, 2004

> "User Interference"

Yes, there is a formal term for it in the field of UI. It is called "excise", like an excise tax you have to pay but which does not help you achieve your goals.

Any actions that the UI requires of the user which do not help him attain his goal are "UI excise". See About Face by Cooper for an entire chapter introducing this idea followed by an entire book elaborating on it.

Regarding your design, I agree with you and not your manager. However, this specific thing is a ongoing debate in the UI community and was even discussed here about 1.5 yrs ago, with Joel coming out favoring your managers view, if I recall correctly.

Dennis Atkins
Saturday, August 21, 2004

Oh and a good suggestion is to set up your ToolTips so that they explain WHY an item is disabled.

Dennis Atkins
Saturday, August 21, 2004

I prefer the Windows 3 approach: wrong input==GPF and all work lost. Pretty soon the bastards (users)  start to learn about doing things properly.

Donald Norman
Saturday, August 21, 2004

The tooltip does take ~1 sec to pop up, and some people may not hover over "Generate" for so long. But you could write your own, which pops up the instant you roll over.

Or hide the button altogether and put some bold red text "Make A Selection in Order to Generate" right there on the dialog -- golly, you'll have to subclass! :)

Saturday, August 21, 2004

The tooltip idea is a bit mouse-centric. What if the user is operating the software using keyboard only? In that case you also need to consider what the Enter key does when the default Generate button is disabled.

Saturday, August 21, 2004

put a text like 'select items and then click 'generate'' in bold


if the button is enabled at first, when he clicks it, popup a non modal tip like 'select items'


select some items by default.

My $0.02

Sunday, August 22, 2004

We need to ask "Mr. Usability UI design Joel Himself Mister Master" about this issue.

Sunday, August 22, 2004

UIs need to do two things - hold the hand of the noob while they figure out how to use the software, and get out of the way of the experienced users so they can do their job.

If attempting to generate a report with none of the checkboxes checked is not a valid option, then it seems reasonable to me to pop up a window explaining that.  It lets the user know what they need to do, and perhaps why.  The experienced user won't ever see this message, because they will know better than to try to generate a report that way.

Simply disabling the button with a tool tip explanation doesn't go far enough, in my opinion, to help the user understand the process.

I agree whole heartedly with eliminating User Interference (nice term), but at some level you have to gently nudge the user towards making the right choices.

First Time Poster
Monday, August 23, 2004

*  Recent Topics

*  Fog Creek Home