Re: Feedback requested on Fluid's Date-Time Picker

[John Norman]

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
<abloodwo...@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
<abloodwo...@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 <abloodwo...@berkeley.edu>

Date: December 18, 2008 8:39:36 PM PST

To: Fluid Mailing List <fluid-work@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

abloodwo...@berkeley.edu



_______________________________________________________

fluid-work mailing list - fluid-work@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

abloodwo...@berkeley.edu




_______________________________________________________

fluid-work mailing list - fluid-work@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@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
abloodwo...@berkeley.edu







--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
<dial.gif>_______________________________________________________
fluid-work mailing list - fluid-work@fluidproject.org
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work

_______________________________________________________
fluid-work mailing list - fluid-work@fluidproject.org
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work