Heuristic UX evaluation of Date Picker

Fri Mar 21 01:12:08 UTC 2008

Hi all,

I'm just getting through this thread--thanks to everyone for their  
hard work on this and their comments! :)

I led the development of a campus event calendaring application a few  
years ago so I've had some exposure to some date pickers (though not  
a combined date and time picker) and would love to get more involved  
with this work in the future. :)

Since many of us on Fluid are focused on the 0.3 release (and this  
component is *not* part of it) I'm guessing we won't be addressing a  
lot of these comments right now, but I'll add a few suggestions for  
future work:

* One thing that is almost always a part of my design process is to  
do a Competitive Analysis (even if it's just a brief collection of  
screenshots and a few pluses & minuses of each) of what is out there  
now. This helps ensure our designs follow any conventions that are  
out there now (e.g. the 'consistency and standards' heuristic) and of  
course also gives us design ideas.  I think it's probably important  
to do this explicitly in our community environment where we often  
don't get to talk with each other about our designs in person. So as  
a start on this I created a Date Picker Competitive Analysis page:  
http://wiki.fluidproject.org/display/fluid/Date+Picker+Competitive 
+Analysis, and I'd love to see Erin (or anyone else! :)) add to it to  
give us an idea of what examples informed the initial design.

* I think it's also important to provide a design rationale which  
ties the design decisions back to the requirements and use cases  
(including why we aren't addressing particular use cases &  
requirements now), so that would also be an important addition to the  
main Date Picker page: http://wiki.fluidproject.org/display/fluid/Date 
+Picker+Widget.

* Though it is certainly pretty, from an information standpoint It  
seems to me that the clock doesn't add much to the textual  
representation of the date (I did just realize that yellow is AM and  
blue is PM, but again that is expressed above). Are you supposed to  
be able to move the hands on the clock somehow or set the time by  
clicking on the clock? The clock also takes up a lot of screen real  
estate (which may be covering up something underneath the picker that  
the user may want to see), so I'm wondering what the rationale is for  
including it? Though I'm not sure at this point what to suggest as a  
design solution, I've heard some other suggestions for using this  
space differently (e.g. timezones, relative dates) on this thread,  
but would advocate in the interest of simplicity and space-saving  
that we make the picker only large enough to convey the information  
we believe the majority of our users need. Perhaps the datepicker  
could also be configurable to only convey extra information (e.g.  
timezones) when it's needed in specific contexts? Additionally it  
might be nice to be able to specify whether it opens in the  
"expanded" or "contracted" state--or we should do some thinking on  
what the default should be. Some user testing would likely give us  
some good insight as to whether users prefer to type in dates (in the  
"contracted" state) or interact with the calendar (in the "expanded"  
state). I do have a hypothesis that in most contexts (e.g. unless  
they weren't changing the date very often, or needed to see  
information underneath the picker) users would prefer to click on the  
calendar to enter a date rather than type it in (which argues for an  
"expanded" default).

* I don't see how to change a time from AM to PM or vice versa.

* I'm guessing it will be important (or at least helpful) to allow  
users to jump not only to the next month, but to jump a year ahead as  
most date pickers allow. Either a ">>" or a year drop-down (as Aaron  
pointed out) could be a way to do this.

* I agree with Aaron that it's important to be able to jump to  
"today" in case the user gets lost or quickly needs to 'reset' the  
picker.

* I agree with Peter that quick loading is going to be *highly*  
important. We've heard a lot about frustrations with things loading  
slowly in Sakai in the Contextual Inquiries.

* I'm guessing we also need a version of this picker which:
   ** is a date *only* picker, but doesn't use time
   ** picks only one date/time at a time, instead of having both an  
open and close date as shown in the designs
   ** allows the user picks a date and time range (e.g. for a multi- 
day 'event'), perhaps representing it visually on the calendar

Thanks again Erin & Antranig for all your hard work on this!
Allison

On Mar 13, 2008, at 8:36 AM, Knoop, Peter wrote:

>> -----Original Message-----
>> From: John Norman [mailto:john at caret.cam.ac.uk]
>> Sent: Thursday, March 13, 2008 8:36 AM
>> To: Knoop, Peter
>> Cc: Barbara Glover; Gary Thompson; Daphne Ogle; Allison Bloodworth;
>> erin yu; Shaw-Han Liem; fluid-work at fluidproject.org
>> Subject: Re: Heuristic UX evaluation of Date Picker
>>
>>
>> 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.)
>>>
>> Norman, John wrote:
>>
>> 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.
>
> Right, but since some of the logic is likely to work best if  
> accompanied
> by visual cues and when supported by specific interaction  
> behaviors, it
> seems like it needs to get considered in the design process at some
> point.  In addition, even if it not everything to goes into the
> component itself, it's important to avoid putting things into it that
> prevent desired behavior down the road, such as being able to pick  
> dates
> in the past.  (Maybe I'm getting ahead of things though, and the  
> design
> process still has a way to go before its at that point?)
>
> -peter
>
>

Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080320/396f9404/attachment.html>