Chapter 3: Breaking the Browser (Part 1)
For as long as most of us have been using the internet, the way to view online content has been through a browser. The browser is its own application that has its own controls, standards, and behaviors that users now take for granted and employ almost unconsciously. Because of this, one of the most common reservations I hear from companies thinking about transitioning to RIAs is that RIAs break fundamental notions about browser behavior. They have heard controversy about the back button, and worry about the usability of non-standard browser interactions like drag and drop. They envision their users caught in the middle of an ugly conflict between the browser and the rich internet application inside. It’s a showdown at high noon, and only one can survive.
Of course, the demise of the browser would be greatly exaggerated. HTML will be a dominant standard for a while to come and browsers will continue to be a preferred point of entry to anything online, but web applications will become more and more prevalent. Our job as designers is to help the users navigate the inherent tension between the browser and the web app, treating it more like a conversation than a war. We need to make apparent to the user which party is talking and must be listened to, and allow the dialogue to flow naturally.
To that end, creators of web applications need to dissect the browser and understand when it can work for us and when it’s best to keep it on a short leash. We also need to look beyond the current HTML paradigms and draw from new sources, including an old friend: the desktop. When we do that we can make peace between the browser and its rich content.
3.1 Browser baggage: the back button and other relics
Since the inception of the browser a few basic controls have been consistently offered: a URL field, back, next, and reload buttons. All of them have the potential to wreak havoc with an RIA.
Browsers are explicit in their hierarchy. The application keeps its controls in the chrome at the top, which very clearly from a UI standpoint shouts “I am in control of this content!” In creating a rich internet application, we are asking the users to ignore this great big signpost, the controls that they have relied on for all of their internet lives. Trust us, we say, it’s better in here.
And I find that users are generally willing to play along… that is until something goes wrong. At this point they quickly activate Plan B: the browser controls. But in all likelihood the browser control will not do the expected, and will probably get them deeper into trouble. Now we’ll take a closer look at some browser favorites we’ve come to rely on and how to avoid their potential pitfalls.
3.1.1 Back/Next buttons
At some point in a conversation with someone new to RIAs, they’ll look solemnly at me and say, “Yes, but what about the Back button?” People are understandably concerned about losing one of the main tools of navigation through any website. HTML websites are structured to enable this use, and even make efforts to complement it.
RIAs on the other hand, do not have unique URLs for each view, and so even determining the meaning of “Back” is very tricky. Back to what? Back to before I adjusted this dynamic filter? Back to when I had that tabslider open? Back to when I was in the preferences section of the application? And sometimes the user doesn’t really mean “back” but instead “undo”, which is an equally sticky but conceptually distinct problem. Discouraging use of the Back button takes some courage, but will greatly benefit your users.
Depending on the level of complexity and integration of your application, use of the Back button can have a few different outcomes. In the case of a sovereign, plug-in based web application, the user may be popped out of the application entirely and back to whatever page they had visited prior to your application. Hitting the Next button at this point will bring the user back to the application, but probably at the beginning of an experience, waiting for the application to load. Yuck.
In the case of transient, AJAX, or smaller-scale integrations, or widgets in an otherwise HTML page, the user might click the back button intending to view a previous state, and instead ends up on a previous page. Clicking Next may cause them to lose whatever changes or additions they made to that state in the first place. Double yuck.
There are a variety of solutions to this problem, none of which is optimal or foolproof. The best solution of is to yank the user’s focus to the controls inside your application and hold them there. Communicate clearly throughout the workflow, minimize confusion at all costs, and clearly mark exits to any action. Carefully consider situations where the user might want to Undo something, which is a desire that frequently sends them reaching for the back button. It is also worth mentioning that creating the look and feel of an application versus a web site will steer users toward application-appropriate interactions.
Another somewhat sneaky tactic is to take is to remove browser chrome altogether, typically done by displaying the application in a popup. This will remove Back button temptation from the user. If the browser page consists of the application and nothing else, you might be able to get away with this. If you’re dealing with a smaller integration, an application that resides within an HTML wrapper, or an application that’s a subsection of a larger site, this option is not a possibility.
If back button is really something you want to support, there are ways to implement it and ways to fake it. Depending on the complexity of your application this can be somewhat simple or a screaming nightmare. We’ll cover all the ins and outs of this later in this chapter in “Finding the Where in Here”.
3.1.2 Reload
Reload has many of the same pitfalls as with the Back and Next buttons. Reload will bring a plugin-based application back to the entry point, starting at a loading animation. In AJAX implementations, data or UI features may be lost on reloading.
The main difference to consider is that users click Reload generally when they perceive some kind of performance problem. In a rich internet application, one scenario where a performance problem could be perceived is when the user performs a search and no results are displayed. If there is no feedback (loading animation, timeout or error message) the user may conclude that the application is stuck and hit the Reload button.
The key again is communication. If you are designing an application that allows users to customize data, be sure that you have designed the application in“no data” scenarios. When the user enters your application for the first time, they won’t have the robust data set your design is optimized for, so add instructional messages, sample data, or whatever else might help get the ball rolling.
Once the user is actually using the application, loading animations are a great way to create a continuous feedback loop and let the user know something’s happened after a click. Also be sure to consider all real failure scenarios as well. There are a number of ways to handle errors and failures (see Error messages suck, Chapter 2), but be sure to inform the user what went wrong and how to avoid it in the future. All of these tactics can minimize the use of the Reload button.
3.1.3 Popups
Popups come in two flavors in a browser: content popups that appear outside a page (presumably to help the user keep their place in the originating site or application) and dialog popups (modal or otherwise) that offer feedback messages, often on an application level.
Content popups have become the lepers of the internet, largely because of the proliferation of intrusive popup and popunder advertisements. But popups are a mainstay in the RIA world, to provide both a rich and contained user experience. Flash-based applications don’t have as much of a problem with popup blockers, but using javascript, DHTML or some other technologies in a popup will trigger blockers and could leave your users out in the cold. Also to consider:
• All browsers have different ways of handling popups and blocking
• Some users may have non-standard browsers that don’t follow convention
• Java may be turned off, blocking some technologies
• People often install software separate from the browser to block popups
One way to mitigate a poor experience where popups are concerned could be to include a message before the launch of the popup, something along the lines of “Application X will pop up in a new window. Please disable your pop up blockers to access the application.” (This is what I like to call “Strange behavior alert!”, pointing out a behavior that is not by any means my wish for the user, but that they should know about nonetheless). It also might be a good idea for the originating window to indicate that a popup was launched, in case the user didn’t see it or the blocker doesn’t identify when it blocks a page.
If popup blockers are a concern, be sure that you incorporate this issue into the initial architecture of your site. You may choose to change directions if it seems the risks of putting your application in a popup outweigh the benefits. Less savvy users may consider anything in a popup to be undesirable, and may not take the steps necessary to see the application. Nothing is as sad as a site unseen.
