Month: February 2012

If you enter an invalid URL into a web browser’s address field, the browser will usually display a reasonably helpful error message.

Some internet service providers override this behavior by displaying their own, branded search page. Like this one from CenturyLink, which is named Web Helper service.

It is easy to see how such “error pages” provide ISPs with extra income from sponsored search results (read: paid ads).

Nevertheless, they are a poor substitute for the browser’s built-in error handling, because it creates usability problems:

1. The ISP’s search page masks the underlying error,
2. it obscures the URL that was entered originally, and
3. restoring the default behavior is tedious.

Masking the underlying error

The error message that appears in Safari is unambiguous. It says exactly what went wrong in easy-to-grasp language.

Users who may still be confused by the error message can click on the Help button next to the message text to summon a help page in OS X’s Help Center, which lists possible causes for the error, and provides useful instructions on how to fix it.

Contrast that to CenturyLink’s page, which completely fails to explain what just happened, and why you are seeing it instead of the web page you originally wanted to visit.

Thankfully, there is a link at the top (and bottom) of the page, labeled “Why am I here?”, that promises to answer this very question.

https://uiobservatory.com/media/2012/CenturyLinkWebHelper_WhyAmIHere.jpg” alt=”When clicking on “Why am I here” in CenturyLink’s search page, a verbose text explains why the page is being shown” border=”0″ width=”400″ height=”250″ />

Compared to Safari’s concise error message, the explanation is much more verbose and purely descriptive. It does not contain a single prompt telling the user what to do now, as in “To fix this problem, do this!”

As a result, understanding what went wrong, and learning how to solve the problem, take more effort.

Obscuring the original URL

Look at what happens to the data, i.e., the URL, that you enter into the browser.

Safari leaves it unchanged despite the error. In contrast, CenturyLink uses a redirect to hop over to their search page, which replaces the link in the browser’s address field.

In cases where the error is caused by a typo, seeing just the original URL that you had entered makes it much easier and faster to verify what you had typed, and to fix any typos that you may find.

Making it tedious to restore the default behavior

As stated in the “Why am I here?” text, you can opt-out of this service. All you need to do is change a setting on the Web Helper service’s preferences page, and click Save.

https://uiobservatory.com/media/2012/CenturyLinkWebHelper_OptOut.jpg” alt=”You can opt out of CenturyLink’s “Web Helper” service via simple change of settings on their preferences web page” border=”0″ width=”400″ height=”250″ />

Once the changes have been confirmed, you will be spared CenturyLink’s Web Helper page and see Safari’s plain old error message, instead.

If, that is, you changed the setting on a computer that is connected directly to your CenturyLink modem. Otherwise, the setting won’t stick, even though the website presented you with that confirmation screen.

https://uiobservatory.com/media/2012/CenturyLinkWebHelper_FAQ.jpg” alt=”CenturyLink’s “Web Helper” FAQ explains that for the settings changes to stick, you need to connect your computer directly to the modem” border=”0″ width=”400″ height=”250″ />

What “directly connected to the modem” means is this: Plug one end of an ethernet cable into your computer, and the other right into the modem’s LAN socket.

Depending on your network setup, this is a non-trivial task.

In our home, for example, we use an older Qwest-branded Actiontech M1000 modem. This device only has a single Ethernet port, to which our WiFi router is connected. All of our computing devices go through this router to connect to the Internet.

As an important detail, I have configured our modem to operate in “bridge mode”, and user name and password for signing into our ISP’s network are configured in the router, not the modem.

To follow CenturyLink’s instructions for disabling their Web Helper service, I would need to unplug the router from the modem; connect one of our computers to the LAN socket on the modem; find our credentials for PPPoE access and enter them into the computer’s Network preferences; and then I could finally opt out of the Web Helper service in the hopes that this setting would stick.

What a mess!

The least that CenturyLink could do is to let you change the Web Helper setting via their customer account dashboard. Better yet, just get rid of this page already, or make it opt-in. Why?

Because any state-of-the-art web browser provides better error messages for, and faster and easier recovery from, invalid URLs than customized “error response” pages like CenturyLink’s.

And if you really need to perform a web search for finding the proper URL, there’s a prominent field for that in every browser, anyway.

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:

1. The swipe-for-page-turn behavior is not non-standard,
2. it does not break the web, and
3. 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.