So it’s Friday night and I find myself cruising around the web after a night out. In my travels, I landed on JJG’s blog and subsequently stumbled into his Ajax essay on the Adaptive site. 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, “ok.”
I don’t say that to offend, 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 attempted to communicate these types of design solutions to developers. I say “these types of solutions” lightly, as I’m a designer, not a developer, so from my perspective these communication calls have been screaming to be stiched together for a while 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 on the impact on next-generation type apps, I disagree with the approach to design, for while practicing interaction design, scenarios shouldn’t be modeled 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 to support user needs; the limitations of the front-end evolve over time. I agree that one has to understand the constraints of the medium when designing for it, but only to a degree, otherwise one can handcuff a more useful experience by setting the box too tight.
So how can one design for the user, while considering possibilities of Ajax?
While at Ameritrade I was able to convince management to include our relatively small client-side development team in my UX team. 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 iterate on features
We used the phrase “push the browser until it pushes back” more times in our weekly staff meetings than could be counted. Our 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 team latched onto my mantra with vigor and did the heavy lifting to evolve our conversations into working code, while myself and the IxD team returned to iterating user needs into interface behavior.
Did the team use the Ajax approach per se? Probably not, but they pretty much pushed the browser until their SOP is now reflected in some of the latest Ajax app behaviors, such as Gmail.
Business as usual for design and development at Ameritrade began to evolve.
Were the solutions as soundly executed across the board as Google’s current attempts in leveraging an 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 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.”
Ajax should mark the sweet spot of the golden age for presenting complex scenario relationships as simplified behavioral experience in the browser.
Elegance in motion.
