Hyperion Entertainment Message Boards

I've for some time been working on an article on common GUI design problems, and I've run into something that I'd like to share with other devs.

The User Interface Style Guide (now maintained and updated in the AmigaOS Documentation Wiki) says, in its Gadgets and Menus chapters, the following about using ellipsis in labels:

"When a menu item brings up a window or requester, an ellipsis (three dots) should be appended to the menu item's label."
"When an action gadget brings up another window or requester, the label should end in an ellipsis (three periods)."

We all know that, don't we? Or do we?

The convention/rule to use ellipsis for actions that will be followed by another step (asking for a choice etc.) was established by Apple in the 1980s. The problem is the rule seems to have been misunderstood and overgeneralized by the Amiga UI Style Guide authors. They thought (and wrote) that the “...” is for any command that opens a new window - which is not really what Apple meant and standardized! In fact, the ellipsis should only be used for commands (gadgets and menu items) bringing up a window or requester that prompts for user input. In other words, you should only use the ellipsis when additional information or confirmation is required to perform the particular action. Commands that merely open an information window/requester (such as "About" in application menus, or the "Info" button in AmiUpdate) are not supposed to be labelled with an ellipsis.

Proper use of ellipses is important to indicate that users can make further choices before performing the action, or even cancel the action entirely. The visual cue offered by an ellipsis allows users to explore your software without fear. If you happen to be using Firefox when reading this, please refer to its Help menu for an example of correct ellipsis usage. You'll see that "Firefox Help" and "About Firefox" have no ellipsis: it is because what they open doesn't require user input. On the other hand, "Submit Feedback..." and "Report Web Forgery..." will ask the user to submit some information - so the ellipsis is in place.

This is a cross-platform standard codified in, among others:

Apple Human Interface Guidelines [Apple Computer, 2006]
Java Look and Feel Guidelines [Sun Microsystems, 2001]
Windows Vista User Experience Guidelines [Microsoft Corp., 2006]

As I don't think AmigaOS is supposed to be playing its own game here, I will be updating the UI Style Guide to be more specific and to reflect the cross-platform convention as far as the use of the ellipsis is concerned. I'm also kindly asking developers to check their software for compliance. I'll surely need to check mine

As far as I understood, this style guideline was just missing the "...asking for user input" part. But, IMHO, its quite irrelevant if anybody, be it the fruit company or anybody else, defines the ellipsis extension of a menu point as something that opens a window specifically asking for user input. Amiga wether is the fruit company, nor it is somehow related to Java rocket scientists.

IMHO it was quite right to NOT define it specifically as "...asking for user input". The ellipsis should just show that another intermediate action WILL take place, if the user decides to choose this menu point. This is in difference to a menu point not extended by ellipsis, which will clearly show that the chosen action will take place immediately, without ANY intermediate action.

Sometimes there are intermediate actions that dont need any user input, but will take some time. For these cases, some progress report is desireable, and the menu point text should reflect the fact, that there will be some intermediate action, not immediately performing the task reflected by the menu point naming.

You should extend the style guide with "good practices". If the chosen action takes place immediately, but will show just a progress report window for the action itself, the developer should NOT use ellipsis.

Simple as that.

@whose

The ellipsis should just show that another intermediate action WILL take place, if the user decides to choose this menu point. This is in difference to a menu point not extended by ellipsis, which will clearly show that the chosen action will take place immediately, without ANY intermediate action.

You are right - and that is exactly the case with about- and info-type requesters/windows: displaying information is not an intermediate action, it is THE action itself. If you choose the "About" menu item, the action will take place immediately (ie. the requester opens) - so no ellipsis for the label.

Sometimes there are intermediate actions that dont need any user input, but will take some time. For these cases, some progress report is desireable, and the menu point text should reflect the fact, that there will be some intermediate action, not immediately performing the task reflected by the menu point naming.

I absolutely agree that displaying a progress indicator is good practice but I think that extending the ellipsis convention to actions that merely indicate their progress is a bit to much. A progress indicator/gauge is neither an intermediate action (the action is already under way), nor a prompt for input or confirmation.

