Improved alerts creation flow and dashboard

[ajparsons]

This ticket is about improving the user interface of managing alerts, and the database changes that might be needed to support that.

The main goals are to:

• Make it easier to add more complicated queries (including prompting on possible alternate terms)
• Make it easier to review and manage existing queries.

Worth referring to the user stories from past research .

Adding more complicated queries.

We want a better flow for creating keyword email alerts.

This might double as an alternative/improvement to the advanced search interface.

What we specifically want is to make it simpler to do ORs - both manually and using suggestions from our similarity data (as in cape).

The thinking here is for political monitoring, it's less complicated AND NOTs, and more 'here is a list of related terms I want to know about'.

One possible flow is:

• I want to create an email alert
• enter terms and filters (new form)
• would you like to also include any of the following suggested terms (tickboxes)
• search preview of the results, would you like to revise?
• set frequency, and name of alert (name might be suggested from first term).

Doesn't have to be this exactly, but we want a clear flow - some screenshots with notes on existing process in this doc - and especially something that's very clear how to make it work for devolved parliament searches.

This flow should also work to modify existing alerts.

For person based alerts - need to be able to select if it's speeches AND votes or just one of those.

Managing multiple alerts

Having more complicated alerts - we want an interface that helps us manage and view them. This dashboard should in a minimal way make the alerts useful even without checking emails.

We want to be able to:

• View all queries - and be able to sort by name, date created, or the last time the alert found something.
• Have a link to modify a query rather than just removing it.
• Be able to click through from the query to the search results (see below, but this might include some customisation of the search page).

Additional information this might mean storing:

• date of last match (this might be single last match date - or alternatively a json dict of key statistics - e.g. hits all time, last year, last month, last day, last_date matched)
• store longer queries (complex queries might plausibly be longer than 255).
• As in CAPE, similarity table to help find similar terms see data - this is basically term_a, term_b, distance between 0.1
• names for queries

Why names for queries

More explanation on that last one. Using vector derived similarity, we're going to get longer queries:

e.g.

"offshore wind" OR "offshore renewable energy" OR "offshore renewable" OR "offshore energy" section:scotland

If displaying this in the interface, it'd be helpful to be able to label this 'offshore wind (SP)' so it's clear in a list what it's trying to be. Might also need a longer description field. Potentially this could then be used as a shortcut into the search e.g. https://www.theyworkforyou.com/search/?stored_query=offshore_wind_sp.

This might be useful if wanting to display some information about the query above the actual search results. Obvs people can already share query links, but could attach some extra information to share with other members of team/orgs.

Possible problems

The 'let people have weekly digests' and 'let people use it as a web interface' might be in conflict, where 'a new match' wouldn't be flagged for weekly alerts unless you ran them all every day anyway. I think this would be fine if you labelled the column right.

(i guess also an approach where you always do a count for the last day for all queries to update that number).

[struan]

This is going to require input from a designer.

[ajparsons]

Do you think before/after or both?

[struan]

I think ideally before. It's much easier to have a clear "this is the form that we would ideally build" and then to turn that into code than me to try and bodge something roughly correct and then fix the ux post-hoc. At least for me.

[ajparsons]

I'll put up the designer bat signal.

[ajparsons]

@lucascumsille has said he should have time - scheduled a chat for Monday.

[ajparsons]

Just dropping a screenshot of CAPE:

[ajparsons]

Screenshots of the process: https://docs.google.com/document/d/1Jx4wTlyr69HJXzTEHKCTpjMhKCy4V1MuWW3MxPetAkI/edit#heading=h.x9qyu5uq46xr

What I'd recommend as part of this is trying to make a keyword alert in the existing interface and getting a sense of the fiddly bits of the flow.

[dracos]

If it makes any difference to anything, from the receiving-of-alerts point of view, there's no real difference between having one alert for "offshore wind" OR "offshore renewable energy" OR "offshore renewable" OR "offshore energy" section:scotland, and having four alerts for "offshore renewable" section:scotland, "offshore wind" section:scotland, "offshore renewable energy" section:scotland, "offshore energy" section:scotland. You'd get more results in the email with the latter (at present), as each one would include up to 3 results. Guess there's pros and cons either way. But conceptually for me, I find having a number of different alerts easier than trying to make sure I've got my boolean logic correct...

[ajparsons]

Yeah - I'm happy to be led with what's best for the interface there.

Either way it's possible to name/group them - just needs a different approach - are we talking about a named query with lots of ORs, or a group name that multiple queries have connections to.

Having them in one (constructed) OR query does mean you can see the preview for the group in one search - but that might not be hugely important either way.

Do we have a performance preference between more simpler queries or fewer more complicated ones?