Ky Decker

Mapping where districts start and end

Tue, 13 Feb 2024 05:53:27 GMT

import ProjectInfo from "../../../components/ProjectInfo.astro"; import zhi from "./zhi.jpeg";

Background

BetaNYC is a non-profit civic tech organization which builds tools and hosts public events to increase access to civic data and demystify government processes. I joined BetaNYC for 8 weeks during Summer 2022 as a Civic Innovation Fellow.

<figure> <figcaption> BetaNYC operates out of the Manhattan Municipal Building at 1 Centre Street. Technologists work alongside urban planners and other city professionals. Photo by Mattia Panciroli via Flickr, 2012. </figcaption> </figure>

The Challenge

Every day, you cross dozens of invisible borders: city council districts, school districts, police precincts, fire battalions, senate districts, zip codes, and more. These borders, although invisible, affect your life in important ways. Who collects your trash? Who represents you? Who arrives to care for you if you're injured? To answer these questions, it helps to know exactly where boundaries begin and end—and how they overlap.

BetaNYC maintains an open source web app called NYC Boundaries Map. First launched in 2018, the Boundaries Map allows anyone to view and explore overlapping jurisdictional boundaries within the city. The map is commonly used by city council staff and community boards in order to direct feedback from constituents to the correct department.

The Boundaries Map helps answer questions like, "which school districts does this community board serve?", "which sanitation district do I contact about the trash at 2nd Avenue and East 14th Street?", and "what police precinct am I in right now?"

The map was not pleasant to use.

<figure> <figcaption> The original Boundaries Map. 13 separate boundaries render with 13 separate border colors and labels. A rainbow spaghetti of geographic data. </figcaption> </figure>

Working together with Zhi, we noted several usability issues:

Toggling on more than two districts quickly made the map illegible.
Boundaries on the map itself were not interactive.
The map's implementation in Leaflet resulted in rasterized borders and labels, which looked blurry on HiDPI screens.
Viewing overlaps required a complex sequence of "querying" boundaries by selecting an administrative region and then selecting which district to intersect with, and the query itself was slow to execute.
The map required frequent manual zooming and panning, since it did not adapt automatically to queries.
Searching for an address required pre-selecting a borough.
Viewing additional metadata about a district required leaving the app and searching Google.
The app was desktop-only.
Visual design polish was generally lacking.

Additionally, there was no frontend framework in use (!) and I felt there was an opportunity to modernize and speed up development by adding one.

Research and Build

With a solid list of usability tickets to address, I got to work sketching ideas for how we might fit things together.

<figure> <figcaption> Sketching ideas. I explored how we might combine location search, district browsing, and overlap browsing within a single interface. </figcaption> </figure>

Without delay, we dove into code. After quick exploration with various frontend libraries, I installed Svelte and Tailwind, which would allow us to build more advanced functionality more easily. We moved from Leaflet to Mapbox since it offered us exciting opportunities to interact with the map directly.

We scheduled video calls with some frequent users of the Boundaries Map in order to better understand how they were using the tool and what could be improved. We shared our work-in-progress prototype for feedback. The participants were excited to be a part of the process and helped validate assumptions we had made.

Outcomes

After a few short weeks, we announced the updated app.

<figure> <div class="video-wrapper"> <video autoplay loop muted playsinline preload="none" poster="/video/boundaries-map-poster.png" > <source src="/video/boundaries-map.mp4" type="video/mp4" /> </video> </div> <figcaption> The new Boundaries Map. The updated app features overlaps on hover, direct interaction with the map, a unified navigation bar, and clearer information hierarchy. </figcaption> </figure>

The new map automatically zooms and pans to the selected boundary. It displays boundary overlaps on hover, allows single-click filtering by clicking any boundary, and supports mobile viewing. It links to the relevant webpage for a district when available, so users can find things like phone numbers for city council members. And it now allows users to share URLs for filtered views, and export overlap data to JSON for analysis in other tools.

Read the announcement or explore boundaries.

Reflections

I had never worked with mapping technology before, so it was fun to learn about how to wield geospatial data using Mapbox. (Huge thanks to Zhi sharing his knowledge of GeoJSON and Shapefiles!) Svelte and Tailwind were also new frameworks for me, and this project helped me get more familiar with their capabilities.

