CUTTING THE FATWhen to use Ajax and when to reload
@theophaniTIFFANY CONROYAll content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/My name is Tiffany, an...
CUTTING THE FATWhen to use Ajax and when to reloadWhen to use Ajax and when to reload=======================This is a talk...
Last summer there was a conference called “Throne of JS”The conference had a very specific premise:
“Throne of JS … is …focused on answeringthe question on everyweb developer’s mind:“Throne of JS is […] focused on answerin...
“Throne of JS … is …focused on answeringthe question on everyweb developer’s mind:which framework?”“Throne of JS is […] fo...
Question the premise.The premise of the question “which framework” is based on the idea that in a modern webapplication, t...
What to expectFirst I’m going to define some terminology.Then we examine the benefits and problems of fancy single-page web ...
What to expect• TerminologyFirst I’m going to define some terminology.Then we examine the benefits and problems of fancy sin...
What to expect• Terminology• Benefits and costs of AjaxFirst I’m going to define some terminology.Then we examine the benefi...
What to expect• Terminology• Benefits and costs of Ajax• A pragmatic approachFirst I’m going to define some terminology.The...
AJAX vs RELOADA quick recap for everyone on what Ajax is and what we use it for, and how it differs from apage reload.
In the early 90s, all web pages were static, and if you wanted to see new content, youfollowed a link or clicked on a form...
In the early 90s, all web pages were static, and if you wanted to see new content, youfollowed a link or clicked on a form...
Whole pagereloadsIn the early 90s, all web pages were static, and if you wanted to see new content, youfollowed a link or ...
In the second half of the 90s …
JavaScript… after JavaScript was introduced, a JavaScript object called …
JavaScriptandXMLHttpRequest… XMLHttpRequest was introduced, which allowed content to be sent and loaded …
AsynchronousJavaScriptandXMLHttpRequestasynchronously, without reloading the whole page.
AsynchronousJavaScriptandXMLHttpRequestIn 2005, the technique of loading content asynchronously with JavaScript was given ...
Just one partreloadsAjax allowed us to change the page content without a full page reload.But the more exciting use case w...
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 Ajaxto load information about the lin...
When I send the message, the app uses Ajax to send my message without reloading the page.Ajax allowed us to maintain the c...
Ajax → maintains contextThe web stopped being a collection of static web sites with fixed content, and allowed us toexchang...
CONTEXTWhat do I mean by “context”?
“Context” is the answer to the question: where are you, and what are you doing. By this I amnot talking about where you ph...
UserProfileNewsFeedStoreCheckoutSlideshowSome examples of different contexts could be:user profile, a news feed, the checko...
But two different instances of the same “screen” are in fact two different contexts.For example: The timeline of two diffe...
Two separate contextsBut two different instances of the same “screen” are in fact two different contexts.For example: The ...
✓Multiple parts of the same workflow can all happen in the same context.In this example, the context is filling out a form. ...
✓Same contextMultiple parts of the same workflow can all happen in the same context.In this example, the context is filling ...
Your application may have lots of little components and features and bits of information, andyou need to understand out ho...
Then you need to define which components go together.
Then you need to define which components go together.
So when I say a context, I mean these different groupings of related bits organized intomeaningful groupings.Designers nee...
When we make a transition from one context to the next, we exit the boundary of onecontext and enter another.Ajax could be...
Designers need to understand, define and communicate the distinct contexts in any rich webapplication, being clear about th...
Ajax → maintains contextSo, Ajax allows us to maintain context for users.
Lots of Ajax → “Fat Client”Web applications that use a lot of Ajax are sometimes called “fat client”
FAT vs THINWhat is a “fat” client?What do we mean by a “fat client”.How is it different from a “thin client”
Client = code in the browserSERVER ----[ network ]----> CLIENT## Server and clientIn this discussion, the code that runs i...
Thin clientDATA + ALL THE LOGIC-------------------[ network ]---------------->PRESENTATION## Thin Client[ DATA ] + [ ALL T...
Fat clientDATA-------------------[ network ]---------------->ALL THE LOGIC + PRESENTATION## Fat Client[ DATA ] + [ ALL THE...
“Native Experience”People also talk about a “native experience” on the web.Ajax allows us to emulate a “native experience”...
“Native Experience”and controlling transitionsOne of the most basic features of a ”native” experience is the controlled tr...
SINGLE-PAGE APPSAwesome or not awesome?So called “single-page apps” are very sexy these days. But people have begun to see...
SINGLE-PAGE APPSTrying to recreate a native experience brings with it all kinds of technical problems.One upon a time, if ...
SINGLE-PAGE APPSback buttonTrying to recreate a native experience brings with it all kinds of technical problems.One upon ...
SINGLE-PAGE APPSdeep-linkingback buttonTrying to recreate a native experience brings with it all kinds of technical proble...
SINGLE-PAGE APPSdeep-linking#! hash-bangback buttonTrying to recreate a native experience brings with it all kinds of tech...
SINGLE-PAGE APPSdeep-linkingJavaScript router#! hash-bangback buttonTrying to recreate a native experience brings with it ...
SINGLE-PAGE APPSdeep-linkingJavaScript router#! hash-bangback buttonwindow.historyTrying to recreate a native experience b...
SINGLE-PAGE APPSdeep-linkingJavaScript router#! hash-bangback buttonframeworkswindow.historyTrying to recreate a native ex...
Let’s pause for a moment:Why do we want to use Ajax?What problems are we trying to solve with Ajax? i.e. what **benefits** ...
Problems a fat client solves:Problems a fat client solves:* The user can continue to interact (including simply viewing) w...
Problems a fat client solves:• Continuous interactionProblems a fat client solves:* The user can continue to interact (inc...
Problems a fat client solves:• Continuous interaction• Transitions between contextsProblems a fat client solves:* The user...
Problems a fat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingProblems a fat cli...
Problems a fat client solves:• Continuous interaction• Transitions between contexts• Incremental loading• Reduced network ...
Problems a fat client solves:• Continuous interaction• Transitions between contexts• Incremental loading• Reduced network ...
Problems a fat client causes:Problems a fat client causes:* Routing becomes the responsibility of the client-side script i...
Problems a fat client causes:• RoutingProblems a fat client causes:* Routing becomes the responsibility of the client-side...
Problems a fat client causes:• Routing• HistoryProblems a fat client causes:* Routing becomes the responsibility of the cl...
Problems a fat client causes:• Routing• History• Caching and garbage collectionProblems a fat client causes:* Routing beco...
Problems a fat client causes:• Routing• History• Caching and garbage collection• Computation is outside of our controlProb...
Problems a fat client causes:• Routing• History• Caching and garbage collection• Computation is outside of our control→ TE...
Design problems afat client solves:Let’s look again at the interaction design problems that a fat client can solve.
Design problems afat client solves:• Continuous interactionLet’s look again at the interaction design problems that a fat ...
Design problems afat client solves:• Continuous interaction• Transitions between contextsLet’s look again at the interacti...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLet’s look a...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLet’s look a...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMaintain con...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMaintain con...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMaintain con...
Ajax → controls contextAjax allows us to establish and maintain the context for the user, without jarring reloads.BUT …
Ajax → adds complexityAjax also introduces all lot of technical complications.This is complication that you as designer do...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingWhen we look...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMost importa...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMost importa...
Continuous interactionContinuous interaction is the primary reason we use Ajax. We use it during form validation,live chat...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingSo what bene...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLeast import...
Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLeast import...
New context? → Reload!When the user switches to a new context, the page can just be reloaded.
NO TRANSITIONS!?What about transitions?Transition are nice to have but not essential for most cases.
“The cool kids are doing it!”You might say:BUT BUT BUT … all the cool kids are doing it! My product is also cool!Maybe, bu...
Case study: Github
On github.com: a profile is a context, the repo file-browser is a context, and each pullrequest is one context, with page re...
On github.com: a profile is a context, the repo file-browser is a context, and each pullrequest is one context, with page re...
As we saw, Github is a collection of single-page apps, one per context, with page reloads inbetween.
AJAX vs RELOAD?So, when should you use Ajax and when should you use reload?Let’s recap:
Limit your demand for AjaxLimit your demand for asynchronous communication to only within the contexts that matter.Only us...
Find the interaction pointsFind the interaction points. Everywhere the user will click, type, hover or otherwise engagewit...
Find the context boundariesKnow where the boundaries between contexts are, and communicate them to developers,because thes...
Does your frameworkminimize your technical costs?Does your framework help solve the design problems while minimizing the t...
Single-page apps? YES: we can help our users maintain context so they can focus withoutjarring interruptions. These means:...
Single-page apps? → YESSingle-page apps? YES: we can help our users maintain context so they can focus withoutjarring inte...
Single-page apps? → YESMonolithic apps? → NOSingle-page apps? YES: we can help our users maintain context so they can focu...
QUESTIONS?and discussion@theophanispeakerdeck.com/theophani/cutting-the-fat
THANKS!All content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/
Nächste SlideShare
Wird geladen in …5
×

Cutting the Fat by Tiffany Conroy

1.060 Aufrufe

Veröffentlicht am

Rich, interactive web applications AKA fat clients are now commonplace. There are so many frameworks for building these rich client applications, and the debate among developers is which of these frameworks to use. As designers and developers we need to step back, and ask ourselves when and how we should enrich our client applications and when or why not. Let's dig in to the question: Why do we even want fat clients, and when should we use them? Let's examine the complications such clients introduce so we can weigh them against all the benefits.

Veröffentlicht in: Technologie, Bildung
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.060
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
25
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Cutting the Fat by Tiffany Conroy

  1. 1. CUTTING THE FATWhen to use Ajax and when to reload
  2. 2. @theophaniTIFFANY CONROYAll content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/My name is Tiffany, and I work as an interaction designer and front-end developer atSoundCloud.
  3. 3. CUTTING THE FATWhen to use Ajax and when to reloadWhen to use Ajax and when to reload=======================This is a talk about being pragmatic.This is a talk is about how to reduce the technical complexity of web applications.This talk is about using interaction design to help make the choice between using Ajax andreloading the page.
  4. 4. Last summer there was a conference called “Throne of JS”The conference had a very specific premise:
  5. 5. “Throne of JS … is …focused on answeringthe question on everyweb developer’s mind:“Throne of JS is […] focused on answering the question on every web developers mind: whichframework?”Yes: rich, interactive web applications are now commonplace. There are so many frameworksfor building these rich client applications, and the debate among developers is which of theseframeworks to use.
  6. 6. “Throne of JS … is …focused on answeringthe question on everyweb developer’s mind:which framework?”“Throne of JS is […] focused on answering the question on every web developers mind: whichframework?”Yes: rich, interactive web applications are now commonplace. There are so many frameworksfor building these rich client applications, and the debate among developers is which of theseframeworks to use.
  7. 7. Question the premise.The premise of the question “which framework” is based on the idea that in a modern webapplication, the page should never be reloaded.But as designers and developers, we need to step back, and ask ourselves: why don’t we wantto reload the page? When *can* we reload the page, and What is the benefit of Ajax? What isthe cost of using Ajax?Frameworks help up to solve technical problems, but can we ever avoid those problemsentirely?
  8. 8. What to expectFirst I’m going to define some terminology.Then we examine the benefits and problems of fancy single-page web applications.Lastly, I want to show you one way of approaching your applications as a designer anddeveloper that can help you reduce complexity, even before you choose a framework.Let’s get started.
  9. 9. What to expect• TerminologyFirst I’m going to define some terminology.Then we examine the benefits and problems of fancy single-page web applications.Lastly, I want to show you one way of approaching your applications as a designer anddeveloper that can help you reduce complexity, even before you choose a framework.Let’s get started.
  10. 10. What to expect• Terminology• Benefits and costs of AjaxFirst I’m going to define some terminology.Then we examine the benefits and problems of fancy single-page web applications.Lastly, I want to show you one way of approaching your applications as a designer anddeveloper that can help you reduce complexity, even before you choose a framework.Let’s get started.
  11. 11. What to expect• Terminology• Benefits and costs of Ajax• A pragmatic approachFirst I’m going to define some terminology.Then we examine the benefits and problems of fancy single-page web applications.Lastly, I want to show you one way of approaching your applications as a designer anddeveloper that can help you reduce complexity, even before you choose a framework.Let’s get started.
  12. 12. AJAX vs RELOADA quick recap for everyone on what Ajax is and what we use it for, and how it differs from apage reload.
  13. 13. In the early 90s, all web pages were static, and if you wanted to see new content, youfollowed a link or clicked on a form submit button …
  14. 14. In the early 90s, all web pages were static, and if you wanted to see new content, youfollowed a link or clicked on a form submit button …… and the whole page would reload.
  15. 15. Whole pagereloadsIn the early 90s, all web pages were static, and if you wanted to see new content, youfollowed a link or clicked on a form submit button …… and the whole page would reload.
  16. 16. In the second half of the 90s …
  17. 17. JavaScript… after JavaScript was introduced, a JavaScript object called …
  18. 18. JavaScriptandXMLHttpRequest… XMLHttpRequest was introduced, which allowed content to be sent and loaded …
  19. 19. AsynchronousJavaScriptandXMLHttpRequestasynchronously, without reloading the whole page.
  20. 20. AsynchronousJavaScriptandXMLHttpRequestIn 2005, the technique of loading content asynchronously with JavaScript was given the nameAjax. Around that time Google released Gmail and Google Maps.(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 complicatethings.)
  21. 21. Just one partreloadsAjax 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 userinteraction.
  22. 22. Let’s look at an example using Facebook messages.
  23. 23. I start to type a reply.
  24. 24. In my reply, I enter a web address.
  25. 25. Without me doing anything, and without interrupting me typing, the Facebook app uses Ajaxto load information about the link I entered, and adds it to my message.
  26. 26. 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 thepage.
  27. 27. Ajax → maintains contextThe web stopped being a collection of static web sites with fixed content, and allowed us toexchange data with the web server without reloading the page.Now, we rely heavily on Ajax to control the users experience.To reiterate what I said before:Ajax allows us to maintain the context of what the user was doing, without reloading thepage.
  28. 28. CONTEXTWhat do I mean by “context”?
  29. 29. “Context” is the answer to the question: where are you, and what are you doing. By this I amnot 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.
  30. 30. UserProfileNewsFeedStoreCheckoutSlideshowSome examples of different contexts could be:user profile, a news feed, the checkout of a store, a slideshow.Within each of these contexts, we may not want to reload the page.Each distinct context could be its own “single-page app”, and a plain old browser refreshcould be used to transition between these contexts.
  31. 31. 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.
  32. 32. Two separate contextsBut 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.
  33. 33. ✓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 tocontrol the user’s experience as much as possible, so that the user doesn’t lose context.
  34. 34. ✓Same contextMultiple 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 tocontrol the user’s experience as much as possible, so that the user doesn’t lose context.
  35. 35. Your application may have lots of little components and features and bits of information, andyou need to understand out how they all relate to each other.
  36. 36. Then you need to define which components go together.
  37. 37. Then you need to define which components go together.
  38. 38. So when I say a context, I mean these different groupings of related bits organized intomeaningful groupings.Designers need to understand, define and communicate the distinct contexts in any rich webapplication, being clear about the where boundaries between contexts are; where one stopsand the next one starts.
  39. 39. When we make a transition from one context to the next, we exit the boundary of onecontext and enter another.Ajax could be used to control the transition between contexts, if the designer and thedeveloper can negotiate it by balancing the benefits against the technical costs.
  40. 40. Designers need to understand, define and communicate the distinct contexts in any rich webapplication, being clear about the where boundaries between contexts are; where one stopsand the next one starts.
  41. 41. Ajax → maintains contextSo, Ajax allows us to maintain context for users.
  42. 42. Lots of Ajax → “Fat Client”Web applications that use a lot of Ajax are sometimes called “fat client”
  43. 43. FAT vs THINWhat is a “fat” client?What do we mean by a “fat client”.How is it different from a “thin client”
  44. 44. Client = code in the browserSERVER ----[ network ]----> CLIENT## Server and clientIn this discussion, the code that runs in a web browser is the “client”, in contrast with codethat runs on a web server.
  45. 45. Thin clientDATA + ALL THE LOGIC-------------------[ network ]---------------->PRESENTATION## Thin Client[ DATA ] + [ ALL THE LOGIC ] ----[network]----> [PRESENTATION]All the logic is performed on the server-side.Static pages that rely on page reload are THIN. The browser, AKA the client, just displays thecontent.
  46. 46. Fat clientDATA-------------------[ network ]---------------->ALL THE LOGIC + PRESENTATION## Fat Client[ DATA ] + [ ALL THE LOGIC ] ----[network]----> [PRESENTATION]All the logic is performed on the client-side.The server sends static content over the network, and all the logic is done in the browser AKAthe client.These fat clients rely on a lot of JavaScript and Ajax.
  47. 47. “Native Experience”People also talk about a “native experience” on the web.Ajax allows us to emulate a “native experience” on the web, meaning, it feels like anapplication not a web site.
  48. 48. “Native Experience”and controlling transitionsOne of the most basic features of a ”native” experience is the controlled transitions betweencontexts, 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 newcontext. We call these sort of sites that exclusively use Ajax “single-page apps”.
  49. 49. SINGLE-PAGE APPSAwesome or not awesome?So called “single-page apps” are very sexy these days. But people have begun to see thatsingle-page apps are also nasty beasts that bring all sorts of technical complications withthem.
  50. 50. SINGLE-PAGE APPSTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  51. 51. SINGLE-PAGE APPSback buttonTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  52. 52. SINGLE-PAGE APPSdeep-linkingback buttonTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  53. 53. SINGLE-PAGE APPSdeep-linking#! hash-bangback buttonTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  54. 54. SINGLE-PAGE APPSdeep-linkingJavaScript router#! hash-bangback buttonTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  55. 55. SINGLE-PAGE APPSdeep-linkingJavaScript router#! hash-bangback buttonwindow.historyTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  56. 56. SINGLE-PAGE APPSdeep-linkingJavaScript router#! hash-bangback buttonframeworkswindow.historyTrying 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 statein the application that we could not link to. We started to talk about how to “deep-link” to acontext within an application.This wasn’t (usually) a problem before we started using Ajax.
  57. 57. Let’s pause for a moment:Why do we want to use Ajax?What problems are we trying to solve with Ajax? i.e. what **benefits** do we gain from usingit?
  58. 58. Problems a fat client solves:Problems a fat client solves:* The user can continue to interact (including simply viewing) while data is exchanged.* The designer can customize and control the loading and transition experience betweencontexts.* Information can be presented in a partial, incremental, incomplete form, thus context canbe established while further information is retrieved. (Like a pan in a film, setting can beestablished in advance of details.)* The traffic between server and client can be reduced to data separate from the presentation,reducing network use and speeding up information transmission.Most of these are design problems. Even improved speed would result in a better experiencefor people.
  59. 59. Problems a fat client solves:• Continuous interactionProblems a fat client solves:* The user can continue to interact (including simply viewing) while data is exchanged.* The designer can customize and control the loading and transition experience betweencontexts.* Information can be presented in a partial, incremental, incomplete form, thus context canbe established while further information is retrieved. (Like a pan in a film, setting can beestablished in advance of details.)* The traffic between server and client can be reduced to data separate from the presentation,reducing network use and speeding up information transmission.Most of these are design problems. Even improved speed would result in a better experiencefor people.
  60. 60. Problems a fat client solves:• Continuous interaction• Transitions between contextsProblems a fat client solves:* The user can continue to interact (including simply viewing) while data is exchanged.* The designer can customize and control the loading and transition experience betweencontexts.* Information can be presented in a partial, incremental, incomplete form, thus context canbe established while further information is retrieved. (Like a pan in a film, setting can beestablished in advance of details.)* The traffic between server and client can be reduced to data separate from the presentation,reducing network use and speeding up information transmission.Most of these are design problems. Even improved speed would result in a better experiencefor people.
  61. 61. Problems a fat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingProblems a fat client solves:* The user can continue to interact (including simply viewing) while data is exchanged.* The designer can customize and control the loading and transition experience betweencontexts.* Information can be presented in a partial, incremental, incomplete form, thus context canbe established while further information is retrieved. (Like a pan in a film, setting can beestablished in advance of details.)* The traffic between server and client can be reduced to data separate from the presentation,reducing network use and speeding up information transmission.Most of these are design problems. Even improved speed would result in a better experiencefor people.
  62. 62. Problems a fat client solves:• Continuous interaction• Transitions between contexts• Incremental loading• Reduced network trafficProblems a fat client solves:* The user can continue to interact (including simply viewing) while data is exchanged.* The designer can customize and control the loading and transition experience betweencontexts.* Information can be presented in a partial, incremental, incomplete form, thus context canbe established while further information is retrieved. (Like a pan in a film, setting can beestablished in advance of details.)* The traffic between server and client can be reduced to data separate from the presentation,reducing network use and speeding up information transmission.Most of these are design problems. Even improved speed would result in a better experiencefor people.
  63. 63. Problems a fat client solves:• Continuous interaction• Transitions between contexts• Incremental loading• Reduced network traffic→ DESIGN PROBLEMS (mostly)Problems a fat client solves:* The user can continue to interact (including simply viewing) while data is exchanged.* The designer can customize and control the loading and transition experience betweencontexts.* Information can be presented in a partial, incremental, incomplete form, thus context canbe established while further information is retrieved. (Like a pan in a film, setting can beestablished in advance of details.)* The traffic between server and client can be reduced to data separate from the presentation,reducing network use and speeding up information transmission.Most of these are design problems. Even improved speed would result in a better experiencefor people.
  64. 64. Problems a fat client causes:Problems a fat client causes:* Routing becomes the responsibility of the client-side script instead of the browser -->deep-linking* History management becomes the responsibility of the client-side script instead of thebrowser --> back button* Caching (what and for how long) becomes the responsibility of the client-side script insteadof the browser --> reusing previously-fetched data and templates to achieve improvedspeed* Improvements from the speedy transmission are eroded by computation within the clienti.e. instead of doing computation in an environment we can control (the server) we push it tothe client, which is notoriously out of our control.These are technical problems. From a design perspective, these become trade-offs that are“someone else’s problem”.
  65. 65. Problems a fat client causes:• RoutingProblems a fat client causes:* Routing becomes the responsibility of the client-side script instead of the browser -->deep-linking* History management becomes the responsibility of the client-side script instead of thebrowser --> back button* Caching (what and for how long) becomes the responsibility of the client-side script insteadof the browser --> reusing previously-fetched data and templates to achieve improvedspeed* Improvements from the speedy transmission are eroded by computation within the clienti.e. instead of doing computation in an environment we can control (the server) we push it tothe client, which is notoriously out of our control.These are technical problems. From a design perspective, these become trade-offs that are“someone else’s problem”.
  66. 66. Problems a fat client causes:• Routing• HistoryProblems a fat client causes:* Routing becomes the responsibility of the client-side script instead of the browser -->deep-linking* History management becomes the responsibility of the client-side script instead of thebrowser --> back button* Caching (what and for how long) becomes the responsibility of the client-side script insteadof the browser --> reusing previously-fetched data and templates to achieve improvedspeed* Improvements from the speedy transmission are eroded by computation within the clienti.e. instead of doing computation in an environment we can control (the server) we push it tothe client, which is notoriously out of our control.These are technical problems. From a design perspective, these become trade-offs that are“someone else’s problem”.
  67. 67. Problems a fat client causes:• Routing• History• Caching and garbage collectionProblems a fat client causes:* Routing becomes the responsibility of the client-side script instead of the browser -->deep-linking* History management becomes the responsibility of the client-side script instead of thebrowser --> back button* Caching (what and for how long) becomes the responsibility of the client-side script insteadof the browser --> reusing previously-fetched data and templates to achieve improvedspeed* Improvements from the speedy transmission are eroded by computation within the clienti.e. instead of doing computation in an environment we can control (the server) we push it tothe client, which is notoriously out of our control.These are technical problems. From a design perspective, these become trade-offs that are“someone else’s problem”.
  68. 68. Problems a fat client causes:• Routing• History• Caching and garbage collection• Computation is outside of our controlProblems a fat client causes:* Routing becomes the responsibility of the client-side script instead of the browser -->deep-linking* History management becomes the responsibility of the client-side script instead of thebrowser --> back button* Caching (what and for how long) becomes the responsibility of the client-side script insteadof the browser --> reusing previously-fetched data and templates to achieve improvedspeed* Improvements from the speedy transmission are eroded by computation within the clienti.e. instead of doing computation in an environment we can control (the server) we push it tothe client, which is notoriously out of our control.These are technical problems. From a design perspective, these become trade-offs that are“someone else’s problem”.
  69. 69. Problems a fat client causes:• Routing• History• Caching and garbage collection• Computation is outside of our control→ TECHNICAL PROBLEMSProblems a fat client causes:* Routing becomes the responsibility of the client-side script instead of the browser -->deep-linking* History management becomes the responsibility of the client-side script instead of thebrowser --> back button* Caching (what and for how long) becomes the responsibility of the client-side script insteadof the browser --> reusing previously-fetched data and templates to achieve improvedspeed* Improvements from the speedy transmission are eroded by computation within the clienti.e. instead of doing computation in an environment we can control (the server) we push it tothe client, which is notoriously out of our control.These are technical problems. From a design perspective, these become trade-offs that are“someone else’s problem”.
  70. 70. Design problems afat client solves:Let’s look again at the interaction design problems that a fat client can solve.
  71. 71. Design problems afat client solves:• Continuous interactionLet’s look again at the interaction design problems that a fat client can solve.
  72. 72. Design problems afat client solves:• Continuous interaction• Transitions between contextsLet’s look again at the interaction design problems that a fat client can solve.
  73. 73. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLet’s look again at the interaction design problems that a fat client can solve.
  74. 74. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLet’s look again at the interaction design problems that a fat client can solve.
  75. 75. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMaintain contextLet’s look again at the interaction design problems that a fat client can solve.
  76. 76. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMaintain contextLet’s look again at the interaction design problems that a fat client can solve.
  77. 77. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMaintain contextEstablish contextLet’s look again at the interaction design problems that a fat client can solve.
  78. 78. Ajax → controls contextAjax allows us to establish and maintain the context for the user, without jarring reloads.BUT …
  79. 79. Ajax → adds complexityAjax 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 extrawork for developers.And that extra work might not be worth it. How can designers help developers be pragmaticabout when to use Ajax and when not to?
  80. 80. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingWhen we look at the problems that a fat client can solve, we can ask which one is the mostimportant?-> Continuous interaction is the primary reason we use Ajax. We use it during formvalidation, live chatting, commenting while watching a video
  81. 81. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMost importantWhen we look at the problems that a fat client can solve, we can ask which one is the mostimportant?-> Continuous interaction is the primary reason we use Ajax. We use it during formvalidation, live chatting, commenting while watching a video
  82. 82. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingMost importantWhen we look at the problems that a fat client can solve, we can ask which one is the mostimportant?-> Continuous interaction is the primary reason we use Ajax. We use it during formvalidation, live chatting, commenting while watching a video
  83. 83. Continuous interactionContinuous interaction is the primary reason we use Ajax. We use it during form validation,live chatting, commenting while watching a video, performing a search.
  84. 84. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingSo what benefit of Ajax is the least important?-> Transitions between contexts
  85. 85. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLeast importantSo what benefit of Ajax is the least important?-> Transitions between contexts
  86. 86. Design problems afat client solves:• Continuous interaction• Transitions between contexts• Incremental loadingLeast importantSo what benefit of Ajax is the least important?-> Transitions between contexts
  87. 87. New context? → Reload!When the user switches to a new context, the page can just be reloaded.
  88. 88. NO TRANSITIONS!?What about transitions?Transition are nice to have but not essential for most cases.
  89. 89. “The cool kids are doing it!”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.
  90. 90. Case study: Github
  91. 91. On github.com: a profile is a context, the repo file-browser is a context, and each pullrequest is one context, with page reloads in between.
  92. 92. On github.com: a profile is a context, the repo file-browser is a context, and each pullrequest is one context, with page reloads in between.
  93. 93. As we saw, Github is a collection of single-page apps, one per context, with page reloads inbetween.
  94. 94. AJAX vs RELOAD?So, when should you use Ajax and when should you use reload?Let’s recap:
  95. 95. Limit your demand for AjaxLimit your demand for asynchronous communication to only within the contexts that matter.Only use it when you can afford it.“Single-page apps” are often made as single-page apps for the wrong reasons. I have madethis mistake.Where is our need for Ajax? -- at the interaction points.
  96. 96. Find the interaction pointsFind the interaction points. Everywhere the user will click, type, hover or otherwise engagewith the interface.For each, ask: what benefit vs cost does Ajax have at that interaction point? Can we afford thecost? Where can we eliminate our need for Ajax?
  97. 97. Find the context boundariesKnow where the boundaries between contexts are, and communicate them to developers,because these are important for designing the application architecture.Using Ajax in at these interaction points give us the least benefit.Lastly, for developers:
  98. 98. Does your frameworkminimize your technical costs?Does your framework help solve the design problems while minimizing the technical costs?
  99. 99. Single-page apps? YES: we can help our users maintain context so they can focus withoutjarring interruptions. These means: use Ajax for each context, and each of those is its ownsingle-page app.Monolithic apps? NO: or at least, they aren’t nearly as useful as they are technically hard, andyou should be very clear of the costs. You may get so much benefit, or have so many peopleworking in the problems, that you can overcome the costs. Your *entire web app* does *not*need to be one single front-end app.
  100. 100. Single-page apps? → YESSingle-page apps? YES: we can help our users maintain context so they can focus withoutjarring interruptions. These means: use Ajax for each context, and each of those is its ownsingle-page app.Monolithic apps? NO: or at least, they aren’t nearly as useful as they are technically hard, andyou should be very clear of the costs. You may get so much benefit, or have so many peopleworking in the problems, that you can overcome the costs. Your *entire web app* does *not*need to be one single front-end app.
  101. 101. Single-page apps? → YESMonolithic apps? → NOSingle-page apps? YES: we can help our users maintain context so they can focus withoutjarring interruptions. These means: use Ajax for each context, and each of those is its ownsingle-page app.Monolithic apps? NO: or at least, they aren’t nearly as useful as they are technically hard, andyou should be very clear of the costs. You may get so much benefit, or have so many peopleworking in the problems, that you can overcome the costs. Your *entire web app* does *not*need to be one single front-end app.
  102. 102. QUESTIONS?and discussion@theophanispeakerdeck.com/theophani/cutting-the-fat
  103. 103. THANKS!All content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/

×