Pro Yearly is on sale from $80 to $50! »

When to use Ajax and when to reload

7b1746f5ae99453e6a67f022ec0d73bd?s=47 Tiffany Conroy
February 27, 2013

When to use Ajax and when to reload

The Limits of Context
When to use Ajax and when to reload

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.

Since this talk requires some basic understand of Ajax, I’ll begin defining Ajax and explaining how the technique is used in web development to create app-like experiences.

7b1746f5ae99453e6a67f022ec0d73bd?s=128

Tiffany Conroy

February 27, 2013
Tweet

Transcript

  1. 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.
  2. CONTEXT Let’s start with context: What do I mean when

    I say “context”?
  3. “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.
  4. 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.
  5. ✓ 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.
  6. 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.
  7. 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.
  8. 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.
  9. AJAX? Right, so what does that have to do with

    Ajax?
  10. 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.
  11. 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 …
  12. Whole page reloads … and the whole page would reload.

  13. In the second half of the 90s …

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

  15. JavaScript and XMLHttpRequest … XMLHttpRequest was introduced, which allowed content

    to be sent and loaded …
  16. Asynchronous JavaScript and XMLHttpRequest asynchronously, without reloading the whole page.

  17. 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.)
  18. 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.
  19. Let’s look at an example using Facebook messages.

  20. I start to type a reply.

  21. In my reply, I enter a web address.

  22. 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.
  23. 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.
  24. 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.
  25. “Native Experience” Ajax allows us to emulate a “native experience”

    on the web, meaning, it feels like an application not a web site.
  26. “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”.
  27. 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.
  28. 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.
  29. Let’s pause for a moment: Why do we want to

    use Ajax?
  30. AJAX → maintains context Ajax allows us to maintain the

    context for the user, without jarring reloads. BUT …
  31. 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?
  32. New context? → Reload! When the user switches to a

    new context, the page can just be reloaded.
  33. TRANSITIONS? What about transitions? Transition are nice to have but

    not essential for most cases.
  34. 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.
  35. 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.]
  36. 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.
  37. 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.
  38. 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.
  39. THANKS!