This is the third (and final) article in the Use of Language series. It is worth reading them in sequence:
1) Chrome Browser: A Novel Approach to Language
2) SQL Response: Choosing Our Words Carefully
3) SQL Response: Does Everything Need a Name?

Our overriding goal at Red Gate is to make our software more usable by "doing whatever works". That means to do whatever users are most likely to instinctively understand. As we analyse and consider every use of language in our applications, this sometimes leads me as a writer to ask the following question:

Does everything need a name?

We don't consider it heresy to design interfaces that eschew ‘properly named’ features and functions in favour of words that users can immediately understand.

For example, in SQL Response, you can cut down the list of raised alerts (note proper use of the terms!) by applying a bunch of filters. The main toolbar lets you do this quickly and easily:

The drop-down on the left lets you select a View. A view is a saved set of filters. The drop-down on the right lets you select a Timeframe. A timeframe only shows alerts that were raised within a selected time period.

Note that neither of these terms, View or Timeframe appears in the interface. Reading from left to right you can choose to "Show <the alerts I want> from the last <number of hours/days etc>". This is a natural sounding English sentence that we hope is simple and unambiguous, and lets you use the software without having to puzzle over exactly what we mean by "views" or "filters". It becomes obvious upon use.

We still use these 'proper' terms, "view" and "timeframe", in the embedded help and in our Support portal documentation, because it helps us to refer to certain aspects of the interface in various places with a degree of consistency. But like Google and their "More" and "Minor Tweaks" tabs we tried to keep the language simple. Imagine the same toolbar with the same two drop-downs but this time called "Views:" and "Timeframes:". Sure, you would figure out what they did, but it wouldn't be as immediate or obvious.

At least, that's our theory. In the end only you, the user, can tell us if we get this stuff right.

"Hey, writer, leave us names alone" – a final anecdote

While I was in the middle of writing this, Nigel, one of our more loveable, eccentric developers on the SQL Response team, came up to me and said… ( I quote him verbatim):

“
I'm not such a keen
neologist that I feel
the need to rename
things that already
have a name. Know
when to leave well
alone.
                ”

"Brian, it's your time to shine. I need some names for things."

Following an enhancement request from a user posting on the SQL Response RC forum yesterday, Nigel is adding additional columns to the System Processes section of the alert details pane. It's not a myth, we really do value feedback, and act on it where we can.

"OK, Nigel," I replied, musing on the irony of him asking this right now, and wondering quite what sort of "shine" he was expecting from me. "What things do you need naming?"

"Three columns." He showed me the three columns of values he was adding. They were three of the columns in the Processes tab of Windows Task Manager, indicating CPU Usage, Memory Usage and Virtual Memory Size. I started to ask him for a precise explanation of what data each of these columns provided. As he was explaining, I had a thought.

"Hang on, so these values are exactly those that you would see in Task Manager if you were looking at it at the moment the alert was raised"

"Exactly"

I realised that these names were already used elsewhere, and that changing them in SQL Response would ultimately prove confusing. Also, I thought ahead and anticipated a note in the embedded help for that section that could explicitly state that "these columns are those displayed in Windows Task Manager".

I'm not such a keen neologist that I feel the need to rename things that already have a name. Know when to leave well alone. I'm agnostic about the names Windows uses for these columns, because in this case consistency overrides other considerations. Again, it's about doing what we think works best.

Conclusions

We are always told to 'choose our words carefully'. In software, this is especially true. If I use a word in conversation that is ambiguous or open to misinterpretation, you can stop me and ask me to explain. In an application, you're pretty much stuck. You could just "press the button and see what happens" but that can be a dangerous strategy.

In the end it's mostly just common sense. To summarize a few of the key points:

• Give the same careful, considered attention to the names of application features and options as to the code that makes them work.
• Consider the domain and technical knowledge of your users when choosing names.
• As a rule, re-using names for the GUI that originated within the code is lazy, and bad practice.
• Use natural sounding English where possible in the GUI.
• Be consistent when referring to areas of your application.
• Don't invent names for things that don't need them.
• Don't change the names of things that are already commonly used and widely understood.
• Test how users respond to options and features during development, and don't be scared to change their name if they prove confusing or hard to understand.
• At the start of a development project, create a list of all the key terminology in your application; it helps when all team members can refer to a feature using the right name, and is likely to lead to a more consistently designed GUI.

I hope that if anything, this series of articles has demonstrated that we think long and hard about every aspect of our software, and that the names of things – even if you may not notice them –are no exception. In fact, if you don't notice them, then we're probably doing an OK job.