Page MenuHomePhabricator

Please rearrange the order of items in the Insert menu
Open, LowPublic

Description

Hieroglyphics, which is rarely used, is easier to find than Gallery and mathematical formulae, which are used in tens of thousands of enwiki articles. It would be good if the items which were used the most were either towards the top or bottom, so that they were easier to find. Things that are rarely used, such as hieroglyphics and musical notation, could go in the middle.

Insert menu (initial)Insert menu (expanded)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 5 2017, 7:43 PM
Schnark added a subscriber: Schnark.Jul 6 2017, 7:11 AM
Deskana added subscribers: Prtksxna, Pginer-WMF, Deskana.

@Pginer-WMF @Prtksxna Your thoughts would be welcome on this.

Yes, functionality that is used more often should be easier to access. I couldn't find any information on why the menu items are ordered the way they currently are, links? Also do we have any data on which of these items are used most often, or do we just infer it by looking at the content on the pages?

It might make sense to group similar items together too, but not sure how that'd work with More/Fewer.

  • ??Wiki??
    • Table
    • Template
    • Comment
    • References
    • Signature
  • Media
    • Media
    • Graph
    • Gallery
  • Advanced
    • Hieroglyphs
    • Music notation
    • Chemical formula
    • Math formula
    • Code block

I agree with @Prtksxna considerations. I just wanted to try to compile usual strategies to deal with complexity in these cases. Depending on the volume of options we expect the "insert" menu to reach we can consider different strategies:

  • Ordering. It makes sense to have the general tools before the very specific ones that are used less frequently.
  • Grouping. Grouping by related categories also helps to scan the list easily since users can skip the groups they are not interested in. Those groups can be implicit (e.g., adding separators) or explicit (e.g., adding labels with clear and descriptive names).
  • Personalisation. Make it easy to access those options that each individual user uses the most can help to better support regular use for the user. For example, the initial list (visible before clicking "more") can include in addition to the current options, a couple more based on the items that the user used the most/recently. This can help to avoid looking for the "gallery" option again and again in a longer list if that is a common tool for the user.
  • Search. Being able to search for options by typing can provide a quick keyboard access for advanced users to access any option (e.g., press cmd+i and type "gal"+ enter to insert a gallery).

"Ordering" may not work well for a very long list, and "search" can be overkill for a short list that can be quickly scanned though. So having an understanding on how long this list of options is perceived and how much it is going to grow is also something worth considering.

Yes, functionality that is used more often should be easier to access. I couldn't find any information on why the menu items are ordered the way they currently are, links? Also do we have any data on which of these items are used most often, or do we just infer it by looking at the content on the pages?

They're ordered based on user testing back in 2013/14, with some messy changes since then. Frequently-used items were promoted based on how often they were used (with Media intentionally promoted above Template based on user testing meaning users were confused by the first item in the menu and skipping the rest). The rest were originally in alphabetical order, with references list demoted to the bottom as it's infrequently needed. However, since then the order's been screwed due to the load order changing; re-sorting to alphabetical order might be a good quick step before going further?

It might make sense to group similar items together too, but not sure how that'd work with More/Fewer.

I'd recommend keeping the "above the line" items in their own top-level area, rather than having them move position when the menu expands (@matmarex fixed this for Table just recently).

  • ??Wiki??
    • Table
    • Template
    • Comment
    • References
    • Signature
  • Media
    • Media
    • Graph
    • Gallery
  • Advanced
    • Hieroglyphs
    • Music notation
    • Chemical formula
    • Math formula
    • Code block

Sections of tool menus, and double-level/nested tool menus, aren't yet supported in OOjs UI's toolbars; I proposed them back in 2014 for this purpose: T73616: OOUI: Toolbar menus should use sub-groups with a separator (<hr>?) between them for splitting up longer lists for the former, T74159: OOUI: Toolbar groups should support sub-groups as items (hierarchical, nested menus) for the latter. I understand that they'd be moderately hard to do.

You (plural) should also think about whether we really want to encourage some anti-patterns (like HTML comments).

If we can't have proper sections, then what do you think about fake sections? We could add "Advanced features:" as a grayed-out, never-functional "item" (maybe with some sort of different formatting).

Also: What does "alphabetical" mean in a multilingual world? I'd rather find items in the same place, no matter what my user-interface language is.

There may be some minor tweaks to make here that would be beneficial, such as moving "Comment" down to discourage its use by novice editors as James suggests, or moving "Hieroglyphics" down since it's very infrequently used. A major overhaul does not seem worth the effort.

If we can't have proper sections, then what do you think about fake sections? We could add "Advanced features:" as a grayed-out, never-functional "item" (maybe with some sort of different formatting).

Using disabled buttons as headers would be very bad for usability, so I think we'd be making one problem a lot worse to potentially make another better.

Also: What does "alphabetical" mean in a multilingual world? I'd rather find items in the same place, no matter what my user-interface language is.

I was thinking of sorting them by their internal name (so consistent for users whatever their language), rather than by display name, but in most/all languages that means the list won't be alphabetical to them, of course.

Deskana triaged this task as Low priority.Jul 18 2017, 7:22 PM
Deskana moved this task from To Triage to TR1: Releases on the VisualEditor board.
Prtksxna added a comment.EditedJul 20 2017, 10:41 AM
NOTE: The following assumes that: "A major overhaul does not seem worth the effort." – @Deskana

I have a pretty bad proposal in mind. It goes against the following:

There may be some minor tweaks to make here that would be beneficial, such as moving "Comment" down to discourage its use by novice editors as James suggests

Media intentionally promoted above Template based on user testing meaning users were confused by the first item in the menu and skipping the rest)

with references list demoted to the bottom as it's infrequently needed.

I propose that we use the grouping I suggested in my previous comment and keep the ??Wiki?? items "above the line". We don't introduce any sections for the grouping, and just use the ordering that results from it. Its bad because:

  1. Two rarely used or discouraged items are now above the line.
  2. We don't have Media on top, but I guess Table can serve the purpose of not confusing the user just as well.
  3. Lack of discoverability and an added click required to add Media.

Let's make it better by adding a new Group called "Discouraged/Rarely used items", add Comment and References list to it, and move it to the bottom.

WikiMediaAdvancedRarely used
TableMediaCode blockReferences list
TemplateGalleryMath formulaComment
SignatureGraphMusic notation
Chemical formula
Heiroglyphics

Now we have two options:

  1. Move "the line" to after Media making the above list - Table, Template, Signature, Media
  2. Remove the More/Fewer option completely. This would temporarily increase the cognitive load on users, but will make using, and discovering these items easier in the long run (it would also get rid of T85638).
Pginer-WMF updated the task description. (Show Details)Jul 21 2017, 2:28 PM

"Media" is at the top because it is the thing that newer editors are most likely to use.

"Graph" probably seems like an "Advanced" item for most users.

Where would you put the (two) refs items on wikis without a Cite button in the toolbar? I'm not sure that these are "rarely used". In fact, if it weren't for the ref-deleting bug T152070, I'd probably do this once in nearly every enwiki article that I edit.

Maps is missing from the list. I don't know what else might be missing.

The English Wikivoyage has 16 items in this menu at the moment. Maybe we need two menus – one "Insert" and one "Advanced".

matmarex removed a subscriber: matmarex.Aug 2 2017, 11:22 PM
Deskana moved this task from TR1: Releases to Freezer on the VisualEditor board.Aug 23 2017, 3:50 PM