703 Creative Blog

Time Tracker and Interaction Design

noreply@blogger.com (mawcs) — Fri, 15 May 2009 12:10:00 +0000

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

noreply@blogger.com (mawcs) — Tue, 17 Feb 2009 17:44:00 +0000

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.

I couldn't find an application to track my time that was easy to use and available anywhere I was.
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

noreply@blogger.com (mawcs) — Thu, 18 Dec 2008 21:32:00 +0000

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

noreply@blogger.com (mawcs) — Mon, 15 Dec 2008 17:52:00 +0000

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

noreply@blogger.com (mawcs) — Wed, 03 Dec 2008 15:28:00 +0000

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...

noreply@blogger.com (mawcs) — Mon, 17 Nov 2008 16:30:00 +0000

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.

Style and Tone, part 2

noreply@blogger.com (mawcs) — Mon, 10 Nov 2008 18:25:00 +0000

The last time I discussed Style and Tone, I focused mostly on style. Today, I want to talk more about tone. Tone is kinda-like the tone of voice we use when speaking with each other. If I say, "you're the greatest" but I use a tone of voice that demonstrates that I don't mean it, I'm probably being sarcastic. Much of what we call sarcasm is the result of saying one thing, but using a tone of voice that conveys another meaning. Our tone is a way of conveying messages without words.

Software design (including Web sites) convey a certain tone without using words. The way a visual interface looks and communicates to the user conveys a design tone. Many times software will convey a tone that is inconsistent with the type of tone that the software developers would like to convey to their users. Sometimes, software tone can be condescending, arrogant, unfriendly or obtuse. Most of the time, software should be inviting, friendly, user-centric and amiable. These are tones that a piece of software (or Website) can convey with sensory immersion techniques.

Take a look at this screen of a Web site:

Some of the words were left un-blurred because they play a small role in tone. Both style and language play a role in tone, but much of it is strictly visual. This site has a "friendly" and "playful" tone. Certainly, with a paragraph beginning with "We are..." one might think that the site is a little self-centered; which might be true. But it is consistent with a tone that I would call "open." The site is up-front and honest about who it represents in addition to stylistically inviting the user in. Some of the text begins with "Hello..." which tempers the self-centered text above. In addition, we see call-out bubbles, and paper airplanes in an open sky above clouds. It is imaginative and open, but the green at the bottom "grounds" it in reality. The site makes it clear that it (and the people behind it) want to have a dialog, or conversation with you, the user, and they want to skip some of the typical formalities in doing so.

For a little bit of contrast, look at this site screen shot:

While the visible text might make it seem conversational in the same way the previous site did, there are some subtle differences in tone here. They say, "Hello," but end up looking far more self-centered than the previous site. This site is obviously proud of themselves with their pictures on the home page (avante garde styling aside), their obvious "Check (us out)" intro and the incredible emphasis on Mac hardware/software (no actually affiliation, just a bit of pride).

The "Let's talk" is less friendly and the style is more of a 'coolness' and an 'aloofness.' I would call this tone, 'cool and proud.' This tone is very appropriate for their business and it isn't a negative connotation. This appears to be the right tone for the customer and works for them. It is merely a contrast with the previous site.

Try this site on for size:

What do you make of this tone? What do they represent? Who are they? Leave your comments on this post and share!

What the heck is Fitts' Law?

noreply@blogger.com (mawcs) — Fri, 07 Nov 2008 19:30:00 +0000

Ok, so somebody asked me this question, which seems to remain unanswered in my blog, "what the heck is Fitts' law?"

Fitts' (pronounced fitz-ez) Law is pretty simple. The ability to reach or hit a target is a function of the distance to the target and the size of the target. Let's use an analogy, suppose I put a bow and arrow in your hand and ask you to hit a target. Regardless of your skill, I can make this task very easy for you by putting the target at "point blank" range and you won't miss. The short distance will make it very easy. The other thing I could do is make the target as large as a skyscraper and place you 25 feet away. I'm pretty sure you'd still be able to hit it even though you are further away (it's as big as a building!).

