Type or select?

27 Nov 2008 - 9:10am
5 years ago
11 replies
1121 reads
Morten Just
2008

We're asking for the user's birhtday in our profile editor, and are
currently discussing if we should use

a) dropdowns for day, month and year
b) text fields for day, month and year
c) one free text field

The advantages as we see it for b and c are
- the user is in typing mode, and in most cases a dropdown would mean
switching from keyboard to mouse
- text fields resemble natural language more than a dropdown

Disadvantages would be
- higher requirements for form validation
- the user will be able to provoke a (validation) error, and that is just
bad Poka Yoke (http://en.wikipedia.org/wiki/Poka-yoke)

Personally, I see UI heading towards a conversational paradigm that
resembles a real-life situation with all its self-correctingness. That would
call for solution c with proper parsing and validation. I wrote a bit about
that subject here

http://blog.genstart.dk/2008/11/25/what-would-reality-do/

Comments

27 Nov 2008 - 11:32am
Robert Hoekman, Jr.
2005

>
> - the user will be able to provoke a (validation) error, and that is just
> bad Poka Yoke (http://en.wikipedia.org/wiki/Poka-yoke)
>

Errors can happen regardless of which solution you choose and validation
should be written to handle it — what's important is that you do what you
can to guide people towards completing it correctly.

A solution when using input fields is to set default values that tell people
how the date should be formatted (e.g. 10/03/1954). The field should be able
to accept any format, and simply convert it to the format you need via
Javascript or something else before passing it to the database, but showing
an example as a default value helps users determine a format to use. Not
including this means users have to guess, and that lowers confidence. (Note,
though, that the date format is different for different countries, so be
sure to specify whether month or day comes first.)

Another option: use a calendar widget for choosing the birthdate (slow, yes,
but effective), and then have them manually type in the year (include a
default value example).

-r-

27 Nov 2008 - 1:46pm
Fredrik Matheson
2005

Supporting multiple date formats is a great idea and reduces errors.
I'd suggest looking into the flexible date/time picker used in iCal (
http://is.gd/9hPY) which is an array of date/time fields masquerading as one
text field. Arrow up/down lets you step the number up/down and arrow
left/right (and tab/shirt+tab) provides navigation inside the field.

The calendar pattern found Yahoo Pattern Library http://is.gd/9hQp is
perhaps even better suited to this task if the user is not already looking
at a calendar.

I'll be so bold as to suggest that using individual drop-downs for year,
month and day is inflexible and should now be considered an outdated
practice.

- Fredrik

27 Nov 2008 - 9:51pm
Anonymous

Hi Morten,
b

I think typing is much better than selecting because mistakes happens
a lot when users are not very carefully moving the mouse and
selecting.But,when users are typing,they won't make the similer
unconscious mistakes.
Best wishes!

Angela

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36010

30 Nov 2008 - 8:07pm
Caroline Jarrett
2007

Been travelling, so this is my first chance to chip in on this thread.

The essential point is: you're asking users to enter their date of birth.

This is an answer that you can expect most users to have in 'muscle memory'
in their fingertips, at a similar level to typing their street address. And
it's also an answer that many users will have stored in a form-filler
utility such as Google toolbar autofill.

Therefore: let them type it in. Don't require drop downs or calendars or any
other type of fancy widget.

There is a minor issue, which is the problem of date order for
internationalisation. If you can work out the accurate date from the text
typed in, you don't have a problem (any day 13 and above is unambiguous).
Otherwise you're going to have to provide a hint about the order that you
want, and perhaps try to guess as well based on other clues such as address.

The preference for typing in a date without fancy widgets or dropdowns
doesn't necessarily apply to other dates. For example, type-in PLUS calendar
is a good pattern for many dates such as booking flights. Users are often
thinking something like: "Fly out on 15th, return the following Friday" - a
recipe much easier to deal with on a calendar, but you need the type-in
option as well for flexibility and accessibility.

Best
Caroline Jarrett

Out now: "Forms that work: Designing web forms for usability"
http://www.amazon.co.uk/Forms-that-Work-Interactive-Technologies/
dp/1558607102
http://www.amazon.com/Forms-that-Work-Interactive-Technologies/dp/product-de
scription/1558607102

30 Nov 2008 - 8:53pm
Jarod Tang
2007

On Fri, Nov 28, 2008 at 12:32 AM, Robert Hoekman Jr <robert at rhjr.net> wrote:
>>
>> - the user will be able to provoke a (validation) error, and that is just
>> bad Poka Yoke (http://en.wikipedia.org/wiki/Poka-yoke)
>>
>
> Errors can happen regardless of which solution you choose and validation
> should be written to handle it — what's important is that you do what you
> can to guide people towards completing it correctly.
Yup, a good example is some visa form, it give the hints, as
[dd/mm/yyyy], which makes some sense.

Regards,
Jarod

--
http://designforuse.blogspot.com/

1 Dec 2008 - 4:14am
Pietro Desiato
2008

hi all,

I think that the date format could be an issue. I'd rather prefer a
text field for day and year and a dropdown for month (it's also
easier to select the month instead of either writing it or understand
which format has been used). If you feel that the conversational
paradigm is the way to go (as I do), think also about the label you
want to associate to these fields. Maybe (I don't know your
context\users) you can "melt" these input fileds with the label.
Something like "I am born on [month dropdown] [day], [year]. Imho
the calendar is a complex interaction (opening, browsing, selecting,
closing) and I'd avoid it.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36010

2 Mar 2009 - 11:09am
Shaun O'Connell
2009

Hi IXDA'ers,

I was trawling through the archives looking for a suitable discussion topic
to post against, and this one came up.

I was recently inspired by a blog entry concerning calendar-based date/time
pickers<http://blogs.uct.ac.za/blog/lovemores-world/2009/02/25/an-effective-jquery-date-time-picker>to
create a more intuitive date/time picker.
I'm not sure about the rest of you, but some calendar controls frustrate me
as a user. Sometimes I'm forced to use a calendar control because it's
easier than interpreting the format for the single date field.

Anyway, the post got me thinking about a different approach to date/time
pickers, leaning heavily on those old mechanical alarm clocks that had dials
or cogs next to the hour and minute displays. Read more on the idea here:
http://ndorfin.wordpress.com/2009/03/02/rl-date-picker/

Will this idea end up being harder to understand than a fly-out calendar
picker? i.e. Does convention over-rule out-of-the-box UI ideas?

Has anyone had any experience testing up-down-arrow or slider controls in
web-based forms? Could something like my 'tumbler' idea work if the graphic
design is done properly?

I'd love to have some feedback on this idea. Thanks!

Cheers,
Shaun

On Mon, Dec 1, 2008 at 11:14 AM, Pietro Desiato <pietro.desiato at gmail.com>wrote:

> hi all,
>
> I think that the date format could be an issue. I'd rather prefer a
> text field for day and year and a dropdown for month (it's also
> easier to select the month instead of either writing it or understand
> which format has been used). If you feel that the conversational
> paradigm is the way to go (as I do), think also about the label you
> want to associate to these fields. Maybe (I don't know your
> context\users) you can "melt" these input fileds with the label.
> Something like "I am born on [month dropdown] [day], [year]. Imho
> the calendar is a complex interaction (opening, browsing, selecting,
> closing) and I'd avoid it.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=36010
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

2 Mar 2009 - 11:09am
Shaun O'Connell
2009

Hi IXDA'ers,

I was trawling through the archives looking for a suitable discussion topic
to post against, and this one came up.

I was recently inspired by a blog entry concerning calendar-based date/time
pickers<http://blogs.uct.ac.za/blog/lovemores-world/2009/02/25/an-effective-jquery-date-time-picker>to
create a more intuitive date/time picker.
I'm not sure about the rest of you, but some calendar controls frustrate me
as a user. Sometimes I'm forced to use a calendar control because it's
easier than interpreting the format for the single date field.

Anyway, the post got me thinking about a different approach to date/time
pickers, leaning heavily on those old mechanical alarm clocks that had dials
or cogs next to the hour and minute displays. Read more on the idea here:
http://ndorfin.wordpress.com/2009/03/02/rl-date-picker/

Will this idea end up being harder to understand than a fly-out calendar
picker? i.e. Does convention over-rule out-of-the-box UI ideas?

Has anyone had any experience testing up-down-arrow or slider controls in
web-based forms? Could something like my 'tumbler' idea work if the graphic
design is done properly?

I'd love to have some feedback on this idea. Thanks!

Cheers,
Shaun

On Mon, Dec 1, 2008 at 11:14 AM, Pietro Desiato <pietro.desiato at gmail.com>wrote:

> hi all,
>
> I think that the date format could be an issue. I'd rather prefer a
> text field for day and year and a dropdown for month (it's also
> easier to select the month instead of either writing it or understand
> which format has been used). If you feel that the conversational
> paradigm is the way to go (as I do), think also about the label you
> want to associate to these fields. Maybe (I don't know your
> context\users) you can "melt" these input fileds with the label.
> Something like "I am born on [month dropdown] [day], [year]. Imho
> the calendar is a complex interaction (opening, browsing, selecting,
> closing) and I'd avoid it.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=36010
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

3 Mar 2009 - 1:02pm
pyces
2007

<from your site>
Now imagine you need to set your birthdate using the above control.

We could initialise the date with an arbitrary date such as: 1980.06.15.

One of the problems with setting an arbitrary date is that users might
not change it to the appropriate date unless it actually behooves them
(they get some sort of reward for being below or above a certain age),
thus if you are trying to track the age groups of your users, this would
skew your results. Since they won't get an error when they try to submit
the form and if they don't get some type of reward, then why would they
take the time?

Another problem would be that it might make people think that the dates
start at 1980, thus no one older than 27-28 could sign up for whatever
service/product you're offering. This would skew the age group that you
end up with.

In looking at your tumbler, my first thought is what happens when I
click the tumbler? There seems to be no way to go up or down as in a
normal up/down arrow spin button control, so if it starts at 1980, does
clicking it once move is to 1979 or 1981.

Courtney Jordan

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Shaun O'Connell
Sent: Monday, March 02, 2009 11:10 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Type or select?

Hi IXDA'ers,

I was trawling through the archives looking for a suitable discussion
topic
to post against, and this one came up.

I was recently inspired by a blog entry concerning calendar-based
date/time
pickers<http://blogs.uct.ac.za/blog/lovemores-world/2009/02/25/an-effect
ive-jquery-date-time-picker>to
create a more intuitive date/time picker.
I'm not sure about the rest of you, but some calendar controls frustrate
me
as a user. Sometimes I'm forced to use a calendar control because it's
easier than interpreting the format for the single date field.

Anyway, the post got me thinking about a different approach to date/time
pickers, leaning heavily on those old mechanical alarm clocks that had
dials
or cogs next to the hour and minute displays. Read more on the idea
here:
http://ndorfin.wordpress.com/2009/03/02/rl-date-picker/

Will this idea end up being harder to understand than a fly-out calendar
picker? i.e. Does convention over-rule out-of-the-box UI ideas?

Has anyone had any experience testing up-down-arrow or slider controls
in
web-based forms? Could something like my 'tumbler' idea work if the
graphic
design is done properly?

I'd love to have some feedback on this idea. Thanks!

Cheers,
Shaun

On Mon, Dec 1, 2008 at 11:14 AM, Pietro Desiato
<pietro.desiato at gmail.com>wrote:

> hi all,
>
> I think that the date format could be an issue. I'd rather prefer a
> text field for day and year and a dropdown for month (it's also
> easier to select the month instead of either writing it or understand
> which format has been used). If you feel that the conversational
> paradigm is the way to go (as I do), think also about the label you
> want to associate to these fields. Maybe (I don't know your
> context\users) you can "melt" these input fileds with the label.
> Something like "I am born on [month dropdown] [day], [year]. Imho
> the calendar is a complex interaction (opening, browsing, selecting,
> closing) and I'd avoid it.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=36010
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

3 Mar 2009 - 3:25pm
Shaun O'Connell
2009

Hey Courtney, Turi,

Thanks for the responses :)

The idea is that the text field is still a normal text field, it just has an
attached tumbler.
If the user clicks in the text field, it just selects the text in the text
field as normal.

The up/down arrow actions only occur if the field is in focus.

You're right, a real date could allow the user to skip over the date and
proceed as normal - not good. To circumvent this, we could use a fake date,
such as 1980.02.31? If they skip over it, the validation should kick in and
say that it's an invalid date.

Another option would be to use a mask (e.g. CCYY as year). When the user
puts focus on the text-field, the mask disappears. If the user set's focus
to the field and the field is blank, and they subsequently use the tumbler
or press an arrow key, the field jumps to the top number?

Interestingness :)
Ciao,
Shaun

On Tue, Mar 3, 2009 at 8:02 PM, Jordan, Courtney <CJordan at bbandt.com> wrote:

> <from your site>
> Now imagine you need to set your birthdate using the above control.
>
> We could initialise the date with an arbitrary date such as: 1980.06.15.
>
>
> One of the problems with setting an arbitrary date is that users might
> not change it to the appropriate date unless it actually behooves them
> (they get some sort of reward for being below or above a certain age),
> thus if you are trying to track the age groups of your users, this would
> skew your results. Since they won't get an error when they try to submit
> the form and if they don't get some type of reward, then why would they
> take the time?
>
> Another problem would be that it might make people think that the dates
> start at 1980, thus no one older than 27-28 could sign up for whatever
> service/product you're offering. This would skew the age group that you
> end up with.
>
> In looking at your tumbler, my first thought is what happens when I
> click the tumbler? There seems to be no way to go up or down as in a
> normal up/down arrow spin button control, so if it starts at 1980, does
> clicking it once move is to 1979 or 1981.
>
> Courtney Jordan
>

7 Mar 2009 - 12:38am
Abhay Rautela
2008

Applying an input mask to the input field is an elegant solution. Try the
jQuery masked input plugin:
http://www.conetrees.com/2009/03/blog/jquery-masked-input-plugin-increase-usability-for-masked-format-input-fields/
-Abhay

--
Cone Trees- User Research & Design
http://www.conetrees.com
http://www.twitter.com/conetrees
http://www.theuxbookmark.com
http://uxbookclub.org/doku.php?id=new_delhi

On Mon, Mar 2, 2009 at 9:39 PM, Shaun O'Connell <ndorfin at gmail.com> wrote:

> Hi IXDA'ers,
>
> I was trawling through the archives looking for a suitable discussion topic
> to post against, and this one came up.
>
> I was recently inspired by a blog entry concerning calendar-based date/time
> pickers<
> http://blogs.uct.ac.za/blog/lovemores-world/2009/02/25/an-effective-jquery-date-time-picker
> >to
> create a more intuitive date/time picker.
> I'm not sure about the rest of you, but some calendar controls frustrate me
> as a user. Sometimes I'm forced to use a calendar control because it's
> easier than interpreting the format for the single date field.
>
> Anyway, the post got me thinking about a different approach to date/time
> pickers, leaning heavily on those old mechanical alarm clocks that had
> dials
> or cogs next to the hour and minute displays. Read more on the idea here:
> http://ndorfin.wordpress.com/2009/03/02/rl-date-picker/
>
> Will this idea end up being harder to understand than a fly-out calendar
> picker? i.e. Does convention over-rule out-of-the-box UI ideas?
>
> Has anyone had any experience testing up-down-arrow or slider controls in
> web-based forms? Could something like my 'tumbler' idea work if the
> graphic
> design is done properly?
>
> I'd love to have some feedback on this idea. Thanks!
>
> Cheers,
> Shaun
>
> On Mon, Dec 1, 2008 at 11:14 AM, Pietro Desiato <pietro.desiato at
> gmail.com>wrote:
>
> > hi all,
> >
> > I think that the date format could be an issue. I'd rather prefer a
> > text field for day and year and a dropdown for month (it's also
> > easier to select the month instead of either writing it or understand
> > which format has been used). If you feel that the conversational
> > paradigm is the way to go (as I do), think also about the label you
> > want to associate to these fields. Maybe (I don't know your
> > context\users) you can "melt" these input fileds with the label.
> > Something like "I am born on [month dropdown] [day], [year]. Imho
> > the calendar is a complex interaction (opening, browsing, selecting,
> > closing) and I'd avoid it.
> >
> >
> > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> > Posted from the new ixda.org
> > http://www.ixda.org/discuss?post=36010
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > Unsubscribe ................ http://www.ixda.org/unsubscribe
> > List Guidelines ............ http://www.ixda.org/guidelines
> > List Help .................. http://www.ixda.org/help
> >
>
>
> ________________________________________________________________
> Reply to this thread at ixda.org
> http://www.ixda.org/discuss?post=39417
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Syndicate content Get the feed