Jun
24

Why can’t website forms be more intelligent?

MarkusRants

I’m really disappointed about how stupid web forms are sometimes. Consider this:

  • A captcha that has as a side-note: “Please do not enter whitespace characters“.
    • Why can’t the website just filter the whitespace?
  • A edit field for a URL that has as a side-note: “Please also enter the http://“.
    • Why can’t the website just add the http:// when it is missing?!
  • A submit button with side-note “Please hit submit only once“.
    • Most websites don’t have this anymore, they disable the Submit button with Javascript. Thank you :)
  • A edit field for a phone number that insists on a specific number format.
    • Does the number format matter in any way except for the +Countrycode at the beginning? Why not just filter everything except numbers?

All of these mentioned are even happening on very big sites who should have the people who know better. Are there any reasons except annoying me?

Does anyone have more examples? Please comment :)

(Translated from the blog of guruz)

Update: Blogoscoped has another posting about forms in websites.

Are you interested in reading more from CodingClues?
Then subscribe to new postings via RSS or via E-Mail.




Viewing 14 Comments

    • ^
    • v
    @Thomas Farrell and your

    "Why can’t users be more intelligent? Why do we programmers have to go to the trouble of coding buttons that vanish after used "

    You are the type of person I would never want in my team, an arrogant programmer that thinks all users are stupid - you give IT departments a bad name. You talk about intelligence - have you ever considered being intelligent and thinking about it from a users POV. Have you ever dealt with a non-responsive interface? How do you know your action has actually be processed? Need a clue - it is called feedback.

    Would you find as website where you submit and order and the page remains the same once your order is submitted a good design? I mean, why would anyone want email confirmation, why should programmers go to the bother of coding it.
    • ^
    • v
    I think that is because the forms aren't treated as an important part of the project. Probably the described things remain from the testing phase, when the developers showed the things they've done, however they left "the unimportant" parts (i.e. forms) to the last development phase and of course they forget about that or simply don't have enough time to finish.
    • ^
    • v
    The first makes perfect sense to me. You present a captcha (that includes spaces) and ask for the user to retype it sans-spaces. You then check to see if what they typed has spaces and reject it as invalid -- if the captcha is OCR'ed or inserted by a human in a pre-made system it is less likely that they'll see the "please do not enter whitespaces" statement and will enter the whitespace. Result: more likely that your traffic is authentic human.

    The rest are because the programmers are lazy, overworked, behind schedule, rushed, not fully specified.. pick and choose.
    • ^
    • v
    I didn't hear about the captcha thing yet, but you are of course both right... no time and a focus on more new features leave those things behind..

    I'd probably do the same when not being forced to focus on such aspects.
    • ^
    • v
    Why can't users be more intelligent? Why do we programmers have to go to the trouble of coding buttons that vanish after used, just because users are too stupid to realize that hitting the button 50 times just makes it take longer? Why do we have to waste processor time trimming whitespace from strings just because users are too stupid to realize that entering a bunch of blank space around everything they enter might make things work incorrectly?

    Maybe the reason we don't "bother" coding around stupid user behavior is because it doesn't occur to us to do stupid stuff with forms.
    • ^
    • v
    Wait for Web Forms 2.0. They will have implemented out of the box most things you complain about.
    • ^
    • v
    I disagree with disabling a submit button after form submission.
    Occasional form submissions I've made I have cancelled to make a modification, then been annoyed at having to refresh the page or fiddle in Firebug to reenable the button.

    IMHO a 'get' form should not disable the button. At all. Ever.
    There is more argument for disabling with a 'post' form, but submitting the same thing more than once is better handled server-side either at application or database level.

    @Thomas Farrell - I agree totally, development life would be much better if users weren't so stupid. I'm sure many aspects of engineering would be much easier if friction didn't exist.
    Unfortunately neither of these things can happen. Users *are* often stupid, and seeing as you're writing a Website for their benefit you must design and code with them in mind.
    It is a harsh realisation to come to, but an important one in UI design I think.
    • ^
    • v
    Regarding the second point: Not all URLs start with "http". You have to consider the possibility that the site being entered is a secure site ("https") or an FTP site ("ftp").
    • ^
    • v
    Yes, but when it is not prefixed with whatever:// I think you can safely assume http:// :)

    Coding with a focus on usability, sane defaults and fail-safe is a nice thing in web applications.
    • ^
    • v
    I totally agree with you! There are more annoyances though... like no submit button - relying on user hitting Enter key.
    • ^
    • v
    Regard the submit button what if u browes the website without javascript on or better, what if u noticing this behaviour turn javascript off??? ahhhhh??
    for sure you developer have to keep that in mind, one little thing between the magic world of web developing
    • ^
    • v
    Turned off Javascript (be it per default or on purpose) has to be considered, yes. But this is what nonces ("number used once") in a hidden form field can be used for.

    http://en.wikipedia.org/wiki/Cryptographic_nonce
    • ^
    • v
    The most important reason why those things are not into browsers right now according to me, is because it will only complicate things.
    Let me explain:
    Imagine having to expand html (or xhtml) with all the functions you want. Now imagine you have to get it supported by all big browsers out there. Since we have another browser war, that won't be that hard but still. Now think about the fact that all your messages have to be able to be translated, but also supply default settings. Now, those default settings should be the same on every platform/browser. If you got that far, think about different encodings. Sure, the whitespaces are trimmed when entering just latin1, but are they trimmed when entering utf8? And the error message is shown correctly in English, but what about ie Arabic where text is written from right to left? Localization in itself is one of the most important and hard parts of writing software that is going to be used all over the world. Next is the backwards compatibility. You can't just expect all people to install a new browser at once! Look at the usage statistics of IE6, 30% of the people still use it and god knows it doesn't follow standards. Things might not seem as easy as you think...
    • ^
    • v
    @Steve
    The funny thing is, the BROWSER should give the feedback that your form is being send, but if you look at IE7 or IE8, you can hardly tell it anymore. So now the web developers have to add behaviour to all of their forms or the users will start to "whine".
    Not trying to defend the "users are stupid" pseudo-argument, just pointing out that the responsibility to provide the clearly needed feedback seems to have shifted from the browser to the web application and basically the web developers take the blame for the mistakes of the browser developers now.

    Of course Markus is right, a simple nonce can prevent most problems from double submissions. That doesn't solve the lack of feedback, but it at least prevents corrupted data.
 

Trackbacks

(Trackback URL)

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus