Return to Answer

Apple removed scrollbars from appearing, unless in use, from viewports in 2011 with the release of Lion, immediately sparking multiple articles about how to get them back. The usability rationale and merit of this can still be debated today.

Not showing it until it is needed is a clean design and does not clutter the display, but the user must figure out how to get them to appear.

Showing them always adds clutter, but clearly indicates what actions are possible.

To illustrate the problem with not showing the scrollbars, take an example similar to yours and ask: how does a OS X user know what to do when they see this:

The lack of scrollbars actually create a Gulf of Execution, in that the system is not presenting the proper artifacts that imply that the viewport can be scrolled.

Assuming that no modifications have been made to Windows' default rendering of a viewport, they will show a scrollbar. So your original picture would appear something like this:

So actually, your challenge is how to represent to OS X users that it is a scrollable space!

If you’re writing a common desktop application, let the operating system do what it does. OS X will, by default, hide the scrollbars but users can turn them back on. Windows will show the scrollbars.

If we’re talking about the web, you have two choices:

1. “Force” the scrollbar back using pseudo elements, realizing that they are not supported in all browsers.
2. Create your own scrolling mechanism and hide the scrollbars using standard CSS properties.

If you make your own scrolling mechanism you will force all users to figure out how it works for your application/page. It might not be hard for them, but they will have to put in that effort.

If you “leave it alone” then Windows users will see a scrollbar. OS X users will be left with hopefully enough subtle visual queues to realize that the region can be scrolled horizontally.

(Answered from a Mac.)

Apple removed scrollbars from appearing, unless in use, from viewports in 2011 with the release of Lion, immediately sparking multiple articles about how to get them back. The usability rationale and merit of this can still be debated today.

Not showing it until it is needed is a clean design and does not clutter the display, but the user must figure out how to get them to appear.

Showing them always adds clutter, but clearly indicates what actions are possible.

To illustrate the problem with not showing the scrollbars, take an example similar to yours and ask: how does a OS X user know what to do when they see this:

The lack of scrollbars actually create a Gulf of Execution, in that the system is not presenting the proper artifacts that imply that the viewport can be scrolled.

Assuming that no modifications have been made to Windows' default rendering of a viewport, they will show a scrollbar. So your original picture would appear something like this:

So actually, your challenge is how to represent to OS X users that it is a scrollable space!

If you’re writing a common desktop application, let the operating system do what it does. OS X will, by default, hide the scrollbars but users can turn them back on. Windows will show the scrollbars.

If we’re talking about the web, you have two choices:

1. “Force” the scrollbar back using pseudo elements, realizing that they are not supported in all browsers.
2. Create your own scrolling mechanism and hide the scrollbars using standard CSS properties.

If you make your own scrolling mechanism you will force all users to figure out how it works for your application/page. It might not be hard for them, but they will have to put in that effort.

If you “leave it alone” then Windows users will see a scrollbar. OS X users will be left with hopefully enough subtle visual queues to realize that the region can be scrolled horizontally.

(Answered from a Mac.)

Apple removed scrollbars from appearing, unless in use, from viewports in 2011 with the release of Lion, immediately sparking multiple articles about how to get them back. The usability rationale and merit of this can still be debated today.

Not showing it until it is needed is a clean design and does not clutter the display, but the user must figure out how to get them to appear.

Showing them always adds clutter, but clearly indicates what actions are possible.

To illustrate the problem with not showing the scrollbars, take an example similar to yours and ask: how does a OS X user know what to do when they see this:

The lack of scrollbars actually create a Gulf of Execution, in that the system is not presenting the proper artefacts that imply that the viewport can be scrolled.

Assuming that no modifications have been made to Windows’s default rendering of a viewport, they will show a scrollbar. So your original picture would appear something like this:

So actually, your challenge is how to represent to OS X users that it is a scrollable space!

If you’re writing a common desktop application, let the operating system do what it does. OS X will, by default, hide the scrollbars but users can turn them back on. Windows will show the scrollbars.

If we’re talking about the web, you have two choices:

1. “Force” the scrollbar back using pseudo elements, realizing that they are not supported in all browsers.
2. Create your own scrolling mechanism and hide the scrollbars using standard CSS properties.

If you make your own scrolling mechanism you will force all users to figure out how it works for your application/page. It might not be hard for them, but they will have to put in that effort.

If you “leave it alone” then Windows users will see a scrollbar. OS X users will be left with hopefully enough subtle visual queues to realize that the region can be scrolled horizontally.

(Answered from a Mac.)

