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 11 days ago.
Improve this question
I usually add the "clear form" button to HTML forms by default. Is this button actually necessary or a holdover from another time? I have never gotten to the end of the form and thought "I screwed up, I need to reset this!".
I stopped adding those about 1997. It really bothers me when I fill out a large form and accidentially hit the Clear button. I am not really sure why they were ever used in the first place. You're right, I don't think I've ever filled out a form and said to myself, "Oh wait a minute, I think I want to start over?"
The nice thing about the reset button is that it will repopulate all form elements with their original values, not simply set them to zero or blank. So if the form was generated by server with saved data, the user makes a bunch of changes, and then realizes not only that something is wrong but that they also have no clue what the original value was, reset is VERY handy.
Also it's nice for forms with lots of numerical data, like the timesheet page I'm working on right now. There are potentially 16 fields, all with generic, somewhat meaningless numbers. If the user figures out they were looking at the wrong schedule, it's nice to just nuke it back to what the server loaded.
Having said all of that, my page does NOT include a reset button, simply because I didn't want to leave open the exact opposite of awesome it presents, which is "and I'll just click this button to save...oh shit."
What I do instead is any field can be set to 0, but any non-valid data (non-numeric, less than 0, greater than 16) will revert back to the value last entered (which is stored via js). Doesn't offer the grand sweep, but it at least lowers the amount of possible data entry errors and keeps the user from losing data over a simple mistake.
456 has a great article and link on this topic, by the way.
No, we don't need it. I usually just hit the Refresh button.
And then remember it's a #$#$## Flash website.
In what situation would you enter totally wrong information for 10+ fields before realizing it? And then, how much time does it save to clear them before starting over instead of just changing each value? It's adding a major UI element that is not only completely useless, but dangerous for 99.99% of your users so the remaining .01% saves maybe 1 second of their time.
What about one day you need to use it ?
I guess nowadays maybe there are some issues with browsers autofilling forms
for you with irrelevant information that people might want to clear.
I think instead of clearing the whole form, selecting some of them and pressing clear button would be something users would want more.
Anthony's example seems to be the only valid reason why we would add a "clear" button on forms now-a-days. It only seems relevant within a web application of some sort. I don't think general single-direction-forms will benefit much, such as collecting personal information. I couldn't tell you the the last... or for that matter, the first time I ever used a "clear" button as a USER. I can certainly give examples to when I used it as a developer, but that was before Firefox became so awesome!
So; in the end... I think it's more traditional than functional. Unless you've got a complex web application, I see no need for this extra functionality.
I often have a select box that has an "add new >>" option, whereupon the select field morphs into a text field to allow users to add new values to the field on-the-fly. I put a reset button so they can get the regular select box back.
In order to avoid the usability issue of accidentally clicking reset when they meant to click submit I put it some distance away from submit and have it in a neutral tone while the submit button is an accented color (sorta like OS X, it's got the glowing blue button and then the grey ones.)
However, I still don't really like it. I've been exploring a reset button of some sort on each select box that morphs so they can just reset that one piece.
Hmm, maybe your average IE and Firefox users may not be aware that there is a supposed "feature" called autocomplete that these browsers offer by default.
Maybe the "clear form" button is commonly provided for forms due to the chance the user has not unchecked the Remember search forms and history and the Form & Search History checkboxes, and will otherwise be confused and try to manually delete form fields...
EDIT --
And apparently there is a non-W3C-standard attribute autocomplete that can be added to input fields of a form and set to "off." There may be problems with this though, check out this stackoverflow question about it.
Just a thought to the people who can't think of any reason to have a reset form button! We have a search form at the top of our results pages, which is pre-filled with the search criteria from the previous search. Without a reset form button, the user has to either go back to the previous page, or manually clear all the form fields to do a new search. Why pre-fill the search form? So the user can keep the rest of their search parameters the same and change the location they're searching in, for example.
Edit: I just found out the reset button returns all form values to their original values. So, I'm talking more about a "clear all fields" button really.
Related
I want to create a simple survey as an HTML file, where below each question is a Yes and a No button. (or True and False)
Depending which one you click, you are consecutively taken to a different page containing the next question, but the question is different depending on whether you clicked Yes or No.
I created a simple decision tree to describe a situation where that would be applicable to me:
decision_tree_image
I googled this but I couldn't find what I was looking exactly. Thanks :)
edit: Please note, the survey is not supposed to collect or send data. I just want to run it on my computer and reach a branch of the tree, whichever that might be. Nothing further.
You can try and make the buttons a hyperlink and link it to the other question (page).
Here is an example
Make Radio Button Clickable Link
So over the past couple of weeks I've been working on trying to create a way of using google forms as a kind of editable pdf. The idea is to have it be used as a group work order wherein the various people involved fill out the information pertaining to them as they acquire it. Now I know this isn't exactly what forms are designed to do, but it seems to mostly be working.
The way I have it right now is that the initial user creates the initial response, which triggers a script on the form submission, that sends out an editable link via email to all of the contributors to the form. Then whenever a contributor has information to add, they merely have to follow the link, make the change, submit the form and another email gets sent off alerting everyone of the edit.
The only problem with the system, however, comes when two users are filling out the edit link at the same time. At that point the collision resolution (or potentially a lack of collision resolution) for the edit link appears to kick in. The first user will submit and the form gets updated correctly, but once the second user submits, their changes override the changes of the first user. Looking at this from a user standpoint this would be highly confusing. Their change would appear to have been registered correctly, but in reality have been overwritten and discarded.
Now the ideal solution would be that the only changes that are overridden by the second user are those that actually have values in them. I.e. if user one answers question A, and user two answers question B, and both answer question C, only question C is actually overridden, instead of A and C.
I initially thought that perhaps I could compare the two form responses and find some way of doing the collision detection on my own, but there seems to be no way to edit the actual form responses, to change the data on the edit link to match. (Changing the spreadsheet values does not actually have any impact on the edit link itself)
So my question really boils down to is there a way to get this collision detection to work the way I am intending it to? And if there isn't any way to do that, what would be the best way to trigger off a warning email when a collision does happen so that the users would at least know that something went wrong?
The question I have is about the general functionality of the back button in wizards. I was thinking about the possible behaviors of this button and I couldn't find any clue which one is the right choice between these two options.
1- It should show the previous page and the changes made in the current form shouldn't be saved.
2- It should show the previous page and the changes made in the current form should be saved.
I would like to know which option you think is the correct behavior for the back button and why.
The pretty sensible Windows guideline from Microsoft is;
Preserve user selections through navigation.
For example, if the user
makes changes, clicks Back and then Next, those changes should be
preserved. Users don't expect to have to re-enter changes unless they
explicitly chose to clear them.
See UX Wizards guide.
Windows and OS X have always bumped heads on this, but what is the general concensus on whether a Save button or Cancel button goes first in a web application?
[Save] [Cancel]
or
[Cancel] [Save]
Note: I have these buttons at the top of the form flush to the right.
Follow the principle of least astonishment: do it the Windows way ([Save] [Cancel]) unless you have reason to believe that Mac users make up a greater portion of your user base.
The key here is that we are talking "web" usability. To that point, I think it is pretty clear that the principal of least astonishment referenced in the accepted answer would suggest that right is the forward action (save) and left is the backwards action (cancel), and not what the accepted answer suggests.
The web browser is the user interface web users are most accustomed to, and 15+ years of web browsing has made it pretty clear that the back button is to the left of the forward button. It also jives with the left to right based languages that the web was initially developed for. The right is where you are going, the left is where you have been.
Even in general computer vernacular, a forward slash, /, leans right while a back slash, \, leans left.
The windows UI is the outlier here, and I think it is a poor decision to base your UI design on Microsoft's precedence.
I might point out that your top right corner positioning of the two buttons is non-standard, but I don't think it bears on the ordering of the buttons themselves.
Instinctively I always put the Save button as the rightmost element.
I think there are other things to consider. Primarily whether a Cancel button is actually needed, or whether another element (such as a breadcrumb trail pointing to the previous page) might be more appropriate.
Edit: http://www.lukew.com/resources/articles/web_forms.html - The section 'Primary and Secondary Actions' shows how visual weighting can be used to good effect as well.
For all the heated arguments this issue can generate, it doesn’t seem to make much difference in actual human performance. The advantages and disadvantages of each work out to a wash. Users appear equally likely to expect Cancel on either the left or right in web forms. There appears to be a bias to favor Cancel on the left if the buttons are widely separated, but you don’t want to do that since putting the Execute button the far right is associated with slow responses and high error rates on web forms.
I’d say the most important thing is to be internally consistent in you app, and be sure Cancel is always labeled “Cancel” (not, say, “Return” like I saw in one web app). Otherwise, put the buttons next to each other and near the last field the user will look at (which is probably not in the upper right of the form).
And don’t worry about it too much.
It's probably not a big difference either way, as long as it is clear what the buttons do.
My personal vote would be to have save on the left, as that is what people do the most often, and people read left-to-right.
Also, I would also put some space between the buttons, to make sure users don't accidently click one when they are trying to click the other.
Why do you need a cancel button at all?
On a web form, the user can almost always cancel through some other action. Putting "Cancel" near "Save" is creating a situation where the user has a good chance of firing the ejection seat when all they want to do is save.
I generally put the button which will cause the most actions to occur farthest away from the center. If your buttons are top-right, my order would be [Cancel][Save]
Familiarity is often more important than being objectively correct, since things that are unfamiliar are often, by default, less usable.
People use their Windows PC or their Mac more than your app or website. So if I were in your shoes, I'd pick the order which you think will be familiar to the users you care most about. If it's a mostly-mac audience, do it the mac way. If mostly PC audience, do it the PC way.
On a normal form, Save should be under the form fields. Cancel should be to the left or right of Save, but not too close to avoid tragic mistakes. Luke W's Web Application Form Design page has some illuminating diagrams.
Your form is unusual in that you want the buttons to be at the top. In this case I'd need to know what the page looks like and how it will be used. But since you're already breaking any flow between form fields and Save, I suspect Save should be on the right to support the natural left-to-right path.
(Windows and Mac have differing standards for button placement on dialog boxes, and they both have the buttons at the bottom. These standards do not apply to web pages.)
Here are some examples of what I mean:
google.com - focus is set on the "search" box
gmail.google.com - focus is set on the "user name" field (actually, most web email clients do this).
stackoverflow, ask a question - focus is set on the "title" box.
Sometimes, this is a convenient feature - e.g., on Google. From a usability standpoint, however, is it really considered a good feature to have on login pages?
Personally, I have often entered my user name, started to enter my password, then the page finished loading and had focus put back onto the user name field. Unfortunately, since I have complex passwords that force me to look at the keyboard while typing, I fail to notice when focus shifts. I often wind up typing my password in the unmasked user name field for anyone standing behind me to see.
Another situation, less dangerous but still annoying, is when I'm typing a url in my address bar while my homepage is still loading. As soon as it finishes, however, and if I'm not done entering the url, focus is stolen from me and put on some other field.
Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? Do problems like this bother ordinary (i.e., non-programmer) users?
These are really two separate questions with different answers:
Q: Should focus be given to the input field the user is most likely to use?
A: Most definitely yes, if "most users" really is 90% or more.
Q: Should this happen when the webpage finishes loading?
A: No. The "onLoad" event is a pretty stupid place to put this. The input field should get the focus as soon as it appears - it's usually completely irrelevant when the page finishes loading. Just put a <script> tag that sets the focus right after the input element itself.
I personally hate it when websites assume the focus. The main reason is that on my laptop, if I'm using the track pad and hit the backspace key it will automatically navigate back to the previous page. If focus has been placed on a textbox it will treat the backspace as tho I'm trying to delete a character.
My personal preference (and this has very little to do with best practice) is that it nothing should have initial focus, but the first tab will take it to the element that you want to have initial focus.
The same happened to me in Gmail, I find it slightly annoying, especially since it should be easy to circumvent:
In the OnLoad event handler, check if the input boxes (username or password) already contain text. If this is the case, do not change the focus.
As with all simple solutions, I would not be surprised if there were some strange side effects that render it unpractical, but I would give it a try anyway.
Oh, and if it works, why don't you send an email to Google? ;-)
That being said, I consider this behaviour a usability glitch, something that is not a bug, but slightly annoying. Don't annoy your customers. Fix it.
I think only we programmers have the habit of typing even before the page gets loaded ;-)
Most of the non-programmers friends I have wait till they see the "Completed" signal from the loading area.
But the 2 issues above are les annoying than having to move our mouse pointer/use tab everytime to type in what we want (username, password) in sites which do not have focus on a particular control.
"Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? "
I think browsers should be enabled to do this than the websites. Becauase it will be another trip back to server and can be frustrating for connections with low speed.
Overall I think this is just another minor issue/annoyance which we can live with. As I said only we programmers jump in type even before the page loads. Most of my friends dont know that they can type before the page gets loaded :)
There are sites where you acutally have one usecase a normal user uses keyboard for (normal user - as some, like me, use keyboard to navigate also). Sites like Google search actually expect you to just enter what you're looking for and hit enter.
Sites with multiple input areas and multiple exit paths though sometimes put initial focus somewhere too, and then it gets annoying. It gets even worse if they haev some odd tabbing order of their input areas - so they actually force you to use mouse.
I personally don't see the changing of focus when site finishes it's loading as an issue, not for a general user. But, as I mentioned, if it's really useful, it's a matter of what's the usecase in your particular application. And this might be a matter of showing the application in it's beta-stage to some people and performing usability tests.
Yes, focus should default to the most likely place for a user to start typing. Not doing so is textbook bad UI design.
When focus defaulting interferes with something you're already doing, this isn't an inherent problem of focus defaulting, it's a failure of an inadequate implementation. This, among other reasons, is why I put together a generic 'smart' autofocus script that does things like leaving you the hell alone if you've already started typing.
(Yes, I know it's hairy. Most of the hairiness is dealing with cross-browser issues -- a failing of Firefox, actually, for once.)