As someone with access to a submitted audit, I want to be able to view my submitted audits.

[melchoyce]

Breakout issue of #339.

This issue covers the design of previewing submitted audits.

Background

We've been discussing the possibility of editing submitted audits, and it looks like that's off the table per this info from @jadudm:

Once the Clearinghouse (the legal entity which implements the systems that handle the audits — meaning, the GSA) accepts an audit, it triggers a process. Specifically, agencies have a limited amount of time to respond to the audits once they are “accepted” by the Clearinghouse. If we allow editing after submission, we have a number of complex challenges to deal with: What if there is s submission one day before it is due, an agency pulls the data later that night, and begins their evaluation processes the next day.

1. One week later, an auditor discovers an error, and wants to edit. Is the audit still on time?
2. The audit has already been reviewed, and there are findings. What if the edits obviate the findings? What should the agency do?
3. The audit has not yet been reviewed; how do we indicate to the agency that this particular audit needs to be downloaded again? How do they keep track of the versioning. (We might have a database; they might have a person armed with a spreadsheet.)

There are more questions, no doubt, but they all have implications.

1. Being late is considered Rather Bad™. It has legal implications, and the grantee can be labeled a “risk,” lowering their changes of receiving future Federal grants.
2. The process of reviewing the audits is time consuming and critical to oversight; how do we “track changes,” or do Federal agencies have to try and manage the differences between two PDFs that might be between 20 and 200 pages long? What processes or policies even exist for such a situation?
3. We know we need notifications, but this becomes very complex very quickly, especially with pass-through entities.

However, we found in interviews that people expect to see their submitted audits within the audit list, so we need some way to handle that. @austinhernandez's latest design has them listed as such:

We need to figure out what happens when someone clicks to view that submitted audit, since they won't be able to edit. Some possibilities:

• We replace the audit pages with a single summary page where users can download their submitted audit
• We display the audit pages as read-only with a notice explaining that since the audit is submitted, they can't made additional changes
• Something else?

@tadhg-ohiggins would love your and the devs' input on what's feasible here for an MVP.

Acceptance criteria (We'll know we're done when...)

• [ ] We've figure out an approach for users to view their submitted audits.

Tasks

• [ ] Explore potential options with input from engineering
• [ ] Design the decided-upon approach
• [ ] Peer review
• [ ] Write implementation notes

Definition of Done

• [ ] Screens in Figma are ready to be handed off to front end
• [ ] All text has a contrast ratio of 4.5:1 with the background
• [ ] Interaction are documented if they deviate from USWDS components
• [ ] The needs of someone navigating the site with the use of a screenreader or keyboard has been considered and documented
• [ ] There is supporting documentation for alt text, labels for links (anchor + target), error text in forms, and what assistive technologies should announce (if applicable)

[melchoyce]

We chatted this over in our design/dev sync today, and it sounds like this won't be feasible for the MVP:

We display the audit pages as read-only with a notice explaining that since the audit is submitted, they can't made additional changes

Some other options that came up:

• The submission is listed in the table, but the report ID isn't a link. The table row would just be informational.
• Show a "you can't edit" notice on every page and then if someone tries to save, return an error.
• Instead of directing to the submission edit page, the report link generates a CSV download.

[austinhernandez]

Totally agree. The UI heuristics I want to be mindful of are:

• Help users recognize, diagnose, and recover from errors: Its fine if things are out of scope, but error messaging should be clear and recognizable.
• Help and documentation: the system should be user-friendly enough not to warrant any additional explanation. However, it may be necessary to provide documentation on things like this, so there is help for how to complete tasks.

I think this is a bigger issue of:

1. "where do we point people to help?"
2. "who is the point person for updating things like the cognizant agency list?"
3. "where do we collect and document these things that may need to be on an FAQ or need additional testing?"
   • list of testing related questions on https://github.com/GSA-TTS/FAC/issues/150

[melchoyce]

After chatting about this in our design sync today, we've decided the simplest option is:

Instead of directing to the submission edit page, the report link generates a full export of the submitted report and prompts a download.

[petermarks-gsa]

@melchoyce Thinking this through, generating a full export of the submitted report in a useful format is potentially a large lift and is possibly more in line with the goal of the second (non-MVP) data dissemination release. Can we quantify the user impact of not being able to do this for MVP?