1.3. Ajaxifying the Web: The Story of Portals
If you Google for "year of the portal", you'll find ample evidence that every year since 1996 has been the year of the portal. It's just around the corner, really. The idea has so much promise: the first thing you see when your browser opens up is a personal homepage with "My News" and "My Mail" and lots of other boxes just about "Me." In short, a page created by Me for Me. So why have they never really taken off? One big factor is that most portal interfaces, frankly, are unusable.[*]
[*] There are several problems with portals that Ajax can't solve on its own. Most importantly, the fact that portal servers don't know what you're doing in the browser most of the time suggests that some kind of browser plugin is necessary. Nevertheless, Ajax remains the most obvious way to create the Web interface to any such system.
Consider the problems you face in using a legacy-style portal, using Excite.com as an examplemany other conventional portals work in a similar manner (Figure 1-1).[*]
[*] I'm not picking on Excite, which gained a lot of interest and did some good things with the technology that was available at the time; its inclusion here is testimony to its status as the quintessential example of the first generation of portals.
Figure 1-1. Excite
Customizing the page is the most critical task, but you have to register first; each of the customization controls on the homepage will close the portal and take you to a completely different registration page.
Adding new "portlets" the blocks of contentis rather painful. You have to click on Add/Delete Content, which will whisk you off to a tabbed configuration interface. There, you add and delete portlets by updating a list of current portlets.
Customizing an individual portlete.g., setting the stocks you're watchingwill close the portal and send you to a special configuration page. You've lost the context.
Changing layout doesn't happen directly on the page, but in the configuration area. The layout is managed on a miniature model of the real portal, with titles shown only. (Some portals require repetitive clicking on arrow buttons for layout; fortunately, Excite allows drag-and-drop on the model.)
Volatile content such as news and market information is present on the page, but refreshes occur only occasionally; the smallest allowed period is five minutes. Refreshes force the whole page to be reloaded, which is not only distracting, but also makes it difficult for the user to see what, if anything, just changed.
You can't interact with individual portletsfor example, to perform a search. Any time you act on a portlet, such as submitting a form from it, the entire page will update or you'll be sent to a new location.
Portals are so well-suited to Ajaxification that they are probably the most widespread Ajax genre right now; editing the Ajaxian.com blog in late 2005, we reached a point where we were hearing about two or three new Ajax portals a week! Some, like the popular NetVibes (http://netvibes.com) and Protopage (http://protopage.com) products, are startups. Among the more mature portal producers are none other than Google (http://www.google.com/ig/) and Microsoft (http://live.com). An explanation follows of how Ajax rectifies each of the problems mentioned above, using NetVibes as an example (Figure 1-2).
Figure 1-2. NetVibes
When a new user visits NetVibes, she is free to add and manipulate content, which will stay there for the next time she logs in from the same browser (via cookies). As explained in Lazy Registration (Chapter 17), this has always been possible, but Ajax makes the customizations richer and the transition to registering smoother.
Clicking on NetVibes' Add Content link doesn't cause a disruptive new page to be shown. It is simply the appearance of a new column (an example of the Microlink pattern). There, you can choose new portlet types and watch them appear instantly in the portal. Thanks to the remoting and display manipulation technologies of Ajax, a browser app can talk to the server and update elements without forcing a page refresh.
Portlets are customized in-page and without disrupting the other content. Clicking on an Edit link will lead to a small customization form being squeezed into the portlet (an example of Malleable Content). There's no page refresh involved, and you can see the effects of editing immediately.
Changing layout is as effortlessand funas dragging portlets around the page, discussed in Drag-And-Drop (Chapter 15).
Portlet content is updated directly and without page refresh. Moreover, each portlet is refreshed on its own schedule. In theory, the weather portlet could be updated once a day; the news portlet every five minutes; the stock portlet each second, as explained in Periodic Refresh (Chapter 10) and in Portlet (Chapter 15). When a portlet updates, an effect like those described in One-Second Spotlight (Chapter 16), can be shown for the sake of user feedback.
You can have a conversation with an individual portlet, clicking on controls and watching it update. It's as if the portlet is a mini-page; no page refresh occurs and no other content is affected.
The story of portals demonstrates how Ajax can radically improve the usability of a well-established web genre. Indeed, Ajax is breathing new life into many genres that, like portals, had stagnated. Flickr is an Ajax-heavy update of the old photo-sharing category. Gmail (http://gmail.com)reinvented webmail, Google Maps (http://www.googlemaps.com) reinvented maps, and Google Suggest (http://www.google.com/webhp?complete=1&hl=en) opened up new possibilities for search and data entry. Newer genres like RSS readers, wikis, social bookmarking and tagging are also benefiting from Ajax.