DesignAday

In the Details: Field Promotion

I stumbled upon an interaction today on my iPhone that made me smile—kind of like finding a chocolate on my pillow. I don’t often edit people’s contact information on my phone, but I had call to do it today. Open the Contacts app and edit one of your contacts. Enter some text into the street address field. A second field slides down as soon as you enter the first character. Enter some text into the second field, and a third field appears. Now, clear the first field and tap on the second field. The populated second field slides up, replacing the empty field.

It’s a very simple thing, but it is so elegant. Nicely done, anonymous Apple UI designer.

Less JS

As I have become more and more proficient with CSS, and as support for CSS3 selectors has improved, I have been making a concerted effort to implement as much behavior as possible through CSS rules, rather than JavaScript. Historically, it has been up to the developers to update UI element states through DOM manipulation. I have found, however, that I can do an awful lot with a single class placed on a high level element.

For example, let’s say you are implementing a copy/paste function within a web application. There is a tool bar containing buttons to delete or copy a selected item and a visual representation of the item on the clipboard. There is also a paste button that will show up at specific locations within the content when the cursor hovers over containers that can be pasted into.  The toolbar buttons enable only when an item is selected. The clipboard is hidden until populated, and the paste button only displays when the clipboard is populated. The way this functionality would have been implemented in the past would be to run through a JS sequence of events each time an item was selected to enable the buttons by changing the classes assigned to them (or worse, write inline styles). When an item was copied, JS would change the style applied to the clipboard, and every time a container was hovered over, it would check a variable to see whether or not it should show the pasted icon, and then manipulate it’s style.

While I can’t get rid of JavaScript, I can limit its complexity. By placing a class on an HTML element high in the hierarchy (e.g. the body tag), I can easily drive complex state changes throughout the UI. In the above example, JS could be used to add the class ”selectionTrue” to the body, and selectors keyed off of that class would style the delete and copy buttons to appear enabled with their corresponding hover and active states. Remove the class on deselection, and both buttons go back to their disabled states. When an item is copied to the clipboard, a single class on the body, say “clipboardTrue”, can be used both to display the clipboard in the toolbar and show the paste button wherever it occurs on hover. JavaScript is reduced to adding or removing a single class in an easily accessible spot, rather than combing the DOM.

The result is less complexity in the JavaScript that requires a developer to maintain. The complexity is in the CSS, which the designer is responsible for. This is appropriate, since the designer is the one who should be responsible for the behavior in the first place.

Hide and Seek

Final grades are due today, so I was submitting them last night through WVU’s STAR system. I entered the grades and pressed the “Submit” button below the table. There was a flash as the page reloaded and… looked exactly the same as it did before I hit the button. How am I to know if the grades were actually submitted?

Do you see it? No, it’s not the line in red, nor is it the line in blue. It’s not at the very top, nor is it at the bottom. It’s not either of the lines with the proverbial exclamation point in a yellow triangle. It’s the sentence just above the table—you know, the one that looks just like every other line of text on the page.

If you are going to display confirmations inline, make sure they are conspicuous.

IxD Podcasts

I’ve posted lists of books, journals, and blogs for the IxD n00b; it’s about time I do the same for podcasts. It takes a lot more work to publish a regular audio show than it does a blog, so there are a lot fewer of them, and fewer still with professional-level production values. Here is my recommended set, in alphabetical order. There are others, but these are the ones to which I subscribe and know to be of value. Of course, you are always welcome to add your own recommendations in the comments.

Adaptive Path
Adaptive Path’s podcast has 103 episodes spanning from 2006 to 2012. 5 of the episodes are videos. However, all of the episodes more recent than 2008 are other podcasts featuring their people. So, I’m considering this one defunct.

Boxes and Arrows
This is a prolific podcast that has been running regularly for several years. The production values aren’t at a professional level, but the content is excellent, made up mostly of interviews and conference presentations. Their coverage of the IA Summit is thorough, having included all of the presentations in past years.

Design Critique
Tim Keirnan encourages usable products for a better customer experience. He does so by reviewing products that he has purchased and used for significant periods of time. He also conducts interviews with user experience practitioners, authors and educators. With 97 episodes since 2005, there is a lot to listen to.

Design Matters
Debbie Millman’s podcast isn’t specifically about Interaction Design; it’s about all types of design, or rather, all types of designers. Debbie conducts interviews with “industry-leading graphic designers, change agents, artists, writers, and educators.”  It’s certainly my favorite design-related podcast. For an in-depth review, see my earlier post.

Icon-o-Cast
Lunar has been podcasting about product design since 2005. They don’t have a regular schedule, and there can be long gaps between episodes, but they have a good selection of discussions, interviews, and critiques with a smattering of video episodes. 

The Prepared Mind
Chris Gee’s podcast was the first design podcast I subscribed to back in 2005. Unfortunately, it only lasted six months, topping out at 13 episodes. Oh, but what a fine set of podcasts they were. I include them here as a nostalgic tribute.

Radio Johnny
Johnny Holland’s podcast only started in 2010, so it doesn’t have quite as large an archive as most in this list, but you can expect to find interviews with a lot of the names you have become familiar with through IxDA, IAI, and the general UX community. The audio quality isn’t particularly good, but the content is worth it.

