<Insert Title Here>
(or, Variables in Interface Language)

One of my favorite scenes in Futurama features a Lucy-Lui-lookalike robot who is programmed to fall in love with the main character, Fry. When she sees him, she purrs, “You’re one sexy man,” and then switches into a harsh monotone to shout, “PHILIP J. FRY”, before jumping in his arms and giving him a kiss. The writers can make this sort of insert-name-here joke because we’re all familiar with this type of communication, mostly from mass mailed form letters and IVR telephone systems that try and composite sentences from prerecorded bits. “If you want to talk to SUZY THOMPSON, press THREE FIVE TWO FIVE…”

Variables in otherwise-static text (like in interfaces) can be good or bad, depending on how you treat them.

When are they bad?

The joke under the Lucy Lui-bot is that the variable really sticks out from the other language around it. In mail merges, it’s the fact that your name and details look different than any of the rest of the text, because of a different font or a slightly different color. This telling difference sadly calls attention to the fact that you’re reading a form letter with variables stuck into it, which only makes it that much more apparent that it’s a mass mailing, which is the opposite of the intended effect. The designers may have wanted to make it feel more personal, but instead it feels like a poorly designed robot.

Computer interfaces sometimes run into similar problems; when the interface labels, navigation, or instructions need to include a variable. A quick example comes from Amazon. At the top of the logged in page, the site greets me by name. It also gives someone the option to log out if I’m they’re not me, and a link to a personalized recommendations page, which they’ve given my name. Kind of. See what they’ve had to do to accommodate all 19 letters:

In order to control the layout, they abbreviated the name in two places to 7 letters and an ellipsis. Sure, there’s enough of my name and plenty of context for me to realize that they’re not talking about the Bulgarian sculptor Christo, but I can assure you I don’t feel more inspired to visit that page because it has those extra seven characters.

When are they good?

The robot joke wouldn’t work without the crude shouting of “PHILIP J FRY!” Variables in interface language are best when they fit in seamlessly, i.e. when they just read as content. When done this way, they can convey a sense of your software’s being more personal and smart. Take for instance how Facebook handles “Mutual friends.” When there’s one, it says “friend” and when there’s more than one, it’s pluralized correctly.

You don’t even notice it because it’s correct. You register the information and move on. It's just smart that way.

The length problem: Real Estate

As the Amazon example illustrates, interface labels that include variables must accommodate sizes of, well, variable length. If you’re dealing with a small variation, such as number of friends in Facebook, your labels can simply slide over a few characters to accommodate longer numbers, as there are only a few orders of magnitude between the smallest and largest possible. For more variable-length “strings,” like full name, you will have to have some sort of limit, less your interface elements begin to run off screen or worse, interfere with other things. Nearly every application that I know of abbreviates interface strings and supplies an ellipsis to acknowledge the abbreviation. I found a notable exception in Adobe Illustrator, whose “Window” menu accommodates file names to the maximum width allowed by the Save dialog box. (Image edited for succinctness.)

What’s the best character limit for strings in the interface? Considering the Amazon “Christo” problem, I wondered what an average name length was. The most confident sources I could find weren’t as authoritative as I’d prefer (i.e., Babynames1000), but the data seem to support that 6 letters is the average. Is this the reason Amazon abbreviates to six? Note that if you constrain your variable names to the average length, by definition, it will be abbreviated, i.e. suboptimal, for half of your users. Better is to plan for the maximum of common lengths, as Illustrator does. In the case of names, the maximum seems to be 11 for common given- and surnames. If that’s simply untenable, aim for accommodating as much as you can, with 80% being a somewhat arbitrary but useful target.

The grammar problem: Agreement

The other problem is that variables are dangerous to play with, linguistically. Humans are pretty good language parsers. Listening, speaking, reading, or writing blog articles, we’re involved with language all the time. Unless you’re a LOLcat, when grammars is broked, you notice. In order for variables to work right, they have to fit in context, which the language geeks might recall is called “agreement.”

