future project: make one phone call

[jnolasco]

Future project: someone clicks an "i want to make one phone call" button and it gives them a number, a script, and a form to fill out the update showing old value, and new value ____ for each field. Updating logistics have been the biggest challenge 3 storms in a row now, not really maps or anything... and i say this as a guy who made a map.

[miklb]

not sure if you saw, but someone is also looking at a virtual phonebank through Twilio that we might be able to tie all of that together with.

[jnolasco]

Needlessly high tech for my taste. I'd say just 1) dump api /shelters endpoint 2) javascript to pick a row at random that hasn't seen an update in a "while". 3) some basic html to put that phone number, current status, and a script of questions next to a form. It's likely that one wouldn't need to know Ruby explicitly and can just post directly to the endpoint barring no csrf restrictions. (Because if you wanted to find enough Ruby programmers to go work on this, you'd need to go back to 2006 :) ).

This version of the implementation isn't elegant but it would open up the set of people who can work on it much wider and it can be likely deployed anywhere as a cut-and-paste javascript vs. some third-party integration that might require exotic debugging ("I can't get the Twilio call center thing to see my computer headset." etc).

There would need to be a button to flag incorrect phone numbers too, because we have no actual idea is those numbers are actually accurate.

[miklb]

that's the goal. To be able to quickly and efficiently onboard a large group of volunteers and not duplicate work.however we wind up achieving that is still to be determined.

[nihonjinrxs]

Note that we've added a view of shelters not updated in the last 4 hours, which you can sort by last update descending: https://hurricane-florence-api.herokuapp.com/shelters/outdated -- Easy enough to add that to the API side too, if it helps.

We can also just add this as a page in the API app, where the data updates are done anyway, and use the Rails framework goodies to make it easy to provide direct updates within the call script.

[jnolasco]

If the rule is just "updated at < now-4 hours" then one could filter that pretty easily from the existing shelter endpoint in js (result.filter(x=> x.updated<now-4h)... using whatever comparison math and/or moment.js as necessary)

[jnolasco]

I've got an hour or two here, I'll try to make a proof of concept for a "make one call". it'll only work from desktop since we have to use the rails form that's in place. plan: left frame has a script, right frame has a randomly selected edit page from the "needs updating" list. Press button to spin the Wheel of Fortune (tm) and grab a new random entry. There's obvious flaws in coverage, but its' better than nothign.

[nihonjinrxs]

Following up here that the API now supports the endpoint at https://hurricane-florence-api.herokuapp.com/api/v1/shelters/outdated.

Regarding the "make one call", I think it might be worthwhile to actually make this a separate rails view taking the least recently updated shelter, and displaying the info (name, address) at the top with the phone number really large, then including the script below with the fields inline within the script, so that folks can fill in the blanks as they go through the script. We can either do save as you go (more work), or have a "Finish Call and Save Update" button at the bottom.

That would alleviate the need for a right pane for the form, so that the script should work from a phone, tablet or desktop.

Thoughts on doing that?

[jnolasco]

Absolutely it's best to build this in at the API level instead of a kludgey javascript thing. I didn't get very far with this because I got distracted yesterday by adding a layer that was requested to the map thing. If there's a Rails person with free cycles, I definitely support them implementing instead.

[miklb]

Riffing on this, if there was a separate volunteer view just for updates that outdated endpoint could be queued, and split among # of logged in users, or just a dynamic dashboard that updates in real time as other volunteers update.

Reducing duplicate efforts or manual coordination in Slack.

[nihonjinrxs]

There is already https://hurricane-florence-api.herokuapp.com/shelters/outdated, so if volunteers take the one off the top there, this should work.

Some kind of marker on the record to say "volunteer already working this update" would be good, as I don't think there's anything like that yet.

[miklb]

I’m just thinking through scenario there are a dozen folks calling at same time, how do we assure 3 of them aren’t calling same shelter at same time.

[jnolasco]

If you randomly select an outdated record (instead of taking from top) chances of a collision are relatively small (but higher than the average person would guess, google "birthday paradox" for math). In a "correct" scenario, you'd have a job queue -- perhaps even an Amazon Turk -- that assigns jobs to people and times them out (returns job to queue) if an update isn't filed with x minutes.

The quick and dirty way is shrug and admit, "hey, that's life" because there's 300 shelters needing updates and realistically if any 10 volunteers pick a random number ever 5 minutes, they won't collide enough to do more harm than good. Important to keep your insight @miklb in back pocket for the "real" implementation.

tldr "if it's stupid but it works..."

[miklb]

I am 100% thinking ahead. Anything that gets us part way there in the short term would be great.

[nihonjinrxs]

I think the "job queue" idea is exactly what this "Make one call" feature would be -- You got to the "Make one call" page, and you're presented with a center to call.

I'm thinking along these lines: When a center is presented to a user, it's automatically taken out of the queue temporarily, and can be added back after 10-15 mins if no update to the record is made. Once an update is made, it's now at the bottom of the list, since it's the most recently updated record.

[nihonjinrxs]

I'm going to start building this out in the API. I think what I need most is a call script that factors in the input fields where they go in the list of questions. Can someone work on that content? (Will cross-post in Slack, since there are likely to be non-coders there who can help with that.)

[miklb]

Here is the call script, just need to factor in the fields https://docs.google.com/document/d/15UYtfAmsGNLkYFyi4CdaIHQaN-YXRbhMbygN244qXiU/edit#heading=h.61ih3mq38b1s

[miklb]

See also #14 about potential script info and discussion about a flexible script system.

[omnilord]

Twilio released a new tool last week at SIGNAL called Flex that seems like it might be a tool for the workflow. I dropped into the video stream mid demo, so I may be missing some things but it seems like worth evaluating. You can customize the whole thing by uploading react components to Twilio.

[miklb]

I had seen a Twilio repo that also seemed like it could work, will be interested to see the new tool

[nihonjinrxs]

@GovInTrenches @miklb @omnilord @jnolasco

Here's a synopsis of this issue, which I hope summarizes where I think we've landed on how this should work.

• [ ] When the user clicks the Help Call Shelters option in the menu, they are taken to a page with the call script for the least recently called shelter (with existing information pre-filled).
• [ ] The shelter is taken out of the outdated queue temporarily (5 or 10 min timeout?).
• [ ] The user calls the shelter using the script, and makes updates inline (with blanks next to the questions as appropriate within the script).
• [ ] When the user clicks Finish Call and Save Update at the end of the call script, the shelter record is updated, which automatically removes it from the outdated queue until it's added back by the queue's rules.
• [ ] If the user does not complete the call by clicking the Finish Call and Save Update button the shelter is added back to the outdated queue where it was, so that it can be called by another volunteer.

The call script (as it currently stands) is here.

Do we think this is ready to start work on?

[omnilord]

Re:timeout, we could use an ActionCable to track that the user is active with a particular shelter in case they get put on hold or the person who is responding to questions is taking a long time.

We can track engagement events (typing in text boxes, clicking on controls, set focus, etc.) and either send that back to the server over the ActionCable or the ActionCable could poll the client. Using this technique, every event would debounce an "Are you still working with this shelter?" popup on a 5 minute timeout of UI inactivity, then the user either answer "no" or they don't respond to the prompt within 1 minute in which the ActionCable will close and perform a requeue; the UI would redirect the user back to either root_path or the outdated list.

I would like to see my refactor branch merged prior to adding any more new features. I ran Rubocop (I am not going to recommend adding that to Travis tests at this time) and there were...many alterations that I am still reading through.

[miklb]

That workflow sounds good to me, and definitely any improvements to the UX for volunteers regarding timing out if it takes longer than expected sounds like a great idea.

[nihonjinrxs]

Sounds good to me. I'll hold off on implementation until your refactor is done.

@omnilord Is there a PR out here somewhere to track that work? Can I assist in some way?

[omnilord]

@nihonjinrxs @jnolasco In case you guys missed it in slack a couple weeks back, PR #83 is available for review. Please feel free to pick it apart, I am certain I missed something.

[nihonjinrxs]

83 has been merged. I plan to start on this implementation later this week.

[nihonjinrxs]

I think master has diverged pretty far from where I was working on this last January. I think it's still a worthwhile feature, but perhaps we consolidate current information into a new issue and move forward with that? @omnilord, thoughts?