I’ve been reading a bit lately about the challenges that Rich Internet Applications (RIA’s) present to people interested in designing elegant, efficient, usable interfaces. Most recently it was Usability for Rich Internet Applications by Donna Maurer over at Digital Web Magazine.

One of the aspects of RIA interface design that is causing some consternation (or at least discussion) at the moment, is around how we make the interfaces easy to use.

There are lots of great ideas being thrown around, techniques that look as though they could evolve into future conventions.

One thing I find myself thinking of often is how we go about documenting these conventions.

It has been my experience that in reading about RIA and usability, many of the suggestions made fall into what would traditionally be the realm of the visual designer or the application developer. Examples (from the article cited above) include:

… Visual attention is attracted by movement and high color contrast … We can use this to our advantage and draw the eye to the updated part of the page [Visual Design]

… By making sure the change occurs quickly …. we can ensure the eye is drawn to the appropriate place [Application Developer]

… Odeo provides effective feedback by using color (and) movement [Visual Design]

Now, for me, these are all excellent suggestions for making RIAs more usable. They are also things that, traditionally, I would have neglected to include in my project documentation. Say I was working in a large development team and wasn’t involved in the ‘production’ phase of the project (where the designers and developers took up my specifications and built the project), I couldn’t guarantee that these measures would be taken. I could only hope that they’d be picked up and recommended in later usability testing. Not good enough really, is it?

At the same time… as an information architect/interaction designer who’s not a ‘visual’ designer… imagine the response I’d get if I started specifying colours in my documentation! (If you’re not certain what this might be, trust me.. its not pretty).

So, what to do? Do I need to be more specific when I document an RIA? Do I need to suggest using yellow fades? Do I need to specify that confirmation messages should be shown in highly contrasting but not red font? (someone was writing about the emergence of people using red fonts for not-error messages… can’t remember who, but it was an astute reflection).

Although theoretically I like the idea of more beautiful documentation, in reality, it doesn’t seem likely.

Here are some alternatives that have potential.

UI Libraries and Patterns – Patterns are getting pretty popular at the moment, and I think this is good for everyone (not to mention, its very caring and sharing and 2.0). Yahoo! have set a brilliant example to the webosphere by making their Design Pattern Library public and supplementing it with access to their User Interface Code Library.

Conventions come about when everyone agrees on an optimal way of presenting an interface design to solve a particular problem. The more people do it the same way, the stronger the convention.

Design Pattern Libraries, and shared UI code means that rather than everyone expending energy asking the same questions and coming up with varying quality solutions, we can strengthen conventions and thereby usability and spend our spare time improving the usability of known conventions… or solving other interface quandries.

Collaborative Design – This is just one of many reasons why collaborative application design becoming more of a necessity and less ‘extreme’ every day. Not only do we benefit from having the full range of expertise in play from the earliest stages, but ideas can be tested more quickly and the amount of documentation required can be minimised through prototyping interaction at the earliest stages.

Does this mean the death of the functional specification?

I don’t believe so.

I don’t think its time to dump everything we know about our design and development methodologies, but it is certainly time to start thinking about how they need to shift and give take best advantage of and to support the type of development that we are doing today. One that often renders pedantically detailed specification obselete, but one that will definitely benefit from experienced usability and interaction design experts applying their expertise in the earliest stages of the project and throughout the development lifecycle.

What might that development methodology look like?

I’m not sure. But I know I’ve seen a lot that don’t look right to me. And I know that the old ones just aren’t coping.

So, what do you think? What does the design/development methodology of the future look like? How will we work together? Can we come up with something that scales? And something that is client friendly? I’d be interested in your thoughts.

Technorati Tags: RIA, Documentation, Specifications, Usability, RIA, Usability, Ajax