Inkwell: Authors and Artists

    
I'll throw in GIS too.  and Mapquest as a corollary.
  

    
Dan, one of the things that was curious to me, but perhaps appropriate, is 
how the designer becomes the center of creating these new products. 
Especially with interactive design, that role seems essential in designing 
how the ultimate item - software, hardware, widget whatever - will look 
and feel and function, but that is often part of a negotiated plan that 
includes the limits set by budget, time, quality, as well as by the 
various stakeholders' sense of what is needed.

In that sense, I'd have to say that a good designer isn't nececessarily 
someone who can come up with the singular design that is perfect, but one 
who can come up with multiple scenarios to help negotiate all of these 
other factors and helf decide (most often) which compromise makes most 
sense.
  

    
That's a good, if controversial, list there Jim. Of course, I think
ANY list is probably going to be controversial, because as Jet pointed
out, even seemingly "simple" programs like email can flummox some
users. But then, I'm not sure you could make a device--especially a
digital device--that would be usable by everyone on the planet. The
only universal products I can think of are things like cups and
spoons--certainly nothing as complex as an ATM or mobile phone, much
less a program like Excel.

I've had a number of people ask me (after the John Maeda book was
published) why I didn't make simplicity one of the "characteristics of
good interaction design" that I list in the book. My answer is that I
don't think everything should be simple. Do I appreciate a simple,
elegant device that does one thing very well? Sure. I have an iPod. :)

But I also have a complex laptop that lets me do any number of things
and I'm not going to trade it in for a laptop that only, say, does
email and web surfing. With simplicity often comes a loss of control,
and for some devices and services, you want that control. I want the
air traffic controllers to have advanced features in their workstations
for those rare cases when something goes wrong. Likewise, I don't want
missile control stations to be too simple to operate. I want them to
have to turn two keys and enter in the super-secret code to fire those
things. (God help us.)
  

    
I forget who said it, but someone noted that the best designers were
those who could work under the most constraints.

Being an interaction designer is a juggling act. You've got users,
business, and technology, sometimes pulling in opposite directions and
it's the designer's job to put them together in a product that makes
sense and satisfies everyone's needs. One of my design heroes, John
Rheinfrank, noted that being a designer was akin to being a
"trickster." You have to sometimes trick organizations into doing the
right thing.

Of course, there is also a new way of thinking: that the designer is
only one contributor to the process, that far from being at the center
of this process, we really only have a very limited amount of control
over the product or service. It's really the users who control how,
when, and where the product is used. They'll work around it, hack it,
use it as they will. The ability of the design to control the
experience is actually pretty limited.
  

    
From Design Q&A with Charles Eames:

Q. Does the creation of design admit constraint?
A. Design depends largely on constraints.

Q. What constraints?  
A. The sum of all constraints. Here is one of the few effective keys to
the design problem -- the ability of the designer to recognize as many
of the constraints as possible -- his willingness and enthusiasm for
working within these constraints -- the constraints of price, of size,
of strength, balance, of surface, of time, etc.; each problem has its
own peculiar list.

Q. Does design obey laws?
A. Aren't constraints enough?
  

    

The notion of "simplicity" and the term "simple," like many words used in
the broad field of user experience, can mean different things in different
contexts.  Though there are many attempts to "nail down" and fix terminology
in our discipline, I'm convinced that we're a long way from being able to
settle on agreed-upon meanings for a range of words and terms.  There are so
many different and valid approaches to interaction design, and its
practitioners come from so many different fields, it's always going to be
problematic.

Simple can, in some contexts mean a quality possible in all kinds of things
"easy to use" or in other contexts can be interpreted as a product, system,
or service that does just one or a few things, or works in fixed way, thus
avoiding the confusion that flexibility can sometimes produce.

Back in the 1980s I began talking with clients about the difference between
"complication" and "complexity."  I think this is in a similar vein to what
Dan is speaking about, regarding "products not always wanting to be simple."
 Complexity, which entails a variety of sub-criteria (large number of
components or functions, flexible usage and application possibilities, open-
ended functionality and systems, many possible interrelationships between
functions and users,  etc.) are an inherent reality of many modern products
and systems.  But that doesn't mean that complication is inevitable.

Also, complication can occur in even products, systems, and services that
are not inherently complex.  In my work, I've always seen one aspect of my
role to be the reduction of complication, and designing in the means to
simplify usage of even complex systems.

