|
I’ve been chatting behind the scenes with Tim about his AJAX
“blogversation” for a while, but haven’t had the time
to add my own thoughts. (This of course has given me the advantage of
reading the other fine postings around this topic before I got going).
Now I’m keenly interested in what can be done to
get the interaction experience of the web closer to that of a
smart-client. And whilst it is impossible to take it the whole hog
– I figure that an AJAX approach can do enough to make a lot of
otherwise miserable interactions (when executed within a page-redraw
paradigm) at least bearable – and at best desirable. Hopefully we’ll even see a new breed
of app emerge that you wouldn’t even consider without an AJAX
approach….well see (the mapping apps from Google and MSN are probably
candidates for this).
So what I wanted to do was take a step back, and before
delving into some nitty-gritty ideas of what might be done to Tim’s  to
improve the interaction, I wanted to have a think about “AJAX
the big picture” –
the general structure and shape of this technology – and what it means
for interaction design. I also want to consider some of the problems AJAX throws up, and
I’ve seen some interesting insights on problems from this blogversation
already – so this process is very useful to me. [I’ll
probably do this over a number of different postings].
So first off, what’s the key point
of AJAX? For those of us who first started playing with the
XmlHttpObject way back in IE4 (or was it 5? Can’t remember now)
it was exciting times. This was a way to get away from that revolting
page-redraw. And this is the essence I believe of AJAX. I’ve seen people getting
confused with dragging-n-dropping, and dynamic updating on the client –
that’s all part of AJAX – but the defining quality of AJAX is that the dynamic behaviour of the
DOM is linked to server interaction. That’s the
point…get me some new data without redrawing the page, or persist my
change to the server without redrawing the page. Without that,
it’s just so much more eye-candy. That’s what we
we’re excited about in the early days, and then along came ASP.NET. The beautiful abstraction
away from the way the web-page actually worked into a logical event driven
model was so powerful, and so productive that we all pretty much forgot about
the XmlHttpObject, and happily went to work on our new toy -
WebControls. But now that the XmlHttpObject is back with a vengence,
all spruced up with a new coat of paint called AJAX… its time to figure
out how we can make it really work…
So I’ve been looking at all the great suggestions
people have been making in this blogversation, and thinking myself - what
kind of features would improve Tim’s -
and then it occurred to me – perhaps it would be useful to flip this
around. If we can provisionally agree (for the sake of this argument)
that page-redraws of the entire UI tend not to enhance the user experience,
then the question becomes:
What Features Wouldn’t Be Better With AJAX?
It’s not so much thinking up a unique ecommerce
feature (although that’s always good), just go to Amazon.com and there are boundless features
you could employ. The questions is, of all these cool features, what
wouldn’t work with an AJAX
implementation, or shouldn’t be done with AJAX….and why.
A couple of issues have been raised in the blogversation:
- Breaks the
URL system.
- Isn’t
supported by down-level browsers.
The second is important, but for the purposes of this
discussion I don’t want to dwell on it. The issue is germane to
any endeavour to push forward with dynamic interaction within the
web-browser. It needs to be considered as Tim’s is
a consumer product, not a controlled enterprise or intranet app – but
let’s assume for the moment that some kind of graceful fallback to
static HTML is always possible.
Breaking the stability of the URL system is
important. The example being - when using AJAX to navigate to products, “what if I want to send the page link to a friend”
(apologies for not linking, I went looking for who said it, I thought it was
in response to Nic’s
posting). Distinct URL’s are an advantage here, but there must be
some way around this issue. Off the top of my head, you could have a
“copy shortcut” button that uses JScript to copy an explicit link
of the product/filter to the clipboard.
Now, I wonder, what other kinds of
problems do you think are important enough to keep you away from AJAX? Or at the
very least, should give you pause…
(more soon…)
|