Description: UX Rationale: Currently there is the top-level menu item "Help" that contains 10-12 sub-entries, and six of them are not about help - this is confusing and user-unfriendly, and help is a critical menu for LibreOffice to succeed. TASKS: 1. Limit the "Help" menu to the following submenus: 1.a > "LibreOffice Help" 1.b > "What's This?" 1.c > "User Guides" 1.d > "Get Help Online" 1.e > "Show Tip of the Day" 2. Add an extra UI step after clicking "Get Help Online" to confirm that the user could not find answers to what the user is looking for in "LibreOffice Help F1". Steps to Reproduce: ... Actual Results: ... Expected Results: ... Reproducible: Always User Profile Reset: No Additional Info: ...
Not a fan. The single Help menu with mix of content is functional. Splitting its content into 3 addtional main menu entries gains little and consumes screeen width for no reason.
See proposed, closely related UI/UX improvements: Develop a new bug-reporting functionality and a new top-level "Bugs" menu item in the menu bar https://bugs.documentfoundation.org/show_bug.cgi?id=142831 Make a new top-level "About" menu item in the menu bar https://bugs.documentfoundation.org/show_bug.cgi?id=142829 Make a new menu out of the globe icon ("Check for Updates") https://bugs.documentfoundation.org/show_bug.cgi?id=142828
(In reply to V Stuart Foote from comment #1) > Not a fan. The single Help menu with mix of content is functional. Splitting > its content into 3 addtional main menu entries gains little and consumes > screeen width for no reason. I disagree about gaining little and the value of screen width. Enhanced bug reporting and enhanced help UX are quite the reasons that are worth every pixel of the menu bar.
(In reply to Max L. from comment #3) > (In reply to V Stuart Foote from comment #1) > > Not a fan. The single Help menu with mix of content is functional. Splitting > > its content into 3 addtional main menu entries gains little and consumes > > screeen width for no reason. > > I disagree about gaining little and the value of screen width. Enhanced bug > reporting and enhanced help UX are quite the reasons that are worth every > pixel of the menu bar. Besides, most of the screen width at that menu bar is completely unused as of now.
Note that extensions may add top-level menu items. So as users making customizations. Screens are different, and it's incorrect to assume wide screens with multiple smaller devices like Raspberry Pi, or simply smaller laptops with UI scaling making the width not that big. I don't see a user who is confused by the current menu. I want to see a report or a question where user struggled to find something. Additionally, introduction of HUD would hopefully make finding functionality easier, and IMO the best would be not to introduce more menus (and confuse users more), but to improve HUD (e.g., by improving its results, e.g. not only matching menu names, but also keywords that could help find "Chapter Numbering" by typing "Outline", etc.) -1.
(In reply to Mike Kaganski from comment #5) > Note that extensions may add top-level menu items. So as users making > customizations. Screens are different, and it's incorrect to assume wide > screens with multiple smaller devices like Raspberry Pi, or simply smaller > laptops with UI scaling making the width not that big. > > I don't see a user who is confused by the current menu. I want to see a > report or a question where user struggled to find something. > > Additionally, introduction of HUD would hopefully make finding functionality > easier, and IMO the best would be not to introduce more menus (and confuse > users more), but to improve HUD (e.g., by improving its results, e.g. not > only matching menu names, but also keywords that could help find "Chapter > Numbering" by typing "Outline", etc.) > > -1. I made this recommendation as a user confused by the current menu, and as a user I assure you I didn't know there was a link to bug reporting in that menu (and even so, it's too convoluted for an average productivity suite user to actually report a bug). How many users use tiny (less than 13") devices to do any type of serious work and do so in work-related context? My Raspberry Pi has a HD monitor, and I can't imagine using LibreOffice to compose work of any value on a tiny breadboard display.
(In reply to Max L. from comment #6) > I made this recommendation as a user confused by the current menu, and as a > user I assure you I didn't know there was a link to bug reporting in that > menu No, as you obviously found it, could understand current set of options there, and finally file several reports. Current menu structure didn't prevent it. And it's very unlikely that we find something like "I didn't file a bug because I didn't find relevant menu entry".
*** Bug 142828 has been marked as a duplicate of this bug. ***
*** Bug 142829 has been marked as a duplicate of this bug. ***
*** Bug 142831 has been marked as a duplicate of this bug. ***
Your logic is flawed. I emailed info@documentfoundation.org who asked me to put all my recommendations into Bugzilla, which I did. If I didn't bother to waste my time to email info@documentfoundation.org and if they didn't bother to waste their time to reply and refer me to Bugzilla, we wouldn't be having this conversation here. Moreover, expecting corporate openspace workers to have the knowledge of Bugzilla and have the understanding, time, and will to register an account in order to describe and file a bug report is every bit unrealistic.
(In reply to Max L. from comment #11) > Your logic is flawed. I emailed info@documentfoundation.org who asked me to > put all my recommendations into Bugzilla, which I did. If I didn't bother to > waste my time to email info@documentfoundation.org and if they didn't bother > to waste their time to reply and refer me to Bugzilla, we wouldn't be having > this conversation here. No. LibreOffice offers to provide feedback. That's OK, and if user does not find this option, they have other ways - like you did, or - unexpectedly - on home page. What you did shows that it's all working nicely. > Moreover, expecting corporate openspace workers to have the knowledge of > Bugzilla and have the understanding, time, and will to register an account > in order to describe and file a bug report is every bit unrealistic. 1. Corporate workers are better served by professional support [1] anyway. 2. A bug report without reporter having an account is a total nonsense. If you only filed something, and then we were unable to contact you, you would be unable to try to prove your PoV. Likewise, any bug report might need a clarification, and people ask *reporter* for the details - and not having an account would make most reports just junk. Note that simply using mail would not work, since many people would use "no spam" unread mail accounts for that. [1] https://www.libreoffice.org/get-help/professional-support/
Can you please explain it to me as to what exactly is duplicate between reorganizing the Help menu and developing a new bug-reporting functionality? Develop a new bug-reporting functionality and a new top-level "Bugs" menu item in the menu bar https://bugs.documentfoundation.org/show_bug.cgi?id=142831
Additionally, you will not find a single function, which would not find its lucky user who somehow would think "it's best to put it to the top level". OTOH, some UI configurations do not have menus at all. To reiterate: it would be best to not reorganize the menu to make it longer without real benefit, but instead make HUD more prominent and functional, such as typing "support", or "bug", or "I want to report a problem" would provide the "Feedback" result from Help menu, with some description text (extended tooltip) telling that this is where one may file bugs.
(In reply to Mike Kaganski from comment #12) > (In reply to Max L. from comment #11) > > Your logic is flawed. I emailed info@documentfoundation.org who asked me to > > put all my recommendations into Bugzilla, which I did. If I didn't bother to > > waste my time to email info@documentfoundation.org and if they didn't bother > > to waste their time to reply and refer me to Bugzilla, we wouldn't be having > > this conversation here. > > No. LibreOffice offers to provide feedback. That's OK, and if user does not > find this option, they have other ways - like you did, or - unexpectedly - > on home page. What you did shows that it's all working nicely. > > > Moreover, expecting corporate openspace workers to have the knowledge of > > Bugzilla and have the understanding, time, and will to register an account > > in order to describe and file a bug report is every bit unrealistic. > > 1. Corporate workers are better served by professional support [1] anyway. You mean you expect corporate workers to open a ticket with their IT Support about a feature in LibreOffice? Any corporate worker I ever came across will do two of three following things instead - either find a workaround to get their job done on time (and the issue will never be reported to documentfoundation.org) and trash LibreOffice to their teammates and/or trash LibreOffice to their IT guys. Either way, MS Office will happily return with their licenses when called upon. I'd expect LibreOffice to take advantage of crowdsourcing its issues whenever they may be detected, but if the majority of its users are not offered the UX to easily make a difference then who cares. > 2. A bug report without reporter having an account is a total nonsense. If > you only filed something, and then we were unable to contact you, you would > be unable to try to prove your PoV. Likewise, any bug report might need a > clarification, and people ask *reporter* for the details - and not having an > account would make most reports just junk. Note that simply using mail would > not work, since many people would use "no spam" unread mail accounts for > that. But the bug reporting suggestion is described in a different bug: https://bugs.documentfoundation.org/show_bug.cgi?id=142831 > [1] https://www.libreoffice.org/get-help/professional-support/
(In reply to Mike Kaganski from comment #14) > Additionally, you will not find a single function, which would not find its > lucky user who somehow would think "it's best to put it to the top level". > OTOH, some UI configurations do not have menus at all. What mattered to me is the aggregate impact on a large user community. > > To reiterate: it would be best to not reorganize the menu to make it longer > without real benefit, but instead make HUD more prominent and functional, > such as typing "support", or "bug", or "I want to report a problem" would > provide the "Feedback" result from Help menu, with some description text > (extended tooltip) telling that this is where one may file bugs. If newbies to LibreOffice who need the Help menu and who are not IT-savvy will know to use HUD, then sure, but to me this use case sounds like an oxymoron.
> (In reply to Mike Kaganski from comment #5) > ...I didn't know there was a link to bug reporting Sounds rather as if you think the content of the help menu is inconsistent. Well, it is - and we have many bits in the main menu that might be better organized. The help menu collects all miscellaneous functions and neither renaming it to Misc nor having About, Bug reports, Updates exposed on the root level improves anything for the average user. Don't see Benjamin [1] searching for this functions or even being interested in it. And having these commands always present "in-your-face" on the root level would be rather annoying to him. Keep also in mind that some functions, at least About, are sorted into a special menu on macOS. [1] https://wiki.documentfoundation.org/Design/Guidelines/HIG_foundations#Persona
(In reply to Heiko Tietze from comment #17) > > (In reply to Mike Kaganski from comment #5) > > ...I didn't know there was a link to bug reporting > > Sounds rather as if you think the content of the help menu is inconsistent. > Well, it is - and we have many bits in the main menu that might be better > organized. The help menu collects all miscellaneous functions and neither > renaming it to Misc nor having About, Bug reports, Updates exposed on the > root level improves anything for the average user. Don't see Benjamin [1] > searching for this functions or even being interested in it. And having > these commands always present "in-your-face" on the root level would be > rather annoying to him. > > Keep also in mind that some functions, at least About, are sorted into a > special menu on macOS. > > [1] > https://wiki.documentfoundation.org/Design/Guidelines/HIG_foundations#Persona Inconsistency of menu contents is only a symptom - most top-level menu items have many diverse functionalities grouped together and I did not raise any suggestions to reorganize those. The biggest problem with the current "Help" menu is that 1. it is not conducive to the user for actively reporting bugs (Bugs), 2. it is not conducive to the user for actively using the help features (Help), 3. it is not conducive for promoting LibreOffice (About Us, etc.). The current "Help" obfuscates all of the above processes. (Effectively, this is one level above hiding those menu items from the user completely.) Most importantly, all three points above are important for driving LibreOffice adoption in all use cases and expanding LibreOffice's user base. Document Foundation is not Microsoft, but LibreOffice is a competitor of MS Office. LibreOffice has lots of features and thus probability of bugs is much higher due to more permutations of user steps. If LibreOffice does not make its users actively use Help AND actively report bugs, it won't succeed, because bugs will not be reported. It's enough for a user to encounter just a few bugs and form an ingrained negative opinion of LibreOffice that will stick as a bad reputation for very long.
Xisco made an interesting point: We often need additional information and if the ticket would be anonymous this wont work.
Had this topic on the agenda for the design meeting. No further opinion but mine: The root level items should organize the menu and not provide access to seldom used function. It's a clear -1 for splitting the help menu's content in two or three menus. Introducing an inbuilt bugtracking feature might be interesting. I still believe this is nothing that can be done en passant but worth a discussion anyway. Please re/open a dedicated ticket for this idea.