jleasia at umich.edu
Wed Nov 12 13:05:26 UTC 2008
Just asking - do we need to worry about finer granularity for minutes? A
common time picked for Assignment due dates is 12:59 or 12:01. If a time
can be picked, and then the minutes changed by typing I suppose that
handles. Might be nice if there was a way to, for those that wanted,
click to get a wider range of minutes.
Erin Yu wrote:
>Here's a portion of the date and time picker storyboard Allison and I
>have worked on.
>Our time picker design is a bit different - once the time field is
>clicked, all possible options are displayed at once and the user
>clicks on the hour, minutes, and am/pm to select the time they want.
>It does require more clicks than the jQuery timepickr (two additional
>clicks at most), but does not restrict the movement of the mouse as
>they do as Colin pointed out.
>Would be interesting to see what people think. :)
>On 11-Nov-08, at 5:42 PM, Colin Clark wrote:
>>On 11-Nov-08, at 1:14 PM, Eli Cochran wrote:
>>>To the point about accessibility. While the current implementation
>>>is not accessible, with addition of some arrow key handlers this
>>>would be very accessible.
>>I guess the real answer to this question depends on how you define
>>"accessible." Just adding arrow key handlers won't necessarily make
>>the user interface more accessible in itself. It's a pretty dynamic
>>interface, so we'd also need to think about ways to cue users into
>>the changing spatial structure of the widget.
>>In the current implementation, you can edit the time with the
>>keyboard by simply entering it into the form field. This basic
>>interaction might suffice for some keyboard-only users, but it might
>>be sub-optimal. I guess we'd have to do some testing to know for sure.
>>That said, I think there's a larger problem with this particular
>>time picker. In my hands, it feels jerky and hard to control. I
>>think it requires far too much fine motor control for any user,
>>regardless of ability. It doesn't take Fitt's Law into account, and
>>the interaction suffers as a result.
>>Put simply, bigger things are easier to it. Closer things are also
>>easier to hit. In this example, the targets are too small, and
>>there's not enough "squishiness" or forgiveness between cells in the
>>time picker. Worse yet, you can't move the mouse diagonally to
>>acquire targets that are farther away. This makes it much more
>>likely that you'll accidently hit the wrong thing and the whole UI
>>will shift over unintentionally.
>>Let me try to illustrate with a little picture:
>>The fastest route from my currently selected hour, 02, to the 45-
>>minute target is via a diagonal line. If you try this in the real
>>picker, you'll find that it's really easy to accidentally select 03
>>and have the whole thing shift over on you. Instead, you have to
>>carefully move down and then over to the right:
>>The other issue that comes to mind is that it feels a bit like
>>internationalization was bolted on at the end. The field itself will
>>display your selection in 24-hr format, but still requires you to
>>interact with controls that use am/pm and are 12-hour based. I
>>suspect that this particular control wouldn't scale nicely for
>>picking 24-hour times natively.
>>>On Nov 11, 2008, at 10:01 AM, Allison Bloodworth wrote:
>>>>This time picker could definitely serve as inspiration for any
>>>>redesigns. I found a place to play with it: http://haineault.com/media/examples/jquery-utils/demo/ui-timepickr.html
>>>> and am wondering if folks on the list see any accessibility
>>>>issues with the design in general before we consider doing
>>>>something like this? For instance, since there there isn't a
>>>>moment that the two is selected before moving on to the 15 and
>>>>then the "am" (e.g. they are all selected after the user rolls
>>>>over everything) I wasn't sure if it would be difficult for a
>>>>screen reader to process. Perhaps it's supposed to work
>>>>differently with the keyboard, but neither Erin nor I could figure
>>>>out how to use it with the keyboard. I
>>It's hard to tell, but I think your link may be out of date,
>>Allison. Here's the link to a working demo that was included in the
>>blog post Eli sent along initially:
>>I think there's a lot to be said about this interaction, and it's a
>>novel concept. It was fascinating to play around with, but to me, it
>>just feels awkward in the end.
>>Technical Lead, Fluid Project
>>Adaptive Technology Resource Centre, University of Toronto
>>fluid-work mailing list - fluid-work at fluidproject.org
>>To unsubscribe, change settings or access archives,
>fluid-work mailing list - fluid-work at fluidproject.org
>To unsubscribe, change settings or access archives,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work