Wrong confirmation ID

Email
Favorite
Favorited ×
Download
Embed
Contact Me
Private Content
Copy and paste this code into your blog or website Copy Customize… Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
+

+ Follow

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

by Jonathan Boutelle on Jun 01, 2007

104 views

More…

Less

Statistics

Favorites: 14
Downloads: 240
Comments: 0
Embed Views: 0
Views on SlideShare: 104
Total Views: 104

Introducing myself. I’m Jonathan Boutelle, a Principal at Uzanto Consulting www.uzanto.com We’re a company with offices in South Delhi and Silicon Valley. We have a couple of practices 1)User Experience practice 2)Rich Internet Applications practice As a result of the RIA , I’ve been thinking about zero-install, web-based applications for a couple of years, and blogging about them for about a year or so www.jonathanboutelle.com It turns out that RIAs and AJAX applications are very similar, so most of the stuff I’ve written about RIAs applies to AJAX applications as well.
Common Ground Reducing system latency (the time that users are waiting for the system) is an uncontroversial goal. Developers and designers, even if they agree on little else, agree that fast systems are much better than slow ones. In fact, speed is an intuitively valuable attribute of an application. A good way to articulate the value of rich clients is to frame it in terms of making more responsive applications. From an engineering perspective, making faster applications is a basic part of the engineering job description: making the most performant system, given existing hardware constraints. There are two strategies to squeeze more performance out of a system: optimizing the actual execution of code, and harvesting unused system resources to do work before the user asks for it. AJAX is an example of the latter case. Even MBA’s understand that fast applications are better! So if you’re pitching to a business decision maker, this is a good way to frame the value of AJAX.
What does valet parking have to do with AJAX. A good metaphor for this is a valet in a city parking garage. If you park your car in a garage, and you go to work at 9AM on Monday, the valet will take about 5 min to get your car. When you come at 9AM on Tuesday, it will still take 5 minutes. When you come at 9AM on Wednesday, it will take 5 minutes. On Thursday, when you arrive, something will be different! .On Wednesday, go to work every day at 9, you’ll soon find that your car is waiting for you when you arrive. The valet has noticed the pattern in your behavior, and is optimizing things by fetching the car in advance, so that it’s ready when you arrive .
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.
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
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.
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.
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
To do effective preloading you need two things The first is some kind of predictive model that tells you which data is most likely to be requested.
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 …
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.
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.
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.

14 Favorites

Robson Silva Espig , Software Developer at Espig 2 years ago
Bi Oliveira 2 years ago
André Huf 4 years ago
Alexey Tigarev , freelance software developer / team lead at None 4 years ago
Martin Kalfatovic , Librarian at Smithsonian 4 years ago
My own sweet home at My own sweet home 4 years ago
DigiConsult at DigiConsult 4 years ago
ashishsinha 4 years ago
Golak Sarangi , web developer at Slideshare 4 years ago
Luigi Puzone , ICT Project Manager / ICT Professor at Italian Court of Auditors / University of Ferrara / University of Rome "Sapienza" 4 years ago

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

Making Magic Happen: Using Predictive Fetching in AJAX / RIA applications Jonathan Boutelle Uzanto
Who am I?
- www.jonathanboutelle.com
- www.uzanto.com
- www.themindcanvas.com
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
Rich Internet Application ( circa 2003 ) Http request for app App (ActionScript & Flash) downloads Data UI Client Manager Server Dbase User action requiring data
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
AJAX Application ( circa 2005 ) Http request for app User action requiring data Optionally preload data UI Client Manager Server Dbase App (Javascript & HTML) downloads
Building a model of user behavior
- Build naïve model
- Validate and refine model
- Be metric driven
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
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

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

by Jonathan Boutelle on Jun 01, 2007

Accessibility

Categories

Upload Details

Usage Rights

Statistics

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