Thanks @violetto!

I'll supply the icon and more details soon

@Prtksxna, let me know when you feel like it's at a place where you can share with me.

It's difficult to feel how it's like with only static images. I'd want to see how this interact and we can make changes wherever necessary. I expect things to not work and feel perfectly the first round. Keep me updated, same goes to other controls you'll be implementing.

@Prtksxna, let me know when you feel like it's at a place where you can share with me.

@matmarex will be implementing this.

I like this. I started working on it, I'll have a demo with this design up for you to review later today. Some thoughts:

• I think the calendar should always display 6 weeks in a month. A month can span anywhere between 4 and 6 weeks, it'll be neater if the size of the calendar doesn't change between months. (This would also make it more convenient to use the calendar "standalone", without the text field, if we ever need that.)
• The date formatting library we have available (Moment.js) uses "Su Mo Tu We Th Fr Sa" rather than "S M T W T F S" for day abbreviations, so the widget will also use that.
• When editing the text field, I think we should use a single field in the YYYY-MM-DD date format rather than "human-readable" format split among separate field, to ease rapid data entry. I'll implement keyboard arrow navigation on the calendar itself, which should suffice for easy switching to tomorrow/yesterday etc.
• The mockups only have a "month" view, which would make choosing a date that is, say, ten years ago, rather labor-intensive. In my research I've seen some pickers with "year" and "decade" views too, I'll try to implement this.

What do you think?

Demo of the calendar (without the input field yet, just the calendar) currently available at http://users.v-lo.krakow.pl/~matmarex/testwiki/index.php/Special:BlankPage (use login/password of testwiki/testwiki if asked). I'd especially welcome input about the "year" and "decade" UX (available via 'up' arrow).

• I think the calendar should always display 6 weeks in a month. A month can span anywhere between 4 and 6 weeks, it'll be neater if the size of the calendar doesn't change between months. (This would also make it more convenient to use the calendar "standalone", without the text field, if we ever need that.)

Let's try this. While you implement, I'll see how we can visualize this view.

• The date formatting library we have available (Moment.js) uses "Su Mo Tu We Th Fr Sa" rather than "S M T W T F S" for day abbreviations, so the widget will also use that.

I don't mind this.

• When editing the text field, I think we should use a single field in the YYYY-MM-DD date format rather than "human-readable" format split among separate field, to ease rapid data entry. I'll implement keyboard arrow navigation on the calendar itself, which should suffice for easy switching to tomorrow/yesterday etc.

The label when not expanded should be human readable with both the day and date info. Changing the order after the menu has been clicked to expand will confuse. Based on what you were suggesting, it sounds like making it easy for users to select from the calendar is most important. Let's make that happen, we'll keep the day/date format the same because it's more important that it's human readable but also easy to change via text field, although it might not be super easy for rapid entry.

• The mockups only have a "month" view, which would make choosing a date that is, say, ten years ago, rather labor-intensive. In my research I've seen some pickers with "year" and "decade" views too, I'll try to implement this.

I was hoping with the year text field, our users will be able to enter the year. When the year has been entered, users will be able to see the month or months in that year (depending on their current view of the cal) based on the year entered.

I wasn't able to view the link, it says: This page is intentionally left blank.

I wasn't able to view the link, it says: This page is intentionally left blank.

Hmm, it works for me. Can you try again? The message should be replaced by some (mostly unstyled) calendars.

I see what you meant now. I've revised the design after looking at what you've done here.

Scrolling up/down will reveal more following/previous months/years. This gives users a nicer experience and easier to navigate by mouse scroll (even better on touch screens) to access following / previous month/years instead of only clicking on next/previous buttons. I've also added a "select today's date" in between the next/prev buttons.

Going "back" from the "days" calendar view gives you the option of changing "month." Going "back" from the "months" calendar view gives you the option of changing "year." This gives our users the flexibility of going back to change an information instead of a fixed workflow of selecting year > month > day.

