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.
Related
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!
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.
I'm currently working on a program that has many of those "the user SHOULD read it but he'll click OK like a stupid monkey" dialogs... So I was thinking of adding something like a captcha in order to avoid click-without thinking...
My ideas were:
Randomly change buttons
Randomly position buttons somewhere on the form
The user must click on a randomly colored word within the text he should read
add captcha
add captcha that includes the message for the user
Has anybody made any experience with such a situation. What would you suggest to do?
Well, you asked for opinions and here goes mine, but I don't think this is what you would like to hear...
Users like programs that they can depend on. They don't like when things change and they don't like to do extra work.
Randomly change buttons and Randomly position buttons somewhere on the form will only make them either press the wrong button or become annoyed with your application, because as you say, they don't read the text, and if you think about it, neither do we. As an example think of an Ok/Cancel dialog, you allways expect the ok button to be on the left, and most times i press it without reading it. It Will happen exactly the same with your users.
The user must click on a randomly colored word within the text he should read
add captcha
add captcha that includes the message for the user
With these 3 option you will add extra work to your application, your users will curse you for that. Just think of something that you would have to do 10x per day, let's say check in your code to source safe. How would you feel if your boss told you that from now on you will have to fill a captcha for each file you try to check in?
I think it's our jobs to make the lives of the people that use our software easier. If they must read some kind of text and they don't want to, there is absolutely no way you can make them do it.
You can´t make people work right, all you can do is provide them with the best possible tools and hope that they are professional enough to do their jobs.
So basically all i'm saying is, do your best to ease their work. If this is really important than you(or whoever is in charge) should talk to them and EXPLAIN WHY this is important.
You would be surprised on how people commit to things they understand.
I suggest that you don't; and that, unless you know better, you emulate respectable well-known, well-tested UIs like <big online retailer's> or <online banking site>.
Playing games with the user in order to get them to read messages is doomed. Users will focus mental resources on completing your game, rather than understanding the message. Your users may be less likely to actually understand the important part of the message if you have things like moved buttons, relabeling, scavenger hunts, captchas, or delays. They’ll focus on the instructions for the game, not on the real issue. Errors are likely to increase.
Users’ refusal to read message boxes is due to users wanting to get things done quickly rather than take the time to read stuff, and it is also due to message boxes being overused and misused so badly in so many apps. Including silly games in message boxes will just make users resent them all the more, compounding the problem.
Here’s what you can do:
Rule 1. Don’t use messages boxes. They should only appear for exceptional circumstances. An app should not have “many” message boxes. It should not be necessary to read a whole lot of documentation each time the user uses an app. If normal use of your app results in a message box, then your UI is wrong. Find another way.
Instead of verification messages, show clearly in the main window what has happened and provide a clear way to Undo it.
Use auto-correction, pictured/masked fields, and disabling rather than error messages.
Use good defaults and automation to avoid messages. For example, rather than showing an error message saying the user can’t upload because they’re not connected to the server, simply reconnect automatically.
Break commands along options. Rather that a message box to ask if the user wants paste with or without format, provide two different commands in the menu.
Don’t have information messages spontaneously popping up telling the user everything worked fine (e.g., “Preferences Saved!”)
Don’t have pop-ups providing helpful hints or documentation. Provide a tutorial or balloon help if you can’t make your UI self-documenting.
Don’t have nagging “upgrade me” messages.
Consider providing message text in the main window rather than in a separate message box (e.g., “Page may not look or act right because ActiveX is off for security.”). Pop-ups from web surfing have conditioned users to automatically dismiss anything that pops up as irrelevant.
Rule 2. If you have to use a message:
Make the text as brief as possible to get the key information across. More text is not equivalent to more helpful. Use “No match to [filemask] in [path].” Don’t use “Nonfatal Error 307: Search action aborted. [Appname] is unable to complete your string search for the regular expression you provided because the file mask you gave, namely [filemask], does not result in any matching files in the directory that you specified (which was [path]). Please check your filemask or path selection and again re-enter it or them in the Files to Search dialog box. Click the OK button below on this message box to return to the Files to Search dialog box. Click the Cancel Button on the Files to Search dialog when you get there to cancel your search for strings.” If there are some users who will need more explanation than can be achieved in a brief message, provide a Help button or a “How do I…” link in the message box.
Use plain language and no jargon in the message. That includes “innocent” words like “dialog,” “database,” and “toner.” Do not take raw exception text and throw it in a error message. Do not include any error numbers or dumps; log these instead. Purge your app of any debugging message boxes left by developers. Better to simply let the app disappear on a fatal error than to put up a message full of jargon and then the app disappears.
Label the buttons of a message box with what the action does, not “OK.” At the very least, the users have to focus on the activating button to dismiss a message box. If that button is labeled something like “Delete” or “Install,” it should give them pause. You should never have to explain in your message text what each button does. BTW, such labeling is a GUI standard on most platforms.
Redesign your application so that it does not use message boxes.
My suggestion, live with it or redesign your dialogs/interface. Do not add randomness to dialogs or otherwise treat the user like an idiot, even though you may think most are :-).
I just recently read a Joel on Software article, Designing for People Who Have Better Things To Do With Their Lives. It makes the point that most people won't read anything and discusses ways to work around that or at least not make it worse.
You could try with a timer which waits for the "supposed reading time" before enabling the submit button. You can even calculate the supposed reading time from the number of words.
I think that subtle ways to force the user to read your text (like moving around buttons or asking them to read a captcha) can make them feel like stupid monkeys.
You could use a choice question based on what the user should read.
This is inspired by the question OK-Cancel or Cancel-OK?.
I remember reading somewhere about the concept of switching OK-Cancel/Cancel-OK in certain situations to prevent the user from clicking through information popups or dialog boxes without reading their content. As far as I remember, this also included moving the location of the OK button (horizontally, left to right) to prevent the user from just remembering where to click.
Does this really make sense? Is this a good way to force the user to "think/read first, then click"? Are there any other concepts applicable to this kind of situation?
I am particularly thinking of a safety-related application, where thoughtlessly pressing OK out of habit can result in a potentially dangerous situation whereas Cancel would lead to a safe state.
Please don't do this unless you are really, really, really sure it's absolutely required. This is a case of trying to fix carelessness and stupidity by technological means, and that sort of thing almost never works.
What you could do is use verbs or nouns instead of the typical Windows OK / Cancel button captions. That will give you an instant attention benefit without sacrificing predictability.
NOOOOOOOOOOOO!
In one of our products we have a user option to require Ctrl+Click for safety related commands.
But startling the user with buttons that swap place or move around is bad design in my book.
NO. If you make it harder for the user to click OK by mistake and force them to think, they will still only think harder about how to click OK -- they will not think about the actual thing they're trying to carry out. See usability expert Aza Raskin's article: Never use a warning when you mean Undo. Quote:
What about making the warning
impossible to ignore? If it’s
habituation on the human side that is
causing the problem, why not design
the interface such that we cannot form
a habit. That way we’ll always be
forced to stop and think before
answering the question, so we’ll
always choose the answer we mean.
That’ll solve the problem, right?
This type of thinking is not new: It’s
the
type-the-nth-word-of-this-sentence-to-continue approach. In the game Guild Wars, for
example, deleting a character requires
first clicking a “delete” button and
then typing the name of the character
as confirmation. Unfortunately, it
doesn’t always work. In particular:
It causes us to concentrate on the unhabitual-task at hand and not on
whether we want to be throwing away
our work. Thus, the
impossible-to-ignore warning is little
better than a normal warning: We end
up losing our work either way. This
(losing our work) is the worst
software sin possible.
It is remarkably annoying, and because it always requires our
attention, it necessarily distracts us
from our work (which is the second
worst software sin).
It is always slower and more work-intensive than a standard
warning. Thus, it commits the third
worst sin—requiring more work from us
than is necessary.
[If you want a Microsoftish one, this one by a .NET guy on MSDN says the same thing!]
If you must use a dialog, put descriptive captions on the buttons within the dialog.
For example, instead of OK and Cancel buttons, have them say "Send Invoice" and "Go Back", or whatever is appropriate in the context of your dialog.
That way, the text is right under their cursor and they have a good chance of understanding.
The Apple Human Interface Guideline site is a great reference, and very readable. This page on that site talks about Dialogs.
Here is an example image:
(source: apple.com)
No, it doesn't make sense. You're not going to "make" users read. If the decision is that crucial, then you're better off finding a way to mitigate the danger rather than handing a presumed-careless user a loaded gun.
Making the "safe" button default (triggered by enter/spacebar/etc.) is a good idea regardless, simply because if they surprise the user then a keystroke intended for the expected window won't accidentally trigger the unexpected action. But even in that scenario, you must be aware that by the time the user has realized what they've done, the choice is already gone (along with any explanatory text on the dialog). Again, you're better off finding another way to give them information.
What I've done in some instances was to compare the time of the message box being shown with the time of it being dismissed. If it was less than 'x' amount of seconds, it popped right back up. This forced them, in most cases, to actual read what was on the screen rather than just clicking through it blindly.
Fairly easy to do, as well....
Something like this:
Dim strStart As DateTime = Now
While Now < strStart.AddSeconds(5)
MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK)
If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While
End While
At the end of the day you can't force a user to do something they're unwilling to do... they will always find a way around it
Short cut keys to bypass the requirement to move the mouse to a moving button.
Scrolling down to the bottom of the EULA without reading it to enable to continue.
Starting the software and then going to get their cup of tea while waiting for the nag screen to enable the OK button.
The most reliable way I've seen this done is to give a multiple choice question based on what is written. If they don't get the answer correct, they can't continue... of course after a couple of times, they'll realise that they can just choose each of the answers in turn until the button enables and then click it. Once again meaning they don't read what was written.
You can only go so far before you have to put the responsibility on the user for their actions. Telling the user that their actions are logged will make them more careful - if they're being held accountable, they're more likely to do things right. Especially if there's a carefully crafted message that says something like:
This is being logged and you will be held accountable for any
repercussions of this decision. You have instructed me to delete
the table ALL_CORPORATE_DATA. Doing so will cause the entire company's
database to stop working, thus grinding the whole company to a halt.
You must select the checkbox to state that you accept this responsibility
before you can choose to continue...
And then a checkbox with "Yes, I accept the responsibility for my actions" and two buttons:
"YES, I WANT TO DELETE IT" this button should only be enabled if the checkbox is checked.
"OH CRAP, THAT'S NOT WHAT I MEANT AT ALL" this button can always be enabled.
If they delete the table and the company grids to a halt, they get fired. Then the backup is restored and everyone's happy as Larry [whoever Larry is] again.
Do NOT do it, please. This will have no positive effect: You are trying to AVOID people's clicking OK instead of Cancel, by making them potentially click Cancel instead of OK (okay, they may try again). But! you might as well achieve people's clicking OK when they really want to cancel and that could be a real disaster. It's just no good.
Why not reformulate the UI to make the OK the "safe choice"?
The problem is better solved with a combination of good feedback, communication of a system model and built-in tolerance.
In favor of the confirmation mechanism speaks the simplicity of implementation. From programmer's point of view it's the easiest way of shifting responsibility onto user: "Hey, I've asked you if you really want to shoot yourself into the foot, haven't I? Now there is no one to blame but yourself..."
From user point of view:
There is a productivity penalty of having to confirm operation twice every time even though actual mistakes take up just a fraction of total number of actions, any switching of buttons, breaking the habitual workflow or inserting a pause into confirmation just increases the penalty.
The mechanism doesn't really provide much safety net for frequent users whose reflexes work ahead of the concious mind. Personally I have many times done a complex sequence of actions only to realise a moment later when observing the consequences that my brain somehow took the wrong route!
A better for the user, but more complex (from software development point of view) solution would be:
Where possible communicate in advance what exact affect the action is going to make on the system (for instance Stack Overflow shows message preview above Post Your Answer button).
Give an immediate feedback to confirm once the action took place (SO highlights the freshly submitted answer, gmail displayes a confirmation when a message is sent etc).
Allow to undo or correct possible mistake (i.e. in SO case delete or edit the answer, Windows lets restore a file from recycle bin etc). For certain non-reversible actions it's still possible to give an undo capability but for a limited timeframe only (i.e. letting to cancel or change an online order during the first 10 minutes after its submission, or letting to recall an e-mail during the first 60 seconds after its been "sent", but actually queued in the outbox etc).
Sure, this is much more initial work than inserting a confimation message box, but instead of shifting the responsibility it attempts to solve the problem.
But if the OK/Cancels are not consistent, that might throw off or upset the user.
And don't do like some EULAs where a user is forced to scroll a panel to the bottom before the Agree button becomes clickable. Sometimes you just won't be able to get a user to read everything carefully.
If they really need to read it, maybe a short delay should happen before the buttons appear? This could also potentially be annoying to the user, but if it is a very critical question, it'd be worth it.
Edit: Or require some sort of additional mechanism than just clicking to "accept" the very important decision. A check box, key press, password, etc.
I recommend informing the user that this is a critical operation by using red text and explaining why is this an unsafe operation.
Also, rather than two buttons, have two radio buttons and one "Ok" button, with the "don't continue" radio button selected as default.
This will present the user with an uncommon interface, increasing cognitive load and slowing him down. Which is what you want here.
As always with anything with user interaction, you have a small space between helping the user and being annoying. I don't know you exact requirements but your idea seems OK(pun intended) to me.
It sounds like your user is going through a type of input wizard in the safety app.
Some ideas as alternatives to moving buttons.
Have a final screen to review all input before pressing the final ok.
Have a confirmation box after they hit ok explaining what the result of this action will be.
A disclaimer that require you to agree to it by checking a box before the user could continue.
Don't switch it around - you'll only confuse more than you'll help.
Instead, do like FireFox and not activate the control for 5 sec. - just make sure you include a timer or some sort of indicator that you're giving them a chance to read it over. If they click on it, it cuts off the timer, but requires they click one more time.
Don't know how much better it will be, but it could help.
Just remember, as the man said: You can't fix stupid.
This will give me headache. Especially when I accidentally close the application and forget to save my file :(
I see another good example of forcing user to "read" before click: Firefox always grayed out the button (a.k.a disable) the "OK" button. Therefore the user have to wait around 5 seconds before he can proceed to do anything. I think this is the best effort I have seen in forcing user to read (and think)
Another example I have seen is in "License and Agreements" page of the installer. Some of them required the user to scroll down to the end of the page before he/she can proceed to next step.
Keyboard shortcuts would still behave as before (and you'd be surprised how few people actually use mice (especially in LOB applications).
Vista (and OSX IIRC) have moved towards the idea of using specific verbs for each question (like the "Send"/"Don't send" when an app wants to crash and wants to submit a crashdump to MS)
In my opinion, I like the approach used by Outlook when an app tries to send an email via COM, with a timer before the buttons are allowed to be used (also affects keyboard shortcuts)
If you use Ok and Cancel as your interface you will always be allow the user to just skip your message or screen. If you then rearrange the Ok and Cancel you will just annoy your user.
A solution to this, if your goal is to insure the users understanding, is:
Question the user about the content. If you click Ok you are agreeing to Option 1, or if you click Ok you are agreeing to option 2. If they choose the correct answer, allow the action.
This will annoy the user, so if you can keep track of users, only do it to them once per message.
This is what I responded to Submit/Reset button order question and I think the same principle can be used here. The order does not really matter as far as you make sure the user can distinguish the two buttons. In the past what I have done is used a button for (submit/OK) button and used a link for (reset/cancel) button. The users can instantly tell that these two items are functionally different and hence treat them that way.
I am not really for OK/Cancel. It's overused and requires you to read the babbling in order to say what you are OKing or Canceling. Follow the idea of MacOSX UI: the button contains a simple, easy phrase that is meaningful by itself. Exampleç you change a file extension and a dialog pops up saying:
"Are you sure you want to change the extension from .py to .ps?"
If you perform the change, the document could be opened by a different application.
(Use .ps) (Keep .py)
It is way more communicative than OK/Cancel, and your question becomes almost superfluous, that is, you just need to keep active the rightmost button, which seems to be the standard.
As it concerns the raw question you posed. Never do it. Ever. Not even at gunpoint. Consistency is an important requisite for GUIs. If you are not consistent you will ruin the user experience, and your users will most likely to see this as a bug than a feature (indeed it would be a BUG). Consistency is very important. To break it, you must have very good reason, and there must not be another different, standard way to achieve the same effect.
I wonder if you're thinking about the option that exists in Visual Basic where you can set various prompts and response options; and one option is to allow you to switch Cancel and OK based on which should be the default; so the user could just hit enter and most of the time get the proper action.
If you really want to head in this direction (which I think is a bad idea, and I'm sure you will too after little reflection and reading all the oher posts) it would work even better to include a capcha display for OK.
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...