terminal: UI style errors: Menu items capitalization and … (ellipses) mark misuse
Windows Terminal version
1.20.10572.0
Windows build number
10.0.22631.3235
Other Software
No response
Steps to reproduce
Display the tab contextual menu, preferably with a second pane open to show all options.
There are several problems with this menu.
First: Excessive capitalization
If you check out the style guide: https://learn.microsoft.com/en-us/style-guide/text-formatting/formatting-common-text-elements
You’ll see that UI text or strings should use Sentence-style capitalization, this is further described at https://learn.microsoft.com/en-us/style-guide/capitalization
capitalize the first word and lowercase the rest.
Exceptions: Proper nouns, including brand, product, and service names, are always capitalized.
If a title or heading includes a colon, capitalize the first word after it.
Tab, New, Window, Right are not brands, products, or service names, they should not be capitalized.
This looks worse in other languages as determiners make the capitalized words lose their vertical alignment, as seen in #16819.
Second: Misuse of … (ellipses)
From the Windows UX design guide: https://learn.microsoft.com/en-us/windows/win32/uxguide/text-ui#guidelines
Ellipses mean incompleteness. Use ellipses in UI text as follows:
Commands: Indicate that a command needs additional information.
Don't use an ellipsis whenever an action displays another window only when additional information is required.
For more information, see [Command Buttons](https://learn.microsoft.com/en-us/windows/win32/uxguide/ctrl-command-buttons).
(… more details about truncated text, use in data and labels not included here)
I know this is getting out of style, but … and > next to menu items were originally designed to provide predictability.
The … after a menu item means selecting it will display a follow-up dialog or window asking for more options before completing the selected action, while > after a menu item means selecting it will display a cascading submenu, finally, neither means selecting it will perform the action immediately.
Therefore, they are mutually exclusive, you cannot have … and > on the same menu item, clicking it either displays a dialog/window, or a submenu, it cannot do both.
More modern Windows UI is trying to get rid of … on menu items, trading discoverability and predictability for the sake of visual style, but including it when it doesn’t mean a subsequent window will get displayed breaks both the UI guidelines we had since Windows 3.x, and the modern look. Those Close… have to go.
Note the tab contextual menu was taken as an example because it contains all the problems I wanted to mention, but other menus also contain similar errors.
Expected Behavior
UI consistency (didn’t there used to be a UI guidelines check before inclusion as a Windows component?).
Actual Behavior
Unpredictability and confusion 🤪
About this issue
- Original URL
- State: closed
- Created 4 months ago
- Comments: 33 (17 by maintainers)
Commits related to this issue
- Fix: UI style errors: Menu items capitalization and … (ellipses) mark misuse (#16886) I changed the improper capitalization and misuse of ellipses mark (...) in the context menu and various other pla... — committed to microsoft/terminal by HarshNarayanJha 3 months ago
- Fix: UI style errors: Menu items capitalization and … (ellipses) mark misuse (#16886) I changed the improper capitalization and misuse of ellipses mark (...) in the context menu and various other pla... — committed to microsoft/terminal by HarshNarayanJha 3 months ago
- Fix: UI style errors: Menu items capitalization and … (ellipses) mark misuse (#16886) I changed the improper capitalization and misuse of ellipses mark (...) in the context menu and various other pla... — committed to microsoft/terminal by HarshNarayanJha 3 months ago
Looking at recent versions of Word and Excel, and the new versions of Notepad and Paint, it seems they removed the
...from all menu items. In Terminal, onlyChange tab color...remains. To me it doesn’t make sense to haveChange tab color..., butExport textandFindwithout...in the same menu. I would suggest getting rid of the last remaining one to achieve consistency with other modern built-in apps.It will be sufficient to update only the English text. The rest of the localizations are automatically uploaded to a human translation service.
Since they are fully qualified colour (or color if you are american) names, I think they should be both capital.
@HarshNarayanJha Thanks for taking on this issue. I had a quick look at the PR.
The
TabCloseSubMenuis still “Close…”. If I’m not mistaken, that is the menu item that shows the submenu on my screenshot starting this thread. It should be “Close” without the ellipses as it will have the “>”.The
NewTabSplitButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Nameis “New Tab”. I’m not sure where this label is used, but it probably should be “New tab”. TheAboutDialog.PrimaryButtonTextshould probably be “Send feedback”, it’s not referring to the Feeback hub, and Notepad uses the lowercase version as well for the same purpose. TheExportTabTextshould probably use lowercase as well: “Export text”. Same forPlainText: “Plain text”.You changed “Admin” to “admin”, but left an uppercase for
RunAsAdminFlyout.Text: “Run as Administrator”. This one is less clear cut because there is an “Administrator” default user account, but the same label in the shell uses “Run as administrator”. I think it should be lowercase. I would suggest we also take the opportunity to change “This Terminal window is running as admin” to “This Terminal window is running as administrator”. What do you think @DHowett ? I know most power users simply say “admin”, but every other piece of system UI I checked uses the full “administrator” term, such as “Run as administrator” in the shell and in Terminal itself, “Administrators” group in Local Users and Groups,…. I think keeping the full term will make it more consistent and easier to understand for all the non-native English using the en-us UI as a global default. (I love all the localization work Microsoft has done over the years, but some global companies are not used to the idea of just having MUI and letting each user in subsidiaries pick their preferred UI language just yet).Another arbitration question to Dustin about
LargePasteDialog.Content, “You are about to paste text that is longer than 5 KiB. Do you wish to continue?”. It is correct, but Windows has always used “KB” for binary units, so wouldn’t it be better to be consistent with the shell and avoid the “KiB”?@HartJesse Resource files for different languages are in src/cascadia/TerminalApp/Resources.
However, I think to fully resolve this issue, all locales must be updated, not just English.
I would also change
Color…toChange tab color…, making it more clear and justifying the…, since it clarifies it is the color of the tab that will be changed, but only after a subsequent dialog that requests more information about the color and can still be cancelled.To old-timers like me, the
…always mean “it’s safe to click to find out more about what this menu item does because there’s another step where it can still be cancelled”.