I like the experience of the workflow you showed. When we have users start from scratch in selecting a date, we'll do what you did here—first select a year, followed by month and day.

p/s: I'm still not in love with the month view on this mock up. Feel free to use this while I keep thinking.

@violetto just my two cents: blue on blue day/date/month selection/current one? Fails on colour contrast.

Unfortunately. Especially when it's set on a regular weight.

It's totally on my radar though. We haven't thought of it all yet.

Obligatory: https://twitter.com/amazingmap/status/599931666803597312/photo/1 ;-)

I updated the demo at http://users.v-lo.krakow.pl/~matmarex/testwiki/index.php/Special:BlankPage with complete widgets with the input field (https://gerrit.wikimedia.org/r/216375). I didn't incorporate the new mockups yet, although I mostly like them. It currently doesn't exactly implement the workflow described here, but rather my initial intuition of what would work well for me, as a programmer and non-native English speaker. Try pressing "Tab" to focus the calendar rather than the text field, and use arrow keys to move around. Try it out in a different language too: http://users.v-lo.krakow.pl/~matmarex/testwiki/index.php/Special:BlankPage?uselang=es and others.

I also created http://users.v-lo.krakow.pl/~matmarex/testwiki/index.php/Special:BlankPage?anomie which demoes @Anomie's version of this, https://gerrit.wikimedia.org/r/216909. (We didn't know that the other was working on this at the same time.) The behavior is a lot closer to the mockups here. Try scrolling the mouse wheel over different fields, or pressing arrow keys when they are focussed.

I'm curious what you all think.

@matmarex: FYI, I just submitted a new patchset for mine. Changes:

• Clean up some issues with not removing the calendar popup when tabbing to a different widget.
• Make the calendar more usable via the keyboard if you tab to it (since I was impressed when I tried that with yours).

BTW, I noticed on yours that moving to the next month with the keyboard animates while moving to the previous month doesn't.

As for other UI comparisons, I see yours has a mode that's like <input type="month"> (demoed), while mine has modes for <input type="time"> and <input type="datetime">/<input type="datetime-local"> (not demoed?).

I'm curious what you all think.

These are both awesome. I'm looking forward to it!

Re: accessibility - Do either of them have pros/cons over the other, for screenreader users?

Re: MMDDYYYY in uselang=en (vs. DDMMYYYY) - would it be possible to get these to respect the userpreference for mw-prefsection-rendering-dateformat at least? The default in log feeds (RC/history/etc) is DDMMYYYY.

Re: MMDDYYYY in uselang=en (vs. DDMMYYYY) - would it be possible to get these to respect the userpreference for mw-prefsection-rendering-dateformat at least?

For mine, it's just a matter of defining format-strings for both ways (which could be done in various ways) then picking one from the MW code after checking the preference.

Theoretically the same could be done for Matma's, but at the moment he's hard-coding something based on moment.js's localizations which might make it more difficult.

@matmarex Just for clarification for others, the input fields don't show currently up on Chrome, only on Firefox.

Updated the demo.

• http://users.v-lo.krakow.pl/~matmarex/testwiki/index.php/Special:BlankPage
• http://users.v-lo.krakow.pl/~matmarex/testwiki/index.php/Special:BlankPage?anomie (now with previously-missing modes)

@Volker_E, the widgets should work on all modern browsers. The setup I'm running this demo on is kind of lame, try refreshing once or twice if it doesn't load at first :/

Ideally it should be sensitive to our users' region and to determine the date/time format it so it's more familiar to them. But if that's not possible and if the default in log feeds like @Quiddity mentioned is DD MM YY, we'll stick with DD MM YY.

DD MM YY
Tuesday, 4 Jan 2004

MM DD YY
Tuesday, Jan 4, 2004

Thoughts on the first link.

Here's a video to help describe some of my thoughts and observations:

