As an end user of the widget, I want to reduce the delay as much as possible when I click the "close" or the "join" button.

Acceptance Criteria:
The manual delay in the event handlers should be replaced by asynchronous promises.

It should read "Unsere Webseite unterstützt den #Klimastreik am 20. September. Bist du auch dabei?"

Original Text:
Unsere Webseite unterstützt den #Klimastreik am 20. September. Bist Du auch dabei?

Hello, thanks for making this!

I'm trying to implement the self-hosted option, and the footer message is showing fine. When I set fullPageDisplayStartDate to the current day, the text shows correctly but it does not resize to full screen. It looks like widget.js is not receiving the message from the iframe.

My PR is here: ConvivioTeam/Convivio-Site#117
The branch can be previewed here: https://deploy-preview-117--convivio-site.netlify.com/

As the Digital Climate Strike organizing team I want google analytics events to be registered for the most important actions so that we know when and where the widget is being used.

Acceptance Criteria:

• Add analytics tracking code to index.js -- you can see examples of this in the https://github.com/fightforthefuture/redalert-widget widget code
• Add config option disableGoogleAnalytics to turn off tracking if a website wants to.
• Each event should have some sort of reference to the hostname so that we know which websites are using the widget.

Events to track:

• Footer widget loaded
• Footer widget Link Button clicked
• Footer widget Close Button clicked
• Full page widget loaded
• Full page widget Link Button clicked
• Full page widget Close Button clicked

Note: we don't know exactly which Google Analytics account we'll be using for this. You could just use your personal one for testing, but align with @dtoakley on what we should use for production.

Links all break when we set iframeHost.

iframeHost: '/wp-content/themes/shiro/assets/digitalclimatestrike',

Anyone else had similar issue? Any known fix?

As a digital strike user I want to see the widget with the updated design and copy so that my experience is awesome.

Acceptance Criteria:

• Widget design and copy is updated to reflected the mobile and desktop designs below.
• With regards to the banner version: the code will need to be updated so that the iFrame loads in the correct height regardless of screen width (e.g. mobile vs tablet vs desktop). Currently it's not quite right.

Tech Notes:

• Currently the iFrame width is set in getIframeHeight in widget.js. I'm not sure if this is the best way to do it. Could there be a better CSS based solution?

Designs and copy to implement:

• Mobile: https://invis.io/X7TGTP76TPM
• Desktop: https://invis.io/QGTGTOQUM57

Has anyone looked at the accessibility of this widget?

Green is always a hard color to match against for color contrast.

We don't want folks coming and saying that they can't add this widget because it breaks their commitment to being an inclusive organization (or exposes them to a lawsuit if this is the USA).

Context
The date comparison logic - used to compare the current date with a configured date option - is shifting to EDT. This means any users based in Europe or anywhere else east of Greenwich will experience a delay (i.e. 4am, 10am instead of midnight) in seeing the full-page widget appear.

Steps to reproduce

1. Set your system time zone to London (GMT)
2. Set your system time to 2am
3. Set the fullPageDisplayStartDate option in demo.html to the current date, i.e. for July 31 it would be new Date(2019, 6, 31)
4. Re-load demo.html and the full page widget will not appear
5. Set your system time to 5am
6. Re-load demo.html and the full page widget will now appear

This isn't exactly an issue... I just thought I'd share something I'm playing around with to put GitHub repos on digital climate strike...

Would be cool if some big GitHub repos would do this! cc @yyx990803 @sindresorhus @KrauseFx

Hey
I run a website based on Joomla in German and English using the core functions of Joomla for multi language sites. I added the banner using the script and a module. Problem: The banner is always in German, no matter what language the site is in. Is there a way to provide the German version only to the german visitors?
Thanks
Rolf

As a digital climate strike team I want to migrate Google Analytics tracking to Matomo so that we aren't posting event to google anymore.

Acceptance criteria:

• All events (banner shown, button clicks, etc) in index.js are replaced by calls to our Matomo cloud account.
• The domain for this Matomo instance is https://digitalclimatestrike.matomo.cloud
• We must be able to configure a report to show counts of all the different event types, per domain and between any time period we want.
• Any reports needs to be able import into our tracking spreadsheet as we have with the Google Analytics workflow. Ask @dtoakley for more information about this.

Technical info:
Matomo tracking script:

