a capture layer for the tidal player: when a song hits, you pull it. three taps, no typing, and it lands on your profile.
record pull: a capture layer for the tidal player. when a song hits, you pull it — three taps for craft, feeling, connection. no text box.
designed the vocabulary and flows, built two interactive prototypes (the vision and the shippable version), and wrote the backend audit that separates them.
in pitch at tidal, paired with a sibling concept (liner notes) as one "active listening" story.
when a song hits, you pull it. a pull is a small structured note on a track: the whole song, a moment in it, or a line of it. instead of writing why it mattered, you tap what it did — the craft you noticed, the feeling it gave you, what it connected to. pulls land in personal crates and surface on your profile.
the thesis underneath is that a listener is a contributor, not a consumer. liner notes documents what happened around a record; record pull documents what it meant to you. same rails: structured contributions, profile identity, a signal that can feed personalization.
every "why do you love this song" feature dies the same way: a text box. writing is a barrier, and the people with the best taste are often the laziest writers. i wanted the capture to be faster than skipping a track, to never pause the music, and to still produce data structured enough to be useful downstream.
the craft chips are the part i care about most. they give people who don't have the words a vocabulary for what they're hearing, and every chip has a plain-english definition one tap away: a friend explaining, no wine-tasting language.
the pocket — drums and bass locked into the groove, sitting a hair behind or ahead of the beat, on purpose.
the restraint — what the track leaves out. the band holding back on purpose.
the silence before it hits — the empty beat that makes the next one land harder.
the understatement — saying less than the moment deserves, and landing harder for it.
v2 is the full concept. v1 is the same product scoped to what tidal's backend supports today. i wrote a backend audit first, then cut anything that depended on rails that don't exist yet, and documented why. the pitch is stronger for having both: here is the vision, here is the version we could ship this quarter.
| suggested chips | needs unbuilt personalization batch features |
| "3rd listen" context | no per-user listening history service; v1 shows time only |
| your ear card + explainer | derived analytics, phase 2 |
| from your archive | no anniversary batch job |
| neighbors row | no crate-overlap batch job |
| people tagging | notification path unproven |
| location suggestions | kept as one optional free-text label (a string field) |
| added in v1: pull ⋯ menu | pin/unpin and delete are trivial writes on the pulls resource; report maps to userReports |
each demo is one html file: no build, no server, no network, all state in memory. the script is divided into constants / data / state / renderers / sheet logic / event delegation / init; screen names and click actions are frozen maps; every function has a docstring. one document-level click listener handles everything through data-action attributes. escape unwinds layers in order, dialogs trap focus and return it on close, and double-tapping save creates exactly one pull.
it uses tidal's real tokens (solidBase fills, the cyan accent for the context dot only, nationale at 20/16/14/12/10) so it reads as the product, not a mock of the product.
screens from v2, captured from the running demo. the flow: now playing → new pull → this moment → tag the craft → pulled → profile.
record pull and liner notes are the same thesis from two sides: liner notes is what happened, record pull is what it meant. they can share the badge and reputation system, share an identity model, and both feed recommendations. the pitch i'm making is to present them together as one "active listening" story.
placeholder, one honest paragraph: what you'd change about the vocabulary, the flow, or the pitch after showing it around.