UpSwyng

Development Notes

In late 2018, I joined Code for Boulder, a brigade of Code for America, with the goal of improving my development skills while contributing to the community. The brigade was comprised of volunteers from different professions with similar aspirations.

The first project I was introduced to was UpSwyng, a mobile-ready, digital directory of resources to assist the unhoused and at-risk communities.

Ionic to React

UpSwyng had started as a prototype developed during a hackathon using Ionic (v1). There wasn't an initial technical issue with using this framework, but it was contributing a different challenge. Code for Boulder was run by volunteers, and many of those volunteers were looking to gain experience that would help them find a job.

Popularity shouldn't be the deciding factor when choosing a tool, but it became clear that Ionic's limited use by the industry was a major hinderance to recruitment. After deliberation, we decided that the amount of progress made on the project didn't prevent us from partially starting over with React, which was a popular tool that was familiar to the current team. with. It didn't provide us the ability to create a native application like Ionic, but we settled with eventually making it a progressive web application.

The Provider Portal

Creating the directory application to surface resources to those in need was only a quarter of the battle, and there was a not a starting point for the largest feature of the project, the provider portal. The eventual goal of UpSwyng was to enable service providers to update their own listings as needed. This included quite a few features:

• an interface for providers to add, edit, and delete info about their service:
  • basic details such as the title, description, and services
  • hours of operation, which ranged from weekly, monthly, and yearly listings
  • the location of their establishment
  • a street view of their establishment
• a review interface for UpSwyng managers to prevent incorrect or malicious changes
• a scheduled message system for surfacing important community updates, such as those surrounding COVID-19
• API endpoints used by the provider portal to update the database and the directory application to read

The provider portal team settled on using Sapper. Sapper is a web framework, powered by Svelte, which uses filesystem-based routing to build both client and API routes.

Pros

• simple setup and plenty of documentation to get started quickly
• Filesystem-based routing made navigating the project simpler for new volunteers.
• A lot of performance optimization was handled by the framework out-of-the-box.
• Svelte was, at the time, the hot new tool that made working on the project more appealing.

Cons

• Using separate front-end frameworks meant UI components couldn't be shared between the provider portal and directory application.
• Context switching for developers working on both applications added overhead.
• Compared to React, Svelte had far fewer packages, which could be utilized to speed-up development.
• Since Svelte was a new tool, it was also daunting for some volunteers to commit learning.

Conclusion

Overall, I believe the choice to use Sapper was a sound one. Our real mistake was choosing different frameworks for the provider portal, and the directory application. Given the opportunity to start over, I would either go all in on using Sapper for both applications, or chosen a similar framework like NextJS, which was React based.

Project Management Notes

I learned quite a bit developing for UpSwyng but I learned even more being its project manager.

Define a MVP

The most important lesson I learned was to make sure you determine the absolute minimum your product can do to provide value to its users.

Above, I mentioned that one of the features of the provider portal was "a scheduled message system for surfacing important community updates". At the time, rotating emergency overflow shelters were made available in the winter depending on temperature and precipitation. The decision to open those shelters in the evening was made the morning of the same day. The point of the messaging system was to inform users if and where they would be made available.

Our goal was to release UpSwyng by winter 2018. We didn't release until fall 2019. The reality is UpSwyng shouldn't have released as a web application. It should have released as a notification system. Had we taken a step back and considered the bare minimum at the beginning of the project, we would have provided something of high value and most likely less work.

NOTE: Boulder made emergency overflow shelters available without condition in the winter of 2019.

Write Clear, Organized Tickets

UpSwyng was my first go at managing an open-source project. We had a rotating door of volunteers and a fluctuating scope. Unsurprisingly, the most common question I received from contributors was, "What's next?".

I eventually came to rely on a number of tools and techiques to support volunteers:

• For developers, I mostly utilized GitHub for writing tickets:
  • tickets were written as issues so they could be categorized using labels
  • issues were then added to a GitHub Project, which to generated a Kanban board, marking the current status of work
• For other contributors, tickets were created as part of a Trello Kanban board
• Tickets typically had the following properties:
  • a brief description of the current problem
  • the goal of the current ticket
  • specific tasks that would need completed (acceptance criteria)
  • supportive material including links to repository files and screenshots
• Weekly meetings started with a review of current work and requests for support where needed (standup).

Before I implemented the above, I learned that having poorly written tickets meant both me and contributors having less time to actually work on UpSwyng as well as losing some of those volunteers in the first place.