Apple removed scrollbars from appearing, unless in use, from viewports in 2011 with the release of Lion, immediately sparking multiple articles about how to get them back. The usability rationale and merit of this can still be debated today.

Not showing it until it is needed is a clean design and does not clutter the display, but the user must figure out how to get them to appear.

Showing them always adds clutter, but clearly indicates what actions are possible.

To illustrate the problem with not showing the scrollbars, take an example similar to yours and ask: how does a OS X user know what to do when they see this:

The lack of scrollbars actually create a Gulf of Execution, in that the system is not presenting the proper artifacts that imply that the viewport can be scrolled.

Assuming that no modifications have been made to Windows' default rendering of a viewport, they will show a scrollbar. So your original picture would appear something like this:

So actually, your challenge is how to represent to OS X users that it is a scrollable space!

If you’re writing a common desktop application, let the operating system do what it does. OS X will, by default, hide the scrollbars but users can turn them back on. Windows will show the scrollbars.

If we’re talking about the web, you have two choices:

1. “Force” the scrollbar back using pseudo elements, realizing that they are not supported in all browsers.
2. Create your own scrolling mechanism and hide the scrollbars using standard CSS properties.

If you make your own scrolling mechanism you will force all users to figure out how it works for your application/page. It might not be hard for them, but they will have to put in that effort.

If you “leave it alone” then Windows users will see a scrollbar. OS X users will be left with hopefully enough subtle visual queues to realize that the region can be scrolled horizontally.

(Answered from a Mac.)

Apple removed scrollbars from appearing, unless in use, from viewports in 2011 with the release of Lion. Immediately sparking multiple articles about how to get them back. The usability rationale and merit of this can still be debated today.

Not showing it until it is needed is a clean design and does not clutter the display, but the user must figure out how to get them to appear.

Showing them always adds clutter, but clearly indicates what actions are possible.

To illustrate the problem with not showing the scrollbars, take an example similar to yours and ask: how does a OS X user know what to do when they see this:

The lack of scrollbars actually create a Gulf of Execution, in that the system is not presenting the proper artifacts that imply the viewport can be scrolled.

Assuming that no modifications have been made to Window's default rendering of a viewport, they will show a scrollbar. So your original picture would appear something like this:

So actually, your challenge is how to represent to OS X users that it is a scrollable space!

If you're writing a common desktop application, let the operating system do what it does. OS X will, by default, hide the scrollbars but users can turn them back on. Windows will show the scrollbars.

If we're talking about the web, you have two choices:

1. "Force" the scrollbar back using pseudo elements, realizing that they are not supported in all browsers (http://stackoverflow.com/questions/7855590/how-can-i-prevent-scroll-bars-from-being-hidden-for-os-x-trackpad-users-in-webki)
2. Create your own scrolling mechanism and hide the scrollbars using standard CSS properties.

If you make your own scrolling mechanism you will force all users to figure out how it works for your application/page. It might not be hard for them, but they will have to put in that effort.

If you "leave it along" then Windows users will see a scrollbar. OS X users will be left with hopefully enough subtle visual queues to realize the region can be scrolled horizontally.

(Answered from a Mac)

Apple removed scrollbars from appearing, unless in use, from viewports in 2011 with the release of Lion, immediately sparking multiple articles about how to get them back. The usability rationale and merit of this can still be debated today.

Not showing it until it is needed is a clean design and does not clutter the display, but the user must figure out how to get them to appear.

Showing them always adds clutter, but clearly indicates what actions are possible.

To illustrate the problem with not showing the scrollbars, take an example similar to yours and ask: how does a OS X user know what to do when they see this:

The lack of scrollbars actually create a Gulf of Execution, in that the system is not presenting the proper artefacts that imply that the viewport can be scrolled.

Assuming that no modifications have been made to Windows’s default rendering of a viewport, they will show a scrollbar. So your original picture would appear something like this:

So actually, your challenge is how to represent to OS X users that it is a scrollable space!

If you’re writing a common desktop application, let the operating system do what it does. OS X will, by default, hide the scrollbars but users can turn them back on. Windows will show the scrollbars.

If we’re talking about the web, you have two choices:

1. “Force” the scrollbar back using pseudo elements, realizing that they are not supported in all browsers.
2. Create your own scrolling mechanism and hide the scrollbars using standard CSS properties.

If you make your own scrolling mechanism you will force all users to figure out how it works for your application/page. It might not be hard for them, but they will have to put in that effort.

If you “leave it alone” then Windows users will see a scrollbar. OS X users will be left with hopefully enough subtle visual queues to realize that the region can be scrolled horizontally.

(Answered from a Mac.)