Label parliamentary elections as such, and label electoral divisions

[pmk01]

There's some inconsistency with how the widget labels different election types. Parliamentary elections seem to use [constituency name] election, while local elections uses [council name] [election type] [ward name]. In neither case is the electoral division labelled (eg ward or division). Compare screenshots below.

Parliament

Local

Can we:

1. Make it clear when something is a parliamentary election.
2. Add division name where appropriate.

[pmk01]

What I like about WCIVF is that we put these on two lines - the “UK Parliamentary by-election” header, followed by “West Lancashire constituency” subheading.

I think this is much clearer than UK Parliamentary by-election West Lancashire constituency which is quite a long sentence with a lot going on in it (or West Lancashire local election Ormskirk East ward).

[VirginiaDooley]

@chris48s Am I right to assume that the only way to add division here is to make another API call? Or add division to the postcode response (this doesn't seem worth it either). Unfortunately division isn't available on a postcode search. I'm just not sure that's the best move given current and upcoming traffic.

[chris48s]

I don't think I have this totally clear in my mind. When you say division, the thing you're looking for is the name of the electoral division? In this context, isn't that just post_name ?

[chris48s]

From the docs

"post_name": {
  "type": "string",
  "description": "Name of the division or post the winner(s) of this election will represent"
}

[VirginiaDooley]

You might be right and the data might be inconsistent. I thought I might use division_election_sub_type to infer (such as "c" for "constituency") the locality type that I could then add to the post name.

[chris48s]

Right, so the thing you want is the division type not the division name. It looks like this isn't exposed by the devs.DC API at the moment.

I think the ideal way to do this would be to expose that data point through the devs.DC API so the widget is making just one API request. I don't really hold this all in my head enough these days (particularly not what has changed in the last few years) to know if that is a matter of just exposing one more field or if this opens a big can of its a bit more complicated than that. I suspect the second one though.

One possible option to bodge this would be to look at the election type. For example

• parl.*, senedd.c.* or sp.c.* is always going to be "Constituency"
• senedd.r.* or sp.r.* is always going to be "Region"

but some election types don't unambiguously map to a single type For example

• mayor.* could be either "Local Authority" or "Combined Authority"
• local.* might be "Ward" or "County Electoral Division" (or "Parish" for Isles of Scilly - fun edge case)

so to do this properly, you really do need to pass the full division object from Every Election though the devs.DC API - although if you dig into it, there are some blank division_subtypes in there. For example I just checked https://elections.democracyclub.org.uk/api/elections/local.isles-of-scilly.st-marys.by.2023-05-22/ to see if it calls it a "ward" or a "parish" and division_subtype is just empty string :laughing:

One thing you could do here is write some logic for the simple cases (where the election type implies a single word for all elections of that type) and then fall back to a generic wording for the cases where it's complicated.

[VirginiaDooley]

Given everything else, this seems a very good next step:

One thing you could do here is write some logic for the simple cases (where the election type implies a single word for all elections of that type) and then fall back to a generic wording for the cases where it's complicated.

But I will discuss at standup and see what the team thinks. Thanks for the input!