You should extend the style guide with "good practices".

The Amiga UI Style Guide philosophy is based on the "good practice" principle, so, yes, let's continue in this tradition.

With "intermediate action" I meant actions, that i.e. call other programs first and THEN perform the action mentioned in the menu point name. In these cases ellipsis would be the right choice IMHO. It indicates that there will happen another thing first. Sometimes user input might be necessary, sometimes not.

Take AmiPDF for example. If the print function would use saved user preferences, the GhostScript config requester wouldnt be necessary, but nonetheless GS is called, before the actual print work starts (including a progress report window). Ellipsis.

@whose

Why not - if the particular context of the operation calls for giving the user a visual cue, just use the ellipsis. What I'm really after is stopping the (apparently Amiga-only) practice of littering labels with ellipses where they are not required.

I don't know if you really have different views on this matter. But, my initial interpretation of an ellipsis is that you can click without anythng happening directly and being able to cancel the action.

For example:
"Print..." will allow me to first press an ok button in order to really print, whereas "Print" would start printing directly -- perhaps with a progress bar and a cancel button, however pressing cancel might have printed a few pages.
"Quit..." requires confirmation, "Quit" will just quit immediately.

"Save as..." kind of starts immediately, since the first, and basically only thing you have to do is enter another name for your file. The ellipsis here tells me this dialog has a cancel button. If it had no cancel button, I wouldn't expect an ellipsis.

Thats my take, irregarding any fruits or other companies, only a matter of software being user friendly.

I agree. I've gone ahead and fixed NetSurf (on AmigaOS anyway - some of the other platforms look like they might have the same problem, but I decided to leave those as I don't know for sure what the "correct" way is).

The auto-builder appears to be broken, but when it is back up please let me know if I've missed anything (or removed some ellipses that were valid!)

I've also corrected the order of Print and Close as per the Style Guide.

chris wrote:I agree. I've gone ahead and fixed NetSurf (on AmigaOS anyway - some of the other platforms look like they might have the same problem, but I decided to leave those as I don't know for sure what the "correct" way is).

I've now been picked up on this on the NetSurf ML

The first answer here is interesting: http://stackoverflow.com/questions/6376 ... menu-items

Apparently if the item is only going to ask for confirmation the ellipsis shouldn't be used. So "Delete" in WB's Icons menu should not have an ellipsis (and neither should About, Quit or Information, but WB's menus are not terribly style guide compliant anyway)

chris wrote:Apparently if the item is only going to ask for confirmation the ellipsis shouldn't be used. So "Delete" in WB's Icons menu should not have an ellipsis (and neither should About, Quit or Information, but WB's menus are not terribly style guide compliant anyway)

That may be the case on some other platforms, but then they are not necessarily good at that userfriendlyness lark anyway (e.g. the whole modal/non-modal business - who can trust the logic behind a GUI that encourages the habit of blocking access - even if just for moving or rearranging - to any window except the only one it decides the user needs access to).

I strongly suggest we stick to the rule that if there is a way to safely avoid the action after having clicked a button or used a menu item, then that should be signified by the friendly ellipsis. Even if that safe exit is the only purpose of the following window or requester.

Best regards,

Niels

@chris

I know the Stack Overflow post you've linked to, it's one of the many materials I studied when writing my common GUI design problems article (still to be finished, though).

My opinion is that actions that merely require confirmation should not need an ellipsis. Three reasons:

1. The confirmation of actions is sometimes configurable in programs. In such a case you'd need to alter the menu/button label (add or remove the ellipsis) each time its function becomes or ceases to be confirmable as per the changed settings. This is unnecessary programming hassle, and can even be confusing because the labels keep changing.
2. It's a universal software design rule that a program will never scrap your work or data willy-nilly, without your own consent. The user should know that, so there's IMHO no particular need to indicate that he/she will be able to back out of an action: it's quite an obvious thing.
3. Adding ellipses to actions that require confirmation would actually be an extension of the current Style Guide rule, whereas we should strive for the opposite, ie. stopping the overuse of the ellipsis. That's my entire point in this thread.