Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider more generic public body questions #1057

Closed
garethrees opened this issue Mar 14, 2022 · 7 comments
Closed

Consider more generic public body questions #1057

garethrees opened this issue Mar 14, 2022 · 7 comments

Comments

@garethrees
Copy link
Member

We've now built up quite a selection of pre-request questions for a handful of bodies, and some more on the way.

These attempt to minimise misuse, and the subsequent risk of misuse, as we find there are quite a few individuals who misunderstand the purpose of the service. While we haven't measured, there's a feeling that these have reduced misuse on at least some bodies.

We should reflect on our use of these, as they do have some downsides.

  1. They do add additional complexity to the codebase
  2. They add additional complexity for people who are intending to make a good FOI request
  3. As we get increasingly specific, we risk appearing like an official communication channel for that authority

I think the thing to consider is whether we can refactor the current questions into a more generic set that applies to all of the bodies identified as needing this extra step.

@mdeuk
Copy link
Collaborator

mdeuk commented Mar 15, 2022

Importing some comments I made elsewhere:

We should reflect on our use of these, as they do have some downsides.

1. They do add additional complexity to the codebase

2. They add additional complexity for people who are intending to make a good FOI request

The code complexity is a concern for me - the usability less so. Reason: It's a one stage click-through, choose the right option and the form appears.

The technical side may need refinement!

Elaborating on usability: The key thing here is simplicity - we render the public body questions where the request form would usually be (save for WDTK Pro, and if memory serves, users without JS enabled).

The form is a list of radio buttons, it's a one step process to click the option most applicable; therefore, provided the wording is plain and simple, there doesn't seem to be much risk here.

3. As we get increasingly specific, we risk appearing like an _official_ communication channel for that authority

This risk is minimised by being careful as to how we word things, and being clear about who/what we are.

If we do this, we can minimise the current risk - we've certainly had more than a few users in the past who, somewhat inexplicably, thought they were dealing with the public body directly. Quite how they manage it, I'm not sure.

IMO, we don't want to be seen to be giving advice on these matters - it's generally outwith our own expertise, and we can better serve people by linking to official sources, and / or reputable sources (e.g. Citizens Advice). We should always be clear as to why we're doing that.

The expansion of this toolset has been with the aim of minimising misuse in a number of public bodies where we see persistent patterns - there's possibly a good bit of anecdotal evidence there, but also general observations from WDTK team members. A common pattern is outlined in #722 and #745 - the TL;DR summary being:

"quite often we see the service being misused by folks trying to access information about themselves, or to make customer service queries to public bodies about sensitive matters. We need to act to minimise the risk."

I think the thing to consider is whether we can refactor the current questions into a more generic set that applies to all of the bodies identified as needing this extra step.

I don't think we can at the moment, based on the code that is in Alaveteli - without refactoring.

There's certainly some merit in looking at a generic "What are you asking for?" question, so I wouldn't be dismissive of us exploring the art of possible.

@RichardTaylor had noted in response to this point:

"I don't think the suggestion on the call actually was to make it generic across all bodies, but rather to take a more generic approach across those bodies where we have identified there is a significant problem of personal correspondence."

… in essence, however, I'm not sure we can always be so generic. The research that generated the questions proposed for #745 (comment) was based on identification of the key themes behind misuse for that type of body.

I don't think a one size fits all approach would work for all bodies, as it'd essentially just replicate the warnings that we already provide in at least two places during the new request workflow. We've refined these over years, and used public body notes to further outline our approach, but it doesn't necessarily dissuade users who see our service as a contact form. Providing a specific pointer may dissuade misuse. Perhaps there's scope for some a/b testing here?

With that said, I think a generic approach for bodies we haven't identified specific patterns of misuse / inappropriate usage from might be interesting - if we can make things more user friendly, and simultaneously reduce risk, it's to everyone's benefit.

@RichardTaylor
Copy link

I don't think we should replace the specific interstitial questions with a more generic approach where we've already got specific questions.

The suggestion is: Can we do something generic that we can easily add to a wider group of bodies?

To clarify what's been quoted from me, I'll add a bit at the end:

I don't think the suggestion on the call actually was to make it generic across all bodies, but rather to take a more generic approach across those bodies where we have identified there is a significant problem of personal correspondence but where we don't already have specific interstitial questions.

@garethrees
Copy link
Member Author

I don't think we should replace the specific interstitial questions with a more generic approach where we've already got specific questions.

I think we should consider this on the basis that I feel like we're a little at risk of looking too "official". I'm not saying there's definitely something we can change; just that we should consider this as we review what we have in place.

@mdeuk
Copy link
Collaborator

mdeuk commented Mar 15, 2022

I don't think we should replace the specific interstitial questions with a more generic approach where we've already got specific questions.

I think we should consider this on the basis that I feel like we're a little at risk of looking too "official". I'm not saying there's definitely something we can change; just that we should consider this as we review what we have in place.

Are we being more controversial than what we already do with the Home Office?

The risk with the benefits ones is there’s often special category information involved - so if we can dissuade them by offering a “you can’t do that here - use their website or contact an advice service” that seems a reasonable thing to do.

My suggestion here would be: we have a generic boilerplate which attaches to each question via an include - it would be no trouble to add a “why am I seeing this?” link that branches out to a help page which includes a reminder as to who we are and gives an overview of why the question appeared. It’s not strictly necessary, but it does feel like a nice to have.

@RichardTaylor
Copy link

A pre-request question requiring a user of the WDTK public service to confirm they understand they are making their request via our public service, and not directly and privately to the public body could, if carefully phrased, help prevent confusion between our site and official direct contact forms.

This would be extra friction for all users though. We could target it on bodies which receive sensitive direct correspondence eg. police forces.

@mdeuk
Copy link
Collaborator

mdeuk commented Jul 24, 2022

I ought to have noted this here - originally posted in #722:

Of note, our colleagues over in Australia have a nice generic "stop and think" speedbump that they deploy. The technical implementation is in /views/requests/new.html.erb and appears to be based on how many hidden requests a body has - nicely done!

@FOIMonkey has suggested reaching out to find out if this seems to be effective at reducing takedowns.

@HelenWDTK HelenWDTK added the stale Issues with no activity in over a year label Nov 17, 2024
@HelenWDTK
Copy link
Contributor

This issue is being closed due to a lack of discussion or resolution for over 12 months. Should we decide to revisit this issue in the future, it can be reopened.

@HelenWDTK HelenWDTK closed this as not planned Won't fix, can't repro, duplicate, stale Nov 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants