Identify exemptions used in correspondence

[garethrees]

Automatically identifying what exemptions have been used in a refusal​, makes it quicker and easier for users to understand the grounds for an appeal. Once a user knows which exemption has been used, they are in a better position to examine whether it has been correctly applied and to rebut it effectively.

The goals for this feature are to:

1. Pull out exemptions that have been used in correspondence
2. Help the user understand the basic implications
3. Encourage them to challenge them

On the request page we’ll add a panel to the incoming message that shows any exemptions we’ve been able to identify.

Our initial version of the identification will be quite basic, so we’ll have to be clear that these are possible exemptions. The exemptions should be separate from the incoming message body. It will be too complicated to manipulate the HTML generated for the message body in the time we have available. We won’t add any sort of learning or ways to remove the identified exemptions.

We should list each exemption that’s identified. Each exemption should have a name, a short description explaining what the exemption is about and its implications. We’ll possibly add a link that will take the user to a help page about that exemption.

We won’t trigger any automated decision making at this point. A user will still have to manually classify their request as refused to be pushed into the flow to challenge a refusal. Identifying exemptions helps give the user a leg up in understanding that “refused” is the option they need to pick, and that’s what will take them into the flow for challenging the refusal.

[zarino]

So, the most obvious treatment here is to reuse/expand the existing .correspondence_delivery styling, and either present the message at the top or the bottom of the authority’s reply:

This is quick and easy for us to do, but I’m a bit worried it’s adding an action in a place that actions don’t currently exist (ie: in the middle of the otherwise read-only correspondence elements) and it feels a bit contradictory to the two absoluely gigantic "describe state" boxes above and below the correspondence thread.

Indeed, those "describe state" boxes already contain a "my request has been refused" option. They feel like the most logical place, to me, to put anything related to taking the next step after a refusal. Maybe something like this, where the checkboxes are pre-ticked, based on which terms were detected in the correspondence?

In effect, we’re just pulling the first question of the checklist forward by one page, because our automated scanning has detected that it’s likely the request has been refused.

[gbp]

@zarino I see issues with the second option. 1. it would need to be reworked for the Pro interface. 2. this form isn't always shown, EG when the request has been already been classified. How would a user start the refusal wizard in this case?

[zarino]

@gbp Yeah, in those two cases, I guess the user would (re)classify the request into the "refused" status, and then we’d need to show them a little message that lets them find out what to do next. But yeah, seems a shame to duplicate stuff :-/

Maybe we just stick with the first option (which is here: 53d3219) and see how it feels.

It does make me wonder, though, whether the checklist UI (#5910) should include a copy of the last piece of incoming correspondence in a request thread (including its attachments), so that when you’re answering the "which exemptions did the authority mention?" question, you’ve actually got their response in front of you. Maybe that’s something to cover in #5910.

[garethrees]

I see issues with the second option.

Yeah, I agree with @gbp's notes that this gets complicated due to the different interfaces. The "describe state" form itself is also pretty complicated, so I was thinking to avoid adding yet more Things to it.

I’m a bit worried it’s adding an action in a place that actions don’t currently exist

I wasn't necessarily thinking we'd make it an action. To get to our checklists, the user will still need to use the describe state form to put the request into the "refused" state. Perhaps the "action" could be to initiate a smooth scroll down to the describe state form. If the request is already classified as refused, then maybe we could link through to /help/unhappy.

Maybe we just stick with the first option (which is here: 53d3219) and see how it feels.

Yeah, I agree that this is not perfect, but it's a relatively quick option that doesn't result in us needing to go down several rabbit holes. Maybe we'll circle back to improve the describe state form if we have time near the end of the project.

I think we we should tone it down a little in terms of appearance and how confident we sound about having identified an exemption (currently, if I asked "How many Section 12 exemptions have you used this year?" and the authority quoted that in the reply, we'd trigger the identification")

[zarino]

I wasn't necessarily thinking we'd make it an action. To get to our checklists, the user will still need to use the describe state form to put the request into the "refused" state.

Oh, okay, I was assuming that them clicking that "find out if you have grounds for appeal" button would both set the state to "refused" and then send them to the /help/unhappy checklist with the "detected" exemptions pre-checked. Since, I figure, if they’re wanting to take the next step in challenging a refusal, it’s pretty safe to assume their request has been refused. Is that not a safe assumption?

Taking a different tack, I wonder whether maybe a less opinionated message might help…

I’m imagining that the link would go to /help/unhappy, and the first question in the render_refusal_advice form would repeat this idea of "exemptions detected in your most recent response" (or whatever) so people know why some of the checkboxes are pre-ticked.

Still leaves the issue of when the request status gets set to "refused". Feels awkward making them fill in the yellow box. I wonder whether we could set the request to "refused" once we know that they’ve got further through our refusal workflow? eg: set the request to refused once they’ve clicked one of the suggested "action" buttons (reply for confirmation, or request an internal review) from the checklist?

[garethrees]

I wasn't necessarily thinking we'd make it an action. To get to our checklists, the user will still need to use the describe state form to put the request into the "refused" state.

Oh, okay, I was assuming that them clicking that "find out if you have grounds for appeal" button would both set the state to "refused" and then send them to the /help/unhappy checklist with the "detected" exemptions pre-checked. Since, I figure, if they’re wanting to take the next step in challenging a refusal, it’s pretty safe to assume their request has been refused. Is that not a safe assumption?

I didn't think so when originally writing this up:

A user will still have to manually classify their request as refused to be pushed into the flow to challenge a refusal. Identifying exemptions helps give the user a leg up in understanding that “refused” is the option they need to pick, and that’s what will take them into the flow for challenging the refusal.

My concerns with enacting the flow at the "exemption identification" point, is that:

• We may have a false positive
• There may be more than one incoming message that contains exemptions
• The incoming message may have exemptions that we haven't identified
• It's pretty different to normal classification; I think it's conceptually easier to understand that for any given classification option I classify the request then I take a next action. I could certainly be persuaded otherwise on this, but it's not something we've considered much in this context, and I'm keen to avoid a big sprawl in complexity before we tackle some of the other issues in this project.

All of the above makes me want to push users through the "normal" mechanism for classifying the request.

Taking a different tack, I wonder whether maybe a less opinionated message might help…

Yeah, this feels much more appropriate for where we are right now, taking into account the wider picture of how the app works. I was very much imagining this more akin to a password strength hint.

I think we still need to really work on the wording. Imagine you've made your first FOI request and had a refusal. What's an "exemption"? What's "Section 12". We obviously don't want to make this section gigantic, but equally we want to set the scene for what's about to come (a challenge from the user, hopefully!)