Making Magic Happen: Using Predictive Fetching in AJAX/RIA Applications

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

14 comments

Comments 1 - 10 of 14 previous next Post a comment

  • + eleonora300 eleonora300 3 years ago
    Andró via subito, non capisco niente ma lei sei un uomo che sá molto su la questione.



    Ecco!.



    Un saluto
  • + jboutelle Jonathan Boutelle 3 years ago
    This slide shows the paradox of you run into when you think about this issue. Both the cost and the value side of the equasion are influenced by your estimate of the chances the data will be needed.

    WE COULD TOTALLY DO A CHART HERE

    1)The fact that as the odd the data will be needed go down, the cost goes up and value goes down there will be a border, below which it doesn’t make sense to download.
    2)If you have no idea what the odds are the data will be needed, you have no way of knowing whether value is greater than cost. In this case it’s probably best not to download.
    3)The more important reducing latency is, the more preloading you should do, even if it means you are downloading data you don’t need.
  • + jboutelle Jonathan Boutelle 3 years ago
    has a cost. Server resources are scarce, especially for a web-scale application.

    Has a cost…implies that an economic model as well as an engineering model is needed for making this decision

    We need to think about the cost and the value of preloading data in a consistent way in order to perform this trade-off analysis.
  • + jboutelle Jonathan Boutelle 3 years ago
    Interesting topics of discussion:
    Pre-saving of data.
    tactics for reducing initial download time.
    Is giving design freedom to engineers a good thing?
    ROI of Rich Clients: where do they pay for themselves?


    So where do we go from here? Assuming you’ve squeezed all the latency out of your web applications, what are the logical next steps?

    One thing that I think will be a big deal in the near future for AJAX is pre-saving data. Instead of making users to explicitly save, you can commit their actions to the database as they do them, behind the scenes. This hasn’t come up yet because most AJAX applications are about data consumption, not data creation.

    The interesting thing is that this technological approach has led to a sea change in developer attitudes.
    Developers are for the first time trying to build models for how users behave, a task that has up until now been left to designers and user experience people.
    Once you get into the mindset of anticipating your users actions and needs, you are bound to write better software.
    It’s a big shift in attitude from the way things were before. And it’s bound to result in software that is much better than anything we’ve seen up to this point.
  • + jboutelle Jonathan Boutelle 3 years ago
    A neat hack that occurred to many RIA developers when trying to make their apps “feel” faster.
    Preload data.
    Done very informally (preload the next 10 records the user might see if they hit the “next” button).
    Like a good valet in a parking garage getting the car ready because the owner of the car goes to work at a regular time.
  • + jboutelle Jonathan Boutelle 3 years ago
    Flash-based RIAs
    As you can see, the logic and display elements of the application download at the beginning.
    Further requests are only for data: this saves bandwidth over time.
    Rule of thumb: if it’s an application that people are going to spend some time in, RIA will save bandwidth.
    If it’s a page that they will visit and move on, html is a better.

    The major disadvantage: the big download at the beginning.
    Fortunately, since it doesn’t contain data, it doesn’t change from one visit to the next, so it can be cached. But it’s still a disadvantage.
  • + jboutelle Jonathan Boutelle 3 years ago
    Build naïve model:
    Your initial predictions of what data will be requested by users should be informed by introspection and, if possible, usability tests.
    For example, on google maps, do users initially zoom in, zoom out, or pan left/right/up/down?
    A developer might assume that odds are equal for all actions.
    Usability testing might show that 80% of users immediately zoom all the way in.
    Entirely possible that the odds are not equal, that there’s a pattern. Usability testing on a mock-up design can answer these questions.

    Validate and refine model
    If you’re building a small application that isn’t very important than you can maybe stop there.
    But if you’re building a web-scale application, like the apps hosted by google, you’re just getting started.
    Need to get real-world data on what real users actually do with your system.
    Instrument your code so that you measure the user actions.
    Instrumenting has to happen on client (requests met by preloaded data will never make it to the server)

    Google maps example.
    Record user actions, send back a log of the actions to the server at the end of the session.

    Why are we building this model of user behavior? What’s the goal?
    Responsiveness: increase % of user requests met with pre fetched data.
    Easy to get high responsiveness by downloading all the data. But that effects your
    Efficiency: the % of pre-fetched data that ends up being used.

    Responsiveness and Efficiency trade-off against each other. It’s hard to increase one without decreasing the other.

    Focus on efficiency is important because preloading …
  • + jboutelle Jonathan Boutelle 3 years ago
    So to ground the discussion let’s start by looking at a typical web application, pre-ajax.

    Good points
    a) Easy for designers (page-centric, just like print media)
    b) Easy for developers (maps onto MVC model)
    c) Lots of mature tools to support this kind of development (e.g. struts).
    Disadvantages
    1)Sending Display (HTML) to the user each time!
    2)High latency because system waits for a user action (in the form of an httprequest) to do anythin
  • + jboutelle Jonathan Boutelle 3 years ago
    From a design point of view, a different metaphor is more useful.

    A good metaphor is a magic trick.

    The essence of magic is attention control.

    The effect of magic is created by diverting the audiences attention, and the crucial work is done behind the scenes.
    The audience sees the result of the work without having witnessed the work itself: “how did they do that? it was magic”.

    In this case you are focusing the user’s attention on the initial screen, and prefetching the information that will be needed later.
    When the user takes an action, the system response is instantaneous.
    The “trick” is making a browser window act like your own desktop.
    You user response is ideally “how did they do that? It was magic”

    With RIA /AJAX, no page refresh, more continuous experience,
    So you can drive the users attention to a particular section of the screen in a way that you can’t with web applications that load a page at a time.
  • + jboutelle Jonathan Boutelle 3 years ago
    The flow of an AJAX application looks pretty similar to an RIA.
    One difference: preloading of data is core to the definition of AJAX. An RIA _can_ have asynchronous data transfer. An AJAX application MUST have asychronous data transfer (it’s in the name).
    Result: picking which data to download becomes a major design issue for AJAX apps

