31 August 2012

The Web's visual language

Current interactions are far more complex than they used to be and will probably get even more tricky. However, the interaction language we use is finding it hard to cope.

This redesign I've been doing for Analytics SEO is coming on well but one thing about this and many previous designs has been nagging me.

When I first used the Web in 1994-5, interactions were simple. Links were (generally) blue and underlined and went to a new page. A button submitted a form. Form elements worked more-or-less as on the desktop.

But current interactions are far more complex. Take the live edit type interaction as seen in Basecamp. Here, an active element (most often text: in this screenshot, it's a date) shows an overlay when clicked on that allows the user to change the element. It's a very nice piece of interaction that helps do away with separate "edit" screens and server-side lags.

But this type of interaction differs from the classic click-on-a-link-and-open-new-page-in-this-window. It's all client-side so quick. From my experience researching non-technical users, some might miss this and instead opt to wait for the page to reload. Yes, this is possible - I've seen it in testing and it feels embarrassing for participants to wait only to be shown they got the interaction wrong even if it's not their fault.

But we do not communicate the different interactions to users. If I see a link, I have no way of telling whether a) this opens a new page in the current screen, b) this opens a new page in a new screen / tab, c) this opens an overlay, d) this sorts a table's column client-side, e) whatever else might be expected.

Most people seem to muddle through okay but, as I've found, some people just don't. This, I cannot help feeling, is a significant shortcoming of our field. We make these things. If otherwise intelligent people don't understand them, we have a degree of failure to our work.

Post a Comment