Project Spotlight: Sistering

Introduction

Sistering is a non-profit organization based in Toronto that aims to support homeless and transient women and transgender individuals. Sistering particularly supports women and transgender individuals who are alienated from their families and communities, individuals leaving abusive situations, individuals who were widowed and pensionless, and individuals involved in prostitution and drugs. Sistering has been in operation for 40 years and offers a variety of services including food, harm reduction, employment support, and drop-in programs. In just the 2019–2020 fiscal year, Sistering has experienced over 140 000 participant visits and served over 150 000 meals. UW Blueprint partnered with Sistering to create a volunteer management web application. This web application would be used by the volunteers as well as full-time Sistering employees to coordinate scheduling, volunteer profile or training history retrieval, and notification.

The Problem

Sistering relies heavily on volunteers, both recurring and one-off, in each branch of their operations. However, managing volunteers is a friction-full and time-consuming process, with many inefficiencies that result in volunteer slots going unfilled. Furthermore, the COVID-19 pandemic has been particularly detrimental to Sistering’s roster of volunteers, with the number shrinking from over 100 to around 10. Sistering faces many pain points when trying to schedule, train, communicate with, and otherwise organize the volunteers. Currently, volunteers manage their shifts by emailing back and forth with the employees. Given the load of volunteers and the complexity of shifts, this system quickly becomes unmanageable. As a result, situations arise where a volunteer cancels their shift and an availability opens up but the employees do not discover the email in time and are unable to advertise or directly notify other volunteers of the posting.

The Solution

The objective is to create a volunteer management web application for Sistering. This web application would be used by the volunteers as well as full-time Sistering employees to coordinate scheduling, volunteer profile or training history retrieval, and notification.

The product has three main user types:

1.) Sistering administrative member

This user has the most privileged scope of control over the application. The user is able to create and modify schedules, set prerequisites, notify volunteers, and retrieve volunteer information for all branches of Sistering’s initiatives. This type of user will be limited to one account

2.) Sistering non-administrative member

This user is able to view schedules for the branch they are directly working with. A branch is a specific volunteering category, for example a Sistering branch would be Food Services. This user does not have as privileged scope compared to the Sistering administrative member. Many Sistering employees will have an account with this type of user privilege.

3.) Volunteer

This user is able to browse available volunteer slots, register for or cancel volunteer slots, set availability, list skills, view upcoming slots, receive notifications, and view prerequisite information. Volunteers have a wide range of technological literacy and an age range of 18–75.

Technical Overview

What’s the tech stack and architecture? What infrastructure/practices are being employed and why?

Frontend technology: React + Chakra UI

  • A Blueprint staple!
  • Team members were comfortable with it, would be easy for future developers to pick up

Backend/API technologies: GraphQL & Apollo

  • Some team members were familiar, remaining devs were excited to learn it
  • Strong typing, easy to test API endpoints with the GraphQL playground

Database technology: Heroku Postgres

  • Relational schema makes the most sense to represent entities (volunteer, admin, employee, posting, shifts, etc.)
  • One of the few cloud (relational) database offerings that are truly free for the long-term
  • Other offerings like GCP and AWS provide a free tier/credits for a limited amount of time

Cloud: Firebase Auth & Firebase Cloud Storage

  • Potential to easily build Google Sign-In
  • Cloud Storage has free tier
  • All-in-one platform

Infrastructure: Asurtec VM/VPS

  • Manually deploy backend and database to provisioned VPS via dokku — easily transitions from staging deploy that is using heroku
  • Asurtec works with NPO for low pricing + IT maintenance on provisioned VPS
  • Provisioned VPS has much more resources than Heroku equivalents

What were some of the biggest challenges/decisions?

Implementing User Invite System

Our platform is an invite-only platform where invitations are sent out to eligible employees and volunteers at Sistering

  • For simplicity, we leveraged a invites table in our DB, using its uuid as the token for invites, and we use the created at date to determine the age of each invite

Invites needs to be sent via email

  • We use the Gmail API to mail out these user invites to create new accounts

