Ajax design terminology

~ 25 October 2006 ~

JARGON ALERT: UI = user interface; GUI = graphical user interface, or the older brother of the younger, more attractive “UI”. (The tech-savvy girlfriend who flirts with UI is “UX”, wherein X = experience.)

The line between “desktop UI” and “web UI” is gradually blurring. Love it or loathe it, “Ajax”, which originally referred to Asynchronous JavaScript + XML, has somehow become the catch-all term for describing “desktop-like” interaction on the web; more accurately, GUI interaction as seen previously only in native applications running in an operating system environment. (Or was that “Web 2.0” that’s become the catch-all misnomer?)

It’s safe to say nearly all of you, whether aware of it or not, have been exposed to Ajax implementation on the web. Gmail, Yahoo, and plenty of other high-traffic sites have been using it to enhance interfaces, some even for a couple years now. A fair share of you have have developed sites and apps that employ Ajax, and those who haven’t will probably do so within the next 6-12 months.

The point of this article is to associate traditional GUI terminology with desktop-like web UI interaction. Credit for this terminology must be given to the following, both of which are fabulous resources:

Designing Interfaces by Jenifer Tidwell
“First Principles of Interaction Design” by Bruce Tognazzini

While there are many terms to describe UI interaction, I’ll explain only four as related to desktop-like interaction, along with a few brief screencasts to demonstrate each term. It’s also important to note that true Ajax implementation — interaction with the server — isn’t always required for each of the items below; sometimes only DHTML or JavaScript is required, but more often than not Ajax integration is present nonetheless. (This article neither promotes nor discourages the use of Ajax, but rather leaves the judgement of such to those involved in its deployment. *washes hands*)

Responsive Disclosure

The UI grows dynamically as additional elements are requested by the user.

Responsive disclosure is the act of “disclosing”, or showing, additional interface elements on demand. Only what’s necessary is displayed until further options are requested by the user. No unnecessary page changes occur, and therefore workflow isn’t interrupted. However, take note that this technique “is less successful when used to radically change a preexisting UI,” as Jenifer Tidwell explains, “instead of adding UI controls to a blank space.”

Blinksale: Create new invoice

Magnetism

Elements “snap” into place when moved about the interface.

Nearly all of you are familiar with this feature, often referred to as snapping in programs such as Photoshop or Illustrator. Magnetism “helps compensate for users’ lack of perfect dexterity with a mouse” (Tidwell) by forcing elements to position in place without requiring precise input by the user. Magnetism essentially increases the target area, thereby making the app feel more responsive.

Mint: Pane reordering

Data Brushing

Multiple views of the same data, simultaneously.

Data brushing is fairly straightforward: Present the same data simultaneously in two or more formats. This is common in mapping applications such as Google Maps but can also be used to dynamically present expanded data.

Amazon: Product previews

Veer: Character zooming

Latency Reduction

Visual status cues are provided, or multi-tasking is enabled, while actions are computed.

Latency, “a time delay between the moment something is initiated, and the moment its first effect begins” (Wikipedia), has challenged interface designers since the early days of software development. Latency reduction means to reduce the user’s visual perception of latency by 1) providing visual cues such as spinners, progress indicators, and potential length of wait, or 2) “hiding” latency by allowing the user to do other tasks while actions are computed in the background. The DropSend example below is notable in that it does both — it provides a progress indicator, while also allowing the user to do other tasks while the file is being sent.

DropSend: Progress indicator

There, that wasn’t so bad, was it? Now that you’ve got the terminology down, put it to use with a few tutorials and how-tos: Ajax tutorials at DHTML Site.

12 Comments

Veer: Visual Elements for Creatives.
Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.

1 Michael ~ 25 October 2006 at 09:43 AM

Thanks for pulling this together. While I am familiar with all of the examples you provide, it’s good to know the terminology.

2 Colly ~ 25 October 2006 at 10:03 AM

Nice, simple overview. I’m in the “probably do so in the next 6-12 months” catchment. I’m always learning Ajax next week, but next week I’ll be learning it week after, and so on. Jeremy Keith’s book is so dusty.

Anyway, it is all fine so long as it doesn’t break the actual usability of a site. How many times has AJAX-y cleverness screwed with a simple action?

I hate the terms UI, GUI, UX and all that stuff though. Hate the term Ajax too. Hate terms today, really. Hate the fact that I can’t keep on top of all that there is to learn.

3 Cameron Moll ~ 25 October 2006 at 01:59 PM

Understood. This might very well be the most jargon/acronym-laden article I’ve published to date.

4 Somebody Else ~ 25 October 2006 at 02:13 PM

Wow, perfect timing! Just last night I was frantically collecting an assortment of links concerning AJAX to teach to a friend of mine.

Thank you very much for explaining this in plain English!

5 Nathan Smith ~ 25 October 2006 at 04:07 PM

Point of clarification: Ajax wasn’t ever meant to be written “AJAX.” In Jesse’s original article, it was always with an uppercase “A” but the rest of the word lowercase. I used to make this mistake a lot, which is the only reason I bring it up.

6 Craig Minch ~ 25 October 2006 at 09:21 PM

I’ve seen UXD being used more and more too (User Experience Designer). I think it’s great that everyone is carving out there own niche in the process. I’m all for it. It’s good for the craft, but you definitely hit the nail on the head with “jargon alert.”

That’s a solid breakdown of the Ajax terms too. I like the idea of naming and referring to these functions in a consistent manner. “Responsive Disclosure” sounds much more accurate and representational than a “cickable expanding module.”

This was a great, timely article. Thanks!

7 Soo ~ 26 October 2006 at 02:17 AM

good stuff, sir :) I will use all the wisdom!

8 Bramus! ~ 26 October 2006 at 05:17 AM

As Michael said in the first post: good to know some terminology for the things we’re doing (automatically).

9 Kerwyn Wilson ~ 26 October 2006 at 06:03 AM

Great article! Any suggestions on how I can learn more about UI design and from what other resources that are out there on the web?

10 Cameron Moll ~ 26 October 2006 at 06:10 AM

Kerwyn - May I shamelessly suggest a workshop?

(there are a ton of UI design resources on the web, and it would likely require a full article to list them all)

11 Kerwyn Wilson ~ 26 October 2006 at 11:19 AM

I would if I didn’t live on the other side of the globe. Unless you plan to fly over to the Caribbean, Trinidad to be more precise.

12 Ryan Romero ~ 26 October 2006 at 02:06 PM

Awesome review of design terminology. Being in the Interaction Design field, I find it useful to be familiar with these terms and the concepts that define them in order to effectively communicate functionality to our clients.

Being involved with designing interfaces with AJAX functionality sparks yet another issue. How do we wireframe these rich internet applications? Guess I’ll have to attempt to create a new jargon for that type of documentation… how about Web-two-point-oh-mentation?