I see interactive systems in terms of patterns, symmetries, and syntactical
components.  I look for similarities and interrelationships between the
different parts of complex systems, and reinforce those in multiple ways.
Graphically, syntactically, organizationally, hierarchically, sequentially,
and so on.  When designing a system or complex product I always work
iteratively to develop an interactional syntaxes, from which the individual
functions and sequences can be embodied.  In this way, when users have used
one part of the system, they naturally know how many other parts of the
system work.  This has been borne out successfully in many products and
systems over many years.

Mark Rettig alludes to this in your book, Dan, when he calls for a carving
out of a new branch of linguistics - the linguistics of designed
interactions.  Though I've not been able to do much formal writing during my
career, I've carefully and comprehensively documented all of my projects all
these years to preserve the interactional architectures and syntaxes for
later study.  I would love to collaborate in the study of the many types of
interactional languages, as I think they are a crucial aspect of
understanding and designing complex interactive systems that are both
powerful, flexible, and still easy to learn and use.
  

    
Hello all. James must have conjured me up in his last post. 

So, yow. I don't know where to jump in to this conversation. I'm glad
it's happening, and I'll try to do more than lurk. I feel like I
wandered into the bar where you've all been talking for some time, and
now I'm about to spout a bunch of stuff by way of getting into the
conversation. 

Thanks for the nod toward the linguistic view of interaction. I do
think it is an important point of view that is going to lead to real
progress one day, <whine> if any of us get to take time away from
making a living long enough to work on fundamentals. </whine>

On constraints: a favorite quote comes to mind....
“The form is a part of the world over which we have control, and which
we decide to shape while leaving the rest of the world as it is. The
context is that part of the world which puts demands on this form;
anything in the world that makes demands of the form is context.
Fitness is a relation of mutual acceptability between these two. In a
problem of design we want to satisfy the mutual demands which the two
make on one another. We want to put the context and the form into
effortless contact or friction-less coexistence.”
- Christopher Alexander, Notes on the Synthesis of Form

on systems and unforeseen ripple effects: a favorite book of mine on
this topic is John Gall's "The Systems Bible." It's an insightful but
informal overview of systems thinking, funny in a
laugh-out-loud-at-the-tragic-truth sort of way, and boils the ideas
down into memorable axioms. ("The old system become the new problem."
"The crucial variables are discovered by accident". And so on.)

On simplicity: Really, nothing is simple. Better just to assume
mind-frying complexity from the beginning, and roll up your sleeves to
deal with it. But... you were talking about the pressure on designers
to create something that is "simple." The good news is that people are
pretty good at living with complexity. Maybe once in a career we'll
have a project where something truly simple is The Right Answer. The
rest of the time the challenge is not to reach for simplicity, but to
give people something that lets them deal with the complexity through
an appropriate level of order and accessibility. If we nail it, they'll
call it simple. But we know its Byzantine complexity because we had to
touch every part of it during design. 

I hate to quote Alexander twice in one post, but his new set of four
books -- especially the first two / okay the second one really, "The
Process of Creating Life" -- addresses this beautifully. He reminds us
that any particular layer of complexity might appear to be simple, so
long as that is the right level for us to be interacting with. A single
tree can be seen as a gorgeous simple thing, for example. Never mind
that it is made up of an inaccessibly complex system of layers of
systems. Is Google simple? Well, yes, at one level....

Okay. That was a bit of a ramble by way of a wave hello. A lot of good
things have been said so far. I hope my too-many-topic post doesn't
derail the thread of conversation. 

Cheers! <clink> 
  

    
A few sleepy thoughts before bed...


> My answer is that I don't think everything should be simple.

I'm not arguing for that as much as a Magic Slider on things that can
make them go from "simple" to "complex" with a few stops in between.
Setting up a Mac for my mom?  All sliders to "simple".  For me?  All
to "complex".

Doesn't (shouldn't?) "simple" mean "simple for the typical person
interacting that specific system".  I don't know that I'd want an air
traffic controller to ever perceive their console as "complex".  You
or I, sure, we'd think it complex, but someone who uses it daily?  Do
I want them to think of it as complex?

