I could repeat what's written there, or I could just tell you to read it.

I'm going to tell you to read it.

Okay, maybe I'm going to repeat what's written there, but briefly:

Use an ellipsis if the command requires additional information before it can be performed. Sometimes the dialog box is the command itself, such as "About" or "Properties". Even though they display a dialog, the dialog is the result, as opposed to commands like "Print" where the dialog is collecting additional information prior to the result.

Interesting – The first two applications I looked at, RSS Bandit and Microsoft Visual Studio .NET 2003, both had ellipses after the About item.

The situation where the command requires more information to complete but the application has a modeless mechanism for requesting the information is also interesting – for example in Outlook 2003, the "Find" menu item doesn’t have an ellipses, and when you select it, even though the command requires more information to execute, no dialog appears – the Find toolbar bar just shows up.

This can be pretty confusing since it means you have to watch the rest of the UI to see what changes when you pick the menu item.

By that logic, IE’s Internet Options option is wrong (it displays an ellipsis), as is Microsoft Management Console’s Help > About menu items.

You could offer the same argument against IE’s Organize Favorites, View > Privacy Report. View > Toolbars > Customize is an interesting one. The act of customization doesn’t occur until you hit OK, but you could argue that the menu command simply offers you the option of customization, therefore the dialog is the command.

I don’t think it’s that subtle: the rule is clear once it’s been explained. It’s quite surprising that Microsoft doesn’t ensure that the guidelines are followed in all its products: surely it wouldn’t be difficult? And this would make it more likely that 3rd parties follow the guidelines.

Another common error seen in Microsoft products is underlining the O of OK and C of Cancel.