This relates to design as well; especially software design. Most actions that a person executes on a piece of software is achieve by the physical motion of the person. This is typically achieved either by mouse or keyboard. With mouse and keyboard, the virtual action is a translation of a physical action.

For example, when you move your mouse up to the "Favorites" or "Bookmarks" menu to bookmark this blog, you are translating the physical action of moving the mouse into a virtual action of motion on the screen. There is a physical spot on your mousepad or desktop that corresponds to the location of the "Bookmarks" menu item. Some people are more dexterous than others in reaching that point. But in any case, it requires the dexterity of "acquiring" the target. If you overshoot the target, you must make corrections in order to land the mouse cursor in the right space to manipulate the action associated with that space.

The smaller it is, the more corrections you will need to make in "acquiring" the target. The further that target is from your current mouse cursor position, the longer it will take, and the more dexterity it will take to reach that target. For software design, this means that any action that is important for the user's current task should be close to the user's current position and large enough to "acquire." Other actions that are less important should be further away and smaller.

Back to our bookmarks example. Let's pretend that bookmarking a site is the most important action. We could make the bookmarks menu a larger button and put it right next to the page that you are visiting so that it is a quick shot of the mouse to reach it.

There is another aspect of virtual size and distance that doesn't translate directly into physcial space. Most desktop operating systems are designed with screen edges that do not allow the mouse to move beyond the edge of the screen. This is a huge, nearby target.

Go ahead and push your mouse to the top of the screen; pretty easy right? You could probably do it with your feet instead of your hands, it is so easy. If a menu bar is "pinned" to the top edge of the screen (like the MacOS X menu) it is far easier for users to reach the menu and thus the items on the menu. This is one of the reasons that I have long disliked the "title bar" of Microsoft Windows. It occupies important space with little-to-no benefit to the user.

In my posts about the ribbon pattern, I mentioned that it is an improvement over older patterns, but that it has problems in regards to Fitts' Law. Namely, that it leaves "a small strip of dead space above the quick toolbar [that] breaks Fitts' law." Hopefully, now this comment makes more sense to you, dear reader. The 2-pixel strip of dead space above the quick access toolbar shrinks the targets of the bar and places is it much further away in virtual space.

Do you have any additional questions about Fitts' Law? Leave questions and comments at the end of this post. I've been pretty good about responding to commenters, give it a try.

Luke Expands on Design Misconceptions

noreply@blogger.com (mawcs) — Wed, 05 Nov 2008 21:36:00 +0000

In an earlier post I linked to a podcast with Luke Wroblewski and Jared Spool regarding common visual design misconceptions. (Visual Design is one of the many sub-disciplines of IxD.) Luke officially wrote and article for UXMatter.com that dives deeper into the same subject.

Please share your thoughts in the comments section of this post.

Ethnographic studies

noreply@blogger.com (mawcs) — Wed, 05 Nov 2008 21:18:00 +0000

This article on Ethnography on My Customer.com is very interesting. Interaction designers use ethnographic studies to generate better research data about user and people behavior. This article isn't specific to IxD, but more generic business. Give it a read and leave a comment on this post with your thoughts and opinions about it.

Style and Tone

noreply@blogger.com (mawcs) — Mon, 03 Nov 2008 21:16:00 +0000

I've spoken with several people here about style and tone. It is somewhat abstract theory and difficult to describe in words. I can simply say, "style is some adherence to a related set of forms" or "tone is like a tone of voice, only not using words" and people generally nod their head, but I don't think the extent of it really sinks it; they can't see it in action.

So, I thought I would put together a list of Web site screen shots to discuss style and tone. The ideas don't just relate to Web design, but to any design. However, since Web design is most prevalent, it is the easiest medium to use to discuss the principles.

To get started, take a look at this screen shot of a Website.

Now, you'll notice that I've blurred a lot of the text. While text is a small part of style and tone, it can also lead to confusing discussions about vocal style and tone of voice; which are similar, but not entirely the same. Also, if you know the owner of this site, or you are the owner, my apologies for the critical look at the style and tone; bear with me, though, I think it is a valuable discussion.

So, just focus on the visual aspects of the site, including font choice, color, layout, margins, contrast, alignment, etc. The font is Arial, a fairly straight-forward sans-serif font. It certainly isn't monochromatic, the contrast of text on background makes some of the text difficult to read. The eye doesn't know where to land and the background is "noisy." These are the aspects of "style." To describe this style, I would call it gaudy and bricolage. It certainly couldn't be described as "elegant" in style, nor is the style particularly "hip" (for lack of a better term).

Contrast the former site with the one below. Remember to look at the visual aspects of the site.

This site has a completely different style from the earlier one. This one is certainly appropriate for pop culture; It has "fashion" and appeal. But I wouldn't call it "elegant" or even "clean;" it has a sort of "dirty" bricolage feel to it also; but more of a street-wise bricolage. It also uses a fairly plain Times New Roman serif font, nothing fancy, but the line-height and kern are adjusted stylistically. I would describe this site as a "postmodern" and "pop culture" style.

So, armed with the above examples, leave a comment on this post describing the style of this site:

I will probably post more on this topic in the future, so stay tuned.

Vocabulary

noreply@blogger.com (mawcs) — Wed, 29 Oct 2008 14:54:00 +0000

I was recently in a discussion with several team mates about design validation. I had the distinct impression that they were going to embark on design validation using old processes. I had this impression because they used terms like "testing the flow," "workflow," "interaction," and "navigation." These were the things that they wanted to "test" in the QA group. While I have no problems with testing these concepts in the QA group, I wanted to bring in some tried and true design validation scenarios to maximize the results of the process.

My scenarios alarmed and frustrated the team and my initial reaction was that the team was once again resisting design processes and I needed to engage in "pushing" the team to "do it right."

But they wouldn't budge. Something was wrong and it took a while for me to figure out that what they wanted to do was some form of integration testing, or as the QA lead called it "exploratory testing." They didn't actually want to test the "flow," "workflow," and "navigation." They wanted to test the product of development by utilizing "workflow" and "navigation." Heretofore, we had called this process "design validation" because of my misunderstanding.

Once the confusion was resolved I said, "Oh, you want to do some integration testing." To which the response was, "I don't care what you call it..." I heartily agreed that we didn't need to quibble over terms and to move on with productive tasks.

However, having time to think about this and the implications of what happened, I realized that the problem is the result of differing vocabularies. We are saying the same words, but speaking different languages. My presence is the introduction of a new vocabulary and getting this vocabulary right will help everyone understand things better.

Certainly, arguing about the meaning of words is pointless, but when different vocabularies lead to confusion, it is time to define words explicitly in order to avoid confusion. I believe that we should be careful to define our terms and be explicit and forthright about the meanings we intend. This is the foundation of "communication" which is often to blame for struggling projects.

Ribbon Questions Answered

noreply@blogger.com (mawcs) — Mon, 27 Oct 2008 16:55:00 +0000

Some think that the ribbon pattern was intended to replace the traditional toolbars and so, have concerns about the way a ribbon works in comparison to a toolbar. This is only partly true, but it is better to think of the ribbon as a replacement to the menu pattern. The ribbon pattern also replaces the toolbar pattern with the "quick access toolbar"

Take a look at this image of Microsoft Word with most of the common toolbars available.

Each of these toolbars is a representation of only some of the functionality available in Word. To get to all of the information, you must learn the menu structure of Word and rely on textual information only. Tools of prominent use have no emphasis above tools with less common use. They are the same size and require "customizing" to change the layouts of toolbars.

The ribbon pattern, on the other hand, takes the menu structure and lays it out in tabs making the exploration a little easier. The context of the user's task is adjusted by automatically changing the ribbon tab for the user instead of displaying and hiding toolbars. Any tool that a user wants available regardless of context can be added to the quick access toolbar with a simple right-click action.

Thinking of the ribbon as a replacement to a toolbar, one might complain that not all tools are available for immediate access like they are in a traditional toolbar. This thinking has two problems: 1)Even traditional toolbars are hidden and displayed based on context; look at the "Reviewing" and "Outline" toolbars in Word. It is impractical to have all toolbars available because of limited screen space. 2)The quick access toolbar portion of the ribbon is intended to serve this purpose, except that instead of giving the user an entire toolbar full of tools they may or may not use, it is easily customizable to be exactly what they want.