It seems natural to us, but agreement is pretty complex. English takes into account person (like first person vs. third person), singular vs. plural, masculine vs. feminine vs. neuter, and whether or not the variable is the subject or object of a sentence. There are also particular rules about how to handle possessives like “Chris’ hard drive” as opposed to “Michael’s hard drive.” So with all these difficulties, how do you implement language variables in a way that doesn’t force you into getting a computational linguistics degree?

Variable container

A way to “cheat” is to keep variables inside of containers and don’t worry about agreement in the rest of the presented language. For example, look at the way that Outlook labels the number of unread and unsent emails in its folders.

The parentheses and brackets act as the container for the variable, outside of the need for agreement. This technique isn’t just for numbers. You could work with word variables in this same way. For example, “Save to hard drive (Chris’ laptop).”

This technique works well for sovereign users. Cooper uses it all the time (we even have a initialism for it, RVMF), and it avoids the problems of agreement. But it’s not really the way people speak, and won’t necessarily serve transient users very well.

Simple number agreement

A more natural way of speaking places the variables “inline” with language. The first and probably most common variable expressed in interfaces is number of things. This is the simplest kind of agreement, since in English, only the singular requires a different case. All others become pluralized, keeping in mind that zero is a special case. See below for an example of how Flickr shows the differences between one and two views.

Possessive agreement

Possessives help a user distinguish between objects they’ve named themselves. In a recent project, the persona needed access to data about individual family members, requiring the construction of phrases like “Edit Carlos’ information” and “Edit Sara’s information.”

Possessives also play a part in fostering a sense of a user’s ownership and personal investment in interfaces. The example below is the default name that Mac OSX gave to my laptop, after I had provided it with my first name.

What is especially pleasing about this is that it handled “Chris” correctly. Most possessives in English require the addition of an “s” after the apostrophe. The exception to this rule is if the word ends with an “s”. Some smart designer made sure that the computer wouldn’t look stupid if it defaulted to “Chris’s MacBook Pro.”

To “cheat” your way around this problem, you can use a trick called “postnominal possessives”, in which the owner is described after the noun, using “that”, “for”, or “of.” So, rather than “Chris’ MacBook Pro”, the designers could have gotten around the problem with “The MacBook Pro belonging to Chris”. As the example shows, this sometimes forces you into awkward language choices, but it is at least grammatically correct with no need to dynamically change the rest of the text on the fly.

Gender agreement

Gender is pretty tricky from an agreement point of view, since it requires knowing if the object is treated as female, male, or like most English nouns, without gender. Inferring gender from the name is tricky business, as any "Pat" can tell you. Fortunately, the need for dynamic pronouns in interfaces is pretty rare. Mostly they will be used in determining pronouns, i.e. “her” or “his”.

If the user has specified the gender of a supplied object, then you can dynamically change the output. But asking for gender may strike your users as intrusive and rude if the reason for asking isn’t clear. If the user hasn’t explicitly provided the gender you’ll be stuck with using the ungainly “his/her”, the colloquial “their”, or trying to jump through the hoops necessary to avoid the pronoun altogether. Most applications I surveyed for this writeup tended to avoid the problem by repeating the provided name, even at the expense of being much more repetitive than a human might be. (If you're picking between "his/her" and "their", the IxDA discussion group has been mulling this over of late.)

Had Turbotax known the gender of “John”, the screen could have read “He served in the U.S. Armed Forces…” but without knowing, the name is repeated over and over.

Case agreement

Case is generally a non-issue, as the variable will be generally hard-coded in the grammar as a subject or an object. If you’re having to figure this out, then you’re getting into natural language generation, which is awesome, but beyond the scope of this article. Maybe you’re programming a robot?

<Insert Conclusion Here>

Language is a complicated thing, and the problems associated with real estate and agreement can seem a little daunting at first. But by being smart with your design, you can accommodate variables in interface language to make systems feel more personal, smarter, and more informative for your personas.

Filed under: Information design

---

---

Comments

 

Post a comment

---