RFC: Request/Release-style dynamic assignment + Texter Sidebox extensibility

[schuyler1d]

Proposal

• Change dynamic assignment from incremental 'pull' as the texter is texting to a Batch Request/Release model
• Mostly do this with an extensible Texter Sidebox

Motivation

The Warren Campaign Spoke Project successfully deployed a great model to manage texters. We'd like to make the following workflows possible in Spoke:

• New texters are invited through a (campaign-specific secure link) and can "Request a batch" (e.g. of 300)
• During texting, they are assigned the full 300 right away.
• It is easy for them to 'give up' and release their 'batch' for other people to text.

Furthermore, a lot of use-cases have come up both in the Warren campaign and other contexts for a Texter 'sidebox' -- where other widgets, etc can be contextually added. These 'request/release' buttons are an opportunity to structure this framework. Some Texter Sidebox use cases include:
request a new batch button

• Release batch (texter can give up for other texters to take it on)
• Release replies (an optional button for texters to 'give up' on replies and pass the conversations on)
• "Great Job! you finished" confetti widget
• Survey iframe (The Warren campaign used this for shift signups)
• 'Add feedback' widget for Admins viewing the contact thread. (Something I believe WFP has discussed)

Because of recent Texter UI work there is also quite a bit of simplification to do to remove the older interfaces, so doing that simultaneously seems like a good opportune time.

Detailed Design

• Per-campaign invites will move to the Warren model where there's a different uuid per campaign -- however I plan to just use the same invite link with the campaign uuid NOT the organization uuid, but instead the campaign uuid. Thus the same request can match both and then join the campaign's organization at the same time.
• I plan to have a sidebox directory where new sideboxes are added. The api will need to be worked out further in implementation but roughtly for each sidebox there will be:
  • an admin UI react component which returns config data
  • a texter UI react component for the sidebox widget -- in some cases, including the release/request buttons, this will be a container with a mutation graphql hook
  • some function that can be called to decide (on state change) whether to popup the sidebox actively on mobile where it is hidden behind a button -- this can be for e.g. "great job!" sideboxes which might want to demand attention.

Design choices/alternatives

• It seems batch size is likely to be something that can be different for different campaigns, even for the same organization -- this means a new campaign field and also new campaign admin interface, so we might as well make some other things customizable as well.
• We could skip the whole 'sidebox' framework, however these buttons seem well-suited as first use-cases and would need additional UI space/etc. Further, a lot of these buttons can/should be controlled with settings in a campaign -- rather than just showing them, so it seems we'll need that infrastructure anyway.
• There was some discussion of having 'vetted texters' being allowed to start another batch (instead of anyone) -- I think this is still possible, but if we do this, it should be after the main pieces are in-place, and then access control/visibility can go with an added role. So this is explicitly deferred for this project.
• Allowing release and pull of reply assignments was something imagined, and it seems worth exploring this space in terms of assignment management -- thus making it a possible option seems worth including -- I don't think it adds much complexity besides the enable/disable option.

Project Plan Information

This project has a lot of steps. I would like to do the 'quick' things first, to reduce churn over time, and then focus on hard things later in the process. Here are the steps I plan:

1. Refactor TexterUI -- this will move files around, so getting that done first, seems best
2. Schema changes: adding new columns to campaign table will allow other changes to move forward without migration churn. We can also move the Dynamic assignment down in a different AdminCampaignEdit panel.
3. Sidebox extension framework for TexterUI
4. Request/Release mutations/adjustments
5. Refactor some AssignmentTexterContact requests to simplify incoming data.

Sponsor Organization (will test alphas/betas)

MoveOn

Developer allocated

@schuyler1d

Planned timeline

Work should complete by the beginning of June. Hopefully different pieces will be merged throughout releases before then.

Files/File-sections touched

• Frontend Texter UI Refactor (all components will be moved/renamed):

  • components: ContactToolbar, ScriptList, MessageList, SendButtonArrow, CannedResponseMenu, AssignmentTexterContactControls
  • containers: AssignmentTexterContact, TexterTodo, TexterTodoList

• Admin Additional controls

  • containers/AdminCampaignEdit
  • components/CampaignTextersForm.jsx (to move dynamic assignment out of the main texter form into a new component)

• Backend mutations (currently in server/api/schema.js -- will move some mutations to their own file)

  • findNewCampaignContact
  • getAssignmentContacts
  • new mutation: releaseBatch,
  • editCampaign (to save new admin options)

• Schema changes:

  • api/campaign.js
  • server/models/campaign.js
  • server/models/cacheable_queries/campaign.js

Schema changes and migrations

• new columns in campaign: join_url, batch_size, texter_viewdata (we could name this generically features since it will be a json field, we could leverage it for other campaign-specific data)

Any other links to details about the plan (maybe a Google Doc link, or other place where folks have commented)

The same RFC text is available here:
https://docs.google.com/document/d/1DL_Vq50JWxzrhoFEBmDxZ_2ht7rWf33d_ui9neiEhmo/edit?usp=sharing
which can allow inline comments more easily.

Existing github issues that this RFC will address

• https://github.com/MoveOnOrg/Spoke/issues/897
• https://github.com/MoveOnOrg/Spoke/issues/887
• https://github.com/MoveOnOrg/Spoke/issues/669

cc: @ibrand @matteosb @jeffm2001

[ibrand]

@deasterdaywfp @codygordon This sidebar could also be used for some better feedback for texters to notify a guide or communicate with admin. Even escalate a conversation. Thoughts on this UI concept?

[ibrand]

@Frydafly curious to hear if this sidebar would be useful for something like your issue: #1541

[Frydafly]

@Frydafly curious to hear if this sidebar would be useful for something like your issue: #1541

@ibrand I think yes! It could offer a less clunky way to embed a support ticket request form /knowledge base

[ibrand]

This would close #846

[deasterdaywfp]

@ibrand I really support this moving into the UI and we would have so many uses for the extendable sidebar!

[suegibson]

This part gives me pause: “an optional button for texters to 'give up' on replies and pass the conversations on”.
I need to review conversations and correct user errors before they get moved.

[schuyler1d]

This part gives me pause: “an optional button for texters to 'give up' on replies and pass the conversations on”.
I need to review conversations and correct user errors before they get moved.

This would be an optional setting -- both able to set a default at the organization level and a per-campaign setting.