Des Traynor recently published his thoughts around a talk he gave, “The Language of Interfaces.” As he writes:

In “Getting Real” Jason Fried wrote that Copywriting is Interface Design, yet five years later copywriting is almost always where interfaces fall to pieces.

(By the way, was “Getting Real” published 5 years ago already? Wow.)

As Fried said:

Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you’re writing your interface, always put yourself in the shoes of the person who’s reading your interface. What do they need to know? How you can explain it succinctly and clearly?

Do you label a button Submit or Save or Update or New or Create? That’s copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

If you’re reading this blog, you’ve probably read the above. But do you practice it?

Writing is Fundamental.

In my experience, clear and consistent language (which extends beyond the user interface—into how people describe your application, how the email notifications read, etc.) is often the difference between a good application and a world-class one. And it’s often the difference between a confused user and a comfortable one.

Creating and maintaining that in your application takes time. It’s easy to let this slip: a new feature built in a hurry is referred to inconsistently, proper nouns slip through uncapitalized, overly formal/casual language breaks the established tone. And most easily overlooked of all: email notifications are written in haste, and not by the appropriate member of the team.

And is there payoff for this thoughtfulness? If it comes, it’s certainly delayed. In 2011, application development and delay are not friends.

I choose to remind myself, and my team, that these are the very qualities that make an app stand apart. With our product, Kindling, we’re as interested in renewing accounts as we are in landing new ones, and I can draw a direct line between good, clear and consistent interface language and usability—and continue that line from usability onto usage and straight through to renewals. Or said reductively: good interface copywriting is good business.

A Dribbble for Words?

Des then introduces the concept of a “Dribbble for Words:”

I would love to see a Dribbble for writing. A place where I can post the latest Intercom broadcast, email, even a sentence from the interface and get feedback. “You can strip the word currently there.”, “The important word here is buried in the middle of the sentence!“. “The message makes sense, but what I am supposed to do next?”.

In this hypothetical Dribbble for Words, I suppose product designers would post snippets of interface, buttons, modals, copy and other “language of interface” examples for criticism from the content and interface communities.

Cool idea on paper, but I’m not sure it would work.

In my experience, there’s no universal truth with these things. Interface words live exclusively inside their parent context: the app. Devoid of this context, words become merely an ordered list of letters.

Context is everything... ask King George.

Again, Fried is instructive here:

You need to speak the same language as your audience too. Just because you’re writing a web app doesn’t mean you can get away with technical jargon. Think about your customers and think about what those buttons and words mean to them. Don’t use acronyms or words that most people don’t understand. Don’t use internal lingo. Don’t sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more.

Either way, I’m glad Des posted this. We as an industry spend an awful lot of time discussing visual/interaction/user experience design, and not enough time discussing the language of interfaces. Words matter.

—

…and speaking of secret weapons, hat tip to Joe on the great drawing accompanying this post.

I’ve been using my iPad a lot of late. I find myself in Safari probably 70% of the time. As my habits have settled in, I’m suffering from a mildly acute level of frustration with a lot of little things. Mind you, I’m ecstatic that I can lounge around and surf the Web on it, but various aspects of the browsing experience just don’t feel right.

“He’s got too much baggage.”

When we design within a new arena that represents a dramatic shift in interaction, we can’t help but carry forward our own biases and prejudices about how things can or should work. For the past twenty years, we’ve been staring at…windows. Windows that open, close, expand and minimize. It’s probably the single most dominant metaphor in OS interface design today.

When you open Safari on the ipad, its lineage is fairly obvious:

Safari inherits a classic window trait: controls and a healthy slab of chrome along the top. For Safari’s ancestry, this made a lot of sense. We “grab” windows with a mouse pointer to drag them around. Also, from a visual perspective, we tend to title and provide “top level” controls along the top-most pane.

On the iPad, you can’t do any of those things. No resizing or minimizing. Even closing a window amounts to closing the entire application.

Another challenge the iPad has to overcome is mimicking input devices like a keyboard right on the screen. When we focus in on a search or URL box, the iPad pulls up a keyboard along the bottom portion of the screen. Unlike a physical keyboard (which requires zero visual focus for me) the iPad keyboard is a bit more challenging. I find myself splitting my focus between typing on the keyboard and checking what I’m typing up top. It isn’t helpful to have your text so far away from the virtual keyboard:

Is there better way? Interestingly, once we shed the characteristics of typical OS interfaces, we find new opportunities. To reboot the design of the iPad’s browser interface, we should focus first on how we physically handle the device. I want an experience that takes advantage of where my hands are 90% of the time and provides feedback to what I’m doing that is within my line of sight. While having controls at the top of the browser “window” (it’s hardly a window anymore on the iPad) feels familiar, the main reason it doesn’t work so well is that the key controls are far away. Bookmarks, tabs and the URL bar are nowhere near what I would call the “hot zones”: where our hands grip an iPad:

I most often grip my iPad on the sides – whether portrait or landscape. When I’m ready to change pages or type a new URL, I anchor it on one of my hands for a better grip (usually my left, since I’m right-handed) and press a button with my right. It’s not awful but it’s also not ideal.

Bring on the Edge Swipe^TM

One possible approach is to do the following:

• Get rid of the chrome up top altogether (the actual Web page reclaims that real estate – a good thing).
• Recognize an edge swipe: it’s essentially a swipe off the edge of the iPad window (either left or right) and reveal controls in a gutter off the Web page.
• Put the bookmarks pane near my thumbs so I can scroll and make selections with either hand.
• Adhere the URL and search windows atop the screen keyboard.

Here’s a concept video that illustrates how such an experience would work on an iPad (users on the iPad can view the video here):

