Ajax… About Time
So it’s Friday night and I find myself cruising around the web after a night out and a tooth brushing away before a night in. In my travels, I landed on JJG’s blog and subsequently stumbled into his Ajax essay on the Adaptive site. I’ve got to admit something; before tonight, I’ve never read one iota about Ajax. The only real conversation I’ve had on the topic was a recent conversation with a client-side developer pal and after reading Jesse’s well defined description of the approach and the benefits. My initial reaction was pretty much, "well, duh!"
I don’t say that to offend Jesse, nor downplay the great client-side work anyone is doing right now, it’s just that I’ve been immersed in online application design for years now and have always tried to communicate these types of solutions to developers. I say "these types of solutions" lightly, as I’m primarily a designer, not a developer, so from my perspective these communication calls have been screaming to be stiched together for a while now. All said, I refuse to rake engineers over the coals. We’re here now.
Jesse spoke to the difficulties of designing online applications due to the technical workarounds which have been historically necessary to successfully support innovative interface behavior. While I agree with the level of difficulty, I disagree with the approach to design, for while practicing interaction design, I don’t model persona scenarios based on technological constraints. As David Fore of Cooper exhorts, the period of scenario modeling should be a period of making magic. That’s how innovation occurs while supporting user needs. I’d much rather engage an engineer in a position to support a brilliant solution than bland, useless features/interface behaviors. So first, come up with the right behaviors, then encourage technology to make it come to life.
Okay, that could come off as a bit pushy, unrealistic and non-tech savvy. One has to understand the constraints of the media when designing for it right? Sure. But not at the cost of potentially handcuffing a more useful experience by limiting possibilities. So how can one design for the user, while considering possibilities of Ajax?
While at Ameritrade, when the opportunity to start the UX Group came my way, I was lucky to be able to convince management to include our relatively small client-side development team in the mix. That brief organizational commitment created a huge opportunity for me to espouse innovation and collaboration across both designers and developers. I didn’t know how long the group structure would last, so I instantly switched up working from the level of context scenarios and began to approach the issue holistically.
We must have used the phrase "push the browser until it pushes back" more times in our weekly staff meetings than "war against terror" has been used in the White House over the past few years. Come hell or highwater, our (paying) client behaviors needed to be supported in our online applications, so in turn, I refused to limit us to any narrow definitions of client-side technology.
Thankfully, my CSD guys (and gal) latched onto my mantra with vigor and did the heavy lifting to evolve our conversations into their domain (code), while myself and the IxD’s returned to the iteration of modeling user needs into interface behavior. Did they use the Ajax approach per se? No, but they pretty much pushed the browser until their SOP—which supported the design team’s further pursuit of forward thinking behavioral patterns—is now reflected in some of the latest Ajax app behaviors, such as Gmail. Business as usual of design and development at Ameritrade started to evolve.
Were the solutions as soundly executed across the board as the current Google attempts in leveraging the Ajax approach? I’d have to say no again, as we were performing Ajax-type workarounds on the fly. But the mere fact that the team addressed dynamic interface scenarios on a case-by-case basis, with dynamic executions on the presentation layer,
led our marketing group to center their next campaign around the slogan, "Welcome to the 21st Century. Now trade like it." The ripple
effect of the progressive experience design was contained, as it only applied to the authenticated, Apex trading platform, but Barrons seemed to notice it by giving us a 4 star rating (up from 2.5 stars the previous year).
A switch to a complete Ajax approach at Ameritrade today would entail a short period of refactoring, but would make the current authenticated interface move from "singing" to "harmonizing."
As long as the IT politicians and system managers keep their paws out of coding philosophy, Ajax should mark the sweet spot of the golden age of presenting complex scenario relationships as simplified behavioral experience in the browser. Elegance in action. Personally speaking, I just never want to hear "that’s not feasible" again when proposing the design for such a dynamic solution.
Remember Belushi’s reaction to the insipid acuistic guitar love song in Animal House? Exactly.
Tags: Adaptive Path, Ajax, Ameritrade, Animal House, Apex, application, Barrons, behavior, business, collaboration, evolution, experience design, Gmail, Google, holistic, innovation, interaction design, interface, internet, Jim Belushi, marketing, methodology, philosophy, portfolio, progressive, scenario, World 2.0.Search
No Tweets RSS feedLatest Posts
- album cover finished… whatch…
- working on designing the "…
- booker doesn’t tell band that …
- at 6th & vine in W-S, havi…
- checking out uncg’s master of …
- taking a prop plane from LGA t…
- can everyone thumbs up this sh…
- mixing down the recording of t…
- FREE. SORRY ABOUT DRESDEN. 30 …
- and the show is a go!
What I Write About (see all)
- 9 11 accountability activism Adam Smith Problem advertising America antiwar artsy fartsy blogging business capitalism change citizen media community Congress corporation corruption creativity disturbing experience design film funny George Bush government graffiti Greensboro Hip hop humanity information architecture innovation inspiration internet Iraq War journalism lyrics media music New World Order New York City North Carolina personal philosophy photography poetry politics reality Republican Party terrorism video World 2.0
Sean — I’m getting into Ajax big time over with the new project on unto.net. It’s a client/server application that is relying on Ajax techniques to provide a rich user experience. While the focus is mostly on the backend thus far, the whole architecture is designed to support a web-services (and REST) approach so that powerful Ajax clients can do more in the browser.
Help me out with this REST concept, as I’ve only encountered it briefly. Is it basically an attempt to create “floating” states of interaction with any representation of a resource found online, so movement between one and another is just a change of state and not a call to a server? And then Ajax would serve as the initial load and the Dutch boy to plug calls as necessary?
It stands for Representational State Transfer, and it is basically what the HTTP request types, such as GET, POST, PUT, DELETE, were designed for. It allows you to create service APIs that operate at the HTTP layer, such as getting a customer record, updating their data, and whatnot. The difference between this and popular RPC (remote procedure call) methods like CORBA and SOAP is that it is all transparent and takes advantage of standard web protocols and such. Done right it can be very elegant and simply feels better. It puts the emphasis on the URI rather than the payload, which makes exposing services to any client (not just an Ajax client) all that much easier.
Okay. That actually made sense to me. Forgive my giddyness when I find that actual development approaches represent my conceptual understanding of possibility. I guess I need to fully embrace my “geekness” and start digging into the client/server side more. It’s just that it’s so much nicer dealing with people and behavior. ;)
The client side bunch are trying to impose this Ajax thingee on the “site”. That in itself makes me suspect… Nah, it looks good but it’s going to take some heat by being a term coined from those …ahem…designers.
I heard about that. It’s funny, people are scrambling across the industry to “design for Ajax” instead of just designing the right interface behavior for the user. Ameritrade can refactor a lot of what’s up there because the behavior is spot on (or there are solid sketches hanging to the side that can be refactored and iterated taking Ajax possibilities into account). If Amazon, Yahoo! and Google had used the approach superficially, then I’d like to think that we wouldn’t be talking about it. (except for the geek factor of presenting asynchronous communication between the interface and a data source)
So yeah, the next few years of designing smart, online applications, research, contextual navigation, etc. has dramatically opened up regarding development possibilities, but once adopted, Ajax should be just another development approach to supporting smart user experience design. Anyone that calls themselves a designer and works in reverse is doing themselves, the business and the user a disservice. That would just be “shiny” design on another level.