Replace Hamburger Icon with Chevron Icon for sidebar toggle functionality.

[nenb]

Is your feature request related to a problem? Please describe.

I would like to replace the 'Hamburger Icon' for sidebar toggling with a 'Chevron Icon' (see screenshots below) for the panel core templates.

TL;DR The Chevron Icon indicates to users that it would open an accordion in place. The Hamburger Icon indicates to users that it would open a new page.

Details The Hamburger Icon is typically used on mobile devices for expandable navigation menus, whereas the Chevron Icon aligns better with the functionality of a task-oriented/dashboard site on the Desktop. It clearly indicates the direction of collapse or expansion (left or right), akin to accordion signifiers, making it more intuitive for controlling sidebars that contain a number of tasks. This approach reduces visual complexity and helps users focus on the main content, such as data visualizations and tables.

Describe the solution you'd like

This could involve some additions to the core templates in panel. For example, for the FastList template (fast_list_template.html):

{% if nav or sidebar_footer %}
<span onclick="{{ 'openNav()' if collapsed_sidebar else 'closeNav()' }}" id="sidebar-button">
&laquo;
</span>

and

function openNav() {
  document.getElementById("sidebar").classList.remove("hidden");
  document.getElementById('sidebar-button').innerHTML = '&laquo';
  document.getElementById("sidebar-button").onclick = closeNav;
}

function closeNav() {
  document.getElementById("sidebar").classList.add("hidden");
  document.getElementById('sidebar-button').innerHTML = '»';
  document.getElementById("sidebar-button").onclick = openNav;
}

If this seems reasonable, I'm happy to contribute.

Describe alternatives you've considered

Overriding the default CSS rules and patching the HTML. It's messy though.

Additional context

[trallard]

Thanks for opening this @nenb, adding a bit more context.

The Hamburger Icon is typically used on mobile devices

The Chevron Icon indicates to users that it would open an accordion in place. The Hamburger Icon indicates to users that it would open a new page.

A slight nuance is that hamburger menus are a mobile-first approach to "hide" site navigation elements. Thus, the expectation is that when a user clicks on a Navigation menu (or hamburger menu) item, a new page will open. At the same time, accordions open a component in place (no page change). This is a known pattern, and cognitively, users might be anticipating a default behaviour by seeing a hamburger menu, and the actual behaviour is entirely different (collapse the sidebar).

There is also another issue that needs to be mentioned here. The placement of the hamburger menu is awkward. This is placed on the navbar next to the panel app title. Visually, this makes it seem like it belongs to the navbar and gives the impression that it would expand a menu/submenu within this context (a.k.a proximity principle) (yellow rectangle in the image below).

Since this component (collapse sidebar button) intends to modify the sidebar display, it makes more sense to have this within the sidebar area (purple rectangle in the image above). It could be placed at the top or bottom of the sidebar (see green rectangles in image below)

This visually indicates that it is part of the sidebar, thus will affect the sidebar and its components only. It also comes with the advantage of extra space, so instead of having just a chevron << the button could have more descriptive text such as << Collapse sidebar >> Expand sidebar making it more usable

[philippjfr]

Thank you both, all good feedback. Just so I understand what is being proposed:

Since this component (collapse sidebar button) intends to modify the sidebar display, it makes more sense to have this within the sidebar area (purple rectangle in the image above)

Can you explain what it would mean to place the button in the sidebar area when it is collapsed and therefore by definition not visible?

[trallard]

That will mean that the sidebar cannot be entirely removed, there might be a thin collapsed sidebar containing the icon.

I can ask one of our designers to create a quick mock or two

[smeragoel]

This is a quick mockup of the proposed functionality:

https://github.com/holoviz/panel/assets/98317216/968df939-fdb0-48b1-a235-6f545f1bba82

[trallard]

In case this change/feature is of interest and the team is happy to have it implemented we'd be glad to make the corresponding contribution.

[jbednar]

This all sounds like it's moving in a good direction, but I do have a concern about retaining a small sidebar when collapsed. Above I think the focus is on a full-page templated app, and maybe that case can have a completely different solution, but we very often present the same data both as a full-page web app and in a cell in a Jupyter notebook or embedded into a web page where there is only a narrow space available. We also have cases where the widgets in the sidebar are truly optional and only for advanced or optional usage, where we want the full space to be available (with sidebar initially collapsed) while also providing some way to access the sidebar. E.g. see https://hvplot.holoviz.org/user_guide/Explorer.html#supported-data-inputs , where you can see that the widgets dominate the screen, and even a small sidebar would mess up the formatting and prevent this explorer from being the default way of displaying data. In those cases, accessing the controls would be a bonus extra step, not the main point, and so they have to not detract from the main point (the non-sidebar content).

For these reasons, maybe the chevron could not occupy a vertical column so that it takes up space even when minimized, but instead appear in the same location as above but overlaid on the rest of the content, without taking up any horizontal space? I think that approach would mean that adding a sidebar to a template or plot would take almost nothing away from the experience before the sidebar, while still being intuitive for proximity.

[jbednar]

For a counter example, I happened to notice that Chrome's PDF viewer's hamburger menu acts just like Panel's current support:

So we at least aren't the only ones using this UI style...

[MarcSkovMadsen]

It's the material design way of doing it.