There are some issues with this approach. One of the biggest is discoverability. Unless there’s some sort of illustrative first visit walk-thru, people won’t know to swipe off the edge to get at the controls. Another potential problem is that additional steps are being added to some of these tasks. For example, visiting a new URL is a swipe + pull up bookmark pane + select bookmark. One extra step is added here, though you could make an argument that the swipe is so trivial (and arguably natural) that the net benefit outweighs the extra step.

Generally speaking, this case should serve more as an illustration of how we instinctively revert to familiar patterns and traits, even when the outcome is less than ideal. We rarely see examples of bold new approaches to interaction. It’s a tricky line to walk. Most often we seek user feedback to show the way. Devices like the iPad challenge the typical user-driven approaches by presenting new rules of interaction. And with new rules come new opportunities to break new ground.

Fred Brooks, author of the classic Mythical Man-Month, has a new book of his essays titled The Design of Design, where he explores the design (lowercase ‘d’) process. Brooks’ discussion is at times academic – in a good way. If you’re looking to read about Web standards or typography, look elsewhere – this is a deep dive into the processes of design.

It’s a worthy read, and contains the best definition of style that I’ve come across. It’s lengthy, but worth quoting entirely:

What is Style?

Precisely what is this characteristic way of working that confers designer recognizability on the products? This question is harder than it appears.

Definitions. The Oxford English Dictionary defines style, in the sense we are considering, as

14. Those features of literary composition that belong to form or expression rather than to the substance of the thought of matter expressed.

21. A particular mode or form of skilled construction, execution or production; the manner in which a work of art is executed, regarded as characteristic of the individual artist or of his time and place.

Webster’s Revised Unabridged Dictionary (1913 Edition):

4. Mode of presentation, especially in music or any of the fine arts; a characteristic or peculiar mode of developing an idea or accomplishing a result.

Akin [1988], “Expertise of the architect”:

Style as an expression of the designer’s personal and professional choices is a vehicle which helps limit the many degrees of freedom that design problems have.

A Characteristic of Detailing. We observe that different works by the same artist are different in the subject painted, or the genre and themes of music composed, but alike in recognizable style. Similarly, the Oak Park church by Frank Lloyd Wright has certain resemblances of parts and arrangement to other architects’ churches, but it has a close affinity of line, of detailing, of ornamentation, of palette, wth Wright’s residences. Whatever style is, it has more to do with details of design than with the main purpose or thrust.

A Hypothesis: Minimization of Mental Effort. All design, all creation, involves hundreds of microdecisions. Habits seem to be a mechanism by which economize on mental effort, by which we reduce the burden of decision making in everyday life. If this is indeed an inborn human, trait, it surely carries over into our creative activities. Absent substantial reasons to do otherwise, we make the same microdeicsion the same way every time. The bundle of microdecisions, consistently made, characterizes our work and gives it the particularity, the distinctiveness, that yields recognizability.

Consistency across Microdecisions. One would expect microdecisions to be consistent not only across time but also across sets of similar decisions. In related microdecisions, the same factors enter, and the same mind would naturally weight them in a consistent way.

A Frank Lloyd Wright will tend to use rectilinear elements instead of curved ones in all his decorations, and in his structures, too. A Seymour Cray will consistently opt for maximum performance over compatibility with his earlier computers.

Clarity of Style. To the degree that a designer does indeed achieve consistency across a wide range of macro- and micro-decisions, we say that he has a clear style, meaning that it is possible to describe it economically. It follows that recognitition is easier.

Even a baroque architecture can show clarity of style. Wright’s architecture was spare as well as clear, but those aren’t the same property.

When little consistency across design decisions is achieved, we call the style opaque or muddled. Somehow, consistency brings clarity, and clarity brings delight.

My working definition:
Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different.

Moreover, related microdecisions are resolved in related ways.

Style unquestionably exists. A few bars tell us that a work is Bach’s, or Mozart’s, or Schubert’s. A famous exhibition brought together many Rembrandts, and many works once attributed to Rembrandt but now recognized as imitations. The experts agreed as to what was genuine; even laymen could tell surprisingly often.

Reasonably knowledgeable people can readily tell a Seymour Cray computer from a Gerry Blaauw or Gordon Bell one. The authors of the Federalist Papers have been conclusively identified by details of their prose styles. Programmers can identify each other’s code. C. S. Lewis argues that Jesus’s miracles faithfully display the hallmarks of Father’s creative style.

I’ve been reminded a lot lately — especially with the releases of The Better Project and the good showing that Kindling made at the Web 2.0 Expo last week — that the best compliment you can get on a UI is that the product makes a difference in someone’s work, or let’s someone do something they couldn’t or didn’t want to do before, or makes twenty minutes a day a little more fun.

It’s not “Wow, that looks great”. It’s not “What a slick interface”. It’s not even “Users probably love this” (which is a different way of saying, mostly, “That’s a pretty UI”). I’d much rather hear “What a great idea for an app” or “I could see myself using this every day” or “How am I working without this?”. That means the UI is doing its job: getting out of the way of content and utility.

If you’re designing to make something look good, you’re probably going down the wrong path. Focus on providing something that’s going to make someone’s life a little better after they use it. That’s a compliment you want.

The funny thing about interface design is that everyone thinks they can do it, or try to do it, but few people actually do it well (or at all). But it’s easier to say "Move the button to the upper right and make it green" than "The button feels awkward to me" or even "The page doesn’t look right to me with the button in that position".

Everyone’s guilty of it; I know I do the same thing to other designers. It’s a hard habit to break. Many times, though, the designer knows what you really want more than you do. Pose a problem and let him or her fix it, instead of dictating a solution.