Vocabulary

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

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

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

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?

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.