Dreamforce is just around the corner. Everyone in the Developer Marketing team—and the entire company—is heads down getting ready for the big event. I will blog more on that topic tomorrow but I wanted to share a quick thought based on one of the resent dry-run sessions I attended.
Dave, Reid, and I have split the management of this years Developers Track at Dreamforce. What this means is that each of us have approximately sixteen sessions to manage. One part of the management process is attending the dry-runs where the presenter has the opportunity to rehearse their timing, and practice their demos etc. One of the sessions in my pool was titled Professional Visualforce Pages, presented by Stephan Moralis. Stephan's presentation, scheduled for 12:45 on Tuesday is one not to miss.
Stephan's presentation reminded me of a tenet of design which I have always strived to maintain as paramount in any architecture and development project. That tenet is affordance.
The computing and design dictionary defines affordance as "the visual clue to the function of the object." Think of a chair. You don't need any instructions on how to use a chair. True, we all know how a chair works after many years of sitting on them, but the affordance of a chair means that if you had never seen one before, it is pretty obvious there is one way to use it: sit on the flat, cushioned surface.
Makes sense? Right.
But good affordance is hard.
To demonstrate, a friend of mine the other day bought a netbook and was having trouble connecting to the internet. He brought it over for me to look at (yes, computer guys are the modern day version of the neighbourhood mechanic who is constantly asked "can you look at this for me?"). Let's call my friend Bob, to protect the innocent.
Bob: "I can't get the wireless to work. I double click the wireless icon, and it never works"
Quinton: "Show me what you have been doing."
Bob double-clicks on on the wireless icon and is presented with the following dialog:
What's the first thing that comes to mind when you see dialog above? "Push this button to power the wireless on" Right? Unfortunately the affordance of this computers system was very poor. The dialog above uses a label on a button to indicate wireless status. Pressing the button changes the label to the following:
Now that is confusing! Is the wireless on, or is it off?
The point of my post here is that when designing a system, be it the User Interface, or APIs, think about the affordance—the visual clues to how a system is to be used. If the designers of the above dialogs took a few extra minutes they might have come up with something like the following:
It doesn't take much to improve affordance dramatically. Our wireless system is already significantly better, but another critical aspect to good design is doing what is natural to a user—work with the way they work; do not force them to work differently to suit you. Take the following picture as an example of what happens when you attempt to make a user work in a way in which is not natural to them:
The basic rule here is simple: Users will use your system in the way in which is most natural to them, even if that means they need to break the rules and create their own path.
With this final rule of affordance and design set in or mind, we could massively improve the system design of our wireless device by thinking about how a user uses a netbook: they use it to connect to the internet—thus the "net" in netbook.
By adding a checkbox allowing the Wireless device to power on when the system starts supports the way a user naturally uses the netbook. We now have a greatly improved user experience. Bob would be happy.
In summary, whenever designing a system remember two simple rules:
1. Affordance: Consider the affordance of the application —how will it give a visual clue to its use.
2. Natural Design: Make the application work in the manner is which is natural to the user.