Per Bug 773205 Comment 12. What we need is a UX & UI spec for date, time, datetime, datetime-local, month, week pickers (desktop). For platforms that have native equivalents, these should be used instead. Is that enough info?

Hi, any timeline on this missing feature? Is it a matter of weeks? Thanks

(In reply to Florian Bender from comment #1) > Per Bug 773205 Comment 12. > > What we need is a UX & UI spec for date, time, datetime, datetime-local, > month, week pickers (desktop). For platforms that have native equivalents, > these should be used instead. > > Is that enough info? Thanks for filing! Do you know of a test page where I can see these elements in action? (In reply to marco from comment #2) > Hi, > any timeline on this missing feature? Is it a matter of weeks? > Thanks There's no official timeline that I know of at the moment.

(In reply to Philipp Sackl [:phlsa] from comment #3) > (In reply to Florian Bender from comment #1) > > Per Bug 773205 Comment 12. > Thanks for filing! Do you know of a test page where I can see these elements > in action? > Not sure if I understood your question but you can use this page to test all date/time inputs with Google Chrome

(In reply to marco from comment #5) > http://www.w3schools.com/html/html5_form_input_types.asp Please read w3fools.com (In reply to Philipp Sackl [:phlsa] from comment #3) > Do you know of a test page where I can see these elements > in action? Check out sixrevisions.com/html5/new-html5-form-input-types – there's a link to a demo a bit below the table and detailed information below that. Or wufoo.com/html5/4-date.html for another Demo with less examples. Check out html5test.com/compare/browser/ for information on which Browser supports what. Please note that Fennec and (AFAIK) B2G both have special UI but no actual support for the input types – they are using a hack.

Here's a demo page with all input types : http://people.mozilla.org/~mmaslaney/widget_v2/firefox-html-forms.html The relevant ones are at the bottom. You can use Chrome to see a working example.

Adding to the backlog (and unassigning myself since I probably won't be the person working on it)

(In reply to Florian Bender from comment #1) > Per Bug 773205 Comment 12. > > What we need is a UX & UI spec for date, time, datetime, datetime-local, > month, week pickers (desktop). For platforms that have native equivalents, > these should be used instead. > > Is that enough info? So all you need is a suggestion on how it should look like? Some designs and etc?

(In reply to rustedwolf from comment #9) > So all you need is a suggestion on how it should look like? Some designs and > etc? It's the first step. We're waiting on UX to deliver now.

Is there any progress on this?

Is there any progress on this? Is there anything a newbie like me can do to help? Ccing myself :)

As it looks that the progress of this bug got stuck, I took the time to create some mockups for this. I have also created a simple live sample showing some basic functionality. (Note that it is not fully functional.) Let me know whether this helps you and whether I should continue to work on this and provide a proper specification for the inputs' UI. Sebastian

(In reply to Sebastian Zartner [:sebo] from comment #13) > Created attachment 8710338 [details] > Date and time input mockups Forgot to mention that the layout of these mockups is based on the UI used in different parts of Firefox like e.g. the XUL <tree> widget. Sebastian

As a web author, I'd like Firefox to support these input types: date, datetime, datetime-local, month, time, week More explanations in http://www.w3schools.com/tags/att_input_type.asp

Morpheus is working on the UI spec.

move this work to meta bug 888320.

Hi all, After collecting feedback from all stakeholders in London, I've uploaded the draft UX spec v 0.8 to InVision (See attached link). It'll be great if you can spend some time reviewing the spec, and share with us your concerns or if something missing on feasibility, accessibility and localization. In order to save your time on reviewing this 80+ pages, you can find all pickers following the structure below: a. Basic mechanism b. Attributes c. Keyboard integration d. Localization e. RTL Please note that the spec is still WIP and waiting for joining Firefox UX critique session, thank. Spec Link: https://invis.io/237UTNHS8

Looks great! Wrt. localization - it would be awesome if you were able to use L20n, but I don't know if we'll be able to land it in time for your release. The work is tracked in bug 1279002. The only comment I have is actually not related to l10n/i18n, but UX. From the list of keys allowed to operate on the fields I don't see scroll wheel. Is it something you considered adding?

I'm not on the ni list, but I also want to give some feedback. Here are some points I saw while going through the slides: - Months and years look disabled, therefore they should have a darker color. (e.g. in slide 4) - Having an up arrow to get "down" to the days looks illogical. (e.g. slide 4) - Slides just say 'Trigger Picker', but not how it's triggered. (I guess by clicking or tapping, e.g. slide 8) - The input box has the month selected, but the picker shows days. (slide 8) - The popup´s size should be adjusted according to its contents. (e.g. slide 10) - Display the scroll arrows as disabled when there are no more options. (e.g. slide 10) - Show the picker below the predefined items instead of 'Other...' (e.g. slide 12) - Entering 1 into the input box should select the first day for consistency with entering other numbers. (e.g. slide 14) - Page Up/Down on the month within the input box should go 10 months forward/back to be consistent with the year action (e.g.) - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) - Avoid empty spaces within the picker. (e.g. slide 28) - RTL slides say "Rright" instead of "Right". (e.g. slide 24) The above points mainly apply to all inputs and pickers. The mentioned slides are just examples where I saw them. Furthermore, the use cases of picking a date of birth or the current day, week, month or time are not covered well by the current UI. The mockups I attached in comment 13 cover the latter (by having a button to pick the current date). The former could be improved by allowing to "zoom out" to a year range view like the date picker in Windows 7+ provides it instead of having to scroll from the current year to the birth year. Sebastian

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #20) > Looks great! > > Wrt. localization - it would be awesome if you were able to use L20n, but I > don't know if we'll be able to land it in time for your release. The work is > tracked in bug 1279002. > > The only comment I have is actually not related to l10n/i18n, but UX. From > the list of keys allowed to operate on the fields I don't see scroll wheel. > Is it something you considered adding? Hi Zibi, Thanks for your reminder. We did't specifically define the functionality for "scroll wheel" in the spec, however, we did want to have scroll wheel to scroll on both picker and input fields. I will add this in the spec later, thanks.

Hi Sebastian, Sorry for the late reply, and thanks for these questions. We've updated the spec and fix lots of minor mistakes or typos, and we also provide detailed descriptions for most of flows. Please check the spec for more information and find the comments inline for UX-related questions. (In reply to Sebastian Zartner [:sebo] from comment #22) > I'm not on the ni list, but I also want to give some feedback. > > Here are some points I saw while going through the slides: > - Months and years look disabled, therefore they should have a darker color. > (e.g. in slide 4) Sorry that we didn't mention this is not the final visual design. Now the visual desinger is working on the final visual design. > - Having an up arrow to get "down" to the days looks illogical. (e.g. slide > 4) Please find the added description in the spec for answer. If still questioned, could you elaborate more about the question? > - Slides just say 'Trigger Picker', but not how it's triggered. (I guess by > clicking or tapping, e.g. slide 8) Sorry we didn't make it clear. The circle with an arrow means to click by mouse as default, you can find the rule across entire spec. > - The input box has the month selected, but the picker shows days. (slide 8) We've fixed the mistake, thanks. > - The popup´s size should be adjusted according to its contents. (e.g. slide > 10) We intend not to adjust the size according to it's contents since this might cause user annoyance and distraction. > - Display the scroll arrows as disabled when there are no more options. > (e.g. slide 10) Good suggestion! We'll update in the next spec version. > - Show the picker below the predefined items instead of 'Other...' (e.g. > slide 12) The main reason we put 'Other...' in the next level is: 1. Prioritize the options to help user focus on one thing at a time; 2. Preset lists function totally differently than picker; 3. Preset lists are suggestions which web authors specifically address to users, so it would be better to display suggestions first instead of displaying all options. > - Entering 1 into the input box should select the first day for consistency > with entering other numbers. (e.g. slide 14) Please find the added notes for the rules and more information. > - Page Up/Down on the month within the input box should go 10 months > forward/back to be consistent with the year action (e.g.) We had discussion with accessibility team, including visually impaired, and they suggest having forward/back one month makes more sense to them. Besides, there are only 12 months/12 hours within a year/day, forward/back 10 months/hours will make user harder to pick a specific month. > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) This was suggested by accessibility team. But we'll confirm with them what's the more common use case. > - Avoid empty spaces within the picker. (e.g. slide 28) Could you give more details for this question? > - RTL slides say "Rright" instead of "Right". (e.g. slide 24) > Nice catch! Updated. > The above points mainly apply to all inputs and pickers. The mentioned > slides are just examples where I saw them. > > Furthermore, the use cases of picking a date of birth or the current day, > week, month or time are not covered well by the current UI. The mockups I > attached in comment 13 cover the latter (by having a button to pick the > current date). The former could be improved by allowing to "zoom out" to a > year range view like the date picker in Windows 7+ provides it instead of > having to scroll from the current year to the birth year. > Thanks for the suggestion. We had this idea before, however, we realize there is no specific use case to use a 'today' button in date picker after we did two user testings. Normally, 'today' button is more useful for calendar apps or websites to provide a quick way to switch back to today after user explores within the calendar. But the purposes of providing users a date picker is to let users easily pick a date. After taking simplicity and usability into consideration, we decided to remove 'today' button but always display the month of today as default. As for scrolling for the year of birth, we'll fine tune the acceleration when users scroll or click on the up/down arrows. Generally speaking, our main focus for designing the pickers is to ensure we provide a simple, quick and basic tool to help general users complete small tasks. Please let us know if still any concerns or suggestions, thanks. > Sebastian

So sorry for the late feedback. It looks good! My main concern that we only briefly touched on in London is color contrast. It would be good if the prev/next month days had higher contrast in the picker, and the non-selected month/year in the month picker would as well. More comments below.. * I got confused about slide 14 (Arrow keys on input box). The picker should not be visible. Pressing alt+down should open it and bring it into focus. But otherwise the user is arrowing and changing the value in the input field with a collapsed picker. * Same in slide 15, 16 and 17. The picker should not be visible. * I don't understand how the user changes the month with number keys. It seems like the initial focus should be on the left-most field (depending on locale it would be different). Then the user punches in the number of the date. For example, pressing 9102016 will set the field to September 10th, 2016 (with US locale). If we are in a non-US locale the same value would be set by pressing 1092016. * Just of out curiosity, how was the 3 letter abbreviated month chosen for the input field? I have never seen "mmm / dd / yyyy" before. I have seen "mm / dd / yyyy". Having it be number seems less confusing for number key entry above too. * In slide 17, I would add that the values should be bound by min/max in the other fields as well. For example, if the max was "April 23, 2016", pressing end in the day field would change the value to 23, not 30. * In slide 21, I am unclear about the escape behavior. In previous slides it specifies that the field changes the value as you arrow around in the picker. So the field already shows a value, but pressing escape removes the values? What if there was a previous user-set value in the field before the picker was expanded? I think it should revert to that, and not completely unset the field. Some nuance is probably required here. * Keys on month and time pickers look good!

(In reply to Morpheus Chen [:morpheus] UX from comment #24) > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > This was suggested by accessibility team. But we'll confirm with them what's > the more common use case. > Shift + Tab! Even if we wanted to use alt+tab we couldn't because the OS consumes that for switching windows :)

Hi Eitan, Thanks for your feedback, please find my comments inline. (In reply to Eitan Isaacson [:eeejay] from comment #25) > So sorry for the late feedback. It looks good! > > My main concern that we only briefly touched on in London is color contrast. > It would be good if the prev/next month days had higher contrast in the > picker, and the non-selected month/year in the month picker would as well. > As I mentioned before, now the UX spec has forwarded to visual designer, Helen. She'll provide a detailed visual spec afterward, including visual changes to refine the visibility and contrast, etc. However, still appreciate your reminder. > More comments below.. > > * I got confused about slide 14 (Arrow keys on input box). The picker should > not be visible. Pressing alt+down should open it and bring it into focus. > But otherwise the user is arrowing and changing the value in the input field > with a collapsed picker. > * Same in slide 15, 16 and 17. The picker should not be visible. The picker here is triggered by clicking the input field, instead of alt+down. We divide the situations into three types: 1. User only uses cursor on picker; 2. User clicks the input box and triggers the picker by cursor, but uses keyboard in input box or cursor on picker randomly; 3. User only uses keyboard to trigger the picker. Based on the rules above, you might mix the second and third situation. I will put a cursor in the spec to make it more understandable. But please let us know if that's still issues among our design. > * I don't understand how the user changes the month with number keys. It > seems like the initial focus should be on the left-most field (depending on > locale it would be different). Then the user punches in the number of the > date. For example, pressing 9102016 will set the field to September 10th, > 2016 (with US locale). If we are in a non-US locale the same value would be > set by pressing 1092016. It's the same situation as I mentioned above. When user clicks the input box by cursor, the clicked segment will be highlighted. However, if user triggers the input box by keyboard, the highlight will always start from the first segment. > * Just of out curiosity, how was the 3 letter abbreviated month chosen for > the input field? I have never seen "mmm / dd / yyyy" before. I have seen "mm > / dd / yyyy". Having it be number seems less confusing for number key entry > above too. We had the discussion and decided to use Apr/03/2016 instead of 04/03/2016 to ensure there's no misunderstanding between month and date. However, it affects the default value. We chose to have mmm/dd/yyyy instead of mm/dd/yyyy to make it consistent with Apr/03/2016. I admit it's pretty weird, so we've forwarded the concern to the localization team to find a better solution for the issues above. > * In slide 17, I would add that the values should be bound by min/max in the > other fields as well. For example, if the max was "April 23, 2016", pressing > end in the day field would change the value to 23, not 30. Yes, this is what we planed. We just didn't elaborate them in the spec to keep spec simple, but we did check with the engineers. Thanks for the reminder. > * In slide 21, I am unclear about the escape behavior. In previous slides it > specifies that the field changes the value as you arrow around in the > picker. So the field already shows a value, but pressing escape removes the > values? What if there was a previous user-set value in the field before the > picker was expanded? I think it should revert to that, and not completely > unset the field. Some nuance is probably required here. Sorry that I misunderstand what we discussed in London. I thought escape key will cancel all actions and go back to default value. So that means the ESC key will function as Space and Enter key? > * Keys on month and time pickers look good! Thank you!!!

(In reply to Eitan Isaacson [:eeejay] from comment #26) > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > > > This was suggested by accessibility team. But we'll confirm with them what's > > the more common use case. > > > > Shift + Tab! > > Even if we wanted to use alt+tab we couldn't because the OS consumes that > for switching windows :) Thanks for correction. We'll update the spec immediately!

(In reply to Eitan Isaacson [:eeejay] from comment #26) > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > > > This was suggested by accessibility team. But we'll confirm with them what's > > the more common use case. > > > > Shift + Tab! > > Even if we wanted to use alt+tab we couldn't because the OS consumes that > for switching windows :) But Shift + Tab is used for tabbing backwards.

> > * In slide 21, I am unclear about the escape behavior. In previous slides it > > specifies that the field changes the value as you arrow around in the > > picker. So the field already shows a value, but pressing escape removes the > > values? What if there was a previous user-set value in the field before the > > picker was expanded? I think it should revert to that, and not completely > > unset the field. Some nuance is probably required here. > > Sorry that I misunderstand what we discussed in London. I thought escape key > will cancel all actions and go back to default value. So that means the ESC > key will function as Space and Enter key? I checked the meeting minutes Jamie sent. Yes, ESC will function as what you mentioned, I've updated the spec. Thanks.

(In reply to Morpheus Chen [:morpheus] UX from comment #24) > (In reply to Sebastian Zartner [:sebo] from comment #22) > > - Months and years look disabled, therefore they should have a darker color. > > (e.g. in slide 4) > > Sorry that we didn't mention this is not the final visual design. Now the > visual desinger is working on the final visual design. They are not changed yet, so I guess that will happen the next days, right? > > - Having an up arrow to get "down" to the days looks illogical. (e.g. slide > > 4) > > Please find the added description in the spec for answer. If still > questioned, could you elaborate more about the question? What I meant is the up arrow besides the month in "3. Scroll & Pick Month" of slide "5.1 Basic Flow". This arrow indicates that clicking it will get you higher in the date hierarchy. Though clicking it will show the day picker, which is lower in the hierarchy. Therefore I think you should switch the up and down arrows from step 2 and 3 (or replace them by something else or just remove them). > > - The popup´s size should be adjusted according to its contents. (e.g. slide > > 10) > > We intend not to adjust the size according to it's contents since this might > cause user annoyance and distraction. Then you should use the space better. E.g. in "4. Auto-Correct" of "5.2.2 Input Box With Preset Max-Min" there is a big unused space. For example, you could list all twelve months of a year in a grid of 3 x 4 and only make the year scrollable. Or only show the months and allow to switch the years by going up and down. This would allow to pick the month faster. > > - Entering 1 into the input box should select the first day for consistency > > with entering other numbers. (e.g. slide 14) > > Please find the added notes for the rules and more information. Let me make this clearer. At note C you say "Whenever detecting the confirmation, the picker below will reflect the values simultaneously." I say it should already reflect them before. E.g. when you type '1', day 1 should be selected in the picker. When you then type '2', day 12 will be selected in the picker, confirmation will be detected and the highlight moves to the next segment. > > - Page Up/Down on the month within the input box should go 10 months > > forward/back to be consistent with the year action (e.g.) > > We had discussion with accessibility team, including visually impaired, and > they suggest having forward/back one month makes more sense to them. > Besides, there are only 12 months/12 hours within a year/day, forward/back > 10 months/hours will make user harder to pick a specific month. A smaller step could also be chosen, e.g. 3 months/hours. Point is, having Page Up/Down do the same as Arrow Up/Down for months (i.e. increase/decrease by 1) while they do different things for years (i.e. increase/decrease by 1 vs. 10) is inconsistent. Another approach is to keep the step size consistent at 10 but also switch the year. E.g. having July 2016 selected, pressing Page Up would get you May 2017, pressing Page Down September 2015. > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > This was suggested by accessibility team. But we'll confirm with them what's > the more common use case. I didn't explain why, because I thought it was obvious that Shift + Tab is the shortcut used to switch the focus to the previous item as expected in those slides (and that Alt + Tab is used by the OS [Thank you, Eitan, for clarifying that!]). Note that you missed to change the notes to say Shift + Tab. > > - Avoid empty spaces within the picker. (e.g. slide 28) > > Could you give more details for this question? In "5. Auto-Correct" of slide "6.2.2 Input Box With Preset Max-Min" there is some empty space at the top of the picker due to the restriction, which looks a bit odd. You may either just remove that empty space or show the unavailable months and years as disabled. Btw. another approach for picking month and year in that slide would be to restrict the choice of years to 2017 when FEB is selected. > > The above points mainly apply to all inputs and pickers. The mentioned > > slides are just examples where I saw them. > > > > Furthermore, the use cases of picking a date of birth or the current day, > > week, month or time are not covered well by the current UI. The mockups I > > attached in comment 13 cover the latter (by having a button to pick the > > current date). The former could be improved by allowing to "zoom out" to a > > year range view like the date picker in Windows 7+ provides it instead of > > having to scroll from the current year to the birth year. > > > > Thanks for the suggestion. We had this idea before, however, we realize > there is no specific use case to use a 'today' button in date picker after > we did two user testings. Normally, 'today' button is more useful for > calendar apps or websites to provide a quick way to switch back to today > after user explores within the calendar. But the purposes of providing users > a date picker is to let users easily pick a date. After taking simplicity > and usability into consideration, we decided to remove 'today' button but > always display the month of today as default. A use case is a train or bus travel page where you may want to jump back to the current day after first having selected a day in the future. But I can get your point. > As for scrolling for the year > of birth, we'll fine tune the acceleration when users scroll or click on the > up/down arrows. Generally speaking, our main focus for designing the pickers > is to ensure we provide a simple, quick and basic tool to help general users > complete small tasks. I am still convinced that the Windows calendar widget better suits this use case, but fine tuned scrolling will also be ok. (In reply to okj from comment #29) > (In reply to Eitan Isaacson [:eeejay] from comment #26) > > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > > > > > This was suggested by accessibility team. But we'll confirm with them what's > > > the more common use case. > > > > > > > Shift + Tab! > > > > Even if we wanted to use alt+tab we couldn't because the OS consumes that > > for switching windows :) > > But Shift + Tab is used for tabbing backwards. Exactly that is what the shortcut in the slides is meant to do. Sebastian

Hi Sebastian, Thanks for your valuable feedback. Please find my comments inline. (In reply to Sebastian Zartner [:sebo] from comment #31) > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > (In reply to Sebastian Zartner [:sebo] from comment #22) > > > - Months and years look disabled, therefore they should have a darker color. > > > (e.g. in slide 4) > > > > Sorry that we didn't mention this is not the final visual design. Now the > > visual desinger is working on the final visual design. > > They are not changed yet, so I guess that will happen the next days, right? Yes, but just to clarify, there will be another document which displays the final visual design and lists all measurements for engineers to implement. > > > > - Having an up arrow to get "down" to the days looks illogical. (e.g. slide > > > 4) > > > > Please find the added description in the spec for answer. If still > > questioned, could you elaborate more about the question? > > What I meant is the up arrow besides the month in "3. Scroll & Pick Month" > of slide "5.1 Basic Flow". This arrow indicates that clicking it will get > you higher in the date hierarchy. Though clicking it will show the day > picker, which is lower in the hierarchy. Therefore I think you should switch > the up and down arrows from step 2 and 3 (or replace them by something else > or just remove them). > The arrows here apply the logic of expand/collapse. You can find the mockup below for the transition. This might give you more context on our intention. To clarify, this is not the final visual design. Helen is working on the transition and also the arrows design here which will be designed based on transition. And I'll let her know your concern. https://www.youtube.com/watch?v=8fnCu6B7ow8 > > > - The popup´s size should be adjusted according to its contents. (e.g. slide > > > 10) > > > > We intend not to adjust the size according to it's contents since this might > > cause user annoyance and distraction. > > Then you should use the space better. E.g. in "4. Auto-Correct" of "5.2.2 > Input Box With Preset Max-Min" there is a big unused space. For example, you > could list all twelve months of a year in a grid of 3 x 4 and only make the > year scrollable. Or only show the months and allow to switch the years by > going up and down. This would allow to pick the month faster. > Thanks for your suggestion. But there are two reasons why we reluctantly decided not to have grid design. First, based on the user research, we noticed the grid design can use the space better, but it's not listed in an intuitive order. That is, users will spend more time searching for a specific month, or need time to understand the logic of the order. However, just like I mentioned before, our goal is to ensure user can have an simple and quick tool, therefore, we decided to use scroller as an intuitive and understandable way. Second, big unused space doesn't always means bad thing. Space can help users easier and more efficient to concentrate on what we want them to focus. In this case, space can function as a hint to let user notice a specific range of selection. > > > - Entering 1 into the input box should select the first day for consistency > > > with entering other numbers. (e.g. slide 14) > > > > Please find the added notes for the rules and more information. > > Let me make this clearer. At note C you say "Whenever detecting the > confirmation, the picker below will reflect the values simultaneously." I > say it should already reflect them before. E.g. when you type '1', day 1 > should be selected in the picker. When you then type '2', day 12 will be > selected in the picker, confirmation will be detected and the highlight > moves to the next segment. > I understood your previous question, and what you suggest now is our initial design too. However, the reason we chose this design is because of two concerns. 1. Performance might be low if user constantly inputs numbers, for example, if user keeps typing 123456789 in year segment, this will cause the calendar frequently change layout from 0001, 0012, 0123 ~ 6789. 2. Constantly changing layout will also cause users hard to focus on the picker. > > > - Page Up/Down on the month within the input box should go 10 months > > > forward/back to be consistent with the year action (e.g.) > > > > We had discussion with accessibility team, including visually impaired, and > > they suggest having forward/back one month makes more sense to them. > > Besides, there are only 12 months/12 hours within a year/day, forward/back > > 10 months/hours will make user harder to pick a specific month. > > A smaller step could also be chosen, e.g. 3 months/hours. Point is, having > Page Up/Down do the same as Arrow Up/Down for months (i.e. increase/decrease > by 1) while they do different things for years (i.e. increase/decrease by 1 > vs. 10) is inconsistent. > > Another approach is to keep the step size consistent at 10 but also switch > the year. E.g. having July 2016 selected, pressing Page Up would get you May > 2017, pressing Page Down September 2015. > We understand your concern, but we still want to consult accessibility team for more feedback since these changes might impact visually impaired more than the sighted. We can easily realize the changes no matter what steps pageup/down skips, but this will cause more time for visually impaired to understand the changes. Therefore, I would like to have accessibility team provide us what they think. Eitan, could you help check this with Jamie or Marco? > > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > > > This was suggested by accessibility team. But we'll confirm with them what's > > the more common use case. > > I didn't explain why, because I thought it was obvious that Shift + Tab is > the shortcut used to switch the focus to the previous item as expected in > those slides (and that Alt + Tab is used by the OS [Thank you, Eitan, for > clarifying that!]). > > Note that you missed to change the notes to say Shift + Tab. > Sorry for my mistake. I didn't double confirm. Now the design and note are both fixed. > > > - Avoid empty spaces within the picker. (e.g. slide 28) > > > > Could you give more details for this question? > > In "5. Auto-Correct" of slide "6.2.2 Input Box With Preset Max-Min" there is > some empty space at the top of the picker due to the restriction, which > looks a bit odd. You may either just remove that empty space or show the > unavailable months and years as disabled. > > Btw. another approach for picking month and year in that slide would be to > restrict the choice of years to 2017 when FEB is selected. > Please find my comments above for space. Besides, we considered your another approach before, but this might confuse users more since users might not know the preset range and they will need more time to process why the picker constantly changes when pick month or year first. What do you think? > > > The above points mainly apply to all inputs and pickers. The mentioned > > > slides are just examples where I saw them. > > > > > > Furthermore, the use cases of picking a date of birth or the current day, > > > week, month or time are not covered well by the current UI. The mockups I > > > attached in comment 13 cover the latter (by having a button to pick the > > > current date). The former could be improved by allowing to "zoom out" to a > > > year range view like the date picker in Windows 7+ provides it instead of > > > having to scroll from the current year to the birth year. > > > > > > > Thanks for the suggestion. We had this idea before, however, we realize > > there is no specific use case to use a 'today' button in date picker after > > we did two user testings. Normally, 'today' button is more useful for > > calendar apps or websites to provide a quick way to switch back to today > > after user explores within the calendar. But the purposes of providing users > > a date picker is to let users easily pick a date. After taking simplicity > > and usability into consideration, we decided to remove 'today' button but > > always display the month of today as default. > > A use case is a train or bus travel page where you may want to jump back to > the current day after first having selected a day in the future. But I can > get your point. > > > As for scrolling for the year > > of birth, we'll fine tune the acceleration when users scroll or click on the > > up/down arrows. Generally speaking, our main focus for designing the pickers > > is to ensure we provide a simple, quick and basic tool to help general users > > complete small tasks. > > I am still convinced that the Windows calendar widget better suits this use > case, but fine tuned scrolling will also be ok. > Could you provide a screenshot of Windows calendar widget? We did research Windows Edge for pickers design, but we want to make sure we are talking the same thing. If what you suggest is better, then we could still apply it in our design. > (In reply to okj from comment #29) > > (In reply to Eitan Isaacson [:eeejay] from comment #26) > > > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > > > - Alt + Tab is probably meant to be Shift + Tab. (e.g. slide 17 and 20) > > > > > > > > This was suggested by accessibility team. But we'll confirm with them what's > > > > the more common use case. > > > > > > > > > > Shift + Tab! > > > > > > Even if we wanted to use alt+tab we couldn't because the OS consumes that > > > for switching windows :) > > > > But Shift + Tab is used for tabbing backwards. > > Exactly that is what the shortcut in the slides is meant to do. > > Sebastian

(In reply to Morpheus Chen [:morpheus] UX from comment #32) > (In reply to Sebastian Zartner [:sebo] from comment #31) > > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > (In reply to Sebastian Zartner [:sebo] from comment #22) > > > > - Having an up arrow to get "down" to the days looks illogical. (e.g. slide > > > > 4) > > > > > > Please find the added description in the spec for answer. If still > > > questioned, could you elaborate more about the question? > > > > What I meant is the up arrow besides the month in "3. Scroll & Pick Month" > > of slide "5.1 Basic Flow". This arrow indicates that clicking it will get > > you higher in the date hierarchy. Though clicking it will show the day > > picker, which is lower in the hierarchy. Therefore I think you should switch > > the up and down arrows from step 2 and 3 (or replace them by something else > > or just remove them). > > > > The arrows here apply the logic of expand/collapse. You can find the mockup > below for the transition. This might give you more context on our intention. Yes, with the animations shown in the video it gets clearer. > To clarify, this is not the final visual design. Helen is working on the > transition and also the arrows design here which will be designed based on > transition. And I'll let her know your concern. Helen Holmes? I suggest she should be CC'ed on this bug, so she can follow the discussion herself. > > > > - The popup´s size should be adjusted according to its contents. (e.g. slide > > > > 10) > > > > > > We intend not to adjust the size according to it's contents since this might > > > cause user annoyance and distraction. > > > > Then you should use the space better. E.g. in "4. Auto-Correct" of "5.2.2 > > Input Box With Preset Max-Min" there is a big unused space. For example, you > > could list all twelve months of a year in a grid of 3 x 4 and only make the > > year scrollable. Or only show the months and allow to switch the years by > > going up and down. This would allow to pick the month faster. > > > > Thanks for your suggestion. But there are two reasons why we reluctantly > decided not to have grid design. > First, based on the user research, we noticed the grid design can use the > space better, but it's not listed in an intuitive order. That is, users will > spend more time searching for a specific month, or need time to understand > the logic of the order. Sounds reasonable, but while it's not as intuitive as a list, I assume after the second or third use people will be faster than with scrolling. (I have no stats to verify that assumption, though.) > However, just like I mentioned before, our goal is > to ensure user can have an simple and quick tool, therefore, we decided to > use scroller as an intuitive and understandable way. Second, big unused > space doesn't always means bad thing. Space can help users easier and more > efficient to concentrate on what we want them to focus. In this case, space > can function as a hint to let user notice a specific range of selection. Btw. note that the Firefox Menu also adapts its size to the shown contents. Of course, empty space can be something good. In this case, though, it rather wastes space and hides the elements behind and helping to focus on it is already reached by other stylistic means like borders, shadows and the popup arrow. > > > > - Entering 1 into the input box should select the first day for consistency > > > > with entering other numbers. (e.g. slide 14) > > > > > > Please find the added notes for the rules and more information. > > > > Let me make this clearer. At note C you say "Whenever detecting the > > confirmation, the picker below will reflect the values simultaneously." I > > say it should already reflect them before. E.g. when you type '1', day 1 > > should be selected in the picker. When you then type '2', day 12 will be > > selected in the picker, confirmation will be detected and the highlight > > moves to the next segment. > > > > I understood your previous question, and what you suggest now is our initial > design too. However, the reason we chose this design is because of two > concerns. 1. Performance might be low if user constantly inputs numbers, for > example, if user keeps typing 123456789 in year segment, this will cause the > calendar frequently change layout from 0001, 0012, 0123 ~ 6789. 2. > Constantly changing layout will also cause users hard to focus on the > picker. You're right, it may be distracting when the value changes constantly. I guess that's why other browsers don't allow to change the values in the input box while the picker is open. Maybe that's also something to consider... > > > > - Avoid empty spaces within the picker. (e.g. slide 28) > > > > > > Could you give more details for this question? > > > > In "5. Auto-Correct" of slide "6.2.2 Input Box With Preset Max-Min" there is > > some empty space at the top of the picker due to the restriction, which > > looks a bit odd. You may either just remove that empty space or show the > > unavailable months and years as disabled. > > > > Btw. another approach for picking month and year in that slide would be to > > restrict the choice of years to 2017 when FEB is selected. > > > > Please find my comments above for space. Besides, we considered your another > approach before, but this might confuse users more since users might not > know the preset range and they will need more time to process why the picker > constantly changes when pick month or year first. What do you think? Yes, without hint people might wonder why the selection gets restricted. And having a hint might be obtrusive in somewhat obvious cases (might also be the case with the auto-correction hint, though). > > > As for scrolling for the year > > > of birth, we'll fine tune the acceleration when users scroll or click on the > > > up/down arrows. Generally speaking, our main focus for designing the pickers > > > is to ensure we provide a simple, quick and basic tool to help general users > > > complete small tasks. > > > > I am still convinced that the Windows calendar widget better suits this use > > case, but fine tuned scrolling will also be ok. > > > > Could you provide a screenshot of Windows calendar widget? We did research > Windows Edge for pickers design, but we want to make sure we are talking the > same thing. If what you suggest is better, then we could still apply it in > our design. The Edge picker is pretty poorly designed, IMO. I am talking about the calendar widget that opens when you click the clock in the task bar. I'll attach a screenshot. (In reply to Morpheus Chen [:morpheus] UX from comment #30) > > > * In slide 21, I am unclear about the escape behavior. In previous slides it > > > specifies that the field changes the value as you arrow around in the > > > picker. So the field already shows a value, but pressing escape removes the > > > values? What if there was a previous user-set value in the field before the > > > picker was expanded? I think it should revert to that, and not completely > > > unset the field. Some nuance is probably required here. > > > > Sorry that I misunderstand what we discussed in London. I thought escape key > > will cancel all actions and go back to default value. So that means the ESC > > key will function as Space and Enter key? > > I checked the meeting minutes Jamie sent. Yes, ESC will function as what you > mentioned, I've updated the spec. Thanks. Unfortunately I was not at the All Hands in London, but what Morpheus meant was that Escape should reset the value to the previously user-set one or unset it if there wasn't one before, *not* to accept the currently chosen value like Space or Enter. Sebastian

(In reply to Sebastian Zartner [:sebo] from comment #33) > (In reply to Morpheus Chen [:morpheus] UX from comment #32) > > (In reply to Sebastian Zartner [:sebo] from comment #31) > > > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > > (In reply to Sebastian Zartner [:sebo] from comment #22) > > > > > - Having an up arrow to get "down" to the days looks illogical. (e.g. slide > > > > > 4) > > > > > > > > Please find the added description in the spec for answer. If still > > > > questioned, could you elaborate more about the question? > > > > > > What I meant is the up arrow besides the month in "3. Scroll & Pick Month" > > > of slide "5.1 Basic Flow". This arrow indicates that clicking it will get > > > you higher in the date hierarchy. Though clicking it will show the day > > > picker, which is lower in the hierarchy. Therefore I think you should switch > > > the up and down arrows from step 2 and 3 (or replace them by something else > > > or just remove them). > > > > > > > The arrows here apply the logic of expand/collapse. You can find the mockup > > below for the transition. This might give you more context on our intention. > > Yes, with the animations shown in the video it gets clearer. > > > To clarify, this is not the final visual design. Helen is working on the > > transition and also the arrows design here which will be designed based on > > transition. And I'll let her know your concern. > > Helen Holmes? I suggest she should be CC'ed on this bug, so she can follow > the discussion herself. > Sorry I didn't make it clear. The visual designer is Helen Huang also in Taipei. And I've added her into the mail list. Thanks for your suggestion. > > > > > - The popup´s size should be adjusted according to its contents. (e.g. slide > > > > > 10) > > > > > > > > We intend not to adjust the size according to it's contents since this might > > > > cause user annoyance and distraction. > > > > > > Then you should use the space better. E.g. in "4. Auto-Correct" of "5.2.2 > > > Input Box With Preset Max-Min" there is a big unused space. For example, you > > > could list all twelve months of a year in a grid of 3 x 4 and only make the > > > year scrollable. Or only show the months and allow to switch the years by > > > going up and down. This would allow to pick the month faster. > > > > > > > Thanks for your suggestion. But there are two reasons why we reluctantly > > decided not to have grid design. > > First, based on the user research, we noticed the grid design can use the > > space better, but it's not listed in an intuitive order. That is, users will > > spend more time searching for a specific month, or need time to understand > > the logic of the order. > > Sounds reasonable, but while it's not as intuitive as a list, I assume after > the second or third use people will be faster than with scrolling. (I have > no stats to verify that assumption, though.) > We considered that before. However, it's some kind of a tradeoff to choose to make it more intuitive. First, on average most of use cases will only need users to use picker once, or different kinds of pickers for filling forms of personal profile. That means users might not get the chance to familiar with grid design. Second, just like what I mentioned before, we are designing default pickers to help user finish simple tasks. So we want to provide the most intuitive tool without any learning curve. > > However, just like I mentioned before, our goal is > > to ensure user can have an simple and quick tool, therefore, we decided to > > use scroller as an intuitive and understandable way. Second, big unused > > space doesn't always means bad thing. Space can help users easier and more > > efficient to concentrate on what we want them to focus. In this case, space > > can function as a hint to let user notice a specific range of selection. > > Btw. note that the Firefox Menu also adapts its size to the shown contents. > Of course, empty space can be something good. In this case, though, it > rather wastes space and hides the elements behind and helping to focus on it > is already reached by other stylistic means like borders, shadows and the > popup arrow. > We'll check if we can follow Firefox Menu design for our pickers. > > > > > - Entering 1 into the input box should select the first day for consistency > > > > > with entering other numbers. (e.g. slide 14) > > > > > > > > Please find the added notes for the rules and more information. > > > > > > Let me make this clearer. At note C you say "Whenever detecting the > > > confirmation, the picker below will reflect the values simultaneously." I > > > say it should already reflect them before. E.g. when you type '1', day 1 > > > should be selected in the picker. When you then type '2', day 12 will be > > > selected in the picker, confirmation will be detected and the highlight > > > moves to the next segment. > > > > > > > I understood your previous question, and what you suggest now is our initial > > design too. However, the reason we chose this design is because of two > > concerns. 1. Performance might be low if user constantly inputs numbers, for > > example, if user keeps typing 123456789 in year segment, this will cause the > > calendar frequently change layout from 0001, 0012, 0123 ~ 6789. 2. > > Constantly changing layout will also cause users hard to focus on the > > picker. > > You're right, it may be distracting when the value changes constantly. I > guess that's why other browsers don't allow to change the values in the > input box while the picker is open. Maybe that's also something to > consider... > > > > > > - Avoid empty spaces within the picker. (e.g. slide 28) > > > > > > > > Could you give more details for this question? > > > > > > In "5. Auto-Correct" of slide "6.2.2 Input Box With Preset Max-Min" there is > > > some empty space at the top of the picker due to the restriction, which > > > looks a bit odd. You may either just remove that empty space or show the > > > unavailable months and years as disabled. > > > > > > Btw. another approach for picking month and year in that slide would be to > > > restrict the choice of years to 2017 when FEB is selected. > > > > > > > Please find my comments above for space. Besides, we considered your another > > approach before, but this might confuse users more since users might not > > know the preset range and they will need more time to process why the picker > > constantly changes when pick month or year first. What do you think? > > Yes, without hint people might wonder why the selection gets restricted. And > having a hint might be obtrusive in somewhat obvious cases (might also be > the case with the auto-correction hint, though). > > > > > As for scrolling for the year > > > > of birth, we'll fine tune the acceleration when users scroll or click on the > > > > up/down arrows. Generally speaking, our main focus for designing the pickers > > > > is to ensure we provide a simple, quick and basic tool to help general users > > > > complete small tasks. > > > > > > I am still convinced that the Windows calendar widget better suits this use > > > case, but fine tuned scrolling will also be ok. > > > > > > > Could you provide a screenshot of Windows calendar widget? We did research > > Windows Edge for pickers design, but we want to make sure we are talking the > > same thing. If what you suggest is better, then we could still apply it in > > our design. > > The Edge picker is pretty poorly designed, IMO. I am talking about the > calendar widget that opens when you click the clock in the task bar. I'll > attach a screenshot. Thanks, we'll check if it can help our design. > > (In reply to Morpheus Chen [:morpheus] UX from comment #30) > > > > * In slide 21, I am unclear about the escape behavior. In previous slides it > > > > specifies that the field changes the value as you arrow around in the > > > > picker. So the field already shows a value, but pressing escape removes the > > > > values? What if there was a previous user-set value in the field before the > > > > picker was expanded? I think it should revert to that, and not completely > > > > unset the field. Some nuance is probably required here. > > > > > > Sorry that I misunderstand what we discussed in London. I thought escape key > > > will cancel all actions and go back to default value. So that means the ESC > > > key will function as Space and Enter key? > > > > I checked the meeting minutes Jamie sent. Yes, ESC will function as what you > > mentioned, I've updated the spec. Thanks. > > Unfortunately I was not at the All Hands in London, but what Morpheus meant > was that Escape should reset the value to the previously user-set one or > unset it if there wasn't one before, *not* to accept the currently chosen > value like Space or Enter. > This is what I thought, we might need Eitan to check the mechanism of ESC for us. > Sebastian

As promised, I attached a screenshot of the Windows 10 calendar widget. It shows three states, to which you can switch by clicking the month/year. Sebastian

Hi all, Per talked, I've attached UX spec v1.2 as record for reference, please always find the InVision link below for the latest spec, Thanks. Link: https://invis.io/GU7VBIB4D

We've had a few offline discussions, on another bug [1], and on invision [2], about the date time patterns & placeholders, and I'd like to take the discussion here: When an input field is empty, we need placeholders to show what each section represents [2]. For en-US, the date field would be the familiar "mm/dd/yyyy", and for European locales, it would be more like "dd.mm.yyyy". We can get the order and separators from CLDR, but we can't find anything suitable for placeholders in CLDR. One way we can approach this is by using en-US placeholders as default: "dd" for day, "mm" for month, and "yyyy" for year, and give localizers the option to override them if necessary. So the placement order and separators will come from CLDR, but placeholders won't. Hopefully this simplifies the problem while maintaining flexibility. Please let us know if you have any feedback or concern about this approach :) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1280654 [2] https://mozilla.invisionapp.com/share/237UTNHS8#/screens/171579981/comments/67706201 [3] https://mozilla.invisionapp.com/share/237UTNHS8#/screens/171579820

(In reply to Morpheus Chen [:morpheus] UX from comment #32) > (In reply to Sebastian Zartner [:sebo] from comment #31) > > (In reply to Morpheus Chen [:morpheus] UX from comment #24) > > > (In reply to Sebastian Zartner [:sebo] from comment #22) > > > > - Page Up/Down on the month within the input box should go 10 months > > > > forward/back to be consistent with the year action (e.g.) > > > > > > We had discussion with accessibility team, including visually impaired, and > > > they suggest having forward/back one month makes more sense to them. > > > Besides, there are only 12 months/12 hours within a year/day, forward/back > > > 10 months/hours will make user harder to pick a specific month. > > > > A smaller step could also be chosen, e.g. 3 months/hours. Point is, having > > Page Up/Down do the same as Arrow Up/Down for months (i.e. increase/decrease > > by 1) while they do different things for years (i.e. increase/decrease by 1 > > vs. 10) is inconsistent. > > > > Another approach is to keep the step size consistent at 10 but also switch > > the year. E.g. having July 2016 selected, pressing Page Up would get you May > > 2017, pressing Page Down September 2015. > > > > We understand your concern, but we still want to consult accessibility team > for more feedback since these changes might impact visually impaired more > than the sighted. We can easily realize the changes no matter what steps > pageup/down skips, but this will cause more time for visually impaired to > understand the changes. Therefore, I would like to have accessibility team > provide us what they think. > > Eitan, could you help check this with Jamie or Marco? > I can see maybe having a smaller step size of 3 months. The last suggestion of skipping 10 months into the next year in my opinion makes page up/down confusing and unusable. I'll put this in Marco's plate for more feedback.

NI Morpheus for comment 37

Hi all, Yes, what Scott mentioned in comment 37 is the conclusion from UX and engineers in Taiwan. Originally we got 2 major proposals for the placeholder: Proposal 1 Default: mm/dd/yyyy Value inputed: 04/04/2016 Pros: Most common format, numbers are understandable Cons: User might get confused when month and date are the same numbers Proposal 2 Default: mmm/dd/yyyy Value inputed: Apr/04/2016 Pros: User won't get confused when month and date are the same numbers Cons: Rarely used, keyboard inputs will be complicated The main reason why we decided to have proposal 1 as default is to simplify the format and the mechanism. Besides, the confusing use case will be pretty rare since it only happens when web author sets a confusing preset value for users. We've consulted localization team for a better solution, however, it seems no best solution for all countries. Consequently, we chose to have a default format but still provide flexibility for localizers to change the default format. Please let us know if you have any concerns, thanks.

I'm going to argue about the default, yyyy-mm-dd is what most European is familiar with, it's also the ISO standard specifies. So I think that should be the default It's also what the date.toJSON spit out: yyyy-mm-dd

By pure curiosity, why the ISO 8601 standard format wasn't selected as a proposal? Isn't it less likely to cause confusion? [1] [1] https://xkcd.com/1179/

As I understood comment 37, the order would depend on the browser locale, so if it is set to en-us (the only place in the world really that uses mm/dd/yyyy) it would use that, but if set to somewhere else it would be set to a more suitable format. The m, d and y is not changed though, even if m is not the short for month in the current locale. Maybe this was incorrect, as comment 40 sounds like mm/dd/yyyy would be the standard format no matter what. If this is the case it should be discussed further, as it makes no sense to select that format. It is a standard only used in the US, and not anywhere else in the world (not even Canada, even though it exists there). This wikipedia article brings more light to this: https://en.wikipedia.org/wiki/Date_format_by_country As is said above as well, why not follow the ISO standard, which is used by most programming languages as well? Or at least go for a format more commonly used (see the wikipedia link above). I wonder on what data the comment 40's statement about mm/dd/yyyy being the most common format is, could you provide a reference morpheus? Thanks!

Apologies if I'm speaking out of turn, here, but it seems like the selection of the date-format string should be either in the hands of the OS (which tends to know the user's locale and all of these formats, etc.) or in the browser's locale settings. Or, if you want to go crazy, maybe the page's locale settings (coming from an HTTP response header, perhaps?). As much as I like ISO 8601, virtually nobody wants to see that format on the screen. The case of date.toJSON is a red herring: JSON is intended to be software-readable, not human-readable. Comment #40 is horribly confusing, as it suggests that there will be a single date format used universally. My understanding was that the conversation was narrowing toward how to choose the actual letters shown on the screen (e.g. "mm" to represent "Month" in English-speaking locales, "jj" to represent the same in French-speaking locales, etc.) and not what the overall date format was going to be. It seems like the localized date-format-specifier problem has been solved many times in the past. Are we trying to invent a new way to map letters to pieces of dates?

So there are two separate issues we are discussing here: 1. The order of dates and their separators 2. The placeholder for each field The first issue, as many have pointed out, should be locale specific (and what locale setting to use is the topic of another discussion). And for this, we can refer to the CLDR data from Unicode, because they've already solved the problem with deciding what's the acceptable pattern for each locale (see links below). The proposals outlined by Morpheus in comment 40 are meant to address the second issue, so he simplified it by using en-US as the pattern, and focus on the placeholders. By "most common" I believe he meant using "dd" as day, "mm" as month, and "yyyy" as year. Ideally we'd like to refer to CLDR for placeholders as well, but I didn't found anything appropriate. So I'm hoping localizers could help us translate them. For example, "aaaa" replaces "yyyy" for Spanish, and "tttt" replaces "yyyy" for German (I don't know Spanish or German so I might be wrong). If nothing is done on localizers' side, it would default to using "dd", "mm", and "yyyy" as placeholders. I agree that this seems like a solved problem, so maybe there's a more readily available solution I'm not aware of that doesn't involve additional effort from localizers. Hope this clarifies some points. Thanks everyone for commenting on this issue! Examples of CLDR patterns: http://www.unicode.org/cldr/charts/29/summary/en.html#1776 http://www.unicode.org/cldr/charts/29/summary/de.html#1889 http://www.unicode.org/cldr/charts/29/summary/zh.html#1815

Hi all, I'm really glad to have all your feedback, and this is exactly the discussion we originally wanted. But just let me clarify what I mentioned in Comment #40 first since it seemed I confused everybody. What Scott and I mentioned about the "format" is only the actual letters shown for the default placeholder. I tried to list all possible order of date field and separator in the spec [1] based on what I found in Wiki[2] and CLDR, and all these various formats will just be applied based on localization needs which are defined in CLDR. This was also the conclusion we had in London with localization team. It would be great if anyone can still provide format we miss in the spec. According to all your comments, it seems you all agree to use "mm" to represent month instead of "mmm". (Don't forget, this will be changed based on locales, like Christopher commented: > "mm" to represent "Month" in English-speaking locales, "jj" to represent the same in French-speaking >locales, etc.) Therefore, now the last problem is to decide a default date format when browser can't detect any of locale settings. This is what we've kept asking for answers for quite a long time, so it would be great if you can provide a best solution. Based on the comments, Jimmy, Geoffroy and Fredrik prefer to have ISO 8601 as default, but Christopher seems to have concerns. In my opinion, I still would like to have the expertise of localization team to make the call since the localized date-format-specifier problem has been solved many times in the past. What do you think? Please let me know if I don't make sense. [1] https://mozilla.invisionapp.com/d/#/console/8012535/171579820/preview (In reply to Christopher Schultz from comment #44) [2] https://en.wikipedia.org/wiki/Date_format_by_country

I'll be working on the API to provide the CLDR pattern for the date (see bug 1280654 and its dependencies). I'm almost done with the first two APIs (the one for getCalendarInfo and getDisplayNames), and the date/time patterns will be the third API. I didn't start working on it yet, but based on the conversation with scott, my current plan is to expose sth like: mozIntl.getDateTimePattern('en-US', 'yMd'); // "M/d/y" mozIntl.getDateTimePattern('pl', 'yMd'); // "d.MM.y" mozIntl.getDateTimePattern('de', 'yMd'); // "d.M.y" mozIntl.getDateTimePattern('de', 'Hm'); // "HH:mm" mozIntl.getDateTimePattern('en-US', 'Hm'); // "H.mm" Then, if I understand correctly, we will use localization entities to replace tokens "MM", "M", "d", "y", "HH", "H", and "mm" with their localized variants in the returned pattern. One thing to notice is that the the time pattern requires us to already know if the locale/user uses 24h or 12h clock. We can either take this information from the OS, or we need to get the information from the locale. That may be material for the fourth API: mozIntl.getDateTimeInfo(locale); Does it sound like a good plan?

> As much as I like ISO 8601, virtually nobody wants to see that format on the screen Speak for yourself i actually want that format, and we swedes use it all the time :P

(In reply to Jimmy Warting from comment #48) > > As much as I like ISO 8601, virtually nobody wants to see that format on the screen > > Speak for yourself i actually want that format, and we swedes use it all the > time :P Actually, I prefer it, too. But I'm a programmer and so I also start counting at zero :) (In reply to Morpheus Chen [:morpheus] UX from comment #46) > But just let me clarify what I mentioned in Comment #40 first since it seemed > I confused everybody. What Scott and I mentioned about the "format" is only > the actual letters shown for the default placeholder. Perfect. Thanks for the clarification. I'm just dying to have the date-picker widgets finally added to ff. Even MSIE has them, and that's saying something. :p

(In reply to Eitan Isaacson [:eeejay] from comment #38) > I can see maybe having a smaller step size of 3 months. The last suggestion > of skipping 10 months into the next year in my opinion makes page up/down > confusing and unusable. Agreed. Don't cross year boundaries with any of that navigation while in the Month field.

Hi all, I've uploaded the PDF file of UX spec v1.3 as record, and please find the latest spec in the link below. You can find the updated details in release notes. Besides, based on the discussion, it seems that everyone all agree to have ISO 8601 as the default placeholder for date format. We'll update the spec and state ISO 8601 is the default placeholder. If anyone, especially localization team, has any concerns please let me know, thanks. Latest spec link: https://mozilla.invisionapp.com/share/GU7VBIB4D

Quick summary of what had been discussed offline: ISO 8601 format is like yyyy/mm/dd, which would be used as default when locale is not specified (or couldn't matched). Feel free to correct me if I understand incorrectly.

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #52) > Quick summary of what had been discussed offline: > ISO 8601 format is like yyyy/mm/dd Nope. It's yyyy-MM-dd. https://en.wikipedia.org/wiki/ISO_8601

Hi all, I've uploaded the PDF file of UX spec v1.4 as record, and please find the latest spec in the link below. You can find the updated details in release notes. Latest spec link: https://mozilla.invisionapp.com/share/GU7VBIB4D

Now that mozIntl.getCalendarInfo landed and mozIntl.getDisplayNames is in review, I'm ready to get back to the conversation about the remaining items. I reviewed the latest spec and here's the list of items that we'll want to take from ICU/CLDR and we should discuss: 1) the placeholder skeletons ('yyyy-mm-dd', '--:-- --', 'yyyy-mm-dd, --:-- --' etc.) should come from CLDR/ICU. I'll investigate the API for that next. It may require us to combine I18n and L10n as I suggested in comment 47. The skeleton we'll likely receive from ICU will be in a form like "M/d/y, H.mm" and we will then use localization to map those tokens into placeholder tokens: - M -> mm - d -> dd - y -> yyyy - H -> -- - mm -> -- The open question is if we'll want to allow localizers to define tokens for hour/minute/dayperiod or just use "--" across the board. 2) 12h/24h clocks This may be an important UX detail. My experience from the FxOS days is that users tend to be very opinionated about it and we want to make sure that we get it right. The easier part of the solution is to add a small API that will be a counterpart to mozIntl.getCalendarInfo that deals with date/time info: mozIntl.getDateTimeInfo(locale); // {locale: 'en-US', hour24: true } The tricky part here is that by default this will only return the default clock for the given locale. 12h for en-US, 24h for fr. But if the user modified the defaults in the OS, we should reflect that. There are couple ways to do that: a) We can design another API that will return the current OS hour12 setting b) We can extend Intl API to take hour12 settings from the OS and reflect it in its results c) We can modify how we store the locale list used by Intl API to include hour12 setting in the locale token (for example instead of `[en-US, pl]` we would have `[en-US-u-hc-h24, pl-u-hc-h24]` when the user sets hour12=false) The first option is what we aimed for in FxOS with document.mozHour12, and moztimeformatchange event. The second and third are debated in ECMA402 group: https://github.com/tc39/ecma402/issues/68 We can try to aim for something along the lines of b/c internally for now and move the conversation in ECMA402 forward. 3) Caps There are many places in the slide deck which indicate intentional use of caps. This is a risky move from the i18n perspective since locales vary in how they treat caps. For example: - In slide 6 all months names use style:short and are in caps. Would we want to do that for all months? - In the same slide, "APRIL 2016" is style:long and all caps. - In slide 62 word "Week" starts with a caps. CLDR data returns "week" for en-US. We should be careful with altering what CLDR returns here (when we try to enforce first letter cap for en-US) - In slide 13 there's word "Other" and ellipsis. That should come from a localized entity since not all locales will want to use an ellipsis (and I question if en-US should by the way[0]) - In slide 22 the error and note uses different date pattern than in the textbox. I think it should use the same - In slide 22 "Choose dates in 5-day increments" is a very hard phrase to localize and may not fit in one line for many languages. Any chance we can reword it? - And as a general implementation note: Please, make sure you structure the code architecture to take into account that this is just for one of many different calendar types and we will want to add other than gregorian calendars later. We should aim not to require any serious refactoring of the code to add it. [0] Generally speaking, ellipsis indicates that the menu item is meaningless without data from the user ("Find" - what?). "Other" doesn't require more data from the user. - https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW3 - https://msdn.microsoft.com/en-us/library/windows/desktop/dn742478(v=vs.85).aspx

Also, annevk shed some light on the datetime local to global transformations we should be doing when interpreting user input: https://github.com/whatwg/html/issues/1787 That means that `minDays` that I added to getCalendarInfo are important, and we need to do more calculations between timezones, week preferences etc.

Filed bug 1303579 for `navigator.locales`.

NI myself and Morpheus to follow up for comment 55

NI Michelle for comment 55, item 3) Caps

Update visual spec which is based on the UX document, please let me know if any questions.

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #59) > NI Michelle for comment 55, item 3) Caps Hi Wesley and Zibi - comments inline: In slide 6 all months names use style:short and are in caps. Would we want to do that for all months? Yes, we should use style:short and all caps for the selector portion. - In the same slide, "APRIL 2016" is style:long and all caps. OK to use style:long as the label of the calendar. - In slide 62 word "Week" starts with a caps. CLDR data returns "week" for en-US. We should be careful with altering what CLDR returns here (when we try to enforce first letter cap for en-US) This should remain initial cap in this case, but not others where it is shown lower case. Here it is a name for a specific week (Week 7) not a generic week (select a different week). - In slide 13 there's word "Other" and ellipsis. That should come from a localized entity since not all locales will want to use an ellipsis (and I question if en-US should by the way[0]) Yes, you can remove the ellipsis here. - In slide 22 the error and note uses different date pattern than in the textbox. I think it should use the same Agreed. Both should follow the same format. - In slide 22 "Choose dates in 5-day increments" is a very hard phrase to localize and may not fit in one line for many languages. Any chance we can reword it? I struggled with this one - it means you can only pick a day that is [X number] or a multiple of [X number] of days before or after the first allowable date. I wanted to explain this as succinctly and precisely as possible entirely with words, but maybe the answer to simplify this is to rely on the information in the interface do the heavy lifting and have the error message convey this: Select a date from the calendar. Or: Choose a selectable day from the calendar. What do you think? Does this present an issue for a11y?

Hi Zibi, Thanks for bringing these concerns. After discussion with EPM and engineer, please find my response inline. >(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #55) > The open question is if we'll want to allow localizers to define tokens for > hour/minute/dayperiod or just use "--" across the board. This should be the same as the way we handle date picker on localization. That is, we use "--" as default placeholder, but leave flexibility for localizer to customize for their locales. > 2) 12h/24h clocks > > This may be an important UX detail. My experience from the FxOS days is that > users tend to be very opinionated about it and we want to make sure that we > get it right. From UX perspective, since all operating systems provide the ability to change time format, we would suggest following OS setting to have consistent experience across the OS no matter where the locale is. > 3) Caps > - In slide 22 the error and note uses different date pattern than in the > textbox. I think it should use the same It's my bad I didn't revise this section. Now it's updated, thanks.

Hi all, I've uploaded the PDF file of UX spec v1.5 as record, and please find the latest spec in the link below. This revision targets to unify some inconsistency between keyboard and cursor mode. You can find the updated details in the release notes. Latest spec link: https://mozilla.invisionapp.com/share/GU7VBIB4D

(In reply to Morpheus Chen [:morpheus] UX from comment #62) > > 2) 12h/24h clocks > > > > This may be an important UX detail. My experience from the FxOS days is that > > users tend to be very opinionated about it and we want to make sure that we > > get it right. > > From UX perspective, since all operating systems provide the ability to > change time format, we would suggest following OS setting to have consistent > experience across the OS no matter where the locale is. Hey folks, We had UX decision on the (12h/24h) issue but looks like the technical end is still an open question. Let me quote what Zibi mentioned from comment 55 as below. a) We can design another API that will return the current OS hour12 setting b) We can extend Intl API to take hour12 settings from the OS and reflect it in its results c) We can modify how we store the locale list used by Intl API to include hour12 setting in the locale token (for example instead of `[en-US, pl]` we would have `[en-US-u-hc-h24, pl-u-hc-h24]` when the user sets hour12=false) Should we create a separate engineering bug to proceed on this discussion ?

I have a plan to tackle that. Now that we have all other APIs ready for you, the one remaining one is how to retrieve the hour12 bit. There is a conversation in bug 1301640 about this and I'm planning on implementation in bug 1303579.

Hi all, I've released the UX spec to v1.51 which provides more details about date picker and the aligned mechanism of error messages in current Firefox. You can find the updated items in the released note. Please let me know if any questions, thanks. Spec link: https://mozilla.invisionapp.com/share/GU7VBIB4D

Hi all, I've released the UX spec to v1.52 which simplify the mechanism of the month/year menu within date picker. You can find the updated details in release notes. Please let me know if any questions, thanks. Spec link: https://mozilla.invisionapp.com/share/GU7VBIB4D

:morpheus - one question. In the latest revision you still seem to use "yyyy" for year placeholder, and "mm" for month. My worry here is that this will not work for almost any locale except of english, because "yyyy" means nothing in them, not to mention languages that don't use latin alphabet. I remember us discussing it and we were talking about either going for CLDR narrow date fields ("yr/mth/day") or for example placeholders ("2016-01-01" grayed out) Am I missing something here or is it the decision of the UX team to expose it to all locales?

:zibi - I stand with your point on the "yyyy" placeholder syntax. IMHO, the most intuitive way to fill the field is either the current date, or an example smartly chosen to differentiate days and months which may not to satisfy the range criteria (a day in the low twenties seems to be the best choice there). I'm not sure how CLDR narrow date fields would integrate safely with specific locales (e.g. with the japanese 2017年01月13日). Same remark applies for the time picker.

for comment 68

(In reply to Morpheus Chen [:morpheus] UX from comment #67) > Created attachment 8826546 [details] > Date_Time_Picker_v1.52_20170113.pdf > > Hi all, > > I've released the UX spec to v1.52 which simplify the mechanism of the > month/year menu within date picker. You can find the updated details in > release notes. Please let me know if any questions, thanks. > > Spec link: https://mozilla.invisionapp.com/share/GU7VBIB4D For people who want to see the diffs, modifications are marked at p.9, p.12, p.13, p.26, p.60, p.67, p.78.

:zibi I think there had been so many discussions that I lost track what we finally agreed on :( Here's what I can recall: We talked about what placeholder to use, because "yyyy" is not good for any locale other than English. One option is to localize them the old fashioned way (w/ .properites), or we can try using strings from CLDR. I see that from the API you created in Bug 1287677 that you've already exposed 'year', 'month', and 'day' fields, and with the possibility of including the narrow forms. One concern UX brought up was that the strings from CLDR might not map exactly to what every locale expects placeholders to look like. For example in en-US, while CLDR outputs 'month' or 'mth' for the month field, the most appropriate might be 'mm' instead. Perhaps we can use a CLDR strings as default, but with an option to localize the placeholders the usual way? just so that we can customize them if we need to. Do you think that's a viable option?

Hmmm, the more I think about it the less I like the current CLDR options. Let's just do l10n for now. I filled CLDR ticket and maybe we'll upstream our localizations to CLDR eventually - http://unicode.org/cldr/trac/ticket/9993

After talked with Scott, if I recall correctly, I remembered we had the discussion on the placeholder before too, and we did talk about the solutions you raised here. The narrow date fields(yr/mth/day) had the same problems as yyyy/mm/dd did since it's also an exclusive abbreviation for English. As for 2016-01-01, we had concerns this might cause confusions according to the locale, for example, 01-01-2016 might confuse users if it's Jan-01-2016 or 01-Jan-2016. From UX perspective, our goal was to make sure the placeholder provides clues instead of confusions. So, the best solution is to handle the decision to localizers as they know what's best for the locale. Based on the concerns above, we had a conclusion to allow localizers fine tune the placeholders based on the usability in their countries since we couldn't find the best format of placeholder which can cover all various requirements from different locales. That's why we noted in the UX spec which states "Default input field displays yyyy-mm-dd, but varies based on locale". Please let me know if I misunderstand what we discussed or there are any feasibility issues, thanks. (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #68) > :morpheus - one question. In the latest revision you still seem to use > "yyyy" for year placeholder, and "mm" for month. > > My worry here is that this will not work for almost any locale except of > english, because "yyyy" means nothing in them, not to mention languages that > don't use latin alphabet. > > I remember us discussing it and we were talking about either going for CLDR > narrow date fields ("yr/mth/day") or for example placeholders ("2016-01-01" > grayed out) > > Am I missing something here or is it the decision of the UX team to expose > it to all locales?

FWIW, other browsers solved the issue about the placeholders by using the initial letter of the word repeatedly, e.g. "tt.mm.jjjj" in German locales. I don't know what's displayed in locales like Chinese or Arabic, though. Sebastian

:sebo, can you share how you tested that (url? browser/os?)?

Ah, sorry, for not providing that info! I am using a German Windows 10, URL is http://jsbin.com/miyeguzaye/edit?html,output. Browsers: Chrome 55, Edge 38, Opera 42 (all de-DE). The display is the same across all of them, i.e. "tt.mm.jjjj". In Opera 44 with en-US as locale the placeholder looks like "mm/dd/yyyy". So there this obviously depends on the locale of the browser. For Edge you need to change the system language. E.g. when you change it to Spanish, it shows "mm/dd/aaaa" as placeholder (obviously for *m*es, *d*ía and *a*ño). Sebastian

Excellent, thank you. I run it via several languages and it seems that: 1) For latin script LTR they do first letter of the word repeated 4 or 2 times (so "yyyy/mm/dd" for en or "rrrr.mm.dd" for pl) 2) For chinese they use words "year", "month" and "day" from CLDR 3) For arabic they are trying to use words "year", "month" and "day" but they mess with directionality and end up using LTR. So, I think it's fine to go for localization approach and let localizers pick what placeholder term they want. We can expect that most latin will go for first-letter approach, but non-latin for the whole word. NI'ing jungshik about bug in Chrome.

(Commenting on User Story) > As a web author, I'd like Firefox to support these input types: date, > datetime, datetime-local, month, time, week > > More explanations in http://www.w3schools.com/tags/att_input_type.asp > > UX spec: > https://mozilla.invisionapp.com/share/GU7VBIB4D#/screens/171886633 Added the link to the living UX spec. Major modification is to mark the backlogged items with red square.

Cleraing ni as we've gone through the spec in a face to face meeting. Thanks Morpheus!