THE LIMITS OF CONTEXT When to use Ajax and when to reload THE LIMITS OF CONTEXT When to use Ajax and when to reload ======================= What the hell do I mean by that? For starters, this is a talk about interaction design for web applications. This is also a talk about working with developers, using their language to communicate with them, and understanding the technical challenges that fancy immersive designs can introduce. This is also a talk about being pragmatic. This talk is about using interaction design to help make the choice between using Ajax and reloading the page. There’s a lot in that title that I need to define before I can make the point I want to make.

CONTEXT Let’s start with context: What do I mean when I say “context”?

“Context” is the answer to the question: where are you, and what are you doing. By this I am not talking about where you physically are while using a web application, but where you are *within* the web application, and what you are doing there. When you are designing an instance of a context, you may call it a view, or a screen.

But two different instances of the same “screen” are in fact two different contexts. For example: The timeline of two different people are two different contexts.

✓ Multiple parts of the same workflow can all happen in the same context. In this example, the context is filling out a form. While the user is in this context, we want to control the user’s experience as much as possible, so that the user doesn’t lose context.

As an interaction designer, you need to understand and define the contexts that your users will be working in. When I say “the limits of context” I mean the boundaries between contexts, where one stops and the next one starts.

When we make a transition from one context to the next, we cross the limit of one context and enter another. When we design a context, we have to understand, define, and communicate the limits of the context.

LIMITS OF CONTEXT ✓ So, that is what I mean by “the limits of context” -- understanding and defining the different parts of an application, and seeing where one context stops and the next one begins.

AJAX? Right, so what does that have to do with Ajax?

AJAX vs RELOAD A quick recap for everyone on what Ajax is and what we use it for, and how it differs from a page reload.

In the early 90s, all web pages were static, and if you wanted to see new content, you followed a link or clicked on a form submit button …

Whole page reloads … and the whole page would reload.

In the second half of the 90s …

JavaScript … after JavaScript was introduced, a JavaScript object called …

JavaScript and XMLHttpRequest … XMLHttpRequest was introduced, which allowed content to be sent and loaded …

Asynchronous JavaScript and XMLHttpRequest asynchronously, without reloading the whole page.

Asynchronous JavaScript and XMLHttpRequest Around that time Google released Gmail and Google Maps that used this technique, which was given the name Ajax in 2005. (ps to big know-it-alls reading these speaker notes: yes, I know the X originally stood for XML, but making that distinction would just complicate things.)

Just one part reloads Ajax allowed us to change the page content without a full page reload. But the more exciting use case was to make the page send and load content based on user interaction.

Let’s look at an example using Facebook messages.

I start to type a reply.

In my reply, I enter a web address.

Without me doing anything, and without interrupting me typing, the Facebook app uses Ajax to load information about the link I entered, and adds it to my message.

When I send the message, the app uses Ajax to send my message without reloading the page. Ajax allowed us to maintain the context of what the user was doing, without reloading the page.

AJAX → interactive The web stopped being a collection of static web sites, and we now have more and more web applications full of complex interactive logic. We rely heavily on Ajax to control the interactions, transitions and feedback in modern web applications as we strive for greater control of the user's experience. To reiterate what I said before: Ajax allows us to maintain the context of what the user was doing, without reloading the page.

“Native Experience” Ajax allows us to emulate a “native experience” on the web, meaning, it feels like an application not a web site.

“Native Experience” and controlling transitions One of the most basic features of a ”native” experience is the controlled transitions between contexts, for example, the sliding left and right between screens. On the web, if you reload the page, you can’t define the transition. In every browser I’ve used, the transition is the same: the page goes white, the spinner spins, and then the page loads. Reloading can be jarring. We can get around this if we load the content with Ajax, and then transition to the new context. We call these sort of sites that exclusively use Ajax “single-page apps”.

SINGLE-PAGE APPS So called “single-page apps” are very sexy. But people have begun to see that single-page apps are also nasty beasts that bring all sorts of technical complications with them.

SINGLE-PAGE APPS deep-linking JavaScript router #! hash-bang back button fat client document.history Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Let’s pause for a moment: Why do we want to use Ajax?

AJAX → maintains context Ajax allows us to maintain the context for the user, without jarring reloads. BUT …

AJAX → adds complexity Ajax also introduces all lot of technical complications. This is complication that you as designer don’t have to think about, but creates a lot of extra work for developers. And that extra work might not be worth it. How can we as designers help developers be pragmatic about when to use Ajax and when not to?

New context? → Reload! When the user switches to a new context, the page can just be reloaded.

TRANSITIONS? What about transitions? Transition are nice to have but not essential for most cases.

You might say: BUT BUT BUT … all the cool kids are doing it! My product is also cool! Maybe, but some of the cool kids still use page reload.

Case study: Github [Show on github.com how a profile is a context, how a repo-browser is a context, and how each pull request is one context, with page reloads in between.]

Limit your demand for Ajax Limit your demand for asynchronous communication to only within the contexts that matter. “Single-page apps” are often made as single-page apps for the wrong reasons. I have made this mistake.

Know where context breaks are Know where the breaks in context are, and communicate them to developers, because these are important for designing the application architecture.

In modern web application design and development, as we strive for greater control of the user's experience, we rely heavily on Ajax to control the interactions, transitions and feedback. We do this to maintain context for the user during their interactions. As designers, we need to be able to clearly see and communicate which contexts exist, so that developers can make decisions about how to keep and switch contexts.

THANKS!