How to customise: the context for context

[tttp]

We need to find a balance between having a big unmaintainable mess with a gazillion options and something that is too rigid.

On the backend, we have mostly sorted it out (famous last words) with a tool that can process two "abstract" payload from the campaign website: "add action+personal data+consent" (eg a petition signature) and "add action" (eg a share on the previous signature). The core process in then encrypting the data and pushing it it to various other micro-services that will take care of other actions (send an email, add it to the CRM, generate a PDF...)

What we need now to tackle is how to customise the front-end (widget).

We have 3 main options:

1. add css/js to customise from the campaign page (the site that embed the widget)
2. set options to the widget generator to include/exclude some features
3. fork and have your own widget with exactly what you want

from the campaign page

The widget is embedding html+js directly on the page (no iframe), so you are free to modify the layout or add extra features (eg add a lookup on the zipcode to pre-fill the city field)

• warning *: our terms and conditions prevent you to alter the "consent to be contacted part" of the form. Beside violating our term, you'd doing something illegal (GDPR, you risk fines big enough to bankrupt you).

the widget has a few hooks and you can provide your own function at the end of each step (eg "call my function displayFirework() after the user signs). or you can provide your own custom steps (eg "call my donate tool after the share step").

parameters to our widget generator

Right now, the customisation options are put into a config/your-org.yaml file, and used in the build step $widget=your-org yarn build that creates the widget you embed.

What you can customise beside the "static texts" (eg the language, name of your organisation...) is what steps you want in the journey (eg "petition,share" or "floating action button, dialog with petition" without share

At the technical level, it defines what components to include in the widget (each step is a react component)

It allows to have as many "special" steps as needed (eg "ECI signature", "CH initiative"...) and they won't be included in the code of the widget unless it's one of the step

Where I'm not sure is how to enable/disable features within a single step. For instance:

• remove the ip to country geolookup
• make the last name mandatory
• remove facebook from the share option
• ...

one option might be to have a line in the yaml

• {step}_features= list eg. petition_features=first_name_optional, last_name_mandatory, country_geolookup share_features=facebook,twitter,reddit

But it means that if we introduce a new feature, the widgets won't benefit "out of the box" without having to modify the config.

Might be better to have a multitude of {step}_{feature} = true | false and if we do not have that line, it's the default?

in the code, we'll have a multitude of if (widget.step.feature) {do the feature}

That might be a bit of a hell to manage too

Don't know @marcinkoziej ?

fork

you can customise the hell out of your widget the way you want, but we strongly suggest you to check with us first because

• you might struggle adding new features that landed on the main branch
• we might change the API (but it's graphql, so we will do our best to keep compatibility)
• your own custom thingie might benefit other organisations. Contributing back to the greater good gives you such a nice and warm feeling, that's be a shame to miss it

X+

[tttp]

Just to clarify: this is about how to structure the code and widget generator.

We will need to find a human friendly way of letting folks customize the widget through a UI or great documentation (storybook or something)

[tttp]

After further brainstorms and discussions: One context that defines the journey and allows to override the configuration of specific steps (eg the share message on twitter)

A big yaml file for now, probably a json coming from a UX that allows to configure later. To be continued...

[tttp]

Getting there: one big context and ability to change a value through proca.set("key,"value")

Sharp tool, you can customise a lot, and fubar things quite nicely too