Same Language, New Dialect

Vivabit’s Dan Webb wrote an interesting post a few days ago that touches two important topics, both of which I’ve been thinking about a bunch lately. His entry is called DOM Abuse Part 1: Drag and Drop and he says towards the beginning that:

As more and more JavaScript libraries add solid drag and drop support I begin to shiver. Everyone is going to be doing it soon and Im scared.

I’m not scared – I think we’re entering a great era of web design – but I understand exactly what he means. I would categorise his two points as “the accessibility issue” and “the discovery issue.”

First, accessibility: Advanced interactions and behavior provided via JavaScript must be enhancements, not the sole way to accomplish a task. In desktop cut-and-paste, there are at least three ways: keyboard shortcuts; “Edit” menu options; and drag and drop. Accessibility isn’t an optional characteristic of the Web. With what could be considered a gold rush of JavaScript development powering a big chunk of “Web 2.0”, the accessibility gains won over the last four years (Web Standards) are at risk. For JavaScript, the way forward is clear – progressive enhancement, unobtrusive javascript, and Hijax – and championed by the DOM scripting task force.

His second point I’d summarize as the “discoverability issue”. It’s definitely an issue, but it’s also a symptom of a larger overarching issue, what I call “the low expectations issue.” Here’s what he says:

Drag and drop is not a method of interaction you see on the web (at least at the moment) and as such you do really need to be told when to do it. That’s not good. I’m not used to reading what’s on the screen. How are we supposed to know to and when not to try it?

It’s not that the feature isn’t discoverable (though it could certainly be aided by some visual affordances), it’s that he’s not expecting it to be there! On the desktop there are minimal cues because we expect it to just be there, and often don’t need to be told.

In my opinion (with a hat-tip to colleagues Eric Miraglia, Bill Scott, and others), this is a primary design challenge of the day. It’s not just about adding visual affordances, it’s about something bigger. It’s about raising overall expectations in a careful, purposful, we’ve-got-one-chance-to-get-this-right type of way.

Since the beginning, we’ve been lowering expectations of what’s possible in the browser compared to other desktop software. No double-click in the browser. No drag-and-drop in the browser. No right-click, context menus, auto-save, auto-complete, full screen, minimize, layers, spell-check, not even many tooltips.

More broadly: no direct manipulation, no immediate feedback, and no persistence in the browser. On the desktop, we learn by experiementing. In the browser, users have stopped exploring because there hasn’t been a reason to explore, nothing to find. (To make matters worse, every click has traditionally meant many seconds of page teardown and replacement.)

It’s not that we didn’t want to provide a familiar experience, it’s that the technology wasn’t really available in the browser. That’s not true anymore.

But, the availability of new technology isn’t a cure, or a reason to believe we’ll make a successful transition.

Being able to do something does not mean that we should do something. Why is more important that how. Using animation to create 2006’s version of the 1999 Flash splash screen isn’t a why, it’s a “because we can” (and a bad idea). On the other hand, using animation to ease transitions, provide user feedback, maintain user orientation, and promote learning of new idioms are four good reasons why.

But knowing why isn’t the same as doing it well. When I say that we’re got one chance to get it right, I mean this: If we bring the rich interaction patterns of the desktop to the browser in a recognizable, comfortable, thorough, complete and appropriate way, user’s will break through their doubts and quickly transfer their desktop experience into the browser. We won’t have to put big neon signs on our sites saying “drag here”. If we get it right, users will just assume.

On the other hand, if we don’t get it right, if we’re spotty, if we don’t keep the façade intact, then the illusion will not stick. If we make too many missteps, if we leave to many gaps, then the nearly free “user education” and the potential parity of expectations will be gone again. I’m not scared by drag and drop, I’m scared that if we miss this chance to bring richness to the browser, user’s expectations won’t just be low they’ll be shattered.

To be clear, it’s not about replicating the desktop in the browser. They’re different environments. Instead, we want to take the idomatic language users already understand and express it within this new environment. Same language, new dialect.