Page MenuHomePhabricator

Better WMF error pages
Closed, DuplicatePublic

Description

There are two main objectives of this task, to make error pages better.

1. Communication
We need communication (copy) on error pages which sounds friendlier and sound like it's written by humans. It should be understandable by a normal user and should give clear idea about the error.

2. Status
We need better means of telling the user about the current situation/updates about the error. Also the updates should be understandable by a non-technical person. IRC is not enough anymore. More discussion about this here.

The pages to be used both on mediawiki.org and projects. Should be general as the specific project name may be unknown due the the failure type.

Mediawiki example — http://www.mediawiki.org/skfjghsdjf

Requirements

  • Minimal text (10 variations - randomise copy if possible)
  • i18n
  • Single HTML
  • SVG only (simple) will be converted into dataURI
  • CSS need to be inline

Things we can't do

  • Linked images
  • Linked css
  • Other linked assets (wikifont)
  • Auto-reload the page

Things to consider including

Error description spreadsheet
[Public] https://docs.google.com/a/wikimedia.org/spreadsheets/d/1pm2flhyK7CjwyfBHc5GM0OC8PX_7tuASt_ArEYW5F5M/edit?usp=sharing


See also ongoing work at:

Event Timeline

Nirzar claimed this task.
Nirzar raised the priority of this task from to Normal.
Nirzar updated the task description. (Show Details)
Nirzar added projects: Design, WMF-Design.
Nirzar changed Security from none to None.

Which types of error pages is this supposed to cover?
Only 404s etc.? Or also 503s etc. in the style of http://farm4.static.flickr.com/3044/2946860326_1097a4bee2_o.jpg ?

Nirzar added a comment.EditedDec 3 2014, 5:22 PM

We were trying to populate this spread sheet with common errors
https://docs.google.com/a/wikimedia.org/spreadsheets/d/1pm2flhyK7CjwyfBHc5GM0OC8PX_7tuASt_ArEYW5F5M/edit#gid=0

Also, based on the conversation over at T22079, I think we are also looking at the outage error page. There needs to be better communication about the exact error, state of the error (temporary/permanent), what can be done about it (a way out) and current status of things.

I have added few mocks over here, based on the first template. I've also updated the spread sheet to reflect the requirement of communication and primary actions for different types of errors.

About the 404
@faidon Currently if you go to mediawiki.org/xyz it shows a 404 page and then redirects to mediawiki.org/wiki/xyz after 5 seconds. Is there a reason we're showing a page and a timeout. What if there is a redirect rule for 404, which implicitly redirects without showing a page?

Nemo_bis renamed this task from Better Error Pages to Better WMF error pages.Dec 9 2014, 6:59 AM
Nemo_bis updated the task description. (Show Details)
Nemo_bis updated the task description. (Show Details)Dec 9 2014, 7:01 AM