A few bonus details is that the screen space is managed better because the ribbon is collapsible (or minimizable) and the typically-wasted space of the title bar now a has more functional use.

So, now it is your turn. What are your complaints about the ribbon pattern? Got any questions? Do you love it? Leave your comments on this post to start the discussion.

Tied up nicely with a Ribbon

noreply@blogger.com (mawcs) — Wed, 22 Oct 2008 16:23:00 +0000

For one of my projects, we chose to use a ribbon (like Microsoft Office 2007) instead of the now-traditional toolbar and menu approach. There were several factors relevant to this choice; some negative, some positive. One of the leading factors is that our suite of applications have some degree of integration with Microsoft Office, specifically Excel. While currently we are only supporting the 2003 version of the software in beta, there is a strong emphasis on supporting the 2007 version in the very near future. Using the ribbon pattern in our software positions us to have a degree of cohesion with Office 2007 as well as preparing our application for the future. As and example of this principle, I use SnagIT 9 which also uses the ribbon pattern in the SnagIT editor. But, just because Microsoft does it, doesn't mean we should do it, right? There are certainly a few negative factors that must be taken into account. One of the advantages of Menus is that the text description of the action is directly associated with the taxonomy, and offers the user the possibility of exploring the product's capabilities through this taxonomy. Explorability is important and menus do offer a very structured way of exploring a product. However, the "taskonomy" of the Ribbon offers an alternative form of explorability that I think will prove to be superior as time progresses. Another issue with the ribbon is the context-aware tabbing of the tools. Traditional toolbars show everything on the screen at once. Some are relevant to the current task, others are not. The ribbon allows the user to just see tools relevant to the current task and related taxonomy. However, there are times that a user needs a tool from another tab and the inclusion of tabs increases the effort to reach this tool. Multiplied over numerous uses, this can be an amplified excise. However, the ribbon pattern offers a "quick" toolbar that shares space with the titlebar (usually wasted space in my opinion). These tools are always availabe regardless of the ribbon tab space. The application menu also provides access to additional behaviors that are universally available. Keyboard navigation, initially, seems to suffer also. With menubars and menus, the user could navigate the menus with a keyboard. People usually notice that without menus, it appears to be mouse-only. However, the Ribbon will display immediate keyboard hints when the "alt" key is presed on the keyboard. In my opinion, this is superior keyboard navigation because the possibilites are immediately displayed to the user. Fitts' law is also applied, although still with problems. Tools with frequent use can be made larger and include text to allow the target behavior to require less effort. Unfortunately, a small strip of dead space above the quick toolbar breaks Fitts' law making a maximized application more difficult when approaching the quick toolbar; effectively, this slows the use of a "quick" toolbar. The other major factor in using the ribbon is that many people are not comfortable with it. This is an unfortunate truth of human behavior: change is difficult to accept. In my opinion, all good things come with change. I believe that the ribbon will eventually become familiar to people as they continue to work with the tools and as they become increasingly more popular.

Always Pushing

noreply@blogger.com (mawcs) — Wed, 15 Oct 2008 14:47:00 +0000

I'm not a pushy person... really! I tend to be a wimp and want to avoid conflict. Sometimes this "personality trait" is a tremendous weakness; and other times it is helpful. However, here at S&P, I can't afford to succumb to this personality trait and I feel like I am constantly "pushing" the people around me.

Part of a designer's job is to compromise; on just about every design decision, there is the weight of meeting business objectives, working with technical limitations, having limited resources and working in the confines of proficiency--which all limit the product of design. The designer's job is to work within these constraints. The difference between a designer and an artist is that a designer knows when to compromise because without compromise, design becomes strictly art.

Here at S&P, they aren't accustomed to having a designer as part of product development. They are happy doing everything, and it can be difficult to let go of some things. I think some might have the false belief that they weren't doing design before and now they are, and therefore, my presence is an addition to their process. However, there is no such thing as "no design"--all products are designed. The reality is that my presence is a subtraction of old processes and additions of new processes in their place.

