Unexpected UX: Overlay popover window, scroll wheel selects controls, not scrolls #62777

New Issue

Ian Finnimore · 2019-03-20T14:38:56+01:00

Ian Finnimore commented

2019-03-20 14:38:56 +01:00

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 650/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13

Blender Version
Broken: version: 2.80 (sub 48), branch: master, commit date: 2019-03-15 00:41, hash: 388ff003e2
Worked: (optional)

Short description of error
The overlays popover window has enough that it runs into the bottom screen edge even at 1920x1080 with a marker indicating more below (normal).

Scroll wheel does not directly scroll the window, but sets mouse focus and subtle highlights the next edit control (hard to notice on check boxes). This highlighting is indicating mouse input capture only, as keyboard focus has not been moved to the control.

This scroll wheel select wraps around the list of controls, selecting the last control when running off top, and first when running off bottom.

This results in the unexpected experience behavior where the scroll wheel does not do consistent scrolling.

Examples of inconsistencies:
With the Overlays popover window freshly opened for each trial, try the following:

scroll wheel forward (UP) and the overlay window visible portion shifts DOWN to show the Freestyle section (Bottom).

scroll wheel back (DOWN), and no scrolling happens (mouse focus is moving between controls, subtle highlights only on check boxes, no highlights on enabled toggle buttons). scroll down long enough and eventually the hidden controls scroll into view. Continue scrolling down, which is highly likely since the wheel appears to be minimally reactive, and when the focus moves off the last control suddenly (and very jarring experience) the top of the popover window appears.

Recommended correction:
I realize since the popover does not have a scroll bar, the mechanics of scrolling were implemented differently, such as "shift control with focus into view".

Retaining that constraint, I would recommend the following:

Scroll Up/Down selects the first obscured control in the scroll direction, not the next adjacent control.
If there is no obscured control in the requested direction, do nothing (no wrapping)

Implemented in this manner, UX would match to expectations of scrolling the window, without the change of adding visible scroll bars.

**System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 650/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13 **Blender Version** Broken: version: 2.80 (sub 48), branch: master, commit date: 2019-03-15 00:41, hash: `388ff003e2` Worked: (optional) **Short description of error** The overlays popover window has enough that it runs into the bottom screen edge even at 1920x1080 with a marker indicating more below (normal). Scroll wheel does not directly scroll the window, but sets mouse focus and subtle highlights the next edit control (hard to notice on check boxes). This highlighting is indicating mouse input capture only, as keyboard focus has not been moved to the control. This scroll wheel select wraps around the list of controls, selecting the last control when running off top, and first when running off bottom. This results in the unexpected experience behavior where the scroll wheel does not do consistent scrolling. Examples of inconsistencies: With the Overlays popover window freshly opened for each trial, try the following: scroll wheel forward (UP) and the overlay window visible portion shifts DOWN to show the Freestyle section (Bottom). scroll wheel back (DOWN), and no scrolling happens (mouse focus is moving between controls, subtle highlights only on check boxes, no highlights on enabled toggle buttons). scroll down long enough and eventually the hidden controls scroll into view. Continue scrolling down, which is highly likely since the wheel appears to be minimally reactive, and when the focus moves off the last control suddenly (and very jarring experience) the top of the popover window appears. Recommended correction: I realize since the popover does not have a scroll bar, the mechanics of scrolling were implemented differently, such as "shift control with focus into view". Retaining that constraint, I would recommend the following: 1) Scroll Up/Down selects the first obscured control in the scroll direction, not the next adjacent control. 2) If there is no obscured control in the requested direction, do nothing (no wrapping) Implemented in this manner, UX would match to expectations of scrolling the window, without the change of adding visible scroll bars.

Ian Finnimore commented

2019-03-20 14:38:56 +01:00

Added subscriber: @IanFinn

blender-admin commented

2019-03-21 01:37:44 +01:00

This issue was referenced by 06585e0b13

This issue was referenced by 06585e0b133f1e94f0042d5f42da5810ebce4682

Campbell Barton commented

2019-03-21 01:43:36 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-03-21 01:43:36 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Unexpected UX: Overlay popover window, scroll wheel selects controls, not scrolls #62777