Affordance
Quinton Wall's Blog |
September 19, 2005 10:45 AM
|
Comments (2)
I seem to spend a lot of my time flying somewhere and this ends up
being where I get down time to work on my own projects or create a
blog entry. I had some time last week to make some great progress on
my Reeter tool which I should be able to upload to code share in the
next week or so. During this time I have been thinking about the
design decisions that I have made so far. One of my graduate subjects
I took a number of years ago was on Human Computer Interaction (HCI), in particular
how familar an interface is to a user and to what extent does someone
have to 'relearn' to understand the system.
HCI borrows a term from the world of design called Affordance.
Affordance is the level which an object (an item, not just a OO object)
through its design provides an indication of how it is to be used.
The higher the level of affordance an object has the less amount of
learning is required to use it. A great example of an object with
high affordance is a coffee cup. Through prior experience we can
instantly tell that the central piece could hold some form of liquid
and the handle provides the best way to hold or lift it. You dont
need a length instruction manual use a coffee cup; it is familar to
how other things in our world work. A more technical example may be
Apple's, IPod. With very little learning, new users can quickly become
comfortable the controls.
Whenever designing systems I try to keep the notion of Affordance in
my mind. Can I made the design similar to the way other things
function? Is there a way to make it similar to 'real world items' so
that it doesn't hours of scouring APIs just to use it. Design Patterns
are probably IT's best approach at offering some form of commonality
to programs. In particular the Command Pattern can assist in defining
common entry points to the system. But I find that we still miss the
point when it comes to good design as most of us think like engineers
not graphics designers etc.
Too often we add layers of abstraction in an order to encapsulate logic
or delegate functionality to a helper class but fail to take a wholistic
approach to design. I have a friend who is a great graphics designer.
One thing that always strikes me when I look at some of his work is
the presence of a common theme throughout. The style all shares a common
base and seems to re-enforce the theme of the site or product. Sometimes
its easy to get lost on the specifics of a single implementation or
aspect of the system while forgetting about how the whole should look.
I am not sure whether I have an answer to affordance in IT architecture
but I believe that consistency throughout may be part of the solution.
Consistency may allow engineers learning your APIs to spend the time
on core components with the confidence that the same patterns will
be present in the rest of the site as everything re-enforces a common
theme or goal.
I am sure that when the first people to invent the cup sat around the
fire and pit of clay they have a central theme in mind; perhaps something
as simple as "build something that can hold liquid but not burn our
hands". This central theme guided their design from beginning to end.
The result is something that has stood the test of time with very little
change to the design we know now.
Maybe it is lofty ideals but to me that is the essence of design.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Great post! W.r.t your comment "when it comes to good design as most of us think like engineers not graphics designers etc. " - this is so true. I would recommend reading "The Inmates are running the asylum" if you haven't already done so. The book explores this theme further.
In terms of well designed software, that is elegant and intutive after you understand the philosophy, the only ones that I have encountered are the Unix OS, Interleaf (a great document publishing system), WinZip and POET OODBMS (pre 4.0 release).
Posted by: nsimha on September 23, 2005 at 12:56 PM
-
I agree. Any software should not force change and relearning if it can avoid it. A great example is CVSGui project verses the Tortoise project.
Now dont get me wrong, the CVSGui project is pretty amazing. Pre Eclipse and its CVS client I used MacCVS all the time but it forces you to change the way you would usually work. Tortoise, on the other hand is integrated with what you are used to. In this instance, going to some form of explorer window, create documents etc. With intuitive visual clues and right click access to commit, update etc the experience is simply an extension to what you do everyday; thats Affordance.
Posted by: quinton_wall on October 7, 2005 at 10:52 AM
|