It is difficult for human nature to let go of responsibility and to delegate, or "let go" in order to improve the outcome. (I don't have empirical proof of this, just a designer's intuition.) So I feel like I am always pushing the team to let go of old processes and adopt new ones. The design outcome is diminished, and I happen to think this team is capable of so much more, so I must constantly push the team to build a better UI.

If the "perfect" UI is measured by 100%, then since my arrival, this team has built a UI at about 25% (in my humble estimation) which is better than 5%, 10%, or even 24%. But, we still have 75% to go and my only choice is to constantly push for more design.

Obviously for me, pushing like this is emotionally difficult and "draining." There are times that I want to just cave and go with the flow, but then the outcome wouldn't improve. So, I am "always pushing" and I'm sure my presence is sometimes felt as a tedious annoyance. I am taking away responsibilities and shifting power. It isn't comfortable, but necessary in order to create products that are truly delightful for users to experience.

So, this post is my apology and plea combined. Apology for always pushing and a plea to join me in always pushing.

Am I GUI?

noreply@blogger.com (mawcs) — Mon, 06 Oct 2008 21:21:00 +0000

Some people seem to think that I don't like the term GUI (pronounced goo-ee). In fact, when I was called "the GUI guy," I thought it would be fun to put the monicker on the outside of my office.

But, it's not entirely true that I don't like the term. The term GUI, meaning Graphical User Interface is an important part of my job. Most software is designed with some form of a GUI interface. I happen to be a very visual person and enjoy the aesthetics of a well designed GUI.

However, I do have some problems with the term. First, some important interaction does not occur within a GUI, but with sound and other interaction mediums. Second, the GUI in most products does not indicate that it is better for users. Most GUIs are not designed well, and designing products for users is a heck of a lot more than working with GUIs.

An "attractive" design isn't always more usable and a good visual design isn't always more usable. Usability is found in how a user interacts with the behavior of software. Working with GUIs will only solve a small part of usability problems. Working with mental models and with workflows yields a much greater result on usability.

On top of that, GUIs these days, can be automatically generated as a result of the underlying data. The application just spits out textboxes and comboboxes becaue the data can be represented in that way. There is zero design in this situation; other than what the authors of the tool did by way of design. No usability is taken into consideration in theses cases; no real design is done; but there is still a "GUI."

I prefer designing interactions instead of GUIs. I prefer getting to know the user's goals and subconcious in order to design software that is delightful to use; software that knows the user better than most people do. This involves using mediums other than the visual and working with a lot more than just the graphical interface.

So, I don't dislike the term GUI. But, I certainly work with a lot more than the GUI to design products.

What is a "True" Interaction Designer?

noreply@blogger.com (mawcs) — Mon, 29 Sep 2008 18:20:00 +0000

I just finished reading Uday Gajendar's blog post about What’s a “true” interaction designer? I find little to disagree with. I have always been partial to (and perhaps over-emphasize) the aesthetic and graphic aspect of my job, but I wouldn't expect someone to say that it isn't part of my job.

But it is only part of the job. There is a lot to it. His bullet points are worth noting:

Believes in the human experience...
Is a champion of aesthetic value...
Leads with a design process...
Does typical process artifacts like diagrams, flows, wireframes, site maps, system models...
Sketches, draws, visualizes, iterates, prototypes, over and over again, to get better resolution of solutions for well-defined problems.
Takes pride in the craft of making a superb experience...
Leverages research (of users, of technology, of business)...

I particularly liked how he wrapped up the discussion, though. "In sum, my view of a “true” interaction designer is really an informed visionary."

Design Misconceptions

noreply@blogger.com (mawcs) — Wed, 24 Sep 2008 19:23:00 +0000

I've mentioned this before, but I thought it was important to highlight it. A while back, Jared Spool interviewed Luke Wroblewski (both interaction designers of sorts) about some of the misconceptions of design. It is a fairly short podcast interview that is well worth listening to. In the interview, they refer to "visual design." For our purposes, this is synonymous with "interaction design." Have a listen and let me know what you think.

