Feedback requested on Fluid's Date-Time Picker

Knoop, Peter knoop at umich.edu
Mon Jan 5 19:47:19 UTC 2009


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<https://collab.sakaiproject.org/portal>) from the DG: User Experience site.
You can modify how you receive notifications at My Workspace > Preferences.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090105/0ce805b5/attachment.html>


More information about the fluid-work mailing list