Basically, what pros/cons are there to using multiple forms in the same web page vs one form with multiple submit buttons? Any difference at?
Ah? Multiple submit buttons on a single form will all submit the entire form when pressed... there's really no advantage to having multiples, unless you're overriding how the submit process works so each button only submits it's own area. In this case they'd probably not even by submit buttons, but just buttons with sum JS code to handle submission.
Multiple forms are discrete spaces of data collection, each can have it's own submit button... but only one of them can be sent at a time (and depending on the browser you may loose what's in the other forms).
Neither approach is particularly good from a user interface perspective since it'll be confusing.
The real question is, what are you trying to do that prompts you to ask this?
The two behave differently and there are good reasons to choose one over the other.
Multiple Forms on a page allow you to send data to two different locations. A common example is to have an input form as the main focus of a page going to one location, and a search form that appears as part of the generic header/footer. These both go to separate locations and submit only the HTML form elements within their appropriate <form/>
Multiple submit buttons offer you the ability to give different purpose to a submitted set of form elements. E.g. One form may have a bunch of submit buttons all with name attributes, meaning you can add conditional logic on the server side to say: "Continue", go " Back" or even "Save for later". All reference only the form elements within it's parent tag.
Two side notes are: 1) You can't nest forms. 2) JavaScript can change this default behaviour if you wanted it to. :)
Edit: with reference to a comment you made, if you wanted to do without JavaScript (a wise choice while it's not needed), you could do some careful thinking and keep POSTing the form to itself. Each time checking which form button has been clicked (top tip, give them all the same name and you can just switch case through it) and do whatever you need to do, including performing validation. E.g: When they hit "add media", you'd save the media uploaded and return a reference of it to the screen as a hidden input. The user can then continue to add things to the other boxes and when complete, hit your save button, at which point you do all the main saving work and make sure you tie the uploaded file to it as well.
You effectively keep adding stuff to their screen until they hit the save and then you perform a save method and redirect to a thank you page (or whatever logic suits your scenario). :)
All fields in a form are sent when one of their submit button is clicked. It's for you to see if you need all fields or not.
Related
I'm looking for insights about how users with disabilities make use of implicit submission (https://www.w3.org/TR/html50/forms.html#implicit-submission) ?
I'm wondering if submitting a form on enter key when focus is in a input text is a must in the accessibility world or not ? I'm sure it could be useful in some scenarios, but I know it could be harmful also in others...
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ? what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?
On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...
I know that JAWS and NVDA offers keyboards shorcuts to go to the next buton, so I wonder if it's really userful for them. What are expectations of users navigating the web with a reader or keyboard navigation on that matter ?
I'm a screen reader user. Implicit submission with enter key is, I think, an absolute must.
Except if it causes more annoyance than it solves, but it's extremely rare.
Generally, screen reader and keyboard-only users are much slower than normal users.
And I confirm that it's quite annoying to have to navigate manually to the submit button when the enter key doesn't work as expected.
By chance, if you are doing things correctly, it's implicit, you don't have to do anything to support it.
The most elementary rules to not break implicit enter submission are:
Use <input type="submit"/>, <button type="submit"/> or <input type="image"/> to indicate the submit button automatically triggered upon pressing enter.
Use onsubmit event on the form, rather than onclick on the button
Make sure that the form has only a single submit button
The submit button must be present, not disabled, and not display:none in order for implicit submission via enter to work.
The button may not be visible on the screen though, if it's your wish.
The second rule reminds you that onclick on the button is bad, because it isn't triggered when pressing enter while being in another field.
Thus breaking implicit submit. This is the most common reason for implicit submit to not work as expected.
The third rule ensure that the right button is pressed when doing implicit submit.
If there are multiple buttons, normally the first one in DOM order should be taken, but browser have sometimes different behaviors, especially IE. So the best is to always avoid it.
Now for your little fears:
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?
In principle it won't happen unexpectedly.
When entering a text field, it is announced to screen readers, whether it is single line (<input type="text"/>) or multiline (<textarea>)
In case of doubt, remember to attach an appropriate label that makes sense.
If the label is "comment", "message" or "address", I can reasonably expect that the field is multiline; if it is "First name" or "city", I implicitly know that it isn't.
what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?
It's very common, but you shouldn't be afraid of it.
It's your job to provide clear and efficient error messages to the user, allongside with as simple as possible navigation inside the form.
The more it is difficult to go back, understand and fix errors, the less chance the form is going to be finally submitted; it drops very quickly, and even more with screen reader users.
How to do it well is another question.
Most forms on the web has the behavior of implicit submission built-in, so users of assistive technology would not be surprised by it, and I've not experienced it as an issue when using screen-readers.
However, you should ensure that you always provide a proper button for submitting the form as well. See WCAG 3.2.2
You should also ensure to make it as easy as possible to go back and change the data afterwards/at a later time.
QuentinC's answer is excellent, so I won't answer every point.
I would recommend that you don't attempt to interfere with implicit form submission, unless you have a very good reason for doing so.
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?
For <textarea>, pressing enter usually produces a new line, and implicit form submission doesn't happen. For <input type="text">, pressing enter causes implicit form submission.
Some applications override this behaviour though (in confusing ways, in my view). A common example is with messaging applications, which have overridden the enter key, so it means "send message". To get a new line, they put some custom behaviour, such as CTRL+ENTER to make a new line. This isn't the default behaviour of a <textarea> though. To make matters worse, different messaging applications do the opposite. A few offer a user preference to configure whether pressing enter sends a message, or adds a new line (Slack offers a preference).
On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...
This is the main reason to avoid interfering with the browser's default behaviours for implicit form submission. As a keyboard user, I often make use of this. Screen readers offer various navigation shortcuts, but these aren't available to a sighted keyboard user who isn't using assistive technology.
I have an input form in which users submit multiple types of information to the database.
Is there any way I could provide an example input of what should go in each field, upon the form loading?
Some fields I'd expect a small paragraph of text, others are dropdowns. The dropdown fields I wouldn't need to put an example of course, just the string text fields. If I try and include an example in the Default value for example, it would save the default value, which I wouldn't want.
Any help is greatly appreciated - It's worth noting I'm quite new to Access & coding in general.
I agree you probably don't want to use default values, or actually enter dummy data into the actual controls for the reason you mention: saving dummy values to the table.
A few possibilities:
Use a custom tooltip. You can do this by editing a control's "controltip text" property. Keep in mind that tooltips are only visible to the user when they hover the cursor over the specific control.
Add a label below the input control that describes the information that should be put in the control. This would always be visible, but can quickly cause your form to be cluttered and difficult to read.
I should say though, that you want to attempt to make your forms as intuitive as possible. For example, if you expect a paragraph of text, make the textbox much larger than a control only expecting a 6 character string. The more you are concerned with UX (user experience), the greater the chance that users will pick up on expectations using subtle design hints. I highly recommend researching the topic if you are concerned that your users will be unable to decipher the purpose of your form/controls. Be sure to check out the UX page on SE.
Furthermore, you can utilize a control's "AfterUpdate" event to validate the input placed in the control as soon as the user moves away from it. For example, you could test if the input IsNumeric() to validate that numbers were entered instead of text. If text is found, you can use a message box to alert the user, and move the cursor back to the control that is invalid.
Of course, that's the customized approach to just using the control's validation rules. The only issue I have had with the standard validation rules is user exhaustion. It can be irritating for a user to deal with validation messages when they are already aware that a typo was made. With an unbound entry form that requires a save button, I usually batch all control validation into the save procedure. This allows the user free reign to skip controls in the tab order without being blocked by constant validation exceptions.
Does anyone know how I can get the same pop up via a button located on different pages (.JSF)?
That is, there is a button "add file" which then opens a pop up with a form where the user adds information about the file. As the pop up is always the same I was thinking of using declarative components. However, I do not understand how.
You can create a taskflow which will contain your page with upload form, and then reuse it on other pages as af:region. Check out this great post with an example how to do it.
I might think about three different ways to achieve this:
1) As #Pregrad said, you can create a Bounded Task Flow and expose this BTF as region (or dynamic region) in every page you need it as a popUp window (recommended if you are using transactions)
2) You can create page templates, put the af:popUp in them and apply the template for each page (recommended if you already have templates, and you need the popUp for each page on your application)
3) You can put the af:popUp component on each page you need it, and then call it programmatically. This approach may be would give you more control on the popUp behaviour but would require you to handle it manually.
The approach you should use does really depend on your needs.
In my Manager controller's add action I want to intercept the form submission, perform a search using the submitted data, and (if the query returns any results) display a list of results to the user.
My question is: what is the best way to display the results to the user? Should I just redirect to a different action (say search), or is there a nice way to display the data while remaining in the add action (session flash maybe)?
I know this can easily be done with the ajaxHelper and I am approaching this from that angle too, but I also need this functionality for my non-javascript users.
Any ideas appreciated!
badp,
you could just have a look at one of the generated (by cake bake controller ..., resp. cake bake view) controller methods named edit and look at the dataflow there.
It should be easy to adept it to your needs from there, as you can compare the dataflow and its outcome visually.
Today I was doing this thing with Spring:
Have a page with a form and a chance to choose one item related to the form.
If you push "Choose item" the app will save somehow what you typed in the form, go to another page, let you choose the thing.
When you are back to the form it's filled with what you wrote before going to the other page, plus the item chosen.
Seems easy, but you have to take into account that for some stupid reason the user could open the page where you choose the item (maybe because of a bookmark, or because he pressed the back button 10 times to play). You know what I mean. I tried many ways, mainly based on HttpSession... I don't like any of those. None of them seems elegant. I was even thinking of using a hidden form in the other page, but given that it is not unique to this "flow" (I mean you can go to the item choose page from others as well), I will have to worry about conflicts and so on.
So what would be the preferred way for you? Suggestions?
Go around the problem instead of solving it. You can use a modal javascript div popup where the user can pick the item she wants. The contents of this div can be loaded via ajax (separate Spring MVC controller called with Http GET). Once the selection has been made, you close the popup (hide the div) and copy the value into the original form. Done.
No need to store the state anywhere.
I suggest Spring Web Flow.
Spring Web Flow compliments the Spring MVC.
Here is link to Spring Web Flow Demo