Many web applications insist that inputted data follow aprecisely prescribed, often unintuitive, form: Phone numbers haveto use an exact layout (“Do not enter parenthesis or dashes inphone number!”), or postal codes can’t have spaces (“Enterpostal code as A#A#A#! Do not enter a space!”).
While sometimes these rules conform to common norms, manytimes they’re completely inexcusable, arbitrary choices on the partof a very-lazy programmer or GUI developer.
I’ve come across this countless times, but it came to theforefront while I looked at “competitors” to the trivial yaflaColor (whichis a micro-utility to solve my own need to easily and quickly getcolour scales for theming). One such alternative included a boxwhere you could punch in the hex color, and out would pop a colortheme. Aside the hex color box, and as a pop-up, was the warning”DO NOT ENTER THE #!” (as web colours areusually prefaced with a #, they clearly knew that many userswould input this form).
Really – What takes longer: Writing a single line of code toparse out the #, or forcing every single user to read andunderstand that warning, and possible alter what they were going toput in there (e.g. if they were just going to paste in web colorsit would be a no go – now they have to edit each of them) Why inthe world would someone choose the route of refusing such aridiculously trivial allowance?
Yet sadly this is entirely too common: Too many times I’ve beenforced to remove (or add) spaces in inputs that have zeropossible impact on the preciseness or ambiguity of theinput.
To save the developer a tiny amount of time, countless users areforced to waste their time.