You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On 7 June 2023 @HelenWDTK wrote:
The contact form has now become the primary way that our users and public authorities get in contact with us. To improve our handling incoming reports, we should consider adding some more structure to these, that would allow us to automatically categorise them in our inbox, akin to how we manage reports made via the report links. This could be achieved by presenting users with a selection of topics that, when chosen, insert specific identifiers in the subject line indicating the nature of the issue. We could detect this text, and triage the report by auto labelling it.
The upcoming 'Report a Data Breach' form will significantly improve our handling of these, however, my ideal setup would involve being able to make a clear distinction between critical, time-sensitive, risky matters (those that would receive a !Risk label/GDPR requests), and routine inquiries such as site operation questions, basic FOI assistance,
feature suggestions, and users seeking requests being submitted on their behalf.
Frequently, site operation inquiries and basic FOI questions can be addressed by directing users to a help page or
ICO guidance. One approach could be to guide users through a series of questions about their query before
presenting them with the contact form. This approach would be designed to resolve their query before they submit it,
and could potentially reduce the volume of incoming inquiries.
In implementing these changes, it's important that we continue prioritise accessibility and overall user experience. We
don't want the form to be challenging to navigate or annoying to use.
On 07 June 2023 @mdeuk wrote:
Frequently, site operation inquiries and basic FOI questions can be addressed by directing users to a help page or ICO guidance. One approach could be to guide users through a series of questions about their query before presenting them with the contact form. This approach would be designed to resolve their query before they submit it, and could potentially reduce the volume of incoming inquiries. That's the very one we discussed recently - I think a small proof of concept, using a tool such as EnquiryWitch, might be a good way forward.
Implement a mechanism for solving queries before the form is submitted
1. Implement a mechanism for auto-labelling queries
Given we'd want the first of these anyway, we'll focus on that for now.
The first step we can take here is to add a field to the form that asks what the topic is:
@HelenWDTK We'll need a list of these topics in user-facing language, and what label they would map to.
We could detect this text, and triage the report by auto labelling it
We've got a couple of options for this:
Use the subject line
Add to the body text
Use a CC address like GitHub does.
What we pick here will probably depend on the list of topics.
2. Implement a mechanism for solving queries before the form is submitted
Frequently, site operation inquiries and basic FOI questions can be addressed by directing users to a
help page or ICO guidance.
Once we have a topic field in place, we can dynamically render a sidebar that provides the most relevant signposting for the query. This isn't as good as a Q&A system, but it's a more achievable first step.
In terms of implementation, we could easily map the fields in the select box to a partial to render dynamically, e.g:
FOI Help → views/help/contact/_foi_help.html.erb
Account Help → views/help/contact/_account_help.html.erb
etc...
using a tool such as EnquiryWitch
I think this is a bit far from where we are right now. This might be something to consider to integrate with mysociety/alaveteli#7764.
We'll need a list of these topics in user-facing language, and what label they would map to.
That would depend on how many options we'd want to usefully add/exactly how we'd phrase them eg topics vs
questions.
So we could have:
"I'm having trouble using WhatDoTheyKnow" -> Help/Basic site use
"I've got a question about how WDTK works" -> Site operation query
"I've got a question about FOI" -> Help/Basic FOI
"I'd like someone to make a request for me" -> seeking volunteer
For risky things, we could have:
"I'd like to report a legal issue" -> !Risk
"Someone is harassing me" -> !Risk/Harrassment
"Someone is pretending to be me" -> Risk/Impersonation
"You are publishing information that infringes my Copyright" -> Risk/Copyright
"You are publishing material that is defamatory" -> Risk Defamation etc
OR
We could go more topic based eg have a heading "Legal issues" then bullets:
Copyright -> !Risk/Copyright
Defamation -> !Risk/Defamation
Other -> !Risk
etc
I would suggest avoiding 2 if we can - filtering in the body is a nuisance to do.
My suggested approach would be to use a mail header, as that would fit in with our automation a bit better... in essence, shunt the labelling work to the Monster.
Internally, we already use the following headers
Why? Currently, we have an occasional issue where Gmail will thread messages from different senders, if they have
the same subject[ 3], so this would solve that problem.
If minded to do so, writing a header with the logged in user would be helpful for the Monster, as it would allow for more consistent linking to logged in user profiles. We currently do this by using the "logged in as" text in the body, gripping it, and then using the public API. That's a bit of a resource bottleneck.
using a tool such as EnquiryWitch
I think this is a bit far from where we are right now. This might be something to consider to integrate with mysociety/alaveteli#7764.
It's certainly aspirational. The tool is JS, so it probably wouldn't be too difficult - from early experimentation, the bits we
need to interface around are the help controller. The benefit here is that you can have a guided workflow, so it's one to
ponder. In any case, step 1 will help with enabling this (or another solution!).
Footnotes
Messages from Monster, Tracker, the volunteer form, and forthcoming report a breach form ↩
reuse the logic from the volunteer form, with a slight simplification. This could also be presented in the "Thanks,
we've got your message" flash, as it gives the user something they can quote to us in the future. ↩ ↩2
I would surmise it is because the do-not-reply-to-this-address from header is getting used. ↩
My suggested approach would be to use a mail header...
Ah, I'd thought about a header but didn't think we could label based off that. Of course, the Monster is a clever
monster! One advantage of the subject line approach is that it would be more useful for other Alavetelis, but I do like
the cleanliness of a header not adding a load of "internal" stuff to the mail that ends up going back and forth with
users.
I think let's start with the form location and topic (i'd call the more like X-Alaveteli-Source and X-Alaveteli-Topic, but details details) to get the framework of this in place, and then we can add the extra bits as incremental improvements once we've got the two pieces talking to one another.
That would depend on how many options... how we'd phrase them eg topics vs questions.
What do we do on our (mySociety) other contact forms? Can probably learn from those.
I think there's a balance between easy to use and useful to us.
We can probably balance between topics vs questions by using an optgroup – topics as the label and then questions as the option.
As to what feels like a right number? I'd guess 5 +/- 2 optgroups and then 5+/-2 options within each would be some reasonable boundaries.
On 13 June 2023 @garethrees wrote:
It would also be good to build this in such a way that we can set a custom topic from anywhere in the app.
For example, we're currently building an authority performance tracking page that has a "contact us" so that users can contribute to this tracking.
It would be good if we could add in arbitrary topics <%= link_to 'let us know', help_contact_path(topic:
'Authority performance issue') %>. Perhaps this initially just sets the topic to "other/something else" (if no
match is found) and then sets the subject to the value ("Authority performance issue").
On 16 June 2023 @garethrees wrote:
Next step is to answer the questions from the above.
On 16 June 2023 @HelenWDTK wrote:
WTT gives you options for queries that are best answered by some means other than contacting the team
FMS use radio buttons with limited options
TWFY doesn't have a form.
General mySociety points to each service, then has an option for selecting which one you're writing about:
Does topic + question using a select with optgroups seem okay, given the above?
Yes, despite being out of sync with other services. The volume and diversity of correspondence that these receive will
be much less than with WDTK
If so, what are the actual groups and questions we want to use?
Let's keep it simple to start with, and try something like.
Legal:
"Someone is harassing me" -> !Risk/Harrassment
"Someone is pretending to be me" -> Risk/Impersonation
"You are publishing information that infringes my Copyright" -> Risk/Copyright
"You are publishing material that is defamatory" -> Risk Defamation
"I have another legal issue" -> !Risk
FOI & EIR help
"I've got a question about FOI/EIR" -> Help/Basic FOI
"I'd like someone to make a request for me" -> admin action: volunteer makes request
Technical
"I'm having trouble using WhatDoTheyKnow" -> help/Basic site use
"I've got a question about how WDTK works" -> help/site operation query
"I've got a great idea for a new feature" -> help/user-feedback
Personal Information
"I'd like you to stop publishing my name" -> GDPR&DPA/Rt. to Object
"I'd like you to delete the information that you hold about me" -> GDPR&DPA/ Rt. to Erasure
"I have another query about your processing of my personal information" -> GDPR&DPA
Feel free to tweak the wording at will.
On 5 October 2023 @garethrees wrote:
In implementation we'll want to be able to add topical items in on short notice (via codebase is fine; doesn't need to be
on admin interface), but it should be as easy as adding some values to a hash and making a deploy.
The text was updated successfully, but these errors were encountered:
Replaces #740, which was deleted in error:
On 7 June 2023 @HelenWDTK wrote:
The contact form has now become the primary way that our users and public authorities get in contact with us. To improve our handling incoming reports, we should consider adding some more structure to these, that would allow us to automatically categorise them in our inbox, akin to how we manage reports made via the report links. This could be achieved by presenting users with a selection of topics that, when chosen, insert specific identifiers in the subject line indicating the nature of the issue. We could detect this text, and triage the report by auto labelling it.
The upcoming 'Report a Data Breach' form will significantly improve our handling of these, however, my ideal setup would involve being able to make a clear distinction between critical, time-sensitive, risky matters (those that would receive a !Risk label/GDPR requests), and routine inquiries such as site operation questions, basic FOI assistance,
feature suggestions, and users seeking requests being submitted on their behalf.
Frequently, site operation inquiries and basic FOI questions can be addressed by directing users to a help page or
ICO guidance. One approach could be to guide users through a series of questions about their query before
presenting them with the contact form. This approach would be designed to resolve their query before they submit it,
and could potentially reduce the volume of incoming inquiries.
In implementing these changes, it's important that we continue prioritise accessibility and overall user experience. We
don't want the form to be challenging to navigate or annoying to use.
On 07 June 2023 @mdeuk wrote:
Frequently, site operation inquiries and basic FOI questions can be addressed by directing users to a help page or ICO guidance. One approach could be to guide users through a series of questions about their query before presenting them with the contact form. This approach would be designed to resolve their query before they submit it, and could potentially reduce the volume of incoming inquiries. That's the very one we discussed recently - I think a small proof of concept, using a tool such as EnquiryWitch, might be a good way forward.
On 7 June 2023 @garethrees wrote:
There are two steps here.
1. Implement a mechanism for auto-labelling queries
Given we'd want the first of these anyway, we'll focus on that for now.
The first step we can take here is to add a field to the form that asks what the topic is:
@HelenWDTK We'll need a list of these topics in user-facing language, and what label they would map to.
We've got a couple of options for this:
What we pick here will probably depend on the list of topics.
2. Implement a mechanism for solving queries before the form is submitted
Once we have a topic field in place, we can dynamically render a sidebar that provides the most relevant signposting for the query. This isn't as good as a Q&A system, but it's a more achievable first step.
In terms of implementation, we could easily map the fields in the select box to a partial to render dynamically, e.g:
I think this is a bit far from where we are right now. This might be something to consider to integrate with
mysociety/alaveteli#7764.
On 7 June 2023 @HelenWDTK wrote
That would depend on how many options we'd want to usefully add/exactly how we'd phrase them eg topics vs
questions.
So we could have:
"I'm having trouble using WhatDoTheyKnow" -> Help/Basic site use
"I've got a question about how WDTK works" -> Site operation query
"I've got a question about FOI" -> Help/Basic FOI
"I'd like someone to make a request for me" -> seeking volunteer
For risky things, we could have:
"I'd like to report a legal issue" -> !Risk
"Someone is harassing me" -> !Risk/Harrassment
"Someone is pretending to be me" -> Risk/Impersonation
"You are publishing information that infringes my Copyright" -> Risk/Copyright
"You are publishing material that is defamatory" -> Risk Defamation etc
OR
We could go more topic based eg have a heading "Legal issues" then bullets:
Copyright -> !Risk/Copyright
Defamation -> !Risk/Defamation
Other -> !Risk
etc
On 7 June 2023 @mdeuk wrote:
I would suggest avoiding 2 if we can - filtering in the body is a nuisance to do.
My suggested approach would be to use a mail header, as that would fit in with our automation a bit better... in essence, shunt the labelling work to the Monster.
Internally, we already use the following headers
Why? Currently, we have an occasional issue where Gmail will thread messages from different senders, if they have
the same subject[ 3], so this would solve that problem.
If minded to do so, writing a header with the logged in user would be helpful for the Monster, as it would allow for more consistent linking to logged in user profiles. We currently do this by using the "logged in as" text in the body, gripping it, and then using the public API. That's a bit of a resource bottleneck.
It's certainly aspirational. The tool is JS, so it probably wouldn't be too difficult - from early experimentation, the bits we
need to interface around are the help controller. The benefit here is that you can have a guided workflow, so it's one to
ponder. In any case, step 1 will help with enabling this (or another solution!).
Footnotes
we've got your message" flash, as it gives the user something they can quote to us in the future. ↩ ↩2
On 8 June 2023 @garethrees wrote
Ah, I'd thought about a header but didn't think we could label based off that. Of course, the Monster is a clever
monster! One advantage of the subject line approach is that it would be more useful for other Alavetelis, but I do like
the cleanliness of a header not adding a load of "internal" stuff to the mail that ends up going back and forth with
users.
I think let's start with the form location and topic (i'd call the more like X-Alaveteli-Source and X-Alaveteli-Topic, but details details) to get the framework of this in place, and then we can add the extra bits as incremental improvements once we've got the two pieces talking to one another.
On 12 June 2023 @garethrees wrote
What do we do on our (mySociety) other contact forms? Can probably learn from those.
I think there's a balance between easy to use and useful to us.
We can probably balance between topics vs questions by using an optgroup – topics as the label and then questions as the option.
As to what feels like a right number? I'd guess 5 +/- 2 optgroups and then 5+/-2 options within each would be some reasonable boundaries.
On 13 June 2023 @garethrees wrote:
It would also be good to build this in such a way that we can set a custom topic from anywhere in the app.
For example, we're currently building an authority performance tracking page that has a "contact us" so that users can contribute to this tracking.
It would be good if we could add in arbitrary topics <%= link_to 'let us know', help_contact_path(topic:
'Authority performance issue') %>. Perhaps this initially just sets the topic to "other/something else" (if no
match is found) and then sets the subject to the value ("Authority performance issue").
On 16 June 2023 @garethrees wrote:
Next step is to answer the questions from the above.
On 16 June 2023 @HelenWDTK wrote:
WTT gives you options for queries that are best answered by some means other than contacting the team
FMS use radio buttons with limited options
TWFY doesn't have a form.
General mySociety points to each service, then has an option for selecting which one you're writing about:
On 19 June 2023 @HelenWDTK wrote:
Yes, despite being out of sync with other services. The volume and diversity of correspondence that these receive will
be much less than with WDTK
Let's keep it simple to start with, and try something like.
Legal:
"Someone is harassing me" -> !Risk/Harrassment
"Someone is pretending to be me" -> Risk/Impersonation
"You are publishing information that infringes my Copyright" -> Risk/Copyright
"You are publishing material that is defamatory" -> Risk Defamation
"I have another legal issue" -> !Risk
FOI & EIR help
"I've got a question about FOI/EIR" -> Help/Basic FOI
"I'd like someone to make a request for me" -> admin action: volunteer makes request
Technical
"I'm having trouble using WhatDoTheyKnow" -> help/Basic site use
"I've got a question about how WDTK works" -> help/site operation query
"I've got a great idea for a new feature" -> help/user-feedback
Personal Information
"I'd like you to stop publishing my name" -> GDPR&DPA/Rt. to Object
"I'd like you to delete the information that you hold about me" -> GDPR&DPA/ Rt. to Erasure
"I have another query about your processing of my personal information" -> GDPR&DPA
Feel free to tweak the wording at will.
On 5 October 2023 @garethrees wrote:
In implementation we'll want to be able to add topical items in on short notice (via codebase is fine; doesn't need to be
on admin interface), but it should be as easy as adding some values to a hash and making a deploy.
The text was updated successfully, but these errors were encountered: