1348052 - vertical scroll buttons on the datetime picker are opposed to the natural behavior of scrolling buttons

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Tomer Cohen :tomer]

The DOM controls for dates and times are featuring an option to select months and years, hours and minutes. These two widgets has an option to scroll between values using the wheel, dragging and buttons. I suggest reversing the buttons behavior, as top supposed to mean previous and the bottom should mean next.

Expected result: The buttons should behave as a scrolling buttons.

data:text/html,<input type=date>
data:text/html,<input type=time>

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

oh yes, they definitely are weird.

Comment 3

[Scott Wu [:scottwu]]

Morpheus, do you think the change is reasonable from UX point of view?

Comment 4

[Ian Moody [:Kwan] (UTC+1)]

I already have the required change in my local repo, so publishing it for if it does go ahead (assuming there are no complications like platform-specific behaviour).
Bug 1347621 comment #0 and bug 1347621 comment #1 have some of my thinking on the matter.

Comment 5

[Ian Moody [:Kwan] (UTC+1)]

Attachment: Bug 1348052 - Change the scroll buttons in the datetime picker to move the view, not the list.

Review commit: https://reviewboard.mozilla.org/r/121540/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/121540/

Comment 6

[Morpheus Chen [:morpheus] UX]

Attachment: Natural Scroll vs Reverse Scroll.png

Thanks for bringing out this issue. In fact, we had the discussion before and realized it had been a long-lasting debate. Here I'll try to elaborate and make it long story short. 

First, the reason why you think the buttons are opposite is that you've got used to Reverse scrolling, which is exactly contrary to Natural scrolling. (You can find more context here: https://www.slashgear.com/the-subjectivity-of-natural-scrolling-05169915/) 

However, the key reason pushed us to go Natural scrolling for date/time picker was CONSISTENCY.(See attachment) By applying Natural scrolling, we can: 1. ensure the scrolling mechanism for the buttons and keyboard(up/down key) is the same; 2. align with the current scrolling mechanism of touchscreen products; 3. apply the "natural" way to move things. Besides, users who are "Reverse scrollers" can quickly adapt to the natural scrolling.

Nevertheless, we realize that almost 90% of Firefox users are Windows users, and Reverse scrolling is the default setting in Windows. That means, 90% of Firefox users will feel weird whenever they encounter and click the buttons or tap up/down key in the month/year scroller. However, we don't recommend simply reversing the buttons since this would get users more confused when using up/down key to scroll.  

Therefore, we tried to come up with two proposals which apply Reverse scrolling and are waiting for developers for feasibility testing:
1. Just modify the list of the month and year to be opposite, which means the digits will vertically go from the maximum to minimum. We'll test on prototype if that's unreasonable for users. 
2. When users are in month/year scroller and scroll by the up/down key on the keyboard, up/down key scrolls the list to move down/up the content instead of adding/subtracting numbers in the input field. FYI, The mechanism is exactly same way Windows Edge browser does.

If these proposals aren't feasible, then we would prefer to keep the current design to ensure the consistency. Please let us know if any better ideas, thanks.

Comment 7

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Per UX perspective in comment 6, current behavior is by design and I don't see strong reason to have it changed now.

Comment 8

[Tomer Cohen :tomer]

(In reply to Morpheus Chen [:morpheus]  UX from comment #6)
> 2. When users are in month/year scroller and scroll by the up/down key on
> the keyboard, up/down key scrolls the list to move down/up the content
> instead of adding/subtracting numbers in the input field. FYI, The mechanism
> is exactly same way Windows Edge browser does.
> 
> If these proposals aren't feasible, then we would prefer to keep the current
> design to ensure the consistency. Please let us know if any better ideas,
> thanks.

The second proposal sounds good to me, and if it is kept hidden behind a pref, it would be possible to make it the default behavior to Windows and Linux users, while keeping it as-is on Mac.

Comment 9

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Reopen to leave it as backlog item, but I wouldn't consider it as a hard blocker for releasing.
So far the ultimate plan (consolidating comment 6 and comment 8) seems to be: 

A. keep current behavior on Mac, but on Linux/Windows: When users are in month/year scroller and scroll by the up/down key on the keyboard, up/down key scrolls the list to move down/up the content instead of adding/subtracting numbers in the input field. 

B. make the behavior in A as configurable pref

Comment 10

[Scott Wu [:scottwu]]

Comment on attachment 8848646 [details]
Bug 1348052 - Change the scroll buttons in the datetime picker to move the view, not the list.

Since we are moving forward with the second proposal in comment 6, I think it's okay to land this patch first, and work on reversing keyboard input in bug 1361950.

Comment 11

[Scott Wu [:scottwu]]

Comment on attachment 8848646 [details]
Bug 1348052 - Change the scroll buttons in the datetime picker to move the view, not the list.

Mike, we are reversing the arrow keys directions to make it more intuitive for Windows users. Thanks!

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8848646 [details]
Bug 1348052 - Change the scroll buttons in the datetime picker to move the view, not the list.

https://reviewboard.mozilla.org/r/121540/#review146416

This looks okay, but I don't see anything Windows-specific about this branch of the code... this is going to affect all platforms. Is that intended?

Comment 13

[Scott Wu [:scottwu]]

Yes we've thought of making the directions OS specific. On OSX the default is "Natural" scrolling, which works the same way on touch screens. However some people (myself included) prefer the old way and would reverse the scrolling direction, so the generalization doesn't always work. Morpheus from UX would prefer if we can change the directions based on whether users have "Natural" or "Reverse" scrolling, would you happen to know a way to do that?

What is clear so far is that this patch would satisfy the expectation of the majority of our users (who are on Windows), and maybe we can optimize the experience for Mac users down the road.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8fb7e770d89f
Change the scroll buttons in the datetime picker to move the view, not the list. r=mconley

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8fb7e770d89f

Comment 16

[roxleitan]

Verified fixed on the latest Nightly 55.0a1 (2017-06-07) on Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.12.