I think the design looks quite nice and clean overall. I know it's a work in progress, but you might find circulating this to the Sakai lists too also gets you some useful input. I also see you've focused here on the 2-day/2-time scenario, and some of my observations and questions below pertain perhaps a bit more to other ways a date-picker is used in Sakai. (I'll also note that in Assignments in Sakai you are potentially specifying up to 3 day/time combinations, not just 2: the open date, the due date, and the close date; though that shouldn't invalidate any of the observations you've noted in your evaluation.) If your in-progress flag on the page means your not ready for the sort of feedback below, feel free to ignore it for now.
* The notes in the date-picker widget mock-up seem to suggest you should not be able to pick dates in the past. In practice, this needs to be permitted. Sakai users find revisionist history to be a critical feature under certain circumstances. One common example is creating a Gradebook item after you've already "started" an activity. I would suggest providing the option to choose whether or not past-dates are allowed, so a coder can select the appropriate behavioral constraint for their particular context. I'd also suggest that when past-dates are permitted, it behave similar to the current practice of warning the user they have selected a past-date before the information is actually accepted. * What do you envision the time box and clock dial looking like when the user has selected a locale with a 24-hour clock, rather than the 12-hour AM/PM? Is it a clock dial with 24 tick-marks? I would guess you just don't bother with displaying AM/PM next to the time box for a 24-hour locale? * When you are selecting a range of dates, such as "open" and "due" in the example, it would be nice to see the "open" date indicated on the "due" date's calendar so you have some visual feedback on the range your looking at. Particularly since it looks like the open date's calendar disappears when you switch to selecting a due date. * The clock dial colours seem to overwhelm the rest of the interface a bit. * Is there room in the design to display the time zone for the selected date? It is probably more important in the distance-ed or project/collaboration site scenarios, which tend to involve users in different time-zones, than in the on-campus learning environment scenario. It often becomes even more important when you're picking dates near daylight-savings-time boundaries, especially during times like now when some areas of the world have already switched to daylight savings time and others have not. (In fact, in Sakai we currently have a bug where we display the right time, but the wrong time-zone in the calendar widget when the date in question is in a different daylight or non-daylight period then the current date.) * 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 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.) * What happens if I were to type an invalid date, such as 2/31/2008, into the box? Or an invalid time, such as 44:00, into the time box? Is there any sort of data validation envisioned as focus changes? * Is there flexibility in terms of what can be entered in the date box? In other words, could I also express 2/15/2008 as 2/15/08 or 2-15-2008, or do I need to stick strictly with what the locale defines as the appropriate delimiter? * 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. -peter From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barbara Glover Sent: Wednesday, March 12, 2008 3:18 PM To: Gary Thompson; Daphne Ogle; Allison Bloodworth; erin yu; Shaw-Han Liem Cc: [email protected] Subject: Heuristic UX evaluation of Date Picker Hi all Gary and I did a heuristic walk through of Erin's excellent date picker designs. Our comments are found at this link. Gary feel free to add comments I forgot. http://wiki.fluidproject.org/display/fluid/Heuristic+UX+Evaluation+of+Da te+Picker cheers Barbara
_______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
