For editing and answering, I want to know: what's the best way to notate a menu item's path? (This also goes for things such as preferences.)

I have seen the following:

  • Menu > Item
  • Menu-> Item
  • Menu -> Item
  • Menu → Item
  • Menu → Item
  • Menu > Item
  • Menu » Item
  • Menu » Item

…and many more. We should really have some standard.


Apple's Style Guide (page 116) uses this method:

Pull-down menus: Note hyphenation. A pull-down menu is a menu in the menu bar. When you give instructions for choosing an item from a pull-down menu (a menu in the menu bar), use the style shown here.

  • Choose [menu] > [item] > [submenu item]
  • Choose Edit > Find > Find Next
  • Choose File > Save As.

I don't think it should be a rule, but such a guideline would be helpful for new users and would increase the consistency/legibility of the site. There's a good reason to have style guides.

  • To be honest, I dislike using ">" - after all it's a binary operator used for logical operations. "»" Is usually used when quoting. Here we are talking about navigating in menus. That's why using arrows makes the most sense to me.
    – gentmatt
    Apr 30 '12 at 16:26
  • It's only said binary operator for people who have terminal-fu skills, remember. For everyone else (the vast majority) it's handily descriptive of the actions required to find an option in a menu bar which every uses.
    – stuffe
    Apr 30 '12 at 20:45

I think we should stay away from the options involving special characters. They're harder to type and some older computers/browsers may have trouble displaying them. A standard involving special characters would be hard to enforce simply because it's more work to type so people are less likely to use it.

I don't think that we should bold all menu paths. I like preserving bold for where emphasis is required. Using it in all menu paths would 'dilute' its meaning in the rest of the document, and it would make it impossible to emphasize a specific path.
Similarly, I think that the <code> formatting should be reserved for code or specific parameters.

That leaves the first, second, and third options. I would argue that they are all fine: they contain the same information and are equally clear and readable. I prefer the second and third options, but that's just a personal preference.

That said, I think that much of this comes down to personal choice. Like the phrasing of a post, the original poster's 'voice' and preferences should be preserved whenever possible.
I would say that menu path formatting that does not match the standard is not an acceptable reason for an edit. Even if you're editing a post already, I don't think that changing the menu path formatting should be done except in extreme cases (all menu items in code formatting, or some problematic option that we haven't even considered).

Short version:

I propose considering any of the first three options standard. But, don't edit other people's stuff to match the standard unless you've got a good reason.

  • 1
    I can see absolutely no reason to enforce a standard on this. So long as the author makes his intentions clear, all is good. Personally, I like to put menu choices in Bold, and generally separate them using > (unless I can guide you to the menu using words).
    – jaberg
    Mar 18 '12 at 14:11
  • Agreed almost 100%, other than use of the <code> highlighting is very useful for differentiating what is prose in an answer, and what is meant to represent on screen text. Given that this is not a programming Q&A, I have co-opted the code emphasis to mean "screen text" of any sort. A such File > Print is cool with me.
    – stuffe
    Mar 18 '12 at 19:39

I would personally say that using:

Menu > Submenu

would be best for simplicity and easy of use.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .