531881 - Improve crash reporter UI around the mail address

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Right now the UI for the email address in the crash reporter says:

"Email me when more information is available".

This is bad for two reasons:
1. My first reaction as a user when I see that is "heck no, I don't want to get
   spammed".
2. It's not actually what we do. As far as I know we never email this address
   when the bug is analyzed, fixed, or shipped in a release. So we risk creating
   false hope for the people that *do* want to get informed when the bug is
   fixed.

I recommend we change the wording to something like

Contact me if there are further questions that would help solving this problem.

I further think it'd be nice if you didn't have to check a box to enable the email field. That might encourage more people to not leave it blanks. But I'll leave that up to the UI experts.


It would be neat if we *did* send people an email once we've shipped a release that we think fixes a specific crash. We could have a separate checkbox for this *after* the initial email question. But we shouldn't put that UI in until we actually have a mechanism in place that we are ready to use IMHO.

Comment 1

[Jesse Ruderman]

See also bug 472357, which suggests removing the email field.

Comment 2

[(not currently active) Ted Mielczarek]

If you just want to change strings then that's super-easy (although obviously difficult to do on branches) and I'm open to suggestions. The strings are here:
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/crashreporter/crashreporter.ini

I believe we put the checkbox in so you could easily uncheck it, since we persist the value of the email between runs. We do do some fancy footwork to auto-check the box when you click on the email field, at least on Windows. I'm open to better ideas on that as well.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, so how about this for wording for now:

Allow mozilla to contact me if they have questions that would help with fixing this crash.

