No ellipsis in menu items?

[Evan Shultz]

In Windows and macOS (formerly Mac OS X or just OS X), it's common to put an ellipsis (three dots, "...") at the end of the text string for a menu item that opens a dialog. It's just the way the OS works. In Linux, of which I have little experience, it seems some UIs use an ellipsis and others don't.

Why doesn't KiCad use an ellipsis for relevant menu items? As a typical Windows user, it gave me pause to not see them. I can't say what percentage of KiCad users would want an ellipsis, but my vote is in favor of them (at least on OSes that use them, if OS variations are possible).

[Novak Tamas (novak-7)]

Another vote for "..."
Let's stick to standards --or at least habits-- when possible.

[Wayne Stambaugh (stambaughw)]

Standards? What are these standards you speak of? I'm using
Thunderbird to write this email and in some cases menu entries that open
dialogs have ellipsis (File->Print, File->Page Setup) and some do not
(File->Save and Tool->Options). Out of intellectual curiosity I checked
some other applications and the use of ellipsis is inconsistent at best
and down right confusing at worst. Since AFAIK none of our menu entries
have ellipsis, we are at least consistent. Personally I don't see how
this makes the user experience any better but I don't have a strong
opinion about it. The only strong opinion I do have is if we choose to
support ellipsis, we need to use them consistently or not at all.

On 7/8/2016 12:26 PM, Novak Tamas wrote:
> Another vote for "..."
> Let's stick to standards --or at least habits-- when possible.
>

[xzcvczx (xzcvczx)]

in regards to file->save does that not depend on whether something has previously been saved as if it has it will not have a dialog? whereas file->Save As will?

[Novak Tamas (novak-7)]

@Wayne, I think this can be called a standard...despite of some programs are exceptions from a standard.
I don't use Thunderbird as mail client, but your examples are fine: File->Save does the job immediately (no questions asked). Tool->Options's goal is to show the Options pane up..it is *not* a dialog where function details needed to achieve something: this case doesn't deserve an ellipsis.

E.g. Edit-Search needs answers (search key, where to find) to achieve search, so it is "Edit-Search...".
If your mail client opens up Address Book, a new window opens, but that is the main goal; it's not a dialog to specify function's details, so no "..." for Address Book mune item.

I've just indicated another "yes" vote. I also don't have a strong opinion about this "ellipsis thing" making the user experience way better, but IMO menus *are* better with ellipsis, and it's quite easy to do...

[Evan Shultz (evan-shultz)]

@Wayne, I believe this is a matter of perspective. You happened to look at outliers from what is, for all intents and purposes, a standard. Likely you're using a Linux distro?

For a macOS or Windows users, nearly all programs have ellipses in their menus and it's weird (for this primary Windows user) to not see them. Linux is more hit or miss.

Let's see what I can find online.

Windows, from MSDN Menu documentation:
"Indicate a command that needs additional information (including a confirmation) by adding an ellipsis at the end of the label." and "Proper use of ellipses is important to indicate that users can make further choices before performing the action, or even cancel the action entirely.".
https://msdn.microsoft.com/en-us/library/dn742392.aspx#usingellipses

macOS, from OS X Human Interface Guidelines:
"The ellipsis character (…) means that a dialog or a separate window will open... in order to complete the action." and "Specifically, it prepares the user to expect the appearance of a window or dialog in which to make selections or enter information before the command executes.".
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/MenuNaming.html#//apple_ref/doc/uid/20000957-CH24-SW1
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW3

KDE, from KDE TechBase Projects/Usability/HIG/Menu Bar:
"Indicate a function that needs additional information (including a confirmation) by adding an ellipsis at the end of the label (e.g. Save as…)."
https://techbase.kde.org/Projects/Usability/HIG/Menu_Bar
Also see https://mail.kde.org/pipermail/kde-guidelines/2014-January/000629.html.

Gnome, from Gnome Developer Writing Style:
"Use an ellipsis (…) at the end of a label if further input or confirmation is required from the user before the action can be carried out."
https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses
And if you're brave, see https://bugzilla.gnome.org/show_bug.cgi?id=169447.

I couldn't find anything solid on Ubuntu, just the following from their Standard Terminology:
"A button with an ellipsis ("...") on it, usually used to select a file."
https://wiki.ubuntu.com/DocumentationTeam/StyleGuide/StandardTerminology

There must be examples to the contrary, but I found these all by Googling "windows menu ellipsis" and similar within the first two pages of results. And all from official sources for each OS. Searching for images also turns up a load of screenshots reinforcing the above. I just don't see much ambiguity here.

So yeah. To answer "Standards? What are these standards you speak of?", FWIW that's a de facto (if not official) standard for all major OSes/Desktops under which KiCad runs. It surely seems like KiCad is an outlier by not using ellipses at all. That doesn't mean KiCad is unusable, but it does have a disjointed feel, especially under Windows and macOS.

For an example within KiCad, open Eeschema and go to File > Plot > Plot. Two buttons, "Browse..." and "Save report to file..." use ellipses. And yet we see "Browse" with no ellipsis in the Page Settings ...

[Jeff Young (jeyjey)]

Another +1 for correct use of ellipses.

I did find some in the current menus: Position Relative to... and Select... (both in the context menu in pcbnew). Of course the second of those is wrong. :O

[Jeff Young (jeyjey)]

A bunch of capitalisation errors were fixed.

And a few wording changes:

  3Dviewer File menu: Create Image (png format) --> Export Current View as PNG...
  3Dviewer File menu: Create Image (jpeg format) --> Export Current View as JPEG...

  eeschema pin context menu: Pin Size to Others --> Push Pin Size to Others
  eeschema pin context menu: Pin Name Size to Others --> Push Pin Name Size to Others
  eeschema pin context menu: Pin Num Size to Others --> Push Pin Num Size to Others

  eeschema block context menu: Zoom Block (drag middle mouse) --> Zoom Block
  eeschema Tools menu: Assign Footprint --> Assign Footprints
  eeschema Tools menu: Symbol Table View --> Symbol Table...

  libedit File menu: Create PNG File from Screen... --> Export Current View as PNG...
  libedit File menu: Create SVG File... --> Export as SVG...
  libedit Symbol menu: ERC --> Electrical Rules Checker

  pleditor Preferences menu: Text Editor --> Set Text Editor...
  gerbview Preferences menu: Text Editor --> Set Text Editor...

  modedit Dimensions menu: Pad Properties --> Default Pad Properties...
  modedit pad context menu: Enumerate Pads --> Renumber Pads...
  modedit pad context menu:
          Explode Selected Pad To Graphical Shapes --> Explode Pad to Graphic Shapes...
  modedit file menu: rationalised "Active Library" and "Current Library" to "Active Library"

  pcbnew Dimensions menu: Pads Size --> Default Pad Properties...
  pcbnew File > Archive sub-menu:
         Archive Footprints in Project Library --> Archive Footprints in Existing Library...

And a couple of menu restructurings:

  3Dviewer: moved "Copy 3D Image to Clipboard" from File menu to Edit menu
  3Dviewer: "Copy 3D Image to Clipboard" --> "Copy 3D Image"

  eeschema: promoted "Plot" and "Plot to Clipboard" from sub-menu
  eeschema: promoted "Save/Load Preferences" and "Import/Export Hotkeys" from sub-menu

[Wayne Stambaugh (stambaughw)]

@Jeff, I merged your patch. Thanks. I didn't see any outliers but it was a fairly large patch so I may have missed some. If I did, please send any additional patches to the dev mailing list.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 1afbfad44a30bf50efe04270ff94feaf11d17163
https://git.launchpad.net/kicad/patch/?id=1afbfad44a30bf50efe04270ff94feaf11d17163

[Jeff Young (jeyjey)]

The dialog buttons need doing too, but that can wait for 6.0. (There aren't that many of them, and some of them are already done like "Run DRC..." and "Generate Drill File..." from the Plot dialog.)