In several of our marketing campaigns we have always touted “Making content go” or “Making BIG websites.” We take the future of content and interactions with it seriously — even internally.
The Web Chefs at Four Kitchens prioritize open-source community work. One such project is OpenKJ. The OpenKJ Project is a collection of applications and services intended to make life easier for Karaoke DJs (KJs). Since I discovered the cross-platform open-sourced karaoke project, I’ve paired up with the author and main contribution team to contribute to the web interface, song book web application, and Drupal integration. We have been using this module and its configuration since 2018 for our company retreat’s karaoke nights.
The workflow is simple: A user comes to the website, searches for a song title or artist, hits the request button, and logs in using SSO. Then that request gets transmitted to the OpenKJ software running on my machine. The KJ then puts the singer in the rotation with the version of the song requested. They can even tell me if they plan on singing solo, in a duet, or as a group.
It sounds like a simple use case, but it provided us with several unique stances that we would normally not verbalize.
We make interactive content
How many websites can you say that you interact with in real time? Our team experienced that. While the songs are fairly static, the way that users interact with them at the Four Kitchens Karaoke event is really interesting. We created content (songs, artists, lyrics, and categories) that users can favorite, browse, search through, and finally request. In a matter of minutes, they can be on stage, interacting with said content. We feel like this is an exceptional use case that is beyond the norm of the standard articles, videos, and events that we normally work with on a daily basis with our client partners.
While I wouldn’t say we are experts in creating living real-time content or interactions, we learned a lot about the differences in user experience and interactions. The urgency of karaoke requires performance and usability at a scale much faster than that of any other standard website. The way people search for songs is different from the way people search for subject matter on their favorite political subject. And lastly, even though we all build websites for a living, we expected the site to deliver immediately and easily so that we could focus on fun.
Technically, we did this by optimizing Solr Search so that it’s more than just word matches. We used stemming to find the roots of words being searched, synonyms to match commonly abbreviated words (such as “feeling” and “feelin'”), and the introduction of supporting metadata so users could find songs in certain genres or categories.
Knowing our audience was key. We could make the login experience fast by utilizing social networks (specifically Google) since we knew all of our audience had Gmail accounts. Providing the login allows users to store information about the songs they like and allows the DJ to identify who is making a request and silently enforcing “no silliness” rules to keep the karaoke trolls from submitting songs for other users.
We listened to the feedback year after year, adding features, improvements, and bug fixes that we contribute back to the Drupal and Karaoke communities. This has provided us with suggestions like lyrics integration via APIs like Genius, and improved browsing mechanisms such as grouping music by taxonomy such as “Disney,” movie titles, and even frequency of requests. This has even been customized to the “venue,” as a “country bar” doesn’t carry the same analytics for requests and songs as an “English pub,” even though the songs and artists are generally the same.
We provide professional development opportunities
One of the great side effects of doing this work pro bono for our own retreat is that we can use this project to grow the skill of our associate developers. They, too, get the satisfaction of seeing their work do “something cool!” Picture this: You have always wanted to know how Emulsify works, but you haven’t had the opportunity to implement it. This gave our associate developers a proving ground at our own expense and a chance to go wild with abandon and pull out all the stops.
That’s not to say that they could put together a site full of blink and marquee tags. They wanted to do their best work to show off to their peers what they could do. It had to be usable and needed to satisfy the strenuous expectations of the user submitting a request. But they could make it flashy. They could gold plate it. They could test out techniques they had never previously had an opportunity to employ. And next year, we may decide to tear it down and redesign it again so that our next set of associate developers can feel that same glory and satisfaction of making something awesome that everyone at the company uses, even if it is for only one or two nights.
We treated this like any other project but only used our “non-billable” hours. It was resourced with a technical lead, a project manager, a client, and a full, prioritized backlog of must-haves, nice-to-haves, technical debt, and maintenance. We had estimation, planning, and road-mapping. With the resources we had, this project started at the beginning of June and ended in mid-October at our company retreat. Like all projects, there was a crunch time, and while stressful like any other release time, we all had a blast knowing we did our best and we got all the must-haves with minimal scope creep.
We had fun living our values
In the end, our karaoke development team decided (to paraphrase Cyndi Lauper), “Web Chefs just want to have fun.” At Four Kitchens, our core values include humble confidence, taking action, fostering genuine relationships, always improving, and building off each other’s ideas (“Yes, and…”). We saw each of these embodied in our project while still having a blast.
This was a new use case for content we don’t normally work with. We had never done this, but we were honest with ourselves and weren’t afraid to find out how to make it happen.
We provided the follow-through by building usable interfaces that quickly found that elusive esoteric song that a coworker wanted to sing without resorting to Google.
Our team members were allowed to play, to improve, and to experience a project without the pressure of the contractual obligation that comes with a client engagement.
We provided a platform to build relationships between our coworkers in a friendly, vulnerable, and accepting environment. We are all just a bunch of mediocre singers and that’s okay! Get up there and sing your off-key version of “Bohemian Rhapsody!”
We had some good laughs with several of us struggling with our Spanish trying to sing Selena’s “Bidi Bidi Bom Bom” with our Costa Rican teammates. We all affirmed our relationships by pitching in to Garth Brooks’ “Friends in Low Places.” Finally, we sang some sad goodbyes to the tune of Elton John’s “Friends Never Say Goodbye” for those who were moving on.
We built upon each other’s ideas and work. The amount of collaboration on the look-and-feel alone created a team that bonded over the iterations and the knowledge shared.
Lastly, we had fun contributing back to the Drupal and Karaoke communities, building on the legacy we have created to do good wherever we find ourselves, and allowing others to have a very similar experience to our own.