With extra time, I'd explore how to improve mobile navigation, since touchscreens can't support the same hover interactions as desktop. I'd also explore whether it's worth introducing color to the base map to more clearly communicate the locations of parks, water, and other regions. (Boundaries Map is open source, so maybe I'll get to these one day! Or maybe you, my reader, can make contributions of your own.)

BetaNYC introduced me to the city's vast library of open data, and I've continued to think about other possibilities for design and technology to surface public data for good.

Building Commonplace

Sat, 13 Jan 2024 05:13:17 GMT

import BeforeAfter from "../../../components/BeforeAfter.astro"; import actionPlanBefore from "./action-plan-before.png"; import actionPlanAfter from "./action-plan-after.png"; import memberTableBefore from "./member-table-before.png"; import memberTableAfter from "./member-table-after.png"; import ProjectInfo from "../../../components/ProjectInfo.astro";

import neves from "./neves.jpeg"; import minji from "./minji.jpeg"; import amber from "./amber.jpeg"; import taylor from "./taylor.jpeg"; import liza from "./liza.jpeg"; import owen from "./owen.jpeg"; import brennan from "./brennan.jpeg"; import craig from "./craig.jpeg"; import aster from "./aster.png";

Background

Cityblock is a health company which got its start within Google's Sidewalk Labs. Teams of clinicians and other health professionals provide in-community care to people on Medicare and Medicaid to improve health for an often-neglected population.

<figure> <div class="video-wrapper"> <video controls playsinline preload="none" poster="/video/cityblock-member-story-poster.png" > <source src="/video/cityblock-member-story.mp4" type="video/mp4" /> </video> </div> <figcaption> Andre, a Cityblock member, tells his story. Via{" "} <a href="https://vimeo.com/796683739">Cityblock on Vimeo</a>, 2023. </figcaption> </figure>

To support care teams and the members they serve, Cityblock builds and maintains a tool called Commons. I joined Cityblock in February 2019 as a Product Designer and recognized a need for a more systematic approach to design. Over the following two years, I built and expanded a design system in Figma and React. I named it Commonplace.

The Challenge

Cityblock was less than two years old, but Commons already offered a sprawling set of features, including: tracking member status, charting member acuity, coordinating member outreach, storing and editing core demographics, viewing health history, scheduling events, managing tasks for individuals and teams, creating and administering health assessments with automated scoring, texting members... all that, and more planned.

All of these features converged in an interface that looked like this:

<figure> (quality:100) <figcaption> The appearance of Commons when I joined Cityblock. Here, in the right-hand drawer, a user is composing a progress note about the current member. The varying colors, typography, and hierarchy make the interface difficult to understand. All member data displayed in this case study is notional. </figcaption> </figure>

Although there were some underlying commonalities and shared language throughout the product, the design was not scaling to meet the needs of its users or developers.

A lack of systemization was leading to longer development times, more time spent on undifferentiated work, more bugs in the product, and a user experience that was inconsistent and confusing. These problems would only worsen as Cityblock grew.

Mapping the Territory

Together with Cityblock's Director of Design, Neves, we catalogued the available views. I conducted a product audit, clicking through and taking screenshots of every view, dialog, drawer, and dropdown within Commons. The images were then organized into folders for future reference.

<figure> <div class="video-wrapper"> <video autoplay loop muted playsinline preload="none" poster="/video/product-audit-poster.png" > <source src="/video/product-audit.mp4" type="video/mp4" /> </video> </div> <figcaption> A product audit. We captured screenshots from every corner of Commons and organized them in folders corresponding to the app's information architecture. </figcaption> </figure>

The product audit helped us understand the current state of Commons, and it ushered in an essential archival practice for the future. Throughout my tenure at Cityblock, I would continue to catalogue product interfaces at least once a year.

Following the product audit, we created an interface inventory, collecting all variations and permutations of each component and displaying a collage of those permutations on a large poster board.

<figure> <figcaption> The interface inventory. The product audit screenshots were used to create a collage of each component's variations. How many header styles can you count? </figcaption> </figure>

This inventory allowed us to more easily spot inconsistencies and discuss how best to resolve them across the system.

Laying Foundations

Once the interface inventory was complete, we focused on design foundations—typography, color, and spacing. All components rest on top of these three primitives, and we wanted to get the essentials right.

Typography

Care teams at Cityblock are given small Chromebooks to take with them around the city. They use their Chromebooks to access Commons in many locations: the office, at community hubs, in members' homes, and in their car or on the subway.

As we laid out a typographic scale and compared different typefaces, we made sure to test text on the Chromebook's low-DPI display in a variety of real-world, less-than-ideal lighting conditions, in order to ensure that Commons was legible in every setting.

<figure> (quality:100) <figcaption> Low-contrast typography within Commons. Many views contained small, light text which was difficult to read under ideal conditions, and practically impossible in others. All data is notional. </figcaption> </figure>

With Cityblock's brand designer, Minji, we tested various typefaces for the product before landing on Graphik for its legibility and understated friendliness. All text colors within the new design system would adhere to WCAG AA or AAA contrast ratios.

<figure> (quality:100) <figcaption> The typographic scale. The base unit is set to 16 pixels and most header sizes scale up from there using rem. After experimentation, we decided to break this scale for the body size (15 pixels) and small text (13 pixels) in order to maintain medium-high data density. </figcaption> </figure>

Color

When considering colors in Commons, we prioritized pure function, accessibility and contrast, relation to the brand, and coherence as a whole.

I also examined the use of color in film to portray two separate settings—the hospital and the home.

<figure> <div class="two-up"> (quality:100)

![A collage of various "home" settings portrayed in film and TV.](./home-palette.png)(quality:100)

</div> <figcaption> Colors of the hospital, and colors of home. What feelings do these scenes evoke? </figcaption> </figure>

The hospital blue-greens are distinctly clinical, down to the robes worn by patients and doctors, and feel somber and sterile. “Home” tones, in contrast, emit a warm, welcoming glow. I wrote at the time, "Cityblock should feel less like the hospital, and more like home."

This led to guiding principles:

Guiding Principles for Color in Commons

Color gently. Opt for soft, subdued tones. Avoid highly-saturated, electric colors.

Use high contrast elements sparingly. What is the one action on any given view that deserves attention?

Skew warm. Do not tint neutrals blue.

And the resulting palette, defined as matching Figma styles and CSS variables:

<figure> (quality:100) <figcaption> The color palette. Colors are arranged along a spectrum from 100 (light) to 900 (dark). Some colors are aliased with a semantic name, so developers don't need to remember that icons are --color-neutral-600. They can just use --color-icon. </figcaption> </figure>

Spacing

We agreed to use an 8 pixel grid for all components, and we agreed on specific fixed widths for sidebars while leaving the rest of the app responsive to scale with the browser.

Building Components

Once foundations were in place, primitives were set up both in Figma and as CSS Variables in the codebase, and we were able to quickly and easily replace all existing hex codes with new color variables, replace existing padding, margin, widths, and heights with the new spacing scale, and swap out the typography.

Then began the long and steady process of building and replacing components one-by-one. Create a new Button. Test it. Swap out all existing buttons and delete all existing styles. Merge in the changes. Pick a new component, rinse and repeat.

<figure> (quality:100) <figcaption> Commonplace components. Each component in the codebase included unit tests, a Storybook story, and JSDoc comments for each prop in order to provide in-context documentation within VS Code. </figcaption> </figure>

Component work took place over the course of many months, alongside other feature work I was involved in. It took place largely independently, although I continued to collaborate with Neves for visual and interaction design feedback, researchers like Amber and Taylor for user insights, and engineers like Brennan, Aster, and Craig for code review.

We chose an incremental approach—rather than building and shipping an entirely new design system all at once—in order to maintain forward momentum, bug test along the way, and enable new features to be built with new components as quickly as possible.

Outcomes

By January 2020, most views within Commons used Commonplace components. Responses from engineers and care team members were overwhelmingly positive. Bug reports decreased, new features became easier to build, and engineers got to spend more time on differentiated work and less time fiddling with CSS.

Despite the addition of new components, several thousand lines of code had been deleted since the start of the project due to the reusability and modular nature of the design system—a meaningful reduction in complexity and technical debt.

<figure> <BeforeAfter before={{ src: actionPlanBefore, alt: "The action plan in Commons before the introduction of Commonplace.", }} after={{ src: actionPlanAfter, alt: "The action plan in Commons after the introduction of Commonplace.", }} /> <figcaption> Member action plan, before (early 2019) and after (early 2020). More information is available at a glance, without drilling down into cards and accordions. </figcaption> </figure>

<figure> <BeforeAfter before={{ src: memberTableBefore, alt: "The member table in Commons before the introduction of Commonplace.", }} after={{ src: memberTableAfter, alt: "The member table in Commons after the introduction of Commonplace.", }} /> <figcaption> Member table, before (early 2019) and after (early 2020). We aimed to main medium-high data density, helpful for our care staff, while making the UI feel more approachable and calm. </figcaption> </figure>

Around this time, I gave a company-wide talk about design systems, a concept which was unfamiliar to many people outside of the tech team. There was palpable excitement over seeing the drastic comparisons of before and after screens.

I would continue to contribute design and code toward Commonplace until my departure in July 2021.

Reflections

Care teams at Cityblock do difficult, meaningful work, and it's essential that the technology we build for them respects their time and energy. I'm proud of the way I was able to help transform Cityblock's approach to design and engineering, and (hopefully) reduce stress for our hard-working care teams.

Health tech is a complex space, and I still see dozens of ways that Commons could be streamlined. A design system is only as strong as the features it's used to build, but where a design system ends and product features begin isn't always clear. There is always more to do.

As I write this, in February 2024, I've just returned to Cityblock to help level up design systems again. After 3 years' absence, the system foundations I put in place have held up well. Some areas have flourished, others have remained the same, and a few weeds have sprouted, but it's a wonderful feeling to see the work you put so much effort into continue to endure.

Design outside the computer

Mon, 20 May 2024 17:30:34 GMT

This weekend, I added a new feature to my site. It's an old-school kind of webpage—something I've always wanted to create, but never really had the tools for until now.

It's a guestbook.

In the guestbook, anyone can write and publish a short message accompanying a name and optional URL. Once submitted, the message gets published to the top of the page for everyone to see. That's it—no likes, no shares, no threads. Nothing fancy.

<figcaption> The guestbook. People have already written kind things and drawn snails. </figcaption> </figure>

Astro DB, recently released, made it a breeze to spin up a database and implement publishing, even for a backend novice like me. But this post isn't about how to implement a guestbook. (UX developer Ryan Trimble already wrote a great tutorial for that!) It's about how invigorating it can be to design digital UI when you step away from your computer.

I didn't want to build just any plain stream of messages and text—I wanted to create something that felt warm, personable, and tactile—like signing a real book. To accomplish that, I first did something important: I shut my laptop.

The death of texture

The world around us is full of texture. From the bark of an elm tree to the weave of a linen blanket... even the body of a MacBook isn't completely smooth. Most digital spaces, in contrast, are textureless. Flat expanses of nothingness, stretching into a grainless void.

Our interfaces used to be more textured. During the heydey of skeuomorphism in the late 2000s, designers prided themselves on being able to craft realistic-looking wood grain, leather, glass, and other effects.

In 2013, Apple released iOS 7, featuring a redesigned user interface which, under Jony Ive, fully embraced flat design, bringing a swift death to the iPhone's skeuomorphism. The vast majority of digital spaces soon followed suit.

![The home screen of iOS 7.](./ios7.png)

</div> <figcaption> iOS 6 (left) and iOS 7 (right). iOS 7's flat design effectively killed skeuomorphic design trends across the industry. Images from Ars Technica. </figcaption> </figure>

Although the usability of the digital landscape has improved greatly over the past decade, I can't help but feel like the web lost a little bit of its soul when everything got flattened. So much of the web today feels boring, samey, and soulless.

Real-life objects can live on your website

Let's push that pendulum back the other direction! A bit, at least. Let's give the web some soul. Let's give it some texture.

How do you add texture? You could browse for Photoshop packs and fiddle with layers and blend modes to emulate real life. Or, you could grab some paper, scissors, and markers, and go craft in your living room on a nice Spring day.

The second option is way more fun.

<figcaption> Crafting cards. Stamps from Casey Rubber Stamps in NYC. </figcaption> </figure>

I spent an afternoon cutting out same-sized rectangles of card stock and doodling on them with whatever drawing tools I had around. Highlighters, pencil, crayons. Washi tape. Some ORAL stickers I stole from the queer health clinic. Every card is a little bit different.

I scanned in the cards using a flatbed scanner, cleaned up the images in Photoshop, and optimized them for web. Now all these physical objects have a digital home. :)

