Date Picker Wheels - When to validate?

Question

This is a fairly simple question but may have wider-reaching answers: when is it appropriate to validate entry in a wheel-based date picker (such as the iOS standard ones)?

Since there are three wheels for day, month, and year, and since a user could enter those three pieces of information in any order, there's no real way to ascertain when they're finished. Also, the three fields must have a default state, which we set to today's date.

We currently validate on the "value changed" event of the picker. So, the default state of the picker as they see it may be 31/12/2014, the user may scroll the day field first, and at that point it assesses, say, 10/12/2014, which is not allowed (as the user must be over 13 years old).

The basic issue is that we can't tell when the user has completed their entry, since they could enter day, month, then year, or year, month, then day, or perhaps the month was correct already and they didn't need to touch it, etc.

So, when would the user expect the validation (and any subsequent error message) to occur, and when is it safest to check the status of the picker?

Answer 1

Ballistics

A concept some term ballistics provides a good guide for this. It asserts that:

A system should not interrupt a user while performing a task, until the latest point possible or necessary.

The idea is that users formulate an action plan for a task (or subtask) and any interruption that is not essential diverges users from their original plan (which is held in the working memory).

Partial entries

The concept of ballistics is often demonstrate with clustered elements made of partials. Forms are a classic example for this (with the form field being partials), and so are dates - with the day, month and year being the partials.

Date entries

Ballistics is easy to understand in the case of date entries - a date, as far as mental models go, is made of a day, month and year. The wheels you see on some date pickers serve as interactive design solution, with various benefits attached; but they are design artefacts. You can argue that the user has not finished entering a date until all the fields are reviewed (not necessarily interacted with).

For this, some event has to signify 'I'm done entering the date'. Most commonly, this is done by either the user clicking Done, or outside the picker area (where the rest of the form might be).

And this is, in most cases at least, the right place to validate things.

Invalid dates and leap years

Another thing to consider here is that some dates can only be verified as invalid once the year has been chosen:

• There is never 30th or 31st for February.
• But there can be 29th in a leap year.

Forms

Things are slightly more complicated with forms. Depending on the nature of a form, users may or may not perform post-completion review. If they do (or likely to), then the correct validation trigger should be the Save button. If they don't, then on-blur (leaving the field) validation could be justified, although some argue that even without post-completion review, ballistics has it that you should not validate until the form is submitted - the users has clear intention in mind and any validation will distract from the task being performed.

Answer 2

I have zero experience of iOS listener events (if that is what they are called). This is the way I would deal with this (if I have understood the context properly). So your application requires the user to be above a certain age. Say 13, you would expect the user to enter in the year field a value equal to or less than 2002. If this is your goal showing default value as today's date isn't a wise option, you see.

If you can you should trim down the values you show to the user in the year selection field {1915(100 years of age or maximum you expect), 1916, .. 2002(13 years of age)}, its better to not allow the user to select bad data rather than have them select one and show an error.

Answer 3

The safest (and simplest) time to check the wheel is when the user completes the form. You can also check if the spinner has been blurred (e.g. the user moves on from the selection) to give the user a more responsive experience. Both these methods ensure the user has completed the input.

In response to your comment, I mean you should determine that the user has finished by checking if they submitted the spinner, not the entire form. This can easily be done with some sort of onblur event.

Answer 4

When the user has moved on to the next field. In other words, when the user have completed the date field and moved on to the next field eg; address. This way, you would be sure that the user has decided on his selection.

Answer 5

You could explicitly place a button named "Done". So whenever user is done with his date selection then user will tap on done button. On action of done button you could check the validation part and show a alert with respect to your check.