Posts Tagged ‘web forms’
Why You Should Care About Web Form Usability
Many organizations don’t publish any email addresses on their website because of email spam. On those sites, a contact form is the only way for a visitor to reach the site owner. This should imply that website designers take a lot of care to ensure that web forms are usable by anyone, as email is.
Owing to comment spam and more generally web form abuse, many sites now protect forms with CAPTCHAs or other devices meant to prevent automated software from successfully submitting forms.
The accessibility issues associated with CAPTCHAs for visually impaired people are well known, so I’m not going to discuss this further. I’m going to talk here about people fortunate enough to have normal sight and hearing, but who may also have a hard time using web forms.
Visual CAPTCHAs
Many CAPTCHAs systems are difficult to read because they were designed to defeat automated attempts to read the image using OCR. As the designer of a CAPTCHA system, I’ve been trained more than the average web user to reading them. Still, I’m surprised by how often I miss the correct code on the first try. A high level of image obfuscation may be needed for very large websites like Google or Yahoo, for which it is realistic to believe some people would be ready to invest a lot of effort to break the system, given the potential payoff. But it’s very unlikely someone will try to break the CAPTCHA of the average website. So those should at least be easy-to-read and short, if CAPTCHA there has to be.
Not every web user downloads images. More and more people browse the web via cellphones, on which web usage is charged per megabyte. Users are then inclined not to load images to reduce costs. This is even the default setting on some low-end cellphones. Those users won’t see the CAPTCHA.
Audio CAPTCHAs
Audio CAPTCHAs are commonly accepted as a good complement to visual CAPTCHAs for the visually impaired. Besides the technical reasons for not being able to listen to an audio file on a computer (e.g. no sound support, no loudspeakers or earphones fitted), there are also social reasons. First, there are social environments where it may be rude or prohibited. For example in public libraries and open space offices. Second, the web is global and non-native English speakers may not be able to understand what is said in the audio CAPTCHA.
JavaScript
Some websites require JavaScript to be enabled for submitting a form. It may be because JavaScript is needed to (re)load the CAPTCHA, or because it is used for client-side validation and users not supporting it are redirected to an error page.
If very few people still use browsers without JavaScript support on desktop computers, that is not true for browsers on mobile platforms. More to the point, some people actively disable JavaScript. They do so for privacy reasons, or to get rid of ads. We’ve also seen corporate-wide policies to disable JavaScript for security reasons, i.e. to prevent cross-site scripting attacks and sneaky JavaScript redirects. There are surely compelling forces pushing towards JavaScript acceptance to take advantage of rich and interactive AJAX applications, but those users nonetheless exist and shouldn’t be ignored.
Flash Forms
Some web publishers see using Flash forms as a viable option, presumably in an attempt to reduce form spam. Adobe claims Flash reaches 99% of “Internet viewers” (Sept. 2007). What they mean is that 99% of desktop computers in mature markets have the oldest version of Flash (Flash 6) installed. The figure goes down to 93.3% for Flash 9, and only includes six countries. It goes down to 89.4% for users in emerging markets (97.7% for Flash 6). The figure would be more meaningful prorated to the share of web users in each market segment. Still, I find this figure very high given that for people who are not using video-sharing sites, Flash is mainly a technology for displaying obtrusive ads. I feel that Flash ubiquity could drop a lot if browsers had an option to disable it, as they do for Java or JavaScript.
Posted on Dec 11th, 2007 in HTML form.
1 Comment
Tags: accessibility, form builder, usability, web forms
FormSmarts Compared with Other Form Handlers
What’s specific about FormSmarts form handler? Compared with other web form handlers, FormSmarts may not offer yet the richest set of features. We currently only deliver form results by email, although other form delivery methods are under development.
We believe our Ajax-based form builder allows our users—including those with little technical knowledge—to get an HTML form ready in very little time, and that’s something we wanted. Simplicity, efficiency and usability were our primary design goals.
That being said, FormSmarts is best viewed as a web spam blocker with form handling features, rather than a form handler with form spam prevention features.
Form accessibility is another strong point of FormSmarts: our web forms are usable by anyone, using any HTML-capable browser.
Unlike most other form handlers available today, FormSmarts was puposedly designed to block form spam. We didn’t simply add a CAPTCHA to an old formmail script. The same applies to our form builder: our care for usability and accessibility didn’t come as an afterthought.
Posted on Dec 9th, 2007 in form handler.
1 Comment
Tags: form builder, web forms
Adding Form Filling Instructions to Your Web Forms
You can specify Form Filling Instructions for your web forms. Although this field is optional, we encourage you to make use of it. It will help your visitors complete the form more efficiently, and also help you build trust with them. Here are some information you may want to place in the Form Filling Instructions.
Remind users of the purpose of the form to avoid people submitting the wrong form.
Precise the intended content of particular fields. This will help your visitors complete the form accurately and efficiently.
State for which purposes you will use the data submitted, and whether the data will be shared with a third party. This is particularly important if you collect email addresses and other personally identifying information. People are often concerned about their privacy when submitting forms, so having a clear privacy policy will help build trust with your users.
Include the name of your website, so visitors can be confident they are contacting the right person or organization.
Whenever relevant, give an estimated response time, e.g. “we normally reply within 2 working days”.
Links & Formatting
You may insert links in the form filling instructions and add basic formatting with this wiki-like syntax.
Posted on Dec 6th, 2007 in form builder.
6 Comments
Tags: form design, howto, privacy, usability, web forms
Form Field Data-Type Guessing
The type of a form field defines the range of values it may contain. Using an appropriate datatype for each input field is important to allow correct form validation. FormSmarts form spam filter also behaves differently, depending on the data expected for each field.
To prevent common mistakes, FormSmarts Form Creator now tries to infer the correct field type from the name you specify. However, if you are unsure about what type is best for a particular field, read the help page.
Posted on Dec 4th, 2007 in form builder.
Post a Comment
Tags: form spam, form validation, web forms