Twitter is the recommended medium for communicating with the public during outages (see https://wikitech.wikimedia.org/wiki/Incident_response#Communicating_with_the_public ), so the outage version of the error page should indeed link at least @Wikimedia .

This appears to be a duplicate of T22079. I disagree with the requirements, I edited them a bit. I don't understand the mocks. The task doesn't describe your objective and it's therefore impossible to understand, please add user stories or use cases.

Please make the spreadsheet public, or move that information to the task description.

Nirzar updated the task description. (Show Details)Dec 9 2014, 10:35 AM

I've updated the description to include clear objectives.

I went through all the comments on T22079 and I think so far we have status.wikimedia.org and Wikimedia Twitter as the two ways to inform the user about "what's going on". With this, we also need to provide the error details. If you look at the first mock, the 3rd hierarchical element is "status and more info"

For status, I had tried embedding twitter card. but I'm not sure whether it will be possible to embed that widget on this page since we want a lightweight simple html page.

The other option is to give ways to go to Twitter and status.wikimedia.org for people who are interested in knowing more. As @Tbayer mentioned, twitter is the recommended medium during outages.

Here's the prototype for that one. You can tap on view details (we can make it know more) to see details.

@Nemo_bis please discuss first before changing the requirements of the project, thanks!

In case direct embedding of the Twitter feed is not possible (I think this may present privacy issues, although I don't know about the implementation details) and we go with a link, let me capture the wording proposed earlier on T22079 (with some copyedits and incorporating Erik's suggestion):

"In case of ongoing outages, you may be able to get further information from the <a href="https://twitter.com/wikimedia" @Wikimedia Twitter feed</a>."

@Nemo_bis please discuss first before changing the requirements of the project, thanks!

Why do you ask discussion/consensus for requirements changes? Where is the consensus for the original requirements?

@Nemo_bis this was discussed at length during the zurich hackathon, and has been on the public design trello for a long time. What are you concerns with http://status.wikimedia.org and the 5$ donation link?

Here's final template for the error page.

  • It's mobile optimised, change browser window size to check.
  • Donation link is integrated. fixed $5 via paypal.
  • All images are SVGs - looks sharp on all screens including iPhone 6 plus
  • Twitter handle link added with correct phrasing. @Tbayer
mark added a subscriber: mark.Dec 15 2014, 1:46 PM

@Nirzar error page looks good, have you gotten what you need from Ops to move forward with the 404 page or made a decision about skipping it all together?

@Jaredzimmerman-WMF Ops haven't replied yet. Also, I haven't received browserstack information, so browser testing for windows is pending.

Some implementation related wisdom spotted on irc:

[23:20:49] <robla>	 seems like every 2-3 years, we go through a cycle of:
[23:20:59] <robla>	 1.  Replace the 500 error page
[23:21:13] <robla>	 2.  Have a 500 storm
[23:21:55] <robla>	 3.  Find out that the new 500 page causes the 500 storm to be way worse
[23:23:21] <robla>	 I don't recall the last time this happened, but it may be long enough ago that the institutional knowledge of what's fine and what's bad might not be there.
[23:25:26] <TimStarling>	 it should be possible to use images on the error page
[23:25:56] <TimStarling>	 as long as they use upload.wikimedia.org as a source, not data: URIs
[23:26:15] <TimStarling>	 if upload is down, the images won't load, which is fine
[23:26:54] <TimStarling>	 you can't really use linked CSS, or have a large style tag in the page, so that is a limitation
[23:27:43] <TimStarling>	 similarly with JS, it's possible to load code from the bottom of the document, but not really from the <head>
mark added a subscriber: BBlack.
mark added a comment.Feb 5 2015, 2:46 PM

Some implementation related wisdom spotted on irc:

[23:20:49] <robla>	 seems like every 2-3 years, we go through a cycle of:
[23:20:59] <robla>	 1.  Replace the 500 error page
[23:21:13] <robla>	 2.  Have a 500 storm
[23:21:55] <robla>	 3.  Find out that the new 500 page causes the 500 storm to be way worse
[23:23:21] <robla>	 I don't recall the last time this happened, but it may be long enough ago that the institutional knowledge of what's fine and what's bad might not be there.

Yes, size is the main issue here. That has been indicated in the requirements, but not further specified.

I see the current proposal HTML page is 28 KB, which may be a tad large. We should investigate the mean object size of all Varnish clusters on which this page will get installed, and make sure this error page isn't larger than that. We need to avoid *increasing* our total (bandwidth) load in the case of errors.

Of course not as important as the requirements by Mark and Tim above, but the proposed HTML has some issues which make it not an improvement. Also, it doesn't meet goals (1) and (2) in the task description.

Additionally, it's not clear whether this task is about the 404 (linked in the description) or the 503 (hinted by the proposal).

@Nemo_bis this was discussed at length during the zurich hackathon

Link to notes?

Here's final template for the error page.

  • Donation link is integrated. fixed $5 via paypal.

a) It's misleading to suggest that donations help reduce 5xx errors.

  • Twitter handle link added with correct phrasing. @Tbayer

b) I don't see it.

c) Why is it loading resources from googleapis.com? Please post a patch with the code you actually want to use.
d) The Wikipedia logo must be removed, this is an error page for all Wikimedia projects.
e) What is the "View details" button for? Does it work without JavaScript? Does it ensure that the error is informative (point 1 in description)?
f) Several grammatical issues, can be pointed out when the patch is in gerrit.
g) Must assess whether "take a time out" is understandable for a global audience.
h) Ops should confirm that it's fine to include a button which encourages refresh.
i) operations/mediawiki-config/503.html is multilingual. Existing language support must be ensured; ideally, it should be increased.

