At the moment, our menus have three kinds of items (or rows): 1. Commands 2. Submenus 3. Separators I suggest that we introduce a fourth kind, which combines (1.) and (2.): A menu item which is itself a clickable, executable, command, but whose side has the arrow which would expand into a sub-menu - but only if you click that part of the menu row would you get the side-menu expanded. This would be the equivalent of a toolbar menubutton: You can just click it for the default action, or expand it by clicking the arrow on the side (or the bottom) to get options, or variants of the action. My motivation for suggesting this is that I notice multiple cases of a set of related commands (or commands-and-submenus), which is big enough to merit having a submenu, but one of them is more common than all the others, so much so that you don't want to put it in a submenu. Examples: Writer's File menu. We have: Save, Save As..., Save Remote..., Save a Copy..., Save all that's more than enough to put in a submenu, especially as we're about to get two new items on the File.. menu: Compare Documents and Merge Documents (see bug 167404). But - obviously, we can't relegate _Save_ to a submenu, right? That would be quite inconvenient. So - let's have a Save command-cum-submenu then. We would save 4 spots on the File menu and not lose the easy access to the common Save action. Another example: Writer, File menu, New... submenu. Here, we've already put stuff in a submenu. But - the more common New action is a new empty document, without a template, of the module we're in. Right now, this requires Three clicks: File > New > Text Document. If we made 'New' into a command-with-submenu, that would become two clicks. A third example, similar to the second: Writer, Edit menu, Paste Special. The common action is paste as unformatted text - which would be the command in a command-with-submenu row. (A more complex behavior would be setting the command to the last-used submenu command - in which case we would get the last kind of special paste used, accessible with just two clicks; but let's not go that far with this bug).
I would be rather efficient, if the implementation being right. However I haven't seen this seen implemented it any application, as far I'm aware. So probably quite unconventional? Also probably indirectly fixed by the ribbon layout for quite a group of users. The ribbon of LibreOffice is obviously another hot debated topic and a different can of worms.
(In reply to Telesto from comment #1) > Also probably indirectly fixed by the ribbon layout for quite a group of > users. Different UI modes, different widgets, different challenges and ideas. Well, mostly. This suggestion is for people who use the menus and toolbars and, hopefully, like them :-) > I would be rather efficient, if the implementation being right. However I > haven't seen this seen implemented it any application, as far I'm aware. So > probably quite unconventional? I have also not seen this _exact_ widget implemented before, that's true. But think about our styles sidebar, in hierarchical mode: Each row has the main part, which is the name of the style: Double-click it, and you apply it; but it also has the arrow indicating the open/closed state of the descendent styles hierarchy - a separate part of the row, clickable for different effect. True, it's not a menu, but it's already rather similar to what I suggest. and again, the concept of splitting a menu-opening clickable arrow/button-with-arrow from the main function of a widget is implemented already in toolbar menubuttons. I suppose that if this is considered too adventurous, it could be either an opt-in, or another alternative UI mode.
(In reply to Eyal Rozenberg from comment #2) > Different UI modes, different widgets, different challenges and ideas. Well, > mostly. This suggestion is for people who use the menus and toolbars and, > hopefully, like them :-) Nothing against Menu's. Ribbon isn't my cup of tea either, but might be a generational thing too. If you don't know anything else, the Ribbon feels natural. So some would say focus the limited resources on Ribbon. > I have also not seen this _exact_ widget implemented before, that's true. > But think about our styles sidebar, in hierarchical mode: Each row has the > main part, which is the name of the style: Double-click it, and you apply > it; but it also has the arrow indicating the open/closed state of the > descendent styles hierarchy - a separate part of the row, clickable for > different effect. True, it's not a menu, but it's already rather similar to > what I suggest. A) The menu's are surely hitting the limits of the sensible with the large amount of entry's. It becomes less productive having to read through all entry's and large distances to travel with the mouse to click certain entry. It feels a bit overwhelming at times B) I spoke to soon. LibreOffice does have a case which can do this already in some sense. File -> New opens a new document without selecting the type of document. Problem is more the inconsistency. I most cases it doesn't do anything C) Microsoft had the same feeling amount menu's containing to many entry's by default as it seems. The old MSO approach - before Ribbon - was showing the most used items or something in that direction. A video from YT https://www.youtube.com/watch?v=_IE4LN3Gyas. Not a 100% succes either
(In reply to Eyal Rozenberg from comment #0) > I suggest that we introduce ... a menu item which is itself a clickable, > executable, command, but whose side has the arrow... Strongly against inventing new basic controls. The main menu is what it is, and has no split button capabilities as known from toolbar buttons (eg. the unordered list either applying the default or showing some options). Most users wont understand this overly complex interaction, being afraid to click Save in order to find the non-visible SaveAs, for example. => WF
(In reply to Heiko Tietze from comment #4) > Most users wont understand this overly complex interaction, being afraid to > click Save in order to find the non-visible SaveAs, for example. => WF That is actually a good point. Even with user understanding, we might be deterring people from accessing the submenu for fear of choosing the default action by mistake. So, relsolving WF I guess :-( I guess we'll have to think of other ways for dealing with overly long menus. (In reply to Telesto from comment #3) > Nothing against Menu's. Ribbon isn't my cup of tea either, but might be a > generational thing too. If you don't know anything else, the Ribbon feels > natural. It really doesn't. It only "feels natural" if you're used to MS Office' ribbon. > So some would say focus the limited resources on Ribbon. Our bug reports are not the allocation of resources. Here, we say what can and should be done, not when or in what order. (We have an importance field for that, although that's not used.) > B) I spoke to soon. LibreOffice does have a case which can do this already > in some sense. File -> New opens a new document without selecting the type > of document. Actually - no, that's not the behavior of File > New ; it opens a submenu, and that's it. > > C) Microsoft had the same feeling amount menu's containing to many entry's > by default as it seems. The old MSO approach - before Ribbon - was showing > the most used items or something in that direction. A video from YT > https://www.youtube.com/watch?v=_IE4LN3Gyas. Not a 100% succes either I remember that very well. It was a terrible idea and everyone I ever talked to about this was complaining about how the menus get jumbled... that would not be a direction I would take.
(In reply to Eyal Rozenberg from comment #5) > > So some would say focus the limited resources on Ribbon. > > Our bug reports are not the allocation of resources. Here, we say what can > and should be done, not when or in what order. (We have an importance field > for that, although that's not used.) The resource allocation is implicitly assessed in any enhancement request, IMHO. Not consistently, though. The list of possible enhancements is in principle endless. Maybe even as expert setting, if we want to be geeky. You need some demarcation criterium. Is it useful having a bug/enhancement idea's floating around as nice to have but realistically not gonna happen in lets say next 50 years. At which point it might be superfluous after all. Everything might be done by AI or different UI design because everybody using VR. There is already 'lack' of direction regarding user interface styles. LibreOffice ships various user interface styles; giving users a choice (upside). The downside: * lack of focus resulting we do all of them, but most are not feature complete/ polished or maintained/ tested. So don't meet end-user expectations (based on comparison with other apps) * complexity; having multiple UI's requires a lot more documentation, testing, maintaining etc * impurity's in design. So a flaw in Tabbed UI being presented as non-issue (trivial) because other UI elements cover this aspect (sidebar/menubar). You can't deny, but it's not the point. If opt for Ribbon you want the complete experience. So might be trivial functional, major from point of a proper Ribbon experience. I would be unable to prioritize it. Which perspective should be preferred? Luckily, prioritization doesn't matter around here anyhow as it doesn't move any faster generally speaking. My default lead time maybe 10 years from now; and even that is rather optimistic * Multi interface styles generate an additional conundrum regarding prioritization. So the Ribbon User Interface is (also) developed as replacement for crowded menu's. So improving the menu is a waste of effort from Ribbon/Tabbed UI users perspective. The likely want time (resources) being spend on making the Ribbon shine > > B) I spoke to soon. LibreOffice does have a case which can do this already > > in some sense. File -> New opens a new document without selecting the type > > of document. > > Actually - no, that's not the behavior of File > New ; it opens a submenu, > and that's it. I can Left Click "New" in the main drop down, with navigating the submenu to open a new Writer document (assuming using Writer). At least on macOS
(In reply to Telesto from comment #6) > > Actually - no, that's not the behavior of File > New ; it opens a submenu, > > and that's it. > > I can Left Click "New" in the main drop down, with navigating the submenu to > open a new Writer document (assuming using Writer). At least on macOS Are you sure you're not just releasing the mouse and letting the first submenu item be selected? ... Well, maybe it's MacOS-specific behavior. On Linux (and Windows IIANM), it doesn't work that way. But if MacOS really has this kind of widget, maybe it's less preposterous to also have it on other platforms. Still, let this stay WONTFIX unless more people start clamoring for this. > (In reply to Eyal Rozenberg from comment #5) > The resource allocation is implicitly assessed in any enhancement request, > IMHO. Well, it's not assessed by the people making the request; and it's not assessed - for the most part - in design meetings discussing enhancement requests. So these requests definitely become NEW with nobody committing any resources, or assessing resource availability, for those enhancements. > Not consistently, though. The list of possible enhancements is in > principle endless. Maybe even as expert setting, if we want to be geeky. You > need some demarcation criterium. Well, one demarcation criterion is the willingness to request the enhancement. That already prevents totally-frivolous ones. And the next criterion is convincing a QA person, or barring that the design meeting participants, that it serves a relevant use case and does not better fit in an extension. > Is it useful having a bug/enhancement > idea's floating around as nice to have but realistically not gonna happen in > lets say next 50 years. I don't know about LO, about in Mozilla, there are _critical_ enhancement requests that have been waiting around for nearly 30 years now. So, the fact that something might not happen for several decades does not mean it should not be on file. Moreover - it's almost impossible to tell whether an enhancement request deemed useful would be picked up by someone or not. These things surprise you. > At which point it might be superfluous after all. > Everything might be done by AI or different UI design because everybody > using VR. 40 years ago you already had a mostly-similar desktop environment to what we have today, if we focus on the basics. > There is already 'lack' of direction regarding user interface styles. Semi-agreed, but - that does not mean we should prune and avoid ideas at the bug tracker level; rather, that should happen through the policy-making mechanisms and resource-allocation-coordination mechanisms. We lack those, unfortunately: The ESC has formally stated it does not actually steer the project; and the TDF board of directors... well, let's say it has its problems. > * complexity; having multiple UI's requires a lot more documentation, > testing, maintaining etc Unfortunately, that hasn't happened... someone just gave the green light to us shipping with 7 UI modes. The documentation still assumes menus+toolbars IIANM. > * impurity's in design. So a flaw in Tabbed UI being presented as non-issue > (trivial) because other UI elements cover this aspect (sidebar/menubar). That's very interesting! And quite sad. But we're really getting off topic here... I want to encourage you to maybe write something up, either to send on the design mailing list, or to present at a conference, or even just to propose a discussion in one of the design meetings, about these matters.
Created attachment 203711 [details] Screencast A so so screencast, QuickTime doesn't want to record the menubar, but it shows clicking new opening a new window