Making technology more human

Many of you have heard me say that it is time for technology to be more human. Here is an example of ideas that move in that direction. It's a "technology preview" which means that it isn't real technology, it's a mock-up of sorts. Project Natal for XBOX 360

Time Tracker and Interaction Design

Well, beta 1 of the Time Tracker for deadsimplestuff.com is out in the wild. It was a long road and I still feel like we've just started.  I wanted to take this time to talk about some of the interaction design principles that we used in building the Time Tracker.  Some might notice that the name changed a little.  It is now, Time Tracker.  This is part of the interaction design.  We noticed that "task tracker" lead people to think that it was a to-do list of sorts.  And, while we are very fond of to-do lists, that isn't what we built.

There is more to the interaction design than just the name change, though.  This is the first project of many ideas we have for "dead simple" stuff people need.  We were aiming to make this tool simple and easy to use.  Of course, we aren't finished yet and there are a lot of things we could do better, but the principles remain.

For this project, we started with a small user community, freelance workers. We conducted very brief user research based on budget and time and we built a persona for a freelance worker.  One of the things we discovered about existing time tracking software was the amount of time that the user spent managing the software.  Many of the existing solutions included a start and stop button to start tracking time and to stop tracking time.  Also, most of the solutions included some hierarchy of projects and tasks that the user must create.  Users said that they didn't mind and that it helps them to stay organized.  However, we noticed that the time when tasks are started or when a worker transitions from one task to the next, was a critical cognitive time for the user.  Directing attention to the time tracking software often derailed critical task-oriented thinking and significantly increased the user's cognitive load.  The core process of tracking time was excise to the actual task at hand.

We also noticed that when a user happened to miss when one task ended and the other began that adjusting the times was a bit of a nuisance.  Most people transition from one task to the next.  It isn't a stop-then-start activity, it is a flow of thought and action that typically segues with "life activities."  Many times, the transition happens without the user noticing and at some later point, they notice.  Having to stop the last task, start the next task and then adjust the times for both was a significant jolt to the flow of the day.

Finally, we discovered that users don't think of their tasks in terms of hierarchies, but instead as, "tasks" (go figure).  Any given task fits into a broad spectrum of hierarchies depending on the context from which you are examining the task.  This examination almost never took place at the time the task was performed, but instead was a function of "reflection," or looking back.  Sometimes, it is helpful to look back at the time that was spent "from a different angle."

We do not have it perfect... yet.  We are striving to make this tool in a way that it allows the user to focus as little attention to our tool as possible when transitioning tasks.  This includes not forcing the user to think about the hierarchies at the time of task transition.  We also don't think that the hierarchies should be decided ahead of time.  In fact, there is not hierarchy.  There are tasks and tags; that's it.  Time can be tallied for a task or a tag.  A single task can have multiple tags and a single tag can be used on multiple tasks.

If you've played with the tool (if you haven't, visit theTime Tracker now and play with it), you'll probably notice that there isn't a start and stop button.  This is because most tasks end as the next begins. For the user, it is a single event, not two.  Changing the time of a task transition is simple, you simply enter a single date and time for the transition and the tasks for before and after the transition are adjusted.  If the task was a few tasks back, you can return to it and edit it on the task log page.  For the times when all tasks are truly done, like at the end of the day or for lunch, the user simply enters "stop" as the task.  This is the part of the process that we are still really contemplating.  This seems awkward, still, and their must be a better way.  Any suggestions are welcome.

So, tell us what you think.  You can leave comments here, or on ourfeedback page.

Back in the saddle with a new project

I took a lot of time off from Blogging over the holidays. Now, I'm back and I started a new project during the holidays: the dead simple Task Tracker. The reason for starting this project was twofold.

1. I couldn't find an application to track my time that was easy to use and available anywhere I was.
2. I wanted to learn how to use Google's AppEngine.

Voila! The beginnings of a new project rising from the ashes of necessity. I also want to exercise some Interaction Design principles, too. Here's a screen-shot of the results so far. (The shot is actually an overlay of one screen on top of the other.) The project is in early alpha stages. I still need to add a lot of functionality to make it truly useful to me. However, I have hopes of making it useful to others, too. For that reason, I have created a wishlist of items that I want to add to the service along with an open invitation to all users to respond with feedback and their own items for the wishlist. You, dear reader, are welcome to use the service and include your own feedback. The principle of this service is simple. I want to be able to quickly type in the name of the task on which I am working, without the hassle of setting it up ahead of time and without the hassle of creating projects and sub-projects. I want to be able to see how long I spent on a particular task throughout the day, tracking distractions, etc. The alpha phase of this service allows me to do just that. However, I want to tag certain tasks with various tags and see how much time totals up for a tag, too. I need to be able to correct typos, delete events and all kinds of other things. There is a lot more to do than has been done. So far it is a labor of love, I hope I can see it through. What are the design principles you ask? Well, the primo principle is simplicity. Let me know how I score on that in the comments.

IxD Elevator Pitch

I absolutely loved this discussion post on IxDA from yesterday.  I was intrigued by the variety of answers, but I was most astonished with how difficult it is to describe what we do.

IxDA Discussion: Interaction Designers: What is your elevator pitch?

If you were me, what elevator pitch would you give?  Leave your clever IxD elevator pitches in the comments, please.

User-centered design

The Homer
Originally uploaded by Bolmits Models

I recently had a discussion with someone about being cautious to letting users design the software. Without getting into the arguments about which design school is better and what kinds of user research is best, I wanted to briefly highlight the extremes of user design.

This image is from a Simpson's episode in which Homer is allowed to design a car. It has all the features that Homer wants and yet, as you can guess, turns out to be a huge failure.

Users, like automobile consumers, have lots of ideas of features that they want, activities that they want to do, tasks they need to accomplish, goals that they want to achieve and more.

However, when asking a user to design software, we are asking them to do our job. Our job (as designers) is to take the feature requests, tasks, goals, desires and everything else and synthesize this into a good design that will meet business priorities and the combination of needs/wants of all users.

Letting users design software directly could lead to "The Homer." While this might be hyperbole, the principle remains. Think of the great designs in your everyday life. While the designers very likely listened a great deal to customers and users, they likely weren't designed directly by users.

The alternative is to use methodologies like Cooper's Goal-directed design or other user-centered design processes (as much as you can call these processes). The idea is to let the designers ask the questions that they need answering and to "synthesize" the data into a good design. The results are usually pretty good and customers frequently respond well to the results.

This position on user-centered design is not the only view, just my view. Please, leave your opinions in the comments. I would love to see this discussed more.

Patterns, Idioms and Metaphors

In conversation and in writing, I've used the terms "pattern," "idiom" and "metaphor" in the context of design. But what do these terms mean? Don't these terms pertain to language and not design? Well certainly, these terms are words about language, or a language about language. But, design is a kind of language. The products we design speak a language that is translated from human to machine and back again. However, in the context of design, these terms have special meaning beyond the meaning used to describe spoken language and other mediums.

Patterns

Patterns are easy. We see patterns everywhere. Our human brains are remarkably good at recognizing patterns, even on the subconscious level. A pattern is simply a repeatable relationship of attributes. All of human spoken and written language is a type of pattern. It is the patterns that make it possible for us to communicate.

We can identify patterns in clouds, in water, in paint texture, in highway traffic, in child development, in bird flights and countless other things. This observation of patterns lead to the development and creation of design patterns. This is a different kind of "design" that applies to the programming, development and construction of software. It is related to architecture and engineering. The essence of these patterns is a manner of making concepts that are implicit more explicit and defined. It takes ideas that most people are familiar with and creates a vocabulary that makes it easier for people to communicate about the ideas.

In the context of interaction design, visual design and interface design, patterns are the basic building blocks of making an interface familiar to the humans. When a human being recognizes a pattern, it becomes more familiar and more "usable" to them because of the familiarity. Just about everything that "makes sense" in an interface is the result of a pattern. In the context of interaction design, an idiom is a pattern and a metaphor is a pattern. Think of patterns as the DNA of interface design.

Metaphors

A metaphor is a thing that is a thing and yet, not really that thing. Frequently in language, a familiar (and almost intuitive) concept is used to describe something that is more difficult to understand. For example, when someone says, "John is a closed door on this matter," the person is not saying that John literally is "a movable, usually solid, barrier for opening and closing an entranceway, cupboard, cabinet, or the like, commonly turning on hinges or sliding in grooves." In this case, the speaker is using the very familiar concept of a door to describe John's emotional, judicial and personal attitude and position on a particular subject.

In the context of interaction design, specifically in software interface design, a metaphor is the application of familiar ideas and concepts and using them to convey meaning about a virtual environment. For example, if you are familiar with modern operating systems, you've probably heard of a "desktop." This is not literally the top surface of a piece of furniture, but simply a term used to make a vague concept more discernible to the average person. There are plenty of these metaphors in an operating systems. "Files," "folders," "buttons," and "trees" are not literally these things, but are actually representations of data using metaphoric terms to aid in human communication.