UI standards seem to have gone out of the window since the advent of the net. One thing I find irritating is when web pages (such as the following:

I was a little surprised by this when I first found out about it (as was everybody else I mentioned it to). Seeing as this isn’t what most people expect the ellipsis to mean, I wonder if it would be better to change the guideline rather than rigidly sticking to something most users don’t expect.

Having an access key for OK is useful in one case, namely, when you have a multiline edit or another WANT_RETURNS control which is a substantial part of the dialog box functionality. In this case, you cannot (most of the time) use Enter to close the dialog, so another key is needed.

However, not all agree which. Borland’s Turbo Vision used to use K, and good old Norton Commander had a wonderful convention that Ctrl+Enter activates the default button no matter which control is focused and Enter activates the default button unless the focused control handles Enter (i.e. is a multiline edit or a command button).

Applications in which a dialog with a multiline edit control is the main part (e.g. instant messengers) sometimes let the user customize the behavior of Enter. For example, Enter might send the message, and Ctrl+Enter might begin a new line. Or, depending on the user’s preferences, it could be the other way round.

There is also an awful practice of putting menu commands on the main menu bar (as opposed to a pulldown menu). It is bad because, as a rule, the user expects a menu to pull down, but instead a command is executed. This case should be avoided, but if really necessary, there should be an indication that this is a command rather than a menu. I’ve seen two ways of such indication. One is to write the caption in ALL CAPS, as in “STOP”, and the other is to put a ! at the end, as in “Stop!”.

If there’s this much confusion about when to use the …, then users probably don’t know what they mean either. How about updating the standard to be something that is more obvous and can be used in places other than menus?

That way the feature will be helpful rather than just a silly tradition.

Maybe someone would tell the VB people about the Windows User Experience. The prev UI guidelines talked in px. We npow have DLU or something that one has to write a program to find out how many pixels in a DLU (it appears to be 2 on standard video cards).

VB has always had different sizes to the standard to the guidelines incl in 3.1. That’s why so many vb apps look like a retarded child designed it.

Just maybe they could use DLU rather than px (or twips as the actually do use but one can change this to px for child objects) and make the default sizes the correct sizes rather than the wrong ones.

I must admit that I knew the correct definition for …s (can’t spell that e word) but had sumarised it in my mind to If dialog then show …s without realising till now that they are not equivilent.

It’s like something in the "should this function be a property or method".

Personally I think that those should give the user a warning that a browser will be open. I say this specially because sometimes opening the browser (even without taking into account the page loading time) takes time. I now that this doesn’t fall into the … category, but is related (at least remotely). At least fall into the category of operations that take a long time and should warn the user before starting.

It’s a magor mathamatical effort to lay out a form at run time. This would be more code then the working part of the program. Who on these blogs is a VB person (I clicked a few at random – but the encarta guy is really boring). What is happening with device independent dialogs (a DID).

It like designing a road network where 1/2 the roads are measured in average travel time and 1/2 in Kilometers.

The rule isn’t clear, since at least one of the examples seems to contradict it. Apparently a "Browse" button should have an ellipsis. That doesn’t make sense because the button lets me start browsing immediately. I think the problem is that whoever picked that name confused process with purpose – the purpose of the "Browse" button is not to browse but to *choose* a file or folder. So the command should probably be something like "Choose", for which an ellipsis would be in order. (Even that is problematic, since only "OK" will finalise the choice.)

Ellipses mean that a dialog’s going to pop up, and the user’s going to have to provide some kind of input to make it go away.

This is as true of an "About" dialog as it is of the file-open dialog. Splitting hairs about the dialog being "result" or "process" is silly; see the "Browse" vs. "Choose" post above.

What does the user actually *care* about? The user wants to do something; the user doesn’t care whether the dialog "is the result" or "is prior to the result". Does essense precede existence? How many angels can dance on the low-order bit of a dangling pointer? Who gives a damn?

The UI rule for this is goofy (not just for the above reasons, but also because they lump "show toolbar" and "print preview" together under "the intended action is complete when the view changes", which is bizarre: Print preview is something you get rid of before doing anything else.) and I’m not at all bothered that people generally seem to ignore it and obey the vernacular variation of the rule ("’…’ means there’s a dialog") instead.

The reason darn near everybody gets it "wrong" is that the "wrong" way makes more sense to more people. When people vote with their feet on UI issues, it behooves us to listen. So to speak.

Internet Options is modal. It doesn’t let you proceed unless you have finished inputting information (or decide not to change it).

Property boxes are modeless. They are like folder windows. You are opening a new view to the document, which happens to be the object you’re getting properties of. It’s like going to View/Source to see the source of a web page. Or even right clicking and hitting Open on a file. It’s just a different view on a data, not a modifier that you have to complete to proceed. Though that’s still a kludge, since property boxes don’t have their own button on the taskbar.

If Internet Options opened a modeless window (such as it does from the control panel), then that would be a different story. But I can see the confusion on this one since Internet Options has a global scope.

So I suppose to maintain consistency, the real solution would be to give property boxes their own button on the taskbar and do the same for Internet Options, make it modeless, and take out the ellipses.

The issue is: what does the ellipsis tell the user? In my opinion, it says: Clicking this is harmless, because it will display a dialog with further options before doing anything, so it can be explored freely.

So, it makes sense to have About… because it tells the user that this isn’t a ‘Command’ but an ‘Explore’ option.

I agree with Frederik. Mostly. The key sentence from the Apple documentation that Simon posted is "The ellipsis character lets users know that they will have an opportunity to provide more information before the command executes."

I don’t necessarily agree about About needing an ellipsis. That is because About is a well-known, unambiguous menu item. It’s rather save to assume that people know what it does and that nothing dangerous will happen.

It’s different with commands which the user may not instantly know the outcome from, i.e. commands which are more specific to the application’s domain. When exploring the menus one can savely click on a command with an ellipsis since one can expect nothing dangerous to happen but instead maybe more info on what this command does can be gathered. But with normal commands I am more careful since I might invoke actions I did not want and which I not necessarily know how to revert.

So I’d say forget what the guidelines once said or meant, rewrite them to fit the user model, to describe what the ellipsis means to the normal user.

Observe also that Apple explicitly emphasizes that the ellipsis SHOULD be a real ellipsis (U+2026) rather than three periods (U+002E).

I once tried doing that in a non-Unicode (Delphi) program on Windows. The result was OK on my machine but the ellipsis became something else at the customer’s site. I still cannot understand why it is that way.

‘Properties’ to me implies that I might want to simply *look* at them and not necessarily *change* anything. For example, I might want to bring up file properties to see the file size or modified date.

‘Options’ on the other hand strongly implies that its primary purpose is to let me configure things. If I go to Tools | Internet Options it’s almost always because I want to change something, so the use of ellipsis is justified in my opinion.

I was wondering where I saw the "other" rule for using ellipsis at the end of a menu item.

It’s from the Mac. I *knew* I’d read it somewhere. (I spent a lot of time looking at the Inside Mac and Lisa books a while back when I was looking at implementing a GUI for my old home computer – the SAM Coupe’).

The ellipsis character (…) after a menu item means that the command needs more information from the user before the operation executes. To generate this character in your application’s menus, type Option-; rather than three unspaced periods; the spacing is slightly different. The ellipsis character is often misused to indicate a wide variety of behaviors. The only time they should be used is to let the user know that a command will need more information to execute, as opposed to a command that executes immediately with no further information.

This section contains several examples that demonstrate the correct and incorrect ways to use the ellipsis character in menus. The Find command in the Finder’s File menu is an example of the correct presence of the ellipsis character. The command needs more information from the user about what to look for. The ellipsis character lets users know that they will have an opportunity to provide more information before the command executes."

IIRC, earlier forms of the documentation for the "…" indicated that it was to be used when moving into a new modal state (older docs were much bigger on modality and why it was a bad thing – something that had to be hammered home in a time when more developers were used to coming up with screens for IBM mainframe terminals). In your average GUI, moving into a new modal state meant – typically – throwing up a modal dialog.

It’s a much simpler rule – and probably one that would be good to be adopted again. (If I remember correctly, the WOSA Guidelines from Ye Olde Windows 3.1 days actually used the same rule).

Frankly, the Windows GUI guidelines are occasionally inconsistent. This mess is one example of where it was botched. Here’s another example:

Raymond: Thank you for pointing out this important issue! I always get mad if I see another app with "…" in the About command!

On the other hand, I think "…" should even be included when a command needs further input but doesn’t display a dialog box. For example, the Rename command on the shortcut menu for files in Explorer should have …, because the command will require further input before the file is actually renamed. Of course, the input here happens in-place and no dialog box is displayed (nice direct manipulation), but the missing dialog box shouldn’t be a reason for not including the … after the Rename command.

Small correction: Menu commands and button captions should never say "Save as…", because these UI elements use book title capitalization. So they should always be "Save As…".

The "Microsoft Manual of Style for Technical Publications" is also very helpul in this regard. Highly recommended for everyone, not just UI guys.