Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm currently working on some setting screens, most of which contain a 2 column form with a preference question on the left, and a form element on the right.
The questions are things like:
Can add/edit other users?
Can delete clients?
Obviously this setting is a binary setting and most UI "experts" would insist that a checkbox is the appropriate form element to use.
However, when I mocked up the form with the checkboxes it looked unfriendly and it seemed hard to relate the state of the checkbox back to the question.
I changed the form to use two radio buttons instead:
Yes o No
Personally I find this easier to process, as the options are actually answers to the question posed on the left.
In terms of clicking it makes no difference to the user, it's a single click each time to change the setting.
What do you think of this use of radio buttons? Is this better or worse than a checkbox and why?
For something like "Can do X" I would use a checkbox rather than a radio set as Can Do/Can't Do relates well to the On-Off nature of a checkbox. Most users understand a tick maps to Yes and no tick maps to No.
However, a radio set can make sense for some binary options where the options aren't clear or how they might relate to on/off isn't obvious. For example, you could have "Binary File?" follow by a checkbox, but I think in this case it would be clearer to have "File Format" followed by "Binary" and "Text" options.
We had an experience with customer base of older age group, they understand "Yes"/"No" radio buttons better then checkboxes. And we were forced to remove checkboxes and put radio buttons everywhere. Its better for non IT savvy people.
I've been looking into this recently in order to design a PHP form class. As you note, the standard answer is that a checkbox should be used and I've even seen some people advocate that where radios are used, a default should be given.
I couldn't possibly disagree more. Consider when a user is a confronted with a text input, say for entering their username. If they submit the form without filling in this field, and the field is needed, we know that the empty string generated is bad input. Perhaps the user missed the field or didn't realise it was necessary. We fire an error and ask them to input the missing data.
Now considering the same scenario but with a checkbox. If the user misses the checkbox then we have no idea whether their input was intended or unintended. The same is true for radios with a default.
Consequently, I strongly suggest that a form should not contain defaults at all. If a piece of information is important enough to take from a user then it is important enough to get correct. Providing a default whether through a checkbox or a set of radios with one checked, sacrifices a large amount of accuracy for small amount of usability. Therefore, I think using Yes/No radios are vastly superior to checkboxes.
The only place a checkbox is valid, in my opinion, is where you have a small collection of options of which a user may select more than one. If the collection is large, however, then a select (without a blank default option) should be used instead.
My feeling is that a checkbox should be used where the answer can only be Yes or No - nothing else, e.g. Do you want to register?
Radio buttons where there are other options. e.g. Do you want a newsletter in oPlain text oHTML - with NO defaults
The other consideration is to use radio buttons where you want the user to make a conscious decision. As one of the other answers says, if its important enough to ask, then its probably important enough to get accurate.
The only time I use a checkbox is if the answer is either Yes or No AND if the checkbox ticked will enable other fields that the user needs to fill in AND its optional / not essential information to complete the process, e.g. Do you want to authorise someone else to access your account [ ]. This would then enable fields like Name, address, etc. The one thing I ask is 'If a user left this as the default option (usually NO), does it make a material difference and can it be easily changes afterwards'
I think radiobuttons would clutter the GUI if the answers always are yes/no.
Radiobuttons could also make using the keyboard to set the options a little bit harder.
I agree that checkboxes have more of an implicit "true"/"false" meaning, another point is that for radio buttons you can force the user to make an active choice by having neither option selected. Therefore, for important fields it may be a better idea to use radio buttons so that the user does not accidentally miss it.
It depends on the context and target audience: you're aiming to minimise the thought processes required to answer it.
If it's a questionnaire, for instance, you'll probably want to ask in full sentences. An options screen would be targetted to scan-reading (so allow/deny instead of yes/no), while a toolbar (something frequently set/unset) will use a toggle. In any case, I'd err on the side of consistency.
For permissions, it's normal to use a heading of Permissions, with a checkbox for Edit users. You could even highlight the permission if it's enabled. This helps keyboard users by only requiring one press of tab instead of two. Just make sure that the click area for the checkbox is large enough.
In either case, a two column form is not recommended because it puts the target too far from the description. It also encourages questions like "Allow full control or only some (yes/no)". How about using rows that change from green to red, and show a tick/cross? That can be done in a web-friendly way.
From a ux perspective I'd say check box represents true/false ie; Quest is Do you Want XXX tick for yes in common parlance) but for a choice I'd prefer radio (e.g. A or B). There are other metaphors such as pushed in/popped out button.
Have you tried using only CheckBoxes labeled like "Can add/edit other users" without the question to the left?
I find radio buttons really difficult to support or document.
You can tell people to tick the tickbox, and it sort of makes sense to them.
But "radio button" makes little sense, and "blob the option that most applies" is just a nonsense thing to say.
In my case, because we need explicit answers, an explicit yes or no, I use checkboxes for both a yes and no:
Yes [ ] No [ ]
The benefit is that the form is valid on paper as well (sometimes fax/signatures are required). I guess you can also style the radio buttons as checkboxes!
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm writing an internal-tools webapp; one of the central pages in this tool has a whole bunch of related commands the user can execute by clicking one of a number of buttons on the page, like this:
toolbar http://img709.imageshack.us/img709/1928/commands.png
Ideally, all of the buttons would fit on one line. Ordinarily I'd do this by changing each widget from a button with a (sometimes long) text label to a simple, compact icon - e.g.
button labelled "Save" http://img337.imageshack.us/img337/773/saver.png
could be replaced by a familiar disk icon:
Unfortunately, I don't think I can do this for every button on this particular page. Some of the command buttons just don't have good visual analogs - "VDS List". Or, if I needed to add another button in the future for some other kind of list, I'd need two icons that both communicate "list-ness" and which list. So, I'm still considering this option, but I don't love it.
So it's come time for me to add yet another button to this section (don't you love internal tools?). There's not enough room on that single line to fit the new button. Aside from the icon solution I already mentioned, what would be a good* way to simplify/declutter/reduce or otherwise improve this UI?
*As per Jakob Nielsen's article, I'd like to think that a dropdown menu is not the solution.
Edit: I'm not looking for input about the icon idea. I'm looking for other solutions. Sorry my example disk icon was a small one; it was just an example. I'm showing a bigger one now to hopefully be more clear.
I would add a More Link Like Google does.
See the Top Bar of Google with WeB Images Map More >>
To this more >> drop down you can add logic to add button less frequently used by user or something like that.
If you read Jef (and Aza) Raskin, you'll probably realize that icons are also not a good solution – both were pretty vocal in their dislike for them (with very few notable exceptions). For a start they're even harder to hit than tiny buttons, then their symbols can be confusing, culture-dependent and misleading. We're already good at reading text, parsing and interpreting icons is often slower.
In any case, that button bar looks like it accommodates pretty much anyone and their dog who might be using that product. You might have had some specific scenarios in mind when creating it that should be easy to do and are important. Most likely not all buttons are needed at once for such a task to complete.
Another thing is that maybe not all buttons are even useful at any single state of the application. Can you maybe branch into different sets of buttons, depending on the state. That's only possible however, if each state has clearly defined what actions can be taken. If all buttons are equally pressable regardless of state this won't do anything.
Grouping commands according to related functionality might also be an option. This doesn't have to be done with menu-like idioms, you can also put them into containers with different background color or even color the buttons themselves (just keep in mind color blindness, though). Depending on how related those individual functions are this can be a good way of speeding up interaction. It might requier some training for users to know what the colors refer to but for an in-house tool that's only used by people you know (instead of by arbitrary random ones [which is a problem Microsoft faces quite prominently]) this should pose not much of a problem.
What if you use icons and text?
For the commonly understood commands - use just an icon (like the save)
For the uncommon commands use an Icon + the text.
If you put a border around the button as a whole it should tie the icons / text together nicely and show it's still a button. You could also do some hover effects.
Since you can't do a dropdown menu (or similar techniques like clicking a button to generate a secondary menu). The best I can think of is what Prescott did or showing an area of buttons that are grouped in such a way to make it easy for the user to know which section their button should be in.
I would start by changing some of the longer labels. At a minimum, "Application Loading" could be abbreviated "App Loading." What's another (shorter) way to say "Quick File Transfer"?
You could also group the buttons into tabs (i.e. make it a ribbon). That might work particularly well if different classes of users tend to use different, non-overlapping sets of buttons.
Numerous options:
Group and labeling. Any time you have more than eight commands, you should divide the menu items into semantic groups of about four to help the user scan for the command they want. Labeling the groups also helps the scan and can make the menu more compact. For example, Instead of VDS Ping and VDS List, Have a group labeled “VDS” with “Ping” and “List” menu items. You’ve one less word to fit in (two if you put the label above it’s associated menu items when using a horizontal orientation).
Pulldown menus. Nielsen is correct about avoiding the use of a dropdown menu for making commands. However, he’s clearly in favor of pulldown menus which look and behave like a menubar in a thick client app (Nielsen calls them “command” and “navigation” menus). I think you’ll find that there are several Javascript pulldown menus out there now, unlike back in 2000 when Nielsen wrote his post. You can fit 100s of commands in a menubar.
Sidebar menu. Arraying the menu items vertically and you should be able to fit 20 or more commands and you won’t have to shorten any command names to something user might not understand. If that’s not enough, consider a “menu bank” than combines the benefits of sidebar menu with the capacity of a pulldown menu.
Ribbon. If your commands fit into discrete tasks, where the user tends to stick to one task for a while, you can arrange the buttons on a tab control, with one sheet per task.
Command Overloading. Represent your data objects as selectable entities in your window and change your commands into more general operations, like Drill-down, Create, Copy, Move, Delete, and Link, that can be applied to various different classes of objects, thereby reducing your total number of commands. The user can select one or more data objects then select the desired command to act on them.
Work Area Attributes. Some of your commands may not be commands by settings or attributes. Remove them from the menu and represent them as data objects in the work area of the page (or another page, if they are rarely used) using controls like radio buttons, dropdown lists, and check boxes. This has the added benefit clearly showing the user the current setting as well as providing a means to change it.
Variants. For an internal app, you probably have formal roles and responsibilities that vary by work position. Include the user’s position in your model, and dynamically hide commands (and other controls and pages) that aren't relevant to that position.
What about a combobox and a Confirm button?
Or a simple dropdown menu?
Add a "Tools" or "Actions" menu bar, and stick rightmost 4 commands (or more) into the menu.
Would it be possible to implement a "most used" or "preferred" set of buttons (preferably for the user, but globally if necessary) and button to take you to the rest of the items if you need one of those?
You could group them (like the two 'vds' buttons) behind a single button that, when clicked pops a context menu with the individual icons.
It truly seems like what you're developing is a administration console which happens to present its UI through a web page, rather than something which I'd quantify as a web app. As such, especially given your statement that this is an internal use application, Jakob Nielson's advice regarding <select> tags being poor design need not apply.
For this particular set of assumptions, I think the better option is to imitate a system menu setup using one of the many CSS-based menuing designs possible.
Icons are terrible from a user experience stand point. A picture of a Floppy Disk doesn't un-equivocally mean SAVE. It means something to do with a Floppy Disk. A Floppy really, its 2010, SAVE on a web app means save to the server, how does a Floppy Disk even compute?
Here is an application that has had the same extremely usable interface for 10 years! And hardly any images for buttons, and it is one of the most productive applications in its category.
You know what ICONS stand for I ncomprehesible C ryptic O bfucsated N onsense S ymbol!
Also how do you internationalize an icon?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I think it's considered a bad practice to have controls appearing and disappearing and the size of the window changing in a single GUI screen dynamically based on a user's input. However, I can't seem to find a definitive reference that states this.
I've been asked to create a GUI that has a text box at the top in which a user enters a file name (using a file chooser). Of the files that can be chosen, each has certain properties, however some of these properties can be null for a given file.
Below the file name text box are rows of pairs of labels and text boxes with values for each of those properties. I've been asked to not show a label and a text box if the associated property is null.
The user can repeatedly choose different files and the values in the text boxes should update accordingly. In addition, the labels and text boxes should appear and disappear depending on whether the values are null. Moreover, the value of the screen should shrink or expand so that there isn't empty space (because of null values and, hence, missing controls).
This seems to me like it would be very jarring to the user (to have controls appearing and disappearing and so on).
Is this bad GUI design? If so, could someone quote an authoritative reference that I can use in trying to argue against this design?
(What I would prefer is to just leave the text boxes blank for null values.)
I have to disagree with Konrad and Brian here -- this will end up being jarring for most users.
While dynamic response is definitely a valid GUI paradigm, hiding/showing and resizing displays dynamically based on selections from the same list (or entry into the same text box) tends to be very jarring for normal end users. This is why the so-called "smart" menus in Office (and Win2K/XP) were loathed by many -- features seemed to appear and disappear for no good reason.
The correct paradigm in this case is disabling ("graying out") the controls. If you're looking for specific citations, I believe this has been discussed in About Face: The Essentials of User Interface Design. I know that the Microsoft Office usability team also produced the same results from their labs.
Pre-emptive Note:
Showing/hiding is not always a bad paradigm. But use it when it makes sense. It makes sense for the Windows Explorer detail bar to show different contextual information based on whether you've selected a Word Doc, an image, or an MP3. That's a small, borderline incidental piece of the UI, with no discernible (and especially no editable) controls. It's expected that navigating to a new tab will hide the controls from the previous tab and show the ones from the new tab -- but then again, tabs are a navigational paradigm.
Showing and hiding within the same view, for what (to most users) will appear to be the same kind of data, is the jarring experience.
I think it's considered a bad practice to have a single GUI screen that changes dynamically based on a user's input.
Honestly, that seems like a very odd guideline, at least when formulated this broadly. In fact, in order to get a result, the GUI has got to change dynamically reacting to user input.
This seems to me like it would be very jarring to the user
Try it. I don’t think that it will be a problem, as long as you don’t make the input field shift while it has the focus. The user shouldn’t be chasing the text box she’s typing into.
No, that sounds like a normal GUI design. No matter what the file type is, you're doing the same basic task. You just slightly change the details of which properties are shown. Same task = should be on the same screen.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
On a web contact form, is the reset button really required? Is it really used by anyone? If I don't put it in a page, is there an usability fail?
10x!
Well, it's very useful to erase that textarea your customer just took the time to write, because they press the wrong button -before they lose it anyway because the session expires, and have to retype-
No, I really don't think it's useful.
It's actually sometimes useful for web forms which will be accessed from public terminals - a good example would be a search form for a public library card catalogue.
Imagine if the search form has a lot of fields (author, year, keywords, topic, publisher, collection, title, series, whatever). This lets you do very specific searches (all books by authors named John published in 1987), but once you've found the result you (or another user) may want to do a new search using a very different set of terms (all books about fish published by Random House. A reset button can help a lot here, because you may otherwise find yourself manually clearing a large number of fields.
(Depending on implementation details, a reset button may also be useful if a user doesn't want the next user to see what they were searching for. Again, this is useful in the context of a library, where privacy is a concern.)
I honestly don't think so in the general case, but you should talk to your users or otherwise examine how they use your system to make sure.
General rule of thumb: If you aren't sure that it's a requirement and you have no way of knowing, don't include it. You can always include it on a later iteration.
The reset button must be the safe winner in any contest measuring a uses/usefulness ratio since it's omnipresent and fully useless.
I think it's a) completely useless to 99% of users; and b) requires far too much work in a typical LOB application. Often business analysts add requirements for the Reset button without giving any thought as to why this feature is required.
add it to the webform and log it whenever a user clicks it. that will provide information for your specific page if it's needed or not. we cannot guess if people want it or not.
just use simple analyzing tools of users need it or not.
I don't think it's necessary in most web-pages. If you're entering information, and you enter it wrong, then you'll need to go through every wrong text-box and re-enter it. The reset button is, at minimum, one extra button click on top of that.
If you don't want to enter information, you just don't click the submit button.
The only time I see a reset button being useful is if you have a multi-page workflow, and need to be able to start from scratch. Even then I would suggest re-designing the workflow.
In my opinion the reset button is completely useless on the majority of forms. I mean think about it... Can you ever imagine a time were you would want to complete remove all of the information you typed in? Not likely. Most users tend to make edits to specific fields not the entire form.
In the case that you have to have such a secondary action like a reset button it's better that that button is a little smaller as well as colored a little differently. Let the user know "this button is different" and apply Fitt's Law to make it a little harder to click on.
Absolutely NOT required. In fact, it's a bad idea to use it if you have a long form and have a RESET button at the bottom because you could make some people really angry if they find out that they accidently hit "RESET" and their data is deleted.
Required. Make sure you swap the position of the reset and submit buttons on some of your forms. Better yet, write code to randomly swap their position once in a blue moon.
In all seriousness, I've never used one. When I removed it from the forms on my school's registrar's site that I was working on when I was a student, nobody said anything. So I say leave it off.
Not only on the contact form. I can't also find the benefit of reset button in any type of HTML form, IMHO. But I tend to put it every time I create a form :)
Only reason I could think of is on a preview & confirm scenario, where a user might modify part of their entry before hitting the big bad send button, and actually decide itt made more sense the first time around
I usually leave out the reset button, because I've never seen anybody use it.
I often use the free space for a cancel button which returns the user to where he came from in the first place (the page linking to the form). Makes much more sense to me.
What if I says it IS useful? But not in every form.
I use it with the "UPDATE" part in a CRUD application sometimes.
Say SO for example, I hit an edit link on a question.... and made some edits and reread it... but then I decided it is not a good edit... I have to reload the page or go back to the last page and hit the edit link again to get the original text.
Whereas, if there is a reset button slapped there, it'd be easy.
And there is always CTRL+Z.. so why not?
There are some good uses but just don't slap it in silly like what most ancient HTML books would teach you to.
It can be useful for clearing radio buttons without using Javascript.
In the form below either zero or one radio button may be selected:
Select any one option for any Item(s):
Option 'A' Option 'B' Option 'C'
Item 1 o o o
Item 2 o o o
Item 3 o o o
Item 4 o o o
If a user changes his mind or accidentally clicks on an item's button he didn't want, a reset button will clear the whole form, which seems to be only way to get rid of the selection without using Javascript.
I guess it depends on how large the form is and how big the chance that you actually want to do this. TBH, i've been developing websites for years and never really added one to forms.
It is useful on a form that repeats your previous information. I have had cases in admin interfaces where the users want what they typed in last time, so they don't have to remember. However, on those occasions when they want the form to reset, they simply press the "clear" (or reset) button.
On a one-time form a reset button would be silly.
A reset button should be used only when there is default information. An example is this form. What if I make changes to most of the values but then would like to get it back to it's original state? I guess I could reload the page as long as it doesn't resend my POST. Or I could just hit a simple reset button. The button was never intended to clear all information entered by the user but to reset preset data.
I would suggest the usability fail will present itself if and when a user or business owner complains about the absence.
Definitely not required as a "standard" feature and usually a very bad idea with the exception of the special cases given above where the functionality seems to add value. However the most of the cases offered as examples above could be dealt with in different (and I would suggest, better) ways than with the, often awful, reset button.
Reset is for use with HTTP status 204 only
Destination of the form can send 204 No Content response, which causes browsers to leave the current page unchanged.
In that situation reset button is most reliable way to reset form to original state (page reload could re-send the form).
However I can't come up with realistic use-case for it anyway.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
When designing a good Web GUI what expectations can we expect from an end user?
I've come up with the following, but I wonder if there are any others which can suggest..
If I click on a hyperlink it will take me to another page/part of this page
If I tick/untick a checkbox it might alter the page state (enable/disable elements)
If I click on a button I expect it to do something to data.
If I click on a button I expect something to happen immediately (either to the current page, or for me to be taken to another page)
If I have clicked on a hyperlink and it has taken me to another page, I expect to be able to use the Back button to get back to the previous page in a state similar to that which I left it in
If I change something in a form, I can change it back to its previous value if necessary
Unless I click on the 'Submit' button nothing should happen to my data.
If I bookmark/favourite a page then it should show the same related data each time I visit it
If text is underlined and looks like a link, it should be a link and act as one
The reasoning behind this question is more a 'UI from hell' one. For example I have come across pages which checking a tickbox next to a record will delete it, straight away, via ajax. To me that just seems wrong, a checkbox is a toggle - something which a delete operation definitely isn't!
If some text is underlined it shall be a link.
If I press the back button I shall go back to the previous page, which I will recognise as the previous page.
If something is happening aysnchronously it shall be obvious to me that it is in flight, and obvious when and in what state it completes.
If I want to expand or shrink the text size (ctrl++, ctrl+-) it shall not be at the expense of the layout.
I shall not be presented with a set of radio inputs where I wish to select more than one item.
If I want to disable Javascript or Flash I shall be allowed to do so, and still have access to the basic features of the site.
If a form doesn't validate, I don't expect to have to retype it before trying again
If a control is disabled, it should be greyed out / denoted in some way
When I press back I expect to go back, not get thrown out of the system (bloody banking websites)
There are fundamental principles of UI design embedded in this question. I strongly recommend everyone who touches on UI design should read, at a minimum, our very own Joel's "Controlling Your Environment Makes You Happy", an article that I read some years ago that has stuck with me and is still as relevant today as it was the day it was written.
I also recommend the book "Don't Make Me Think!" as an excellent resource on the principles of good UI design, particularly on the power and importance of convention.
Your list is all about conventions.
Several comments:
The Back button has always been (and will probably always be as long as the Web exists) controversial. There are security and usability reasons to disable it's use. Double-submit might be an annoyance on a forum but it can be a costly error with an order to buy shares. This can be handled with other techniques (eg POST+REDIRECT+GET or overwriting the browser history) but the point remains: Back button behaviour is not always desirable let alone required;
Bookmarking a page and expecting the results has some merit (eg if I bookmark a quote for GOOG then I should go back there and get a current quote, not the quote I saw at the time I bookmarked, obviously) but a page result can also be costly so this may not always be appropriate.
I'll add a couple:
If I can click on it and it's not a button then the cursor should change to a hand when my mouse is over it;
Conversely, if the cursor changes to a hand, I shold be able to click on it and it'll do something; and
If there's a box containing some text that has a border and it looks like a text element on a form, then I should be able to type in it unless it indicates that it is "read-only" or "disabled" (eg by greying it out).
If an ad says i've won a million dollars, give me the money. If not, make the ad go away.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
Have you ever been in a situation where a menu function you really really want to use but can't cause it's disabled or worse gone all together?
There is an argument for always leaving menus enabled and then display a message to a user explaining why a menu function can not be activated when they click on it. I think there is merit in this but maybe there is a cleverer way of addressing this issue.
I would be interested to hear what others think.
If you're refering to Joel's post Don't hide or disable menu items, he clarified in the StackOverflow podcast that he intended that there be information - not a dialog - telling you why a menu item wouldn't do anything:
So, the use-case I was thinking of was, you had mentioned that in the Windows Media Player, you can play things faster when you're listening to podcasts and so forth, and it'll speed them up. And when I looked in there, that was disabled. And I couldn't figure out how to enable it. And obviously the help file is no help--not that anybody reads help files, but even if you did you couldn't find the answer to that. And that was kind of frustrating, and I'd rather have that menu item be enabled and have it just tell me "I'm not going to do this right now because of the following reason. I refuse to do this."
As with most questions about usability, the answer is "it depends". It depends on the problem domain, the type of user, how critical the function is and so on. There is no single answer to your question.
I think the general consensus is, never ever totally remove items from a menu. Menus allow the user to freely discover what functions are available, but if those items are hidden or move around it does nothing to help the user. Also, moving them around makes it impossible to become proficient with the application since you have to constantly scan the menus for the item you want to select.
As for disabling versus enabling an item and displaying a dialog or message explaining why it's not something you can do, I generally prefer the former. However, if there's a function that a user can't reasonably be expected to intuit from the display, leaving it enabled is a good choice.
For example, if "Paste" is disabled it's reasonably obvious to most computer users that there's nothing to paste. However, if you have a "Frizzle the Bonfraz" menu item and the user may not know what a Bonfraz is or why they might want to enable it but can't, it's a good idea to leave it enabled at least for a while.
So again, it depends. If at all possible, do what you think is best and then ask your users.
To generalize it a bit (perhaps incorrectly...), which of these situations would you prefer:
To find yourself on an island with no boat or bridge in site. Of course, you could talk to the villager in town and he would tell you the magical word to make a bridge appear...but you had no idea that magic existed.
You see that there is a bridge; however, when you get to it, there is a sign telling you that the bridge is not open to use.
You see that there is a bridge and celebrate! When you get to the end of the bridge, it tells you that the exit is not open. They must go back.
Maybe I am biased, but I don't believe that leaving the menu options enabled and allowing the user to click on it is the best of idea. That's just wasting someone's time. There is no way for them to distinguish that the item is available or not until they click on the item. (Scenario #3)
Hiding the item all together has its pros and cons. Completely hidden and you run the risk of the user never discovering all these features; however, at the same time, you are presented with the opportunity of making your application 'fun' and 'discoverable.' I've always thought the visibility of actions is more suited to items like toolbars. A good example of that is in when in some applications the picture toolbar pops up when you click on an image...and disappears when you click on text. In general, I would say that something like this is best if the overall experience of your application lends towards a "discovering" and "exploring" attitude from the user. (Scenario #1)
I would generally recommend disabling the items and providing a tooltip to the user informing them how to enable it (or even a link to Help?); however, this cannot be overdone. This must be done in moderation. (Scenario #2)
In general, when it's a context-related action (i.e. picture toolbar) that the user can easily discover, hide the items. If the user won't easily find it, have it disabled.
Make it disabled but have the tooltip explain why it's disabled
It depends on the situation. If the menu item has applies in the current context but isn't available because of state, it should be disabled. If the context has changed so it no longer applies, it should be removed.
I've never really understood this myself (I don't program GUIs). Why even have menu items hidden or disabled in the first place? It is non-intuitive for most users who are looking for a particular menu option to find it disabled, or not even present.
Tooltips are also non-intuitive. If I'm moving my mouse across menu items, I'm not going to pause long enough to get a tooltip explanation. I'm more likely to become frustrated that something I expected to be accessible through the menu isn't there, or is disabled.
That said, I actually don't use GUI menus very often. I find the options available are often not useful, or are accessible in some more intuitive way, such as common keyboard shortcuts.
You can display the 'reason' in the status bar. Or even better, use a text that describes the action and contains information when such action is possible. For example, for 'Copy' menu item, the text in status bar would be: Copy the selected text. Note the 'selected' part, which tells the user that he needs to select the text to enable the menu item.
Another example in a tool I'm making, we have 'Drop database' menu item, but this action is only possible when you're connected to it. So, the text in status bar goes something like: 'Drop the database (only when connected)'.
I've always believed that you should hide as much as you can. (Your application shouldn't be any more complex than what the user can/should do.)
If you display a menu option that a user shouldn't be using, they may click on it, but think your application is broken because nothing happens.
That's what I think at least...