<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

PHILIPJFRY.png

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:

Christos.png

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.

Mutual-friends.png

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

Illustrator-windows.png

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.

i-can-has-cheezburger.jpg

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.

Deleted-Items.png

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.

i-can-has-cheezburgers.png

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.

views.png

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.

Possesives.png

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

John_John_John.png

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?

Fry_And_Lucy_Liu2.png

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

8 Comments

Simon Harris
I've always liked the Simpsons Camp Krusty episode where Krusty the clown appears before the children on a pre-recorded video-cassette: "Hi, I'm Krusty the clown and I fully endorse this prodyct and/or event."
Richard Ishida
Nice article Chris, except that... It's very Anglo-centric. Many of these things can be more complicated when dealing with a multilingual audience (such as you do if you work for Flickr, Facebook, etc.). For example, all the grammar issues you mention can involve very different approaches in other languages (eg. possessives in German require case endings on articles such as 'the' and 'a' and adjectives, as well as the name of the person, and French reorders words to do possessives; Russian has a set of revolving endings for plurality (with irregularity in the teens); etc.). Name lengths, too, can be significantly longer in many parts of the world. If you're designing a product that might be used in a non-English context, you need to take that into account, or at least have an idea how to address it. For more information and some (similar) ideas, see http://www.w3.org/International/articles/composite-messages/ (and it's sister article about text re-use), and for info about names see http://rishida.net/blog/?p=100. Hope that helps (even though it makes everything more complicated ;-).
Mark
Great article! I'm currently reading your book, About Face 3, and it's very good. Thanks
shb
I just found Lucy Liu Bot's Facebook profile, you can check it too if you want... http://www.facebook.com/pages/Lucy-Liu-Bot/148380708209 It's really nice that it's beeing promoted on Facebook too, I hope that this way the link will spread. Regards, John - CEO at Pariuri Sportive
Chris
@Richard: Excellent points. Despite my Italian teachers' best efforts, I'm monolingual, so forgive my mother-tongue-centrism. Those are some excellent (and as you note, complicated) links, everyone. @John: It makes me happy that Lucy Liu Bot has her own page.
me
a typical way to handle the number agreement problem is the way the gettext library for internationalization handles it: the programmer writes print ngettext("This image has %d view", "This image has %d views", number_of_views) gettext then decides based on number_of_views which version to take. this is rather trivial for english, but when additional data for other languages is available, the other language's properties are taken into account. for example, the french version would show the singular form even for zero view (where in english, it'd be "has 0 views"). for languages with more plural forms, like romanian (everything above 19 gets the third plural), translators are just shown a third option and it is chosen accordingly.
Translation is UX @ zuminteractive.com
[...] they use has translation memory, so there’s no need to avoid repetition. They will discuss how to handle variables in text. They will also decide together which internationalization system (such as gettext) and [...]
Translation is UX - Ye Joo Park
[...] they use has translation memory, so there’s no need to avoid repetition. They will discusshow to handle variables in text. They will also decide together which internationalization system (such as gettext) and [...]

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment