813138 - Update <input type="date"> value selector to a spinner, make year selection possible

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Description

[Pablo Sanchez [:pabloUX]]

Starting date for date picker in Settings is 1980. The user has to manually go month by month 'til today. Tap and hold on "next month" doesn't help. This bugs seem to be related to Setttings/System itself, not FTE per se.

See image attached

Comment 1

[Fernando Campo (:fcampo)]

This is only happening when there's no SIM card installed, probably cause we are using NIZL for getting the current time, which depends on network provider information.

Comment 2

[Maria Angeles Oteo (:oteo)]

(In reply to Fernando Campo (:fcampo) from comment #1)
> This is only happening when there's no SIM card installed, probably cause we
> are using NIZL for getting the current time, which depends on network
> provider information.

This affects not only the FTE but on any input field of type=date. If users need to change the year it takes them 12 taps per year, this is not usable at all. We need a way to allow users to change the year easily so it should be a blocker.

Additionally, not all the operators provide NITZ (see bug 714355)

Comment 3

[Maria Angeles Oteo (:oteo)]

(In reply to Fernando Campo (:fcampo) from comment #1)
> This is only happening when there's no SIM card installed, probably cause we
> are using NIZL for getting the current time, which depends on network
> provider information.

This affects not only the FTE but on any input field of type=date. If users need to change the year it takes them 12 taps per year, this is not usable at all. We need a way to allow users to change the year easily so it should be a blocker.

Additionally, not all the operators provide NITZ (see bug 714355)

Comment 4

[Fernando Campo (:fcampo)]

Ok then, so now that this is a UX and probably Building Blocks issue, let's gonna involve more people :D

Sergi, Rafa, Arnau, not sure of who I should to summon in here...

Comment 5

[Rafael Rebolleda]

I don't know where the 1980 comes from, but we could start by changing that to 2012 or 2013. That's not the real issue, however (although it would help in many cases). 

Without getting into redesigning the picker, how about tap-and-hold on the arrows to move fast between months and then, after a certain time threshold, between years?

Comment 6

[Maria Angeles Oteo (:oteo)]

What if in a form you are asked about your birth date? You are over 30 right :-P? Do you want to click 12*30 times to go to it?

Comment 7

[Rafael Rebolleda]

Over 30? Gimme a break ;P

You're right, and that's why I said changing the year was not the real issue ;)

That said, I think it's more common to add, say, calendar events happening around now-for-the-user than birthdays. The Good Thing To Do™, as we've discussed in the building blocks team for a while, is for the caller app to be able to pass params to the picker, indicating what the default selection would be. Alas, it seems that can't be done.

If that's the case, at some point or another in time, the user will have to eventually navigate many years, and it's going to be a pain of different degrees.

We could also redesign the picker, of course. I believe  Josh did this one... adding him to the conversation. The more the merrier :D

Comment 8

[Daniel Coloma:dcoloma]

Even if apps can pass a parameter to the form (I think that is doable or may even work already) , there are use cases in which that is not good enough. The example of the birthday is a good one, where the range could be of 80 years!!! So there is no way to pass a good default selection that prevents jumping tens of years.

In short, we need a way to allow user to jump years without tapping 12 times.

Comment 9

[Rafael Rebolleda]

Yes, I absolutely agree. Passing a default can mitigate, but once again, is not a solution.

Comment 10

[Sergi]

One solution may be using a Time Value selector instead of the calendar for these cases. We could use one row for days, another one for months, and the third one for years. That's the most commonly way of implementing this kind of controls on the web, where dropdown menues are commonly used. I don't think the date selector is usable for the scenarios you describe (for example picking your birth date)

... and this drives me to the second solution....

We can redesign the date selector so it's possible to independently choose the year, and the month+day. 

The first solution doesn't need huge changes on what's been already done. The second solution involves a redesign + changes in the BB.

Comment 11

[Fernando Campo (:fcampo)]

Even if it would imply a little more work, I'd vote for changing the date picker bb and make the year choosing independent, as we might be missing some use cases now that could explode in our face in the future. 

And actually, even this solution wouldn't block any further changes for specific use cases, as the use of a drop down selector for birthdays or other long-range-date situations.

Comment 12

[ayman maat :maat]

I am in agreement. the current date selector using the calendar is impractical. This has been raised a couple of times before, long ago, but was not addressed. anyway. the proposition of long press is a good one, but is not optimal as discussed.

I would second sergi's suggestion of using the architecture of the time value selector and evolve it as *roughly* sketched here:

    set date
    _________________________

        06  |  jan   |  2011
        07  |  feb   |  2012
        08  |  mar  |  2013



let me know if you need more input

Comment 13

[Daniel Coloma:dcoloma]

(In reply to Sergi from comment #10)
> One solution may be using a Time Value selector instead of the calendar for
> these cases. We could use one row for days, another one for months, and the
> third one for years. That's the most commonly way of implementing this kind
> of controls on the web, where dropdown menues are commonly used. I don't
> think the date selector is usable for the scenarios you describe (for
> example picking your birth date)
> 

That could work for the content we are creating... But we cannot prevent a website to use type=date. If a website uses such an input element, it will lead to an awful experience, i.e. we need to fix the date value selector.

> ... and this drives me to the second solution....
> 
> We can redesign the date selector so it's possible to independently choose
> the year, and the month+day. 
> 
> The first solution doesn't need huge changes on what's been already done.
> The second solution involves a redesign + changes in the BB.

Comment 14

[Josh Carpenter [:jcarpenter]]

Hi everyone, I put together a quick competitive analysis of Mobile Safari and Chrome's HTML form interfaces:

https://www.dropbox.com/s/iylkxcq4zzd9dlu/Gaia_DateTimeCompetitiveAnalysis.pdf

I concur with Sergi and Ayman: a solution is to leverage the spinners we've already created and extend them to support the following input types:

* date
* datetime
* month

Firefox desktop doesn't support type=time, but I'm not clear if that's an impediment to our supporting it. I'll defer there to the more technically knowledgeable.

WRT to the existing calendar-based date picker, we can still use that places like Calendar, as a special interface element of sorts. And then revisit extending it in future versions with the luxury of more time.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Marking as P3. Please raise if this bug is a must-fix.

Comment 16

[Sergi]

Attachment: Value Selector - Choosing dd/mm/yy

Comment 17

[Sergi]

I agree with Josh. We should use the date picker within calendar, and make a small tweak to the time picker in order to convert it in a more flexible component letting the user to also choose a date. The great thing about building blocks is that they're highly customizable, so we can use the Time Value Selector BB and tweak it so it's possible to cover all the cases needing a date selector we have right now..

The current Date Value Selector BB is suitable to plan future events which are near of the present day. That means that, for example, when we use it within the Calendar, the year we should display is the present year. If the user wants to set an event for the next year he will need to navigate by clicking on the year+month selector (i think is a similar approach to what iOS is using right now).

Of course we can redesign the Date Value selector so we can separate the year from day+month, but we'd need some time in order to do it, and i'm not sure we have that time for v1. 

Find attached a sample of a tweaked time picker.

Let me know what you think.

Comment 18

[Jinghua zhang]

Not sure how much work it will add to us to do the date picker in this case. 

The simplest solution here is to change 1980 to 2013 so we apply our precious engineering time on  P1 bugs for now.

Comment 19

[Jinghua zhang]

I agree this bug is a must-fix. I just want to suggest a simple usable solution for now since we won't be able to make everything perfect for v1.

Comment 20

[Daniel Coloma:dcoloma]

(In reply to Jinghua zhang from comment #18)
> Not sure how much work it will add to us to do the date picker in this case. 
> 
> The simplest solution here is to change 1980 to 2013 so we apply our
> precious engineering time on  P1 bugs for now.

I am afraid this is not a solution. If we change the default to 2013, what if a website asks me for my birthday (10-October-1975)? I should click 456 times (38*12) in order to enter my birthday so that I feel even older :-)

We need to change the date picker in order to allow the user to change easily the year, there is no other option.

Comment 21

[Jinghua zhang]

Point taken. I didn't realize this is not only for Settings, but a building block issue that effects other similar situations.

Comment 22

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Dear all,

One thing I want to point out is we can only have one style of the picker for different type of input since now the value selector we talked about lives in Gaia System part, not per app. component.

The current implementation,
 1. <input type="date">: The calendar style of date picker
 2. <input type="time">: The spinner style for time selection
 3. type of datetime and month are not supported for now.

I think changing date picker to spinner style as attachment 685079 [details] is good, but I am just wondering if we could take a easier solution , like to add 2 more buttons to the calendar style date picker to change the year. 
--

BTW, as for how to set the default value for the picker, it is already supported. Please just set the value in the <input> field.

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I would like to make sure. Does changing the current 'calendar' style of the date picker to something similar to the 'time' selector means we need to change the one in Calendar too use it's own custom 'calendar' style?

If yes that sounds a lot of last minute change and making a simpler UI (even using '<<' or '>>' on the sides to navigate between years) sounds preferable.

Comment 24

[Josh Carpenter [:jcarpenter]]

To Rudy and Vivien's questions (and to sum up this thread):

We all agree that a fix is needed. Needing to press the "month" button 32*12 times to get to one's birth date is terrible.

Our options:

1. Change <input type="date"> to use the spinner design. 

* Per Sergi's mockup in comment#16.
* Vivien, to your question in comment#23, yes, we would prefer to have Calendar still use the current date picker value selector, but it would also be acceptable for v1 for calendar to also use the spinners.

2. Modify current date selector to enable year selection.

* Adding "year" buttons would creates too much clutter in a small space. 
* Would prefer to a "press-and-hold" mechanism, wherein holding month button begins to change the years, slowly at first, then more quickly.

I can live with either approach, but lean towards the first.

Comment 25

[Sergi]

I totally agree wit Josh in using Option 1 instead of having what we have right now as per date picker. Option 2, although not desirable, at least is a workaround to solve the year selection issue. But i still have my concerns about having to press and hold for a long time to get from 1980 to 2012, for example.

Redesigning the calendar-like date picker to add a new selector for years it's not trivial. As Josh points, you will see there's not enough space to just add a new selector, so the screen should be entirely redesigned and i'm not sure we have the time to do that.

@Rudy i understand date/time pickers are system components, and we can't decide which one to show if we have, for example, two different date pickers. So my proposal is to differentiate three different pickers: Time, Date, Events, where Time+Date will be spinners, and Events will be the calendar-like view we have right now. 

You can check here all of them, together with some new Value Selectors like Optgroups, Window Prompts or Nested Lists: https://www.dropbox.com/sh/b1qsssr39cl45j8/YXmgYO-QvE

As always, any comment is more than welcome

Comment 26

[Arthur Chen [:arthurcc][inactive after 6/30]]

The type of input is defined in the HTML spec and it is not encouraged to add our own customized type (such as Event). Thus for the "Date" type value selector, we have two options as Josh suggested, a spinner style picker or the current calendar-like view with "year" buttons. 

Given the tight schedule, I will suggest going for option 1 for v1.

Comment 27

[Sergi]

+1 let's go for Option 1, and let's review the possibilities of having a calendar-like date picker in the future.

Would it be possible to use the calendar data picker as a custom component instead of a system one for the Calendar app?

Comment 28

[Daniel Coloma:dcoloma]

OK, can go for option 1 as in comment 24 and make the Calendar also use the new spinner selector?

Comment 29

[Arthur Chen [:arthurcc][inactive after 6/30]]

@Sergi Yes, the calendar date picker can be used as a custom component. However, the change costs a lot of effort. We can have it implemented in later versions. 

@Daniel Going for option 1 makes Calendar use the spinner selector by default.

Comment 30

[Sergi]

Sounds good enough for me. Let's go for Option 1 and use the Spinner Selector in all cases for v1.

Comment 31

[Josh Carpenter [:jcarpenter]]

Sounds like we're all in agreement. We'll resurrect the current date selector in future versions, with the benefit of more time.

Comment 32

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

As long as we don't have to implement 2 solutions. One for calendar and one for the rest of the world any solution is fine to me :)

Comment 33

[Josh Carpenter [:jcarpenter]]

What are the next steps here?

Comment 34

[Arthur Chen [:arthurcc][inactive after 6/30]]

I'll schedule the implementation of the spinner picker using the visual provided earlier.

Comment 35

[Sergi]

Attachment: Value Selector - Choosing dd/mm/yy

Comment 36

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Sergi from comment #35)
> Created attachment 688171 [details]
> Value Selector - Choosing dd/mm/yy

We would need a l10n label to specify the order of things I think ... stas, would you mind telling us that's the best way to do it?

Comment 37

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 38

[Axel Hecht [:Pike]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #36)
> (In reply to Sergi from comment #35)
> > Created attachment 688171 [details]
> > Value Selector - Choosing dd/mm/yy
> 
> We would need a l10n label to specify the order of things I think ... stas,
> would you mind telling us that's the best way to do it?

Sorry, not sure what you're asking for specifically.

Also, if this does come with strings, I'd argue against this being a C3.

Comment 39

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Pike, we would need a date format string so the three spinner could switch their places for different locales (Besides the actual localization of the month and dates), e.g. "22""Januany""2012" for en-US, but "2012 年""1 月""22 日" for zh-TW.

Should this be something in the shared/locales/date.en-US.properties ?

Comment 40

[Axel Hecht [:Pike]]

Want to re-use dateTimeFormat_%x ?

Probably holds similar information you're looking for, the only caveat might be that I'm already seeing %e and %d for days, so it's a bit of parsing that one needs to do.

Status quo in l10n looks like:

bn-BD/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
ca/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
cs/shared/date/date.properties:dateTimeFormat_%x = %e. %m. %Y
cy/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
de/shared/date/date.properties:dateTimeFormat_%x = %d.%m.%Y
en-US/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
eo/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
es/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
ff/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
fr/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
fy-NL/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
he/shared/date/date.properties:dateTimeFormat_%x = %d.%m.%Y
hi-IN/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
hu/shared/date/date.properties:dateTimeFormat_%x = %Y. %m. %d.
id/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
it/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
ja/shared/date/date.properties:dateTimeFormat_%x = %Y/%m/%d
ko/shared/date/date.properties:dateTimeFormat_%x = %Y/%m/%d
lij/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
nl/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
pa/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
pl/shared/date/date.properties:dateTimeFormat_%x=%d.%m.%Y
pt-BR/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
ro/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
ru/shared/date/date.properties:dateTimeFormat_%x = %d.%m.%Y
sq/shared/date/date.properties:dateTimeFormat_%x = %d/%m/%Y
ur/shared/date/date.properties:dateTimeFormat_%x = %m/%d/%Y
zh-CN/shared/date/date.properties:dateTimeFormat_%x = %Y/%m/%d
zh-TW/shared/date/date.properties:dateTimeFormat_%x = %Y/%m/%d

Comment 41

[Arthur Chen [:arthurcc][inactive after 6/30]]

Currently I parse dateTimeFormat_%x string and use mozL10n.DateTimeFormat to do the localization. It looks like the same way suggested by Alex.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #39)
> Pike, we would need a date format string so the three spinner could switch
> their places for different locales (Besides the actual localization of the
> month and dates), e.g. "22""Januany""2012" for en-US, but "2012 年""1 月""22
> 日" for zh-TW.
> 
> Should this be something in the shared/locales/date.en-US.properties ?

Comment 42

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Link to https://github.com/mozilla-b2g/gaia/pull/6963

Implement the spinner style date picker for the date type input.

Comment 43

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 691224 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/6963

r=me with lint issues and review comments addressed.

Dear Arthur,

Thanks for taking this work.
I think it works great. :)

Comment 44

[Arthur Chen [:arthurcc][inactive after 6/30]]

Rudy, thanks for reviewing!
https://github.com/mozilla-b2g/gaia/commit/7bf44dc867ae687bec03bf571cbcae325b5a5b27

Comment 47

[Darren]

Verified as fixed in build 20130103070201 on Unagi.