Monday, October 6th, 2008

Ajaxified Body; When to refresh the page

Category: Ajax

Matt Raible has posted on the Ajaxified Body pattern, that loads content into the main area instead of reloading an entire page.

The surrounding template stays put, and the red area changes when you have an action:

This is an old question: “When should you just reload the page?” In the sample application you see the trade offs. Every click causes a red “Loading…” indicator, and just the main area changes. The browser doesn’t have any indication that something is happening, hence the need for the custom red indicator. You also then have to implement support for browser history, make sure that direct access works and the like. The positive is that you don’t get a refresh flash, but is that enough to warrant the change?

One of the use cases on the page is the rich table component. That should definitely be able to refresh and page without the page changing, but when the main content gets swapped in, I start to question. What do you think?

Matt uses SiteMesh, a great technology that can knit together the look and feel, and can fit in very well in this kind of world. If a browser goes directly to a page it can piece together the entire page, but an Ajax request can come in and it can just send back the main content. Very nice.

Posted by Dion Almaer at 10:29 am
18 Comments

++---
2.6 rating from 68 votes

18 Comments »

Comments feed TrackBack URI

I think the question should shift to time and cost as well. I mean time is money in this industry. Is it worth spending hours of coding to get rid of a refresh flash. I personally don’t think so. I would rather spend that time increasing the user experience in more dramatic ways.

Comment by JaxPhper — October 6, 2008

Handling the browser’s back button has been the biggest challenge when the entire page is not refreshed. The bookmarking is other. Even though it makes a lot of sense, technically, to refresh just the content area, the users are tuned to the browser’s back and forward buttons for navigation. While there are ways to handle the browser’s back button in Javascript (Dojo has one of the decent implementations) the user experience is simply not the same. One of the approaches we experimented is to build the pages from templates, where each component such as the header, footer, sidebar etc., is an HTML page in its own right, which has cache control enabled. So when the top level page refreshes, the components are served from the cache with only the main content loaded from the backend. So, the page loads fairly quickly though not as smooth as using XHR to load the content. But, the user experience is not hampered, not their ability to navigate back and forth, bookmark the pages and so on.

Comment by ragjunk — October 6, 2008

Is it worth spending hours of coding to get rid of a refresh flash?

Maybe not, but if the majority of a page’s content is in the header/footer/menu, then it might make sense. Especially if you’re trying to satisfy Rule #1 of best practices for making web pages fast. Yes, browser caching should help, but it often doesn’t solve the inline script blocking issue.

Comment by mraible — October 6, 2008

This is a valuable pattern in web design, but it’s most appropriate when the content outside of the red square has transient state that is related to the content inside the square. For example, if there were a JavaScript hierarchy (tree) outside the square that the users traverses (maybe many levels deep) and when the user selects an element in the tree the red square is loaded with associated content… this would be an excellent use of this technique. The worst use of this technique is to use it for framing (headers, footers, sidebars) which essentially makes it HTML frames!

The short of it is… good in web apps… bad in websites. :)

Cheers!
-Quin’

Comment by MattQuinlan — October 6, 2008

@JaxPhper:
whether it is worth or not heavily depends on the need for agile response. Websites with an old-style loading sequence will not replace proprietary intranet DB interfaces, while fullAJAX webapps definitely have that potential – simply because they are that “little tick” faster. Knowing that, AJAX applications will cut software cost to a fraction of what it was before. Furthermore AJAX allows for a much more structured approach when implementing a complex application ( see SOA ). I didn´t even mention that this way you will automatically become client side system independent in regard of DB handling. All these are good reasons to spend an extra buck … btw coded in the right way an AJAX app is not that much more expensive than a standard webapp.
@ragjunk:
I agree on -history and -bookmark problems. But I have objections to all of these arguments:

(1) the history, from the beginning in the first browsers, is a page oriented functionality. I agree in that users are used to it. But a back button may not make sense in a full ajax app that simultaneously shows more than one form(s) and articles(s) – all of these dynamically generated during user workflow. What would a back button be good for here, granted you have more than one workflow open? A back button can only apply to ONE OF THEM – which one would it be? The simple solution to it is providing “back buttons” directly in the “viewport” that displays a single workflow/process.

(2) bookmarks: same rule applies, since there is probably not a distinct single bookmark possible to describe the page state. Solution is pointing to a print / bookmarkable version of the content, again at the viewport the information is displayed in, and onClick open a popup – uuuuups I said the bad word – window. The user will get used to it.

Overall it is a chicken-egg problem. People tend to believe “we must support the back button”. Not true. New technologies call for new solutions. The goal is to make the user forget about the browser back button by presenting him an application back button where needed.

Comment by Frank Thuerigen — October 6, 2008

With this technique the browser will not process scripts/css files, which results in faster page visualization.
That being said, maintenance cost grows big time.

Comment by icoloma — October 6, 2008

@icoloma:
not true, depends on technology… see http://www.two-birds.de use firebug to examine net traffic…

Comment by FrankThuerigen — October 6, 2008

I have been working on especially this type of application coding for some time, so I think I should say something about it in general:

IMHO one should always check assumptions… e.g. if someone says “we must support the back button because the user is used to it” – the first questions should be “why is the user used to it?” and “what can we do to make the user forget the back button?” …

It may not apply to all cases – but thinking about it always helps.

Comment by FrankThuerigen — October 6, 2008

Not much room for errors … progressive enhancement anyone?

Comment by MorganRoderick — October 6, 2008

@Morgan: how do you mean that? I didn´t get the point…

Comment by FrankThuerigen — October 6, 2008

Looks like it is broken on Safari…
It also looks like the UI sucks a bit. Please at least change cursor to “wait” when content of the box is being refreshed. It would help a lot.

Comment by michalfrackowiak — October 6, 2008

works on safari for win here at least…

Comment by FrankThuerigen — October 6, 2008

Yes, it is a chicken-and-egg problem. It is not so much on the back button support to navigate the pages in the “current application”, but what happens if the user accidentally goes to a page from different domain in the history and then comes back. Consider the following example:
1. User goes to http://demo.raibledesigns.com/ajaxifiedbody/ and selects, “Users” tab.
2. Clicks on the Back button. This will show the previous page wherever the user was.
3. Clicks on the Forward button. The default page (Home) is displayed, instead of “Users.” In other words, the context is lost.

If the site requires authentication, I would assume that information is lost too, forcing the user to relogin, which results in unpleasant user experience. So, again, it is not so much about supporting old habits, but making sure that the Ajax application maintains proper context, so the user experience is not compromised.

Comment by ragjunk — October 6, 2008

@ragjunk this can be handled by storing the pages current stage in a session, but won´t help for bookmarks obviously.

Comment by Frank Thuerigen — October 7, 2008

If all this does is load html fragments over xhr, I have my doubts that its worth it. To each their own, though, I suppose. The major jump in benefits comes when you have a lot of javascript (even something cached needs to be re-parsed and executed) or want to maintain client state in the browser. While not something that is really necessary for web pages, complex web apps can require a lot of client state. It takes a little work to reach the point where the server side maintains no state at all, but when you get there its a huge shift. The server becomes a place that can be focused purely on data and business logic. Using REST services, the data can be directly retrieved and used in the browser. It is incredibly scaleable and fast too.

Web pages may use some of this technology eventually when all browsers work in ajax history and bookmarking, but I predict that within the next couple of years single page applications will become very commonplace.

Comment by genericallyloud — October 7, 2008

Doesn’t take the concept NEARLY far enough IMNSHO.

It still loads HTML which can only be processed by setting some existing element’s innerHTML property. This limits scripting ability, and means the new HTML won’t be part of any existing Javascript-managed structures.

What is REALLY the future is loading the next “Page”‘s JSON description. A fully configured literal which completely describes the page and all the widgets. This is instantiated and added into the javascript layout.

Of course this is dependent on the javascript library you use. I use a one-page app which loads components as JSON configs. No HTML is used at all. The hit of loading a large javascript library and the UI building code is taken only once. From then on only metadata (component configuration) and data are transferred between browser and server.

In fact its better than that. You can click “navigation links”, and the component will ba ajax-loaded into the page’s “content area” as a pure config.

But if you RIGHT CLICK and open in new tab or open in new window, a whole new page is generated with the requested component embedded. Best of both worlds.

Comment by DataPlumber — October 8, 2008

@dataplumber: that is also an interesting approach… i´d like to see that can you provide a link?
Whether one or the other approaches will be the future only the future can tell I think.
Other than that – if you parse a JSON data structure to create DOM elements from it, it is almost the same as creating these in code as other GUI libs do, which comes at an added speed penalty.
It is interesting that the whole theme complex ( innerHTML vs. createElement ) still sparks that much discussion. I think there are good reasons for both approaches – depending on the project requirements.
Roll on, gentlemen!

Comment by FrankThuerigen — October 8, 2008

While coding an AJAX based application developers tends to neglect that fact that there may be times when web server can be offline or down. Here is a nice article which deals with it http://www.hurricanesoftwares.com/ajax-should-not-mandate-http/ We should not mandate AJAX.

Comment by riteshchopra — October 21, 2008

Leave a comment

You must be logged in to post a comment.