Look into feasibility of letting users search for resources (TRAs, support services, etc) by location

[zarino]

Something mentioned by Rhiannon at SGTO.

We’ve had a “Directory of Residents Action Groups” earmarked for a while – https://fixmyblock.staging.mysociety.org/directory-of-residents-action-groups/ – but how would it work?

Does it need to be searchable by postcode? (Like finding your local councillors’ details on WriteToThem.) Or is it good enough to have resources categorised by region?

We’re going to wait to see whether anyone else brings up a searchable directory again. But in the meantime, this is something to stay aware of.

[zarino]

I’ve done some more thinking on this over the last sprint.

Location-based search will be hard to get right. Some support services might have areas of effect (eg: only supporting tenants on a particular estate, or in a particular city or borough), so we’d need a way to model and query on that, like MapIt but for tenant support services. Meanwhile, search will be quite patchy until there’s lots of data in the database, which might leave users feeling like the site is quite "empty".

I think we want to get something up, that at least presents groups in an attractive way, and lets people browse or filter a list of groups by:

• Rough location – most likely, city name. Note: we also need to handle services without a location, and services with a national remit.
• Category – eg: TRA, law firm, union, etc. Seems unlikely we’ll ever have a group that matches multiple categories.
• Some way for people to quickly find TRAs or groups that have experience with particular types of issue. Tags feel like over-engineering here. Maybe just free text search instead?

I’m thinking the data we’d need about each group, to make it useful, would be:

• Group name
• Description – this can be multiple paragraphs, separated by line breaks.
• Contact URL ("where can I get in touch with this group?" – easier than us maintaining separate email addresses, phone numbers, etc.)
• Web page URL ("where can I find out more about this group?")
• Rough location
• Category
• Optional – Display address. Some services might be "local", so displaying an address might help people find and trust them. But we should be aware that some services might not have / need to display an address.
• Optional – Image. It’d help make the listing page look more engaging. We’ll need to think carefully about how to handle images of varying dimensions.

The database also needs to be easy for TBUK volunteers to edit. Rather than building something bespoke within Wordpress, I’m tempted to outsource the data editing to Google Sheets. The main advantages of this:

• The data can be easily exported / downloaded into a CSV or Excel file if TBUK ever want to migrate to another system, or even if they just want to download the data and analyse it in some other piece of software.
• Editing permissions for the sheet can be handled independent of the Wordpress site – eg: TBUK could give a volunteer or a third-party edit access for the sheet, without giving them edit access for the entire website.
• Google Sheets makes it easy to insert an image into a cell, and it takes care of hosting that image for you. The image will be accessible in the "publish to web" output, as long as the source Sheet has its sharing permissions set to "Anyone with the link can access".
• Quicker to develop – no need for complex PHP code to handle storing the data. All we need is the URL to a Google Sheet that has been "published to web". Client-side JavaScript can load the sheet over AJAX, pull out the data, and present it however we want. If JavaScript is unavailable, we can link directly to the Google Sheet’s public web URL as a fallback.

Thinking in more detail, here’s what we’d need to do:

• WordPress block that accepts a Google Sheet’s published URL, and displays some help text on how to set up your sheet and find the "publish to web" URL.
• Front-end HTML output for the block should display a nice fallback link to the given sheet, with progressive enhancement from JavaScript…
• JavaScript code to:
  • Ajax in the Sheet URL, loop through the <tbody> rows, building an array of group data.
  • HTML template to print the groups to the page, grouped by the rough location field, with headings.
  • Select box or segmented control to filter the list to all categories or a specific category.
  • Search box to filter the list by search term.

It seems inevitable that the spreadsheet data will get accidentally messed up at some point, so the JavaScript code will need to be resilient to the data not being in the shape / format it expects. Perhaps it could print out an error only if the user is logged in, so that admins can be notified about errors, but visitors just won’t see that particular column or row?