Chapter 3: Breaking the Browser (Part 3)

3.3 Finding the where in here: getting back, starting in the middle and other snapshots in time
The Back button is a notoriously sticky issue with some RIAs, particularly Flash- or plugin-based ones, but it’s really only one part of the story. The deeper issue is deep-linking, or how to take a snapshot of a specific point in time in an RIA. In the HTML model, going to a new page means pulling down a specific set of data, all at once. In rich internet applications, the data is pulled asynchronously; a lot of little calls instead of one big chunk. As a result, creating a snapshot of the data to display when hitting the Back button or creating a bookmark is very complex, and may or may not involve discrete URLs for every view. Handling of deep-linking right now is wildly inconsistent across RIAs, partially because of the labor involved in creating a holistic solution and partly because no true standards have emerged.

To get a handle on why deep-linking is (necessarily) different from the normal process of capturing a bookmark or back state, think about your favorite desktop application and imagine it running in a browser. Think about what you would expect a unique snapshot to contain. How would I make a bookmark in Adobe Photoshop to share with a friend? When that friend opened the link would it show the file and all my palettes in exactly the state I left them?  Would it capture the history of my doc and support 10 levels of undo upon opening? Would it indicate the tool I was last using? Or would it concentrate on the finished product (similar to sharing a “file” rather than the interface)?

First let’s define what that snapshot could contain. Everything in an application can be boiled down to two types of edits: change to the view state and change to the data state. View states are changed when I manipulate the interface: click on a menu, slide out a preference panel, select a tool, etc. Data state changes occur when I tag a photo, fill out a form, change my profile, or anything else that actually edits data. Determining what to capture in the event of Undo, Back, Save or bookmarking depends on how much of these two states needs to be retained. Many RIAs are opting to capture changes in the data state without capturing changes to the interface. In that way the default view state is maintained, while the user doesn’t lose data. In other applications, the layout and interface customization is very important, and should also be retained.

Data states vs. view states

There are many ways of creating (and faking) snapshots, but context is key. To find the right deep-linking solution, consider again what the user is trying to accomplish by in asking for that snapshot. Now let’s look at the scenarios that create a need for snapshots and talk about ways to address them.

3.3.1 Back button
As I said earlier about the Back button, when it comes to sovereign or plugin-based applications your best bet is to guide users away from it. I feel very strongly that the Back button paradigm is at odds with rich internet applications, and trying to support it will only encourage this unhealthy relationship. Ruthless as I am, I even believe that the slap on the wrist that the Back button doles out (Naughty user! Go back two spaces and lose a turn!) is helpful in teaching users about RIA behaviors.

That controversial statement made, if you do decide to include Back button support, there are a few guidelines to follow.  First, the more your application looks like a traditional HTML page, the more expectation from the user that the Back button will behave “normally”. AJAX implementations are harder to distinguish from their HTML environments, and tend to need more back button support. Web sites with a Flash application vibe will discourage Back button reliance.

Back button states (when supported) are often reserved for major changes to the interface, such as clicking on a section tab. The Picnik application follows this example, providing for a discrete URL for each major section and serving up the last view of that section.  ClickShirt also supports the Back button to move to the previous step in the process (from the buying interface back to the designing interface, for example).

Figure 3.5

Lastly, Back button use should never trump a Save action. If the user has saved data (for example, altered her profile information), this data should not undone by clicking the Back button. Be certain as a designer that you’re making a clear distinction to the user between undo or “previous version” and Back.

3.3.2 Saving
Many deep-linking issues can be sidestepped by designing clear and effective saving functionality with “cancel” and/or “revert” features. This allows users to maintain control of the data by canceling or committing to the edits they’ve made. Whether a save action is initiated by the user or automatically, it will provide clearer rules about what is available and when. Saving functionality evokes the familiar document-based model found on the desktop, which captures a view of the data on each save (usually overwriting the previous version). The data snapshot is more clearly defined and accessible to the application, and the user has a better understanding that the data state is what’s being saved, not the view state.
 
An added benefit is that by requiring saving you will alert users to instances where changes could be lost. Generally, navigating away from an area with unsaved changes (whether to a different part of the application or to another site entirely) should force the user to commit or cancel unsaved edits.

A nice variation on Save functionality is the version/revision history model. This allows users to access previous versions without fear of commitment. Although this can be offered along side a manual saving interface, it’s especially nice to see with auto-save. The application can capture various points along the way, without asking the user to save or discard those changes at every point. Most importantly, it provides no incentive for Back button use.

3.3.3 Undo
Earlier in this chapter, I mentioned that often folks reach for the Back button when what they’d really like is an “undo” feature. Undo actions tend to be much more granular than Back button actions, for example undoing text formatting versus returning to a different section of the application. Undo actions always have immediacy: they recall the last action performed and never need to retain information across sessions.