Invites older than 2 weeks should be invalidated

  • Using the createdAt column in our DB table, we can determine whether or not a user invite is older than 2 weeks, if it is, we delete when we try to fetch such invite
Figure: Initial Account Creation Architecture Design

Using On Site Infrastructure To Host Production Instance

  • We had to host our platform on a provisioned VPS to get around many of the caveats of using free tier Heroku deployments
  • This included: mandatory downtime, very limited resources, limited DB rows
  • We had very little time to set up our production instance and ended up using Dokku on the provisioned VPS to recreate our staging deployment pipeline which hosts the frontend via Firebase Hosting and Backend/DB via Heroku
  • After setting up the Dokku app + DB on the VPS, we push from the backend subtree in our small monorepo, this deploys the backend app in the VPS using a local DB in the Dokku host
  • This required many experimentation as well as dealing with several network failures to get the Production instance up and running
Figure: Deployment Architecture for Production Instance

Design Opportunities & Challenges

What were some of the design challenges?

What sort of constraints/considerations needed to be taken into account?

  • Sistering’s dedicated team of volunteers support various programs and activities offered by Sistering. Many of the volunteers will be assigned shifts on a weekly basis by Sistering’s admin, and so, the design required more complexity than a standard shift sign up platform. Admins needed to have the flexibility to match the right person with the right volunteer shifts. Assigned shifts and open shift opportunities needed to be displayed clearly with the ability to support the case of recurring shifts. Refining these requirements and constraints with the involvement of the client was an essential past of client meetings.

Did you do any user testing, and what did the team change?

  • We did moderated usability testing with the Sistering admin team and several dedicated volunteers — it was valuable to hear from both of our user types, and the feedback was very positive overall. The user testing guided some changes to the way the status of shift requests was displayed to volunteers and emphasized the importance of email notifications as a form of global communication with volunteers.

Collaboration

How did the project evolve between terms?

  • A lot of reflecting and adapting between terms. Looking back at past retros and getting feedback from leaving and returning team members was also super helpful. Abolishing ineffective processes and adding/maintaining better ones.
  • For example, we started dev <> design syncs in W22 to encourage more dev and design collaboration as important features were coming from design into the dev pipeline. This ensured designs were feasible and rallied the devs behind the features they were implementing since they could provide feedback. We stopped this in S22, since major design work for the product had finished and allowed devs to focus on coding.
  • Other important workflows we added: agile 2 week sprints, icebreakers, breaking down product/design tickets more for devs, etc.

What sort of collaboration structure/tools/methods were used? What were socials like?

  • Icebreaker questions at the beginning of every work session were great at helping people get to know each other better and get in a comfortable working environment.
  • Biweekly online socials
S22 Sistering Snack Tier List
  • Some in-person socials
W22 Sistering: Chick-fil-A 🐔 -> Waterloo Park 🏞️ -> BOT GM!
W22 Sistering Nuri Village + Escape room
W22 Sistering Nuri Village + Escape room

Impact

What’s left for the project? How do we expect the project to impact Sistering and the communities they serve?

The product is fully launched and in the hands of Sistering. We wanted to leave Sistering with as much guidance as possible, so we’ve created a comprehensive launch package for them: Sistering Handoff Package.

Our project will help Sistering revitalize their volunteer program after COVID-19. We expect to simplify Sistering’s volunteer management and scheduling for over 100+ volunteers and admins, so they can more efficiently serve women and trans individuals in Toronto.

Team

Joshua Ye

  • 2B Computer Science
  • Product Manager
  • Biggest challenge: Information and time management were definitely struggles, since Blueprint can get busy and messy throughout the terms. I found dedicating blocks of time to Blueprint work and documenting as much as possible to be excellent strategies to ensure the project was under control.
  • Most rewarding: Launch! It was super satisfying seeing the product our team worked on for the last year come to fruition. Seeing our client’s face light up during our handoff meeting as we present the product and launch documentation really validates the time, effort, and passion poured into this project. I’m very excited to see how our product improves volunteer management at Sistering and through that, supporting the communities Sistering serves.
  • Shoutout to the Blueprint team members who worked on Sistering as their contributions made the product possible. Also shoutout to the Sistering organization and our contact with them, Aoife. They were super supportive and responsive throughout the entire process. It was a pleasure working with them all!

Lambert Liu

  • 2B Computer Science
  • Project Developer
  • Biggest challenge: Balancing my time between Blueprint and other commitments has been challenging. As terms got busy, I found ways to be more efficient and improve my habits to get more done.
  • Most rewarding: With this project being my fourth term on Blueprint, I had a great time onboarding the newer devs and helping out with the team’s development workflow. I’m looking forward to seeing the Sistering volunteer platform live and in action!

Brian Tu

  • 2B Computer Science
  • Project Developer
  • Biggest challenge: Having Sistering be my first project on Blueprint, I was completely new to so many technologies. Learning these new tools and frameworks was definitely tough in the beginning, but thanks to the PLs, I was up to speed in no time!
  • Most rewarding: With this being our final term, it’s incredible to see our platform draw close to a finished product. Seeing our user flows in action on top of our amazing UI/UX designs is truly *chef’s kiss*.

Adriana Ceric

  • 1B Civil Engineering
  • Project Developer
  • Biggest challenge: Learning GraphQL was the biggest challenge (navigating the Playground etc.), but I got a lot of support from the more experienced developers to guide me through that!
  • Most rewarding: Being able to contribute and push code to my first open-source project!
  • If you’re thinking about applying to Blueprint as a non-CS-adjacent major, go for it! The community is welcoming for beginners and leaders from multidisciplinary industries. More diverse backgrounds create more accessible products.

Evan Wong

  • 2B Systems Design Engineering
  • Project Developer
  • Biggest challenge was getting around understanding the system as a whole. Once I got a groove on thanks to my PLs and peers, I was able to become productive quickly, and make broader improvements to the project.
  • Most rewarding: While I wasn’t there to see the reveal, it was very rewarding to see everything come together and have the final project revealed.

Tejas Wilkhoo

  • 2A Computer Science
  • Project Developer
  • Biggest challenge: This is my first term on Blueprint and first university-related extracurricular I’ve been a part of. I really enjoyed the welcoming and supportive environment in the Sistering team, and was always able to get in touch with someone for questions and clarifications.
  • Most rewarding: Being able to take on tickets that integrate with the backend and frontend together is a great feeling of accomplishment, and learning new tech is always a fun learning experience.
  • I’m excited to see how our project comes together in production and see the impact of our work!

Boya Zhang

  • 1B Systems Design Engineering
  • Project Developer
  • Biggest challenge: Getting accustomed to the overall architecture of our application was a big learning curve, but many experienced members on the team were there to guide me and provide support!
  • Most rewarding: Learning new technologies like GraphQL, gaining more experience with React + Typescript, as well as working with an awesome team :)

Rickson Yang

  • 3A Software Engineering
  • Project Lead
  • Biggest challenge: Trying to enable everyone on the team to do high quality work was a difficult priority. Making compromises and accommodating everyone can be challenging. Pushing high dev velocity in such a short time is always challenging for projects that are wrapping up.
  • Most rewarding: This term was my third on Blueprint and my second time as a Project Lead. I had a wonderful experience collaborating with my awesome team and I can’t wait to see our work go live!

Anthea Adjei Tawiah

  • 3B Global Business and Digital Arts
  • Product Designer
  • Biggest challenge: Budgeting the time to work on projects concurrently with co-op! It was my first time doing both, and being the sole designer on a team. It felt intimidating to me, making design decisions on my own, especially knowing the product would be launching soon.
  • Most rewarding: This was my third term on Blueprint, and while I have normally seen projects from their beginnings, it feels all the more worthwhile to watch a project grow into a platform that fulfills Sistering’s needs so closely. I felt lucky to be working with such an amazing PM + team, and grew a new appreciation for BP thanks to them :)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
UW Blueprint

UW Blueprint

Tech for non-profits, built by UWaterloo students