Heuristic UX evaluation of Date Picker

John Norman john at caret.cam.ac.uk
Thu Mar 13 12:35:52 UTC 2008

On 13 Mar 2008, at 00:13, Knoop, Peter wrote:
> ...
> ·         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 think we want to be careful about what event-related logic belongs  
in the event setup page that contains a date picker and the date  
picker itself. The picker may become overloaded and difficult to  
reuse if we put too much logic in it.
> ·         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.)
I posted a comment on the wiki page for this: I'm not sure I agree  
with the comments about looking for conflicts in a [personal]  
calendar. I feel this would only apply if you were picking dates for  
an event in the personal calendar and in this case the page in which  
you are creating the event can handle event conflicts. For an  
assignment setup, you would presumably need to look in the site  
schedule tool for conflicts, but will it always be the same calendar  
that contains the potential conflicts. This seems to me like a nice  
idea that is fraught with implementation difficulties. I would  
suggest we might want to develop the use-case scenarios a bit more  
before trying to implement it.
> ...
> ·         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.
Again I see this as logic that belongs in the event setup page.  
However, the ability for the date picker to open with some date  
selections passed into it from the event setup page seems valuable in  


More information about the fluid-work mailing list