Tips for bringing physical media into digital UI

Working with physical media is rewarding. Quirks of the medium show up in ways that would require large effort to reproduce digitally—the edges I cut are not quite straight; the lines I drew are not perfectly even. Sometimes the ink smudged. It's okay! Desirable, even.

But translating media into digital space takes care to show up and perform well. Here are a few tips if you're thinking of bringing real-life objects into your digital designs.

Know how your layout will flow and reflow

Before starting, ask yourself: will text need to wrap to multiple lines? Will the element grow, or is it a static size? Does the design need to adapt to mobile? The more flexible the size of your elements, the more difficult it may be to craft physical media to support them.

When designing cards for the guestbook, I decided to design around a consistent 4:3 aspect ratio. For this, you can use aspect-ratio in CSS, which has coverage in 94% of browsers used globally.

.notecard {
  aspect-ratio: 4 / 3;
}

Enforcing a static aspect ratio means we need to be thoughtful about how much text a user can enter. How wide is each line of text? How many total characters can the content area support?

We can use the ch unit in CSS to define the maximum width of the text. The ch unit is equal to the width of the character 0 in the selected font, and since we're using a monospace font where all characters are the same width, we can use ch to display exactly 28 characters per line.

.notecard .content {
  width: 28ch;
}

We want to allow users to draw ASCII art and other fun things, too. To do that, we need to preserve whitespace for entries and prevent long lines of unbroken text from overflowing the container.

