Change HIG for ellipsis to make sense

[tsg1zzn]

The HIG for ellipsis on menu items states that the ellipsis should be on all menu items that opens a new window. I think it would more sensible to have ellipsis on menu items that require further information to complete the command.

For example, if the menu item is called "show graph window", then it makes no sense to have an ellipsis, because once you click the menu it carries out the task.

On the other hand, the menu item "Print..." needs dots to indicated that a print options window will be shown before any actual printing occurs.

This is the behaviour specified in the guidelines for Windows, Mac and Linux, and using ellipsis on all menu items that opens a window is even listed a gui blooper in the book "GUI Bloopers" by Jeff Johnson.

I suggest the HIG is revised because the current specification

• Makes no sense
  
• Clutters the menu
  
• Violates users' expectations when they are coming from Windows, OS X, Linux, Java/SWING or whereever else they can come from.

Copy-and-paste from Java Look and Feel Guidelines:
Ellipses (...) are punctuation marks that indicate the omission of one or more words that must be supplied in order to make a construction complete. In your menus, you can use ellipses in a similar way: to indicate that the command issued by a menu item needs more specification in order to make it complete.

- If a menu item does not fully specify a command and users need a dialog box to finish the specification, use an ellipsis after the menu item. For example, after choosing Save As..., users are presented with a file chooser to specify a file name and location.

- Do not use an ellipsis mark simply to indicate that a secondary or utility window will appear. For example, choosing Preferences displays a dialog box; because that display is the entire effect of the command, however, Preferences is not followed by an ellipsis.

[humdinger]

Since there has been consent the suggestion is sound, I propose this change to the ​HIG Chapter 9:

Replace: Items are capitalized as described in Chapter 6 and an ellipsis is used with any item which opens a window.

With: Items are capitalized as described in Chapter 6. An ellipsis is used when a menu item opens a panel that is needed to complete the item's function. No ellipses must be used, if the function already implies the opening of a window. See ​Ellipses.

And in ​HIG Cahpter 6 - Ellipses:

Replace: An ellipsis is a series of 3 dots (...) used to tell the user that a control, often a menu item or button, will open a window. For example, a menu item named "New..." will display a window which has the title "New". However, if creating a new document does not require showing a window, then an ellipsis should not be used.

With: An ellipsis is a series of 3 dots (...) used to tell the user that a control, often a menu item or button, will open a window that is needed to complete the item's function. For example, "Print..." will open a dialog before it actually starts printing. No ellipses must be used, if the function already implies the opening of a window, like "Settings" opening a preferences panel or "Show Log" opening a window with some data.

I couldn't find the HIG in the trunk or I would provide a patch. Please advise how to get these changes into the documents.

[humdinger]

Sorry, the first sentence should better be: "Since some have shown consent that the suggestion is sound".

[Prognathous]

I think it would make more sense to show an ellipsis if the new window/dialog typically requires user interaction. "Settings" dialogs typically do, "About" dialogs don't. "Show Log" can be either way.

Some reference:

​http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGText/XHIGText.html

​http://msdn.microsoft.com/en-us/library/aa511502.aspx#ellipses

Prog.

[humdinger]

Replying to Prognathous:

I think it would make more sense to show an ellipsis if the new window/dialog typically requires user interaction...

I agree, if you add "... to complete the menu item's intention."

"Settings" for example (which should according to HIG be "Options" btw): Selecting it is all that's needed to fulfill it's described purpose, i.e. showing the settings panel. The user can make changes or simply close the panel again, in any case, 'Mission Accomplished'.

"Print..." on the other hand, actually *needs* user input, even if she goes with the defaults and just clicks "OK", to actually do what the menu item says: print.

You're 2nd reference (Microsoft, with 4 dots as ellipse for "Page Setup...." in the screenshot there... :) ) puts it like this:

This doesn't mean you should use an ellipsis whenever an action displays another window—only when additional information is required to perform the action. For example, the commands About, Advanced, Help, Options, Properties, and Settings must display another window when clicked, but don't require additional information from the user. Therefore they don't need ellipses.

If we can agree on this, my replacement text will have to be adjusted a bit for clarity.

[jonas.kirilla]

The emphasis should be on the command/action needing additional information, which is what the ellipsis is supposed to stand for. (Opening an intermediate window is the usual form of prompting the user for these command arguments (modifiers?) but is it the only possible form?)

[axeld]

Replying to humdinger:

"Settings" for example (which should according to HIG be "Options" btw)