Question: could we add a link to Kiwix.org during any outages?

Question: could we add a link to Kiwix.org during any outages?

kiwix.org is hosted externally, which is good because it'd be accessible if our sites are down, but we'd likely kill the site by causing a deluge of traffic to it.

I notice that the current Error: 503, Service Unavailable at Thu, 05 Feb 2015 17:36:37 GMT page isn't HTML5 compliant whereas it uses <hr noshade="noshade" size="1px" width="80%" /> in which all of the parameters (noshade, size, and width) have been deprecated since HTML4.01 and obsolete since HTML5 as mentioned in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hr Also <body link="#24442E" text="#000000" vlink="#24442E" alink="#FF0000"> is non-conforming per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body

kiwix.org is hosted externally, which is good because it'd be accessible if our sites are down, but we'd likely kill the site by causing a deluge of traffic to it.

Probably not if we linked download.kiwix.org directly. Mirrors are robust (except WMF). However, it's not obvious how to give a one-size-fits-all link among the many ZIM and torrent files available.

Pcoombe added a subscriber: Pcoombe.Feb 5 2015, 5:58 PM

Question: could we add a link to Kiwix.org during any outages?

kiwix.org is hosted externally, which is good because it'd be accessible if our sites are down, but we'd likely kill the site by causing a deluge of traffic to it.

What about setting something up on meta.orain.org?

I see the current proposal HTML page is 28 KB

I am looking into reducing this. It should be around 12kb

@Nemo_bis

b) I don't see it.

It's under view details. if someone expresses interest in knowing more about the error.

c) Why is it loading resources from googleapis.com? Please post a patch with the code you actually want to use.

This is a temporary usage of jqeury. obviously jqeury won't be used on this page. This was used just for prototyping purpose. I will be posting a patch soon, i was trying to locate the files.

d) The Wikipedia logo must be removed, this is an error page for all Wikimedia projects.

The main logo at the top is about the foundation, which seems appropriate, the current error pages do not have this element so there isn't any immediate association with the projects, the wikipedia logo is tied to the donation call to action which is consistent with how fundraising works now, that most users come to a donation flow via wikipedia, that brand recognition is important to maintain.

e) What is the "View details" button for? Does it work without JavaScript? Does it ensure that the error is informative (point 1 in description)?

It is for people who want to 1. know more about what happened (are interested in technology) 2. report the bug if they found one. and 3. know more about the status overall

f) Several grammatical issues, can be pointed out when the patch is in gerrit.

Text is in the process of getting finalised.

(g) Must assess whether "take a time out" is understandable for a global audience.

Any suggestions would be welcome, we'll also work with Communications to finalise this

(h) Ops should confirm that it's fine to include a button which encourages refresh.

True. but giving a way to do something on an error page (dead end) to user seems like an improvement. If someone faces a dead-end, we need to create a door for them.

i) operations/mediawiki-config/503.html is multilingual. Existing language support must be ensured; ideally, it should be increased.

This page will also be multilingual, need to finalise the main body text first and then planning on translating with translatewiki. what was finalised until now is just the layout and how we handle the actions.

Heather added a subscriber: Heather.Feb 6 2015, 4:38 AM

This looks great! Would you mind sharing where the text is being finalized?

Thanks! Would you mind setting up a meeting with Communications before the text is considered final? -- Whenever you are close.

Krenair added a subscriber: Krenair.Feb 6 2015, 6:20 PM
Prtksxna removed a subscriber: Prtksxna.Feb 6 2015, 11:28 PM
bd808 added a subscriber: greg.

@greg is going to find a Release-Engineering-Team helper for this project

Here's final template for the error page.

  • It's mobile optimised, change browser window size to check.
  • Donation link is integrated. fixed $5 via paypal.
  • All images are SVGs - looks sharp on all screens including iPhone 6 plus
  • Twitter handle link added with correct phrasing.

