[Suggestion] Turn Sidebar/Hamburger menu into traditional horizontal menu on desktop
Open, WishlistPublic

Description

I'm sorry if I'm posting this in the wrong place, or if this isn't the place at all. But I want to propose a suggestion. Feel free to remove this if I'm in the wrong place. :)

My main gripe with the Kirigami framework is that while it provides a typical and appropriate interface on devices with small screens, it never really feels at home on desktop, mostly just feeling like a stretched-out phone app. The main thing I am missing is a classic horizontal menu bar, with clear text to indicate each section and a dropdown with icons and text for each alternative. To me there is no more user-friendly and obvious way to present a large amount of functions. A toolbar with text next to icons works decent for a few options, but not so much when they are many, leading to many functions getting hidden deeper and deeper down between more and more clicks. It's usually neither userfriendly or accessible. Even if the sidebar is displayed at all times, it's less space-efficient and often still requires switching "back and forth" between various views.

So I was thinking, how about if it worked like on most webpages instead, where all options hidden under the hamburger menu on mobile "folds out" into a traditional horizontal menu once there is enough horisontal space? One vertical and one horizontal like a typical webpage navbar: https://www.w3schools.com/css/css_navbar.asp

It works perfect for pretty much all of the internet, and it should be easy to do submenus and such too. (A clear example can be found here: https://www.kadencewp.com or here: https://pressmaximum.com/customify/?builder=elementor&demo=customify-2018)

Imerion created this task.Jan 18 2021, 1:37 PM
Imerion triaged this task as Wishlist priority.

For suggestions and wishes there is a bit of a blurry line between filing a bug report and starting a discussion here.
What you are writing might be better suited as a bug report to Kirigami but I am not certain. In any case I'll answer here because you are talking about a topic I am currently working on.

The main thing I am missing is a classic horizontal menu bar […] To me there is no more user-friendly and obvious way to present a large amount of functions. A toolbar with text next to icons works decent for a few options, but not so much when they are many

Agreed. But this is also why it doesn't make sense for all applications which use a hamburger menu to show a menu bar instead on desktop. Examples within KDE include Dolphin, System Settings, Spectacle. These applications have in common that users don't need to access hamburger menu actions for basic use. So changing it "into a traditional horizontal menu once there is enough horizontal space" isn't always desirable. My opinion is that we should choose sane defaults (hamburger menu or menu bar?) and then allow users to switch between them but only if there might be an advantage to that.

For this very reason I have been working on such a switchable hamburger menu which can be found here: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/25

But this component is for QWidgets and not for Kirigami. I do believe the same arguments apply to Kirigami as well but that's not a project I have contributed to yet and it's contributors might possibly see that differently.

Thanks for your answer! That project does sound smart and I really appreciate you are working on something like this!

But have I understood correctly that your suggestion can switch between both a hamburger menu, a toolbar and/or a menubar? You mention Dolphin as an application where a menu bar would not make sense, but for me the menu bar in Dolphin is really important - there are way too many functions I need to access quickly and smoothly. They would not fit in the toolbar and would not be as accessible in a hamburger menu (due to added clicks, less discoverability, deeper Z-level, etc). Everyone I know who runs KDE has the menu bar active despite this not being the default setting for Dolphin, so I really think it's important to have it in such complect apps, at least as an option. I agree things that are "only" lists, such as System Settings or very simple programs like Spectacle doesn't really need them though.

Speaking generally, there are several accessability gains with a classic menubar. I work a lot with people suffering from aphasia, and for many of them having text-based drop-down menus (and text next to icons in toolbars) can mean the difference between being able to use an application at all or not, simply because the text so clearly signals the category or action. Anything that is just an icon or that is hidden from view is simply much more forgettable and harder to "connect" to actions.

But have I understood correctly that your suggestion can switch between both a hamburger menu, a toolbar and/or a menubar?

No, the hamburger menu button I implemented is only meant to substitute the menu bar if the menu bar is hidden for whatever reason. The button can be put anywhere in the application but it's most common use is to put it on the toolbar. It's a more feature-rich version of the current hamburger menu in Dolphin.

Unrelated to that, menu bars and toolbars can already be hidden by users in many KDE applications. So if someone hides the menu bar, my hamburger menu button should show up somewhere instead of leaving users without any menu at all.

You mention Dolphin as an application where a menu bar would not make sense

I said "users don't need to access hamburger menu actions for basic use" of Dolphin. I absolutely believe that for many advanced and not so advanced users the menu bar is more useful in Dolphin than a hamburger button. I actually added a sub-menu to my implementation of the hamburger menu paradigm so users can discover the additional features of the menu bar more easily. You can see it here (For 73 more actions > Show Menubar): https://invent.kde.org/frameworks/kconfigwidgets/uploads/16a6cbe5d477b4ffdd45a7d4c4ca4ace/2021-01-01_18-43-14.mp4 I think this will make it more likely that users switch to the menu bar if that is advantageous for their specific use of the software.

Anything that is just an icon or that is hidden from view

From what I know KDE contributors are normally aware of problems with this and try to avoid it.

Speaking generally, there are several accessability gains with a classic menubar.

I agree and I am not aware of someone in KDE who wants to abandon the menu bar paradigm. Some of the KDE applications that don't currently have one could probably use one but there is always room for improvement. If you are worried about the sentiment towards menu bars among Krigiami contributors, I would encourage you to ask them directly: https://techbase.kde.org/Kirigami#Get_in_Touch

If you are aware of a specific application that you think really needs a menu bar it maybe makes sense to file a bug report for that application in which you explain why it should be added: https://bugs.kde.org/

If you want some more immediate feedback about your ideas it might also make sense to ask for it in the Visual Design Group chat room which is quite active. Links to the the chat room are here: https://community.kde.org/Get_Involved/design#Communication_and_Workflow. This is also a great place to get started if you want to share your ideas of how KDE software can be made more accessible for users with aphasia. From what I gathered KDE software is currently not as accessible as we'd like it to be so your experiences in this regard might be helpful.

No, the hamburger menu button I implemented is only meant to substitute the menu bar if the menu bar is hidden for whatever reason. The button can be put anywhere in the application but it's most common use is to put it on the toolbar. It's a more feature-rich version of the current hamburger menu in Dolphin.

Unrelated to that, menu bars and toolbars can already be hidden by users in many KDE applications. So if someone hides the menu bar, my hamburger menu button should show up somewhere instead of leaving users without any menu at all.

Ah, I see! So if an application uses/has a menubar but the user wants a hamburger menu this takes care of that. Smart!

I said "users don't need to access hamburger menu actions for basic use" of Dolphin. I absolutely believe that for many advanced and not so advanced users the menu bar is more useful in Dolphin than a hamburger button. I actually added a sub-menu to my implementation of the hamburger menu paradigm so users can discover the additional features of the menu bar more easily. You can see it here (For 73 more actions > Show Menubar): https://invent.kde.org/frameworks/kconfigwidgets/uploads/16a6cbe5d477b4ffdd45a7d4c4ca4ace/2021-01-01_18-43-14.mp4 I think this will make it more likely that users switch to the menu bar if that is advantageous for their specific use of the software.

Ah, now I understand. I looked through the thread but didn't really understand what options ended up where. Again, that sounds like a smart solution!

From what I know KDE contributors are normally aware of problems with this and try to avoid it.

Indeed, that is one of the reasons KDE appealed to me so. There are lots of awareness of different users needs and the importance of customization. I am not worried about that at all - this project is like a dream come true compared to pretty much any other available desktop UI. :D

I agree and I am not aware of someone in KDE who wants to abandon the menu bar paradigm. Some of the KDE applications that don't currently have one could probably use one but there is always room for improvement. If you are worried about the sentiment towards menu bars among Krigiami contributors, I would encourage you to ask them directly: https://techbase.kde.org/Kirigami#Get_in_Touch

As above, no doubt about that either. I think the reason for this post was because I was worried the more frequent use of Kirigami, QTQuick, convergent apps, etc would "move development away" from menu bars on desktop. But as you mention, there is probably no reason to believe so. :)