What is an interaction designer?

noreply@blogger.com (mawcs) — Wed, 24 Sep 2008 12:00:00 +0000

Well, I've briefly explored what a designer is, but I'm sure many of you are asking, "okay, but what is an interaction designer?" An interaction designer is a designer with a specific emphasis on the interaction between human beings and machines. There are lot of terms that seem synonymous, such as User Experience Designer, Visual Designer, Human Factors Engineering and the like. But I've found Interaction Design(er) to be the most appropriate definition. The founders of this term and ixda.org offer a nice definition:

Interaction Design (IxD) is the branch of user experience design that defines the structure and behavior of interactive products and services.

...except, doesn't that seem vague? What is "user experience design?" What is "behavior?" What are "interactive product?" What is an "interactive service?"

Looking at Wikipedia, there is some help:

The practice typically centers around complex technology systems such as software, mobile devices, and other electronic devices. However, it can also apply to other types of products and services, and even organizations themselves. Interaction design defines the behavior (the "interaction") of an artifact or system in response to its users.

And it goes even deeper:

Certain basic principles of cognitive psychology provide grounding for interaction design. These include mental models, mapping, interface metaphors, and affordances any of these are laid out in Donald Norman's influential book The Design of Everyday Things. Interaction Design (IxD) is the discipline of defining the behavior of products and systems that a user can interact with.

...and that's the part I love; the part of my job that is most challenging and rewarding. It's where the rubber meets the road and real design begins. Except that most organizations find it difficult to accept and invest in cognitive psychology and user research. I hope that this will change over time.

But, what does an interaction designer do? Interaction design is essentially a different way of doing product design. Traditionally, companies look at their users as "customers" and try to understand them as customers. This treatment has a range of results from 1) basically, letting the users design the product, to 2) the company designs the product and ignores customer input.

This whole range of results has a fundamental flaw and that is the view of the "customer." Interaction design attempts to look at users from a different perspective... as people; with personal goals, ideals, opinions, efficiencies, flaws and the like. The basic idea of interaction design is to get inside the user's head and use that information to design a product. It includes getting feedback from the users, but it doesn't burden them, nor expect them, to design a product.

With an understanding of users apart from being "customers," interaction design attempts to solve design problems using creative thinking and well-defined patterns. Solving these design problems requires a set of skills and education that includes some principles. Bruce Tognazzini handily distills the basics. Here are a few quotes:

For example, which of the following takes less time? Heating water in a microwave for one minute and ten seconds or heating it for one minute and eleven seconds?From the standpoint of the microwave, one minute and ten seconds is the obviously correct answer. From the standpoint of the user of the microwave, one minute and eleven seconds is faster. Why? Because in the first case, the user must press the one key twice, then visually locate the zero key, move the finger into place over it, and press it once. In the second case, the user just presses the same key–the one key–three times. It typically takes more than one second to acquire the zero key. Hence, the water is heated faster when it is "cooked" longer.

...

The great efficiency breakthroughs in software are to be found in the fundamental architecture of the system, not in the surface design of the interface. This simple truth is why it is so important for everyone involved in a software project to appreciate the importance of making user productivity goal one and to understand the vital difference between building an efficient system and empowering an efficient user. This truth is also key to the need for close and constant cooperation, communication, and conspiracy between engineers and human interface designers if this goal is to be achieved.

...

Give users well-marked roads and landmarks, then let them shift into four-wheel drive. Mimic the safety, smoothness, and consistency of the natural landscape. Don’t trap users into a single path through a service, but do offer them a line of least resistance. This lets the new user and the user who just wants to get the job done in the quickest way possible and "no-brainer" way through, while still enabling those who want to explore and play what-if a means to wander farther afield.

...

Wherever possible, use multi-threading to push latency into the background. Latency can often be hidden from users through multi-tasking techniques, letting them continue with their work while transmission and computation take place in the background.

