Making of the Lyrics Web App: Part 1
This past week, I’ve released a lyrics web app into the wild. The target audience is for my church, though anyone and everyone is free to use it. The purpose is simple: allow users to search for lyrics to their favorite hymnal or campfire song (and eventually, Christmas songs). It also comes with a few instrumental/vocal tracks, to sing along with (for those who are tonally challenged, like *ahem* myself).
Oftentimes, unless you’re in the room where it happens, the process of taking an idea to completion is opaque and mysterious. I’d like to make this all more transparent by using this as a case study: how we took this from conception to an actual product that people can use.
The Idea
Around mid-2021, a good friend of mine released a hymnal app on the iOS App Store. It was a really good start, and I opted to help him out with the UX.
However, the more I designed, the more I considered the ideal use cases — what are the typical scenarios by which someone would want to use this?
- Small group singing hymns: would be nice to easily share songs.
- Those who are less secure in their singing abilities (definitely in smaller groups): ideal if we included accompanying tracks.
- Large groups: ability to project lyrics (in landscape orientation).
- As many “campfire moments” are off-the-grid — or, at best, have spotty internet—would be good to have offline access.
With those use cases in mind, a new idea dawned on me—we need a different kind of app.
The Design
With this new direction in mind, I grabbed a few of my friends and we began hacking away at what would eventually become a web app¹. It’s been ages since I last delved into code, but the more we dug into what’s actually possible, that fed into the design. We had a tight-knit feedback loop between code and design, which was really awesome.
For example, we learned that we could use Dropbox to host our music tracks, and with some javascript wizardry, select it and play it within our app — that knowledge enabled us to include a simple audio player².
With that said, this is still in beta, as more features and ideas are in store for the future!
The Development
The people I had to help develop ranged from HTML/CSS to pure backend devs. But given that we wanted offline access (requirement #4) — and given the wide array of expertise from my team—I made the decision³ to use Svelte as the frontend framework and CodeSandbox as the platform to develop in.
More can be said about this¹, but as a small team, this was tremendously helpful in getting (A) immediate feedback on the state of development, and (B) integrating what’s possible back to the designs, as mentioned earlier.
All in all, this was a really cool project. When I released this earlier in the week, many people seem to be excited by it. One person’s feedback was especially notable—
Wow thank you guys so much. Tried this after my [devotions] this morning and ended up singing hymns for like 30min — really enhanced my devotion time. Going to be using this as part of my regular routine for sure…thank you for all the hard work!
For those interested, check out the lyrics web app for yourself! And if you’re so inclined, feel free to contribute to the feature requests—still a lot of work left to be done!
If you have any questions, or wanted to know some things in further detail, please write up a comment!
[1] In a future post, I plan on describing our tech stack, and the reasons for choosing it.
[2] While the audio player is really simple, the amount of effort and code to get it to work was quite something else. 💪
[3] I wore many hats throughout this project—ranging from Director of UX to Chief Code Monkey.
