Roku Developer Program

[marcelo_cabral]

I'm currently finishing a new project, that I needed to implement a way to select a date, so I decided to create a DatePicker (similar to the ones used on mobile devices).
It ended up pretty nice so I decided to release the source code under MIT on GitHub at https://github.com/lvcabral/SGDatePicker

Let me know what you guys think about it.

[destruk]

Neat.  The main problem I think with this type of system is it takes soooo long to enter the date, where a 10-digit pin pad would be quicker.  If you need 06-16-1953 how long does your system take to scroll all the way there precisely, or how many keypresses, opposed to scrolling a highlight box to 0 (down 4 from the top-right default position for 3 presses) , then to 1 which is (up once), then to 6 (up 1 right 2), then 1, 9, 5, 6.  I get a total of 18 direction presses there.
A standard keypad would be a maximum of 5 presses to select any possible value - if you can find a way to beat that down to 3 presses for any 0-9 digit I'd be interested.

[marcelo_cabral]

It works ok for me because the objective is enter a "Due Date" for a task, so it is something close to the current date.
And we can always implement fast backward/forward with the control.

[destruk]

If it is always a date close to the current date, in the future, wouldn't it make more sense to have the user enter a number from 1-5 for the days, and then display the date that number of days in advance or something similar?

[marcelo_cabral]

"destruk" wrote:
If it is always a date close to the current date, in the future, wouldn't it make more sense to have the user enter a number from 1-5 for the days, and then display the date that number of days in advance or something similar?

I understand your point, but actually a task can be scheduled to months later as well, so for my use-case I believe the date picker is good enough.

[destruk]

Thanks for sharing the code.

[NB_]

"destruk" wrote:
Neat.  The main problem I think with this type of system is it takes soooo long to enter the date, where a 10-digit pin pad would be quicker.  If you need 06-16-1953 how long does your system take to scroll all the way there precisely, or how many keypresses, ...

That is a valid point but for me the solution for that would be for << / >> to skip faster in the Year field (say by -/+10).
Or press&hold on a key, expecting a speedup in labelList scroll but that's not the case currently. For reference, on touch-screen devices such selectors account for the velocity with which you "hurl" the list in a direction.

A standard keypad would be a maximum of 5 presses to select any possible value - if you can find a way to beat that down to 3 presses for any 0-9 digit I'd be interested.

Interesting - i got curious to look at the keypad and indeed 5 keys max to select a digit (counting OK), let's say average of 4. Times 8 for mm-dd-yyyy format, at 32 that's not that few keystrokes. Comparatively, the selector with labelLists would be as short as 3 buttons if the data is today - in fact i can joke it does a sort of "Huffman encoding" 🙂 - i mean variable-length encoding, depending how close the date is to present - which is most often the point of reference - the closer the date, the less keys needed!

[destruk]

Thanks RokuNB.
If all four sides have edge-wrapping enabled and OK doesn't have a selectable key on the screen but accepts the OK button, then 3 button presses to highlight any digit from any existing position. 🙂

7-8-9
4-5-6
1-2-3
--0-- (big 0 button autoselects if vertical position is anywhere on this line and centers on 0/middle column)

0 to 5 = Up/Down 2
0 to 4 or 6= Up/Down 2 and left/right 1=3
0 to 7 or 9=Down 1 and left/right 1=2
0 to 1 or 3=Up 1 and left/right 1=2

+OK of course -- so I agree, maximum of 4 presses required as you said.

Personally I'd want to link in the options button on the remote to act as backspace/delete, and add a confirmation yes/no prompt at the end, but for actual entry this seems to be most efficient for me.  For the wrapping, as soon as the end user notices it wraps they'll appreciate having that functionality.

[NB_]

"destruk" wrote:
Personally I'd want to link in the options button on the remote to act as backspace/delete, and add a confirmation yes/no prompt at the end, but for actual entry this seems to be most efficient for me.  For the wrapping, as soon as the end user notices it wraps they'll appreciate having that functionality.

Regarding "wrapping", food for thought: does your mouse wrap-around the screen? There are drivers/settings to make that happen - why don't we use that?

Regarding the OK/Cancel of sgDatePicker sample (and yours Yes/No) - i think better UX would not to have such buttons but to integrate the picker in the app flow - for example maybe the Back button goes to the previous step/state and the OK button goes to the next (that's when using LabelLists). Or maybe the UI can be even simpler with Right from the "year" moving to next state vs Left from "month" moving to previous screen (IDK, need some usability testing). Think of how things are done in touch-screen UI as baseline. Now recognize you are holding a remote.

[destruk]

I am an owl - my head wraps around 360 degrees.  It is great to be an owl. 🙂