Page MenuHomePhabricator

Investigate - Wikisource Export: Provide Indication of Error State from Download Pop-up [8H]
Closed, ResolvedPublic


As a Wikisource user, I want to be provided with helpful information upon an error (such as the type of error, why it occurred, and next steps), so I can take appropriate next steps when I encounter errors.

NOTE: This ticket is a follow-up to T271869 & a sub-task of T271970.

Background: Prateek & Ilana have discussed that of the three main states for the download experience (download in progress, download complete, download error), the download error state is the most important for users to know about & to receive more information, if possible. This is because, in all other states, users will have the behavior they want and expect. However, in the case of error, users are in a position they do not want to be in and the next steps are often unclear. For this reason, the team discussed in an Estimation meeting how we could address this issue. The original proposal was to provide some indication of error status within the pop-up. However, this would be too much work, since we would need to build in support for such behavior with JavaScript. As an alternative, we decided to have more helpful messaging and support with the current error behavior (which is that user is redirected to the WSExport page, with an error message at the top). This ticket will aim to address this need.

Example page with error:

Acceptance Criteria:

  • What is the breakdown of the different errors experienced by users, based on the emails/logs?
  • What would be helpful recommendations to users who encounter each error types (i.e., should the user try again, or should the user try a different file type, or is it a lost cause?)
  • What support for next steps could we provide on the WSExport page? For example, can we identify a specific error type & then provide a relevant message based on that error type?
  • What would be useful information for llana to include on a Help page about WSExport errors?

Visual Examples:

Original proposal for error message (which we prob can't do):

Example of error message we are currently seeing:

Event Timeline

ARamirez_WMF renamed this task from Wikisource Export: Provide Indication of Error State from Download Pop-up to Investigate - Wikisource Export: Provide Indication of Error State from Download Pop-up [8H].Feb 11 2021, 6:33 PM
ARamirez_WMF moved this task from To Be Estimated/Discussed to Estimated on the Community-Tech board.
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)

Adding @Prtksxna & @nayoub, so you're aware of this ticket. No action required at this time, unless you have questions or concerns to voice, of course.

I have provided a brief description of how this ticket has evolved in the description above. Happy to discuss it in more detail with either of you, if you have any questions. Thank you!

@Samwilson Keep in mind that this is an "investigation" and no actual "code" is required.
Writing down what we discussed yesterday plus whatever you find regarding what error messages are worth handling (or not) is good enough. We'll create some tasks out of this and size them in our next estimation.

A few notes from what we talked about in the Engineering meeting the other day:

  • Without a job queue there's no easy way to get error (or progress, or success) messages displayed in the popup.
  • The alternative is how it works now: in case of an error the user is taken to the export form and an error notice box is displayed at the top.
  • This error box can be improved in a few ways:
    1. Translate the error messages.
    2. Provide a backlink to the page the user has just come from.
    3. Handle all errors that we can in the error-above-form display, rather than the generic white-page 500 error page (at the moment we only show Request and Http errors this way).
    4. Some errors, notably timeout ones now that we have caching enabled, can go away on a second try; tell the user this.
    5. Add better (non-retry) errors for books we know will just keep failing โ€” e.g. T222690: Wikisource Exports: Show useful error if more than N subpages are found
    6. Add a link to a wiki page where we describe the different types of common error.
    7. Some sorts of errors are from wikitext or template/module problems, and we can help editors fix these (e.g. highlighting epubcheck validation errors; this is probably not something we'd want to do on every error though, but only on request, e.g. via a new options checkbox).

There are some error messages that are very unlikely to be displayed to users coming from an on-wiki link (either in the sidebar or the popup), because the language code, book title, and format are provided automatically and so will never be incorrect (although we might add functionality in the future to make it possible to change these).

@Prtksxna, @nayoub, and I have discussed this ticket a bit, and some things that are recommended for the user experience (whenever we implement the outcome of this investigation should include):

  • Short and to-the-point language on cause of error and next steps
  • Lengthier explanation of error could be in a separate pop-up or documentation page accessed by clicking on a link within error text
  • Fields should be pre-populated with selection previously made that resulted in error (in case user wants to try again)
  • There should be an easy way to go back to Wikisource (perhaps a button on the top of the page or next to the error statement)

Note: We have discussed this in our meeting, and all of the points above (other than #2) seemed doable and useful to users, according to @dmaza. We discussed that #2 can be for a more generalized documentation page instead, which provides info on common errors and next steps. We will invite community members to help improve and expand the page.

This investigation is complete. We have decided to provide guidance and support when ebook export errors occur on the Wikisource Export page rather than in the download pop-up for two reasons: 1) It is much more manageable in terms of technical complexity & scope, and 2) There are more options available to the user to take follow-up actions on the Wikisource Export page. This next stage of work on the Wikisource Export page is in progress: T277237. For this reason, I'm marking this ticket as Done.