Recently I was asked to provide input into a presentation. The question was asked, if you were going to provide some quick basic guidelines for designing rich applications what would they be.
Here were the nine thoughts as they originally came to my head.
1) Make it directly interactive
Instead of page to page interactions think direct interaction. Use in context editing as much as possible. Use drag and drop only where it makes sense. Barring a selection model, put tools as close to the objects being edited as possible. Cooper states it as "Where there is output, let there be input."
2) Make it inviting
Use hover to invite users to the next level of interaction. If the interface responds well to light events (like hover) it can be used to entice the user to interact.
3) Use lightweight, in-context popups instead of page transitions where possible
Although they will eventually get over-used, lightweight popups can be your friend. Think of them as annexed areas for your page.
4) Use real-estate creatively
As mentioned popups help. But slide outs have long been allies in desktop tools, they can be an aid in the world of the web.
5) Cross page boundaries reluctantly
Think of a page switch as a context boundary that the user may or may not want to cross. Think of it as a place that many of your users will lose interest and no longer follow you.
6) Create a light footprint
Make it extremely easy to interact. Rating movies or news with just a click on a star with no-refresh is awesome. Checking hostnames without leaving the page is an excellent way to keep a user engaged. Shopping by clicks that only add to a container on the page (instead of going to a new page) are like impulse aisles in the grocery store.
7) Think of your interactions as storyboards
As the designer you are the director. Think about the event states as acts in a play and your interface elements as actors. Get them all moving towards telling your story. Putting the frames down on a storyboard is a great way to rehearse your script. Think of the interesting moments as opportunities for engagement.
8) Communicate transitions
Keeping the user informed during lightweight operations (that don't leave the page) with spinning wheels, busy or progress indicators keep the user engaged with a living page.
9) Think in objects
Instead of thinking about content and pages, think about Rich Internet Objects. The travel log in Yahoo!'s Trip Planner is a good example. Once created it can be searched for or shared. This will help you create more interactive applications and make the user's work recognizable and sharable.
These are not exhaustive. Even as I go to publish this I can think of other tips to include... but I will resist adding to the list. Perhaps you have some tips/principles that have helped you solve design challenges?
8 comments:
Nice tips. I think it would behoove developers in todays fast paced, ever-changing WWW to really consider each and every one of these seemingly commons sense objectives. (Why is common sense becoming more and more uncommon?)
>> Use drag and drop only where it makes sense
I totally agree with you. The main objective should be to help the user with the interaction rather than to show off what all you know in Javascript.
As the previous commenter as said, use your common sense.
I urge strong caution in breaking the back button in the browser. Many of the tips suggested here will break the back button metaphor if not properly implemented.
The back button is an established user interface convention in web applications, and developers should take heed not to confuse their users by ignoring the ramifications of removing it.
I urge developers to move forward and forget about the back button as a hangover from a simple back <-> forward page model not suited to the next generation of web applications.
Sure there will be a period of transition while users adjust to new ways of interacting, but once the initial angst and frustration passes most users will be educated enough to know when a back <-> forward model is appropriate.
Applications are becoming far more interactive, rich, and useful, and blindly adhering to a dated model instead of moving forward is nonsense.
>> Sure there will be a period of transition while users adjust to new ways of interacting
I really have an issue with this sort of thinking. I can tell the diff between a flash-based site and HTML but my wife can't (nor should she be expected to - if it feels like a window/desktop app it should also behave like one too).
the back button (even in windows or the back/forward button in Finder in OS X) should take you "back". that's what it's there for. Browsers ashould be no diffent
how frustrating it is to hit "back" in a flash-based site only to go back to the flash loader page!
MACR provide an API to the history to deal with going "back". Please use it!
(I'll get off my hobby-horse now and shut up...)
Common sense is the commonest thing in the world! Proof: people always complain they do not have enough money, time, sex, consideration, vacations etc, but never that they don't have enough common sense.
(For more of the same, read Descartes)
>> once the initial angst and frustration passes most users will be educated enough to know when a back <-> forward model is appropriate.
That is easy to say if you don't care about revenue, but it is absolutely silly to expect businesses to cause angst and frustration in the customer base like it was no problem.
ouch... yes these are tips ( the rules from my view) that u cannot leave be . My experience is let these battle with your own of course superb solutions and come out a winner after a painfull and coffee addicting merge. But take note of ending the fight in a swift manner and harmonic state.
Post a Comment