From a music wiki to a more complete What I Learned While Opening Digging Music
What I Learned While Opening Digging Music, I started improving the service in several directions at once: the main screen, community structure, navigation, wiki editing UX, and the lyrics database.
This was not just a visual update. It was closer to a product restructuring. The goal was to make Digging Music feel less like a scattered set of features and more like one connected music platform.
Main screen renewal
Before the update, the main screen showed music reviews and new releases, but the user flow was still unclear. It displayed content, but it did not strongly guide users toward reading, clicking, and exploring.
In the renewed main screen, I added announcements to the top and simplified navigation so users could move directly to major pages without relying on dropdowns.
I also exposed reviews and lyric-related content in a more curated form. Horizontal scrolling was added to improve exploration, especially for content blocks where users naturally browse through albums, songs, or stories.
The biggest question was what should appear on the main screen.
Since Digging Music's strongest feature is its wiki-based music interpretation, I tried to design the page around a reading flow: interesting content appears on the main screen, the user clicks it, and that click leads naturally into deeper exploration.
I also moved the date selection feature, which had previously existed only on the chart page, into the main page. The data loads responsively when clicked, reducing unnecessary friction for users.
Community restructuring
The community categories were also reorganized.
At first, the categories were based on a limited set of genres. But this caused two problems. Some genre boundaries were ambiguous, and users also wanted the site to cover more diverse scenes.
So I reorganized the community around broader music scenes: hip-hop, rock, indie, K-pop, J-pop, jazz, pop, electronic, classical, and more. Users can now select multiple scenes when writing a post.
I also decided to use the word "scene" instead of "genre" across the site. "Genre" feels rigid and taxonomic, while "scene" better captures the cultural and social side of music.
Header and navigation improvements
The header also needed to be simplified.
Previously, community pages were hidden inside a dropdown. To reach a specific genre or topic, users had to go through an extra selection step. This made the site feel slower and less direct.
In the new structure, the community became its own tab page, and scene selection happens inside that page. Wiki and review pages are also accessible directly from the header.
The result is a faster and more intuitive navigation flow. Users can now move to the core parts of the service without first decoding the menu structure.
Wiki editing UX and database redesign
The largest improvement happened under the surface: the lyrics and annotation database.
The first structure treated each lyric line as an individual entity. Each line object had translation and annotation fields attached to it.
This was intuitive at first, but it created several serious problems.
First, annotations could not naturally cover multiple lines. If I wanted to explain a chorus, hook, or repeated meaning unit across several lines, I had to copy the same explanation into each line.
Second, repeated lyrics required repeated translations. If the same hook or chorus appeared multiple times, the same translation had to be entered again and again. If the translation changed, every duplicate line had to be edited manually.
Third, the database became filled with meaningless line objects. In Bubble, each lyric line had to be saved as a separate object to store it locally. Most of those objects simply contained API-loaded lyric text and had no real user-edited information. In practice, the database accumulated a huge amount of dead data.
Fourth, server usage became a real concern. Creating or modifying every line object required Bubble's "schedule API on a list" workflow, which is one of the heavier operations in Bubble. A typical song has 30 to 60 lyric lines. When translations and annotations were added, the amount of backend work per song became unnecessarily large.
The new lyrics data model
The redesign started from one principle: do not store the original lyrics unless necessary.
Original lyrics are fetched from APIs such as Spotify in real time. They are saved only when the API cannot provide them. Even then, the full lyrics are stored as one multi-line text field rather than as many separate line objects.
The structure also shifted from line-centered to track-centered.
Each track has a unique Spotify Track ID. Lyrics are managed through a single track_lyrics object, and multiple tracks can be connected to the same lyrics object when needed. This matters because the same song can exist as separate objects depending on whether it appeared as a single, a pre-release, or part of a full album.
Translations were also simplified. Instead of storing translations as a list of objects, the full translated lyrics are stored as one text field.