Styling for gendered progress bar

[zarino]

Part of #277.

I've only done the styling so far, but it looks like this:

Ready for @chrismytton to make the javascript correctly update the right part of the progress bar on each swipe (harder than it sounds, I think).

[chrismytton]

(harder than it sounds, I think)

Yep! We're not actually keeping track of which choice you make currently, we just move the card to show that you've made some choice. The progress bar is currently updated by counting the number of remaining elements on the page and subtracting that from the total elements. To make this change work we'd need to keep track of choices somewhere then use that to calculate the widths of the bars for the various choices.

[tmtmtmtm]

I think there two distinct issues here:

1. How to display the bar when you first load the page (as it may already be part-filled)
2. How to adjust the bar as you go

The first seems like a fairly simple db query (once we tidy up potential duplicates that are still hanging around from undo etc). The second is complicated a little by undo, but it shouldn't be too hard to draw the progress bar based a simple hash with a running count of Yes/No/Other etc that gets incremented (or decremented) on each choice, no?

[chrismytton]

Yea I think keeping a running total is the way to go, I was a little confused about the best way to pass that total around but I think just keeping it in a global value should be fine for our needs.

We also need to make sure the running total in the javascript is updated with the server side data at page load. That shouldn't be too tricky as we're already doing something similar to tell the javascript how many people there are in total using data- attributes on the progress bar.

[tmtmtmtm]

Yea I think keeping a running total is the way to go, I was a little confused about the best way to pass that total around but I think just keeping it in a global value should be fine for our needs.

What does the calculation look like for setting these new divs? I can't quite tell from the CSS, but it looks like it's meant to just be a %. If so, then couldn't we just calculate how much to increment that by on each swipe (or decrement on an undo), and adjust accordingly, without actually needing a separate total? (i.e. the current size of the bars themselves would be the running total) — i.e. if the total number of people is 200, each swipe would add 0.5% to the relevant bar, etc

[chrismytton]

@zarino This is what it looks like currently, you can also play with it on the staging app's onboarding.

It looks a bit weird when you pick "Woman" or "Other" first because the left edge of the progress bar is squared instead of rounded. Do you think it's ok as-is to go live or would you like to tweak it a bit before I merge it?

[zarino]

Hmmm, the square edge is really annoying. I'll take a look at it today and see whether I can find a simple way of rounding the correct edges.

[chrismytton]

@zarino Great, thanks!

[zarino]

Oh @chrismytton – I've done some refactoring: https://github.com/everypolitician/gender-balance/commit/917b0b92e761f96a8d39426a95c41f969a5b2dfa

Previously the progress bar segments were present in the DOM but hidden. Now, they're created by javascript, only when they're required. This means the CSS :first-child / :last-child selectors work as expected (no "hidden" first-children getting in the way) so you get rounded corners.

While I was there, I also removed the "pre-loaded" progress bar stuff into javascript, rather than the template including the elements with its own percentage width logic. This meant we can re-use the same getProgressBarSegment function, which does the hard work of working out whether a segment already exists, and creating it if it doesn't.

[chrismytton]

Woo, thanks @zarino! :+1: