RIAs and the death of the page (rumors greatly exaggerated)

I’m in my final morning of the Information Architecture Summit in Montreal. One of the costs of staying in a cheap off-site hotel was that I didn’t have ready access to my computer (not wanting to lug both a PowerBook and the conference proceedings with me everywhere) and so haven’t blogged about the conference in the way I’d hoped. Maybe I’ll catch up, maybe not. I’ll start with a session for which I have notes at hand, the one on Rich Internet Applications (RIAs) by Dennis Schleicher, Jennifer King, Tara Diachenko, Pat Callow, Gene Smith, Livia Labate, and Todd Warfel.

RIAs are web apps which transcend the page-by-page model of web design (“the death of the page” was one slogan batted about at the session) and are built on platforms like Flash, Ajax and Laszlo. Advantages of RIAs include smoother transitions based on a wider variety of user inputs and more nuanced responses than the click-and-load model; lower latency because the app can anticipate user actions and pre-load what it will need next; and built-in media support that avoids the gotchas of external players. Some RIAs you may have seen include Gmail, Google Maps, Map of the Market, and Newsmap.

A couple of the presenters showed how they used RIAs in recent commercial applications and the rest talked about the potential and challenges to IA presented by RIAs. They saw the challenges as centering on matters like how to design cinematic elements like plot arc in an IA context and how to create wireframes with dynamic elements or some other method with which to communicate specs to developers. To further the discussion they’ve registered riaia.com, yet to be populated with content.

I have to say that I’m skeptical, not about the potential for RIAs but about the idea that their advantages exceed their disadvantages by enough for the “death of the page” to be remotely in consideration. One obvious problem is that the richest platform for RIAs, Flash, is proprietary and closed. Another which I asked about in the session but which wasn’t seriously addressed was what pageless systems mean for functionality like linking to, saving, and bookmarking content (to which in retrospect I would add harvesting, searching, syndicating and semantically marking content). The only item in this category of problems that got much discussion was how RIAs complicate web metrics (how to log and crunch stats on non-click-based interactions).

I find it curious that the panelists’ view of the challenges presented by RIAs was so IA-centered and not at all user-centered. I’m sure IAs will invent the vocabulary they need to talk to developers and if it means the death of the wireframe, then so be it. What matters most is what RIAs mean for users, particularly the loss of the affordances (see my shiny new usability vocabulary!) provided by the page model.

Taking my skeptic’s hat back off, there’s whizbang stuff going on in the RIA field, especially what Google is doing with Ajax. I hope the panelists do get riaia.com off the ground as a place to keep up with it.