<!-- Matomo -->
<script type="text/javascript">
  var _paq = window._paq || [];
  /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="https://digitalclimatestrike.matomo.cloud/";
    _paq.push(['setTrackerUrl', u+'matomo.php']);
    _paq.push(['setSiteId', '1']);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src='//cdn.matomo.cloud/digitalclimatestrike.matomo.cloud/matomo.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<!-- End Matomo Code -->

Matomo API docs: https://developer.matomo.org/api-reference/tracking-api

As a CI server I want to deploy a javascript file to GCS so that it can be read by the internet.

Acceptance Criteria:

• Write access to the GCS bucket should be locked down to only the TravisCI server.
• Travis config is updated to deploy to the bucket on every master build and replace the file.
• We can navigate to the js file with a browser. Example: https://redalert.battleforthenet.com/widget.js

Tech Notes:

• We're not sure how best this is done. Google it, but also discuss and align the approach with the rest of the team, so we can be sure it's secure.
• This needs to be done after #6 and #7

When adding new languages, it's currently necessary to modify multiple files.
The goal of this ticket is to think about a way to reduce the number of files' changes required.

As a digital strike company I want to be able to configure the footer and full page display dates so that I can display them when I want.

Acceptance Criteria:

• Two new config options added: FOOTER_DISPLAY_START_DATE & FULL_PAGE_DISPLAY_DATE.
• FOOTER_DISPLAY_START_DATE: this is the date when the footer starts showing at midnight.
• FULL_PAGE_DISPLAY_DATE: this is the 24 hour period in which the full page display shows.
• Based on this, the associated views should show on these dates.
• If they are configured to show the full page view on or earlier than the footer view, the full page view is honored and shows for its' 24 hour period.
• The footer should display until the full page date happens, then stop after that.

Tech/Testing Notes:

• We should create a /static/test.html that renders the iFrame and also includes DIGITAL_STRIKE_CONFIG object passed to the iFrame that is used by the js that renders the iFrame.
• This HTML file can be used to test the feature.

As a German user I want to be able to see the digital strike content in German so that I can understand it.

Acceptance Criteria:

• When I add German (or English) as a config option, I see the German text as it is defined in the code.

Tech Notes:

• New LANGUAGE config option is added.
• All hardcoded text in the HTML is updated with {content-name}
• German and English .yaml files added to /src dir
• Webpack build is updated to render iFrame using .yaml files and a rendering library like Mustache or handlebars.
• utf-8 character types
• Config value must match the name of the yaml file and is case sensitive.

Out of scope:

• Any text formatting like upper or lowercasing.
• Any content overriding of the translations

As a developer I want to render an empty iFrame locally so that I can verify that local development works.

Acceptance Criteria:

• Developers are able to run the app locally with a CL command
• Running the app compiles and bundles the empty iFrame and makes it available at https://localhost:8000. If getting it work with SSL is a big lift / complex, then we could pivot away from that.

Tech notes:

• Let's use webpack for compiling/bundling
• entry point should be /src/index.js
• This repo helped us design the approach and could give you pointers: https://github.com/fightforthefuture/redalert-widget

As an end user I want to be able to see a footer digital shutdown view so that I can be aware of the strikes.

Acceptance Criteria:

• iFrame is rendered with the footer view of the digital shutdown.
• Style should follow the designs below
• Hardcoded english for now.
• Should be bundled and deployed to GCS

Out of scope:

• Configurable content (company name & logo)
• Configurable display type

Resources:

• Mobile designs: https://projects.invisionapp.com/share/37TC2OM2JPC#/screens/377702416
• Desktop designs: https://projects.invisionapp.com/share/4ETC2PDAVJ7#/screens/377702544

Steps to replicate:

• Open up the demo in Chrome and configure your browser to simulate iPhone 5
• You will see the footer banner is cut off at the top.

Possible solution:

• Increase iFrame height to 200px, rather than 175px in widget.js

We can't drop in a javascript widget just like that because we are a single page web app. Which means that we should be able to change the state of the script depending on the page without a full reload (see opencollective/opencollective#2360)

Would be great if someone could make a React component version of this widget.

As an open source software team we want CI set up so that I can build and test my branches (including master) automatically.

Acceptance criteria:

• CI should run every time a branch is pushed, as well as when merged to master
• Steps in CI should include installing node dependancies, linting, bundling
• Result of build should be easily viable via GitHub

