Feedback requested on Fluid's Date-Time Picker

Allison Bloodworth abloodworth at berkeley.edu
Tue Jan 6 19:47:50 UTC 2009


Thanks very much Clay, John and Peter for your suggestions!

Before commenting on them, we thought it may be helpful to explain a  
bit about our design rationale to help folks understand why we've made  
the decisions we have so far. We started by creating design goals (http://wiki.fluidproject.org/display/fluid/Date+Picker+Design+Goals 
) which have helped us in terms of prioritizing different  
requirements. As we've worked on the time picker, we've also made  
design decisions based on these additional assumptions:

the date-time picker should be internationalizable, meaning we must  
handle the 24-hour clock
the date-time picker must be able to handle a combined date-time field  
(Sakai requirement, e.g. see Mneme & Test Center)
some people who would prefer to use ONLY the mouse to select the time,  
especially if they've just used the mouse to pick the date
it is inefficient to use both the mouse AND the keyboard to select a  
time--we'd like to facilitate using just one of those input modes (the  
user can choose which one). So whenever possible, we'd like to handle  
mouse-based interactions with the mouse only, and not require  
switching from the mouse to the keyboard.
there are a number of scenarios where times will not fall on the hour  
(e.g. see Peter's email), so we'd like to make a reasonable number of  
minute options available

Clay, your dodecagon (had to look that one up! :)) is definitely an  
interesting idea! The shape really helps to pinpoint where on the dial  
someone would click for each hour. We've considered several versions  
of a related clock-like format, but we'd like to include the ability  
to select minutes using the mouse and found a clock difficult to  
manipulate/use to make a selection of minutes (e.g. see http://www.nogray.com/time_picker.php) 
  or even of hours if it's a 24-hour clock. We do have some ideas on  
how to make the section the currently active section (e.g. "Hour")  
jump out more so stay tuned for some new designs for that.

John, very good point about the mobile devices! At this point to  
maximize our efforts we've been trying to design one component that  
would work on multiple platforms. Perhaps allowing our components to  
be extended so that there is a different presentation based on the  
device is something we should consider, but we have not done that  
here. Your idea about allowing users to press harder for minutes to  
scroll quickly and softer for slower scrolling is certainly  
interesting, but we fear might be difficult for people with mobility  
issues to manipulate, or even for the average user. Google Calendar's  
time picker drop-down was one of our favorites as well, although it  
requires scrolling rather than a few quick clicks. We had some designs  
inspired by Google's & Upcoming's time pickers, but ended up not going  
with them because we didn't think we were providing enough granularity  
for the minutes.

John & Peter, thanks very much for pointing out that it would be  
helpful to customize which minutes are displayed. We have added this  
to the requirements and will put together wireframes for 2 additional  
increments of minutes -- a 15 minute increment with 4 options, and a  
10 minute increment with 6 options. With fewer options, this would  
also emphasize the "Hour" section more, which Clay suggests.

It wouldn't be hard to replace *both* hours and minutes with a single  
list of frequently-used times (such as the ones Peter points out  
below). Although that would sacrifice flexibility (would it make sense  
for organizations using both course and project sites?), used in the  
right situations it sounds like it *could* help certain users quite a  
bit. We're considering whether we should add the ability to make that  
type of customization in the future--let us know if this seems like an  
important customization for your organization.

Thanks again for all your comments, and please do let us know if you  
have other ideas!
Allison & Erin

On Jan 5, 2009, at 11:47 AM, Knoop, Peter wrote:

> I think this is the last message in this thread, so I’ll re-insert  
> one other Sakai requirement that’s come up before and is related to  
> these sorts of suggestions.  It might help inform the comments  
> around what choices need to be presented and how many.  In the  
> teaching and learning related use cases for Sakai the time  
> boundaries and intervals are often tied to an organization’s class  
> schedule.   For instance, assignment, announcement, resource show/ 
> hide, etc. date and times are often aligned with when a class starts  
> or ends.  At some institutions, these boundaries match well with the  
> typical hour (or 30 minute) clock intervals.  At other institutions,  
> such boundaries appear to be at “odd” times, such as classes  
> starting every 55 minutes, so assignments might be due at 8:00,  
> 9:55, 10:50, 11:45, 12:40, 1:35, 2:25, etc.; however, these times  
> are well-known to the students and instructors at that institution.   
> So for picking – rather than typing – of “common” times, it would be  
> nice – at least in the Sakai implementation of this UX – to let the  
> institution have control over what is presented for these choices.   
> Some institutions might, therefore, be able to present a simple  
> choice of common times (every 30 minutes for instance).  Others will  
> have need for more choices (every 5 minutes for instance), Or, maybe  
> you present time choices that include both the hour and minute to  
> reduce the number of combinations for these “odd” time boundary  
> institutions, i.e. letting them pick from a list of times such as  
> the ones in the 55 minute example above, rather than having them  
> pick the hours and minutes separately.
>
> -peter
>
> From: John Norman [mailto:john at caret.cam.ac.uk]
> Sent: Tuesday, December 30, 2008 10:23 AM
> To: Clay Fenlason
> Cc: Sakai UX; Fluid Mailing List
> Subject: Re: Feedback requested on Fluid's Date-Time Picker
>
> Well, it's my Christmas break so why can't I play too. When I see
> Clay's picture, I think immediately of resetting the clock on my
> microwave or oven after a powercut (it defaults to 12:00 midday) and I
> wonder how hard it would be to implement the press-and-hold-for-fast-
> forward model. So Clay's time display block below could have a plus
> above a minus at each side of the time. To the left of the hour
> controls the hour, to the right of the minutes controls the minutes. A
> single click increments one unit. Click an hold for more than say 2s
> starts the clock ticking up in slow steps, holding longer causes the
> steps to speed up, releasing gives you the units on the display at
> release time and resets the timer so the next click (plus or minus) is
> a unit adjustment, etc. click and type inside the block overwrites the
> time.
>
> The interesting thing is that in almost any scenario where you can
> type (I can't type on my oven, and it is awkward on my iPhone), a
> precision entry (e.g. 3:42pm) seems easiest by typing. This makes me
> think that we may only want to offer "quick-click" time entries for
> hours and halves, or at most, quarters of the hour. I can even imagine
> that for most scenarios, picking date and having that mean 12:00
> midday with overtyping the time to change it may be the most efficient
> interface. Personally, I would go for the Google Calendar pop up to
> set a time away from the default time (with the default time
> configurable somewhere).
>
> I think the date picker stuff is all good.
>
> Or did I just make a false assumption. Are we designing for mobile
> phones/devices too? If so, can it be an interface that detects the
> display platform and behaves accordingly..? Sorry if this is all
> explained in the detail pages and I have been too lazy in going
> straight for the wireframes. If we are looking at mobile devices, I
> would revisit my suggestion at the beginning. Now I think of it, it is
> how my alarm clock works too.
>
> John
>
> On 28 Dec 2008, at 17:46, Clay Fenlason wrote:
>
> > A line of thinking in which I have the temerity to fiddle in
> > Photoshop: I'll retrace it if only to fill in some color around the
> > edges.
> >
> > I begin with the general observation that in a majority of Sakai
> > contexts - setting due dates for assignments, etc. - coarse-grained
> > settings suffice. Tests and Quizzes would be an exception, but it is
> > relatively unusual for the user to want to set the minutes very
> > precisely. So a picker whose presentation telescoped with desired
> > granularity (whose initial scoping would be configured by a UI
> > developer in context) would be helpful. So far you have the two
> > implicit layers of date and time, but I'd suggest that even in a
> > majority of cases where users do set the time, they most often don't
> > care to set more than the hour, for simplicity's sake.
> >
> > Returning now to the hour/minute tab, I think part of the difficulty
> > with the time picker is in trying to crowd both hours and minutes  
> into
> > the same presentation - a jumble of numbers is the result. If it is
> > indeed true that minutes are less often of interest, then there  
> might
> > be some advantage in separating out hour and minute picking further,
> > however subtly. Again, it seems to me a central issue for the
> > time-picking design to somehow focus attention on only the values of
> > interest, and have the others recede into the background - that's
> > where the number grid feels especially weak; the bulk of the screen
> > real estate is "wasted" to the extent that you have to work your way
> > through a lot that you *don't* want.
> >
> > You'll have to forgive me if I drag back into view things you all  
> have
> > already given close consideration, which I feel I'm bound to do,  
> but I
> > remember an earlier design that Erin had mocked up, using clock-like
> > dials. At some point I'm sure that was dropped for good reason, but
> > I'm tempted to revisit the concept in light of what I've suggested
> > above. If we can make it tabbable, and "focus" on either only  
> minutes
> > or hours at once, it might serve.
> >
> > I imagine a dial like the amateurish graphic attached, where a  
> segment
> > of a 12-sided figure can be highlighted, and the numeric value
> > dominating the face shows the full time, but when the hour field  
> is in
> > focus the selection on the dial (whose segments could also be tabbed
> > through) correspond, and when focus shifts to the minutes that outer
> > dial would also.
> >
> > So, there, I've overstepped my bounds and talents considerably, and
> > there are a lot of things I'm leaving out (no attempt to handle a
> > 24-hour clock, obviously), but while the design may be shoddy, the
> > thinking behind it may shine a different light on a few of the  
> issues.
> >
> > ~Clay
> >
> > On Wed, Dec 24, 2008 at 5:30 PM, Allison Bloodworth
> > <abloodworth at berkeley.edu> wrote:
> >> Hi Clay,
> >> Thanks much for your feedback! I've put my comments inline below.
> >> Allison
> >> On Dec 22, 2008, at 4:36 PM, Clay Fenlason wrote:
> >>
> >> There is much to admire here.
> >>
> >> The date picker seems to me fairly sound, but the time picker
> >> wireframes shown here - http://wiki.fluidproject.org/x/_4hI - I  
> find
> >> problematic.
> >>
> >> The grid of numbers for option #1, increasing left-to- right and  
> then
> >> top-to-bottom, feels like an odd contrivance that I don't associate
> >> with time in any other context, in software or otherwise. It's not
> >> immediately clear what the grid of numbers is supposed to  
> represent,
> >> and if I didn't come into these pages already thinking "time  
> picker"
> >> it might have taken a few more seconds to realize what I was  
> looking
> >> at.
> >>
> >> I've added headers for "Hour" and "Minutes" in the tabbed Time
> >> Picker (we'd
> >> already included them in the 24-hour version), which I hope will
> >> help make
> >> this clearer. We were trying to keep the date and time picker the
> >> same shape
> >> to preserve the "tab" metaphor, and we thought this was the best
> >> way to
> >> arrange the numbers to accomplish that. We've also talked about
> >> whether the
> >> numbers should ascend vertically or horizontally (while staying in
> >> the same
> >> shape) and the horizontal arrangement seemed to make the most sense
> >> for a
> >> number of reasons, such as the fact that is the way the calendar
> >> arranges
> >> its numbers. I've attached an old screenshot of what it looked like
> >> before
> >> with the numbers going the other way--if this seems to work better
> >> for some
> >> reason let us know.
> >>
> >> Perhaps it matters how I *came* to the picker in the first place?
> >> How would that introductory wireframe look?
> >>
> >> Good point! This would be much easier to see in a storyboard. As I
> >> needed to
> >> create one for user testing, I got a start on one today:
> >> http://wiki.fluidproject.org/display/fluid/Date+Picker+Storyboard+-+Selecting+Opening+Date+and+Time+-+Tabbed+Timepicker
> >> .
> >> Keep in mind that this storyboard is somewhat experimental at this
> >> point and
> >> may be modified as I'm not positive the tabs should appear when
> >> dealing with
> >> separate date & time fields. In the two separate fields scenario it
> >> is also
> >> possible to use completely separate date and time pickers (e.g.
> >> either the
> >> rolling time picker or the tabbed time picker without the tabs--
> >> realizing we
> >> need a new name for that!) of your choice as is done
> >> here: http://wiki.fluidproject.org/display/fluid/Date+Picker+Storyboard+-+Selecting+Opening+Date+and+Time
> >> .
> >> I think tabbed Date-Time picker works best with a combined date-
> >> time field
> >> (e.g. in Mneme,
> >> see http://wiki.fluidproject.org/display/fluid/Date+Picker+Contexts+of+Use)
> >> . We
> >> think the tabbed version would "flow" better than two separate and
> >> differently shaped pickers would when moving through date and time
> >> in a
> >> single field (it wouldn't even move as the user moves through the
> >> field--just the tabs would change), and will work on the combined
> >> date-time
> >> field storyboard to illustrate this next.
> >> Since Sakai is a context that seems to require a combined date-time
> >> picker
> >> and we want to avoid multiple date-time pickers there, we are
> >> thinking the
> >> tabbed version may be best there. It can be a date picker only, a
> >> time
> >> picker only, or a combined date-time picker and still be  
> consistent.
> >>
> >> The rolling time picker I have no such difficulty of recognition.
> >> It's like a combination lock or analog dials on old alarm clocks,  
> and
> >> I recognize immediately that the relevant numbers should line up.
> >> The
> >> visible sliding into place provides some satisfaction - I can  
> almost
> >> hear an audible "click."
> >>
> >> But when you combine the two, option #2 drops away. Is there no  
> good
> >> way to combine the rolling time picker with the date picker?
> >>
> >> We have thought long and hard about this, but have not come up with
> >> a good
> >> way to combine them to handle a single date-time field--especially
> >> the small
> >> fields in Mneme. (Any ideas are welcome!) On click we could  
> consider
> >> expanding the date-time field from a single into multiple fields in
> >> a Google
> >> calendar-like manner
> >> (see http://wiki.fluidproject.org/display/fluid/Date+Picker+Competitive+Analysis)
> >> using
> >> some sort of overlay, but that might obscure important related
> >> dates around
> >> it. We've also been told there may be some technical issues with
> >> making sure
> >> the rolling time picker is placed right around the text field which
> >> would
> >> probably further complicate the process of combining them.
> >> If the tabbed time picker does well in user testing, I'm guessing
> >> we will
> >> move forward with that component (first). Though there were some
> >> problems in
> >> our initial user test (on paper) of the rolling time picker, we
> >> plan to
> >> pursue further testing of it using an interactive prototype and to
> >> determine
> >> whether we want to move forward with that as a (most likely)  
> separate
> >> component (e.g. a time picker only).
> >>
> >>
> >> ~Clay
> >>
> >>
> >> On Fri, Dec 19, 2008 at 5:48 PM, Allison Bloodworth
> >> <abloodworth at berkeley.edu> wrote:
> >>
> >> Hello Sakai community!
> >>
> >> At the Fluid Project (http://wiki.fluidproject.org) one of our main
> >>
> >> activities is designing and developing usable and accessible user
> >> interface
> >>
> >> components for you to integrate into your applications.
> >>
> >> We hope that the Date-Time Picker we are currently working on could
> >> be used
> >>
> >> in many of your applications and would love any feedback you could
> >> give us
> >>
> >> on it. See the email below for more info, and free to contact Erin
> >> or me (or
> >>
> >> the fluid-work mailing list, in cc:) with any questions. The Date
> >> Picker
> >>
> >> Design Overview page
> >>
> >> (http://wiki.fluidproject.org/display/fluid/Date+Picker+Design+Overview
> >> )
> >>
> >> also has additional background on the component.
> >>
> >> Thanks very much, and happy holidays!
> >>
> >> Allison
> >>
> >>
> >> Begin forwarded message:
> >>
> >> From: Allison Bloodworth <abloodworth at berkeley.edu>
> >>
> >> Date: December 18, 2008 8:39:36 PM PST
> >>
> >> To: Fluid Mailing List <fluid-work at fluidproject.org>
> >>
> >> Subject: Date-Time Picker Update
> >>
> >> Hi folks,
> >>
> >> Erin and I have been making progress on the Date-Time Picker, and
> >> have some
> >>
> >> new wireframes available for review
> >>
> >> at: http://wiki.fluidproject.org/display/fluid/Date+Picker
> >> +Wireframes. We
> >>
> >> are still trying to determine whether to use a "tabbed" (see
> >> wireframes) or
> >>
> >> "rolling" time picker (see wireframes
> >>
> >> and http://ets-dev.berkeley.edu:8901/trunk/html/timepicker.html).
> >> If both
> >>
> >> seem like feasible options to the community, we plan to do user
> >> testing on
> >>
> >> both of them asap in January. Please let us know if you have
> >> feedback on how
> >>
> >> either of these two options would work in your context.
> >>
> >> One potential advantage of the tabbed time picker is that it can be
> >> more
> >>
> >> easily combined with the date picker in cases where date-time is a
> >> single
> >>
> >> field (e.g. Mneme & Modules in Sakai,
> >>
> >> see http://wiki.fluidproject.org/display/fluid/Date+Picker+Contexts+of+Use)
> >> .
> >>
> >> We'd be very interested in hearing from the community about whether
> >> it would
> >>
> >> be a problem to split date & time into two fields in these (or  
> other)
> >>
> >> situations. If so, we are thinking about other options for
> >> combining the
> >>
> >> 'rolling' time picker with the date picker, but are not sure these
> >> two
> >>
> >> pieces are well-suited to becoming a combined component.
> >>
> >> We've also been working on localization & internationalization
> >> guidelines
> >>
> >> for the Date-Time Picker
> >>
> >> (http://wiki.fluidproject.org/display/fluid/Date+Picker+Functional+Specification
> >> ),
> >>
> >> and would love to have any input from folks on things we may be
> >> missing.
> >>
> >> Finally, we are in the process of creating storycards for the Date
> >> Picker
> >>
> >> portion of the component only (since the Time Picker is still in
> >> flux).
> >>
> >> Check them out
> >>
> >> at: http://wiki.fluidproject.org/display/fluid/Date+Picker
> >> +Storycards --
> >>
> >> though they are still in draft form, we'd love to hear from
> >> developers as to
> >>
> >> whether the way we've started to organize them makes sense.
> >>
> >> Happy almost holidays, everyone!
> >>
> >> Allison & Erin
> >>
> >> Allison Bloodworth
> >>
> >> Senior User Interaction Designer
> >>
> >> Educational Technology Services
> >>
> >> University of California, Berkeley
> >>
> >> (415) 377-8243
> >>
> >> abloodworth at berkeley.edu
> >>
> >>
> >>
> >> _______________________________________________________
> >>
> >> fluid-work mailing list - fluid-work at fluidproject.org
> >>
> >> To unsubscribe, change settings or access archives,
> >>
> >> see http://fluidproject.org/mailman/listinfo/fluid-work
> >>
> >> Allison Bloodworth
> >>
> >> Senior User Interaction Designer
> >>
> >> Educational Technology Services
> >>
> >> University of California, Berkeley
> >>
> >> (415) 377-8243
> >>
> >> abloodworth at berkeley.edu
> >>
> >>
> >>
> >>
> >> _______________________________________________________
> >>
> >> fluid-work mailing list - fluid-work at fluidproject.org
> >>
> >> To unsubscribe, change settings or access archives,
> >>
> >> see http://fluidproject.org/mailman/listinfo/fluid-work
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Clay Fenlason
> >> Director, Educational Technology
> >> Georgia Institute of Technology
> >> (404) 385-6644
> >> _______________________________________________________
> >> fluid-work mailing list - fluid-work at fluidproject.org
> >> To unsubscribe, change settings or access archives,
> >> see http://fluidproject.org/mailman/listinfo/fluid-work
> >>
> >> Allison Bloodworth
> >> Senior User Interaction Designer
> >> Educational Technology Services
> >> University of California, Berkeley
> >> (415) 377-8243
> >> abloodworth at berkeley.edu
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Clay Fenlason
> > Director, Educational Technology
> > Georgia Institute of Technology
> > (404) 385-6644
> > <dial.gif>_______________________________________________________
> > fluid-work mailing list - fluid-work at fluidproject.org
> > To unsubscribe, change settings or access archives,
> > see http://fluidproject.org/mailman/listinfo/fluid-work
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: User Experience site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

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/20090106/23bc6ad9/attachment.html>


More information about the fluid-work mailing list