Heuristic UX evaluation of Date Picker

Daphne Ogle daphne at media.berkeley.edu
Thu Mar 13 19:06:53 UTC 2008

This conversation brings to light how complex it is to build a  
seemingly small widget that we want to work well in many different  

I also think it is a good reminder of how important it is to be very  
clear about the design and functional goals along with the primary and  
secondary scenarios -- which means much analysis needs to go into  
identifying and understanding these scenarios in order to understand  
what is reusable and what should be configurable.  Without this  
understanding we run the risk of feature creep and the challenge of  
"making it work for everything means it works for nothing".  I think  
we'll need to include the various patterns of use (many described in  
this thread) and suggested behaviors in the design pattern -- even  
those that aren't  implemented in the widget itself (but would be an  
add-on or configuration).  *Patterns of use* is the key phrase as  
there is also danger in trying to define so much in the patterns that  
they become difficult to parse.

I suggest we start with creating a list of various locations of date  
picker widgets and their primary scenarios for Fluid's primary apps as  
a starting point.  From there we can start to see patterns of usage  
and abstract the common function/behavior.  Can we add this to the  
list of tasks for the date widget?

Although I created a list of some more complex scenarios for the  
pager, it wasn't comprehensive so perhaps we should do the same for it?


On Mar 13, 2008, at 8:30 AM, Moore, Kathleen E wrote:

> I certainly hope that the date-picker will live in places besides the
> Sakai Assignments tool. Date-pickers appear in many Sakai tools and
> probably in other software that's on our list (Moodle? Kuali?)
> When a group working on the Sakai Resource tool added the ability to
> schedule resource availability, we wanted something like this but  
> never
> finished building it in a way that worked with Velocity, an issue at  
> the
> time.
> It would be great to have one easy-to-use, location-sensitive
> date-picker throughout Sakai and perhaps other open-source ed packages
> as well.
> Kathy
> Kathleen Moore
> Web Manager, Information Technology Services
> Boston University School of Management
> kemoore at bu.edu
> 617-353-2685
> -----Original Message-----
> From: fluid-work-bounces at fluidproject.org
> [mailto:fluid-work-bounces at fluidproject.org] On Behalf Of Barbara  
> Glover
> Sent: Thursday, March 13, 2008 11:09 AM
> To: John Norman
> Cc: fluid-work at fluidproject.org
> Subject: Re: Heuristic UX evaluation of Date Picker
> I think John that your points raise some good questions in what user
> scenarios are we envisioning for the date picker.
> - Will the date picker only live in the Sakai assignments tool?
> - Should we be looking at a broader scope of user scenarios? (which
> is what Gary and I were thinking when we did our heuristic  
> evaluation).
> - As a Fluid component, we may want to make the date picker more
> flexible in that it can sync with calendaring to check for other
> events on a given day because this would increase its ability to be
> used in different user scenarios?
> - Perhaps we want a phased approach to the date picker design where
> the current design doesn't sync with a calendar but down the road add
> in that functionality?
> For a small component I think there are still a lot of user scenario
> questions we need to consider before we finalize the design.  This
> heuristic evaluation is just a step towards bringing these questions
> to for forefront.
> Barbara
> On 13-Mar-08, at 8:35 AM, John Norman wrote:
>> 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 principle...
>> John
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308

More information about the fluid-work mailing list