Skip to content

Repository files navigation

CE4CSID Community Engagement Toolkit

A public, free to host website presenting the CE4CSID Working Group's practical resources and guidelines for integrating community engagement into Climate Sensitive Infectious Disease (CSID) research. Built for the Botswana Society for Human Development (BSHD) and hosted on GitHub Pages.

Live site: https://sunji-droid.github.io/ce4csid-toolkit/

This build corresponds to Option B (Toolkit Website) from the project quotation: a branded GitHub Pages website with full navigation, downloadable resources and templates, a community engagement planning checklist tool, and thirty days of post launch support.


1. What this project is

CE4CSID research is often conducted at a high scientific level without including the communities affected by it. This toolkit makes practical, plain language guidance publicly available so that researchers can plan and run genuine community engagement from the earliest stages of a project.

The site is a static website. There is no server, no database, and no ongoing hosting cost. Everything runs on GitHub Pages.


2. Who this is for

  • Researchers designing and running CSID studies
  • Programme implementers turning findings into interventions or tools
  • Policy makers shaping CSID related policy
  • BSHD staff maintaining and updating the toolkit content over time

3. Folder and file structure

ce4csid-toolkit/
├── index.html                 Home page
├── about.html                 About CE4CSID and the toolkit
├── resources.html             Toolkit Resources, grouped by category
├── downloads.html             Flat list of every downloadable file
├── checklist.html             Interactive Community Engagement Checklist
├── contact.html                Contact page with form and direct details
├── 404.html                    Custom not found page for GitHub Pages
├── assets/
│   ├── css/
│   │   └── style.css           Full design system and page styles
│   ├── js/
│   │   ├── main.js             Shared behaviour: mobile nav, active link, toast
│   │   ├── checklist.js        Checklist tool logic and data
│   │   └── contact.js          Contact form submission handling
│   └── images/
│       ├── logo.svg            Header and footer brand mark
│       └── favicon.svg         Browser tab icon
├── downloads/                  All downloadable resource and template files
│   ├── planning-guidance-community-entry-protocol.pdf
│   ├── planning-guidance-engaging-from-design.pdf
│   ├── framework-stakeholder-mapping.pdf
│   ├── framework-engagement-channel-selection.pdf
│   ├── case-example-flood-response.pdf
│   ├── case-example-vector-control.pdf
│   ├── template-engagement-plan.docx
│   └── template-consent-briefing-note.docx
├── README.md                   This file
├── CONTRIBUTING.md             Plain language guide for non technical updates
├── LICENSE                     MIT License
└── .gitignore

Why plain HTML, CSS, and JavaScript

The site is built with plain HTML, CSS, and JavaScript rather than a static site generator such as Jekyll. With six page templates and no need for a blog style content collection, plain HTML keeps the project simple to read, edit, and deploy without a build step, while still working natively with GitHub Pages.


4. Running the site locally before pushing changes

No build step or installation is required. From the project folder, run any simple local server, for example:

python3 -m http.server 8000

Then open http://localhost:8000 in a browser. Alternatively, open index.html directly in a browser, though a local server is recommended so that relative paths behave the same way they will on GitHub Pages.


5. How GitHub Pages deployment works for this repository

  1. Push this repository to GitHub under the account sunji-droid, as ce4csid-toolkit.
  2. In the repository settings, open the Pages section.
  3. Under Build and deployment, set Source to "Deploy from a branch".
  4. Set Branch to main and folder to / (root).
  5. Save. GitHub will publish the site at https://sunji-droid.github.io/ce4csid-toolkit/, usually within a minute or two.
  6. Any future push to main redeploys the site automatically. No manual rebuild step is needed, since the site is plain HTML, CSS, and JavaScript.

6. How to add or update a resource on Toolkit Resources and Downloads

  1. Add the new file to the downloads/ folder. Use a clear, lowercase, hyphenated filename that describes the resource, matching the existing naming pattern.
  2. Open resources.html and find the relevant category section (Planning Guidance, Engagement Frameworks, Case Examples, or Templates).
  3. Copy an existing .resource-item block within that category and update the title, description, file type badge, file size, and the href on the download link to point to the new file.
  4. Open downloads.html and add a matching row to the table with the same title, category, file type, and size, and the same download link.
  5. Update the resource count shown next to the category heading in resources.html if the number of items in that category has changed.
  6. Commit and push. The new resource will appear once GitHub Pages redeploys.

For non technical staff, see CONTRIBUTING.md for the same process explained without code terminology.


7. How to update the checklist tool's stages and items

All checklist content lives in one place: the STAGES array near the top of assets/js/checklist.js. Each stage has an id, title, description, and a list of items. Each item has an id, label, and desc.

To add a new action to an existing stage, add a new object to that stage's items array with a unique id. To add a new stage entirely, add a new object to the STAGES array following the same structure. The interface, progress tracking, saving, and print export all work automatically from this data, so no other file needs to change.

Item id values are used as the storage key for that item's checked state and notes, so avoid renaming or reusing an id once the toolkit is live, since this would appear to reset that item's saved progress for returning visitors.


8. How to connect the contact form to a live endpoint

The contact form on contact.html is wired to submit through JavaScript in assets/js/contact.js, using a service called Formspree, since GitHub Pages cannot process form submissions on its own.

  1. Create a free account at https://formspree.io using the BSHD contact email.
  2. Create a new form and copy the form endpoint it provides, in the form https://formspree.io/f/xxxxxxxx.
  3. Open assets/js/contact.js and replace the placeholder value of FORM_ENDPOINT near the top of the file with that real endpoint.
  4. Commit and push. The form will now deliver submissions to the connected email address.

Until this step is completed, the form will show a message explaining that it is not yet connected, rather than failing silently.

Any other form handling service that accepts a standard POST request with form data and returns a success response can be used in place of Formspree, by updating the same FORM_ENDPOINT value and confirming the response handling in contact.js matches that service's response format.


9. Placeholder content notice

The toolkit content currently hosted in downloads/ was generated as clearly labelled placeholder material for the initial launch of the website, since final toolkit content had not yet been supplied by BSHD at the time of this build. Every placeholder file states this clearly on its first page.

To replace a placeholder with final content, keep the same filename so that existing links on resources.html and downloads.html continue to work, or follow the update process in Section 6 above if the filename changes.


10. Accessibility and SEO basics included

  • Every page has a descriptive title and meta description
  • A skip to content link is present on every page
  • Headings follow a logical order on each page
  • The mobile navigation menu is fully keyboard operable
  • Colour choices meet accessible contrast levels for body text and buttons
  • A favicon is included site wide

11. Thirty day post launch support scope

This build includes thirty days of post launch support from the date of deployment, covering:

  • Minor content updates, such as new resources, edited text, or new checklist items
  • Small bug fixes, such as broken links or layout issues on specific devices
  • Minor styling adjustments requested by BSHD

Credits

Built by Kabo Merapelo Onamile, Digital Health Developer, for the Botswana Society for Human Development (BSHD) and the CE4CSID Working Group.

About

TRIAL 1

Resources

Contributing

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages