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

VERIFIED FIXED in B2G C3 (12dec-1jan)

Status

Firefox OS
Gaia::System
P3
normal
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: pabloUX, Assigned: arthurcc)

Tracking

({late-l10n})

unspecified
B2G C3 (12dec-1jan)
All
Gonk (Firefox OS)
late-l10n
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: interaction, UX-P1, [target:12/21])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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
(Reporter)

Updated

5 years ago
Whiteboard: UX_QA
(Reporter)

Updated

5 years ago
Component: Gaia → Gaia::System::First Time Experience
Priority: -- → P1
Whiteboard: UX_QA → UX_QA, Interaction design
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.
Depends on: 813129
(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)
blocking-basecamp: --- → ?
(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)
No longer depends on: 813129
Component: Gaia::First Time Experience → Gaia
Summary: [FTE] Set time manually is unnecessarily hard → Change year in input of type=date is not usable
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...
Flags: needinfo?(sergiov)

Comment 5

5 years ago
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?
Flags: needinfo?(aymanmaat)
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

5 years ago
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
Flags: needinfo?(jcarpenter)
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

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

Updated

5 years ago
Component: Gaia → Gaia::System

Comment 10

5 years ago
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.
Flags: needinfo?(sergiov)
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

5 years ago
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
Flags: needinfo?(aymanmaat)
(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.
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.
Flags: needinfo?(jcarpenter)
blocking-basecamp: ? → -
blocking-basecamp: - → +
Priority: P1 → P3
Marking as P3. Please raise if this bug is a must-fix.

Comment 16

5 years ago
Created attachment 685079 [details]
Value Selector - Choosing dd/mm/yy

Comment 17

5 years ago
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

5 years ago
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

5 years ago
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.
(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

5 years ago
Point taken. I didn't realize this is not only for Settings, but a building block issue that effects other similar situations.
Assignee: nobody → arthur.chen
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.
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.
Flags: needinfo?(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.
Flags: needinfo?(jcarpenter)

Comment 25

5 years ago
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
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

5 years ago
+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?
OK, can go for option 1 as in comment 24 and make the Calendar also use the new spinner selector?
@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

5 years ago
Sounds good enough for me. Let's go for Option 1 and use the Spinner Selector in all cases for v1.
Sounds like we're all in agreement. We'll resurrect the current date selector in future versions, with the benefit of more time.
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 :)
What are the next steps here?
I'll schedule the implementation of the spinner picker using the visual provided earlier.

Comment 35

5 years ago
Created attachment 688171 [details]
Value Selector - Choosing dd/mm/yy

Updated

5 years ago
Attachment #685079 - Attachment is obsolete: true
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Change year in input of type=date is not usable → Update <input type="date"> value selector to a spinner, make year selection possible
(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?
Flags: needinfo?(stas)
Keywords: late-l10n
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.
Target Milestone: --- → B2G C3 (12dec-1jan)
Whiteboard: UX_QA, Interaction design → interaction, UX-P1
Flags: needinfo?(l10n)

Comment 38

5 years ago
(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.
Flags: needinfo?(stas)
Flags: needinfo?(l10n)
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 ?
Flags: needinfo?(l10n)

Comment 40

5 years ago
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
Flags: needinfo?(l10n)
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 ?
Created attachment 691224 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/6963

Implement the spinner style date picker for the date type input.
Attachment #691224 - Flags: review?(rlu)
Whiteboard: interaction, UX-P1 → interaction, UX-P1, [target:12/21]
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. :)
Attachment #691224 - Flags: review?(rlu) → review+
Rudy, thanks for reviewing!
https://github.com/mozilla-b2g/gaia/commit/7bf44dc867ae687bec03bf571cbcae325b5a5b27
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 796695
Duplicate of this bug: 825845

Comment 47

5 years ago
Verified as fixed in build 20130103070201 on Unagi.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.