Oreilly AJAX summit

I’m at the Oreilly AJAX summit today and tomorrow (speaking later today).
Here’s the speaker list and the wiki.
Right now Jesse James Garrett has just wrapped up the keynote. No surprises so far

His list of the challenges in using the AJAX approach is reasonably complete (and a bit daunting). Here it is:
AJAX Challenges (technical and design)
1) Back button (making it work)
2) Accessibility (making it work)
3) REST and bookmarkability (making it savable)
4) Cross-browser implementation (making it work)
5) Server performance (making it affordable)
6) Graceful degradation (making it work for everybody)
7) Privaty/security (making sure having logic on client is safe)
8) User behavior metrics (collecting this data is harder with AJAX (because some interactions are purely on the client)
9) Design documentation (how does a designer describe what he wants built? A screen layout doesn’t capture it anymore)
10) Development tools (current tools are primative)
Getting smart about appropriate uses (many bad Ajax applications on the horizon)
He also covered some interesting aspects of Ajax interaction design
Interaction Design For AJAX
1) Everything is alive (conventions for what user can interact with are broken by AJAX)
2) Implicit user actions //focus/blur/hover. (Users don’t think of these as actions, but we can use them as actions to hook code to
3) Prefetching (pulling data incrementally as we anticipate needs of users: Key to AJAX)
4) Action at a distance (a change in one place can have ramifications across the entire interface).
More notes as the conference progresses.

7 thoughts on “Oreilly AJAX summit

  1. John Dowdell May 9, 2005 / 11:40 am

    “Back button (making it work)”
    How should it work? Is there a consensus yet on either of the two positions:
    (a) a web browser’s “Back” button is used to navigate among documents; or
    (b) a web browser’s “Back” button should be used for document navigation but should automagically know when to switch to “Undo” within a single-document application interface.
    (The second seems implied in many conversations, but such smart switching between navigation and “undo” functions seems difficult to do within just a document… seems more like a browser decision than a document decision…?)
    tx, jd/mm

  2. jon May 9, 2005 / 12:20 pm

    “Undo” as in making state changes happen? No, definitely not. “Undo” as in seeing the previous states? Yes definitely.
    For example, we saw a demo from a company (unnamed) that showed renaming the title of a photo. Then moving to the next screen, then back-buttoning. In the previous version, the “old” title showed up (even though the “new” title had been saved to the server. In the new version, the AJAX code was smart enough to know the title had been edited and go back to the server to fetch the new title.
    So it should show the previous “screen”, and if it’s a one-screen dynamic action it should walk back up through the different screen views (e.g. the navigation path through the google maps interface). But it shouldn’t write anything. I think that’s the consensus

  3. M.J.Milicevic May 9, 2005 / 1:29 pm

    at backbase we can define which user actions are stored as history item. works well for us, you can check our site for a demo:

  4. John Dowdell May 9, 2005 / 8:15 pm

    Sorry I wasn’t clear — is the desired behavior such that, every time the browser’s “Back” button is clicked, it goes back to the previous document the browser knows about, or not?
    (I’m wondering whether “make the ‘Back’ button work” has any browser dependencies, or whether the functional definition of that phrase would work across all current browsers, thanks.)

  5. David May 10, 2005 / 3:46 am

    Whenever I hear the issue of documentation changing w/ AJAX I get really concenred. The reaons is, and this is what I felt at IA Summit when this came up is that people have been documenting dynamic software way before the Internet. So I just don’t see why AJAX, or RIAs in general change this. It changes it for web designers, but it doesn’t really change anything from software designers. Interactivity is WHAT we do.

  6. jon May 11, 2005 / 1:28 pm

    Most desktop software engineers wrangle pre-baked components into UIs. Being a java swing programmer, for example, _really_ limits the options you will consider in a user interface. AJAX has a LOT more flexibility: it’s like doing desktop programming before there were windowing toolkits. I don’t know what that was like (before my time), but my guess is that at that point, usability was really backburnered, and most software was really hard to use. We don’t want to go back to the future like that.

  7. Robert Bousquet May 11, 2005 / 5:10 pm

    On the other hand, the maturation of these techniques provides another wedge for taking the user to i+1 in terms of their proficiency with web interfaces and the erosion of the static page/refresh paradigm.
    Usability will definitely be a critical component to the success of Ajax interfaces and keeping advancements to web experiences within the user’s zone of proximal development.
    Ajax, like any technology (HTML included), provides plenty of rope for designers and programmers alike to hang themselves or be on the cutting edge.

Comments are closed.