I have a form with multiple submit buttons, each of which is relevant to how the user wants the data saved and/or loaded.
The problem is (or was) that if a user pressed enter on the last (or any other) input within the form, the submit button that seemed to be called was the "load saved formed" which is at the top of the form. All attempts to user javascript to have the return button default to the "save form" seemed useless, almost as if the browser was too busy already submitting the form to have any js interfere.
Finally, in FireFox 3.5, I actually had the server-side script echo out what it received for the post variable and discovered that none of the submit button values were being passed back to the server. As it turns out, I have hooks in the script for when the user hits "Save" or "Save and Print", etc, but if the user uses the "load page" it simply updates a variable and continues loading the page normally with that variable in context.
So with no submit button value at all, it did the same thing, it simply loaded the page.
So, on to the big question:
Is this typical browser behavior? Maybe even reliable browser behavior? Will hitting enter always submit the form as though no submit button was pressed at all, or do some browsers like to pick a button to use as the default when the user presses enter?
If it is typical behavior, what is the suggested course of action? I was going to have the script save anything no matter what, so long as there was data in the form, but then I realized that this was even more dangerous, because if the user loads one saved form, changes there mind, and changes the form dates and hits "Load Form", then it will save the form data from the pervious form for the new dates they have requested.
I considered setting it up so that changing the load form inputs (selects with dates and other particulars) would clear the form so that the server still recieved an empty form and thus would not overwrite any previous data, but this is risky as well, as many users will certainly notice and think that their data has been lost, etc, and there is always the slight chance that the user will be almost done with the form, go up to the top and fiddle with the form-load selects just to confirm they chose the right what nots and then be forced to start from scratch.
I should just have two forms, one for loading, one for the data, but the problem with that is that all of the data in the load part of the form does get used by the main form. I could write more js to combine the two on submit, or hide the data in the second form, but all of that seems clunky.
Essentially, I need a setup such that the top part of the form is independent of the main form, but not vice versa. Submitting the upper form does not submit the lower, but submitting the lower does submit the higher.
Okay,I've gone on long enough. Basically I'm wondering if a solution already exists or if anyone else has run into this and found a clever fix. I thought simply having the form save whenever the form wasn't empty was pretty clever, until it occurred to me that when the user goes to the page, it auto-loads the most applicable form given the date, and thus changing the load variables will almost always caused trouble.
Having read the possible duplicate that Artelius was good enough to draw my attention to, I'm still unclear on the consistency across browsers regarding the Enter button as submit.
It seems that almost everyone in that question assumed that hitting enter presses the first available submit, which was also my assumption until a friend suggested I hide (via CSS) another submit button at the top of the form with whatever I wanted enter to achieve. It was when this got me the same results that I finally viewed what was being passed to the server (ie nothing in terms of a submit value). So that means either
a) the "enter as no submit button just submit" is new behavior for some or all browsers,
b) the "enter as just submit" vs "enter as first submit button" is just browser choice, no trends, just typical cross-browser unreliability, or
c) Everyone just keeps assuming that the "enter as first submit button" is the case because most of us only code if (situation1) else (assume not situation1) and none of us are really sure what the browser is doing.
I highly doubt it's that last one, but then again, I also highly doubt most of us know which browsers do which. I'd sure like it if there was a straight answer I could pass along.
Oh, and finally: While I know it would be far simpler to use buttons, and I am taking that under serious consideration, I would also like to consider other options, since really the only need for less submit buttons I have is for when users hit enter instead of one of the buttons.
Actually, let me get carried away one more second:
The only thing I really need to know is whether or not they hit enter FROM one of the text inputs. If I could pass that along to the server, I'd know if I should save or reload the form. But the problem is (or at least what I've had troubles with) is that when the user hits enter in an input, it seems like there isn't any more playtime with js to capture anything, and in some cases, it seems like the browser is triggering the onclick for whichever submit button and thus not really allowing me to know the real event that triggered that. I'll play around more with jquery, but has this behavior been observeed by anyone else?
My best advise would be to only have on submit button, and let that submit what ever is the most common usage of the form. Let the rest of the buttons just be normal buttons, which you can hook click events onto.
Just make sure you make it very clear which button will be "pressed" when the user hits enter. Let the submit button be the biggest one. If you have 3 buttons that are used equally as much, I would just drop having a submit button at all...
edit: I'm pretty sure most browsers will post all the data inside a form. If you want to do some checking on the data before posting you could add a listener for onsubmit
<form onsubmit="checkData(this);" ... >
Passing in this will let you check which form is actually being submitted:
function checkData(form) {
var formName = form.id;
//check all the data based on which form is being submitted
}
The HTML5 spec specifies synthetic click activation steps for implicit form submission:
A form element’s default button is the first Submit Button in tree order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.
Related
Previously, I have seen web forms that are multiple pages long, but on each page, if the inputted information is invalid, it will cause an error and make the user fix their input.
However, I can't seem to find anything to show me how to do this. My form is 2 pages, with a Continue button at the bottom of the first and a Submit button at the bottom of the second. However, all possible errors generated will be on the first page, so I want it to show them if the user hits Continue when he has inputted errors.
Right now, the form is only processed after the user hits Submit and all the data is posted to the backend, which means it then has to go back to the first page to show the errors.
You could try to check the information every time the user continues to the next input control, and tell him that there's something wrong if he enters any nonsense.
How to achieve this depends on how your form looks:
Does it just contain and something like that or radio buttons and other "special elements"?
For you could check at the FocusLost event, but I don't exactly remember its syntax.
Much thought has already gone into practices around validating the user input in a form. I have a programming question about the "inline validation", also called "onblur validation". (A research article about the benefits of inline validation can be found here).
Let's say I have a very simple form with 5 inputs and 1 submit button at the bottom. The user focusse on the first field first. After pressing tab or manually clicking on it, he goes to the second input. This triggers the validation of input field 1. Depending on the techniques used, this might take a few seconds (for example, if a server postback is required to truly validate the field).
MY problem lies with the last field. User will be expecting to see the inline validation after they're done. But users do generally not tab if the next ui element is a button instead of yet another input element. Thus, the onblur validation will not trigger and the user gets no feedback, which they might mistake for erronous input. If they manually click on the submit button, the validation will trigger... but it will also trigger the total form submit, likely leading to another page if all is valid. Now, some users might be smart enough to realize this is onblur validation and they should "click anywhere" to trigger the validation, but I can't really count on that.
I thought of one solution: using the keypress event instead of the onblur event for the last input field of a form. However, the article cited above states it is better to avoid this kind of validation. It would also drastically increase the amount of validation to be done (one time for every keypress)
What are your thoughts on trying to mimic the nonexistant event "user stopped typing but did not focus out of input element"? Can it be done by combineing the keypress event and a timer? (Like, if user did not type anything for 2 seconds, then validate?)
var typingTimer; //timer identifier
var doneTypingInterval = 2000; //time in ms
$('input[type="email"]').keyup(function(){
clearTimeout(typingTimer); //reset the timer
typingTimer = setTimeout(validateEmail, doneTypingInterval);
});
Change validateEmail to the name of the function that validates the email input.
I was wondering about the best way to implement a "Confirm Page" upon form submission. I know that it's best for the script that a form POSTs to be implemented by handling the POST data and then redirecting to another page, so the user isn't directly viewing the page that was POSTed to.
My question is about the best way to implement a "Confirm before data save" page. Do I
Have my form POST to a script, which marshals the data, puts in a GET, and redirects to the confirm page, which unmarshals and displays the data in another form, where the user can then either confirm (which causes another POST to a script that actually saves the data) or deny (which causes the user to be redirected back to the original form, with their input added)?
Have my form POST directly to the confirm page, which is displayed to the user and then, like #1, gives the user the option to confirm or deny?
Have my form GET the confirm page, which then does the expected behavior?
I feel like there is a common-sense answer to this question that I am just not getting.
If you must do this (I'd only do it for stuff involving monetary transactions or the like, personally), I'd recommend 2 resources/URIs, both of which follow the Post-Redirect-Get pattern: POST the initial cart checkout, create a "pending order" state (or similar), redirect to the page for that state. The user can then POST from that page to the next URI to create a "confirmed order" (or similar), which redirects to a receipt page or whatever.
What I've done in the past is have one page that has a 'View' area with labels and then a 'Edit' area with textboxes/dropdowns/etc. You can make them DIVs or TABLES depending on your preference.
User comes to page and gets the edit view so they can use the textboxes. Save/Submit button at the bottom.
Clicking on Save/Submit does a postback, populates the labels with the data they entered, and allows them to view/verify what they entered. Continue and Edit buttons at the bottom.
Edit is a postback and goes back to the edit view.
Continue does the actual save and redirection to a new page that displays the confirmation.
Optionally you could save the data on the confirmation page instead of the first page depending on your preference again.
Actually, you could do this ahead of the submit. In the form submit (wherever that is) add an onlick that fires a modal window with a confirmation button. My personal favorite in this situation is to use a Jquery UI Modal Confirmation dialog.
I personally fire this via means of a Jquery .click statement in the page.
So, the document won't submit until the onclick dependency has been completed and changed to "true" which the example does automatically with the included "ok" button.
I believe that this will gracefully fallback to just not require the confirmation if Javascript is turned off, which itself is becoming more and more of an "edge" case. In fact, some of my most staunch corporate clients are starting to accept limitations such as this case when Javascript is turned off....and they're way more picky that most any of us ever will be.
Then, you're free to submit to any page you'd like. Personally, I've switched all of my forms over to a Jquery .ajax submit, but that's just me. You can do it however you like.
I am making a very simple feedback form for an MS-Access application I'm working on. It consists of a textbox (for comments), a Submit button, and a Cancel button.
In your opinion, when the focus is on the textbox, is it more intuitive for the Enter/Return key to click the Submit button or move the cursor to the next line within the textbox?
Edit: The textbox is obviously multi-line.
Standard Access UI is that in a data entry form, the ENTER key is equivalent to the TAB, i.e., moves to the next control in the tab order.
The exception to this default behavior is textboxes that are bound to memo fields. In that case, the default is to have the ENTER key insert a CrLf in the bound memo. Textboxes have a property for this.
In a feedback form, it seems to me that the ENTER key should create a new line when the focus is on the textbox where the user is to type the feedback. ENTER should submit the form only when the focus is on the SUBMIT button.
All that said, your terminology sounds very web-like (nobody uses "submit button" in database forms programming, and certainly not in Access). I like certain aspects of HTML forms and the ENTER key, but have learned from watching others that 99% of the users out there don't know that in an HTML form the ENTER key submits the form (when the focus is not on a multi-line input box).
It's possible to set a command button on a form as the default button, such that hitting the ENTER key will click the command button, but for anything other than a dialog form, that's usually inadvisable in my experience. Users don't expect the ENTER key to execute a command button and making it do so is just likely to confuse them, even if it does make the Access form behave something like HTML forms.
I'd suggest that this depends on your layout: in an obviously multi-line textbox, the average user might expect Enter to move to a new line. In a single-line textbox, we generally don't expect that behaviour.
Depending on the structure of the form.
If the form has several textboxes, I expect it not to send the data when I hit Enter, except maybe on the last text box. Hitting Enter should do nothing, or move the focus to the next text box if you're feeling creative (most users will find this behaviour strange - it is not common in WinForms to move between input fields on pressing Enter).
If the form really consists of one text box and a submit button, then maybe sending the data when i hit Enter is ok, but I'd still be careful - users will not expect this behaviour, except in obvious places (like Google's search text box), and it will annoy the users if they accidently hit Enter and have their incomplete form being sent.
For a multi-line textbox, yes. It's more intuitive for the Enter key to go to the next line. However, in almost every other case (at least for my users), the Enter key should "hit" the "Submit" button.
Caveat: Most of my users use forms with textboxes to do a Search function against the database, which then populates textboxes in another form that disallow editing. My spiffy way to avoid them creating "new" customers that aren't real.
I've got a form like this:
<html>
<body>
<form onSubmit="alert('Just got submitted');">
<p>
Hello: <input class="field" type="text"/><br/>
Goodbye: <input class="field" type="text"/><br/>
</p>
</form>
</body>
</html>
which in one browser submits happily on user pressing enter from one of the fields, and in another browser, doesn't. Oddly, if I remove the second field, it works in both.
My question is really - is it okay to have a form with no explicit submit element? I really like this behaviour.
Having no explicit submit is poor user experience. Your typical end user has, over the past decade, learned a set of principles for website form interaction. Namely, you can tab between fields, you can select lots of checkboxes, and you have a click a button to actually submit your data.
I've tried developing forms in the past that automatically update with JavaScript, and I got countless complaints from users. They wanted a button or they didn't believe it was working. So in that particular case, I kept the form working as it originally had, but added a submit button that really didn't do anything. They were happy.
These days I just build out my forms with normal submit buttons. Not only do users expect it, but it allows for much cleaner progressive enhancement between non-JS enabled browsers.
It's certainly more than possible to have a form with no submit element, especially if you use JavaScript events to submit the form. I highly suggest you use the onkeypress event to detect the "enter" key being pressed rather than depending on the browser to just accept the "enter" key if you make a form with no submits, to make it cross-browser compatible.
However, I think it's bad form to leave out a submit button of some sort. (It doesn't necessarily have to be an input of type "submit", could be "button" or an image you click.) It's just a standard to have forms that people fill out submitt via a button, and you're taking that away, which could confuse many users who are used to a button. It definitely violates the principles of Don't Make Me Think by presenting an alternate form to the norm.
It's not a good idea. You point out the reason yourself - it doesn't work in all browsers. Also, it's not what people expect, so it may confuse people.
It depends on what you mean with "ok".
If you mean valid (x)html, well it's no problem at all, but on the user side, it's a usability issue. But it also depends on the target audience of your website. If its for tech savvy people, then it's ok.
You could create an input button like this:
<input type="button" onclick("doSomething()") />
The doSomething() would be a function in Javascript that would send your form data to a server-side script. This way you wouldn't have a submit behavior.
Submitting a form on 'Enter' with jQuery?
Also, I'd leave the button in the form, but hide it with javascript ($('#submit').hide()). It means that if the user has disabled script or f.ex. uses some other device, he'll see the default way to submit the form.
If you want to have two buttons which generate two different behavior when submit. what you can so is something like that:
or you can put the form submit inside function1() or function2()