Fit and Finish: Insight from the Ironworks User Experience Group

Scrollbars and Swipe Gestures in Mac OS X Lion

I use both an iPad and a MacBook Pro on a regular basis, and I have always found scrolling pages using finger gestures a bit awkward when switching between the two devices. On an iPad you are directly manipulating the page on the device’s touch screen, so it only makes sense that the page moves in the same direction as the movement of your fingers.  The opposite is true when scrolling a document using a Mac multi-touch track pad. If you do a two-finger swipe down, the document moves up. This becomes confusing when rapidly switching between the two devices. On many occasions I have, after a session of using the iPad, caught myself dragging down on the MacBook’s track pad expecting the page to move down.

Dragging down to make the page move up made sense in the pre-touchscreen days because of scrollbars. The classic GUI way of scrolling through a page is clicking and dragging a scrollbar with our mouse. If we drag the scrollbar down, the page moves up, and vice versa. It works like this because the scrollbar represents the part of the document you are currently viewing. If the scroll bar is at the top, you are looking at the top of the document and if the scrollbar is at the bottom you are looking at the bottom of the document. Moving that scrollbar from top to bottom also moves the view from the top of the document to the bottom, and thus moves the page up relative to the viewport of the containing window.

This is the way it has been for 26+ years of the Mac user interface, and it made a lot of sense.  But as the use of multi-touch screens has begun to proliferate, the drag-down-to-move-the-page-up interaction introduces the user to cognitive dissonance when switching between a touchpad laptop and a touchscreen tablet.

And Then There was Lion

Apple’s new operating system addresses this issue by reversing this interaction and making it work more like the iPad. In Lion the direction the page moves maps to the direction you swipe your fingers. If you swipe down the page moves down and vice versa. It takes a little getting used to but I think, overall, I like the consistency between the two platforms. I’ve only been using Lion for a few hours, and I still scroll the wrong way about 50% of the time. Yet, it seems to getting less troublesome even as I am writing and editing this blog post.

Unfortunately, there is one thing about this consistency that is really driving me crazy. The scroll bar is still visible on the screen, and it is moving in the opposite direction that my fingers are moving! For years I have associated a pulling down motion with the scrollbar moving down. Now, when I swipe down the scrollbar moves up! Once I started noticing this I cannot help but see it every time I try to scroll, especially when using narrow column viewports. And it feels, well, just WRONG. This visual feedback is counter-intuitive. So I not only have to fight the urge to swipe the track pad in the opposite way my subconscious brain wants to swipe, I now have to deal with this visual scrollbar screaming at me “you’re doing it wrong!”

This isn't a problem when using a touch screen device. On the iPad my finger is directly manipulating the movement of the page, so seeing the scroll bar move in the opposite direction isn't as disorienting. When using a track pad the conflicting visual feedback of the page movement vs. the scroll bar movement becomes much more pronounced. This is because the swipe movement on a trackpad was previously associated with manipulating the scroll bar and not the page itself. Switching the paradigm from manipulating the scroll bar to manipulating the page is what is causing the cognitive dissonance. 

It is possible that Apple gets this and has a plan for this in the future. As mentioned in John Siracusa’s lengthy review of Lion on Ars Technica, scroll bars in Apple products have recently become less pronounced visually. Apple’s scroll bar design changed little between 2000, when OS X was first released, and 2009 when Snow Leopard came out:

 

The first sign that Apple was moving away from the candy-capsule scroll bar design was in iTunes 10.2.2 released in 2011:

   

Lion’s scroll bars are reduced to a minimal grey bar and the clickable arrows have been eliminated, making the design almost identical to scrollbars in iOS:

 

Can We Eliminate Scrollbars?

I’m sure this more subdued scroll-bar design is somehow related to the new scroll-swipe configuration, but I am wondering if there is a case to be made to eliminate the scrollbar all together when using touch input devices such as a track pad, multi-touch mouse or touch screen. You would lose the visual cue as to how much screen there is left to scroll, but it would also eliminate the conflicting visual cue. Maybe there is a better way to show how big a page is in relation to the viewable area? Or, maybe knowing the length of the page is no longer necessary in a world of finger flicks and accelerated page movements?

I would like to try a scrollbar-less environment for a while just to see if I would even miss them (there isn’t an option to eliminate them in Lion, but you can hide them when the screen isn’t currently scrolling). As the point and click mouse becomes less and less relevant to my human computer interaction, my dependency on scroll bars may be fleeting as well.

 

Webinar Recap: Know What Works - How Testing Can Save You Time, Increase Conversion, and Improve Morale

Today, organizations still make far too many decisions on their website based on imperfect information, with no way to measure effectiveness. With proper data collection and analytics tools by way of A/B and/or multivariate testing, experiments can be a powerful way to help your organization make better, more informed decisions.

In a recent Ironworks and Sitecore webinar, “Know What Works – How Testing Can Save You Time, Increase Conversion, and Improve Morale,”  Geoff Harper of Ironworks and Peter Fogelsanger of Sitecore walked attendees through real-life scenarios on how A/B and multivariate testing can help your organization:

• Save time by building a consensus around a solution using hard data
• Optimize user experience by understanding what solutions best meet the requirements of your audience
• Determine the effect of changes to your website by testing a portion of site visitors to mitigate risks

Using Sitecore's built-in testing features, we demonstrated how easy it is to get started with A/B testing. Once you’re ready to get started, always remember to A/B test often, measure, rinse, and repeat.

Questions? For more information about A/B and multivariate testing, please contact Geoff Harper, Manager of Research & Measurement on the Interactive team at Ironworks Consulting.

View Webinar Recording: “Know What Works – How Testing Can Save You Time, Increase Conversion, and Improve Morale”