.notecard .content {
  width: 28ch;
  white-space: pre-wrap; // Preserve whitespace
  overflow-wrap: break-word; // Break long lines of text
}

We can enforce these limits in our HTML for form submission:

<textarea
  name="content"
  placeholder="Leave a message, write a poem, draw some ASCII art..."
  required
  rows="5"
  cols="28"
  maxlength="140"
></textarea>

We can also tell the form to preserve implicit newlines on submission with wrap="hard", which will guarantee that even if we change our CSS in the future or decide to display guestbook entries somewhere else, handcrafted ASCII art will remain intact.

<textarea
  name="content"
  placeholder="Leave a message, write a poem, draw some ASCII art..."
  required
  rows="5"
  cols="28"
  maxlength="140"
  wrap="hard"
></textarea>

There are a few other details to take care of, like showing a warning message when there's no room left for text, but the above code takes care of the basic setup for a fixed-size, fixed-length textarea.

Use a flatbed scanner

Dedicated scanners are cheap nowadays, and produce better results than photography. There are two types of scanners: CIS scanners have a very shallow focus, while CCD scanners have a wider depth of field. (I used a $60 CIS scanner for this project, but if I needed to buy a new scanner today it would be a CCD!)

I've found that 300 DPI is enough resolution for retina displays. Through trial and error, I also learned that putting a contrasting backdrop behind your documents will make it much easier to isolate the subject in tools like Photoshop after scanning.