10 thoughts on “RIAs and the death of the page (rumors greatly exaggerated)

  1. Wow. I’m slack-jawed at the acceptance and promotion of JavaScript in the Ajax model. Last time I looked at the web from this perspective, it was being roundly thrashed. I’m glad to see it make a comeback of this sort, since it’s so dang functional and utilitarian.

  2. I think the “roundly thrashed” thing was a response to articles like this one at boxesandarrows, which was pointlessly confrontational and unrealistic. The “death of the page” is far more palatable and reasonable than the “death of HTML.”

    BTW, the best example of Ajax I’ve seen yet, maybe even more elegant than Flickr’s use of it, is the business card generator here. (IE and Mozilla only, AFAIK).

  3. Andrew, I am the author of that B&A article. heh heh heh. ;)

    Anyway, I was telling it’s publisher that I want to write a new article very soon on this topic, but w/ a new perspective 2+ years later. But I’ll spill some beans here in reaction to your comment and in reaction tot he poster:

    1. Niether the page nor HTML is dead. the article wasn’t pointlessly controversial, it’s point is to be controversial, to move people out of their boxes and to be thinking about alternatives. The web has been stale for quite some time except for burts from Google. I find the infatuation with Blogware to be a technology distraction with a very good piece of content attached to it. while like HTML it is open, extensible, and easy, it is also not all that much of a leap from the previous set of paradigms. but I can go on there for quite some time.

    2. Prentis, brings up some great concerns. Many of which can be handled using the existing technology. Bookmarking, searching internally, even allowing for crawlers can all be handled in one way or another within the architecture of an RIA including a Flash-based RIA. You just need to dig a bit and you need to work at it.

    3. What’s in it for the user?
    a. My main problem w/ conventional HTML (not AJAX) is the obvious asynchronousity of it. that page flash is the most annoying thing since chalk on blackboard.
    b. HTML is not a contexutalized interface
    c. x-browser/platform support for HTML is a bear. Flash is a code-once distribute anywhere including the mobile device.

    4. Is all this to say that RIAs are done? NO WAY!!! I just through telling a vendor of RIAs that there is no one technology out there that is nearly good enough for the long term ubiquitous use of RIAs.

    5. BUT they are not without their uses. Let’s not dismiss them out of hand.

    also, I recommend that people read up on the other presentation about RIAs that to me was much much more important: “Beyond the Page” … not the page is dead, but that there are information and interaction models that we can consider (not go blindly into, but consider) that will open our minds to more possibilites for figuring out how to meet users’ needs. Options and more options.

    6. Flash is not closed. The flash authoring tool is, but there are other tools for creating SWF files and entire frameworks like Lazslo which are completely open source as well.

    So, I had the quote in the panel of saying, “the Page is Dead” .. it was later revised, “the Page is dead, long live the page.”

  4. I guess my reaction to all of this is somewhat different. I wonder if user experience is dead.

    I am raising the point somewhat provocatively and somewhat seriously. What strikes me in this game is dissemination of information in a *competitive* environment. As an information provider, do I invest in a given technology? Or am I better served investing in an API and letting promulgators of user experience compete for eyeballs?

    Amazon has done this with their RESTful API as has google with google maps.

    Mind you, both have invested in UX, but they’ve hedged their bets on that with the API.

    If we’re going to call a technology dead, then let me propose that we say so because the technology is no longer on the critical path to exploiting the underlying asset’s value proposition. If that’s the case, let me propose that the entire field of UX is dead for many purveyors of archival information.

  5. Scott, that WSJ article sounds interesting. I’m not a subscriber — would you be willing to mail it to me? Thanks.

    Bud, your point is indeed provocative. I think you’re right that it’s possible for some providers of content or services to offload UX to other parties. But for that to work, some conditions have to be met:

    (1) The provider has to have a revenue stream that works no matter who is providing the UX. In particular, the model of ads embedded in the UX won’t work. That’s why Amazon can make its API available for free and unmetered, but Google requires people to use Google Keys (at least they did for their main search the last time I looked).

    (2) If the provider depends on branding, the brand must survive the UX somehow — either through licensing or through the provider being clearly identified in the final delivery of items selected through the API (as in the case of Amazon).

    (3) The API must have been designed well enough to anticipate the needs of the UX designers and their end users. It’s easy to imagine situations in which too strong a separation between the two pieces of the process would lead to disastrous results. We saw this all the time in the client-server model — I’m thinking, for instance, of the mess that Z39.50 turned into. (At least it was a mess the last time I looked. Maybe it’s been resolved by now.)

    Any others?

  6. Prentiss, enjoyed seeing you in Austen quite a bit. I think the points you raise are legitimate. Recall that for some organizations, content will be a giveaway. Consider this blog for instance. You are actually offloading display for many of your readers. Here’s a point-by-point:

    “(1) The provider has to have a revenue stream that works no matter who is providing the UX. In particular, the model of ads embedded in the UX won’t work. That’s why Amazon can make its API available for free and unmetered, but Google requires people to use Google Keys (at least they did for their main search the last time I looked).”

    Seems a fair point, my only observation would be that people and entities give away information all of the time. Not doing UX might actually lessen the cost.

    “(2) If the provider depends on branding, the brand must survive the UX somehow – either through licensing or through the provider being clearly identified in the final delivery of items selected through the API (as in the case of Amazon).”

    Really? In the case of Amazon, they are doing it to get a revenue stream. Are you obliged by their TOS to display brand? At one point, I think you were not.

    “(3) The API must have been designed well enough to anticipate the needs of the UX designers and their end users. It’s easy to imagine situations in which too strong a separation between the two pieces of the process would lead to disastrous results. We saw this all the time in the client-server model – I’m thinking, for instance, of the mess that Z39.50 turned into. (At least it was a mess the last time I looked. Maybe it’s been resolved by now.)”

    This is clearly a giant issue. Six Apart is planning on incorporating AJAX into their product. A real big question what the API will look like. It is easier if you are willing to be more open about your overall architecture. Part of the issue with Amazon is that they insist on offering a completely encapsulated interface. This does not allow people on the UI end of things much lattitude in how the information and even what information is sent over from the server.

  7. I think we’re in agreement — yes, people give away info all the time, and the syndication of RSS feeds is a perfect example of handing the UX off to third parties.

    And I said if the provider depends on branding. Not everybody does.

    Your point about Six Apart and Ajax gets us back to where this conversation started: the “hooks” that RIAs do or don’t offer for operating on particular chunks of content. It will be interesting to see where Six Apart goes with this.

  8. “And I said if the provider depends on branding. Not everybody does.”

    Hey man, I’m in blog debate mode. Unable to notice subtlety in the other party’s argumentation.

    “Your point about Six Apart and Ajax gets us back to where this conversation started: the “hooksâ€? that RIAs do or don’t offer for operating on particular chunks of content. It will be interesting to see where Six Apart goes with this.”

    I’m in the process of posting on this topic here.

Leave a Reply