Feedback requested on Fluid's Date-Time Picker

Sun Dec 28 16:46:40 UTC 2008

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dial.gif
Type: image/gif
Size: 6222 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081228/432c695f/attachment.gif>