CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mary Utt <[log in to unmask]>
Reply To:
Date:
Mon, 13 May 2002 07:58:35 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (83 lines)
Apologies for being so long in compiling a summary, and thanks to everyone
who replied with suggestions and observations.  Unfortunately, no studies
seem to have been done in this area.

I was interested to see that another person had observed users stopping cold
when entering dates and times. (I observed this again last week when walking
through our product with a new hire.)  One suggestion was to supply
plausible examples in date/time fields: we do that, and users still stop
cold. I am continually amazed at what people do not see/read/grok on web
pages! (Yeah, sometimes the UI is at fault.)

On to the suggestions:

Date pickers: Several replies suggested "date pickers" as unambiguous
calendar representations.Our product can do this and users like it. (Yes, it
is possible, though painful, on Netscape. Everything is painful on
Netscape.) However, every year at Christmas a friend in the UK sends me a
lovely calendar...with weeks beginning on Monday: US calendars begin weeks
on Sunday. Not to mention that in the UK people talk about "diaries" where
we say "calendar" in the US. So there is an I18N issue here. In addition,
web date pickers rely on Javascript (or Java or something), which raises
accessibility issues. But I will offer a date picker in addition to an
accessible method; a user preference can determine whether weeks start on
Sunday or Monday. Which brings me to the next suggestion:

Multiple ways of entering the data: one reply suggested combining multiple
ways of entering the data (text fields *and* select boxes, for example).

Text fields: A single text field is problematic in that you need to know
that the user means May 1 and not Jan 5 when 5/1 is entered. This can be
gotten around if the user has selected a date preference. But the single
(free-form) text field seems to be generally confusing: it's not good when
users are "stopped cold" (unless that's the goal, of course).

But the date fields could be presented as separate fields, labeled "day,"
"month," "year." It's possible (again) to order them by user preference, and
to accept either a month name ("May") or number ("5") in the month field.

Select boxes: one reply was definitely on the side of select boxes with
interaction among the boxes such that users cannot select, e.g., 31 Feb. One
reply was strongly against them.

So I'm leaning toward using separate day, month, year text fields, with
"date pickers" as another means of specifying dates. With a good example.
Times are less ambiguous (hours:minutes) and can also be text fields,
separated by a colon (and in 12- or 24-hour format as the user prefers).

One reply noted that the Islamic calendar should also be presented for true
internationalization. Interesting point. Possibly relevant for our product:
need data. Not this release.


Original query:
I work on a web application that includes a calendar and a couple of other
instances where the user enters date and/or time information on a web form.

Our application also has requirements for accessibility and
internationalizability (is that a word? :-) that need to be taken into
account.

I am inclined to use select boxes for hours, minutes (:00, :15, :30, :45),
day, month, year. I have seen recommendations to use text boxes for these
data, allowing users to type the information in whatever format they
normally use. Our application actually can do this for dates, but my
observation of users is that they are confused by a text box: they stop cold
and usually mutter something about "what format..." Even though an example
is provided in the box itself! Then, most users slavishly copy the example,
whether or not this is a format they normally use.

So, while a text box is fewer clicks than a select box, the net result seems
to be more time and trouble using the text box. A select box has the virtue
of being much clearer, more clicks nothwithstanding.

I am wondering if there are any studies/literature/guidelines for
representing this information? In an accessible, localizable way.

    --------------------------------------------------------------
    Tip of the Day: Use the archives to research common questions
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------

ATOM RSS1 RSS2