Tech Notes:

• Let's use TravisCi for this.
• Should add basic node dependency to test the npm install: babel-core at least, maybe other babel modules too.

As a user I don't want to see the Digital Strike widget again on the same site after I have close it so I'm not annoyed by it.

Acceptance Criteria:

• When a user clicks the "x" to close the widget, we should set a cookie in the browser that last, by default, for 1 day.
• Is the cookie exists when the user visits the same domain again with the widget code, we should not show the widget.
• The number of days for the cookie to exist should be configurable with the DIGITAL_CLIMATE_STRIKE_CONFIG object: cookieExpirationDays

Tech notes:

• See https://github.com/fightforthefuture/redalert-widget/blob/master/static/widget.js for hints on how to implement this.

See https://www.drupal.org/project/drupalorg/issues/3079557#comment-13265086 for a full explanation.

In brief, the overlay is at the end of the focusable elements when the iframe is at the end of the document. Getting the focus to join or, if enabled, close, is not easily done via keyboard.

Our tentative fix is https://git.drupalcode.org/project/drupalorg/commit/9c22e182024fafd7481e490dcac1cb104ceb4362

I tried to embed your code on our home page, www.sustainablebainbridge.org. It just shows up as a line of code, not as the widget.

Hi I've noticed that the widget is hidden once I add DIGITAL_CLIMATE_STRIKE_OPTIONS in the page, I used the following snippet below:

<script type="text/javascript">
            var DIGITAL_CLIMATE_STRIKE_OPTIONS = {
                disableGoogleAnalytics: true,
                footerDisplayStartDate: new Date(2019, 9, 27),
            }
</script>
<script src="https://assets.digitalclimatestrike.net/widget.js" async></script>

Hi! One of my customers (a large foundation) asked me today to enable the digital climate strike on their site. It's multilingual, where one of the main audiences is Brazil. However, PT is not available currently.

I've attached a yaml with the correct translations. Would be great if it can be added still, although I know the strike is only a few days from now.

full_page:
  body: '
      <span class="dcs-website-name__default">Noso</span>
      <span class="dcs-website-name__prefix">O</span>
      <span class="dcs-website-name__website">site</span>
      <span class="dcs-website-name"></span>
      se juntou<br />
      hoje à<br />
      #GreveGlobalpeloClima.<br />
      E você?'
  ready:  'Estamos prontos. ➔'
  footer: 'Você poderá acessar nosso site amanhã, dia <time id="dcs-tomorrow-date" datetime="2019-09-21">21 de setembro</time>.'
footer:
  body: 'Nosso site se juntará à #GreveGlobalpeloClima no dia <time id="dcs-strike-date" datetime="2019-09-20">20 de setembro</time>. E você?'
  ready: 'Sim, eu também. ➔'

title: 'Digital Climate Strike'
logo_alt: 'Logo da Digital Climate Strike'
close_overlay: 'Fechar mensagem'
close_banner: 'Fechar banner'

As a developer I want an Google Cloud Storage bucket set up inside the global climate strike GCP project so that I can upload files to it.

Acceptance Criteria:

• Google Cloud Platform projects exists for Global Climate Strike
• GCP Cloud Storage bucket created. It can be called "digital-climate-strike" or something similar if that name exists already.
• It should be read only for now. We will make it writable in a separate issue.

Notes:

• We ideally collaborate with 350.org who manage globalclimatestrike.net to set up GCP and GCS stuff. We might need to ask them for a credit card...
• This might be hard as they are pretty busy, so we could pivot to doing it all ourselves.
• Reach out to @dtoakley for collaborating with 350.org folks!

There needs to be documentation on how to add these to your website

Unless I'm missing something, the demo page is available in the English only. It would be useful to have a simple way to have this page available in every supported language. I know that the demo page should adjust to the language set in the users browser, but some users use a different locale so they might be confused by a "missing" localization.

We would love to add a link: “Why we are doing this” that would link to our (future) blog post and then have the button that says: “Join the strike” (because it won’t be the first link after the text anymore so the CTA needs to be more explicit)

Is there a way we could customize the widget to do that?

Here is the issue on our side opencollective/opencollective#2360

Mac 10.14.6, Chrome 76.0.3809.100

We should be using autoprefixer for CSS compatibility