UIE Brain Sparks
It should be no surprise that Jared Spool has the most prolific podcast in this list. Only the last 100 episodes are listed in iTunes, but this one has been going in earnest since 2006. There are tons of interviews, discussions, debates, and segments from conference presentations. Continue encouraging their behavior.

UXpod
Gerry Gaffney has been conducting interviews with UX practitioners since 2006. There are 66 episodes as of this writing. The audio quality is typically rather poor, and I find this one to be the least exciting of the podcasts listed here, but there is still enough valuable content that I remain subscribed.

99% Invisible
Both the newest and best produced podcast in the list, Roman Mars’ brief exposés are entrancing. While not specifically an IxD podcast, it is 99% relevant. Check out my review from a couple weeks ago. 

Design Vocabulary: Affordance

An affordance is a quality of an object or environment that allows one to perform an action. For example, in the physical world, a light switch affords flicking in two possible directions, but only one based on its current state.

Affordance is a term that quite a lot has been written about. Both Wikipedia and Interaction-Design.org have thorough explanations of its origins and tell the history of its adoption by HCI and design. In brief, the psychologist James J. Gibson published The Theory of Affordances in 1977, which he further explored in his book The Ecological Approach to Visual Perception in 1979. His wife, Eleanor J. Gibson, continued studying affordances in her own book, An Ecological Approach to Perceptual Learning in Development.

Don Norman introduced the term to the field of Interaction Design in his book, The Design of Everyday Things. In the process, he inadvertently broadened the meaning by not making a clear enough distinction between real and perceived affordances. He later corrected this in an article titled Affordances and Design.

I should have used the term “perceived affordance,” for in design, we care much more about what the user perceives than what is actually true. What the designer cares about is whether the user perceives that some action is possible (or in the case of perceived non-affordances, not possible).

The correction came too late, however, and we now use the term loosely as a suggestion or invitation. For example, we might say that the hover highlighting on a button affords clicking. Technically, that is incorrect usage. The highlight indicates that the button is clickable, sure enough, but we understand that due to past experience. It is a perceived affordance.

In 1991, Bill Gaver’s paper, Technology Affordances, appeared in the Proceedings of CHI. Therein, he described false affordances: perceived affordances that do not have any real function, leading the actor to believe that an action is possible when it is not. For example, if I were to style a word in this sentence blue with an underline, you would expect that clicking on it would open another web page.

For further reading on the subject, besides the links above, I recommend Joel Spolsky’s Affordances and Metaphors, which has several illustrated examples, and Dan Lockton’s post, Un-hiding an affordance, on Design with Intent.

Design Vocabulary: Combo Box

A combo box is a graphical user interface widget that combines a text field with a drop-down list. It allows the user to select an option from the list or type in their own. It is common to hear people refer to a drop-down list as a combo box, but this is technically incorrect. Unfortunately, the combo box is not one of the standard web browser form widgets, so designers have developed a number of patterns to replicate its functionality.

• It is possible to overlap a drop-down list with a text field so that it looks like a combo-box and then use JavaScript to enter selections from the menu into the field.
• A graphic can be placed to the right of a field, visually mimicking a combo box. In this case, clicking the graphic will cause a previously hidden div to be displayed under the field, resembling a drop-down list, and clicking text within the div will enter it into the field.
• Rather than mimicking a combo box, a drop-down list and field can be used in concert by including an “other” option in the list. When “other” is selected, the field is displayed or enabled.

Combo boxes are often enhanced with dynamic behaviors, such as auto-complete or the ability to learn custom entries and include them in the list.

Working with Developers: Testing

Only 36% of the designers I surveyed participate in functional testing. In fact, the only activities with less participation are bug fixing, implementation, and the writing of user guides. That’s a shame, because designers make great testers! Good designers are detail oriented, a trait that is also important to testing. Designers use the system more like the users will than like the developers use it, so we will often discover issues that the developers won’t. On top of that, we know better than anybody how the system is supposed to work—we designed it, after all. Participation in functional testing also gives us the opportunity to find and document usability issues prior to usability testing.

Your participation in more of the development process is going to result in a better product and higher job satisfaction. Participation in functional testing is a relatively easy way to extend your influence and grow your technical knowledge.

Hypocriticalmorphism

Interaction Designers and UX professionals have been ganging up on Apple for its skeuomorphic user interfaces. I mean, they’ve really been hammering hard. They make claims such as that decorating UIs with Corinthian leather is lying to the user. The UI designers baby us. They are holding back the progression of sophistication in UI literacy by chaining us to our analog past. James Higgs states on Made By Many:

Simply put: [I detest these new apps] because they are lies. They attempt to comfort us (to patronise us) by trying to show how they relate to physical objects in the real world when there is no need. How are we helped to understand what Find My Friends does by the addition of “leather” trim? And how difficult can it be for someone, even a relative digital newcomer, to understand a list of books? Difficult enough that the only possible way they could understand it is to present them in a “wooden” bookshelf format?

I heard several designers deriding skeuomorphism in their Interaction 12 talks to much applause and supercilious laughter. And yet, two of the keynote speakers, Anthony Dunne and Fabian Hemmert, were treated with great respect for showing us examples of physical objects that had been granted animalistic behaviors, such as mobile phones that breathe and disk drives that avoid coffee spills by standing up. This dichotomy struck me as being rather hypocritical. I’ve been puzzling over it, and I have a hypothesis.

Once upon a time, just prior to the release of Mac OS X, the graphics capabilities of computer operating systems were relatively poor. Sure, games included photorealistic imagery, but your typical application was limited to rather cartoonish representations. Our icons, buttons, and textures were decidedly low-res. OS X changed that. Suddenly, it was possible to include shadows, translucency, and sophisticated gradients. That freedom presented UI designers with a completely new vocabulary to explore, and as history has shown us, we will explore it for better and worse. One of the results of this exploration was a wave of applications, mostly from independent developers and startups that jumped on Apple’s newfound popularity, that were informally referred to as “delicious” applications. This name was derived from the application Delicious Library by Delicious Monster, one of the first new OS X applications to employ a visually stunning UI. They displayed photorealistic books, with the actual book covers, on wooden shelves. This was, in fact, so successful that Apple hired Mike Matas, the co-founder and graphic designer of Delicious Monster. It was not surprising, then, to see similar skeumorphic touches start appearing within Apple’s own software, even to the point of duplicating (stealing?) Delicious Library’s aesthetic in iBooks.

Of course, we designers can only applaud something so popular and successful for so long. We are driven to disdain anything that becomes commonplace in the challenge to find the next, great, original idea. We are so over the once lick-able candy coating of early Mac OS X, ready to embrace the Modernist-inspired Metro UI of Microsoft’s Windows Phone 7.

Our physical devices, however, are in a different stage of development. As artists and scientists alike explore the uncanny valley of robotics, we are fascinated with the potential of animation, automation, and even self-awareness in the everyday objects that have thus far been static—unmoving and unresponsive. We are quick to forgive the tackiness of sneezing phones in the name of experimentation.

But I would suggest that skeuomorphism isn’t as bad as many make it out to be. Compare the Notes app on the iPhone with its Metro cousin. There is no mistaking what the app is for on the iPhone. The color of the background, the rules, and the leather bar across the top all scream “notepad!” The only thing to visually distinguish the notes application from any other in Metro is the name. There is a lot to be said for visual identity, familiarity, and personality. No, faux leather trim isn’t going to help me find my friends, and I don’t need wooden shelves to understand that I am looking at a library of books, but I’ll be damned if I’m going to spend the rest of my life looking at identical, sterile user interfaces, regardless of task and context. Leather is an aesthetic choice, and certainly it will appeal to some and not to others. It’s an awfully popular choice for high-end car interiors, so why not virtual dashboards? Fashion is going to influence interaction design just as it does anything else. Apple has been one of the drivers of fashion in the computer and consumer electronics industries since the introduction of Bondi Blue. We went through brushed metal; now it’s linen and leather. Next year it will be something else.

In conclusion, I encourage you to think about the potential benefits of skeuomorphism just as you consider any other tool in your UI design bag.  Use it effectively when it makes sense to. Don’t give in to hate. That leads to the Dark Side.

Working with Developers Survey: Job Situation

As a point of comparison, I asked survey participants some questions about their work context.

What is your current work situation?

If you are employed by a company, are you:

How would you classify your company?

Are you:

I was actually surprised by the high percentage of designers working in software development firms, and the comparatively low percentage working in UX/design firms. I’m still analyzing the data, but I’m expecting this to lead to some interesting comparisons in the answers to the questions that are the meat of the survey.

The Wrong Questions

I’ve been seeing a lot of questions recently along the lines of “Should Interaction Designers know how to do visual design?” and “Should Interaction Designers know how to code?” My opinion on both questions is that they are the wrong questions.

There are very talented, successful, and influential IxDers that can do neither, so it is already proven that a good IxDer doesn’t have to. The question we should be asking is, “What skills will make me a better Interaction Designer?” The answer will vary greatly depending on the context of your work. The type of company you work for, the makeup of your team, the types of projects you work on, and even what you want to be doing in the future all have a bearing on the skill set that will make you most effective.

I have a hard time imagining being an Interaction Designer without being a visual designer, because that is my background. I have a degree in Graphic Design. CMU, where I got my masters degree in IxD, teaches it with an emphasis on visual design. I consider the majority of IxD to be visual communication, and I draw the most from my visual design skill set. But that’s me, and I’m not about to say that it is the only way, or even the best way, to do it. I have too much respect for others in the industry that are not visual designers. In fact, I make a point of impressing on my design students the importance of the multidisciplinary makeup of the design disciplines.

So, I will strongly disagree with anyone that makes broad claims like “Interaction Designers should not be developers,” or “Interaction Designers without visual design chops are inferior.” IxDers don’t have to be visual designers or developers, but both skill sets have much potential to make us better Interaction Designers.

If you really press me, I will probably argue that a designer with skills in both areas has the most potential, but realization of that potential is dependent upon the context in which one practices.