<figcaption> Use a dark backdrop. A contrasting backdrop makes documents easier to isolate using tools like the magic wand. </figcaption> </figure>

Be mindful of color contrast and file size

Image backgrounds make it more difficult to measure accessible color contrast ratios for text on top; don't make any backgrounds too high-contrast. If you realize a shade you used was too dark, you can adjust contrast settings after scanning your images in. If there are any busy elements in your object, try to position them in a spot where text is unlikely to overlap. For the guestbook, I put the loudest elements in the margins, away from text.

The downside to working with images can be increased bandwidth. Use a command line tool like optipng to losslessly compress files, or a build tool like Astro's <Image /> to handle it for you. There's no use in designing beautiful objects if a massive file size will prevent them from ever being seen!

Incorporate some randomness

The real world isn't often aligned in perfect 90 degree angles; your interface doesn't have to align to the grid, either. Consider incorporating some variation in how you position elements, for example, by using Astro's define:vars style directive to pass variables into CSS:

---
// Rotate each notecard randomly between 3 and -3 degrees
const randomRotation = `${Math.random() * 6 - 3}deg`;

// Offset each notecard randomly between 12 and -12 pixels
const randomTranslateX = `${Math.random() * 24 - 12}px`;
---

<div class="notecard">
  <!-- Notecard contents -->
</div>

<style define:vars={{ rotation: randomRotation, translateX: randomTranslateX }}>
  .notecard {
    transform: translateX(var(--translateX)) rotate(var(--rotation));
  }
</style>

Have fun!

Embrace experimentation and the freedom of designing without a screen. There are so many potential areas to bring physical objects into digital experiences. It isn't always called for or necessary, but for the right moment, a touch of real, physical texture can go a long way toward making an experience that's a joy to use.

Now go off and draw your own UI. Don't forget to sign the guestbook before you go.

Shout out to Lean Rada, whose guestbook—discovered through the CSS JOY webring—offered inspiration for the themable index card format. Lean's even includes customizable fonts, colors, and stickers! Check it out.

Embrace friction

Mon, 08 Dec 2025 17:26:21 GMT

This weekend, I attended a letterpress course at the Center for Book Arts in NYC. I love working with and reading about typography, but until now, most of my interactions with type have been mediated through a digital display. I was thrilled to get physical. To touch the type!

We learned about the Vandercook proof press, an imposing steel machine from the early 20th century. We selected typefaces from the Center’s many cases of lead type. And over the span of two days, each of us set a page of text to print.

<figcaption> Vandercook proof presses. Located at the Center for Book Arts. </figcaption> </figure>

Letterpress is slow, methodical work. Instructor Sarah Nicholls says it “reshapes your relation to time.” Every letter, space, and detail is placed individually, entire forms composed by hand. Nicholls uses letterpress as the final step in her editing process—it forces deep consideration of every word’s purpose.

<figcaption> Letterpress workstation. On the left, a case of 18pt Caslon #540 lead type. Above, a reference using the California job case layout. On the right, a metal galley plate and composition stick, where type is being arranged. </figcaption> </figure>

Setting each character within the composition stick, you feel the shape of words. Physically, yes, but linguistically, too. There is a poetry to the shapes that form language. I felt this intimately, setting Ursula K. Le Guin's translation of the twenty-five hundred year-old Tao Te Ching.

As I composed my page, letter by letter, I thought about friction. Friction shapes our relation to a system. It is difficult to set type in letterpress, so I say less, with more intention. It is easy to type on a computer, so I say more. If I wanted to set this blog post in letterpress, it would take me a week or more. Would I use all of these words?

![The blocks of text are arranged in the center of the metal bed on the Vandercook press, positioned securely by steel blocks.](./vandercook-press.jpg)

</div> <figcaption> Setting type for print. Blocks are arranged individually on a composition stick, then moved to a galley before being placed and secured on the Vandercook press for printing. </figcaption> </figure>

Tools like ChatGPT take friction(-lessness) to a new extreme, where even writing is not required: only a rough impulse about the result you want. What do we lose when we abandon taking time to shape language? What meaning is made from pressing buttons on a text extrusion machine?

New technology often prizes itself on being "frictionless". But is lack of friction always a worthwhile goal? Thoughtfulness requires time. Learning requires time. Friction, ever obstinate, forces us to slow down. When we slow down, we may discover things that are easy to miss when zooming by at quicker speeds.

In a world that constantly demands we move faster and be more productive, there is joy to be found in doing less, more slowly, with greater intent.

<figcaption> Taoing, from Tao Te Ching by Lao Tzu, translated by Ursula K. Le Guin. Title set in Lydian Condensed Bold, 48pt. Text set in Caslon #540, 18pt. </figcaption> </figure>

The penultimate line of "Taoing" ends with an exclamation point. After carefully arranging the preceding sixteen lines, letter by letter, over two days, placing that exclamation point exploded like a firework inside of me.

Bang! I felt it.

I felt it because I was going slow enough to notice.

The Center for Book Arts offers many workshops for letterpress, risograph printing, book binding, and more. I sincerely recommend taking a class if you're in the NYC area. I will definitely be returning.

Edit, December 10: After publishing, I came across a related article by tante about friction, AI, loneliness, and touch:

[...] friction is not just “things not working properly”, it can also be read as being touched. Just as crowded spaces create friction by other people being in my way while moving, a process with friction makes me feel other people's work, their point of view and how it differs from mine, makes me feel their needs and wants. Friction is part of what being in, being part of society is.