Metaphors are frequently used in the semiotics of icons. If you pay attention to icons in your operating system, you are likely to see many metaphors:

The actions associated with these icons are not represented literally, but rather, metaphorically. This is applied broadly to general interface design as well. Both in the linguistic description of patterns and also in the visual and behavioral representation of interaction elements, metaphors are frequently used to help human beings understand what the machine is doing or going to do.

One of the most common design metaphors is the idea of a "page" or a "document". The computer doesn't need to consider a grouping of data as a page or a document. These are metaphors from pre-computer days that are fairly easy for us to understand. The designers decided to use these metaphors to help humans understand how the data is grouped together.

Idioms

Idioms are like metaphors except that they are less specific and frequently don't use something familiar to describe something less familiar. In the English language, we use idioms all the time. In fact, I just used an idiom: "all the time" isn't precisely true. It is an idiom to mean that the frequency and proliferation of idioms in the language is high or very high. An easier idiom is something like "let's take off." When somebody uses this phrase, they don't literally mean that they are going to take any clothing off. If a listener understands the idiom of "taking off" in the terms of aircraft, they probably wouldn't expect that somebody saying "let's take off" to mean that this idiom is the same as the aircraft idiom (unless maybe they were sitting in an airplane at the time). When someone uses this phrase, they generally mean "I think we should leave from where we are and go to another place."

An idiom is a pattern of language or objects that are not to be taken literally, but that have special meaning within a particular context. Idioms in language and in semiotics are very common and constitute a significant portion of human communication. It is important to note, though, that an idiom is within context and culture is a part of that context. Sometimes different cultures and subcultures that use the same language have idioms that are unfamiliar to each other. For example, I was speaking with somebody from Texas and he said, "...that really burns my hide..." Not being from the same subculture as he, I had never heard that phrase and it took me a moment to understand what he meant. (Sometimes an idiom is called a colloquialism and vise versa, but I don't want to get into discussing the distinctions here.)

In the context of design, an idiom is a pattern of representing behavior using ideas and concepts that aren't to be taken literally. This can be tough to discern at first, so let' look at an example.

The image above contains controls (buttons) with specific behavior attached to them. I think most people are familiar with these buttons. You'll notice that I blurred the text above the buttons to illustrate a point. Even without the text, these symbols, in this basic arrangement have become very familiar to many of us. To take them literally, we have buttons with triangles, squares and circles in specific geometric arrangement and accompanied by significant color (red especially). A square is not an action, but the button performs an action. The square on the button is an idiom--a particular kind of pattern--that conveys meaning to a human being. Below is a collage of screen shots from several software applications using the same idioms. See if you can guess what these software applications do and how these controls work.

Most software idioms are far more subtle and complex than this and require a great deal of effort to appropriately discern and analyze. Most of them become usable through repeated exposure and cognitive learning rather than "obvious" and "intuitive" uses. There is nothing intuitive about a triangle facing to the right. Yet over time, we become familiar with the meaning and this allows us to communicate with a machine.

Hopefully, these brief explanations will help you, dear reader, understand me better. I know, I can be pedantic at times, but it is my humble opinion that the definitions of things help maintain world peace... but that's hyperbole... or is it a simile? ...an analogy? oh well. Please feel free to leave comments below about your ideas about patterns, idioms, and metaphors. If you have any questions, don't hesitate to leave those in the comments as well.

Don Norman's People are From Earth...

Some people call Don Norman grumpy.  I think he just cracks me up.  He's right almost all of the time, but he's also funny about it.  Look at this quote from his latest article, People Are From Earth, Machines Are From Outer Space:

"People are from earth. Machines are from outer space. I don’t know what kind of manners they teach in outer space, but if machines are going to live here in our world, they really need to learn to behave properly. You know, when on Earth, do as the earthlings do. So, hey machines, you need to become socialized. Right now you are arrogant, antisocial, irritating know-it-alls. Sure, you say nice things like “please” and “thank you,” but being polite involves more than words."

Really and truly, why does it have to be so hard to interact with machines?  Why can't machines have better manners?

"Norman’s law: The number of hours per day spent maintaining our equipment doubles every 18 months."

Indeed!  Have a read of Norman's article.  I promise it's short.  Please leave your opinion in the comments below.