Add Clarification for Ellipsis Use
Closed, ResolvedPublic

Description

In this link:

https://hig.kde.org/style/writing/labels.html

Under the

https://hig.kde.org/style/writing/labels.html#using-ellipses-in-labels

We need to add a new line explaining a rule to use ellipsis. The rule would be:

"If your menu item opens a new dialog or window and is not considered in the list below, use an ellipsis"

abetts created this task.Apr 27 2018, 5:24 PM

More questions:

Is this about modal boxes?
Is this about setting the expectation that another window is going to appear, or just that the action needs further input to *begin*?
Do screen readers use the contents of menu items to track state, such that perhaps the lack of ellipsis would result in something akin to "focus stealing prevention" causing the user to wonder what just happened?

Just as a contra-example, the macOS application menu most like our "Configure $Application", is "Preferences..."

More questions:

Is this about modal boxes?
Is this about setting the expectation that another window is going to appear, or just that the action needs further input to *begin*?

This is the most common scenario that we have discussed. So, yes, it would apply for that.

Do screen readers use the contents of menu items to track state, such that perhaps the lack of ellipsis would result in something akin to "focus stealing prevention" causing the user to wonder what just happened?

Can you give me an example of this? I am not sure I am understanding the part about screen readers and tracking state. How does that work?

Just as a contra-example, the macOS application menu most like our "Configure $Application", is "Preferences..."

MacOS has this rule:

Use an ellipsis whenever choosing a menu item requires additional input from the user. The ellipsis character (…) means a dialog or separate window will open and prompt the user for more information or to make a choice.

https://developer.apple.com/macos/human-interface-guidelines/menus/menu-anatomy/

More questions:

Is this about modal boxes?
Is this about setting the expectation that another window is going to appear, or just that the action needs further input to *begin*?

This is the most common scenario that we have discussed. So, yes, it would apply for that.

"yes" to the latter, or the former?

Do screen readers use the contents of menu items to track state, such that perhaps the lack of ellipsis would result in something akin to "focus stealing prevention" causing the user to wonder what just happened?

Can you give me an example of this? I am not sure I am understanding the part about screen readers and tracking state. How does that work?

I don't know how it works, I'm not near a macOS installation at the moment and I know nothing of assistive technologies for xorg and/or wayland. My recollection is that Voiceover describes the focused control, but I don't know what it does with "…"

Just as a contra-example, the macOS application menu most like our "Configure $Application", is "Preferences..."

MacOS has this rule:

Use an ellipsis whenever choosing a menu item requires additional input from the user. The ellipsis character (…) means a dialog or separate window will open and prompt the user for more information or to make a choice.

https://developer.apple.com/macos/human-interface-guidelines/menus/menu-anatomy/

And this is where the hair splitting begins:

"{...} dialog or separate window will open and prompt {...}"

The configuration dialog doesn't, strictly speaking, require any input. It just appears. However, Finder has "Preferences..." which would seem to place emphasis on "dialog or separate window" over "and prompt the user"

IMHO, this is an open-and-shut case; no need to inject unnecessary nuance and complication: Any button or menu item that will result in the creation of presentation of a new window (dialog or otherwise) should get the ellipsis, period. This seems like the only way to avoid endless debates about what should or should not have an ellipsis, and it's also the most consistent and comprehensible from the standpoint of a regular user.

kossebau added a subscriber: kossebau.EditedApr 27 2018, 8:14 PM

E.g. all entries in the start menu or all krunner results will often result in the creation of "a new window". Should they really all get ellipsis (and thus more clutter)? Is that really needed?

IMHO the old concept of making a difference between action-which-needs-further-immediate-interaction-to-complete and e.g. action-which-make-a-place-appear-which-can-be-used-for-whatever-wanted-but-not-related-to-the-invoke-action makes a lot of sense. (where "place" can be containers or documents of all kind), shown by some "app".
When it comes to menu entries "Configure" & "Settings", IMHO if using the verb "Configure" this means start-action-which-needs-further-interaction, where if using "Settings" this is more like "Go to Settings", meaning a place where one than can do.

So IMHO the current rules are pretty clear, just need some brush over. Seeing how people instinctively have used ellipisis in some places and not in other places should already serve as a first research what really makes sense for users.

apol added a subscriber: apol.Apr 27 2018, 9:54 PM

+1
Create a patch and let's discuss over the wording?

E.g. all entries in the start menu or all krunner results will often result in the creation of "a new window". Should they really all get ellipsis (and thus more clutter)? Is that really needed?

I think it's more about how in this case you are actually taking an action, deciding on something.

The ellipsis basically tells you "nothing big is going to happen, you will be just asked about your experience". Lack thereof is often actions that happen upon triggering, such as Cut where something will happen on the editor or LibreOffice appearing out from the menu.

fabianr added a subscriber: fabianr.May 1 2018, 8:48 AM

Create a patch and let's discuss over the wording?

+1

ngraham claimed this task.Sep 9 2018, 7:36 PM
ngraham closed this task as Resolved.

I did this in 68cf360fe700c199a76ea6e050198c380b109bc3. If anything is still unclear or inconsistent, we can improve it in subsequent patches.