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