Scroll bar should not overlap content

[SetTrend]

A Scroll Bar Should not Overlap A Component's Content

Describe the bug

When a ScrollViewer scroll bar is displayed, it overlaps the component's content.

This is unexpected behaviour, potentially leading to information being hidden.

Steps to reproduce the bug

I added a GridView component to an UWP Page, similar to this:

<Page>
  <GridView ItemsSource="{x:Bind CdList}">
  ...
  </GridView>
</Page>

When I change the window size, the GridView's vertical scrollbar partially hides/overlaps the rightmost items in the GridView before GridView wraps the items appropriately:

Expected behavior

The ScrollViewer's ItemPresenter should be a sibling of the ScrollViewer's scroll bars, so, as soon as any of the scroll bars is displayed, the ItemPresenter size should shrink appropriately to spread across only the area left/above the scroll bars.

Scroll bars are supposed to appear outside the presenter area, not within.

Version Info

Windows 10 version	Saw the problem?
October 2020 Update (xxxxx)	Yes
May 2020 Update (19041)
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

[robloo]

When a ScrollViewer scroll bar is displayed, it overlaps the component's content. This is unexpected behaviour, potentially leading to information being hidden.

In classic desktop scenarios, yes, it's expected for the scroll bar to be to the right of the content and never overlap. If you are coming over from WPF this is strange behavior for sure.

However, remember UWP was designed to support mobile devices first. Mobile devices are very limited in horizontal size. This is why the mobile convention soon became for scroll bars to appear on top of content and automatically switch between a 'traditional' and minimized 'panning' view. Actually, Apple I believe was the first to design scroll bars that behaved this way on the iPhone and everyone just followed that idea. Scroll bars are now expected to automatically hide themselves when not scrolling and only show a small semi-transparent indicator.

So I disagree that it is unexpected -- it is expected and necessary from a mobile standpoint. It is also the latest design convention. It may be best to simply set the Padding of the GridView (to 16px I believe) and push the content inward for your case.

[SetTrend]

I see. Alright, given this may be a heritage stemmed from mobile devices with small display dimensions, it still is unnecessary. The explanation you provided gives the reason for this behaviour to be wrong:

If a scoll bar is hidden, then

• Centered content, for example, ought to be truely centered, not shifted to the left by 16px. This is particularly true for devices with narrow display estate.

Hiding scroll bars is an Apple peculiarity. Windows Settings provide an option not to hide scroll bars ("Settings > Accessibility > Automatically hide scroll bars in Windows").

Hiding scroll bars is an incarnation of information hiding. It's a usability flaw that may only be tolerated in leisure applications. Otherwise it'd be hiding the fact that there is additional information available, which would be a reason for filing a lawsuit if, for instance, this would occur on a page containing Terms of Use.

[robloo]

It's not really hiding information with the default settings (Edit: although I see your point when the scroll bar fades away completely). The traditional scroll bar is only visible when the pointer moves over it directly. Otherwise, it is the collapsed view. Here is how it was intentionally designed to function:

While you can say that is counterintuitive to you, it is not counterintuitive by modern cross-platform standards. Yes, it's true this thinking came originally from mobile-first applications but it has stayed around and users don't find it too confusing. Additionally, from a design standpoint, it simply looks better. You will have a very hard time convincing the Microsoft design team this is an issue.

In your case, yes, you can customize the scrollbar style so it is always visible -- also in Windows Settings as you found. Doing so is outside the normal use-case and will then require you to add padding as I recommended above. You may also re-template to avoid the concerns and get the ScrollViewer to behave exactly as it did in WPF or WinForms.

Overall though this is really not a bug and your app will need to be designed to handle the case when scroll bars are always shown in the traditional view if set in settings. The design team will need to comment one way or the other if you wish to pursue this further.

[SetTrend]

On the contrary: Professionals working on a desktop machine don't use mouse or touch screen navigation. They are using keyboard navigation (TAB key, arrows, mnemonics). Doing so, the scroll bar never appears:

https://developercommunity.visualstudio.com/idea/993700/dont-hide-scroll-bars.html

So, it's indeed a case of information hiding.

[mdtauk]

The List View Items should be adding padding onto the right hand side, so no text gets hidden when the overlay scrollbar animates in. This will distinguish the good UI from Lazy UI design.

[SetTrend]

If you'd be required to add padding to a List View item, then why should you be hiding scroll bars in the first place? That doesn't make sense.

[robloo]

Hidden scrollbars look better from a design standpoint and are the latest convention.

[SetTrend]

Maybe. But still, that doesn't mean it's a meaningful convention per se.

A hidden scroll bar hides valuable information: the information that there's more content to come. That's a fact that cannot be denied.

Just to give an example from modern life: you won't find any desktop application on Windows outside of UWP that's using hidden scroll bars. That would be too risky. No-one would risk receiving claims from companies missing information due to lack of visual cues about valuable content.

[robloo]

I understand your point and it's a fair point especially when scrollbars are completely hidden when the pointer is no longer over the scroll area. Microsoft also partially agrees with you considering the system setting exists to always show them.

It was still considered acceptable for the reasons mentioned above though and most people have adapted to the change.

[StephenLPeters]

@RBrid and @anawishnoff FYI

[StephenLPeters]

@anawishnoff can you take a look at this, or, if you aren't the right person, pass it along to whoever is?

[SetTrend]

Just like to bring this thread back to attention.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Poopooracoocoo]

Do not close