在几乎所有具有菜单栏的应用程序中，有些项目后面有一个省略号 (...)，有些则没有。是否有一个众所周知的约定什么时候把省略号放在那里，什么时候不放？你什么时候做？你做吗？
我查看了各种 Windows 应用程序，这就是我的想法：
省略
没有省略号
但是似乎总是有不遵循此规则的菜单项。例如，Visual Studio 中的帮助项（我如何、搜索、索引）和查找和替换（快速查找、在文件中查找、查找符号）。
因此，在考虑了更多之后，我现在认为这可能是事情：
省略
没有省略号
你们有什么感想？
关键因素是菜单选项在执行操作之前是否需要附加信息（输入或选择）。所以 Help-About 不需要省略号，但 File-Open 需要。无论如何，这就是 Microsoft、Apple 和 KDE 指南所说的内容。
Microsoft Windows 应用程序应该遵循Microsoft 的“用户体验指南”。这是他们对菜单项上的省略号的看法。
虽然菜单命令用于立即操作，但执行操作可能需要更多信息。通过在标签末尾添加省略号来指示需要附加信息（包括确认）的命令。
这并不意味着您应该在操作显示另一个窗口时使用省略号——仅当需要额外信息来执行操作时。例如，关于、高级、帮助、选项、属性和设置命令在单击时必须显示另一个窗口，但不需要用户提供其他信息。因此它们不需要椭圆。
David 的回答引用了KDE 3 用户界面指南，
请注意，菜单中首先打开需要附加信息的对话框的每个项目都必须用尾随省略号 (...) 进行标记（例如，另存为...、打开...）。菜单项和“...”之间没有空格。简单的确认对话框不被视为需要额外信息的对话框。
当它出现在按钮或菜单项的名称中时，省略号字符 (...) 向用户指示在执行相关操作之前需要附加信息。具体来说，它使用户准备好在命令执行之前期望出现一个窗口或对话框，在该窗口或对话框中进行选择或输入信息。因为用户期望按钮和菜单项的即时操作（如“按钮”和“菜单行为”中所述），所以通过适当地显示省略号字符来为这种替代行为做好准备尤为重要。以下指南和示例将帮助您决定何时在菜单项和按钮名称中使用省略号。
据我了解， (...) a end 通常意味着用户将被要求输入一些内容。no (...) 表示不需要输入。
你说得对，总结一下。如果您想了解更多信息，可以在此处找到用户样式指南列表：http ://www.experiencedynamics.com/science-usability/ui-style-guides
我同意，这符合我自己对何时包含省略号的看法。
我想省略号的重点是“警告”用户，以便她可以理解某个选择是安全的探索，它不会在不通过对话框询问更多信息的情况下立即做某事。
在某些程序中，例如（至少是旧版本的）Autodesk 的 Maya（一个高端 3D 建模包），省略号实际上是一个小的对话框图标。您可以单击菜单中的图标以获取图标，或单击菜单项的其余部分（文本）以使用与上次相同的设置或类似的设置重复命令。似乎这个想法并没有流行起来并成为主流。
这确实是一个非常棘手的问题。起初它可能看起来很明显，但有许多动作属于类别之间。有趣的是，微软自己违反了这种做法。
Vista 中的示例在计算机管理菜单文件 - 选项... 在计算机管理/用户和组/用户中有省略号。右键单击用户。New user... 操作有省略号，但 Rename 没有，尽管它需要额外的操作来实际重命名帐户。在 Micrsoft SQL Server Management Studio 菜单 File - Print 中具有带省略号的 Properties... 按钮。
这只是经过 5 分钟的调查。还有很多例子。
您可以为这两种操作都使用两种约定。您实际上无法更改任何属性或选项，除非在显示的假定应使用省略号的对话框中执行一些额外操作。但是，您可能只对查看定义的选项或属性感兴趣，并且假定没有使用省略号。微软也承认存在模棱两可的情况
“如果有歧义（例如，命令标签缺少动词），请根据最可能的用户操作来决定。如果只是查看窗口是常见操作，请不要使用省略号。” 然而，基于此，省略选项和属性会更有意义，因为您可能更有可能想要更改仅查看它的属性。