The HIG has actually been written by DarkWyrm, and to the best of my knowledge, wasn't ever reviewed by anyone else yet. IOW it should not be considered as an official document at this time; it probably needs lots of work.

[humdinger]

OK. But at least making things consistent after what's in there now (I'm just talking text strings), should be better than having a mix of e.g. Setting, Options, Preferences (+with and without elipses).

[axeld]

Just as a counter example, the Amiga User Interface Style Guide states that (chapter 6)

"When a menu item brings up a window or requester, an ellipsis (three dots) should be appended to the menu item's label."

That being said, I don't particularly care either way, as long as we make it consistent. That's also the only problem with the suggested way: while it does make sense, it probably also introduces a few corner cases where it's not clear what to do. To bring up one simple example: an about dialog is not a "show graph window", and even requires user input to close it -- it's still usually considered to not need the ellipsis.

[leavengood]

Regarding Axel's last post: I think in most cases it is pretty obvious whether the window or menu item needs more user input. Overall I agree with the premise of the ticket.

Also I strongly agree with Axel's assessment from 3 years ago about the HIG: while it is a nice start, I think it definitely needs a good look over and editing to better match Haiku's philosophy and not just DarkWyrm's. Not that he is a bad UI designer, but his opinions may not all match the project.

Also the writing style is a bit cheeky and we may want to adjust that. For example the first chapter is called "How to Design Software Good" and that is generally not good English grammar, but maybe he was trying to be clever. But it would be better to change it to "How to Design Good Software" or "How to Design Software Well" (depending on the intended meaning.) I have a it on my list to read through the HIG and when I do I'll take note of changes needed.

Regarding editing the HIG: I'm not sure if it was in the source before, but now it is at ​src/documentation/uiguidelines/HaikuHIG.xml (one big file.)

Also regarding the name for an application preferences menu item: given we have a whole set of applications called Preferences it makes more sense for applications preferences (or settings or options) to be called Preferences. This also happens to match Mac OS X (and as I use Mac OS X the more I realize that BeOS and Haiku most resemble it.)

[humdinger]

WRT to corner cases of ellipsis: I guess we'll only see while doing it. Theoretically it should be easy (famous last words...). After clicking a menu item a window opens and you ask "Has been accomplished what the menu item says?". If not, the menu item needs an ellipsis. E.g.:

"About" -> shows the about window. -> Mission accomplished -> no "..."
"Page setup" -> shows the printer page setup window. -> Mission accomplished -> no "..."
"Preferences" -> shows the preferences window. -> Mission accomplished -> no "..."
"Print"-> shows the print setup window -> Didn't "print" yet -> "..." needed
"Open"-> shows the file dialog -> Didn't "open" yet -> "..." needed
"Find"-> shows the find dialog -> Didn't "find" yet -> "..." needed
etc.
If we're agreed, I'd start the ellipis hunt...

WRT to settings, options, preferences: I'm OK with going with "Preferences" everywhere. A shame only that there's still ~/config/settings/ ...

[axeld]

See? The about case is done without the ellipsis on other platforms :-)

Anyway, wrt settings vs. preferences: I think it's okay to call the applications (and dialogs) preferences, and the on disk storage settings. Maybe that could be a viable differentiation.

[humdinger]

Replying to axeld:

See? The about case is done without the ellipsis on other platforms :-)

As it is with above's ellipsis recipe. :)

So, ellipsis and preferences full steam ahead...

[axeld]

Damn, I read it completely the other way around: Mission accomplished? -> no, "..." ;-)

[humdinger]

Replying to axeld:

That being said, I don't particularly care either way, as long as we make it consistent. That's also the only problem with the suggested way: while it does make sense, it probably also introduces a few corner cases where it's not clear what to do.

Wise words...
I just went through the source and tried to apply my "recipe". It started all very well, but the longer you're at it, the more you doubt what you're doing. Exceptions creep in and after revisiting your work, you're not sure at all any more. It can't be done (by me). I'm now a proponent of ellipsis whenever another window is opened...

WRT "Preferences": I had a look, and we're using pretty consistently "Settings" (with very few "Options" here and there). Maybe it's not that bad having "Preferences" for the system wide settings that have their own preference panels and using "Settings" for app specific settings that are set from within the app.

Looks like I'm going back on everything I've said before in this ticket today... Can't help it, more data forced me to it.

[pulkomandy]

The HIG is not needed for R1.

[waddlesplash]

I'll let Humdinger make the necessary changes here, seeing as he's already proposed them :)