As an end user I want to be able to see a full page digital shutdown view so that I can be aware of the strikes.

Acceptance Criteria:

• iFrame is rendered with the full page view of the digital shutdown.
• Style should follow the designs below
• Hardcoded english for now.
• Should be bundled and deployed to GCS
• CSS and HTML should support Right to Left languages.

Out of scope:

• Configurable content (company name & logo)
• Configurable display type
• Popover view

Resources:

• Mobile designs: https://projects.invisionapp.com/share/37TC2OM2JPC#/screens/377702416
• Desktop designs: https://projects.invisionapp.com/share/4ETC2PDAVJ7#/screens/377702544

As an admin of the widget, I want the ability to host the widget in my own repo.
The solution is to add instructions on how to clone the repo and generate the widget.js and index.html files.

Hey there,

I am quite sure there is a problem (although I did not check):

When you close the footer banner, a cookie gets set.

The same cookie is responsible for closing the full page banner. So a person who still has the footer cookie set will not see the fullpage banner even on the 20.9. :-(

Hey guys,
the banner doesn't load no matter how I try to do so. Getting a connection reset for the assets, hence, can't deploy it on our sites.

Quick resolution would be helpful

Add the ability to use different urls (landing pages) for the widget, depending on then current layout (i.e, footer vs full-page).

As a developer I want to render an empty iFrame locally so that I can verify that local development works.

Acceptance Criteria:

• Developers are able to run the app locally with a CL command
• Running the app compiles and bundles the empty iFrame and makes it available at https://localhost:8000. If getting it work with SSL is a big lift / complex, then we could pivot away from that.

Tech notes:

• Let's use webpack for compiling/bundling
• entry point should be /src/index.js
• This repo helped us design the approach and could give you pointers: https://github.com/fightforthefuture/redalert-widget

If you are on a screen shorter than the dcs-full-page element, it runs out of green background when you scroll

Screenshot

At least in French (have not tried other languages), the language configuration option for the widget does not change the language of the image used. Just the text and button text. Would be great if this could be fixed in the widget, or perhaps there is a suggestion as to how to manually change this. Thank you.

As the Digital Climate Strike organizing team I want the call to action URL to be configurable from within the iFrame so that we can modify the URL dynamically even if partners have chosen to self-host the widget script.

Acceptance Criteria:

• the call to action URL is configured within the iFrame script
• the widget code should redirect the parent window to the configured URL when the call to action button is clicked

As a Czech user I want to be able to see the digital strike content in Czech so that I can understand it.

Depends on merge of #31

Looking at

I see that there is repeated block of code, with the only difference being the used langcode. Is this correct? We could have multiple languages in the future and it can become maintenance burden, if I understand the code correctly.

Hey there,

why do we want to support companies like google getting more user data?
We expect - or at least hope - that a lot of projects participate in the digital climate strike.

We

• piss off admins who see the google analytics by default
• give the data of users of websites, who previously didn't have google analytics, to google

and for what?...

As the Digital Climate Strike organizing team I want to ensure early adopters do not experience issues when new code is released so that our partners have a great experience.

Acceptance criteria:

• Spike out some options to version the widget code and iFrame code so that early adopters who have chosen to self-host an older version of the widget code do not experience breakages when newer versions of the iFrame code are released.

In the example on https://github.com/fightforthefuture/digital-climate-strike, instead of

footerDisplayStartDate: new Date() 

it should be

footerDisplayStartDate: new Date(),

As someone who owns a website, I want to inject my website name into the body copy so that I can customize the digital strike widget.

Acceptance criteria:

• new config key called WEBSITE_NAME
• This config value replaces the company name in the full page widget version.
  Example: "Our website" should be come "The [website_name] website".
• This shouldn't change anything about the footer widget content.

As a OS developer I want to have a CONTRIBUTING.md in this repo so I know how to add to the project.

Things to include:

• Git/branch workflow description
• Team members for who to ask for what
• Any best practices / code style

As an end user I want the GCS jsvscript file to be behind CloudFlare (CF) so that I can request it quickly and securely from anywhere.

Acceptance Criteria:

• CloudFlare serves the GCS js file.
• Good caching rules are set up via CF console.

Notes:

• We'll likely need to work with 350.org to configure CloudFlare for our needs. Even if we don't work with them to set up GCS, we need to work with them on this one as they already have a CF account.
• This is blocked by #7