Match User Interface Terminology With Tasks, Not User Ability

It’s not often that I’m stopped in my tracks by a user interface element in macOS, which is the reason for this article. I was using the Activity Monitor application to show which processes were consuming the most memory when I spotted HPShortcutManager, the process highlighted in the following screenshot.

I didn’t recognize this process so I requested more information from the process inspector dialog.

After I’d finished with this dialog, I automatically went to click the Quit button but I paused. Then I stopped. What exactly am I quitting? The dialog or the process? Well, in this case, the Quit button quits the process.

In macOS terminology, users quit applications and cancel dialogs. But in the middle of a task flow the semantic difference between quitting and cancelling can diminish. Quitting an application instead of cancelling a dialog is usually just inconvenient rather than destructive. However, quitting a process can be very destructive. One improvement would be to rename the Quit button as Quit Process.

Out of curiosity, I clicked the Quit button and the following confirmation dialog was displayed.

This dialog confirms that the Quit button on the previous dialog does actually initiate quitting the process. It is clear that the Force Quit button quits the process because it’s label includes the word Force, which is macOS terminology for terminating processes. However, the arrangement of the Cancel and Quit buttons presents a fresh dilemma: if the Cancel button cancels the dialog, what does the Quit button do? Does it quit Activity Monitor or quit the process?

In good user interface design, related controls are placed near one other. Therefore, the Quit button seems more likely to quit Activity Monitor because it is next to the Cancel button, and cancelling a dialog is an application-related task. So, what did I do? I ended up closing the quit-confirmation and process-inspector dialogs by clicking the red close button in the top left of each dialog. This was the safe, no-risk option.

A good rule of thumb is that initiating a destructive operation should be more difficult than backing out of that operation. In the case of terminating a process with Activity Monitor, it is easy to start the destructive termination operation, but it is hard to back out with confidence using the buttons with their current labels and positions.

In general, hiding the complexity of the underlying UNIX system is good for users, as is describing operations with easier to understand, non-jargon terminology. However, my initial confusion between the meaning of the Cancel and Quit buttons came about because macOS uses the friendlier, non-threatening term quit instead of the UNIX term kill to refer to process termination. Activity Monitor’s list of processes is a grey area when it comes to the technical ability of users. Process lists are at a much lower level than the Finder or applications like Mail and iTunes, but they are not down at the command-line level of Terminal, which is a level most users never visit. In short, Activity Monitor provides a familiar and friendly user interface with which to perform potentially harmful operations.

To guard against unintended and harmful process terminations, using the unfriendly term kill is appropriate: users who don’t understand the consequences of terminating processes would be put off or at least think twice; users who do understand the consequences will be familiar with killing processes.

Apple has worked hard to make the language used in the Mac user interface friendly and easy to understand for non-technical users. macOS hides its internal complexity well. But when users do get a peek inside—when viewing Activity Monitor’s process list, for example—macOS should change its language to suit the occasion.