Comments 1 - 10 of 14 previous next

Post a comment
Embed Video
Edit your comment Cancel

12 Favorites & 2 Groups

Making Magic Happen: Using Predictive Fetching in AJAX/RIA Applications - Presentation Transcript

  1. Making Magic Happen: Using Predictive Fetching in AJAX / RIA applications Jonathan Boutelle Uzanto
  2. Who am I?
    • www.jonathanboutelle.com
    • www.uzanto.com
    • www.themindcanvas.com
  3.  
  4.  
  5.  
  6. Vanilla Web Application ( circa 2000 ) Http request Initial Html User action Html (with data embedded) User action Html (with data embedded) … HTML Server Dbase User action requiring data User action requiring data
  7. Rich Internet Application ( circa 2003 ) Http request for app App (ActionScript & Flash) downloads Data UI Client Manager Server Dbase User action requiring data
  8. Rich Internet Application ( circa 2004 ) Http request for app App (ActionScript & Flash) downloads User action requiring data Optionally preload data UI Client Manager Server Dbase
  9. AJAX Application ( circa 2005 ) Http request for app User action requiring data Optionally preload data UI Client Manager Server Dbase App (Javascript & HTML) downloads
  10.  
  11.  
  12. Building a model of user behavior
    • Build naïve model
    • Validate and refine model
    • Be metric driven
      • Responsiveness: % user data requests that were met with pre-fetched data
      • Efficiency: the % of pre-fetched data that ended up being used
  13.  
  14. Download if value > cost
    • Value = value of reduced latency * odds the data will be needed
    • Cost = cost of download * odds the data won’t be needed
  15. Value vs Cost Odds a given piece of content will be needed $ Value = value of reduced latency * odds the data will be needed Cost = cost of download * odds the data won’t be needed
  16.  

+ Jonathan BoutelleJonathan Boutelle, 3 years ago

custom

9422 views, 12 favs, 0 embeds more stats

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 9422
    • 9422 on SlideShare
    • 0 from embeds
  • Comments 14
  • Favorites 12
  • Downloads 228
Most viewed embeds

more

All embeds

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories

Groups / Events