Scrollbars Design #69391

Open
opened 2019-09-01 21:38:19 +02:00 by William Reynish · 28 comments

We think we can make a few improvements to how scrollbars look and work.

Larger size
In Blender 2.8, we made it so scrollbars don't make the content jump around as they appear and disappear. However, to do this, scrollbars had to be made very thin.

We would like to make the scrollbars just a tad wider:

Before/after:
Screenshot 2019-09-01 at 21.13.37.png

This requires creating a little bit of extra space always, so scrollbars have enough space to appear & disappear inside this gutter area.

Unified scrollbars
We can also use this opportunity to unify scrollbars. Currently, list view scrollbars are huge, while the regular 2D view scrollbars are very thin. Here, both are unified:

Before/after
Screenshot 2019-09-01 at 21.17.05.png

Thickness fading
It's also desirable to keep the scrollbars always visible, rather than making the fade away. This makes them more practical for use with devices with no hover state (some tablets), and also for users to see at a glance where in a list they are.

We can keep these at a very small width. When the cursor is close, we can then make them much more prominent:

Screenshot 2020-01-12 at 16.58.37.png

We think we can make a few improvements to how scrollbars look and work. **Larger size** In Blender 2.8, we made it so scrollbars don't make the content jump around as they appear and disappear. However, to do this, scrollbars had to be made very thin. We would like to make the scrollbars just a tad wider: Before/after: ![Screenshot 2019-09-01 at 21.13.37.png](https://archive.blender.org/developer/F7713296/Screenshot_2019-09-01_at_21.13.37.png) This requires creating a little bit of extra space always, so scrollbars have enough space to appear & disappear inside this gutter area. **Unified scrollbars** We can also use this opportunity to unify scrollbars. Currently, list view scrollbars are huge, while the regular 2D view scrollbars are very thin. Here, both are unified: Before/after ![Screenshot 2019-09-01 at 21.17.05.png](https://archive.blender.org/developer/F7713298/Screenshot_2019-09-01_at_21.17.05.png) **Thickness fading** It's also desirable to keep the scrollbars always visible, rather than making the fade away. This makes them more practical for use with devices with no hover state (some tablets), and also for users to see at a glance where in a list they are. We can keep these at a very small width. When the cursor is close, we can then make them much more prominent: ![Screenshot 2020-01-12 at 16.58.37.png](https://archive.blender.org/developer/F8273021/Screenshot_2020-01-12_at_16.58.37.png)
Julian Eisel was assigned by William Reynish 2019-09-01 21:38:19 +02:00
Added subscribers: @WilliamReynish, @semaphore, @mendio, @0o00o0oo, @antoniov, @T.R.O.Nunes, @Ehab, @BartekMoniewski, @DuarteRamos, @MaciejJutrzenka, @Znio.G, @brecht, @Sergey, @dfelinto, @mont29, @ideasman42

can we expose this setting? so it is possible to set it up by user?

can we expose this setting? so it is possible to set it up by user?
Member

Added subscriber: @Harley

Added subscriber: @Harley
Member

Why not change the width of the active versus inactive scrollbar? This way you can get away with a narrower gutter since it would look okay to have the active scrollbar take the entire gutter space.

ScrollBars.png

Why not change the width of the active versus inactive scrollbar? This way you can get away with a narrower gutter since it would look okay to have the active scrollbar take the entire gutter space. ![ScrollBars.png](https://archive.blender.org/developer/F7713341/ScrollBars.png)

@Harley Yes that might be ok too. The scrollbars then mainly serve just as indicator lines when not in use.

That solution would work without requiring extra gutter space, which is nice, but may be a bit more jarring if scrollbars change size.

@Harley Yes that might be ok too. The scrollbars then mainly serve just as indicator lines when not in use. That solution would work without requiring extra gutter space, which is nice, but may be a bit more jarring if scrollbars change size.

Added subscriber: @ThinkingPolygons

Added subscriber: @ThinkingPolygons

In #69391#766999, @Harley wrote:
Why not change the width of the active versus inactive scrollbar? This way you can get away with a narrower gutter since it would look okay to have the active scrollbar take the entire gutter space.

Personally I prefer the original proposal. Scrollbars changing sizes would be too distracting IMHO.

Either way, it would be an improvement from what we have currently.

> In #69391#766999, @Harley wrote: > Why not change the width of the active versus inactive scrollbar? This way you can get away with a narrower gutter since it would look okay to have the active scrollbar take the entire gutter space. Personally I prefer the original proposal. Scrollbars changing sizes would be too distracting IMHO. Either way, it would be an improvement from what we have currently.

Added subscriber: @BugFinder

Added subscriber: @BugFinder

I'm all for bringing back the scrollbars usability, now (nearly) unusable - for me, at least.
And for giving the users the ability to set the width/height (depending on the orientation of the scrollbar) to taste.

I'm all for bringing back the scrollbars usability, now (nearly) unusable - for me, at least. And for giving the users the ability to set the width/height (depending on the orientation of the scrollbar) to taste.

Added subscriber: @nokipaike

Added subscriber: @nokipaike

I like how scroll bars currently work, I find it beautiful and functional as I get closer with the cursor, they stand out ...
I also like that they don't take up too much space when we don't need them.

I like how scroll bars currently work, I find it beautiful and functional as I get closer with the cursor, they stand out ... I also like that they don't take up too much space when we don't need them.

I really HATE the new scrollbars. I can HARDLY catch them.
It's like shooting a MOSQUITO with a BAZOOKA.

But if you like 1 px wide scrollbars...
The more I get older, the less I understand youngsters.

I really HATE the new scrollbars. I can HARDLY catch them. It's like shooting a MOSQUITO with a BAZOOKA. But if you like 1 px wide scrollbars... The more I get older, the less I understand youngsters.
Member

Added subscriber: @ankitm

Added subscriber: @ankitm
Member

Can it be done like in macOS? I just received that the primary goal is not to chase OS' behaviour, but if it works, it can be considered.

The scrollbar appears only when there is an attempt to scroll. Even if I put the two fingers on the touchpad, apps would show scrollbars. Lifting the fingers hides scrollbar after 2-3 seconds.

However, it poses a bit of a problem with laptops which don't have multi-finger gestures.(they scroll by holding left key down and then dragging the bar up/down)

Can it be done like in macOS? I just received that the primary goal is not to chase OS' behaviour, but if it works, it can be considered. The scrollbar appears only when there is an attempt to scroll. Even if I put the two fingers on the touchpad, apps would show scrollbars. Lifting the fingers hides scrollbar after 2-3 seconds. However, it poses a bit of a problem with laptops which don't have multi-finger gestures.(they scroll by holding left key down and then dragging the bar up/down)

Added subscriber: @joules-2

Added subscriber: @joules-2

In #69391#768823, @nokipaike wrote:
I like how scroll bars currently work, I find it beautiful and functional as I get closer with the cursor, they stand out ...
I also like that they don't take up too much space when we don't need them.

I have to agree. Maybe users aren't aware of scrolling options (Hold Middle MB). Having a permanent gutter for the scroll bar would take up space. Managing space with addons and lists and maximizing space could be important for some people.

The UIList scrollbar is too wide currently, and a scroll bar could only be "visually" necessary for large lists, a few rows beyond the UL with a scrollbar as a visual hint, won't always translate it into being actually used (i.e. row is in view anyway or the next row is a few mousewheel clicks away).
For large screens and for those that require the scrollbar, then maybe a increase the scrollbar width by a factor with Resolution Scale (I currently use 1.50 at 1440p).

The question about what percentage of users are inconvenienced with current state of the UI and UX are enough to accommodate as opposed with changes that would upset a larger percentage of those that are happy with the way things are.

I just wanted to make that clear as my addon uses UILists and the wide scrollbar seems out of place and is jarring when it pops in to offset items in the list (even more jarring when in a popup).
I would prefer the scroll bar stay the same as seen with properties and against it permanently visible as it make the UI less appealing.
I would prefer the UIList scrollbar have similar behavior and to me the most pressing issue.

As for tablet:
I have a Huion tablet and the pen button is the MMB (hold for scroll), what is the percentages of users that have a tablet and the percentage of that those that have a table that can't scroll?
Compared to the percentage of users that don't have a tablet?

In summary I don't like any of the proposals. Make UILists scrollbar behave like it does everywhere else as it is.

> In #69391#768823, @nokipaike wrote: > I like how scroll bars currently work, I find it beautiful and functional as I get closer with the cursor, they stand out ... > I also like that they don't take up too much space when we don't need them. I have to agree. Maybe users aren't aware of scrolling options (Hold Middle MB). Having a permanent gutter for the scroll bar would take up space. Managing space with addons and lists and maximizing space could be important for some people. The UIList scrollbar is too wide currently, and a scroll bar could only be "visually" necessary for large lists, a few rows beyond the UL with a scrollbar as a visual hint, won't always translate it into being actually used (i.e. row is in view anyway or the next row is a few mousewheel clicks away). For large screens and for those that require the scrollbar, then maybe a increase the scrollbar width by a factor with Resolution Scale (I currently use 1.50 at 1440p). The question about what percentage of users are inconvenienced with current state of the UI and UX are enough to accommodate as opposed with changes that would upset a larger percentage of those that are happy with the way things are. I just wanted to make that clear as my addon uses UILists and the wide scrollbar seems out of place and is jarring when it pops in to offset items in the list (even more jarring when in a popup). I would prefer the scroll bar stay the same as seen with properties and against it permanently visible as it make the UI less appealing. I would prefer the UIList scrollbar have similar behavior and to me the most pressing issue. As for tablet: I have a Huion tablet and the pen button is the MMB (hold for scroll), what is the percentages of users that have a tablet and the percentage of that those that have a table that can't scroll? Compared to the percentage of users that don't have a tablet? In summary I don't like any of the proposals. Make UILists scrollbar behave like it does everywhere else as it is.
Member

Added subscriber: @JulienKaspar

Added subscriber: @JulienKaspar
Member

I am all for this new desing! I think fading the color is a way better method than making the scrollbar thinner or making it disappear entirely.
It makes it much more inviting to use when scrolling massively long lists, which I find way more comfortable than using the MMB drag, which is more convinient for smaller scrolling steps.

! In #69391#815867, @joules-2 wrote:
In #69391#768823, @nokipaike wrote:
I like how scroll bars currently work, I find it beautiful and functional as I get closer with the cursor, they stand out ...
I also like that they don't take up too much space when we don't need them.

I have to disagree with this argument since the scrollbar will always have to take up the amont of space that it has when hovering near it. No space is actually ever saved by making it dynamically thinner. Usually what happens is that the there is a big empty space next to the scrollbar anyway or that when hovering near it, it will start overlapping other UI elements when it becomes thicker.

I am all for this new desing! I think fading the color is a way better method than making the scrollbar thinner or making it disappear entirely. It makes it much more inviting to use when scrolling massively long lists, which I find way more comfortable than using the MMB drag, which is more convinient for smaller scrolling steps. >! In #69391#815867, @joules-2 wrote: > In #69391#768823, @nokipaike wrote: > I like how scroll bars currently work, I find it beautiful and functional as I get closer with the cursor, they stand out ... > I also like that they don't take up too much space when we don't need them. I have to disagree with this argument since the scrollbar will always have to take up the amont of space that it has when hovering near it. No space is actually ever saved by making it dynamically thinner. Usually what happens is that the there is a big empty space next to the scrollbar anyway or that when hovering near it, it will start overlapping other UI elements when it becomes thicker.

I guess I see issues with UILists with 2 or more columns, screen factor is 1.50

I guess what worries me is this scenario:
smalllist.png
A scroll bar isn't necessary here but already it is hard to make out the unique naming (each is appended with .xxx etc) due to space. A permanent space for a scroll bar, when not needed would limit it even further.

What we have currently on larger lists:
largeList.png
Popping in and offsetting the items is jarring. But also, the list isn't long enough, so more of a visual cue that more items exist in the list than anything else (row needed is in view). With long lists a scrollbar is a great option, sure. My argument is, but how often is that the case to make it a permanent fixture? Which is why an an overlayed scrollbar (that you currently have) is the best middle ground.

wide vs narrow.

Why I would prefer a narrower scrollbar in line with the current scrollbar design elsewhere:
preferedUIListScrollbar.png
Only a small adjustment in my list design would be needed to avoid overlap.

I saw the proposal as a permanent allocation for a scrollbar throughout the UI, even when needed or not (so wouldn't appear) that I'm not a fan of right now.
I guess I'm happy with the current design elsewhere in the UI and would like that design to be uni-formal to include how they behave with UILists as well.
I guess I'm warning against drastic change to the scrollbar through the entire UI. But perhaps need more convincing :)

I guess I see issues with UILists with 2 or more columns, screen factor is 1.50 I guess what worries me is this scenario: ![smalllist.png](https://archive.blender.org/developer/F8170846/smalllist.png) A scroll bar isn't necessary here but already it is hard to make out the unique naming (each is appended with .xxx etc) due to space. A permanent space for a scroll bar, when not needed would limit it even further. What we have currently on larger lists: ![largeList.png](https://archive.blender.org/developer/F8170859/largeList.png) Popping in and offsetting the items is jarring. But also, the list isn't long enough, so more of a visual cue that more items exist in the list than anything else (row needed is in view). With long lists a scrollbar is a great option, sure. My argument is, but how often is that the case to make it a permanent fixture? Which is why an an overlayed scrollbar (that you currently have) is the best middle ground. wide vs narrow. Why I would prefer a narrower scrollbar in line with the current scrollbar design elsewhere: ![preferedUIListScrollbar.png](https://archive.blender.org/developer/F8170873/preferedUIListScrollbar.png) Only a small adjustment in my list design would be needed to avoid overlap. I saw the proposal as a permanent allocation for a scrollbar throughout the UI, even when needed or not (so wouldn't appear) that I'm not a fan of right now. I guess I'm happy with the current design elsewhere in the UI and would like that design to be uni-formal to include how they behave with UILists as well. I guess I'm warning against drastic change to the scrollbar through the entire UI. But perhaps need more convincing :)
Member

I added a patch that can be tried that does a few things mentioned:

  • about a third wider.
  • always shown, but at a smaller size and lowered opacity
  • zooms to larger size and full opacity as the mouse approaches it

https://developer.blender.org/D6505

I added a patch that can be tried that does a few things mentioned: - about a third wider. - always shown, but at a smaller size and lowered opacity - zooms to larger size and full opacity as the mouse approaches it https://developer.blender.org/D6505

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Added subscriber: @AlexeyPerminov

Added subscriber: @AlexeyPerminov

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

In #69391#840587, @Harley wrote:
I added a patch that can be tried that does a few things mentioned

Thank you so much for this!
Now position in long lists, like user prefs or outliner can be properly handled.

> In #69391#840587, @Harley wrote: > I added a patch that can be tried that does a few things mentioned Thank you so much for this! Now position in long lists, like user prefs or outliner can be properly handled.

Added subscriber: @YegorSmirnov

Added subscriber: @YegorSmirnov

Is it active?
We still need to properly handle the location in long lists ...

Is it active? We still need to properly handle the location in long lists ...

Added subscriber: @Nominous

Added subscriber: @Nominous

This issue was referenced by 6243972319

This issue was referenced by 6243972319289d86c70ce9946d10909e7eddfdaf
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:25:12 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
15 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#69391
No description provided.