Child pages
  • Heuristic UX Evaluation of Date Picker

Documentation for a historical release of Infusion: 1.3
Please view the Infusion Documentation site for the latest documentation.
If you're looking for Fluid Project coordination, design, communication, etc, try the Fluid Project Wiki.

Skip to end of metadata
Go to start of metadata

Heuristic UX Evaluation - Gary & Barbara - March 12, 2008

The designs so far look really good.  Fluid Date Picker we compared to the JQuery date picker and some of our suggestions merge parts of that design into this one.  Overall though we felt strongly that the Fluid date picker offered good usability to the user.  We have some comments that hopefully will help in finalizing the designs.


  • Currently only one scenario has a design shown, namely when someone is selecting start and end dates for an assignment.  Since Fluid components can be used in a broad range of contexts potentially, we'd like to see the design wiki page break the designs into a few additional variants for 2 other scenarios in addition to the current one.  So there can be three sections to the wiki page for each scenario and its relevant design.  The sections would be:
    • Just picking a day (no time)
    • Just picking a day and time
    • Picking 2 days and 2 times (current scenario shown)
  • This will help to round out the design overall and show interactions for a wider range of scenarios encountered in Sakai and other LMSs.
  • The date picker offers the user no idea when they select a date if there are any other things going on at that time.  There's no tie into their "calendar".  It could be that the user will accidentally select a day/time when there is something else conflicting.  Some checking "behind the scenes" with their calendar needs to occur when the user selects a date.
  • Ideally down the road, the user should be able to start setting up an assignment from either their calendar by first selecting a date or from the Assignments tool (Sakai).

Suggestions for Current Design

  • Selecting the day either from the calendar or by typing into the entry field seems straight-forward.
  • Biggest user issue is that the person has no idea what else they may have planned for a particular day and if there will be a conflict or not.  The clock graphic, while nice, takes up valuable screen space that could be used to show the person a "Day view" of the selected date.  This way the user could quickly see what else is going on for the selected day.  In cases where the Date Picker is only used to select a Day and Time, this will be very helpful. 
  • Proposed "Day View" could list:
    • Start Time
    • Title
    • Duration 
  • There is no easy way to change the year without typing a new one in the entry field.  One strength of the JQuery design is the "Year" drop-down.
  • The JQuery design also had the controls:  <Prev    Today    Next>.  The Fluid Date picker offers the <Prev and  Next> but not "Today". 
  • The Fluid Date Picker does not offer a quick way to get to "Today" if the user moves ahead/behind in time to other months.  Having a way to quickly get back to "Today" would provide the user with more flexibility in navigation and a greater sense of user control.
  • Clock graphic:  From the Interaction notes provided we were not clear on whether the user would interact with the clock graphic or if it just changed as they entered different times?  Since it is very large we think the space would be better used for a "Day View" of the current selected date.  A smaller clock graphic could then be placed after the AM/PM text.
Related Links

There is no content with the specified labels


  1. 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.

  2. I think from a Fluid component design stand point we want to make the date picker component flexible to be used across different scenarios from setting up assignments to other things.  There does need to be further exploration of the scenarios as well. 

    One thing to add to this wiki page is to show the date picker for scenarios where only one date is selected not an interval.  The interval with 2 dates is also good to show here but showing both design variants would be more complete.