Try to identify possible points where users might want to undo. Undoing small edits is a handy feature to have, especially in an immersive application that supports lots of editing (such as a photo editing tool or word processor). In these cases offering an Undo button is a great idea. This is becoming more common, supported by keyboard shortcuts as well. Most users familiar with Undo in desktop applications will also understand that Undo is always related to a change in a data state, not a view state. It’s also standard practice to limit the number of undo actions, which again is acceptable from a user standpoint. On the development side, maintaining small version changes in the application is simpler that supporting a Back button, with clearer ground rules.

Figure 3.6

Sometimes a user would like to reverse a high-cost action. “Delete” is a classic panic-inducing action, which causes anxiety before executing and often incites swearing after. Many UI solutions have been created to deal with the finality of delete, solutions which could be adapted to other Undo scenarios. One method is fading out an item that has been deleted but not actually purging it until the session is over (offering a button in the mean time to undo the delete). Another route is to include “trash” functionality, which stores deleted items until the user manually purges. The simplest approach can simply offer a message to confirm delete (Are you sure?) with no Undo.

As applications become more robust on the web, designers won’t have the luxury of overlooking Save and Undo functionality. Users expect this in desktop applications and will be requiring it online in the very near future.

3.3.4 Bookmarking and sharing
People choose to bookmark pages for a variety of reasons. It’s difficult for the software creators to surmise what a user will want to bookmark and why, and thus it’s very difficult to build for it. Also, user’s mental model of the “page” in an RIA is still fuzzy, and there’s no obvious way to inform users what is bookmarkable. Take for example a basic HTML form on any site. A user could surmise that bookmarking would save the contents of the fields they’ve already entered (but haven’t yet submitted). Of course anyone who works in the computer industry would know that this isn’t the case in HTML, but why couldn’t it be?
 
I think the most defined and supportable bookmarking scenario is when a user bookmarks of a single bit of content such as a pair of shoes on an ecommerce site, or a specific article on a blog. In these types of sites it’s good to have discrete URLs for the final leg of the drill-down. This could happen in the typical way, through the browser, but the sentiment can be supported in other ways, such as wish lists, “save for later”, or other earmarking interfaces. You can also offer a way to get a URL even if that page wouldn’t normally exist in the typical application view: youtube for example offers a “URL” button on their interface for videos embedded externally on blogs and other sites. Not everyone will know what to do with that kind of a button, so use judiciously.

Ultimately, the decision to support bookmarking is completely subjective. Most likely, URLs will be created with other purposes in mind which will determine what someone sees when they bookmark that section. Try to make the user aware of the functions that support other bookmarking scenarios, such as saving a work in progress, recording an item I want to view later, or the sharing of content.
 
Sharing scenarios are a little bit different. Typically sharing with someone requires a characterization of a final output (a file, image or edited content), not the interface. I might want to send you a link to a shirt I’m thinking about buying, a photo of my cat, or a playlist I’ve composed. Guiding users to interfaces that are specifically designed for sharing crystallizes the purpose of the tool, both in the user’s minds and for the designer.
 
Because of the issues with bookmarking mentioned above, a user can’t simply copy a URL and paste it into an email. A few solutions have been created to get around this, but I have yet to see a completely clear direction that would pass the “mom test” (could my mom figure this thing out?). The most common solution seen lately is a Share button. The Share button usually presents a form in which the recipient’s email address is typed. It is generally understood that the user is sharing data in some kind of final output (not a view state), but the actual format of the data is often unknown to the sender.

Figure 3.7

Collaboration is a variation on sharing, but with a twist.  The collaborator will access the latest saved view, but typically with all interface elements in the default state. An invitation to collaborate is usually good for the life of that document.
I think the main trip-up to many application sites and sharing is the login process. People today are over-registered and leery of giving personal information away unless the benefits are clear. Creating a walled garden for all of your content may have its perks, but keep in mind a sizable group of people just won’t bother. How many unviewed pages are floating out in the world because the recipient did not want to register for an account?

3.4 Summary
Browser and HTML interactions, standards and structure have become deeply ingrained in our internet consciousness. But the times they are a’changin. The browser will continue to be a main entry point for online content, but as RIAs become ubiquitous, even the browser is going to have to give a little. In the meantime, we have an awkward middle stage, with users stuck trying to figure out if the site they’re looking at is animal, vegetable or mineral.

While this conflict plays out, continue your work as mediator, but don’t be afraid of a little tough love. The browser standards can be unnecessarily restrictive, and in some situations it’s best to declare loud and clear “this is a rich internet application!” and tell the browser to talk to the hand. Most of all, you must decide if the site is animal, vegetable or mineral and let the posture, look and feel, interactions, and workflow support that stand.
 
Now that we’ve put the browser in it’s place, let’s really shake things up by exploring new frontiers in RIAs and the possibilities of dynamic data.