Which is better: disable a control or enable it but refuse to continue?

For example, there is a "View Previous Record" button in a form but for a certain record there is no previous record yet, which would be better, just disable that "View Previous Record" button or enable it and when clicked just tell a message like "XXX has no previous record yet"?

Disable.... if I can't perform an action, don't let me think that I can.

-tg

I agree with techgnome, disable it...

Quote:

---

Originally Posted by dee-u

For example, there is a "View Previous Record" button in a form but for a certain record there is no previous record yet, which would be better, just disable that "View Previous Record" button or enable it and when clicked just tell a message like "XXX has no previous record yet"?

---

I was just tinkering together a sample program for somebody today and encountered the same issue. Disabling when there is no more available is preferable.

I think my dilemma only appeared because crashing into the beginning or end was easier to detect than predicting it. Thus I briefly toyed with the idea of a message on failure myself.

In the end common sense won out. I bit the bullet and went with logic to do the prediction/disable as well as re-enabling when appropriate. More work, more code, but a better user experience.

Simple rule of thumb...

If you can do it in whatever page / section you're in with some data but not the current data, then you disable it.

If you cannot use it on that page / section at anytime then remove the control. I would group controls that operate on privileges in this group as well. If my user doesn't have access to delete something, I should not see that button.

The reason of my boss for letting it enabled is that there could be many reasons why it should not allow to continue hence it could tell the user why it will refuse to proceed when the concerned button is clicked.

What's your take on this? If there should have been just one reason then it would be perfectly reasonable to disable but perhaps he may have some point, how would a user know why that button is disabled?

Thank you guys!

I would say that disabling it is STILL a better option, though only marginally. If the user will be required to try an action, and will only then be informed that the action is not possible, that would always be less desirable than keeping them from attempting the action. You might show the why in a label or something, but if you leave the button up, they will have an expectation that it will be possible.

On the other hand, there is nothing more frustrating than seeing a grayed out button without any logical reason why it should be disabled. When it comes to navigation buttons, I don't think this is ever an issue, as a disabled navigation button just means, "you can't go that way." A non-navigational button is a much harder decision. The question that must be decided is whether or not a mentally deficient user would be able to realize that the button makes no sense. I don't feel that there is a clear rule in those cases, so the decision is situational. Not so much with navigation buttons.

Why not present a tooltip or a note stating why it's disabled?

To be honest, the UI should really flow in specific ways that makes reasons for why things are disabled intuitive.

Making the user test something that the application can know won't work just seems really evil to me.

disable, disable, disable !!!

always better, any tips on why should be in a help ? button or label or something.

i mean how many different reasons can there be for there being no previous record ? If you had like 10 or 20 legitimate reason then maybe, but just because there maybe a couple of reason why a button might be disabled i think it's a bit anal to be displaying messagebox's for each reason.

Quote:

---

Originally Posted by dee-u

The reason of my boss for letting it enabled is that there could be many reasons why it should not allow to continue hence it could tell the user why it will refuse to proceed when the concerned button is clicked.

---

This is something the should be included in the accompanying documentation, not the screen itself.

Keep it disabled if it can't be used.

Accompanying documentation? What's that?

I've occasionally tried to get out some documentation to accompany a program I wrote, but there has generally been some obstacle in my way. I still dream of documenting, though.

"Documentation? Bah! We don' need no stinking documentation! If it was hard to write, it should be hard to use."

Forget where I picked that up.... it was funny then as it is now. And frightfully true all too often.

-tg

Quote:

---

Originally Posted by techgnome

"Documentation? Bah! We don' need no stinking documentation! If it was hard to write, it should be hard to use."

---

I don't remember either, but it has been around for many, many years. :lol:

Actually, documentation is something we are required to write here. No one reads it anymore than anyone reads the documentation anywhere.

However, here the documentation is used to beat the snot out of the users. If they have a problem that is covered, there problem gets routed right back to the documentation.

For once management actually backs us on this.

I agree that it should be disabled but I'd actually do both... just in case. I tend to be a belt and braces programmer which, while it does lead to some redundant code, also helps prevent my trousers from falling down. Tooltips and help files should be sufficient to let the user know what they need to do before proceeding and if they're not you could consider writing a wizard.

