GSoC 2021 Ideas: Ushahidi

NOTE: This ideas list is under development and will likely be changed up through the official announcement of GSoC projects. Please also visit the Google Summer of Code @ Open Source Center page for other sub-org information and details.


Ushahidi Overview

Information about how to contribute and apply to GSoC, please look at our instructions here GSoC and Outreachy applicants, start here! · Discussion #4213 · ushahidi/platform · GitHub.

Potential mentors for all project ideas on this page are available to answer your questions! Connect with us on Chat with general questions, or contact any of the Ushahidi Mentorship Team (subject to change!):

Project ideas:

Project 1. Improve performance in the Ushahidi Platform Client

The Ushahidi Platform Client is heavy and slow to load for the user. A big bundle of javascript and CSS is loaded before the page is usable and everything is loaded in the same bundle. We want to improve this to make the experience better for our end-users, especially in areas with bad connectivity. The project will be focused on decreasing the bundle size of the javascript, using code splitting, and dive deep into the configuration of Webpack. It will also include finding and removing unused dependencies and finding replacements for heavy dependencies.

We have a big bundle of javascript loaded when the user enters the page. All javascript used for all functionality on the site is loaded at the same time. This means a lot of unnecessary code for a lot of users. Tasks and questions to research:

  • Is there a way to split up the bundle and only import what is needed for each view or use case. For example, can the code for the settings-view and analysis-view be separated?
  • Do we have any unused dependencies? Remove them
  • Some of our dependencies are really heavy, can we find replacements that are lighter?

Skills: Javascript, AngularJs, Webpack, Front End development

Difficulty level: Intermediate to difficult

Project 2: Ushahidi Platform Voice integration

Currently, the Ushahidi platform supports data collection via SMS, Email, Twitter, and smartphone apps.

Even with these different available alternatives, there are circumstances where reporting is still not feasible or sufficiently convenient. Some individuals may not have the required literacy skills to write their report, or may not be able to operate the necessary devices in order to input data. During a natural disaster, infrastructure may fail, leaving no internet or cellular connectivity working in the area.

Proposed solution
A type of data that is currently not being enabled for Ushahidi Platform deployments is voice.

Voice has the advantage of being accessible to individuals regardless of their literacy skills and can be less cumbersome to produce than typing into a device. Also, there have been instances of natural disasters where the only remaining infrastructures were landlines and radios.

Implementation guidelines

  • This project’s aims to complete an experimental / proof-of-concept exercise
    • The purpose is to explore the idea and possibly try it out with a small controlled group of end-users.
  • We suggest (not enforce) receiving the voice data from a voice phone API , such as i.e. Twilio Voice .
    • Other alternatives (i.e. based on radio technology) welcome to be mentioned in the application.
  • Due to the experimental nature of this project, there is a certain latitude here and we are glad to hear of any specific implementation ideas in your application.
  • Rather than re-inventing the wheel with the speech-to-text transcription, it’s expected to interface with one or several of the different speech-to-text services available out there.
  • The minimal necessity at this point is for the service to be able to deliver a single message per report to the Ushahidi Platform.
    • This is similar to the functionality currently provided by the SMS data source.
    • As opposed to the more complex mode of operation, which we refer to as structured data capture. In that case, several messages are to be received from the reporter for each submission, in order to fill a survey form. This would usually require a more sophisticated, conversational (IVR system) approach.

Skills: PHP, systems design, HTTP API

Difficulty level: Difficult

Related readings:

1 Like