Please accept my apologies for this article’s overly dramatic headline, but how else can you properly respond to the accusation that “Mac OS X Lion’s scroll breaks the web“?
According to the article’s author, Pablo Villalba, a feature that premiered in OS X 10.7 Lion — overloading the scrolling gesture with “Show previous/next page” commands — leads to interaction mayhem (emphasis his):
[This behavior] can be disabled with a system-wide setting from Preferences -> Trackpad -> Mouse gestures (disable two-finger swipe), but my problem with it is that it breaks the web with a non-standard behavior, and gives you no JS API to prevent it.
Thankfully, the situation is not quite as gloomy, because Villalba’s claim is flawed:
- The swipe-for-page-turn behavior is not non-standard,
- it does not break the web, and
- disabling it on a website-by-website basis would be the wrong solution.
Just another way to turn a page
Macs equipped with a multi-touch trackpad have offered a two-finger gesture for scrolling window contents for a few years now.
Under OS X 10.7 Lion, this gesture does double-duty for page turning: If the window contents cannot be scrolled (e.g., if the document is fully visible), or if you have scrolled the content as far as it will go, the gesture will switch from scrolling to jumping to the previous or next page in a document.
This two-finger-swipe-to-turn-the-page behavior is a system-wide feature in OS X Lion, and is supported by several applications. For example, you can use it to turn pages in a PDF document in Preview, or to step through photos in Aperture.
In principle, it is just another way to trigger a common operation. As such, it complements existing keyboard shortcuts and button clicks, and constitutes perfectly standard behavior on any Mac running OS X Lion.
If going to another webpage in Safari via the two-finger swipe is breaking “the” web, why doesn’t Villalba accuse the Previous/Next Page buttons of the same crime?
Admittedly, using one interaction for triggering different commands is always problematic, because the user needs to understand what command will be triggered based on the software’s current mode of operation.
Consequently, the risk of inadvertently moving away from the current webpage via the two-finger swipe is likely higher than inadvertently clicking the Previous/Next buttons. But this is not the core problem here.
The real problem is that, for applications, the web’s page metaphor does not make sense.
Web apps and the page metaphor don’t mix
The original concept for the World Wide Web was based on hypertext, and the data you would view right inside the browser was mostly that: interlinked text.
For this kind of data, a page is a natural “serving size”, and this fact is reflected in the way browsers let you navigate “pages”.
If you’re dealing with an interactive web application, however, the page metaphor does not make sense. For a web application, its user interface is the only “page”, and browser features for handling pages — including the Previous/Next Page commands — are not only meaningless. They can even interfere with the proper functioning of such an app and also lead to data loss.
The problem, therefore, does not lie in how you step away from a webpage running an app — via clicking a button, pressing a keyboard shortcut, or gesturing on a trackpad –, but in the very existence of these page-turning functions.
Keeping things consistent across, and within, apps
To address this problem for his own web application, Villalba would like to disable Safari’s turn-the-page gesture programmatically. He bemoans that, as of yet, there is no way to do this.
As I explained above, though, using this gesture for page turning is not limited to the Safari web browser. It is a system-wide feature in OS X Lion. Therefore, if a user has chosen to use this feature, it should work consistently across, as well as within, applications.
If it were possible to disable the gesture on a website-by-website basis, then that actually would break “the web” for any user who wants to use the gesture.
Instead of letting web developers disable system-features in this manner, I would prefer another solution to the very real problem that Villalba talks about.
An application mode in web browsers
The features and related user interface elements that browsers provide for handling web content as pages is what gets in the way when running a web app.
One possible solution, therefore, could be based on a dedicated “application mode” that is supported across different browsers and invoked by a simple, standardized command or tag.
In this mode, the “Previous/Next Page” buttons would be deactivated, forcing the user to stay on the web app’s page. Selecting the Close Window command would present a warning dialog whose text could be customized programmatically, and the user’s response to it passed on to the web app, before it is requested to quit.
Surely there are other functions that web app developers would like to see being enabled or disabled based on this app setting. Also, I’m not sure exactly how these features should be implemented design-wise: How should the application mode status be communicated to the user?Should there be an override for deactivated functions? Etc.
In any case, the key is that the solution is standardized across browsers and web applications, and that it provides a flawless user experience that does not rely on the design and coding skills of the individual web applications’ developers.
Just as importantly, the application mode must not modify any interactions — like scrolling or page selection in a browser — that may be un-conventional overall, but perfectly common on a specific computer platform.