constructive nonconformist

The Back Button is Not an Undo Button

In the film Starman, Jenny (Karen Allen) and Starman (Jeff Bridges), an extra-terrestrial who has crash landed on Earth, road trip across the United States in Jenny’s Mustang while evading government agents. Starman offers to drive and explains to Jenny, “I watched you very carefully. Red light stop, green light go, yellow light go very fast.”

Much has been written about web applications, particularly AJAX applications, that ‘break’ the web browser’s back button. There’s more than one type of back button breakage but what is usually discussed in relation to AJAX is the ability (or un-ability) to use the back button to undo the application’s last action.

I think the concern is misguided. The back button is not an undo button.

The back and forward buttons are part of the model of the web as a repository of documents. They allow a user to move back or forward in the chain of visited hypertext nodes, i.e. web pages.

The ‘back as undo’ argument is often supported by a usability study that shows mere mortal users depend on using the back button as an undo. I think that’s a little bit like using a study that shows automobile drivers speed up on a yellow light to argue for swapping the meanings of green and yellow traffic signals.

I don’t think browser back button behavior is quite as important as road safety but I do think there is an impedance mismatch between the web browser as hypertext document platform and the web browser as application platform.

‘Undo’ is an application action. The back button doesn’t undo anything. It loads a previous page. Spackling over the difference is a bad idea.

Link: Hypertext and Application Workflow (or The Case for Single Node Apps).

Hypertext and Application Workflow (or The Case for Single Node Apps)

Hypertext is a terrible platform for some types of web applications.

Consider an e-commerce web site. The browsing/shopping part of an online store fits rather well with the hypertext model but the checkout/payment part does not. For example, the checkout portion probably shouldn’t run the credit card transaction until after the customer has confirmed her order.

Many applications, even well-behaved non-modal event-driven applications, have some notion of workflow or an ordering of actions where task Y shouldn’t be available unless task X has been completed. Workflow-based constraints are at odds with the non-linear nature of hypertext.

Here’s a diagram with circles and arrows:

Consider this a state diagram. The circles represent states and the arrows represent state transitions. With A as a starting point there are two paths through this hypothetical application to reach state D: ‘ABD’ and ‘ABCD’. It should not be possible to reach D without traversing one of these two paths.

The workflow constraints this state diagram represents could be considered in procedural terms (step A must be followed by step B) or in temporal terms (event B can not be initiated until event A completes).

If this is a web application it could be built as a series of HTML pages. The relations between pages in a web application can be represented as a directed graph where pages and other resources addressable by URL are nodes, and links and transfers are edges. Here’s a page diagram for the hypothetical application:

Bears a striking resemblance to the state diagram, doesn’t it?

If an application has workflow constraints then it has a state machine. The state machine may not be explicit in the application’s architecture. It may only be implicit, arising from the relations between pages.

Now I’ll add the obligatory network cloud:

Oops! Since all URLs have equal visibility, a user can jump directly to any state/page if she knows (or guesses) the URL. Purely in terms of hypertext, this is a feature. But it’s a feature that the Web application developer will need to compensate for. The hypertext model is fundamentally working against the application.

There are three broad strategies for dealing with the “hypertext/workflow impedance mismatch”:

1. Design the application to detect out-of-order page requests and enforce the workflow model.
   

   There is no sense in allowing a user to jump into a broken fragment of an application. URLs are effectively APIs. Taking it further, if a web application can be thought of as an object and its URLs as its methods then the methods should enforce the application’s invariants and do something reasonable with error conditions.

2. Redesign or re-envision the application to either eliminate the workflow constraints or move the constraints out of application scope and down to the level of a single page.
3. Design the application to use a single URL; i.e. create a single page or single node application.

It’s possible to build a single page text pump type of application but a more popularized approach is to push some or all of the application logic down to the web browser client. The client-side code then depends on a service layer of URLs but the service layer can be stateless and/or protected.

In the past ‘single page with client-side app logic’ applications might have used Java Applets, or ActiveX controls, or DHTML. Currently there is a single page application renaissance driven by the buzz around AJAX.

The Web is Asynchronous

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.”

— Lewis Carroll, Through the Looking-Glass

Synchronous and Asynchronous

I didn’t intend to make a contentious statement.

I was on a job interview with a software company and I was meeting with one of the system architects. He was asking design questions about a scenario that involved adding a web front-end to an information intensive software system. He wanted me to consider the scenario to be abstract and hypothetical but it clearly wasn’t. So I was concerned about giving a politically incorrect answer — that is an answer at odds with the politics or decisions of the actual project.

I was trying to talk about general principles and also work in some of my experience with web services and non-traditional web clients. I said something like “the web is asynchronous” and the architect bristled. The web is synchronous he told me because when a user clicks a link she has to wait for the round trip to the server and back. I tried to minimize the damage and suggested that we were considering different aspects of a web application. He cut me off and suggested that I should go learn what it means to be synchronous.

Ouch.

I’m sure that the architect was considering the method of message delivery. With HTTP a client sends a request and expects a response. Delivery is theoretically immediate (i.e. synchronous) compared to, for example, a message queue architecture where an intermediate agent may hold messages for conveyance at a later point in time.

What was I thinking? A client can not determine when or even if a response will be returned. Instead of events synchronized to other events (e.g. response follows request), I was thinking about events synchronized to time.

Timely responses are an issue. It’s trite to say that, yet I have seen many applications and architectures that ignore this simple fact.

Although I think my usage of asynchronous was legitimate, I do realize that it was unconventional.

<rant>When I am the interviewer I see no value in interrupting a job candidate just to correct him or her. People are often imprecise in conversation. When I ask an open-ended question I’m prepared to listen.</rant>

Ajax

What recalled this interview horror moment for me was this article: Ajax: A New Approach to Web Applications.

Despite the title there’s actually nothing new here except the cute name of Ajax. That’s a minor quibble though. The article is a nice synopsis and contributes to the growing recognition that XMLHttpRequest is no longer an IE-only technique.

Figure 2 illustrates synchronization with respect to events, specifically client user activity correlated to server-side processing. It was figure 2 that brought the interview incident to mind.

I have not built an Ajax engine as described but I have worked on numerous projects that used similar patterns with different technologies. In a “classic web application model”, as defined in the article, a web app is only as good as its last server connection. An Ajax engine or, more generically, a client-side request management layer allows an application to be more resilient to the vagaries of the network.