Update the error page design to include information about the error

[sentry-io]

Description

Kinds of errors

404 for pages that do not exist (openverse.org/nonexistentpage)
404 for single media result pages with non-existent id
429 for throttled requests - #2586
500 for API internal server error (can be the same as no. 1?)
Timeout errors

Special cases

What should we show for the following client-side errors:

1. For All content view: what should be done when only one of the media types received an error?
2. Errors on the "Load more" fetching?
3. Should we display an error when there is an error loading Related media, or just hide the section?
   When the requests fail with 429, the user should see an error page with a message indicating what the user can do and when they can resume using Openverse.

Sentry issue

Sentry Issue: OPENVERSE-FRONTEND-ZP

Error fetching image from API. Request failed with status code: 429

Note: This issue originally only said "Add 429 error page", but was edited to include more error kinds

[zackkrida]

Discussion relating to this issue here:

#2612

[obulat]

I'm copying the request for updates to the No results error page from the closed issue #511 here:

If a user makes a search that has no results, it might be nice to give the user some suggestions on how to widen the scope of their search. This could be handled in many ways, either with some simple text or with some actual controls that are contextual to the user's search. Some examples of what types of suggestions I'm thinking of are:

Try enabling other media types
Enable more licenses
Try other providers

[fcoveram]

I have a few ideas for this, but before, I would love some guidance on the following:

404 for single media result pages with non-existent id

I don't follow this error. Can you elaborate more? In ticket #2612, is suggested to "show the media type and the id." So my main questions are:

1. In which way does showing the media type and its id help?
2. What should users do to get results?

429 for throttled requests

If this doesn't relate to a single content, then, showing a message on the search results sounds more in context. Am I understanding it correctly?

500 for API internal server error

Is this related to a single content or to the whole search result? If it's the first, then landing on a page asking you to refresh it sounds sufficient. Am I correct?

For the special cases

For All content view: what should be done when only one of the media types received an error?

From this I deduct three layouts and use cases: all content, image, and audio results. Am I correct?

Errors on the "Load more" fetching?

Can someone elaborate on how this works and what users need to do to continue searching?

Should we display an error when there is an error loading Related media, or just hide the section?

To me, a message replacing the whole related media area seems clear enough.

---

Pinging @obulat as Zack is AFK. But any opinion and suggestion is truly welcome.

[obulat]

We should delay the implementation of these changes until after we convert to Nuxt 3 because it has a nice related feature, NuxtErrorBoundary. However, this is not a blocker for designs.

404 for single media result pages with non-existent id

I don't follow this error. Can you elaborate more? In ticket #2612, is suggested to "show the media type and the id." So my main questions are:

1. In which way does showing the media type and its id help?
2. What should users do to get results?

1. I guess showing the media type and its ID would help me to debug the failure. I don't think the users need these details. I'm not sure if saying something like "We couldn't find an image with id xxxxx" would be better for the user than just "We couldn't find this media item".
2. It is highly unlikely that a user lands on this error page by clicking a search result, since if the media item existed in the search results, it should exist in the single results, too. So, the only way of getting here is by clicking a link that was shared with the user, or by typing it in the address bar manually. This is why I guess we could say something like "There's no such media. Please check your link, or search for another media item"

429 for throttled requests

If this doesn't relate to a single content, then, showing a message on the search results sounds more in context. Am I understanding it correctly?

Some users try to scrape the frontend, and they get throttled after they get the search results. So, they attempt to automatically click on the results - but get the 429 error for each single result they try to open.

500 for API internal server error

Is this related to a single content or to the whole search result? If it's the first, then landing on a page asking you to refresh it sounds sufficient. Am I correct?

This can happen both for the search results and the single item. I think showing a page asking you to refresh would be sufficient.

For the special cases

For All content view: what should be done when only one of the media types received an error?

From this I deduct three layouts and use cases: all content, image, and audio results. Am I correct?

I think we already have an error page when the image search results page or the audio search results page fail to load. What I meant here is when the user is on All content search results page, and, for example, image results load, but the audio results fail. So, the user was expecting to see the mixed results, but sees only the images. This might be fixed by reloading or maybe by clicking on the Load more button, which attempts to re-fetch the first page of audio.

Errors on the "Load more" fetching?

Can someone elaborate on how this works and what users need to do to continue searching?

If there was a network error, or a timeout error (so, an error that can be fixed by retrying fetching) when the user clicked on Load more button, they will not see the additional results. They will need to click the load more button again.

Should we display an error when there is an error loading Related media, or just hide the section?

To me, a message replacing the whole related media area seems clear enough.
👍