Scrolling shopping baskets

December 7, 2009

Some quick thoughts..Scrolling SB has comes with risks. If the shopping basket is too long, the totals and ‘checkout’ call-to-action button could appear below the fold. This is especially the case if many products have been added and at lower resolutions or non-maximized screens. Users would have to scroll to the bottom of the page to get the ‘checkout’ button in view.

I recommend:
– non-scrolling SB.
– if it must scroll, then make sure it anchors to the bottom of the page, so the checkout button is always in view (the top the basket then won’t be though..)
– make it scroll along slowly 
– either keep the product descriptions short (or empty) or consider removing the totals. test the worst-case scenario if it is a likely one.

Anybody seen any examples?

Improving electronic forms

December 6, 2009

Online and web forms

For e-commerce businesses it may be cheaper to make some easy fixes to your form than to implement for inline validation. Quick wins, like the ones listed below, may be cheaper to implement and have more effect on conversion than inline validation.

Always consider making these form improvements first:
Remove optional fields. Let users fill that out via their profile after registering.
Make input formats forgiving and if possible auto-correct user’s data for them without surprising the user negatively (don’t show them the corrections you made).
Clean forms and make them easy and fast to scan by eye.
Improve the emotional experience. Make the form page pleasant (e.g. and filling in the form fun (e.g. ex-Flickr) or calm.
Improve error copy and make messages clear, errors fast to detect and easy to correct. For example make use of red highlights and scroll to the error when user clicks Submit button.
Pre-fill fields with gray examples or give a short static explanation just near the field (below or to the right of the field).
Use inline hints to guide the user when clicking on a field.


Best practice     includes DOB. Optimisation maturity unknown.

When to use inline validation

December 6, 2009

Still uncertain whether inline validation is worth it for you? Can inline validation make your businesses happy? How useful it is to you and your customers depends mainly on your form content.  It may be distracting if overused or misused. Expect that you need to spend some time redesigning your form and copy to accomodate for inline validation. Else you may introduce new usability issues. Not to forget the development costs and testing the implementation which is vital for rich interactions as these.

When is inline validation useful

Registration forms, where comparing user input to server data may prove useful to find out if a new domain name is available or password is secure enough.
Unique fields such as usernames.
Exceptionally long forms or forms with many fields, where filling in or returning (pogosticking) back to the page is experienced as very painstaking at the point that it risks several users bailing out of the process.
 For longer forms it is better because it prevents the user from being overwhelmed if there are a lot of issues.
Time-critical situations, where a user focus is dedicated entirely to a field and real-time feedback is essential and expected. Also if the user wants immediate assurance that data is valid or how to correct it as soon as possible.
Data-critical situations. If a user needs immediate assurance that submitting is not is risky or input data cannot be undone. He might want to know the consequences of his input or selection before submitting the data. Can he still correct wrong data? Make it clear that undo is available or returning back to the form will be possible, for example by using progress indicators to show the user the form filling is a multi-step process with a confirmation step before final submitting. Or (like Amazon) writing under the submit button a text: “You will have the chance to review your order before it is finalized”.
Forms with complex data and strict formatting. If users might doubt during or right after filling in a field, inline validation might be just what is needed to give that instant confidence boost and motivate the user he’s on the right track.

When is inline validation less useful

Order forms. Typical order forms ask a user for contact and payment details, which is pretty standard stuff to the user. I don’t expect it to improve form completion time much, if at all.
Tricky copy. With Inline validation error messages appear suddenly which is why they are usually placed next to fields rather instead of in between them. Some designs are limited in space hortizontally, so error messages need to remain short. Shortening error messages may potentially make them less clear and less usable. After all, error messages should not only say that something is wrong, but may also need to say what is wrong and how to correct it (sometimes with examples or formatting suggestions).
Tricky audience. Websites with relatively many users with different browsers or with Javascript disabled. Inline validation can come as a penalty to non-broadband users with slow connections. Slow PC’s may also be affected depending on what technology you use for implementation.

Consider your users and your form

Ask yourself the following:
– What information do I ask from the user in my form?
– Which fields might the user have trouble filling in?
– If you’re desperate for quick results, have you considered first making other general form improvements?
– Will the time/resources invested in inline validation outweigh the increase in conversion?
– Is there a risk it will decrease it? By definition for any design: less is more, meaning don’t clutter your design with elements which don’t add value.

Measuring the impact of inline validation

If you can implement inline validation, test it on a small audience and revert back to your old design easily, go right ahead. When you want to measure if it makes a quantitive difference (conversion rates) then A/B split testing will give you the answers you’re looking for. But remember to measure other KPI’s, especially if you expect no or not much effect on conversion.

Conversion is critical to businesses, and customer satisfaction often comes secondary. I predict it won’t make a difference to conversion rates of most order forms, but can benefit in other situations where inline validation is useful (e.g. sign-up forms where usernames are scarce or where there is a strict password policy or other complex fields) – discussed earlier in this article.

Consider the effect on other KPI’s like customer satisfaction and lead generation. User experience may improve or suffer. SEO, performance, compatibility may suffer and these play an equally important role in conversion. In some instances lead capturing may be incomplete and lead generation may decrease. Plan the A/B testing well.

In the case conversion/lead generation impact is insignificant, I highly recommend that you also measure the impact on customer satisfaction. This could be measured via a usability test, but preferably via a web questionnaire.  

It could A/B test to measure differences in KPI’s such as:

o        form or order completion satisfaction rating

o        form completion difficulty

o        company friendliness/helpfullness rating

o        form completion time (subjective)

Inline validation design and implementation

December 6, 2009

This post is a continuation of the article about Research into inline validation which discussed risk of loss of conversion.

When (re)designing a form for inline validation you might come across some design challenges. This article discusses some issues and considers some suggestions on how to solve them. First I will discuss implementation issues, and the technical costs, then design issues.

Error messages

With inline validation forms become very dynamic. Because inline validation occurs while the user fills in a form, there needs to be adequate room for helpful error messages. The form probably needs to be redesigned to make room for these messages. This may have some negative consequences. Error messages being inserted and removed between fields may confuse and annoy users due to fields constantly moving from their original position.

This could be solved by a combination of the following:
Compacting forms (horizontally). Its nice to place error messages right next to the field they are refering to. The form may need redesigning (decreasing widths of input fields) for these error messages. This may create new usability issues or new design challenges.
Increasing vertical whitespace between the fields. Increasing forms vertically has many downsides. A longer page might convert less well and makes labels less scannable. It may put off users from filling in the form in at all.
Call-out error balloons can be used. But these may overlap other form elements or obscure other error balloons.
–  Short error messages with the risk of making them potentially less clear and less helpful.

Also keep in mind:
– Show each error message near the field instead of only at the top of the page. This is the whole point of inline validation.
– Prevent error messages from appearing above or below the fold and out of sight. Scrolling to the error might be disliked. The problem can be partially solved by ensuring that error messages appear above their respective fields, where they usually have more chance of being noticed. Discussions about scrolling to errors here and here. This feels like patchwork, however, so try to solve the initial problem rather than using ‘scotch tape’ or stop-gap methods to cover up new ones.
– Error messages should be noticable, visually distinct: most times red.
– Don’t make an error message a Javascript dialog.

Error icons

In inline validation a correct field could be marked by a tick or (green) checkmarks or the text OK. The purpose of this is to reassure the user that what was typed in that field is correct. The business value is that it can help motivate users by giving them the confidence that there is no error so they can continue.

The checkmark as a confirmation of acceptance or pass may not be universally understood by all cultures. Some plausible variants of checkmark:
– OK text (preferably in green)
– smiley
– thumbs up
– VALID text (best for accessibility is an icon that includes the word “valid” or an even more specific messages such as “valid email address”)

If you use inline validation, you shoud strive for consistency. Just like error field might need an error icon, every valid field then also needs a checkmark icon. Leaving the checkmark out may make users uncertain about the fields that do not contain an error symbol. The user will start to think “are these fields correct?” or “is the system still checking these fields?”. This is especially an issue if you plan to use inline validation only on a few fields within your form, which would be an inconsistent user experience.

On the other hand, consistency can be a bad thing. It can be overdone. For example, watch out for the christmas tree effect: it could leave you with many green (valid) and red (error) colours blotted over your form. Ensure your form remains clean and aesthetic.

Checkmarks that fade out with time are easily missed by users. To avoid the christmas tree effect, you might want to make disappear or fade out after a few seconds. [2]: “Yahoo provides instant feedback each time users fill in a field by showing a tick at the end of the field. Each tick disappears after a few seconds. The majority of the participants commented they did pay attention to them. However there were mixed opinions from the participants on the animated ticks. Some of them gave positive comments, whilst others thought they were distracting.”

The tick or checkmark is the most common symbol to indicate that a filled in field is valid. Consider the effect of leaving them out; they might not be needed at all. Can you afford to go for inline validation for only a few fields, or will it make people think and doubt? See my other posts on in which situations I think inline validation can be useful versus harmful.

Implementation challenges

Inline validation comes at a cost. Is there hope? Here are possible work-arounds for overcoming the cons.

Leads: Capture e-mail address and contact details first. Ensure you capture data while a form is filled in, and not only upon clicking submit button. This requires an AJAX like server communication, possibly more moderation and more costs…
Smart format recognition: Ensure forgiving input (make the system smart in recognising errors and correcting them itself).
Requires Javascript. Use a lightweight Javascript. Around 2% of users have Javascript disabled (on purpose), so by using inline validation your are losing them. If you want to support users without Javascript, you might want to use inline validation with normal server-side validation as a back-up. Alternative technologies are Flex/Flash, Java and AJAX, although Javascript is your best bet due to its ubiquity.

– All client side validation (onBlur) must be enforced with server side validation (onSubmit).
– Scroll to the first error onSubmit, as even for large resolutions the error might still be out of sight (outside the fold).

For a comparison of server-side and client-side validation (ideally you should have both in case one fails), see this article.

Developer toolkits

This post is a continuation of the article about Research into inline validation. Be sure to check out my other posts on inline validation research.


Inline validation: pros and cons

December 6, 2009

Inline validation: benefits (advantages) and costs (disadvantages)

If you’ve read our article about research into inline validation you have found that ….

There are some. A comparison.


Helps with tricky fields. Appreciated by users for fields which they want to provide extra thought and care (username, password) or are tricky to fill in (bank account and credit card numbers) or are typically written in various forms.
Immediate help. Appreciated by users because form completion time can be shortened due to immediate feedback. Users remembered what they just typed, so they are in the flow of providing that data and are also more capable of correcting it.
Motivation. Encourages the user by affirming that everything is correct and that he will not remain in the same page but arrive at the next page after clicking the submit button.
– Shorter forms. With inline validation error messages will usually appear next to rather than under fields, depending on where error messages appear. On the other hand, if there are 2 fields placed next to eachother and they are both wrong, how and where will system communicate this?


Cost. Can be expensive to implement (server-side).
System performance. Inline validation may lead to larger scripts, server slow-downs (if error rate is high) 
– SEO. More Javascript may mean heavier, more complex pages. Google might rate your form page lower.
– Expertise. If not designed properly can harm usability and conversion. Also testing intensive.
Leads. May harm lead capturing and lead conversion (especially if user encounters an error, is discouraged to continue filling in the form)
Surprise and distractions. Users don’t know that their form is being validated until they notice a checkmark or error message. Badly designed checkmarks are interpreted with confusion, so it needs to be clear what they represent to be understood. Clicking Submit must scroll the browser window to show where the first error is.
Disrupting. Completion mode versus revision mode theories tell us that interupting a user interupts his mental flow (especially for those users who hardly look up to the screen from their keyboard). Does this lead to increased form completion time? 
Conversion benefit unknown. Requires A/B split testing to determine if it really makes a difference on conversion without doing too much harm to gaining leads.

Asterisks or optional fields

December 5, 2009

Advocates of clear optional fields:

Research into Inline validation

December 4, 2009

Inline validation may seem useful at first insight, but should be implemented carefully and only if appropriate. If you’re still sceptical about its costs and benefits are, read on.

In this first article of the series I  outweigh the pro’s and cons and provide existing researches and a checklist. In other of my posts you can read about the design and implementation challenges you might cross.

Inline validation is generally useful where users would expect it, like when filling in a username to see if it still available or a typing a new password to check if it is long and secure enough. If the system is not forgiving and is strict about format types, the user might start to wonder. Also, most users want to complete the form as fast but accurate as possible. If they click Submit and go to the next step, they might be less pleased to see the same form again (with errors communicated) and make the effort of correcting any errors (and waiting for the next step again).

What is inline validation?

Inline, real-time, or instant validation is a error communication strategy in electronic form design. A system responds immediately to an error, constantly validation user input and providing immediate feedback about input errors during filling out a form.

Two variants of inline validation exist:
a) On-the-fly: any error is communicated in real-time or instant, meaning as soon as the user has typed an invalid character in a textfield.
b) OnBlur:  any error is communicated only after a user leaves a field by clicking outside it or clicking another field (a.k.a. loses focus). This is generally preferred method.