Another example: I think my UNIX work environment is pretty simple.
On the other hand, I've been living with it daily for at least 20
years and think about computing unix the UNIX paradigm.  I avoided
some variants of UNIX (ex: Solaris, AIX) because they seemed overly
complex for the tasks I wanted them to perform.
  

    

Welcome Marc!  So glad you've joined us.  Some great quotes there!

I've posted pointers to this conversation on the IxDA Discussion List and
also at Boxes And Arrows, so hopefully we'll be joined by some more
interesting folks over the coming week.
  

    
Welcome Marc (and everyone else that has joined recently)!

More on simplicity: Larry Tesler (the guy who invented cut-and-paste
(!) while at XEROX Parc back in the 1970s) has a great law that I
reference in book. Amazingly, few designers had heard about it. It's
The Conservation of Complexity and it goes something like this:

Every process has some level of complexity in it that cannot be
avoided.  The question for interaction designers is: who (or what)
handles that complexity? If it's the digital device, well, the process
can be a lot simpler. Many point-and-click digital cameras are like
this--like the one in most mobile phones. There's no messing with
lighting or exposure or any of that. The device handles the complexity.
But on a professional-grade digital camera, the onus of complexity is
taken on by the photographer because those who buy such cameras want
the control that complexity brings with it.

When you are talking about a system like UNIX or anything with a
command line, well, you can see the same thing happen. The complexity
of the system is pretty much pushed onto the user, who can then do some
seriously powerful things quickly. But at the cost of (initially) a
steep learning curve (at least compared to a GUI).

One of the trickiest challenges I've ever faced as an interaction
designer was a project to move a set of customer service reps from
their green-screen, AS400 style UI that they could tab through like
mad, super fast, onto a web-based application. (There were complicated
business reasons to do this--too much to go into here.)

It works the other way too. When I was at Datek, we actually created a
command-line type system for power users to use instead of the
standard web forms. (You'd type b500msft to buy 500 shares of
Microsoft, for example.) We actually de-simplified the interface.
  

    
>>> move a set of customer service reps from
their green-screen, AS400 style UI that they could tab through like
mad, super fast, onto a web-based application

Heh, I worked on the previous incarnation of that idea, moving people
from the AS400 to Unix/Motif.
  

    
And I'm sure eventually we'll work on moving people from a
desktop-like UI to something else. :) Maybe something like a Second
Life or some other sort of 3D space. If not directly TO a physical
space loaded with sensors and microprocessors.
  

    
>>> The question for interaction designers is: who (or what)
handles that complexity? 

I went from programming on Unix to programming on the Mac in 1985. One
of the things that immdiately struck me was that the Mac designers had
moved the complexity off the users and put it on the programmers.
  

    
The last few posts have talked a lot about handling complexity in such
a way that it reduces complication.

As Marc said earlier,
>>>The rest of the time the challenge is not to reach for simplicity,
but to give people something that lets them deal with the complexity
through an appropriate level of order and accessibility.

Providing this order and accessibility is obviously accomplished, in
part, by things like effective information architecture that reflects
the user's conceptual model of the information space, and interaction
design that chunks the process, (whatever it may be) into steps that
are not overwhelming for the user.

So how does interaction design address attention. It seems to me that
this is where interaction design and visual design should crossover,
helping to guide the user in effectively allocating their attention to
the right spot, for the right task, at the right time. 

As Herbert Simon said, "What information consumes is rather obvious:
it consumes the attention of its recipients. Hence a wealth of
information creates a poverty of attention..." 

If... 
>>>>The device handles the complexity.

This allows the user to pay attention to other things, on which they
place a higher priority than "getting the perfect shot".

Just a thought....
  

    
Exactly right, Michael. And, to a lesser extent, to designers as well.
It's easy to make products so that the people using it have to do
difficult things. Heck, we see that all the time! My mobile phone
barely makes calls! But when the onus is on the design and development
to take on the burden of complexity, well, that makes our jobs a lot
harder. But it's worth it, objectively. The extra time and effort spent
by a (usually) small group of people can save hours of annoyance and
frustration by a (usually) much larger user group.
  

    

Many insightful comments all around here.  <mz> is right about the example
of the Macintosh where difficulty was shifted from the users onto the
programmers.  Many programmers complained about that, and yet users
benefitted from the overall superior user experience.  Though there's always
been a tradeoff in the Macintosh community.  Fewer programmers created
applications for the platform, though as a Mac user from the beginning, I
always lots of incredibly useful programs.  Now with OSX, there are way more
small-scale and specialty applications.  While there are some tradeoffs, I
think it's clearly important to have an well-designed user experience.

