User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 The QA menu should be available in ALL Mozilla tools, not just the web browser. The email, and composition windows do not have this menu, and this is important if you do not want to discourage ussrs from reporting bugs about these tools. Also I would add a link to a feedback page from both the QA and Help menus. This is not as difficult for users to use, as Bugzilla is, for reporting issues. Getting good user feedback is what allows you to build a decent tool and making it easy for users to give feedback shows that you care about their experiences. Reproducible: Always Steps to Reproduce: 1. 2. 3.
the QA menus are intended for use by QA people, not users. That's why they are NOT included in release builds. I don't feel a need for more QA menus. I rather wish bug 59655 would be fixed soon. Furthermore, the QA menus are essentially a bunch of bookmarks, and therefore belong in the browser. Not elsewhere. Recommend WONTFIX
Well I guess I must fundamentally and strongly disagree with you. YOUR USERS ARE YOUR BEST QA TEAM! Giving your users the ability to EASILY and QUICKLY provide your engineering teams with feedback and bug reports IS THE BEST asset and feature your products can provide them with. Having Feedback and Bug Report options readily available from the program menus (the Help menu is also a good place for them) makes it very easy for users to report problems. They are not so likely to give up doing so, if they don't have to jump through hoops such as subscribing to news groups, or finding obscure web pages for bug reporting etc. By not providing such options directly within your programs, you are not only sending a message to your users that you simply don't give a damn about their experiences, but you are also doing a dis-service to yourself and your fellow engineers. Getting LOTS of feedback from you users is the best way that engineers have to improve the quality and usability of the products they are building! Finally, is doesn't matter if the items in the QA menu are just "a bunch of bookmarks" The goal is to make it EASY for the user to give you bug reports and feedback whenever he/she encounters a problem. Your job as an engineer is to GUIDE THE USER TO A SOLUTION! POINT THE WAY, and make it as intuitive as possible. You are placing an additional burden on your users if you don't make it easy for them to report problems. IT IS AMAZING TO ME, ANOTHER VETERAN SOFTWARE ENGINEER +30 YEARS EXPERIENCE, HOW MANY OF MY FELLOW COLLEAGES SIMPLY DO NOT REALIZE JUST HOW IMPORTANT HAVING THESE FEATURES BUILT DIRECTLY WITHIN, AND ACCESSABLE FROM, THEIR PROGRAMS REALLY IS!!! PLEASE RE-THINK YOUR POSITION ON THIS ISSUE.
Seeing the count of bugs (also in other products than Browser) the users seem to find bugzilla.mozilla.org also without that menu.
Again, I must strongly disagree with you Frank.... I grant you that any user who is savoy enough to deal with reporting bugs via Bugzilla on their website, is savoy enough to find the website on their own, without needing a guiding pointer from a Help menu item. However, please try to think for a moment, who is Mozilla's average user and who do you really want the Mozilla engineers to be getting feedback from? Believe it or not, Mozilla's average user is NOT A COMPUTER SCIENCE GEEK and cannot handle the complex technical barrier(s) the Mozilla team have raised in order to give them feedback. The average user is Mom, Uncle Joe, Aunt Bessie, trucker friend Jim, daughter Julie etc. etc. These people CANNOT handle any process with any sort of complexity and discover how to give the Mozilla engineers feedback, on their own. They cannot find the Bugzilla website, let alone use it to report bugs and problems they are having! Yet these are the people whom the Mozilla team most desperately needs to hear from and find out if their models for web browsing, email communication etc. are working. They compose of 95% of their user base! If the Mozilla engineers raise technical barriers to allowing users to give them feedback, then they are ONLY GOING TO HEAR FROM THEIR MOST SOPHISTICATED USERS! And the problems they will hear about are only going to be the more difficult and challenging ones. They will NOT hear about problems users have with the very model itself. For example, my Dad ACCIDENTALLY managed to closed the panel that displays the list of email messages in the Mail and Newsgroup utility and could not for the life of him figure out how to reopen it. Because he was no longer seeing new email arrive, he figured his ISP service was broken. My Mom to this day has no idea how to save, retrieve, or insert an image into an email, even though I have show her... The model for doing so is too complex for her to grasp. I could go on an on... Sure, you can argue that these are merely education issues, and the user just has to learn how to use this tool. But that is my point exactly, these non-savoy computers users are NOT learning easily, becoming frustrated, AND THE MOZILLA TEAM IS NOT GETTING ANY FEEDBACK FROM THEM!!!! Without feedback, they will continue to produce a product that, quite possibly, many of their users are finding difficult to learn how to use. And many will give up on it. Believe me, I KNOW because I spend a LOT of my time helping them with even the simpliest tasks, and from these experiences I realize that Mozilla's model IS BROKEN IN MANY PLACES, making features UNDISCOVERABLE to the non computer savoy folks! You and I don't experience these difficulties because we draw on our vast experience of working with other computers and programs and KNOW how things SHOULD OR MAY WORK... But your average user DOES NOT have this experience to draw on, DOES NOT know how to tell the Mozilla engineers about his/her troubles, DOES NOT EVEN KNOW that a bugzilla website exists, and probably DOES NOT even know that there is a Mozilla website PERIOD!!! As an aside, let me also state that providing documentation DOES NOT WORK! Most users are afraid to read documentation, because A) it is boring, B) it is difficult to understand most of the time and it often uses lots of technical jargon, and C) most feel that if a tool is not intuitive to use, then it is not worth using. AND this is WHY the Mozilla team need to be getting lots of feedback... Just because you or the other Mozilla engineers may find Mozilla easy to use and intuitive, their users may not be. Again, and AGAIN I will argue that the Mozilla team needs to be hearing from, getting feedback from their ENTIRE set of users, from the least educated to the most computer savoy genius like yourself... If Mozilla does not provide a VERY SIMPLY way for users to report bugs and give feedback, about their experiences, then the Mozilla engineers will never become aware of ALL the types of problems and issues that their users are facing. I would even argue that Bugzilla is also way to complex and intimidating for most of Mozilla's users to use. What should really be provided, is a VERY SIMPLE email or webmail interface that allows a user to freely type in and explain what he/she wants to say, and then automatically have this entered into the Bugzilla data base for them (perhaps in a "non-specified" catagory). The engineers then can sort through this, catagorize what the common problems are, and begin to build up a more realistic picture of where models within Mozilla are failing. But whatever methodology for providing feedback is chosen, GIVE THE USERS AN EXTREMELY EASY WAY TO FIND AND DISCOVER IT!! Also, keep in mind that many, if not most, of the users are too lazy to try and figure out how to give feedback or find the Bugzilla webpage on their own. Many will, most wont... That is human nature when facing any kind of barrier. So, what happens to those who don't? They become angry, frustrated, and go searching for an easier answer/solution elsewhere. Giving users a very easy means of providing feedback, A) takes some of the anger away, and B) lets them ALL feel like they CAN contribute towards making a product better.
Believe me, we already get enough feedback like this and - to be honest - we already get enough bugs (which doesn't mean we don't want good bug reports anymore :). And the bug reports those people (normal avarage joe) fill are not the best, sometimes even you don't know what the bug reporter wants. And if you know that, there are probably no free resources anymore to fix these bugs, so one more bug report laying around for years. Mozilla's UI is not the best, we know, but there won't be any great changes in the future, since the UI is in some kind of "maintaince mode". Significant changes will only happen in Firefox and Thunderbird in the future afaik. We had such a thing where you could freely type in your bugs/enhancements, but most of the bug reports in the end were garbage, you couldn't make out anything of most bug reports and those were simply closed. But how should a user know anyway what "QA" means? So i guess he also doesn't look there even for the File a Bug menu-point.
Frank - I hope Thunderbird and Firefox will also install a feedback menu item in the help menus (or QA menu if you like, though as you mentioned QA is a term most users will not be familiar with) I have not looked at these products, so I don't know... The benifiets of having a feedback process simply far outweights the costs that it is so sad when not included in a product. As for handling the thundering hoards of users who you fear will overwhelm you with bad or poor reports, you can handle that several ways. One approach I like would be to use a layered bug reporting process. For example - have a feedback form which automatically forwards user comments into a user supported newsgroup (my Mom would be completely unable to find your newsgroups on her own, let alone figure out how to subscribe to it and use it, so again the Mozilla engineers need to be giving her a guide (gui with easy to use forms) to get there, which a feedback item in the help menu would do). Set up a service so that any replies to a users feedback/comment would be presented to the user each time they subsequently start up Mozilla, or maybe you simply insure that comments will be emailed back. That would be layer one of your feedback process, layer 2 dedicate a few engineers to monitor the newsgroup (you probably already do) and have them cull out the better comments and suggestions or summarize them in a bug report for the rest of the engineering team. (Don't have them try an push the bug reporting job back on the user unless they are certain the user can handle Bugzilla. Most users wont be able to.) Reward engineers who do a good job of this somehow (public praise, recognition, opportunity to help make bigger decisions etc.) and use multiple monitoring engineers so as to insure this step will be adaquately taken care of. Yes this IS an extra burden but again I must say the benifiets will far outweight the costs in terms of the overall success of Mozilla and related products. You also may need a layer 3, which is where I fear this bug report, I am submitting, may be failing. Bug reports such as this one affect the very models of your software and processes used by your engineering team. This type of bug report is not easily handled by engineers on the "floor". It needs to be brought to the attention of your core team and management who set the vision for this and all their other products. Most ISO companies have such a process in place but I am not sure how the vision for an open-source project such as Mozilla, and its derivatives, gets established, guided, and adhered to. Whoever your core team is, and its visionaries are, those who establish the overall policies, processes, dedicate resources, etc for the Mozilla family of products, needs to have a mechanism whereby bugs and discussions about said vision, policies, processes, etc is brought to their attention.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.