Error page language tweaks to prevent CS woes

[mmcwatters]

At the moment, we feature a link to contact CS prominently on our error pages. When the site is down, this results in an influx of repetitive messages for CS to deal with. A couple minor tweaks could fix it:

• For 40X errors (which usually mean something's missing or the user just made a weird request) we can keep the contact link
• for 50X errors (which mean something's busted on our end, like today) e can could say words to the effect of "Our Tech team has been alerted and is looking into this issue!"

cc @redoPop @gavinhall

[redoPop]

Woops, forgot to close this one. This change was made as part of version 2.0.1 and has been deployed to production. Example error pages:

• https://www.ted.com/404.html
• https://www.ted.com/500.html

The language I'm using for 50X errors is "We've been notified of this issue and are working on it!"

Feel free to reopen if this or anything else needs to change!

[gavinhall]

Is that true for non site outage issues? I'd rather have people over report than under report. Like that's how we found out about surprise me being broken

…

On Feb 20, 2017, at 8:20 PM, Joe Bartlett ***@***.***> wrote: Woops, forgot to close this one. This change was made as part of version 2.0.1 and has been deployed to production. Example error pages: https://www.ted.com/404.html https://www.ted.com/500.html The language I'm using for 50X errors is "We've been notified of this issue and are working on it!" Feel free to reopen if this or anything else needs to change! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[redoPop]

It depends on the nature of the issue. What was the Surprise Me issue that was caught by user reports?

[gavinhall]

I believe it was 500ing for some reason related to a code change. Someone emailed in and Beck asked about it and we were able to fix it. Kind of the whole point of having CS team inside of tech and doing everything we do to get super fast responses is to allow our users to he the ultimate final check to make sure the site is working. If they stop emailing us that something is broken then what's the point. Although I do think the copy above that like that shows an error could be different and more helpful but having them contact us is the right thing to do

…

On Feb 20, 2017, at 8:53 PM, Joe Bartlett ***@***.***> wrote: It depends on the nature of the issue. What was the Surprise Me issue that was caught by user reports? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[redoPop]

I didn't find that issue in our GH/Flowdock history, but "Surprise Me" is mostly powered by ajax requests, whose error messages will be unaffected by this change.

More broadly, "Error 500" pages are included in this change because they've been involved in past outages: according to GA, over 209,000 of them were served during our Jan 17 outage. When such outages occur, Customer Service becomes overwhelmed with visitor reports. e.g. during the Feb 9 outage we rendered ~153,000 "Error 502" pages, and Customer Service saw 123 reports (vs. a daily average of 0–4).

So for the same error pages (e.g. 500) we need to find a balance between discouraging users from filing reports we might not know about ("We're working on it") vs. encouraging them to file reports we almost certainly know about ("Please contact us"). I'm not sure we can accomplish that with copy alone. @mmcwatters: any ideas?

[mmcwatters]

This is an interesting challenge. I think it's great to let users inform us if something is broken. I also think it's great to give them a sense that they are taking action—nothing worse than a dead-end.

So here's a spitball idea (which I may have mentioned before): instead of directing users to our contact form, what if we gave them a simple button, something which says, "Push this button to let us know" (of course that wouldn't be the actual copy).

That message would be directed to some kind of special inbox for CS—not an actual message they need to deal with like a typical CS issue, but just a box that would notify them that, hey, something's amiss.

After the user selects the button, a thank you message would appear—"Thanks for letting us know. Want an update when it's fixed? Enter your email and we'll alert you." When the problem is solved, CS writes a message and it's automatically sent to all those folks who gave us their email. One bulk response.

[gavinhall]

I think those two outages are the extreme case and hopefully once we get the site to have a read-only version it won't see things like that. Also 123 reports in desk isn't the end of the world. We can select a bunch and have them get the same macro. I'm more worried about when other pages break and we don't have any idea because the 500 count isn't high enough to set off an alarm to notice us and the only way we are going to find out is either from a user or a staff person. Maybe the solution is just a simple flag for when there is a site outage that changes those errors to something else. But then again if we are having a site outage and showing that page...why not show another one that doesn't look like an outage and still gets the person what they are after ;)

…

On Tue, Feb 21, 2017 at 11:28 AM, Joe Bartlett ***@***.***> wrote: I didn't find that issue in our GH/Flowdock history, but "Surprise Me" is mostly powered by ajax requests, whose error messages will be unaffected by this change. More broadly, "Error 500" pages are included in this change because they've been involved in past outages: according to GA, over 209,000 of them were served during our Jan 17 outage. When such outages occur, Customer Service becomes overwhelmed with visitor reports. e.g. during the Feb 9 outage we rendered ~153,000 "Error 502" pages, and Customer Service saw 123 reports (vs. a daily average of 0–4). So for the same error pages (e.g. 500) we need to find a balance between discouraging users from filing reports we might not know about ("We're working on it") <https://github.com/tedconf/error_pages/blob/86f654d5198acbbcef66b05a7e1de8b83545266b/src/statuses/500.md> vs. encouraging them to file reports we almost certainly know about ("Please contact us") <https://github.com/tedconf/error_pages/blob/e5a1cdaa30ce6c53835ce52ec80993eb192dc5f2/src/statuses/500.md>. I'm not sure we can accomplish that with copy alone. @mmcwatters <https://github.com/mmcwatters>: any ideas? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA12OZL1jWFrF__oqNVRr1M4xQ-ODkBiks5rexCcgaJpZM4L8hYl> .

[mmcwatters]

@redoPop and I were brainstorming on this. What if we implement a button on the page that triggers an Airbreak alert. Said alert could potentially be directed to the CS flow and/or Tech flow so we're notified. The user would receive a message saying, "Thanks for letting us know. We're on it!" (Or words to that effect.) How does this plan sound, @gavinhall ?

[gavinhall]

Sounds worth trying. Can we also update the server error copy so Brad frost didn't mock us ? ;)

…

On Mar 6, 2017, at 12:19 PM, Michael McWatters ***@***.***> wrote: @redoPop and I were brainstorming on this. What if we implement a button on the page that triggers an Airbreak alert. Said alert could potentially be directed to the CS flow and/or Tech flow so we're notified. The user would receive a message saying, "Thanks for letting us know. We're on it!" (Or words to that effect.) How does this plan sound, @gavinhall ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[redoPop]

Reopening this issue for me to implement a front-end Airbrake notifier.

McW: I know Gavin was joking above, but please feel free to open a separate issue any time you'd like to request copy changes on these pages.

[mmcwatters]

@redoPop Yes, agreed. Is there one message to be re-written, or multiple?

[redoPop]

I've created #11 as a general issue for rewriting error message copy.