A Simple Solution
There has always been an element of creativity in the development side of web design. The standards constantly change and evolve, and browser makers adopt them in different ways and at different paces. There is a steady stream of blog posts and articles related to bending HTML and CSS to create new effects, ensuring visual consistency amongst the browser targets, and working around the shortcomings of the markup and its implementation.
Generally, then, when we run into issues, we throw code at it. A recent project of ours used conditional comments (for IE specific code), multiple declarations (think RGBa backgrounds), jQuery (obviously), jQuery plugins (for animating rotations), Modernizr (for detecting compatibilities), lettering.js (for finer typographic control), media queries (for phones and devices), fallback code (for HTML5 audio codecs), and even a little browser sniffing.
Similarly, in thinking about user experience, we have many tools we can throw at problems, like tabs, sliders, popups, layers, and reveals.
On a recent project, we ran into an issue where this kind of thinking ultimately proved to be the wrong approach.
We have been working on a side project which is targeted to work on the desktop and on mobile devices, using the same markup. The site is almost ideally suited to use as a web application on the iPhone, using the tag:
to indicate to the mobile device we would like to run the page full screen, launched from the Home Screen, without the browser tool and address bars. This allows the web application to behave almost exactly as a native application.
One major limitation of the web application view, it turns out, is that it can only be used to display a single page. For the most part, that is the case for our application—data is loaded using asynchronous Javascript calls and displayed using dynamic layers. However, there are links to external sites within our data displays—mostly as reference links—but it didn’t occur to us to test these links in fullscreen mode, initially.
We found out about the problem when a test user complained about having to relaunch the application every time they followed one of these links. Each external link was launched in Safari. This exposed another major shortcoming of the web application view on the iPhone—it cannot use any of the multitasking capabilities introduced in iOS 4. Even though it appears in the application switcher, it must be launched fresh each time, which can take a while on 3G, and also means that the user cannot return to the same state they left when tapping the link.
We thought we might try coding our way around the problem. What if we were to capture the link in an iframe, drawn as a layer in our application—mimicking the way that the browser is used in many native applications?
It turned out that this was a limited solution. We could draw the frame and launch the initial link, but subsequent links on the external sites would then launch Safari. We thought about trying to override the default behavior on those links, but it seemed like it might end up being more trouble than it was worth to capture endless links, while the user browser the web without the usual controls or history.
This left us with two options to deal with the problem. The long-term solution would be to eliminate the external links and find some way of duplicating the essential external content within our data.
The short-term solution was to add a Javascript confirm pop-up to the external links when in the web application view. In other words, when the user taps the link, they are presented with a dialog informing them that the link will open in Safari, and asking whether they want to continue. A very old and basic piece of scripting.
Is it sexy? No, but I think it provides the user with the information necessary to understand what is happening. A basic part of web interaction that we tend to forget about when crafting a user experience is that the web enables users to make their own choices. The role of design is to provide the user with a smooth and intuitive interface—which should include enough transparency to help the user understand those choices.