Microsoft tech writing noun pile blog post madness!
« previous post | next post »
Fans of noun piles will enjoy the recent blog post by Mike Pope, a technical editor at Microsoft, "Fun (or not) with noun stacks." Mike shares a few of the lovely compound noun pileups he's encountered on the job:
- data bound control table row action links
- failed password security question answer attempts limit
- reduced minimum OS partition space available requirement
Mike goes on to explain why he thinks these problematic constructions continue to crop up in technical writing, driven by imperatives of terseness and concision at the expense of comprehensibility. He also gives helpful advice for untangling technical noun piles into something more user-friendly. That's all well and good, but you have to wonder just how deeply enmeshed in nerdview a writer must be to produce a whopper like "failed password security question answer attempts limit."
Joshua T said,
August 4, 2011 @ 9:49 pm
I'm a programmer, and so rather biased, but the password attempts pile up isn't so bad if you see "password security question" as a single unit, just a specific type of question. Anyhow, I thought it was pretty comprehensible, whereas the first and third are much less clear.
kktkkr said,
August 4, 2011 @ 9:52 pm
The presence of noun stacks in programming probably comes from the conventions for variable names. Somewhere out there there must have been a "FailedPasswordSecurityQuestionAnswerAttemptsLimit" variable.
The horrors!
Deborah Lipp said,
August 4, 2011 @ 10:24 pm
Honestly, "failed password security question answer attempts limit" was the one I understood!
As a technical writer, I understand where these come from: If you can create a label for something, you can do a great deal of writing that refers back to that label.
Today I wrote about "the Create Writer screen." Indeed, it would be more accurate and more elegant to say "the screen where new accounts for writers are created," but I had to refer back to that screen twenty or more times. Three words was not a terrible nounstack and made the rest of the document flow more smoothly.
PeterJ said,
August 4, 2011 @ 10:39 pm
Not tech-related, but I thought you might enjoy this noun pile from the BBC News website:
http://www.bbc.co.uk/news/uk-england-essex-13863164
(screen shot)
Steve Kass said,
August 4, 2011 @ 11:20 pm
Not to start a programming style convention row, but while I think kktkkr is on the right track in terms of where these pileups come from, I wouldn’t consider failedPasswordSecurityQuestionAnswerAttemptsLimit very horrific as the name of a property within some list of property-value pairs that need to be maintained for configuration purposes (assuming that phrase constitutes a correct description of the variable of property). I even encourage this sort of thing in my programming classes. If pressed, I suppose I might offer something with at least one preposition, like maxAllowedConsecutiveWrongAnswersToPasswordSecurityQuestion.
Within a program (and historic decisions have usually left no alternative to naming entities with unbroken, mostly alphanumeric strings), there’s little to be gained by straying from consistent naming conventions or by reducing precision. Be glad we aren’t limited to names like NWRONG these days.
One advantage of the pileup style is to get the answer to “what sort of information is this?” (a limit, an answer) in a consistent spot: securityQuestionAnswerAttemptsLimit, usersSecurityQuestionAnswer, etc. Other styles might be helpful in other contexts, such as to facilitate this kind of self-documenting code:
if (passwordSecurityQuestionWrongAnswers_SoFar >=
passwordSecurityQuestionWrongAnswers_ConfiguredLimit) then …
Trust me, within programs, at least, if some kind of naming conventions — and these aren’t bad ones — aren’t encouraged, someone will decide to call this thing “Lim5,” or “Goofs,” with, if you’re lucky, a single comment at the point of declaration, but nowhere in the code that uses the thing, which might say (goof <= goofs) or (answer <= Lim5) and be hard to decipher or modify.
As far as the use of these phrases in technical writing, they make some sense when the writing is documentation for a program with the corresponding variable names. On the other hand, they make bad sense when they serve no such purpose and obscure the meaning.
All in all, I like what Mike Pope says in the article you linked, especially regarding the discussions that need to take place between writer and editor. I’ve been on both sides of that fence (and in and near the programmer’s den as well). The technical folks at Microsoft are really outstanding at understanding and coping with these issues, and at maintaining perspective when the ultimate goal is to deliver software and documentation.
All that said, there’s little question that finding, making some fun of, and bantering thoughtfully about extreme examples of this (or any) kind of thing is all well and good, because it gets people thinking about good stuff.
Mark Liberman said,
August 4, 2011 @ 11:44 pm
kktkkr and Steve Kass are right about modern programming practice, but the linguistic processes that lead to piled-up complex nominals have much older and deeper roots. A few years ago I noted a few of my favorites from other domains, like "main landing gear shock strut upper rod end replacement" from a 1960s-era U.S. Army helicopter maintenance manual, or "process control block base register value" from a manual for an old mini-computer that had no compiler for any language above assembler, or "Volume Feeding Management Success Formula Award" from the wall of a New Jersey steakhouse.
Randy Hudson said,
August 5, 2011 @ 12:13 am
Noun compounding isn't limited to technical writing. Jackendoff, in Foundations of Language, discusses the phenomenon:
"Thousands of [noun] compounds with partially idiosyncratic meanings are stored in long-term memory. But in addition, one constantly encounters novel examples such as health management cost containment services and two-axle diesel electric engine dump truck (examples from Boston Globe), whose meanings can be computed on the spot. Thus this is a productive concatenative system involving only words … an entirely different sort of combination than other forms of morphology."
His underlying point is that this is a "linguistic fossil" — a subsystem of grammar that just relies on concatenation and pragmatics to build up larger meaningful units.
By the by, I'm a software developer, and I don't find the compounds in the post particularly problematic — I recognize enough of the noun subsequences as meaningful units to be able to compose the intended overall meaning.
Bread & roses said,
August 5, 2011 @ 1:22 am
Isn't this why English has 300 different words for "thingy"?
Will said,
August 5, 2011 @ 2:58 am
Mark Liberman said
Berna Bleeker said,
August 5, 2011 @ 3:11 am
I am a translator, and I often have to translate those noun stacks. I hate them! I translate into Dutch, and I can't translate them literally, because I'd end up with one mile-long word. I have to 'uncompress' them, but they are often very unclear, especially the way I usually get to see them, in a long list of strings without a lot of context…
John F said,
August 5, 2011 @ 4:51 am
In literary writing, we might create analogies and metaphors and similes. In technical writing, if you are defining a new concept, just keep adding words! Anyone would think English was related to German or something…
So do language families, other than Germanic, do noun-piles, too?
Jarek Weckwerth said,
August 5, 2011 @ 6:05 am
@John F: So do language families, other than Germanic, do noun-piles, too?
I've done my share of technical translation from English into Polish, and noun piles of this sort tend to be the main pain in the ****. You end up with a much longer Byzantine noun phrase with inscrutable inflection (notably mutiply stacked genitives that I find difficult to process) and littered with prepositions and other stuff. For example, the "answer limit" thing could become at least limit liczby niepoprawnych odpowiedzi na podpowiedź do hasła. (BTW, this is a quick and dirty translation off the top of my head that loses some of the nuances of the original; but that's usually unavoidable. It doesn't help that I live my online life almost exclusively in English and I'm not sure what the usual translation of security question is. Go figure.)
As far as MS's ability to cope with these things goes, well, quite a lot gets lost/mangled/inflated in translation, too. Things have improved considerably in newer versions of Windows and Office; the terseness etc. is much more successful in English.
mgh said,
August 5, 2011 @ 6:05 am
I will think of this the next time I see one of your articles in the New York Times Sunday Book Review!
[(myl) You mean "the New York Times Sunday Book Review ArtsBeat Blog". He is, after all, "New York Times Sunday Book Review ArtsBeat Blogger Ben Zimmer".]
Bruce L said,
August 5, 2011 @ 7:02 am
Well done Will :)
Licia said,
August 5, 2011 @ 9:20 am
@Jarek Weckwerth, I used to work as an Italian terminologist at Microsoft when they still had an in-house language department, and I remember giving plenty of feedback to developers and technical writers on noun stacks, indeed a real issue in localization.
For Romance languages there is the additional problem of number, which needs to be made explicit for each noun; adjectives can also add complexity.
One of my favourite examples, dated by now, was standard toolbar color, which could be translated as
1) colour of the standard toolbar
2) standard colour for the toolbar
3) colour of the standard toolbars
4) standard colour for the toolbars
Only 4) was correct – it referred to an option that let you change the colour for all toolbars, at a time when there was a standard toolbar in most products.
William Ockham said,
August 5, 2011 @ 9:45 am
The key to noun pileups is the context of the phrase. You have to know the unspoken connectors between the nouns. The examples from Microsoft technical writing were as clear to me as the ones from the newspaper example, because I spend a good portion of my working day reading Microsoft technical manuals. In each case, the writer is assuming a shared experience with the potential reader will allow decoding of the meaning. I expect that every reader of this blog knows how to decode Ben Zimmer's title:
(((((New York) Times) (Sunday (Book Review) ))ArtsBeat) Blogger) Ben Zimmer
Likewise, I would expect that anyone who encountered the phrase:
((((failed password) (security question)) answer) attempts) limit
fairly easily. If you are writing for nerds, nerdview can be an appropriate POV.
Geoffrey K. Pullum said,
August 5, 2011 @ 12:10 pm
I hope it won't be seen as too pedantic (hey! I'm a professor!) if I point out that the examples aren't all noun stacks. Mike Pope wasn't very careful about this. Along with some ambiguous cases (bound can be either a noun or a verb) there are some clear cases of words that are never nouns. Failed is one; available is another; reduced is another. What's actually going on here is the construction of compounds in which a noun is the head (so the whole thing has the external syntax of a noun, i.e., it goes where a noun would go) and it is preceded by a stack of modifiers of the type that The Cambridge Grammar of the English Language calls a Nominal. A Nominal is like a noun phrase (NP) except that it lacks the Determiner part. Failed attempt is a Nominal. It won't work as an NP (you don't get *Failed attempt was embarrassing), but if you put that or our before it you do have an NP. The rule for the stacks Pope is talking about is that you can use a Nominal as the first part of a compound with a noun as the second part. The result functions like a noun, so you can repeat the process: limit is the head noun, and the modifier can be arbitrarily complex: [attempts] limit; [answer attempts] limit; [question answer attempts] limit; [security question answer attempts] limit; and so on. But not everything in the modifier has to be a noun, so a noun stack is not really a stack of nouns, its a stack of modifiers piled up on a noun making a constituent that acts like a noun. Just thought I'd point that out.
slobone said,
August 5, 2011 @ 12:36 pm
How about using hyphens, and the occasional non-technical word? Googling all the words in the first example, one of the hits I got was (from a Microsoft website):
Table-row action links for data-bound controls
But is this the same thing?
Rick Sprague said,
August 5, 2011 @ 12:44 pm
I suspect that it's characteristic of most stacked noun phrases that they descend a context hierarchy from the general to the specific. This is the opposite of phrases constructed with prepositions, which start with the topic and ascend through the hierarchy to wrap layers of context around it.
For instance, data bound control table row action links refers to links that select an action to be applied to the current row in a table associated with a data-bound control (which is a control [widget] that displays information from its bound [associated] data source onto a web page). Notice that the order of nouns is reversed, and that unless you understood the original phrasing you probably didn't know I was talking about a web application until the very end. Once you know that, you can go back through the prepositional phrases in reverse and get a good idea of what those links are doing—deleting, editing, validating, and saving the row data, or navigating to the previous/next row.
The left-recursive noun stack is like zooming into a Google map, or into a movie scene—your attention is guided step by step down to the topic, each noun refining the context. The right-recursive prepositional phrasing, conversely, focuses on the topic immediately, but without surrounding context it can leave you feeling lost until you've gotten to the end of the phrase, at which point you have to backtrack through the relationships between the nouns (embodied in the prepositions) before you get the whole picture. Cinematically, that's like starting at a closeup, backing up to a two-shot, then a wide shot, then an establishing shot (or a series of them) before returning to the closeup and cueing the dialog. Very awkward and unintuitive. It really surprises me that more languages haven't evolved stacked noun constructions.
Stacked nouns trade the clarity of explicit noun-noun relationships for conciseness. As long as the target audience can easily and accurately supply the implied relationships, stacked nouns optimize communication density—which is no doubt why they're so often found where space is limited (as in headlines) or where the context hierarchy is deep and densely detailed (as in programming and other technical fields).
anon said,
August 5, 2011 @ 12:53 pm
Berna Bleeker:
Whenever I ride the Boston subway, I've noticed a safety sign; the English is the fairly terse "Passenger emergency intercom unit at end of car". The (fairly mild) four-word noun pileup "Passenger emergency intercom unit" is then translated into Spanish as the rather verbose "Sistema de intercomunicación para pasajeros en caso de emergencia"; I've often wondered if the noun pileup or the prepositional-phrase pileup is worse….
(As for the original examples, the second and third are fairly clear to me, but I'm a techie so I may simply be suffering from nerdview. The first is a bit strange to read on its own; I can guess at it as it stands, but I suspect I'd be ok with it in context.)
slobone said,
August 5, 2011 @ 12:54 pm
@kktkkr, You're right, no doubt some of these stacks originated as variable names. But it's just lazy for a technical writer not to translate them from progammerese into real-people language. And the test shouldn't be how easily a native English speaker can parse a sentence, it's how comprehensible it would be to somebody with limited English trying to get an answer in the middle of the night. (I don't think Google Translate is much help with stuff like this.)
slobone said,
August 5, 2011 @ 1:04 pm
Rick Sprague said:
"Stacked nouns trade the clarity of explicit noun-noun relationships for conciseness. As long as the target audience can easily and accurately supply the implied relationships, stacked nouns optimize communication density—which is no doubt why they're so often found where space is limited (as in headlines) or where the context hierarchy is deep and densely detailed (as in programming and other technical fields)."
Trading clarity for conciseness or density is almost the exact opposite of what a technical writer should be doing. When I started out in that field, I soon learned that a lot of programmers don't understand this point. They objected vociferously whenever I replaced the elegantly concise techspeak in the specs they had written with something the average user might have a hope of understanding…
Jarek Weckwerth said,
August 5, 2011 @ 1:19 pm
@ Licia: Yes, the number problem is there in Slavic languages as well. One difference would be that the word count might be lower than in Romance languages, since quite a bit of the structure (e.g. the cases) is compressed into inflection rather than overt (de etc.), and there are no articles.
I wonder what we'd be saying if e.g. Navajo was MS's home language…
Jarek Weckwerth said,
August 5, 2011 @ 1:24 pm
@ anon: Whenever I ride the Boston subway… Sistema de intercomunicación para pasajeros… Wow. I had the exact same thought visting Boston just a couple of weeks ago.
mike said,
August 5, 2011 @ 1:39 pm
@slobone. re: "Table-row action links for data-bound controls". That's almost certainly the post-edited version of the original as listed in the blog entry.
@Dr Pullum — you'll have to train a great many editors in the niceties of your analysis. How about if we consider any pileup of pre-position qualifiers + noun as a "noun stack" (or noun pile) and call it good? (Coz what else would you call these things? "Noun-with-various-flavors-of-single-word-qualifiers-stack (pile)" — ?)
As a general note w/r/t the comment of Rick Sprague et al., I'm sad now that I did not include the analysis that colleague David included when we were discussing the "reduced minimum OS partition space available requirement" example. He diagrammed the relationships of the parts — what modifies what — in a way that did clarify the meaning, but that also showed, basically, what a mess that phrase is.
FWIW, I don't necessarily agree that member names for the associated APIs are to blame for these things. In most cases, in fact, the member names are shorter. True, usually the context is implied (e.g., via namespaces and type names), which helps. But that's often not enough, hence the need for the documentation in the first place. :-) But even if the origin of phrases like these is a Pascal-cased collection of terms, it's not really much justification for coming up with the more extreme cases of these phrases. Even if some people can understand them, as various folks here note that they can, it's a parsing burden nonetheless, and a nightmare for localizers, as also noted several times.
Glenn Bingham said,
August 5, 2011 @ 2:19 pm
@Steve Kass
When I programmed back when two moons circled the earth, I would write for
"if (passwordSecurityQuestionWrongAnswers_SoFar >=
passwordSecurityQuestionWrongAnswers_ConfiguredLimit) then …"
something like
IF x >= y, THEN…
Is this the cost of collaboration?
Jeff R. said,
August 5, 2011 @ 2:57 pm
Except "((((failed password) (security question)) answer) attempts) limit" isn't right. It's
(failed (((password (security question)) answer) attempts) limit.
Clearly.
Jens Fiederer said,
August 5, 2011 @ 4:50 pm
Those didn't even make me blink.
Yes, they look confusing to a non-programmer….but to a programmer the way the words bind is obvious.
As Joshua T points out, "password security question" is treated as a unit.
So are "data bound control", "table row", "action links", "OS partition space available requirement", and even arguably "answer attempts limit".
Note that while these are perfectly acceptable to programmers, they probably should NOT escape into the wild.
Will said,
August 5, 2011 @ 6:04 pm
mike said,
various single word qualifier flavors stack (pile) noun
[(myl) The standard linguistic term, used at least since Robert Lees, The Grammar of English Nominalizations, 1960, is "complex nominals".]
Dan M. said,
August 5, 2011 @ 7:01 pm
@Mike, gkp explained that not all the recursive steps use nouns, but that each uses a nominal. Surely, then these are just "nominal piles". (Will's good joke notwithstanding.)
Anyway, count me as another programmer who finds these transparent. Moreover, I think it would be a fairly grave error to fluff these phrases into something longer in documentation intended for programmers. (Documentation for end-users is quite a different matter.) In general, programmers are trying to pack as many concepts into their working memory as possible at one time; concision is critical. Though I suspect that these things are also more understandable to programmers because the profession selects for people with large working memories.
Daniel Barkalow said,
August 6, 2011 @ 12:48 am
The thing I think is wrong with "failed password security question answer attempts limit" is not the terseness or the jargon, but the fact that such a thing has to be referred to out of context. Surely the comprehensible design would be to be able to refer to it as the "failed answer attempts limit", and have the rest of the information be given by the fact that this is in the "security question" section under account management. But I suspect that this is in a big unorganized list of configurable values.
slobone said,
August 6, 2011 @ 12:51 am
@mike, actually no, it was from a purely technical Microsoft page:
http://msdn.microsoft.com/en-us/library/dd465348.aspx
Theo Vosse said,
August 6, 2011 @ 3:17 am
Readability for laymen is not the most pressing issue in technical documentation. It would be nice, but as long as the target audience can understand the terminology without too much effort, I consider consistency to be more important.
If you haven't done so yet, you should take a look at some of the bigger doc sets, such as the Microsoft's MSDN Library, just for fun. You cannot find anything in there by navigating (unless you know the library's structure really well). That leaves searching. And for searching, the more consistent the terminology, the better. So, if a data bound control (and FYI, a table is a kind of control in .NET) is always called a data bound control, that will make searching easier. If a table row is always known as a table row, idem.
So it would seem to me that a fair amount of stacking is unavoidable.
Xmun said,
August 6, 2011 @ 6:46 am
@Jarek Weckwerth and Anon: Nothing to do with noun stacks, but I remember being amused by the difference in rhetorical approach between English "do not lean out of the window" and Italian "è pericoloso sporgerse" (I am quoting from memory and don't know Italian) on the window sill of a train compartment.
eyesay said,
August 6, 2011 @ 12:15 pm
Deborah Lipp wrote, "Today I wrote about 'the Create Writer screen.' … Three words was not a terrible nounstack and made the rest of the document flow more smoothly." OK, but "Create Writer screen" is verb noun noun; a true noun stack would have been "writer creation screen." I imagine this could be stacked further along the lines of "writer creation screen validation section protocol" or "writer creation screen name entry field character limit" …
Paolo said,
August 6, 2011 @ 5:50 pm
[sorry, OT]
@Xmun, if you spoke Italian, I am sure you’d enjoy a well-known Italian comedian’s take on the translation of è pericoloso sporgersi into English (do not lean out of the window), French (ne pas se pencher dehors) and German (nicht hinauslehen), and how each translation is very representative of the relevant culture.
It can be watched here: http://www.youtube.com/watch?v=9c3msiKVrMI
Ken Brown said,
August 7, 2011 @ 5:01 pm
@Paolo, the Italian railways seem to have cleaned up their act! When I was on holiday in northern Italy back in the mid-1970s the English said "please do not lean out of the window" but in German it was "verboten".
Also, in Italian it was "pericoloso" in most places but "pericolissimo" around Torino!
Matt McIrvin said,
August 7, 2011 @ 10:10 pm
In the early Eighties, everyone who programmed an Atari 400/800 in Atari BASIC with the tape cassette drive lived in terror of ERROR-143, described in the manual as "Serial bus data frame checksum error".
It didn't give any further details, but it soon became clear that in practical terms this meant "all your work is gone".
Brett Kail said,
August 8, 2011 @ 11:27 pm
@Glenn Bingham
As a software engineer, I would write the conditional as:
if (numWrongAnswers >= maxWrongAnswers)
If the names are too short, the reader wastes time deciphering the meaning. If the names are too long, the reader wastes time filtering out visual noise.
Xmun said,
August 9, 2011 @ 2:53 pm
@Paolo, thank you. I didn't understand much of it, but got the gist well enough. I marvel how he manages to spin the joke out so that it goes on for 10 minutes and 3 seconds.
mike said,
August 11, 2011 @ 9:54 pm
@slobobe — yeah, that's us. I'm the editor for the ASP.NET documentation team. :-)
Elisa said,
August 14, 2011 @ 5:14 pm
@Xmun, unsurprisingly, logorroico is a commonly used (and well understood) word in Italian!