<trevorvangorp> makes an excellent point that I've often made, especially in
medical and surgical equipment:

> " This allows the user to pay attention to other things,
> on which they place a higher priority than "getting the
> perfect shot".

This is abundantly true.  I worked with brilliant surgeons, in developing
the user interface for a surgical laser, and there was no doubt that these
professionals were capable of figuring out, learning, and using some very
complex (and often unfortunately over-complicated) equipment.  But it was
clear from observing them during surgery (which I got to scrub down and suit
up for) that they had far more important issues to focus their attention on.
 It was clear that systems needed to communicate key values and settings,
and be rapidly and reliably reconfigurable and usable.  Every iota of
extraneous attention I could remove from the process of interacting with the
surgical laser's controls meant more attention that could be focused on the
multiple other tasks at hand.

A similar dynamic was at work with the newborn hearing screener I designed.
In that usage setting the primary patient was an infant on the day they were
born, or shortly thereafter.  Any attention-stealing complication that could
be removed from the process was attention that could be spent focused on the
infant and often the new mother.  That was also a device designed to be
usable by a wide range of people, from doctors and nurses all the way to
minimally trained volunteers who would ride out to the homes of newborns on
bicycles.  It had to be extremely easy to use and confidence-inspiring.

A device that I know IDEO worked on that also had to be used by a wide
variety of people, and more importantly - in extreme emergency situations -
was a public defibrillation device.  I still marvel at this wonder of design
effort, capable of taking a process as serious as shocking a heart back into
proper rhythm and creating a device simple and reliable enough for lay
persons to pick up and use with a moment's notice.  Perhaps <esau> can tell
us more about that project.
  

    
We observed emergency techs going through the paces of saving a heart
attack victim and compressing the steps so that anyone could perform
with a device. For instance, after exposing the chest of the patient,
one device was used to study the heart pattern -- very important,
because a defibrillator can't help someone with congestive heart
failure. So you have to first get an EKG to determine a fibrillating
heart, then apply the shock device.

Our HF and IaD people turned all the steps into a simple one-two-three
process with foolproof steps, aided by a woman's voice telling you what
to do: "Place the pads on the patient's chest."

That particular step revealed an interesting design challenge. In the
version we designed, each pad has a drawing of its intended location.
One pad is shown on the patient's upper right chest, the other on the
lower left side. In reality, it doesn't matter which pad goes where,
but early tests showed that people were confused -- they treated the
pads like jumper cables and were deathly afraid of reversing the poles,
causing crucial time loss. The few seconds saved by making placement
clear was a brilliant idea. (Our work on that device is over ten
years old and current devices are even simpler, I believe.)
  

    
(Posting from studio when I should be working on a construction project...)

Dan made an analogy a few posts back:

> But on a professional-grade digital camera, the onus of complexity
> is taken on by the photographer because those who buy such cameras
> want the control that complexity brings with it.

My almost-pro-grade digital camera has a knob that I twist and it
becomes about as simple as a point-and-shoot.  If that knob could
disable/hide all the buttons and widgets that were of no use while in
"grandma mode", it would be nearly perfect.

I guess that's what I was thinking about with my
email/editor/spreadsheet comments.  Hiding the "Format" menu in
Mail.App isn't moving the complexity on to the computer, it's removing
a bit of chrome that isn't needed for the basic task of reading,
sending and composing email. 
  

    
Engineers writing international standards for infant incubators were
set to place all sort of safety constraints on the device until we got
a neonatologist to explain the variety of adjustments he needed to
protect the lives of premature babies. 

In other devices, we ran into differences between countries in the way
medical devices are used and the level of expertise of the people
using them. 

BTW, anesthesiologists have been dealing with the complexity of
patient management for many years.  I recall some discussions of having
a complex pattern of sounds that would indicate all is well, distinct
variations when things were approaching limits and more variations when
past the limits.  There was some comparison to the cockpit of an
airplane.  

