When do you put … after a button or menu?

Date:May 17, 2004 / year-entry #193
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040517-00/?p=39313
Comments:    34
Summary:When do you put "..." after a button or menu? For example, some menus say "Save as..." and some buttons say "Customize...". What is the rule for dots? Many people believe that the rule for dots is "If it's going to display a dialog, then you need dots." This is a misapprehension. The rules are...

When do you put "..." after a button or menu? For example, some menus say "Save as..." and some buttons say "Customize...". What is the rule for dots?

Many people believe that the rule for dots is "If it's going to display a dialog, then you need dots." This is a misapprehension.

The rules are spelled out in the Windows User Interface Design Specifications and Guidelines (what a mouthful). Scroll down to "Ellipses".

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.

Comments (34)
  1. 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.

  2. Mike Dimmick says:

    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.

  3. Raymond Chen says:

    I think you’re right. "Internet Options" shouldn’t have ellipses. This is a subtle rule that not everybody understands.

  4. Me says:

    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:


    take over access keys used by my browser: pressing ALT+A no longer displays my Favorites menu, but instead has no apparent effect (to see what’s intended look for ACCESSKEY="A" in the HTML source).

  5. 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.

  6. asdf says:

    File | Versions and Tools | Word Count in Word have "…" after it. Not to mention the Tools | Customize and Tools | Options menu items. I think I’ll stick to the rule "if this shows a dialog box, put … after it".

  7. Centaur says:

    Another common error seen in

    > Microsoft products is underlining the

    > O of OK and C of Cancel.

    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.

  8. Centaur says:

    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!”.

  9. TLKH says:

    So, we have a very unclear GUI rule.

    Even skilled computer programmers/GUI designers (including Microsoft’s) do not always understand it, so what’s about normal PC users (all these rules are for their convenience, aren’t they)?

    (do I understand correctly – "Options" must not have "…", but "Change Options" must have, even if they display identical dialogs?)

    I personally think that the simple rule "… means dialog) would work better.

  10. I’m glad you covered this peeve of mine. It’s really clearly spelled out, uncommonly consistent across all platforms, and yet it’s constantly screwed up!

    This is also covered in "GUI Bloopers" (#38), by Jeff Johnson.

    Think of it this way. The rule is: the user has to type in more stuff before they get what they want.

    Lots of applications make this mistake. I recommend following the rule as written, than trying to reverse engineer wrongly from various applications that suffer from this inconsistency.

  11. AlisdairM says:

    So what are the chances of getting this rule applied consistently across MS apps in the move to Longhorn?

    Effectively a fresh start (complete with new GUI theme) it seems a good time to review against the guidelines, especially as there are likely to be new guidelines anyway!

  12. Aarrgghh says:

    P.S. Betcha 95% of end users have never noticed the ellipses anyway.

  13. Dylan Greene says:

    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.

  14. David Candy says:

    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".

  15. njkayaker says:

    The "Internet Options" item SHOULD have an ellipsis. A dialog (basically) has one of two behaviors:

    1) Display information (can’t change anything) -> no ellipsis.

    2) Display information and can change stuff -> ellipsis.

    The "Internet Options" item allows you to change stuff. That is, 2 above applies (so it needs an ellipsis).

    Since you can always cancel a dialog that does something, these dialogs can just "display" information.

  16. Raymond Chen says:

    David: It is not 2 px per dlu. The number of pixels in a dlu depends on your font size. I discussed this earlier. http://weblogs.asp.net/oldnewthing/archive/2004/02/17/74811.aspx

    njkayaker: That doesn’t explain "Properties".

  17. What about those menu items that open a web page in a browser?

    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.

  18. David Candy says:

    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.

  19. Ben Hutchings says:

    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.)

  20. Aarrgghh says:

    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.

  21. asdf says:

    And when you right click on the taskbar, Adjust Date/Time has no … but Task Manager does. But if you do Ctrl+Alt+Del, the Task Manager button does not have it.

  22. Jack Mathews says:


    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.

  23. Frederik Slijkerman says:

    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.

  24. Florian says:

    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.

  25. Centaur says:

    (By the way, Apple and Java appear to have

    > the same rules for ellipses as Windows.)

    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.

  26. Pavel Lebedinsky says:

    Regarding Properties vs. Options… – I think it actually makes sense this 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.

  27. 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’).

    Specifically, you can find the rule in this: http://developer.apple.com/documentation/mac/pdf/HIGuidelines.pdf – or if you prefer, this: http://developer.apple.com/documentation/mac/HIGuidelines/HIGuidelines-84.html#HEADING84-0

    "The Ellipsis Character in Menus

    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:


    I’m talking about the bit that says to make sure that you don’t ever use the question-mark icon for your message boxes. Instead, you’re supposed to use the Warning! Icon.

    That’s just plain wrong. Not every question posed to the user has potentially devestating results if they don’t pick the right answer.


    Some times it sucks to be a UI Nazi. :)

  28. josh says:

    Outside of this context, "…" basically means "more, omitted." These other meanings are useful information (perhaps more useful), but really have nothing to do with the symbol.

  29. josh:

    Actually, more often than not, it indicates a trailing train of thought, a pause, or an interruption. Diminuendo if you will.

  30. 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.

    Free download at: http://www.microsoft.com/downloads/details.aspx?FamilyID=b494d46b-073f-46b0-b12f-39c8e870517a&displaylang=en

  31. Claw says:

    Roland: Actually if you use title capitalization, the "as" should be lowercase, since it’s a preposition. Prepositions are not capitalized in title case. So "Save as…" is technically correct.

  32. Raymond Chen says:

    With title case, the first and last words are always capitalized, even if they would otherwise be lowercase.

  33. Claw says:

    Interesting… I never knew that rule.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index