<cite>Friction and not being touched</cite>

It's worth reading in full.

Edit, March 25: I've encountered a few more articles on the topic of friction:

Kill Chain by Kevin Baker examines Palantir's Project Maven and its role in the deaths of 175-180 Iranian schoolgirls during a February 2026 attack by the US.
The Shape of Friction by Matthias Ott muses on "working with the nature, the 'grain' of a material rather than against it." and says "Professional work always has friction." The writing is a response to Dave Rupert's piece People are not friction.

I've started an Are.na channel to collect other examples of friction in systems/software.

Creating a catalogue of gender-swapped song covers

Sat, 02 Mar 2024 05:40:50 GMT

import ProjectInfo from "../../../components/ProjectInfo.astro"; import abba from "./abba.jpeg";

Background

In 2021, I read the novel Paul Takes the Form of a Mortal Girl by Andrea Lawlor. Early in the book, Paul gushes about his love of gender-swapped covers:

Some covers deliver the age-old simple pleasures of drag—knowledge, the opportunity to investigate the simulacra and make comparisons, that obscure little frisson of dissonance. Take Joan Baez singing “Virgil Kane is my name… like my father before me, I’m a working man” (which, of course, is originally from The Band’s “The Night They Drove Old Dixie Down)” or Cait O’Riordan from the Pogues crooning, “My name is Jock Stewart, I’m a canny gun man” (from the traditional “I’m a Man You Don’t Meet Every Day”). Joan Baez’s contralto can, if you squint your ears, pass as a farm-boy tenor; Cait O’Riordan’s chalky delivery might be that of a rich ponce.

I listened to each cover and original, enamored with how lyrics could completely transform under another artist's tone, tempo, and gender.

I began compiling Paul's songs into a playlist, and then I added more of my own. And more. And more. For another two years.

The Challenge

As my covers playlist grew, so did the tedium of managing it in Spotify. I kept all covers alphabetized (by hand), and I maintained two separate playlists—one for both covers and originals, and another for covers only.

