Tag Info

New answers tagged

2

Mark the fields that are required for submitting the order. I work on a project with a similar situation. Users can Save the order any time (for completion later) or they can Submit the order to be processed. Saving the order triggers the usual invalid format errors inline and such and is triggered with a Save button at the bottom of the form. This is ...


3

I think it depends a lot on whether this is a very common form or a rare form. If it is rare form, where the user might have little or no idea of what is valid input, I'd emphasize "explaining" a lot more. Since having the field just "beep" or "flash" on invalid entry will frustrate the user who doesn't know what they are doing anyway. If it is a common ...


3

Your second and third bullets (numeric only, maximum length) can be "preventing," because it's more or less clear from the context why the input box is not accepting the characters they are typing. Everything else is almost always "explaining." The ideal, of course, is to both prevent and explain. If your user is running up against a character limit, it's ...


3

There are no absolutes in UI design, so it's impossible to say which is better in all cases. It depends on the data being input, the importance of it being correct, the difficulty in entering the data, the size of the form, the type of user, etc. That being said, Preventing invalid input is generally the best place to start, but you need a ...


2

Create fields for all the main address components, including postal/zip codes, but don't make them mandatory or put restrictions on format. People who are used to always including postal/zip codes will include it when they see the spot on the form. If this is a shipping address, and they actually want to receive their purchase, they are motivated to ...


1

I think you should have the validation happen as they type. I agree with you that it is a little annoying as a user ("I know it doesn't match, I haven't finished yet!") but because its the last field before the submit button, it seems to the best choice for a bad situation. Of course as Taritaro pointed out, if the password is correct do let them know :)


0

I don't agree with what you say about checking for the repeated password being useless and annoying. This would be a different type of validation and therefore it would require different action from the user (re-type the password again) And I don't understand why since this is the last field in the form makes it more complicated. I would go with what the ...


0

Too bad you cannot remove the confirm password field. The method that forms guru Luke Wroblewski recommends is to simply show the password rather than masking it in the first place. Since you don't make that call, the validation should happen on focus out event of the confirm password field.


0

Since you are on a tight deadline and don't have time to properly implement the best solution then my advice would be to provide an additional field and label it "Additional Address info. (zip code, apt #, Attn. name, etc...)" so if it applies to the user then they will fill something in. I am making this recommendation because you specified that most ...


0

Web forms are at times a bugbear for users. The main problem they have is that they feel too much is asked in order for them to achieve their goal (in your case to contact the owner of a website). My view is that, where possible, avoid asking users for information that is not required. Contextualise the request of ZIP code only if that information is used ...


0

Just to offer an alternative solution, which I believe would work best: This sounds like a situation that might benefit from having the form split into various subforms (even if technically it's still one). This however only makes sense if you actually expect people to come to the form with the intent to do something that actually is not possible/allowed ...


1

Do not block the user from completing the form. Allow them to complete the form and fix the errors after. A study in 2007, titled Usable error message presentation in the World Wide Web: Do not show errors right away, was done by Javier A. Bargas-Avilaa, Glenn Oberholzerb, Peter Schmutza, Marco de Vitoa, and Klaus Opwisa. Study abstract: Online form ...


1

I think you are mixing user interface and technical implementation in your design. This leads to more complex interface and hence cognitive load. You could deliver more simple mental model to users: you can change everything (draft) until you approve it (final solution). This model is quite familiar to users: they face it when writing email or creating docs ...


0

This seems more technical than uxd related. However, I don't see why it isn't valid: MDN: The HTML Table Element () represents data in two dimensions or more. W3C: The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells. The problem might ...


0

Inline Validation in Web Forms by Luke Wroblewksi is a great article with test data about web forms that use a basic submit-and-refresh model of interactivity versus real-time inline validation (or the combination thereof). The best way to handle this challenge is to test a few options with users - even lofi paper sketches would be valuable for feedback. ...


1

Just make them clear. Like "Please enter a phone number" for a missing required. Or "Please enter a valid phone number. The phone number you have entered is too short." Tell the user exactly what is required. It is also best to validate before submission with JavaScript and give them instant feedback. Show the error message right near the input field, and ...



Top 50 recent answers are included