252237 - Quality Assurance menu needed in ALL Mozilla windows

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Marc Chamberlin]

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.

Comment 1

[R.K.Aa.]

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

Comment 2

[Marc Chamberlin]

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.

Comment 3

[Frank Wein [:mcsmurf]]

Seeing the count of bugs (also in other products than Browser) the users seem to
find bugzilla.mozilla.org also without that menu.

Comment 4

[Marc Chamberlin]

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.

Comment 5

[Frank Wein [:mcsmurf]]

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.

Comment 6

[Marc Chamberlin]

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.

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.