• Date changes from "Tue, Jun 16, 2015" to "2015-06-16" on click. What do you guys think?
• I'm sure this wasn't intended but currently with keyboard navigation, when the user reaches the topmost date in the column, it moves to the previous/next month instead of navigating to the previous/next date (unless of course it's the first or the last date of the month, which in that case, should move to the last day in the prev month / first day of the following month). It navigates correctly with left/right though, so just the up/down with the issue atm.
• When navigating with keyboard and when the menu is in focus, it should open the calendar automatically without having to hit "Enter." Similarly, when user has selected a date, it should hide the calendar automatically.
• The way you make the "header" within the calendar to change when the year and month have been selected, that makes it so clear to the user that they're going through a workflow and animation is helpful to navigate with arrows if they need to go back. Very minimal. What did you think of the idea of scrolling up/down to see prev/next months and left for month and left again for year?

On second link, I still have no luck with this. Had it the first time I open it but not anymore.

On second link, I still have no luck with this. Had it the first time I open it but not anymore.

In case it works better, I stuck the oojs-ui demo page patched with my version at https://tools.wmflabs.org/anomiebot/oojs-ui/demos/index.html#widgets-mediawiki-vector-ltr for the moment. Search for "DateTimeInputWidget".

@Anomie, link worked! Thanks.

Clicking on the menu reveals the calendar and highlights the area where you just clicked (but if you clicked outside of the text, it will highlight “Month” automatically). The current date will also show as selected in the calendar.

When the “date” within the calendar is selected at the same time as when the “date” within the menu is highlighted, keyboard navigation within the calendar is opposite as what you would expect. Pressing “down” moves the focus to the next date. Pressing “up” moves the focus to the previous date. This makes sense if the user is intending to change the date within the menu and not in the calendar. To avoid this confusion, we can:

• Include a calendar icon at the right side of the menu. The calendar will only expand when the calendar icon is clicked on.
• If the user clicked on DD or MM or YYYY, the calendar won’t expand but will highlight whicever selected and users will be able to change the information by up/down buttons or text input. The mouse wheel is such a bonus, this makes changing things like YYYY so much faster.

Both of these versions are very similar. We should combine and improve the details.

but if you clicked outside of the text, it will highlight “Month” automatically

More specifically, it highlights the first editable field in the widget.

When the “date” within the calendar is selected at the same time as when the “date” within the menu is highlighted, keyboard navigation within the calendar is opposite as what you would expect. Pressing “down” moves the focus to the next date. Pressing “up” moves the focus to the previous date. This makes sense if the user is intending to change the date within the menu and not in the calendar. To avoid this confusion, we can:

• Include a calendar icon at the right side of the menu. The calendar will only expand when the calendar icon is clicked on.
• If the user clicked on DD or MM or YYYY, the calendar won’t expand but will highlight whicever selected and users will be able to change the information by up/down buttons or text input. The mouse wheel is such a bonus, this makes changing things like YYYY so much faster.

Another option would be to just invert the behavior of up and down in the fields, i.e. redefine "up" here from "increase this number" to "make this earlier in chronological order". We'd probably want to do the same for the mouse wheel for consistency.

Another option would be to just invert the behavior of up and down in the fields, i.e. redefine "up" here from "increase this number" to "make this earlier in chronological order". We'd probably want to do the same for the mouse wheel for consistency.

This would help.

Moving up in the calendar is different. It means moving to the week before. For example, moving up from "25" should take me to "18."

@Anomie Is the link that you've provided above still up-to-date?

@Anomie Is the link that you've provided above still up-to-date?

I just updated it to be sure.

Thanks for updating.

May and I are agreeing, that missing year and month views are no blockers for now from UI standardization.
Depending on what code route we're taking, we'd suggest to postpone development of those, after further user research has been accomplished or after we receive user feedback saying, that they are actually missing those -- in order to lower development power needed

Update: Sorry, that was my fault, there was some funny miscommunication. From UI Standardization pov there definitely should be month and year pickers available.