Interaction Over Visualization

Often in programming, it's best to think in orthogonal terms -- for every add, there's a remove or for every set, there's a get method, etc.

As John Resig noted in a comment on his talk on "Building a JavaScript Library" that "if you have a method that performs one action, you should have another that performs an equal and opposite action. Secondly, that there should be one equal way to perform an action against all objects."

There's a similar concept in front-end UI ( and here, I'm focusing on my passion - the web ) which involves the symmetry of design.

There's two parts. There's the visual and then there's interaction.

Visual design is providing a consistent look and feel between pages. Visual elements should "flow" from page to page. This is why the same site maintains the same background color, font style, masthead, tabs, layout, etc. on different pages.

Achieving visual consistency is easy to do.

It's really a matter of manipulating your CSS files. Provide the necessary class names and understanding the structure of your HTML/XHTML, allows you to make good use of CSS.

CSS manipulation is also minimally intrusive. Though you'll effect the layout and look of a page, you're not forcing other team members to make substantial changes.

You're managing a set of CSS files which thankfully, is close to a standard and which is generally agreed, the best way to do things!

Sure, you'll add new class names, but you're not changing how the page is manipulated ( i.e. you're not manipulating JavaScript ) or how users interact.

Like remodeling a bathroom, you're just changing the the ceramic cream tiles to crema marfil, replacing the vanity top with a large marble slab from Spain and swapping out chrome with brushed nickel faucets. They function in the same way, but they just look different ( hopefully better! ).

Of course, when you do something like remodeling a bathroom, the look "flows out" into other areas of the house. So, the crema marfil tiles need to be visually consistent with the tiles in the hallway and perhaps even what you have in the other bathrooms. They need to match or provide visual consistency ( this is why remodeling projects typically go way over budget! ).

However, interactive consistency is more difficult to achieve. There are a number of reasons for this.

One reason is that it takes more time to story board and think through the interaction. Everyone can agree that a dashboard should have the background color #333333, but it takes a lot more thought on how to handle drag and drop transitions on a dashboard.

Fortunately, there are already interaction patterns out there. My favorite is Yahoo!'s Design Pattern Library.

Unfortunately, this doesn't mean that a workflow is easily agreed upon. Bill Scott's LiveGrid supported grid navigation not by traditional pagination but by scrolling.

It seemed to be a more "natural" way to navigate a large dataset.

Microsoft's Live.net had this feature, but eventually, it was taken out and is now only found when searching for images.

Microsoft, maybe through usability testing, felt that it wasn't necessary or good to navigate large lists using scrollbars. After all, Google doesn't do it in their search results; however, they do for their lists in the Google Reader. Even within the same company, interactions on similar things aren't always done in the same way.

Another reason is priority. Software companies, particularly those that have a lot of legacy code ( i.e. enterprise software companies ), take longer to adopt new interactions.

User interactions typically play second fiddle to functionality. If your company specializes in ETL, you're going to add functionality to allow your users to transform your data faster. You're not going to focus on how to transition fade from one dialog to the next.

Unless the interaction demonstrates "better performance" or "user efficiency" ( whatever both of those terms mean ), it usually isn't put on the worthy feature list. It's really unfortunate that there's no "Big O" notation for UI interaction.

Another consideration is technical.

Interactions involve event handling and using event driven models and unless you're using a toolkit ( i.e. YUI, Bindows, JQuery, Dojo, etc. ), manipulating events can be tedious. You typically end up writing your own libraries to abstract the events and then add additional objects/methods to handle the interaction ( i.e. DnD, animations, etc. ). It begs the question of why you didn't use a library to start with.

If you choose a library, use it. Don't choose a library and then use part of its event handling here and then use a "home grown" system ( or another libraries' ) elsewhere. Cross library event handling is difficult and really makes adding new interactions almost impossible.

Some libraries, like Bindows, is component based. This means that your widgets/components are created as JavaScript objects. Unlike YUI, you never pass in a DOM node and manipulate that. In Bindows, the DOM is totally abstracted for you. So, you have to slowly convert your code to that model. This is really the only way to add interactions to your entire application.

You can't have half your application in HTML/XHTML and the other half written in the library. If you do that, you'll reject all the interactive story boards from your user experience team.

Between the two, interactions are far more important than visualizations. Interactions deal with behavior and how your users relate to and communicate with your application. It's more valuable than a pretty face because it's the interactions that allow your users to accomplish what they need to do.

Interactions are also far more difficult to think through, design and implement. So, they should be tackled first before visualizations.

Unfortunately, often interactions are tackled last and are little afterthoughts.