Mythos
Mythos is a donor relations platform for universities and non-profit organizations. The software helps collect stories from beneficiaries and use them to create personalized campaigns that show donors the value and impact of their donations.
I worked with a team to create Mythos from the ground up, building the minimum viable product and then iterating to fix bugs, collect user feedback, and add new features.
Case Study: Bulk Campaigns
I recently led the development of a major new feature that allows users to upload a CSV or Excel data file and generate PDF documents in bulk based on the data records.
Planning & Prototyping
Before writing any code, we spent the first two months planning and prototyping. This may seem like a long time, but in truth it was one of the most important steps of the process. I focused on things like:
- Working with a team to plan the data models and API endpoints
- Making wireframes and designing the user interface
- Building reusable UI components in Figma and creating dynamic prototypes of the screens and user interactions
- Collecting feedback from users about their process and workflows, and using this insight to improve the design and user experience
Development
Once we had a solid plan, it was time for implementation. I built the front end and user interface, which included:
- Frontend routes and views
- Handlebars JS templates for reusable components
- JavaScript interactions
- AJAX requests to hit REST API endpoints and handle the responses
- Reusable polling module
Because this feature could involve processing hundreds or thousands of data records, the results are not always instantaneous. We needed to have queued jobs that ran in the background, and this required polling on the frontend to check the status and update the user interface accordingly. I wrote a reusable polling module in JavaScript to check the status and handle the response with callback functions.
Documentation
While I was working on this feature, I noticed that our documentation was severely lacking and out of date - we had API docs, but out of dozens of endpoints, only 7 were documented. I couldn't solve this problem overnight, but I started by writing documentation in the OpenAPI spec for all of the new endpoints we had just created.
I included the documentation in the git repo, so it would be part of the codebase and updated whenever the code changed. Then I started an initiative to make documentation part of the acceptance criteria for any new features, and made it a priority to add documentation for the rest of the API.
Impact
This new feature makes a previously time-consuming manual process much easier. Before, clients had to send us their data files, and we would manually run custom scripts to process the data and generate document proofs. Then we would send the proofs back to the client for review, they would provide feedback, and we would repeat the process.
The bulk campaigns feature simplifies the proofing process by eliminating the overhead of sending files back and forth. Now, clients can upload their own data and generate proofs to review almost immediately. This is a critical feature that improves the workflow of existing clients and is also a huge selling point to market towards future clients.
I also made a big dent in my team's technical debt by prioritizing documentation and making it part of the codebase. Since then, I've helped other team members get started writing the API docs for both old and new features. We're not finished yet, but we've made a lot of progress towards having complete and up-to-date API docs.