I'm sure some of you are thinking, "that sounds like the business team's job", or "...the architect's job", or "...the developer's job". Essentially, you are correct. It is all of our jobs to do these things in the interest of making interactive products behave more like people and to stop making people behave like interactive products such as computers. However, the disciplines behind all of these jobs sometimes precludes these roles from making decisions in favor of users and that is why designers are exerting more emphasis on product design; to return product design back to being more human-oriented.

Cooper, in About Face 3.0 points out,

There is an important conflict of interest in the world of digital product development: The people who build the products -- programmers -- are usually also the people who design them. Programmers are often required to choose between ease of coding and ease of use.

This notion is used to support the hypothesis that product design needs a better process which he calls Goal-directed design. This is the process that I try to use (with my own modifications) to design a product that more accurately meets a user's goals and balances those with the business goals.

Don't Judge a Book by It's Cover!

noreply@blogger.com (mawcs) — Sat, 20 Sep 2008 16:00:00 +0000

I've heard comments before about the stereotypes about the appearance of "designers." It's kind of humorous, but there is a seriousness to it, too. But, let's skip the seriousness for a moment and check out this site.

Designers vs. Developers.

It's an Australian site (apparently built with WPF!) that throws photos of people on the screen and we are supposed to guess whether they are designer or developer. I'm batting 500 at the moment :).

Enjoy!

What is a designer? Distinct

noreply@blogger.com (mawcs) — Fri, 19 Sep 2008 13:30:00 +0000

If designers are so different, what's the use of having them around? There are two factors to answering this question. First, there is frequently a misconception of what designer does and contributes to a product. The second is an honest question of the value of that contribution.

Let’s deal with the misconception first. A lot of people think that a designer simply makes things look pretty. In fact, questions like this end up in the forums of design studios like 37 Signals:

Designers decide and design the flow, the copy, the structure of the page, the programmers make all of it come to life by plugging it into the backend. All along both parties trade concessions on how to get the feature done as fast possible by grabbing the easiest value.

So stop thinking about designers as artists who work in a different universe of neat graphics and start thinking of them as someone who decides what goes where, which form elements to use, how to split features between screens, what words to use, and how everything fits together in a coherent experience.

I find 37 Signals position on topics to be a bit harsh most of the time, but they are trying to deal with what appears to be an epidemic of misconception. Personally, I don't think it is all that bad; but I see that it exists.

Designers are problem solvers, critical thinkers, cultural critics, creative solution providers and a skilled mix of artisan and technician.

The requirements that a designer works to are both objective and subjective... It’s the subjective, creative side of design that’s hardest to explain and hardest for most people to understand. The aesthetic side of design relates to fashion, human behaviour, emotion and cultural influences such as the cultural meaning of symbols. [1]

When it comes to designers and non-designers, there is often a difference in perspective that makes communication, but it doesn't need to be that way. Designers think differently and that is part of the value that a designer brings to a product.

Design is a strategic tool used to gain market advantage by companies operating at an international level. Their products, their branding, their promotion and their business premises are all designed to maximise customer acceptance of the goods and services they have to offer and to optimise the day to day operation of their business. [1]

[1] Design Institute of Australia - What is a Designer?

What is a designer? Different

noreply@blogger.com (mawcs) — Thu, 18 Sep 2008 16:27:00 +0000

Over the years, I have done some development as a means of survival and necessity. I'd have to say, it isn't my favorite thing to do. I enjoy aspects of it because I can see my designs come to fruition; but frankly, some of the deeper technical stuff like memory management, pointers and references, efficient algorithms, protocols and all the other various "programmer concerns" tend to both frustrate and bore me. It has really struck me how unique people are.

I've met developers that enjoy working with the concepts mentioned above. Those same people are sometimes driven to frustration dealing with design principles such as contrast, repetition, alignment, proximity, balance, white space, proportion, sequence, unity, color theory, Fitts' law and many others. Never mind that the tools we use have very unique information architectures and workflows.

So, why are designers so different? Is it personality? Is it brain chemistry? I would not be surprised to learn that this is the case. Whatever it is, I think it is safe to say that it is a different perspective with its own set of disciplines and processes… did I say "processes?" Well, design processes are difficult to understand, too. Idris Mootee says,