Documentation should only ever be provided as a last resort. Apart from anything it only serves to highlight the lask of testing that code has undergone. In the likely event that a user causes a crash one should pointedly remind them that they caused the crash. Had they done what the programmer intended them to do there wouldn't be a problem. I have no idea why I'm about to follow this with a duck smiley... I just feel like it.:afrog:

Quote:

---

Originally Posted by dee-u

The reason of my boss for letting it enabled is that there could be many reasons why it should not allow to continue hence it could tell the user why it will refuse to proceed when the concerned button is clicked.

What's your take on this? If there should have been just one reason then it would be perfectly reasonable to disable but perhaps he may have some point, how would a user know why that button is disabled?

Thank you guys!

---

How does that matter? The end result is that the user can't perform the action, irrespective of whatever reason. So disabling should be preferred.

one word! disable.

if i cannot perform the specified action, i prefer the button to either not show or be disabled.

Quote:

---

Originally Posted by modpluz

one word! disable.

if i cannot perform the specified action, i prefer the button to either not show or be disabled.

---

Showing/Hiding buttons and menu items can cause confusion as well.

Ultimately disabling the button(s) is most preferred.

Quote:

---

Originally Posted by Hack

I don't remember either, but it has been around for many, many years. :lol:

Actually, documentation is something we are required to write here. No one reads it anymore than anyone reads the documentation anywhere.

However, here the documentation is used to beat the snot out of the users. If they have a problem that is covered, there problem gets routed right back to the documentation.

For once management actually backs us on this.

---

We document everything, even before we start coding it. Then we spend time arguing with the users about what was in the document. The users claim they didn't have time to go through the document.

Then they go to the supervisor. The supervisor claims they should have read the document. UAT gets delayed. Work on the next project gets delayed.

Everyone does over time to keep up. Eventually the original document is updated to incorporate new changes. Welcome to my world!

:wave:

Quote:

---

Originally Posted by JuggaloBrotha

Showing/Hiding buttons and menu items can cause confusion as well.

Ultimately disabling the button(s) is most preferred.

---

when it is not showing, the user has no idea of it existence.so i don't know how that'll confuse them.

and of course i meant in a programmatic approach(server side: ASP, PHP, or whatever your language is).

Quote:

---

Originally Posted by modpluz

when it is not showing, the user has no idea of it existence.so i don't know how that'll confuse them.

---

It would confuse them in the situation where the user, at times, can use that button or link button.

For example, let's say you have the ability to edit user privileges. You go into the page, update them and realize that the save button is missing. Oh no the site is completely broken! Call the help desk and yell!

Or you could simply disable it and leave a message like "This function is currently down" or "you do not have permission to change permissions on this users".

Now they're well aware of the issue.

The only time you should just outright hide the button / link is when the user should never see it regardless of the situation.

The application UI methodology my company uses is:

Disable any control that has unmet conditions.
Hide or don't even create controls if the user doesn't have access permissions to them.

Our applications have a lot of "Save-Cancel" style forms. If any required fields, conditions, etc aren't met, "Save" is disabled. If a tree-root element in a tree-view needs to be selected prior to adding a new node, the "Add New" button is disabled. If the user doesn't have a selected item in a listview box, the "Delete item" button is disabled, etc...

It makes for complicated forms and it's one of those things I'm still struggling with in WPF to figure out how to easily do, but it makes a more natural, intuitive application.

Quote:

---

Originally Posted by Kasracer

For example, let's say you have the ability to edit user privileges. You go into the page, update them and realize that the save button is missing. Oh no the site is completely broken! Call the help desk and yell!

---

well, i don't mean if you only have one button on the form, if you only have a "Save" button, disable will do but if you have more than one button, then, disable the button with unmet conditions.

and also do note that my post is situation specific.

Quote:

---

Originally Posted by Kasracer

For example, let's say you have the ability to edit user privileges. You go into the page, update them and realize that the save button is missing. Oh no the site is completely broken! Call the help desk and yell!

---

well, i don't mean if you only have one button on the form, if you only have a "Save" button, disable will do but if you have more than one button, then, disable the button with unmet conditions.

and also do note that my post is situation specific.

OOPS! another double post, i don't know why this keeps happening in vBulletin.

ok, i posted using the "Quick Reply" below, then it took me to the "Reply to Topic" page, so i assume it hasn't been posted, then i posted again.

can a mod please delete this and the double post?