The opposite of inline validation is afterwards validation or on-submit (onSubmit) validation. That means that errors are communicated only after the user has clicked the submit button.

Just show me the numbers (or research)

Does inline validation increase conversion? When using inline validation on sign-up and ordering forms, do we really win more confidence from the users or only disturb them in their mental flow while filling the form? What about those green check-marks: do they really make filling in a check-out form more pleasant? Research about inline validation and its advantages for conversion is scarce and contradicting. There are no hard sales figures or proof of increased conversion, because research about inline validation is not conclusive about the link yet between different form types (sign-up form, order form or other) and design (content, error behaviour) in relation with its added value on different types of forms.

Research case A: inline validation didn’t help

One research paper covers ‘usable error messages on the web’ [1] (not confirmed) that afterwards validation is more ‘effective’ than inline validation. I’m not sure what they mean by ‘effective’, but I deduct from the table of contents of the article that they define ‘effective’ by:

  • lower error rates.
  • lower time to complete.
  • higher subjective ratings.

Summarizing their findings:

When users are completing online forms present the errors after the user has completed the form.
–          When completing an online form users have two flows or modes: Completion Mode and Revision Mode.
–          Users tend to ignore immediate error messages when they are in Completion Mode.Of the six possible ways to present error messages, thee proved to be more effective (?) than the others:
o        Present the errors afterward, embedded in the form, all at once.
o        Present the errors afterwards, embedded in the form, one by one.
o        Present the errors afterwards, in dialogues, one by one.Where presented with inline validation, users often simply ignored the messages on the screen and continued completing the form as if nothing happened. These results lead to the postulation of the “Modal Theory of Form Completion“: Users are in either “Completion“ or “Revision Mode“ when filling out online forms. These modes affect the users way of interaction with the system: during Completion Mode the users disposition to correct mistakes is reduced, therefore error messages are often ignored.

