Use burger icon for action menu header

[alecharp]

Since the header redesign in 2.507, when too many actions have to be displayed in the header, a button with drop down effect is created. This button is using an ellipsis icon.
However, this type of icon is generally used for actions we can perform, not really for menu.
I propose here to use a burger like icon to represent the menu.

Testing done

Run locally using jetty:run.

Proposed changelog entries

• Use burger icon for actions menu in header

Proposed changelog category

/label web-ui, rfe

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@janfaracik @timja

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[janfaracik]

Fine by me - only ask is if we could use the Ionicons hamburger icon instead -

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path fill="none" stroke="currentColor" stroke-linecap="round" stroke-miterlimit="10" stroke-width="32" d="M80 160h352M80 256h352M80 352h352"/></svg>

[alecharp]

@janfaracik thanks. Replaced the icon with ionicon one.

[daniel-beck]

However, this type of icon is generally used for actions we can perform, not really for menu.

I don't understand this. It's an overflow menu icon. Same as GitHub or Slack for random elements that would be shown in a list-like structure, if there was space:

Neither of these seem to be limited to "actions we can perform".

[janfaracik]

I don't understand this. It's an overflow menu icon. Same as GitHub or Slack for random elements that would be shown in a list-like structure, if there was space:

I agree with this - not precious however.

[cristina-pizzagalli]

Hi @daniel-beck – While I agree that Slack and GitHub use the ellipsis/overflow icon, I don’t think it’s necessarily the best fit for our use case. Just because a design pattern is common elsewhere doesn’t mean it’s always the best solution for every scenario.

There’s a growing consensus in UX (this is just one article I found, but there's many -https://medium.com/free-code-camp/stop-the-overuse-of-overflow-menus-5caa4b54e843) that the overflow menu is too often used as a catch-all for actions that don’t have an obvious place in the UI. While it might seem like a tidy solution, it often means we’re avoiding the harder work of prioritizing and organizing actions for the user’s benefit.

Over-relying on the overflow menu can reduce discoverability and make the interface less intuitive, especially if critical or commonly used actions are tucked away. Users shouldn’t have to hunt for what they need, and hiding too much behind a “...” button can create unnecessary friction.

For our top-right header, I think a more intuitive and user-friendly approach would be to have clear, dedicated icons for search, settings, and account, along with a hamburger menu for any additional navigation items. This way, users immediately know where to go for navigation and core actions, without having to guess what might be hidden behind an ellipsis.

Not willing to die on this hill, but I genuinely don't think it's a best practice we should be embracing somewhere as important as the main header.

[daniel-beck]

For our top-right header, I think a more intuitive and user-friendly approach would be to have clear, dedicated icons for search, settings, and account, along with a hamburger menu for any additional navigation items. This way, users immediately know where to go for navigation and core actions, without having to guess what might be hidden behind an ellipsis.

That's not how this behaves though. It's the menu where I can find stuff after the UI adapts what's visible to window size.

If your window is large enough, these items are visible. If these icons were never visible at the top level in the first place, it'd be different, but they are (or may be, depending on how many there are). So while the Slack example might be a bad one (these are never shown), the GitHub example is a pretty close comparison.

---

The reference is an interesting read, but we need to consider that this is a list of items that builds dynamically based on what extensions are present from plugins etc. -- so "making tough choices" and some of the other advice is not something we can really do. These items need to be placed somewhere if an admin decides to install all of the plugins.

[alecharp]

For now it's an overflow menu. What if we made it an actual menu and only show the manage action and one or two selected ones. Others would always be in the menu, which could use the burger menu? (This is not what this pull request was targeting)

[scherler]

For me facing a 'problem' with the 'stateful' overflow menu is that in case an action provides a 'submenu' it matters whether it is in the collapsed state or the big screen, a thing that is determine by css rules, meaning I would not have the state in jelly. I am attaching a real use case of a custom plugin, where #10678 enables a dropdown

however in the collapsed state that stops working

in case we would agree on certain 'top level' menus and the rest always will collapse the implementation would change and be much cleaner, since we could use 'sub-menus' of the dropdown instead a dropdown (in collapsed state would need to be a dropdown over a dropdown which is IMHO bad ux). Further the UX in general would enhance since you always have x icons plus everything else within the burger, not depending on big vs. small screen. @janfaracik I think that @cristina-pizzagalli is right with that observation and as an implementation the above PR would work without me ATM studying how I can implement either a dropdown or a submenu.