Description: UX Rationale: Currently there is Help > Send Feedback > Create a bug report - this is too many layers of hiding bug reporting. Moreover, a vast majority of LibreOffice users have never heard the words "bug report", so this will not generate the desired bug-reporting behavior on LibreOffice's intended user base. If users are important to LibreOffice, so are the bugs they report! TASKS: 1. Add a top-level "Bugs" menu entry to the right of "Help" as a continuation of the top-level menu of LibreOffice. 2. Move the following submenu item here: "Help" > "Send Feedback" so that it serves as a placeholder while the following new features are being worked on - "Catch a Bug" and "View My Bugs" (when these are released, deprecate "Send Feedback"). 3. Add two sub-entries to the new "Bugs" menu: 3.a > "Catch a Bug" 3.b > "View My Bugs" 4. At the left end of the upper row of buttons, add a by-default-visible button with a Ladybug icon and tooltip text "Catch a Bug" (same action as "Catch a Bug" in the top "Bugs" menu - to provide one more UI entry point). 5. For "Catch a Bug", keep the bug report creation inside the LibreOffice UI, for example a separate window, without redirecting to any website. 6. Consider using an API to get the report created on https://bugs.documentfoundation.org/. 7. When the user submits a "Catch a Bug" report through the LibreOffice UI window, the unique numeric ID of the bug is generated as usual and the full-path link to the new bug report is added to the "View My Bugs" menu. 8. In the bug-submitting UI of "Catch a Bug", notify the user in UI text that the data the user is submitting is anonymous - no personal data is needed from the user, the unique and automatically generated bug id will be most important to all. 9. Make all the information from the "About LibreOffice" window used, displayed (for transparency toward the user), and submitted as automatically added, non-removable, uneditable metadata for the bug report. 10. Make the LibreOffice application type (Writer), in other words which application from the LibreOffice suite, get automatically added to the body of the report. 11. Make the LibreOffice application copy the history into this report of a (configurable for the future) recent number of operations that appear in the Undo menu. Remove (to anonymize) all text that appears as part of any recent operation that involves text manipulation (example: "Undo: Typing "abcdefgh""). This history (along with the LibreOffice version details in the previous point here) must be visible (as has been copied) to the user in the bug report filling window of LibreOffice when the user is checking the contents of the bug report before clicking Send. 12. Reuse the code from LibreOffice's feature "Help" > "What's This?" as part of LibreOffice's internal workflow to enable the user to point and click and thus have the relevant feature(s) entered into the bug report without the user having to name these features. 13. Make all bug reports submitted from this installed LibreOffice instance appear as a list of links in "View My Bugs" by clicking which the user can revisit the unique bug report page on https://bugs.documentfoundation.org/ whenever wishing to check for progress or outcome or respond by providing more details in the bug page. 14. Reuse the "Recent Documents" UI elements from the "File" menu (where each recent document's file name is displayed) in "View My Bugs" as links to the user-opened bugs. 15. Make each bug report's "Summary" line text appear as the menu label over each bug link in "View My Bugs". This is the bug report "Summary" line text that the user fills when creating the bug report within the LibreOffice UI and that will appear as the "Summary" line on the unique bug page on https://bugs.documentfoundation.org/. 16. In "View My Bugs", add a way for the user to easily remove any of the bug entries (links) any time (the respective bug report pages on https://bugs.documentfoundation.org/ will continue to exist independently). Initially, copy the "Clear list" functionality from "Recent Documents"; plan to add functionality to remove specific items (as opposed to all in "Clear list"). 17. In "View My Bugs", add a functionality placeholder for an API to check for updates on the bug page on https://bugs.documentfoundation.org/ for each bug link in the "View My Bugs" menu every time this LibreOffice application is started. Whenever there is an update on the bug page, a UI marker appears for each bug (this can be accomplished by a symbol prepended to the bug label in the menu or a change to the color of the bug label text in the menu. This functionality will enable https://bugs.documentfoundation.org/ to keep in touch (if needed) with this particular user of LibreOffice as well as to inform the user of any progress on any bug that this user reported. Steps to Reproduce: ... Actual Results: ... Expected Results: ... Reproducible: Always User Profile Reset: No Additional Info: ...
See proposed, closely related UI/UX improvements: Split the current "Help" menu into three separate top-level menus (instead of one) to separate help content, bug-reporting content, and 'about' content. https://bugs.documentfoundation.org/show_bug.cgi?id=142830 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
Not a fan, "bikesheding" churn with no functional improvement. -1
(In reply to V Stuart Foote from comment #2) > Not a fan, "bikesheding" churn with no functional improvement. > > -1 OK, I will spend my time more wisely elsewhere than on https://bugs.documentfoundation.org/
(In reply to Max L. from comment #3) > (In reply to V Stuart Foote from comment #2) > > Not a fan, "bikesheding" churn with no functional improvement. > > > > -1 > > OK, I will spend my time more wisely elsewhere than on > https://bugs.documentfoundation.org/ :) Well, if bug reporting is perfect as is, I will not report any bugs as the user.
*** This bug has been marked as a duplicate of bug 142830 ***
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
(In reply to Max L. from comment #0) > ...Help > Send Feedback > Create a bug report - this is too many layers of hiding bug reporting Send Feedback is easy to find and to understand for users who don't know bug reporting. Of course it's not if you look for a menu item "Report bugs" expecting a link to Bugzilla. > 2. Move the following submenu item here... This might be the reason for the duplicate. > 3. Add two sub-entries to the new "Bugs" menu: > 3.a > "Catch a Bug" > 3.b > "View My Bugs" To see your bugs you need to know the account. Sounds like a security/privacy topic if added to the application. > 4. At the left end of the upper row of buttons... The toolbar? You make it very prominent while we actually try to produce a rock solid application ;-). Seriously, I don't see bug reporting as part of the office work and would not make access as easy as possible. > 5. For "Catch a Bug", keep the bug report creation inside the LibreOffice... > 6. Consider using an API to get the report > 7. ...unique numeric ID of the bug ... is added to the "View My Bugs" menu. > 8. In the bug-submitting ...the user is submitting is anonymous... > 9. "About LibreOffice" (info)... submitted as automatically > 10. application type (Writer)... automatically added > 11. ...copy the history of ...Undo menu. ... anonymize all text > 12. Reuse ... "What's This?" to enable the user to point and click... > 13. Make all bug reports submitted ... appear as a list of links Bug reporting is an art beyond point and click. It's hard to summarize the use case so everyone understands the intention, to describe in a concise but complete way, and eventually to transparently track the patch, to organize the work, to prioritize by requests etc. Your basic idea is to simplify the process, to embed the reporting capability in the program, and to use Bugzilla just as backend and for the developers. Have you seen any application that works like this? I think for good reasons not. Besides the menu organization, it is ultimately a QA topic whether this enhancement is needed or not. My take is WF.
(In reply to Heiko Tietze from comment #7) > (In reply to Max L. from comment #0) > > ...Help > Send Feedback > Create a bug report - this is too many layers of hiding bug reporting > > Send Feedback is easy to find and to understand for users who don't know bug > reporting. :) Try it yourself and click it - Send Feedback looks ok in the menu, but once you click it you end up on a web page with several diverse links, and two of them, "Create a bug report" and "File an enhancement request", take the user to the Bugzilla login page (What's that?), which is not an inviting place to proceed with such labels as "Bugzilla – Log in to Bugzilla" and "Bugzilla needs a legitimate login and password to continue". The moment the user leaves that Bugzilla page, you've just lost a conversion, and the bug is left unreported. > Of course it's not if you look for a menu item "Report bugs" > expecting a link to Bugzilla. I'd say the opposite - I wrote down the tasks above with the express intention of making it as simple as possible to report a bug without actually knowing how to report a bug by a user who never reported a bug in their entire life. This is the rationale for making the user fill the bug report in an internal UI as opposed to Bugzilla. I argue that Bugzilla represents too many hurdles to getting a bug reported by individuals who are neither paid nor enthusiastic to do so.
(In reply to Heiko Tietze from comment #7) > (In reply to Max L. from comment #0) > > ...Help > Send Feedback > Create a bug report - this is too many layers of > > > 3. Add two sub-entries to the new "Bugs" menu: > > 3.a > "Catch a Bug" > > 3.b > "View My Bugs" > > To see your bugs you need to know the account. No, you don't need to know the account nor have an account. There is enough or can be enough data on the user's LibreOffice installation for e.g. Bugzilla role backend to confirm that the next user comment is from the same machine. Only the user who sent the bug report will have the link to that specific page (until the user removes that link). So anybody can visit that page if they have nothing better to do with their time. There will be only application info, so identity theft of the user's identity will lead to only the bug being unresolved. The locally installed LibreOffice application can check for changes in the relevant page content when the application starts and flag it in the menu. If/when the user removes the link, the LibreOffice application has nothing to check for changes next time it starts.
(In reply to Heiko Tietze from comment #7) > (In reply to Max L. from comment #0) > To see your bugs you need to know the account. Sounds like a > security/privacy topic if added to the application. I am well aware of that, but it is my belief that LibreOffice has to reinvent how it collects bug data, because the Document Foundation can neither afford a qualified QE workforce nor scale down the total number of application features that in combination produce bugs. Such features as these (copied from the description) can be steps in that direction - if you start receiving bug reports with patterns of same features malfunctioning, you have much more data at your disposal while still missing the QE workforce. It's not automation, it's not machine learning, it's about finding a clever way of getting the needed data when bugs start to appear: 11. Make the LibreOffice application copy the history into this report of a (configurable for the future) recent number of operations that appear in the Undo menu. Remove (to anonymize) all text that appears as part of any recent operation that involves text manipulation (example: "Undo: Typing "abcdefgh""). This history (along with the LibreOffice version details in the previous point here) must be visible (as has been copied) to the user in the bug report filling window of LibreOffice when the user is checking the contents of the bug report before clicking Send. 12. Reuse the code from LibreOffice's feature "Help" > "What's This?" as part of LibreOffice's internal workflow to enable the user to point and click and thus have the relevant feature(s) entered into the bug report without the user having to name these features.
(In reply to Max L. from comment #10) > (In reply to Heiko Tietze from comment #7) > > (In reply to Max L. from comment #0) > > To see your bugs you need to know the account. Sounds like a > > security/privacy topic if added to the application. > I am well aware of that, but it is my belief that LibreOffice has to > reinvent how it collects bug data, because the Document Foundation can > neither afford a qualified QE workforce nor scale down the total number of > application features that in combination produce bugs. > > Such features as these (copied from the description) can be steps in that > direction - if you start receiving bug reports with patterns of same > features malfunctioning, you have much more data at your disposal while > still missing the QE workforce. It's not automation, it's not machine > learning, it's about finding a clever way of getting the needed data when > bugs start to appear: > > 11. Make the LibreOffice application copy the history into this report of a > (configurable for the future) recent number of operations that appear in the > Undo menu. Remove (to anonymize) all text that appears as part of any recent > operation that involves text manipulation (example: "Undo: Typing > "abcdefgh""). This history (along with the LibreOffice version details in > the previous point here) must be visible (as has been copied) to the user in > the bug report filling window of LibreOffice when the user is checking the > contents of the bug report before clicking Send. > 12. Reuse the code from LibreOffice's feature "Help" > "What's This?" as > part of LibreOffice's internal workflow to enable the user to point and > click and thus have the relevant feature(s) entered into the bug report > without the user having to name these features. When you have the data, you can filter it and recognize the patterns - like what is currently done with reported crashes of LibreOffice. BTW, the above was in response to: (In reply to Heiko Tietze from comment #7) "Bug reporting is an art beyond point and click. It's hard to summarize the use case so everyone understands the intention, to describe in a concise but complete way, and eventually to transparently track the patch, to organize the work, to prioritize by requests etc."
(In reply to Max L. from comment #11) > When you have the data, you can filter it and recognize the patterns - like > what is currently done with reported crashes of LibreOffice. We have this for crashes, see https://help.libreoffice.org/latest/lo/text/shared/guide/error_report.html and https://crashreport.libreoffice.org/stats/ But sure, if thousands of users click somewhere to point at some usability flaw we could analyze this. Would be nice to have but is wishful thinking, I guess.
I completely disagree with comments like there has to be a Bugzilla account. The Bugzilla account only has an email address and there is no need for the information on other bugs opened by the account. So whether the bug-reporting user is identified with or without a Bugzilla account is practically irrelevant even for having a conversation with the user where the user is asked to provide further details if needed. The whole point of the bug-reporting functionality proposed above is to introduce a manual telemetry system for bugs, as opposed to a typical support ticketing system. Organizational deployments of LibreOffice can simply have their organization's IT support cc'ed on each bug report submitted from any of their organization's LibreOffice instances, so that the LibreOffice will get the telemetry while the organization's IT support can follow up on issue resolution with both the LibreOffice user and the Document Foundation. This will also save manual work for the organization's IT support, which will not have to manually forward a LibreOffice's issue to the Document Foundation. Off-the-shelf solutions like checksum or security token can enable repeated visits by the user via the link in the proposed "View My Bugs" menu in LibreOffice and thus take care of the user's responses (to questions from the Document Foundation on the bug page) that the user will submit also from the same internal UI as the bug report submission inside LibreOffice. As mentioned, each time the user launches LibreOffice, any bug links present (not yet removed by the user) in the "View My Bugs" menu will be checked for updates. The checksum or security token will enable the user to submit new responses on the bug page through the same bug-reporting UI window in LibreOffice without any Bugzilla account. To me, your user profiles like Benjamin are trivial for several reasons: 1. If Benjamin won't be interested in reporting a bug, there are other use cases with other user profiles like corporate professionals who will be compelled to report bugs in order to continue to use LibreOffice to do their job. "Won't fix"ing this because of Benjamin does disservice to all the other user profiles, who may be more numerous in terms of users than Benjamin. 2. There is a 17-y.o. Benjamin sitting at home doing his high-school homework. No! Instead, you must focus on the total desired size of the user base, that is a MS Office comparable size of user base, so rather than telling me about Benjamin you must imagine a user base of 100 million users as the intended use case. So when you write here that you "won't fix" this because of Benjamin or whatever comes to your mind, you make the 100 million users face an interior app. 3. The number one use case or user profile must be a MS OFFICE USER. Finally, just look at how ridiculous this whole Bugzilla "innovation" process is here - opening a bug that is closed with "won't fix" on a subject of new feature development. Nah, won't get far with any good ideas here. So long and thanks for all the fish!
(In reply to Max L. from comment #13) > Off-the-shelf solutions like checksum or security token can enable repeated > visits by the user via the link in the proposed "View My Bugs" menu in > LibreOffice and thus take care of the user's responses (to questions from > the Document Foundation on the bug page) that the user will submit also from > the same internal UI as the bug report submission inside LibreOffice. As > mentioned, each time the user launches LibreOffice, any bug links present > (not yet removed by the user) in the "View My Bugs" menu will be checked for > updates. The checksum or security token will enable the user to submit new > responses on the bug page through the same bug-reporting UI window in > LibreOffice without any Bugzilla account. And while my mind is still on this: In fact, checking for updates to the bug pages for the links present in "View My Bugs" can be coded directly into the "View My Bugs" (rather than at application start as I previously suggested above), so any time the user wants to check for updates the user simply opens the "View My Bugs" menu and visually checks whether there is an update tag/icon next to any present bug link. This should make coding it easier as it will be directly related to that particular menu (as opposed to application start). Since the Document Foundation is not even remotely interested in further developing this functionality, I will not look for external help for you to have it developed and I will not spend any of my own time. My time is precious and to spend it so that it is cut short with a WONTFIX is a total waste. Please remember one thing - innovation is a process of gradual refinement and development of ideas, not of flipping the WONTFIX switch. So long and thanks for all the fish!
Not complelling, concur with the => WF
(In reply to Max L. from comment #14) > My time is precious and to spend it so that it is cut short > with a WONTFIX is a total waste. That's a pity, I like your UX-focused argumentation. Don't become upset and discouraged if some (including me) disagree with your ideas. Keep in mind that we get many enhancement proposals and need to focus on essential tasks. You can reopen a ticket (I will not close in this case), find supporters, and also submit a patch.