Ajax… About Time

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.

snapticket

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).
deposits_withdrawals_ui
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.

Anything But White Picket…

fence

What do you think of when you hear the word “fence” spoken aloud?

Unless you’re my friend Fleur (she’s a fan of the romantic sports), you probably lean towards the world of “things that stick in the ground and enclose other things” and you would be correct, as fences do just that; they enclose, divide, and protect areas and organisms for a variety of purposes.

If we can agree to such a broad definition, we should be able to agree that fences also define parameters of use, for if one can’t get past the fence, one can’t engage with anything outside (or inside) of its parameters.

Why am I fixated on the definition of a fence?

Well, a good deal of user experience design is centered around defining parameters; experiences that support specific goals rely on thoughtful crafting of usage parameters that work towards the needs of the user.

If that’s a vague concept, think about it in terms of designing a navigation system:

  • Does the top/down navigation live in a consistent pane in the interface?
  • If it’s located at the top of the screen, how does it behave?
  • Does it expand onRollover or onClick?
  • Does it display horizontally or vertically?
  • Does it employ hover states for greater affordance?
  • How does color and behavior reinforce the brand?
  • How is bottom/up exploration presented?

Before we get too granular within an imaginary interface, let’s step back outside for a moment and think about how we might design a fence in the real world.

  • The placement of corner posts could be determined purely on property lines or through specific requirements based on the needs of the owner.
  • The height of the fence, and its types of rails or wires, could be designed based on security requirements, or based purely on style.

When design attributes are specified, parameters of use spring to life. An experience is established through the simple process of reducing the environment from ALL variables to MANY variables (with an eye on reaching FEW variables)

These specific choices define how, say, a fence can keep sheep grazing within a field; or one that protects property in the midst of urban renewal; or one that surrounds a house at the end of a cul-de-sac.

Solution choices determine specific outcomes.

User Centered Design

Interactive design is an iterative process, a constant remodeling based upon the objectives and desires of both the business and the user of the system in play. But moving from good design to great design requires an effort of reduction to reach an elegant solution, where less is more and the complex takes form in simplistic presentation.

Back to one of our fence examples: lets say sheep are now grazing behind an elegant, rustic, utilitarian, wire fence with wooden posts. You’ve designed the perfect experience to meet the particular needs of your customer, and she is ecstatic with the outcome.

Congratulations, but don’t pat yourself on the back for long. As people engage with interactive spaces, priorities and needs will shift on a dime.

Tom_Sawyer_8c_1972_issue_U.S._stamp

In this out-of-control metaphor, imagine your ecstatic customer now telling you that her sheep are going to be racing for cash on the property across a range of individual courses, which will drive numerous betting options for the local yokels. For good measure, you also catch wind that other farmers may be using the property for similar purposes in the near future, but will most likely use more exotic animals than sheep; animals much faster and larger, with different maintenance needs and subtle details pertaining to optimal footing.

Each farmer is now a stakeholder in how the property needs to function, yet they each hold a different degree of say in the decision making process.

With multiple priorities and agendas in play while designing for an optimal experience of the overall environment, your general approach to quality design (reduction and elegance) remains steady, but the outcomes that you’re driving to meet must be continuously and iteratively redefined and understood.

One thing is for certain: you can’t possibly satisfy each customer requirement with a singular understanding of a fence. The challenge that lies on the horizon: How might you broker the definition of appropriate usage parameters moving forward?

You’ll need to meet each customer’s explicit needs, but not by making “fences” too complicated or by over customizing the experience to any one client need in particular.

You’ll need to be innovative with your solutions by keeping an eye on the underlying viability, usability, and usefulness of the environment that you help create.

You’ll need to be discrete in your approach to both understand and frame the outcomes that your designs ultimately serve, or you’ll never reach them.

Tom Sawyer has nothing on the challenge you now face.

This is Design.