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:[EMAIL PROTECTED]
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; [email protected]
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
[EMAIL PROTECTED]
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