Interestingly most users don’t actually look at the inline validation unless they are worried their answers might be wrong. As soon as the user hesitates they look at the form and can see straight away whether their answer is right or not.

Research case B: inline validation helps

On the other hand, an article by Luke L in the article has opposite and positive findings on inline validation:

The inline validation version had:

  • a 22% increase in success rates,
  • a 22% decrease in errors made,
  • a 31% increase in satisfaction rating,
  • a 42% decrease in completion times, and
  • a 47% decrease in the number of eye fixations.

A discussion on summarises:

“His research suggested that:

  • validating data that shouldn’t be validated (e.g. first name, last name) was regarded as weird and confused users.
  • speedy, immediate checking of data that should be validated (e.g. is my choice of username available?) is welcomed by users and helpful
  • attempting to validate data before the user has finished typing is intrusive and disliked by users (a point we explore further in our book: it’s all about interrupting the user’s turn in the conversation). “


Inline validation can either harm or benefit your customer satisfaction and conversion. As every forms differs in content and design, so will each research differ in their findings. Not all design research is universally applicable; we should learn from the context rather than to generalise conclusions.

What does this mean for me?

A/B test inline validation on your site. Be weary about blindly applying something that gave positive conversion results on one site to another site – different sites have different audiences, even with time things may change.  Conversion rate is an important monetary measure, but – just as the case studies above have done – measure other KPI’s as well: usability, customer satisfaction, aesthetic appeal and similar emotional factors should not suffer (too) much as a result of increased conversion. As always, mind the development costs, server load and performance decrease are feasible.

What’s next?

Read my related articles on inline validation:
Pros and cons of inline validation
Design and implementation challenges
When to use inline validation

Preparing for inline validation
Lies, damn lies and A/B tests


[1] Usable error message presentation in the World Wide Web: Do not show errors right away
by Javier A. Bargas-Avilaa, Glenn Oberholzerb, Peter Schmutza, Marco de Vitoa and Klaus Opwisa



Sign-up form examples:
Yahoo! mail sign-up page   (UPDATE: Recently Yahoo has slightly redesigning their form and removed inline validation!) sign-up form
TypePad sign-up form    (Last checked 5/5/11) sign-up   (username onBlur, others onSubmit)    
Eventful sign-up form (use inline hints. Did they get rid of their Javascript alert dialog boxes?)

Order form examples:
Do you know of any e-commerce examples? Let us know.


A short chapter devoted to inline validation in Robert Hoekman Jr ‘s Designing the moment