(still keeping the UI experts cc'ed in case they have better ideas)

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

A more verbose wording from bug 476377 comment 4:

__Email me when more information is available__: Check this box if you would be
willing to receive emails from the development staff should they need followup
information from you about this crash.  Note: Mozilla will __NOT__ e-mail you
back unless more information is requested about your crash.

__Enter your email address here__: If you chose to help our development staff
get information and reproduce this crash, provide the email address you wish to
be contacted at here.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

How about "It's OK to contact me about this crash report" or something similarly simple that ensures that the user understands it's in relation to that particular crash report, and no other.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Could we also add something to the extent of "Mozilla will only contact you if we have specific questions".

The goal would be two-fold:
* Set the expectation that you should not expect to receive an email (something
  that apparently had been a problem in the past based on feedback in support
  forums. See bug 476377)
* Make people not worry about getting spammed (Not sure if this is an actual
  problem. Maybe I was the only one that had the "don't spam me" reaction)

I certainly don't feel strongly about this though.

Comment 8

[chris hofmann]

I like the ideas that help to set better expectations about what will, and won't happen with the e-mail address.

some good design criteria around this accounts for 

-keeping people from getting worried that they will get spammed.

-informing people about the kinds of information that will be requested and the proper communcation channels that should be used when providing private data.

generally e-mail is a poor communication channel for requesting the kind of private data we will ask for when we contact users.   its open to phishing and its not a secure exchange.  

setting up a different commuication channel storage area for private information that we gather from these e-mail contacts may be beyond the scope of this but, but we ought to keep it in mind.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

For what it's worth, this is what adobes crash UI looks like:

http://futurestack.com/jump/aebugs/

Comment 10

[Noah (NoahSUMO/SolidSnake) [:Noah]]

Not to be the voice of negativity here, but accepting email addresses from users causes users to think they are "entitled" to receive a response. The majority of them sound off thru the forums about having sent many crash reports and never, not one time, getting a email back from a developer.

I don't expect this to change in 2010. With developers as busy enough as they are.

It has frustrated a endless number of users. Providing a example of one below.
https://support.mozilla.com/en-US/forum/1/558177?#threadId559126

Much less, actually being proactive myself, responded to one woman's incessant plea for help from a repetitive crash I was investigating. She had actually posted her email address into the comments section. I sent her an email with a suggestion on what the problem was (disabling a addon) and never heard back if that was successful for her or a failure. It's a 2 way street.

Developers aren't going be sending email replies, and users aren't going to be responding back in the majority of cases for numerous reasons. Some already noted by Hofmann.

Comment 11

[chris hofmann]

we should fix this in 1.9.3.

Beltnzer's suggestion in comment 5 or something like the adobe wording that jonas found would work fine.

Comment 12

[Wayne Mery (:wsmwk)]

Jonas seems on the right track. Simplified adobe wording 
  If you supply your complete email address in the field below, xxx will be 
  able to contact you if more information or your help is needed for this 
  problem.
reads similar to his item 2 of comment 5.

original adobe wording:
In some cases our engineers would like to receive additional information to help them resolve the problem. If you supply your complete email address in the field below, xxx will be able to contact you if our engineers require more information or to notify you of a fix or workaround.
_ Include email address in this report


Does it make more sense for email checkbox to automatically be ticked enabled when the user first completes the field?


I hope we don't struggle long with wording or we will miss even Thunderbird 3.2 :)  Perhaps the less said the better, because there are limitations to what people see or care about. For example, posts generated from http://hendrix.mozilla.org/ illustrate a high percentage of posters didn't see, read or correctly interpret a "do not expect a response" - they still ofoten expect a response.

-----
slight aside related to previous comments ... fodder for other bugs?

Forum postings (comment 10) are probably not useful considering in context of this bug - posters tend to be highly dissatisfied in the first place. Further, I can relate that complaints of "no one got back to me" don't square with my recent experience. People dont' seem to be jumping up and down to help with crashes - perhaps they think it's some else's duty?  Anyway, my data ...  contacted crash reporters for about 4 bugs where Thunderbird is having difficultly and don't have testcases for, mailed 3-10 crash reporters for each bug pointing them to the bug (including "contact me if you encounter difficulty"), and saw maybe a 5-10% return ... which isn't much if you interpret the user supplying an email address as being interested in helping. 

5-10% isn't a good yield, but it's quite significant because many thunderbird crashes require testcases and we get very few bugzilla crash reports (a different issue), a bad combination for getting crashes fixed.
---

"Developers aren't going be sending email replies" - don't know whether that's true or not, but certainly not beyond the normal scope of some QA folk.

"setting up a different commuication channel storage area for private information" may not be necessary - wouldn't this be duplicating what bugzilla can do?  Bug comments can be marked private. Less need for emails and yet a third information repository, if after the crash the user is guided ala "crash reporter helper" add-on (after crash is submitted). Perhaps some special bugzilla UI bug. Perhaps even be guided as to what type information is needed depending on the state of the bug.

But until improvement occurs, in thunderbird land does need selective use of email contacts, even if the yield is low.

Comment 13

[Dave Townsend [:mossop]]

Seems like creating a false expectation is something we should fix

Comment 14

[Tyler Downer [He/Him]]

How does "It is OK to contact me about this crash report if more information is needed" sound? If so, this should be a simple string change I can throw together quickly.

Comment 15

[(not currently active) Ted Mielczarek]

That's pretty similar to beltzner's suggestion in comment 6. I'll take any reasonable patch here, I'm not attached to the existing wording.

Comment 16

[timeless]

Attachment: beltzner's wording

Based on http://mozillalinks.org/wp/wp-content/uploads/2008/02/mozilla_breakpad.png ...

I don't think we really have a lot of space for a message, so, let's go with beltzner's...

Comment 17

[Majken Connor [:Kensie]]

I don't think beltzner's wording is clear enough to solve the problem, we need some wording that reflects when and why people will be contacted. Keep in mind not all localizations would have been able to translate that string in the same amount of space.

"I can provide more information if needed" is short, and the assumption left to be made is fairly obvious especially as checking the box then makes the email field active and required.

or "Contact me if I can be more help(ful?)"

Comment 18

[Majken Connor [:Kensie]]

FTR I'd go longer, a la comment#14 rather than with either of my above suggestions.

Comment 19

[(not currently active) Ted Mielczarek]

Longer isn't a problem. The UI already knows how to resize and wrap the text properly (to handle l10n).

Comment 20

[timeless]

Attachment: tyler's wording

Comment 21

[(not currently active) Ted Mielczarek]

Comment on attachment 452000 [details] [diff] [review]
tyler's wording

Fine with me.

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

Sorry to be late here, but we're actually going to be changing the expectations here - joy!

The Socorro team has said that they hope to actually be able to do the full loop thing where we'll contact people if we find a solution to the crash. So I think that either the original wording will work, or some other wording will be needed.

Details on the crash-information-cycle here: https://wiki.mozilla.org/PostCrash

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 452000 [details] [diff] [review]
tyler's wording

>-CheckSendEmail=Email me when more information is available
>+CheckSendEmail=It is OK to contact me about this crash report if more information is needed

How about something a little more generic, such as:

   Allow Mozilla to contact me about this report

(phrased that way to fit with the other strings)

Comment 24

[(not currently active) Ted Mielczarek]

That probably needs a small code change to go along with it, to get the vendor name into the string. Right around here would be the place to change it:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter.cpp#393

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

Taking; I'll re-word such that the vendor string isn't needed.

Comment 26

[chris hofmann]

I added some comments to  https://wiki.mozilla.org/PostCrash a few weeks ago and some stats that show we will only ever send e-mails to a very small pct. of the crash reports sent in, and/or crash reports with e-mail address under the current plans.  If we find a solution to a single one of our top crash problems it only affects 3-5% of the crash submitting population.  Something like:

 If the Firefox team finds a solution to this crash, 
 send e-mail to [     ]  that explains how to fix the problem.

helps to set the right expectation around what might happen.

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: Allow %s to contact me about this report

My wording, and required code change to get the vendor name in there.

Comment 28

[(not currently active) Ted Mielczarek]

Comment on attachment 480148 [details] [diff] [review]
Allow %s to contact me about this report

>diff --git a/toolkit/crashreporter/client/crashreporter.cpp b/toolkit/crashreporter/client/crashreporter.cpp
>--- a/toolkit/crashreporter/client/crashreporter.cpp
>+++ b/toolkit/crashreporter/client/crashreporter.cpp
>@@ -433,16 +433,21 @@ void RewriteStrings(StringTable& queryPa
>   gStrings[ST_CRASHREPORTERDESCRIPTION] = buf;
> 
>   UI_SNPRINTF(buf, sizeof(buf),
>               gStrings[ST_CHECKSUBMIT].c_str(),
>               vendor.c_str());
>   gStrings[ST_CHECKSUBMIT] = buf;
> 
>   UI_SNPRINTF(buf, sizeof(buf),
>+              gStrings[ST_CHECKEMAIL].c_str(),
>+              vendor.c_str());
>+  gStrings[ST_CHECKSUBMIT] = buf;

This should be:
gStrings[ST_CHECKEMAIL] = buf;

r=me, although does this count as enough of a string change that we need to change the key name to notify localizers? Presumably we want them to pick this change up in their localizations.

Comment 29

[(not currently active) Ted Mielczarek]

If so, you just need to rename the key in crashreporter.ini as well as here:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter.h#51

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: Allow %s to contact me about this report (v2, oops)

oops

Comment 31

[Axel Hecht [:Pike]]

This will need to rev the entity name, too.

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: Allow %s to contact me about this report (comments addressed)

Revs entity, carrying forward r+

Comment 33

[:Margaret Leibovic]

http://hg.mozilla.org/mozilla-central/rev/c542dbce104d