Heuristic UX evaluation of Date Picker

Knoop, Peter knoop at umich.edu
Thu Mar 13 00:13:01 UTC 2008

I think the design looks quite nice and clean overall.  I know it's a
work in progress, but you might find circulating this to the Sakai lists
too also gets you some useful input.  I also see you've focused here on
the 2-day/2-time scenario, and some of my observations and questions
below pertain perhaps a bit more to other ways a date-picker is used in
Sakai.  (I'll also note that in Assignments in Sakai you are potentially
specifying up to 3 day/time combinations, not just 2: the open date, the
due date, and the close date; though that shouldn't invalidate any of
the observations you've noted in your evaluation.)  If your in-progress
flag on the page means your not ready for the sort of feedback below,
feel free to ignore it for now.


*         The notes in the date-picker widget mock-up seem to suggest
you should not be able to pick dates in the past.  In practice, this
needs to be permitted.  Sakai users find revisionist history to be a
critical feature under certain circumstances.  One common example is
creating a Gradebook item after you've already "started" an activity.  I
would suggest providing the option to choose whether or not past-dates
are allowed, so a coder can select the appropriate behavioral constraint
for their particular context.  I'd also suggest that when past-dates are
permitted, it behave similar to the current practice of warning the user
they have selected a past-date before the information is actually

*         What do you envision the time box and clock dial looking like
when the user has selected a locale with a 24-hour clock, rather than
the 12-hour AM/PM?  Is it a clock dial with 24 tick-marks?  I would
guess you just don't bother with displaying AM/PM next to the time box
for a 24-hour locale?

*         When you are selecting a range of dates, such as "open" and
"due" in the example, it would be nice to see the "open" date indicated
on the "due" date's calendar so you have some visual feedback on the
range your looking at.  Particularly since it looks like the open date's
calendar disappears when you switch to selecting a due date.

*         The clock dial colours seem to overwhelm the rest of the
interface a bit. 

*         Is there room in the design to display the time zone for the
selected date?  It is probably more important in the distance-ed or
project/collaboration site scenarios, which tend to involve users in
different time-zones, than in the on-campus learning environment
scenario.  It often becomes even more important when you're picking
dates near daylight-savings-time boundaries, especially during times
like now when some areas of the world have already switched to daylight
savings time and others have not.  (In fact, in Sakai we currently have
a bug where we display the right time, but the wrong time-zone in the
calendar widget when the date in question is in a different daylight or
non-daylight period then the current date.)

*         There are a lot of suggestions in Sakai's Jira regarding
"calendar widgets" that you might find informative for your design too.
For instance, SAK-12373 (incorporated into SAK-7000), which talks about
preventing a user from selecting a "due" that occurs prior to already
selected "open" date by graying out the relevant dates and/or performing
some data validation.  (Unlike the need for revisionist history cited
above, I haven't seen a request yet for a user to be able to violate
this sort of relative date order enforcement.)

*         I would echo the comments about a way to get to "Today"
quickly and easily.

*         The notion of a "day view" instead of the clock dial or some
other way to view "conflicts" with the date-time your picking is
interesting.  Some Sakai contexts might well benefit from that.  For
other Sakai contexts though, knowing of such conflicts isn't that
important, and users might end up more frustrated with the delay in the
fancier view loading before they can move along.  (I found sites with
pop-up calendars that take awhile to load, but always load, even if I
just want to type in a date, very frustrating to use as they interrupt
my train of thought.)

*         What happens if I were to type an invalid date, such as
2/31/2008, into the box? Or an invalid time, such as 44:00, into the
time box?  Is there any sort of data validation envisioned as focus

*         Is there flexibility in terms of what can be entered in the
date box?  In other words, could I also express 2/15/2008 as 2/15/08 or
2-15-2008, or do I need to stick strictly with what the locale defines
as the appropriate delimiter?

*         I'll also mention one other scenario for your possible
consideration here that is a bit of a thought experiment about other
potential uses of the date-picker.  It is a scenario that Sakai
currently does not support, but is desired.  I might call this the
"relative dates" scenario, where you use something like a date-picker to
specify a pattern relative date-times.  Say you give the same Assignment
each week in ten different lab sections in your class, however, you want
the open date for the assignment in each lab section to be different;
you want each lab sections' version of the assignment to open for a
given lab section at the date-time that specific section meets.
Similarly, you want the due date to be one week later, at the beginning
of each lab section the next week.  You don't want to have to create 10
different assignments in the Assignment tool (or ten different items in
the Gradebook).  You want to create one Assignment, but give it open and
due dates relative to each sections' meeting time, so you might specify
the open/due dates for the first lab meeting of the week, and have the
rest automatically set by some relative date-time offset.  Maybe a
date-picker would be used in some way to specify a relative pattern of
date-times to use for each section in some as yet un-defined interface.
However, you also need to accommodate weeks where some labs don't meet,
perhaps due to holidays, but others do, so you need a interface to help
you manually override your regular pattern by picking a new date-time
for a specific thing.




From: fluid-work-bounces at fluidproject.org
[mailto:fluid-work-bounces at fluidproject.org] On Behalf Of Barbara Glover
Sent: Wednesday, March 12, 2008 3:18 PM
To: Gary Thompson; Daphne Ogle; Allison Bloodworth; erin yu; Shaw-Han
Cc: fluid-work at fluidproject.org
Subject: Heuristic UX evaluation of Date Picker


Hi all

Gary and I did a heuristic walk through of Erin's excellent date picker
designs.  Our comments are found at this link.  Gary feel free to add
comments I forgot.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080312/43cdd217/attachment.html>

More information about the fluid-work mailing list