There were also issues associated with the circumstances of use. One
problem was getting designers to realize that the doctor was often too
busy treating the patient to make sure the precious, ingenious device
was being coddled. 
  

    
Attention must be paid to...well, attention. I agree, Trevor, that
attention is one area that interaction and visual design meet. What
should get our attention--and when. I'm on a Mac, so I miss out on a
lot of this, but when I use a Windows PC, I am stunned by the amount of
things that frequently pop up and demand my attention: alerts,
reminders, updates. It's amazing work gets done. We need our devices to
be cognizant of our time and attention. When a virus alert disrupts my
gaming, I'm livid! :)

As far as modes of operation--from "grandma" to, erm, hacker?--I'm of
two minds about that. I personally hate having to choose what level I
am or, on some sites, who I am ("Are you buying or selling hay?"). If
you have to make those kinds of determinations, perhaps what you are
trying to do is too complex, covering too much ground. An argument
could be made, for example, of splitting Microsoft Word up into Word
Lite with basic features and Expert Word. Adobe basically did this with
Photoshop--leaving robust Photoshop for advanced users and ImageReady
for those only wanting a smaller subset of features.
  

    
With most websites, search has devolved into a simple little box in which 
you type your search query. Advanced search? If available, it is available 
from the results page. I suspect that this is a very good thing. Very few 
people need advanced search as a first step, and almost everyone 
understands the basic simple search metaphor at this point.
  

    
Working on a MAC at home, and a PC at work, I would have to agree with
you, Dan, about the number of distractions presented in Windows versus
the MAC OS. In my opinon, the MAC OS does a better job of making
alerts unobtrusive to the user. Vista may do a better job of this than
XP, and from what I've seen of the UI work that was done with Vista
(via Joey Benedek), I'm greatly encouraged. :)

But having said that, I also think that attention tends to be
overlooked or assumed in most Interaction Design, UI and IA work.
Mihaly Csikszentmihalyi has described attention as "psychic energy".
Although this may sound somewhat "new age", he's drawing a parallel
between energy (in the physical sense) and energy in the mental sense.
Like physical energy, once attention is spent, that energy cannot be
spent on anything else. And the language around attention reflects
this. "Pay attention" is one good example. Without an "investment of
attention", nothing gets done in the mental domain (e.g. thinking,
making decisions, etc.). So, in this way, attention affects everything
we do in all facets of design.
  

    
BJ Fogg talks and writes a lot about this in his book Persuasive
Technology. Far from being these "neutral" devices, computers and
digital devices are very effective in manipulating behavior and
attention.

The late Jef Raskin wrote about attention in a cognitive way in his
book the Humane Interface. He called it the "locus of attention" and
noted that we as designers needed to be aware of what has this locus of
attention.

Interesting idea about the manipulation and expenditure of psychic
energy. Never thought of it that way.
  

    
I've read BJ's book and I've also talked with him a bit about this
topic. His studies partially inspired the work I'm doing now with
design and emotion.

Csikszentmihalyi's book on flow is a really great examination of
attention, and how focusing it within the right contexts (both external
and internal) can lead to optimal psychological states (which he
refers to as "Flow"). Reading his book definitely leads one to grok the
importance of attention in a whole new way.

I looked through the Humane Interface some time ago, before I was
interested in this topic. But perhaps it warrants another look. Thanks
for mentioning it. :) 
  

    
I mention Csikszentmihalyi's concept of Flow, but in a different
context: that of our devices adapting to us and in turn, we adapting to
them to create flow.

Despite our having incredible memory and processing power at our
disposal, our devices still act as though those were precious
commodities and hoard them like they did 25 years ago, when system
resources were precious commodities. The speed and power of our devices
could be put to better use: creating flow for their users.

I spend probably 10 hours a day in front of my laptop performing
tasks. In a single week, that's 60 hours of data. In a year, over 3000
hours of data. As any researcher will tell you, that's a lot of data,
and more could be done with it. Why doesn't my laptop adjust itself
slowly over time to reflect how I personally use it? I make the same
spelling mistakes over and over. Why can't the system simply correct
those for me? It could notice and record that I always go back and
change the same errors.

Being a designer, I have a ridiculous amount of fonts on my machine,
of which I probably use about six with any regularly. Why isn't it
easier to get to those?

Interaction designers and developers have gotten into the habit of
preferences and settings--"Have the user tell us what she wants." And
thus (like was discussed earlier) keeping the complexity on the user.
But might it not be better to subtly and over time have the users'
observed behaviors create personal preferences?