If you are aware of a specific application that you think really needs a menu bar it maybe makes sense to file a bug report for that application in which you explain why it should be added: https://bugs.kde.org/

If you want some more immediate feedback about your ideas it might also make sense to ask for it in the Visual Design Group chat room which is quite active. Links to the the chat room are here: https://community.kde.org/Get_Involved/design#Communication_and_Workflow. This is also a great place to get started if you want to share your ideas of how KDE software can be made more accessible for users with aphasia. From what I gathered KDE software is currently not as accessible as we'd like it to be so your experiences in this regard might be helpful.

I'm not really fond of chats, which is one of the reasons I posted here. But your suggestion is good. I will definitely help out by filing a bug/suggestion in case something specific comes up. Again, there is nothing that comes close to KDE for the groups of people I'm working with accessability wise.

Also, thanks again for taking this time to answer my questions! I hope I'm not coming of as rude, it's just that these things are important to me so I want to stress that importance. ;)
Best wishes with your work on the switchable menu!

this project is like a dream come true compared to pretty much any other available desktop UI. :D

True 😌

I was worried the more frequent use of Kirigami, QTQuick, convergent apps, etc would "move development away" from menu bars on desktop. But as you mention, there is probably no reason to believe so. :)

Probably not but I also try to stay vigilant about these changes so I understand your concern.

Again, there is nothing that comes close to KDE for the groups of people I'm working with accessability wise.

That's great! At least for these specific kinds of impairments we seem to do a good job then.

I hope I'm not coming of as rude, it's just that these things are important to me so I want to stress that importance. ;)

Don't worry I think your current way of contributing to KDE with comments about what is important to you is helpful for KDE. You don't need to be in the loop about everything that is going on. Constructive feedback and questions are appreciated.

Also, thanks again for taking this time to answer my questions!

You're welcome! It's reassuring to know that you didn't have any immediate concerns about what I am working on. ^^ Sometimes it is difficult to get feedback on things before they are released.

Best wishes with your work on the switchable menu!

Thanks!