Lessons From Album Tags: Part 2
Today’s post is part 2 of a series I’m working on that details important lessons I’ve learned while building my music-focused web application, Album Tags. If you haven’t read the first post in this series, I recommend starting here for some background on the project. If you have never tried out the application, head over to www.albumtags.com to check it out!
This second installment in this series is going to focus on the most recent addition to the site: user-created album lists. While creating this feature, I learned about some new, powerful functionality in MongoDB and Mongoose that allows developers to blend the worlds of relational and NoSQL databases. I also was able to practice balancing delivery of finished, usable features release against expected future data needs.
Custom user-lists is the fourth significantly impactful feature that Album Tags provides, following custom-tags, user-favorites and custom-connections chronologically. The idea for user-lists was sparked by some recent user testing I’ve conducted. During these tests, I noticed that user-favorites was quickly becoming the most highly-used feature of the site. The reasons behind this varied from person to person — whether it was ease of use, or the features ability to help users categorize a group of albums in a way that they could quickly find later.
As people started to fill up their favorites lists, they reported finding themselves wishing they had a way to create separate lists for different kinds of album collections, beyond just their favorites. Some even went as far as to create different gmail accounts in order to build multiple lists with the existing user-favorites functionality, working around its one-favorites-list-per-user limitation! As I covered in the first part of this series, user favorites is actually an attribute of an album in terms of data-structure design. The feature presents information to a user in a way that might look like a stand-alone list, but most decidedly is not a stand-alone data collection on the back-end. This design choice made for a simpler back-end with a single data model, but it also meant that adding the ability for users to create their own stand-alone lists would require some entirely new functionality and data models.
As a part of some related research I was doing on database designs in the winter of 2018, I created a small test version of the Album Tags database hosted in Google Cloud MySQL. This exercise quickly demonstrated how much more extendable a SQL database can be when it comes to adding or removing features. Looking back at this test database, it’s clear that the custom user-lists feature is also a great example of one way Album Tags could benefit from a relational data structure. I was looking to create a list that could exist as its own data model, while at the same time I needed to be able to access information about albums in a list without having to store duplicate information in a second collection.
Motivated by this relational database epiphany, I did some digging into MongoDB / Mongoose features that might allow me to “cheat” a little and relate albums in a list to document objects in my album collection. Luckily, it turns out there is! The mongoose populate and virtual attributes functionality provided everything I would need. I did not have the resources to continue to maintain a GCP MySQL database (both hosting cost and codebase updates), so this was great news.
First I created a new list data model that would store only the handful of album attributes I would need to populate the list UI. This would mean that an album could exist in a list whether or not it also existed in the albums collection. I then created an albums array attribute in the list model, and a virtual album model that would populate this array. Using Mongoose’s virtual attributes functionality, I was then able to link the virtual albums in the list > albums array to the actual albums in the album collection by matching Apple Album ID attributes. The Apple Album ID attribute exists separately from any MongoDB database _id’s, which allowed me to partially isolate this new data relationship from future changes in document structure. It also means that a list can return all the most current information about albums that are in the album collection alongside albums that only exist in the list.
Album Tags v1.2.0, which will include the user-lists functionality, does not yet use any specific information that can only be found in the album collection. It is very likely that it will need to do so in the near future, however! I discovered with the initial user-favorites release that as page of information grows in length, users start to wish they could reach for filters to more quickly find the specific information they are looking for. If users start taking advantage of these new custom user-lists as heavily as they did user-favorites, my new back-end data-structure design will allow me to more quickly implement filtering and help keep the user experience as streamlined as possible. I’m also enjoying how it allows users to create lists without requiring me to store extra albums when they aren’t also adding album-specific information like tags, connections, or favorites.
In this release, I am intentionally working to balance future design flexibility against my desire to always deliver solid minimum viable products. I know from past experience that new features can take a while to catch on, and users often take their own paths through the site that look different than I might have initially planned for. The new lists functionality is coupled with a new album UI page that couples the functionality that users previously accessed on the albumdetails and update pages. The goal of this change is to make it easier for users to take full advantage of all the features Album Tags offers, including the new custom user-lists feature. Though it has been heavily tested in staging already, I hope to conduct further user testing of the new album interface and list functionality in the months ahead, and to keep improving on the very powerful tool that the Album Tags site is becoming.