I’ve seen hundreds of design processes that are anti-design in nature. They force a linear process-driven approach to design as if it is a production line (Six Sigma for Design? No thanks)

I don't think that he means to say that "there is no process," but that a design process is so distinctly different from other processes that it is difficult to articulate into language and sequence. But as designers, we are frequently found inside of processes invented by non-designers and, in a sense, struggling with it… it's our lot in life.

What is a designer? Defined

noreply@blogger.com (mawcs) — Tue, 16 Sep 2008 16:55:00 +0000

So, what exactly is a designer anyway? We could explore technical definitions and opine all day long about the definition of "designer." I'm sure we could find one definition for the word for every designer that exists; or more.

Ok well, let's start with a definition from Merriam Webster:

: one that designs: as a: one who creates and often executes plans for a project or structure designers> designer> b: one that creates and manufactures a new product style or design ; especially : one who designs and manufactures high-fashion clothing designer's new fall line>

Hmm, not very satisfying. We all love free information, what does Wikipedia say?

A designer is a person who designs something. Perhaps the broadest definition is that provided by Herbert Simon: ‘Everyone designs who devises courses of action aimed at changing existing situations into preferred ones.’

Ugh, not much different from Webster. But, as we read on, we will find something a little more helpful:

Working as a designer usually implies being creative in a particular area of expertise. Designers are usually responsible for developing the concept and making drawings or models for something new that will be made by someone else. Their work takes into consideration not only how something will look, but also how it will be used and how it will be made.

The word, "design" is frequently used in a lot of contexts as a synonym for "plan." [1]But, we are talking about designers as professionals that are distinct from other professionals.

Designers bring human and cultural values to business problems, values that sell products and services, create demand and inspire customer confidence and loyalty.

I think we can start to see that "designers" are defined different from other professionals in a myriad of ways. But they are also distinct among people, too.

[1] Design Institute of Australia - What is a Designer?

What is a designer? Defined

noreply@blogger.com (mawcs) — Tue, 16 Sep 2008 16:55:00 +0000

What exactly is a designer anyway? We could explore technical definitions and opine all day long about the definition of "designer." I'm sure we could find one definition for the word for every designer that exists; or more.

Ok well, let's start with a definition from Merriam Webster:

: one that designs: as a: one who creates and often executes plans for a project or structure designers> designer> b: one that creates and manufactures a new product style or design ; especially : one who designs and manufactures high-fashion clothing designer's new fall line>

Hmm, not very satisfying. We all love free information, what does Wikipedia say?

A designer is a person who designs something. Perhaps the broadest definition is that provided by Herbert Simon: ‘Everyone designs who devises courses of action aimed at changing existing situations into preferred ones.’

Ugh, not much different from Webster. But, as we read on, we will find something a little more helpful:

Working as a designer usually implies being creative in a particular area of expertise. Designers are usually responsible for developing the concept and making drawings or models for something new that will be made by someone else. Their work takes into consideration not only how something will look, but also how it will be used and how it will be made.

The word, "design" is frequently used in a lot of contexts as a synonym for "plan." [1]But, we are talking about designers as professionals that are distinct from other professionals.

Designers bring human and cultural values to business problems, values that sell products and services, create demand and inspire customer confidence and loyalty.

An Introduction

noreply@blogger.com (mawcs) — Mon, 08 Sep 2008 14:11:00 +0000

Hello and welcome to the my Interaction Design blog. I'm an Interaction Designer. I hope to put a brief autobiography on this blog shortly. This blog is a place for me to share what I'm learning and to give insight into the work that I am doing. I can't share any trade secrets, so things will be a little vague and superficial, but I aim to make it worthwhile anyways. I want to dig into the strengths of interaction design and how it makes a difference in the production of software and Web sites. I want to explore ideas for making interaction design work for companies that are emerging into a new and exciting chapter like S&P's Compustat products are. I want to make explicit all of the things that are implicit so that they can be discussed with more rational thought than merely assumptions and opinions. I want to reach out to others in the UI design community and share ideas. So, I welcome you to join me on this journey. With warm regards to all of my readers, Michael Williamson