fact-check-manager: The Fact Check Flow
Fact Check Manager (FCM) is designed to allow easy sharing of changes for any given document from any given app assuming the API requirements are met.
This page describes the flow of a given Fact Check Request from the user side in FCM only and does not deal with the backend handling of these requests. For information on the API, check the API reference.
Initial Request
When a fact check request is made from the initial application, outside of FCM, a new page is created within FCM that can be linked to from anywhere.
Users need to sign in through Signon to read and respond to a request. Anyone with a shareable preview link can also read it without signing in, but they need to sign in to respond.
Any signed in user with the link can respond, not just the recipients of the request. This is so that requests sent to shared inboxes can be responded to. Read ADR 002 for why.
To learn more about how we handle permissions, read the user access documentation.
The Diff View
When a user with access arrives on the request page, they will be shown a view indicating the changes made. This diff view contains all of the original formatting from the original document, and indicates where new content has been added, old content has been removed, and what content has been explicitly changed including the formatting.
By default, the removed content is red, the new content is green. Explicit minor changes to words and spellings are highlighted.
The Diff is capable of showing either a whole content block, or separate content blocks, depending on how the source application sends the data to FCM. Regardless, the process is the same for changes.
Note: If there is no previous version to compare to, the diff view will only show the current content without any formatting. This is by design, as there is no prior document from which changes have been made.
Once the user has considered the changes (or the whole document in the case of a new release), and they are signed in, they can move onto the response view.
Response View
The response view is a simple page giving the user the option to approve the changes with no modifications needed, or to flag any further changes with a note.
Note: The large text box allowing input is only displayed when a further change is requested.
Confirmation View
The user will then be given the chance to confirm their response before submission. Once the "Confirm and send" button is pressed, FCM will attempt to send the response to the original application that sent the FCM request in the first place, notifying the requester.
Response Sent View
There are two potential outcomes once the "Confirm and send" button has been pressed.
Successful Response
Assuming there are no errors at all, the user will be presented with a success message explaining what the next steps are:
It is at this stage that FCM sends all the information back to the application that made the original request.
Unsuccessful Response
If there is an error wherein the response has already been sent - likely due to another user getting there ahead of time, then the user is informed of such and told to ask any further questions on the relevant Zendesk ticket.
At this point, the flow is completed from the user side, and everything else is handled by the source application.
Note: There is a chance another error may occur at this stage. At which point a generic error message is shown to the user indicating something went wrong, and the user may try again. This may be reported by users in the relevant Zendesk ticket.