Based on what I see in this prototype, I have objections to the lack of a 'desktop view' link, the 'donation' link lacks information and in the context of 'an error page' implies that the foundation can't afford to offer the content without payment in the form of 'a donation' which is misleading. Other than those two things, the page seems fine at my level although I can see the possibility of people clicking the the 'more details' link and being more confused than less. Needs more verbosity and less tech speak if possible for that.

@Technical13 what would a "desktop view" mean in this case, as it is a responsive page it adjusts for the device… many browsers (mobile and desktop) allow you to spoof or emulate a different device, but since the content is the same what would the value of a desktop view on mobile be?

what information do you feel is missing from the donate message? As @Nirzar said, the final text is not present, I'm not sure that the donation action on the page will tie that strongly to the issue (there's already a donate link on every page of wikipedia and the other project pages in the left nav, and the final text can help clarify) As far as updating all of the technical errors that could be shown in the more details expansion, that would probably be a large project that is beyond the scope of this task. But might be a good one to take on if you have interest and knowledge in that area.

greg added a comment.Feb 10 2015, 4:21 PM

@greg is going to find a Release-Engineering-Team helper for this project

@Nirzar: Can you give me/this ticket a status update of where you are/what you need (including what you need from RelEng)? Also, have there been any patches submitted for this work already? I don't see any linked gerrit changes to this ticket (and I would assume any work on this would have this ticket number listed in the commit message).

@Technical13 what would a "desktop view" mean in this case, as it is a responsive page it adjusts for the device… many browsers (mobile and desktop) allow you to spoof or emulate a different device, but since the content is the same what would the value of a desktop view on mobile be?
what information do you feel is missing from the donate message? As @Nirzar said, the final text is not present, I'm not sure that the donation action on the page will tie that strongly to the issue (there's already a donate link on every page of wikipedia and the other project pages in the left nav, and the final text can help clarify) As far as updating all of the technical errors that could be shown in the more details expansion, that would probably be a large project that is beyond the scope of this task. But might be a good one to take on if you have interest and knowledge in that area.

I honestly think that if size is a concern, then worrying about special layout and formatting for smaller widths is a waste of bits. As far as the donation message goes, you have to picture it... You tried to perform and action and get dumped on this error page that says "hey, we can't do what you asked, please try again later" Then, on the bottom half of your mobile screen is this big message with a global, "Help us improve!", and a big button that says "Make $5 Donation" and nothing else. There should at least be a disclaimer under the button in small print that says something to the effect of (I suck at wordings, so you probably won't want to use this exact phrase) "While donations help keep us running, they're optional." I'd be happy to work on non-tech error descriptions if someone wants to put together a Google spreadsheet of error messages that have occurred or are plausible to occur in the future and send me a link/share/invite. :)

greg added a comment.Feb 10 2015, 9:21 PM

See also: notes on 404/500 error pages from @bd808: https://phabricator.wikimedia.org/P279

@greg thanks, this makes things a lot clear :) only one small thing, /mediawiki-config/503.html this page has language selection in the footer but the wikipedia 503 doesn't, is it configured to the individual wikis?

@Technical13 your point is taken, as we refine the wording we can think about the relationship between the donation action and the page. I'm not sure that anyone would draw this conclusion that the donation is not optional, but it's something to think about.

As far as "wasting the bits" more and more the site is accessed on mobile, and by many it is the only way users access the site. If we had to choose (and thankfully we don't) we'd ONLY have a mobile version of the page, as it would be usable to all people, where as a desktop only version would only serve some.

jeremyb edited subscribers, added: jeremyb; removed: jeremyb-phone.Mar 20 2015, 11:36 PM
Sitic added a subscriber: Sitic.Jul 21 2015, 12:43 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 21 2015, 12:43 AM
Dzahn removed a subscriber: Dzahn.May 4 2016, 1:32 PM

Neither "Requirements" nor "Things we can't do" mentions JavaScript... Any statement about it?

BBlack moved this task from Triage to Watching on the Traffic board.Oct 4 2016, 1:20 PM

This file disappeared. Do you still have a copy? Please upload it somewhere safe, e.g. Wikimedia Commons. (More on this.)

Nemo_bis updated the task description. (Show Details)Apr 4 2017, 8:19 AM