click on / click

Gjones2   Thu Dec 29, 2005 9:07 pm GMT
>"If you want to open a file, click twice on the icon for it." [AmIsmart]

It's worth noting that both 'click' and 'click on' are already shortened versions of the longer descriptions that were needed when the mouse and graphical interface were first introduced (and that are still needed for beginners). Readers familiar only with a command line interface would have no idea how a mouse worked or how clicking could select an item. Keeping the first clause "If you want to open a file...." (or better, "To open a file,..." -- we probably don't need to go into the reader's feelings about opening it :-), I'll make up what I imagine is the history of how this instruction has been written over the last few decades:

"Move the mouse until the cursor is over the icon and press the [left] mouse button twice rapidly."

Even there we're assuming that the reader knows what a cursor, icon, and mouse are.

A bit shorter:

"Move the cursor to the icon and double click."

That assumes that the reader knows that the mouse can used to move the cursor, that what you click is the [left] button on the mouse, and that 'double click' means not only 'click twice' but 'click twice rapidly'. Clicking twice slowly usually won't work.

Even shorter:

"Double click on the icon."

That assumes knowledge about moving the cursor and how to press the mouse button to select.

"Double click the icon."

Almost anybody who would understand 'double click on' would probably understand the more brief version too. I suspect this is why most technical writers prefer 'double click'. Google results:

"double click" 17,900,000
"double click on" 5,080,000
"click twice on" 44,300
Gjones2   Thu Dec 29, 2005 9:18 pm GMT
Technical writing should be brief and clear. Achieving both those goals isn't easy, though. How short an account can be -- and still be understood -- depends on the intended audience (how much they already know). With a tutorial the writer has a good idea about what the reader knows at each particular stage. For instance, if the writing is intended for beginners, the moving of the cursor and the use of the mouse for selection can be explained early in the book. Then the writer can use the shortened instructions 'click' or 'double click' and expect that they'll be understood.

Sometimes it's better to be very specific, though, even at the risk of boring readers who don't need the extra information. This is especially true in reference works that try to be almost entirely self-sufficient. The goal is to make it easy for the reader to look up something in the index, go to the page, and see everything that's needed to do the task. If all the information isn't there, at least specific instructions about where to find it should be. Better to cause many readers to read an extra five or ten seconds than for a few to be puzzled and unable to continue with the task.

The 'click' example is a trivial one, but we're all beginners in some areas. From time to time I write programs in languages that I don't know very well (I use them so seldom that it's hard to keep my knowledge fresh). I don't want to go back and read an entire tutorial when I just need a little information. When that situation arises, how frustrating it is to read about a procedure and understand everything except a single step. That's sometimes the cost of brevity.