In the very common scenario where you have a textbox, and some kind of validation rule which constraints the valid entries on that textbox. How should a failing validation affect the content of the textbox especially in the case when there originally was a valid value entered before the invalid.
Example: Imagine a form where one can enter a number between 0 and 50. The user enteres 40. Everything is fine. But then the user goes in and changes it to 59.
Obviously IMHO the application should inform him about his mistake asap. But what to do with the values? I think there should be a way back to the 40 as an easy way to a valid state, but I'm not sure when and how to revert it: On focus lost? Only on a special key/ button press?
What do you think?
Edit: I absolutely agree with the first two answers: changing the input automatically is a bad idea. Yet I would like to keep the 'last valid' value available ... Maybe a clean UnDo feature would to the trick?
The approach that I take to field validation like this is pretty simple:
Thou Shalt Not Discard the Users Input
If the entry made by the user is invalid, flag it as such - but don't change the value.
The reasoning behind you is simple - consistency.
Consider, for example, a pair of fields used for entry of a date range where "valid" means that the start date is before the end date.
Now, the user wants to enter a completely new range.
If your system discards invalid entries immediately, you force your user into different behaviour. For entry of an earlier date range, the start date must be entered first; for entry of a later date range, the final date must be entered first. Unfriendly.
Instead, respect the users input - when the start date is entered, freely flag it as invalid, but leave the value in place. Then, when the final date is entered, both fields now validate.
This is also motivation for displaying validation dynamically (as values are changed), but for not limiting the users movement between fields.
Depends on you functional specs really, but yeah falling back to the previous correct value sounds like a good practice ... for a blocking error which will always be blocking.
However do you really want to block your user there? What if the valid range is 0-50 when option b is selected but becomes 0-60 when option c is selected? And the user decides to change the ranged value first? Then the user will be very frustrated at having lost what she considers a perfectly valid value...
Keep that in mind when automatically reverting a change made by a user :) The user may have made a mistake but may also have made the change intentionnaly because he associated it to another change in his mind but can't change both at the same time in the application...
Warn that the value is invalid and let ctrl-Z cancel the stuff the user put there may be a more sensible default.
#Bevan Thou art righteous.
If you want to see an example of how annoying it can be crack open Google Analytics
This unfriendly behaviour is exactly what Google Analytics does when you try to compare dates, and it drives me crazy.
If you enter an end date which is before your start date, it discards your entry and thus forces you to enter information in a prescribed sequence.
It also means that small typo's can mean you being forced to retype a whole date, which just sucks.
I agree with the other answers in not changing the user input, you cannot tell what about it may be wrong, perhaps it was a typo, an missing decimal, swapped day/month/year fields, etc. An undo option to allow them to revert back to previous might be an added nice feature however.
The main items in my view are:
- make it clear what the valid ranges and formats are BEFORE the user enteres the data in the form, via examples or other similar indicators.
- be sure to indicate mandatory fields clearly prior to submision.
- user controls that limit the user to entering valida data - date pickers, spin controls, numeric only controls, max lengths set on textboxes, etc.
- make it clear when validation fails as to what item(s) on the form are invalid and why they are invalid, not just a simple "data is incorrect" global message, espeically if you have a long form with many fields that could have validation issues.
Related
I'm going to use PHP in my example, but my question applies to any programming language.
Whenever I deal with forms that can be filled out by users who are not logged in (in other words, untrusted users), I do several things to make sure it is safe to store in the database:
Verify that all of the expected fields are present in $_POST (none were removed using a tool such as Firebug)
Verify that there are no unexpected fields in $_POST. This way, a field in the database doesn't accidentally get written over.
Verify that all of the expected fields are of the expected type (almost always "string"). This way, problems don't come up if a malicious user is tinkering with the code and adds "[]" to the end of a field name, thus making PHP consider the field to be an array and then performing checks on it as though it were a string.
Verify that all of the required fields were filled out.
Verify that all of the fields (both required and optional) were filled out correctly (for example, email addresses and phone numbers are in the expected format).
Related to the previous item, but worthy of being its own item: verify that fields that are dropdown menus were submitted with values that are actually in the dropdown menu. Again, a user could tinker with the code and change the dropdown menu to be anything they want.
Sanitize all fields just in case the user intentionally or unintentionally included malicious code.
I don't believe that any of the above things are overkill because, as I mentioned, the user filling out the form is not trusted.
When it comes to admin backends, however, I'm not sure all of those things are necessary. These are the things that I still consider to be necessary:
Verify that all of the required fields were filled out.
Verify that all of the fields (both required and optional) were filled out correctly (for example, email addresses and phone numbers are in the expected format).
Sanitize all fields just in case the user intentionally or unintentionally included malicious code.
I'm considering dropping the remaining items in order to save time and have less code (and, therefore, more readable code). Is that a reasonable thing to do or is it worthwhile to treat all forms equally regardless of whether or not they are being filled out by a trusted user?
These are the only two reasons I can think of for why it might be wise to treat all forms equally:
The trusted user's credentials might be found out by an untrusted user.
The trusted user's machine could be infected with malware that messes with forms. I have never heard of such malware and doubt that this is something to be really be worried about, but it is something to consider anyway.
Thanks!
Without knowing all the details, it's hard to say.
However, in general this feels like a situation where code re-use should be possible. In other words, it feels like this boiler-plate form validation shouldn't need to be re-written for each unique form. Instead, I would aim to create some reusable external class that could be used for any form.
You mentioned PHP and there are already lots of form validation classes available:
http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=form+validation+php+class
Best of luck!
I have received requirements that ask to normalize text box content when the user changes the focus to another control on the same data input form. Example normalizations:
whitespace at the start and end of the input is trimmed
If the text box was made empty and this is not valid, replace the content of the text box with the default value
I have a feeling that this is not in line with good GUI design. I have read the Windows UX Guidelines for text boxes but I did not immediately find any relevant rules.
Is normalizing text box content in this way acceptable?
I have definitely seen this before (examples elude me right now) but I personally don't like it when the UI changes my input.
If the UI is smart enough to change my input on me then it should accept it as is and change the value when it needs to process it.
When the input changes auto-magically you are now forcing the user to stop and ask themselves why it changed and if they did something wrong or if the application has an error. Don't make the user think!
Generally, you should accept user input exactly has they entered it. Chances are users did it that way for a good reason. For example, imagine a user entering a foreign address, and then your app screws it up trying to format like a domestic address. At the very least, users entered the input the way they’re used to it being, so changing it can make it hard for them to cross-check it.
However, there are several exceptions:
Add defaults to incomplete input. Adding input the user left off (e.g., years to dates, units to dimensions) provides good feedback on how the app is interpreting the input that would otherwise be ambiguous. This also encourages the user to use defaults, making their input more efficient.
Resolve other ambiguities. Change to an unambiguous format if the user’s format is open to interpretation. For example, if you have international users, you may want to change “9-8-09” to “Sep 8 2009” (or “9 Aug 2009”) to provide feedback on what your app considers the month and day to be.
Add delimiters when none provided. Automagically adding standard or even arbitrary delimiters to long alphanumeric strings (e.g., phone numbers, credit card numbers, serial numbers) provides an input display that the users can crosscheck more easily. Sometimes users may enter a string without delimiters in order to go faster or because they are the victim of web abuse by sites that refuse to accept even standard delimiters.
Spelling, grammar, and capitalization correction. Users often appreciate this, but only if there’s also a means to override it. Some users like to use "i" as the first person pronoun.
If the field is used by more than one user, then you probably should automatically format the value in some standard way that accommodates the majority of your users, but that should be done when the value is stored on the backend, not when focus leaves the field. For example, if a user enters a time of 15:30 it should remain as 15:30 as long as the user views the page. However, the next time a user (any user) retrieves the data, it should appear as 3:30pm (if that’s how most of your users are used to seeing time).
Such backend formatting applies to trimming whitespace so that all users can search, find, and sort on the field consistently. It’s probably not a good idea to replace a blank value (or any invalid value) with the default because users are unlikely to anticipate getting that value. An exception would perhaps be changing blank to 0 for numeric fields in situations where obviously blank == none == zero, but again this probably should be done when storing in the backend, not in the field itself. If blank is ambiguous, (e.g., may mean 0 or may mean "I don't know") then the second bullet above applies, and you may want to autocorrect in the field when focus is lost.
Of course, if your users vary in how they need to have a data type formatted, then you can have different variants of the app that display the data type in different ways for different user groups, or you can make the format of the data type a user preference, but that’s really another issue.
If the user wants it, and the Stakeholder ask for it, then is perfectly safe.
Trimming is very common. and the replace is common when you are talking about filling textbox with numbers. (a 0 instead of a blank).
It's a fairly standard feature, especially the whitespace trimming. The default value replacement raises a larger flag just because it is less common.
I'm pretty sure that I've seen versions of Microsoft Office that do this - putting "pt." after a value in points, for instance. Microsoft's endorsement should be a good sign.
We have quite a few of these kind of requirement. The reason given for forcing a default value rather than a blank space is that it looks better in reports or if the client wants to see the live system. A blank looks a bit like "couldn't be bothered to enter anything". For a similar reason, we often upper-case the text for consistency as the users never use consistent formatting.
Very simple question: should a dropdown list be used to populate state abbreviations? From my experience, I think most e-commerce sites do this so I would expect that it's acceptable. However, Jakob Nielsen has something to say about this.
I think I disagree; I use the tab key then type the first letter of my state. Heck, even if it wasn't the first entry, I've done this enough times, I would hit the letter repeatedly and get to what I need. I never need the scroll wheel or mouse.
Is there any additional concrete guidance out there on this particular question?
I think this will become less of an issue now that most modern browsers scroll the drop down lists based on each consecutive letter you type, not just reading the first letter as they once did. So, If you type N-Y, the drop down list will scroll directly to NY and you do not have to hit N a bunch of times.
Since a state is a two letter abbreviation, I wouldn't put a drop downlist, I would put a textbox, but I would validate it using AJAX or Javascript to warn the user about an error, right after he entered something wrong.
DropDown / Auto-completion (in my opinion) is useful when the data to enter is longer / more error-prone.
If you insist on using auto-completion or dropdown, you should put long state names, not just the abbrev.
I don't know about concrete guidance, but one alternative I would consider is using an autocomplete text box that forces you to choose from one of the available choices. I agree that a 50-item drop down list is too long and using autocomplete with enforced choice accomplishes the same purpose -- consistent data -- and has the advantage that it is much easier for the user to navigate. If you don't want to limit the choices to just US states you could drop the enforced choice and just let the autocomplete work as a suggestion with the user being able to enter free-form input.
EDIT: As #Martin suggests, I would probably have the autocomplete show the full state name, even if it only entered the abbreviation. This would solve issues of people getting the abbreviation wrong as well, though you could do the same thing in a drop down -- display the name with the abbreviation as the value.
I was going to post NYSystemsAnalyst's answer, but he beat me. I will instead add a caveat... If you use a dropdown list, it must be complete. Do not forget the obvious DC, or the less common but plausible PR or AE/AA/AP, or the rather improbable but still valid AS, FM, MH, MP, PW, and VI.
The official list
I think it depends on if you are asking a user to enter their own address or someone else's address (ship to address). Everyone knows their own state abbreviation, but may know all the state abbreviations.
So for entering your own address a textbox is the quickest and easiest way, but if you are asking the user to potentially enter someone else's address a drop down is probably best.
Of course, if you site has a combination of both types of address, you want your UI to be consistent and use the drop down for both. Also, if you are using a drop down, I would suggest using the state abbreviation and name (AZ - Arizona) when the drop down is expanded (but just show the abbreviation when it is collapsed).
I'm willing to bet that half the users of online e-commerce sites don't know the abbreviations for the states. Think if you're shipping a gift to someone and you can't remember whether its MS, MO or MI. Dropdowns are fine.
I've never had an issue with state drop down boxes (and this is from someone routinely at the bottom in West Virginia). I've gotten into the habit of just tabbing and pressing W and then it will either recognize the "E" and give me the correct state, or it will not recognize the "E" and then I have to hit the down key once or twice (depending on sort order) to get the proper state.
So all in all I am looking at 5 key presses max to get to my state. I don't think it's that bad.
How about a textbox with validation, and a drop-down list if the state abbreviation is invalid?
I've long thought (but never practiced for some reason) that a dropdown menu that is dynamically generated and only contains one item, should automatically select that item. This would opposed to the typical approach that I've observed where a blank entry is made at the top and you still have to interact with the menu to make the single available selection.
An example is when I login to my online banking and select "View Paper Statements". I've only got one account so the next step in the process is to present me with a dropdown where I have to select that single account to proceed. In this case, by implementing the solution above, it would take one less click to select the account and proceed to viewing it. Even better in this case would be to eliminate the dropdown menu step altogether and go right to the statement.
Can you think of a case where auto-select of a single item would produce undesirable results?
Can you think of a case where auto-select of a single item would produce undesirable results?
Yes - any case where the user has the option not to select any option.
In your bank account example, pre-selecting the only value makes sense. But if you have e.g. some kind of form where users can provide voluntary information, they will need the possiblity to leave that field blank or otherwise give a possible incorrect answer.
So it really should depend on the nature of the data in that dropdown whether pre-selection is a good idea or not.
I completely agree, in the case you describe. But there are times where you want to force the user to make a selection actively -- e.g., when the value of the field is somehow optional or additive.
In your case, without selecting an account, there's probably no useful way to proceed, so automatic selection does make sense. But for example, an application I'm working on allows the user to specify a number of descriptive fields (movie metadata, basically -- title, release year, genre, etc.), many of which are optional, and some of them are represented by drop-down menus. Allowing the user to leave the default selection blank lets him tell us, effectively, "I don't want to use this field," so we leave it blank, and the data remains clean.
Just one example, although you're right -- in your case, I can see how that'd be annoying. :)
If there is truly only one possibility you shouldn't ask a user to decide between Option A. (Bad grammar to illustrate the point)
If the field can be left blank, it's not an option with a single answer. Instead you have a choice between Option A "meaningful data" and Option B "".
Iif list has blank option but the form does not allow that to be blank, it's a choice between Option A. (Bad grammar to illustrate the point)
Sometimes you want the user to explicitly select an option, even when it's the only option. If the option is selected automatically, the user may never even realise it, even though they may not be happy with the result.
For example, I'm reviewing my savings account on my internet bank site. Then I go to set up a payment. As it happens, I'm not allowed to make payments from my savings account, so the payment form automatically selects my only other account. If I don't notice this then I will end up making the payment from my other account when I was expecting to use my savings account. If I had known, I wouldn't have made the payment at all.
Perhaps this is slightly contrived. But unless you can be certain that the user will be happy with the (only) choice, you should ensure that they choose it explicitly.
I agree. If there's only one item in the dropdown and it's required that the user select something, then just default to the single item. I can't think of any negative effects of this (but I'm certainly not a UI expert)
What I like to do in this instance depends on a few factors.
If the dropdown is a required field and ends up with only one item due to dynamic generation, I try to avoid displaying it as a dropdown entirely. I end up showing it as an uneditable text field instead (or not displaying it at all if it isn't necessary). Why make it even look like it's a choice when it isn't?
If the dropdown is not required, then it makes total sense to display a blank choice in addition to the single value.
If it's REQ and there's a single record/value .. I'd try and change the control to a Display field rather than the Drop Down.
When you're passing variables through your site using GET requests, do you validate (regular expressions, filters, etc.) them before you use them?
Say you have the URL http://www.example.com/i=45&p=custform. You know that "i" will always be an integer and "p" will always contain only letters and/or numbers. Is it worth the time to make sure that no one has attempted to manipulate the values and then resubmit the page?
Yes. Without a doubt. Never trust user input.
To improve the user experience, input fields can (and IMHO should) be validated on the client. This can pre-empt a round trip to the server that only leads to the same form and an error message.
However, input must always be validated on the server side since the user can just change the input data manually in the GET url or send crafted POST data.
In a worst case scenario you can end up with an SQL injection, or even worse, a XSS vulnerability.
Most frameworks already have some builtin way to clean the input, but even without this it's usually very easy to clean the input using a combination of regular exceptions and lookup tables.
Say you know it's an integer, use int.Parse or match it against the regex "^\d+$".
If it's a string and the choices are limited, make a dictionary and run the string through it. If you don't get a match change the string to a default.
If it's a user specified string, match it against a strict regex like "^\w+$"
As with any user input it is extremely important to check to make sure it is what you expect it is. So yes!
Yes, yes, and thrice yes.
Many web frameworks will do this for you of course, e.g., Struts 2.
One important reason is to check for sql injection.
So yes, always sanitize user input.
not just what the others are saying. Imagine a querystring variable called nc, which can be seen to have values of 10, 50 and 100 when the user selects 10, 50 and 100 results per page respectively. Now imagine someone changing this to 50000. If you are just checking that to be an integer, you will be showing 50000 results per page, affecting your pageviews, server loads, script times and so on. Plus this could be your entire database. When you have such rules (10, 50 or 100 results per page), you should additionaly check to see if the value of nr is 10, 50 or 100 only, and if not, set it to a default. This can simply be a min(nc, 100), so it will work if nc is changed to 25, 75 and so on, but will default to 100 if it sees anything above 100.
I want to stress how important this is. I know the first answer discussed SQL Injection and XSS Vulnerabilities. The latest rave in SQL Injection is passing a binary encoded SQL statement in query strings, which if it finds a SQL injection hole, it will add a http://reallybadsite.com'/> to every text field in your database.
As web developers we have to validate all input, and clean all the output.
Remember a hacker isn't going to use IE to compromise your site, so you can't rely on any validation in the web.
Yes, check them as thoroughly as you can. In PHP I always check the types (IsInt(i), IsString(p)).