<figure> <div class="video-wrapper"> <video autoplay loop muted playsinline preload="none" poster="/video/adding-spotify-poster.png" > <source src="/video/adding-spotify.mp4" type="video/mp4" /> </video> </div> <figcaption> Difficulties organizing in Spotify. The interface makes it challenging to organize songs within large playlists. (Sorting by title exists, but it's unreliable here—John Denver's "Take Me Home, Country Roads" deserves to live beside Judy Collins's "Leaving on a Jet Plane/Take Me Home Country Roads".) </figcaption> </figure>

After managing this playlist for two years, I decided to build a custom solution to host and catalogue covers. I named it Genderswap.fm.

Laying Foundations

This personal project was my first time working directly on the backend. Thankfully, Supabase—an open source alternative to Google's Firebase—made it easy to get started.

I experimented with alternative data structures and landed on a two table model: one table for songs, and one table for covers, which links two song rows together along with extra metadata about their relation.

<figure class="no-bleed" style="max-width: 600px"> (quality:100) <figcaption> Database schema. This is the shape of the data for Genderswap.fm. </figcaption> </figure>

I decided to use Svelte and SvelteKit for my application framework. I had previously used Svelte in my build for the NYC Boundaries Map, and the addition of SvelteKit made it easy to manage routing, server-side rendering, and API requests. I set up a Spotify Developer account and used the Spotify Web API TypeScript SDK to make it easy for users to search for and enter songs. I also added Melt UI, a Svelte-based component library, to help build the submission form.

Ideation

For the design, I knew I wanted to allow users to browse by pairs of songs shown together. It wouldn't be too different from browsing "by album" in any other music tool, but rather than displaying a single album for each result, I'd display original/cover pairs.

From there, users could tap in to view the details of a cover, and listen to the original and the cover side-by-side, with notes about their differences.

![Search and filtering sketches.](./sketch-2.png)(quality:100)

</div> <figcaption> Exploratory sketches. Ideating around the display of albums, how to structure the submission form, and how to surface filters. I still hadn't figured out what I would ask users to tag manually, and what I could tag automatically using Spotify's API. </figcaption> </figure>

Finding a Design Language

To communicate the way these covers remix sound, reinterpret lyrics, and reconfigure meaning, I established a visual motif to thread its way through the app: two objects, overlapping and askew. Sharing space, but different.

<figure> (quality:100) <figcaption> Overlapping visual motif. Intentional overlapping groups the original and cover as a single unit. The cover album is larger and foregrounded for emphasis. </figcaption> </figure>

Typography is set in Labil Grotesk, a queer font which topples over itself, unable to rest upright, mirroring the off-kilter elements elsewhere in the app.

<figure class="no-bleed"> (quality:100) <figcaption> Labil Grotesk in use. I love the way the 'O' falls over, ready to roll off the screen. </figcaption> </figure>

While the topsy-turvy contextual alternates were enabled for page-level headings, I disabled them for smaller text to prioritize legibility.

Little Big Features

As with all my work, I looked for opportunities to introduce small but meaningful details.

<div class="two-col"> <figure class="no-bleed"> <div class="video-wrapper"> <video autoplay loop muted playsinline preload="none" poster="/video/tag-filtering-poster.png" > <source src="/video/tag-filtering.mp4" type="video/mp4" /> </video> </div> <figcaption> Automated tagging. Covers are automatically tagged with attributes like "sadder" or "more danceable", and you can search and filter by tag. </figcaption> </figure> <figure class="no-bleed"> (quality:100) <figcaption> Readable URLs and page titles. Share human-readable URLs which accommodate diacritics and non-Latin characters. </figcaption> </figure> <figure class="no-bleed"> (quality:100) <figcaption> "Covered as..." Conditionally see when a cover's title diverges from the original. </figcaption> </figure> <figure class="no-bleed"> (quality:100) <figcaption> Earlier release prompting. Behind the scenes, the app will search for earlier album releases for your original song. If one is found, it'll prompt you to update your submission. </figcaption> </figure> <figure class="no-bleed"> (quality:100) <figcaption> Rich social previews. Custom Open Graph images generated using Satori and Sharp display a cover's title, album art, and tags. </figcaption> </figure> <figure class="no-bleed"> (quality:100) <figcaption> Just the titles. Remaster dates, "(Featured on...)", "[From the Movie...]", and other cruft is stripped out, leaving only the artistic title. </figcaption> </figure> <figure class="no-bleed"> <div class="video-wrapper"> <video autoplay loop muted playsinline preload="none" poster="/video/confetti-poster.png" > <source src="/video/confetti.mp4" type="video/mp4" /> </video> </div> <figcaption> Celebrate contribution. Confetti erupts after each new submission. 🎉 </figcaption> </figure> <figure class="no-bleed"> (quality:100) <figcaption> Pre-filled name for repeat submissions. Entered names will be pre-filled for future submissions on the same device. </figcaption> </figure> <figure class="no-bleed"> <div class="video-wrapper"> <video autoplay loop muted playsinline preload="none" poster="/video/paste-link-poster.png" > <source src="/video/paste-link.mp4" type="video/mp4" /> </video> </div> <figcaption> Paste links into search. Title too hard to type? Just copy and paste the Spotify link. </figcaption> </figure> </div>

Explore covers, get a random cover, or submit your own.

Outcomes

I didn't have any massive ambitions for this app—it was mostly a way for me to learn new technology, and see if I could manage my covers library in a way that felt a little more natural. In that sense, it was a success!

After finishing the first version of the app, I emailed it to Andrea Lawlor, sharing how Paul Takes the Form had inspired me. A few days later, I received this reply:

<figure class="no-bleed" style="max-width: 585px"> (quality:100) <figcaption> Andrea Lawlor's reply. You heard it here, folks. The coolest thing ever. </figcaption> </figure>

I was overjoyed. Thanks, Andrea. Thanks, Paul.

Genderswap.fm is now showcased on Made with Svelte and the Utopia.fyi Showcase.

Reflections

There are many improvements I'd still love to make to the app. At the top of the list is an in-app audio player. I'd also like better search, and a way to automatically generate and sync the Genderswap.fm database to a Spotify playlist. I track all issues and ideas on GitHub, and contributions are welcome.

I learned a lot building this out. The backend is not as scary as it seems, and I taught myself that it's possible for me to build a full-stack app from start to finish! There's still more to learn, and I hope to continue working on this project when I have time.