Heuristic UX evaluation of Date Picker

[Barbara Glover]

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