Video

• Gallery view showcases one album’s artwork at a time.
• Manual reordering lets you put your favorites on top.

Kinda like a crate of records!

I started SongPocket in 2020.

Five years changes a person. Past Me would hate some aspects of modern SongPocket. But I still want giant artwork with no distractions.

Now, bittersweet news: future updates are paused, because I’m becoming a pirate.

I’ll still be working on my apps, just not publicly. SongPocket remains available and open-source. (Likewise with Font Booklet.)

And you’ll still see ideas from me, just not here.

I fell in love with computers when I saw iMovie in school, because I learned that technology can make people creative in ways they otherwise never could be.

Ever since, I’ve tried to pay forward that experience. Here’s to magic carpets for the mind.

Specifically, I rewrote how it positions albums and songs, and saves those positions to storage.

The goal

SongPocket lets you reorder albums and songs, so it stores the position and Apple Music ID for each.

To do that, it used to use Core Data, which provides both runtime structures and persistence. Those are separate under the hood; you use different code to handle RAM and storage, because RAM is fast but temporary, while storage is slow but persistent.

So why replace Core Data? I’m preparing to someday switch from Media Player IDs to MusicKit IDs, which’ll require changing the persistence system anyway. I could migrate to a new Core Data model or to SwiftData, but I chose … 🥁 A PLAIN-ASS TEXT FILE

Because control. I’ve learned that controlling my software is critical for my happiness. Testing how APIs behave sucks; deciding how to solve problems is fun.

There’s a limit—I haven’t written an OS. But user data is priceless, and it makes me sick to risk destroying it by holding the tool wrong. This documentation is horrifying. Yes, Core Data should exist, but think carefully before locking your jewels in an opaque box.

I can show you. Here’s SongPocket’s Core Data storage:

How confident am I that this contains exactly my data and no more, and that I can control it perfectly for SongPocket’s entire future? Is -10 out of 5 allowed? 😨

Now here’s SongPocket’s plain-text storage:

Lines with only numbers are album IDs, and lines with an _ are song IDs within those albums. I just explained the entire format in one sentence. It’s dumb in the best way: understandable and debuggable.

So how did I make that work?

The rewrite

For persistence, I wrote some code called Disk to write and read the file. It was my first time, but it wasn’t rocket science. Bam.

But the runtime structures. Every part of SongPocket that shows and edits albums and songs was accustomed to Core Data. So I had to rearchitect all that.

Or rather, I got to. The result is so straightforward because it suits my exact needs, and I love it.

For example, the old way to add a song:

if let existing_songs = album.contents as? [Song] {
  existing_songs.forEach { song in
    song.index += 1
  }
}
let song = Song(context: context)
song.id = mpMediaItem.persistentID
song.container = album
song.index = 0

Versus the new way:

let id = mpMediaItem.persistentID
album.songIDs.insert(id, at: 0)
Librarian.register_songID(id, with: album)

That Librarian thing is a chunk of RAM that lets any part of the app quickly look up album and song info, like which album contains a given song.

There are multiple ways I could’ve enabled that, and it wasn’t obvious at first which was best. I’m actually still unsure what was the best way using Core Data, because I don’t know its internals.

As a guideline, I made my caller code as straightforward as possible.

For example, SongPocket adds songs in 3 scenarios:

1. Loading from storage
2. Merging from Apple Music
3. Migrating from Core Data

In all 3, I need to add a song ID at some position in an album. But when migrating, I actually don’t want the rest of the app to be able to look up that song yet.

let id = old_song.persistentID
new_album.songIDs.append(id)
// Don’t need:
// Librarian.register_songID(id, with: new_album)

So I didn’t give Librarian a procedure like insert_and_register_songID that I had to use everywhere. Instead, when migrating, I insert the song and just don’t register it. But I do register it in the other 2 cases.

I reckon if I forgot about this code for a year, this would be the easiest thing to rediscover.

So I rewrote all editing and merging code to use Librarian’s runtime structures instead of Core Data’s. Bam.

At this point, if SongPocket were a new app, I would’ve been done. But it has existing data, so I had to migrate that.

The migration

Permanence is scary. Once you save data out there, you want to support it forever. Meanwhile, lousy apps waste storage until you delete and reinstall them, because they don’t clean up after themselves. I wanted to do it right.

I realized that a migration’s goal is to sneak in modern save data as if the old system never existed. None of the code that runs after migration should even know it happened. After SongPocket v3.5.2 starts up, it always has an albums file and an empty Core Data database.

But also, let’s accommodate downgrading from v3.5.2 somehow, then re-upgrading. That’s useful mostly for development, but also just in case. What should happen? Let’s try to not break spacetime:

1. SongPocket v3.5.1 and earlier ignore any albums file and operate with Core Data. They don’t know any better.
2. That’s the only scenario where both an albums file and Core Data data exist, and in that case, Core Data is the truth.
3. So SongPocket v3.5.2 always checks for Core Data data on startup, and if it finds any, it uses that to replace any albums file.
4. Then it destroys the Core Data database.

So it always saves your newest data in the newest form, and leaves nothing behind.

The lesson

Did I need to do all that? No.

But was it the right move? I think hell yes.

A day job probably would’ve made me migrate to another persistence system, not my own. “Don’t reinvent the wheel!”

But listen: everything I learned here is reusable knowledge. You don’t get that by only using other people’s systems. The next time I migrate, I know how to do it and why, regardless what exactly I’m moving from and to.

Just helping prevent the collapse of civilization.

Now I wanna work on the UI. In the meantime, enjoy SongPocket v3.5.2: it has an all-new engine, and zero new features*.

SongPocket – App Store

(*Reflecting changes to your Apple Music library is now 1.9× as fast, and first reading it is 51× as fast. Tested with 12,000 songs.)

dear internet

i am granny yuai and i am 84 today as far as u know.

i got the ios 18 on my iphone and the video swipy bar in the photos app is no good.

on the ios 17 it had a long swipy bar for long videos but now it’s always the same size.

so now when i watch a 4-hour video of my great great great grandkids i touch it and it goes like 5 minutes not 5 seconds.

i wish they would keep the good things.

love

granny yuai

It’d be nice to not need to tap or swipe over each item, and remember, no Shift or Command keys.

I can’t believe we still don’t have a convention for this, seventeen years after the iPhone.

Band selection is inadequate

Yes, iOS lets you swipe to quickly select in lists and grids, but you still have to smear your finger over each item.

That’s like dragging a box on a computer. It’s better than nothing, but you don’t want to select 1000 items that way.

Let’s call that band selection. I want range selection: “1, 1000, and everything in between”.

And it must be discoverable.

My design

Here’s what I came up with:

1. If an item is unselected, offer “Select Range Above” and “Select Range Below”. If it’s selected, offer “Deselect Range Above” and “Deselect Range Below”.
2. “Select Range Above” selects that item and continues selecting upward, until it reaches the top or an already-selected item.
3. Likewise for “Below” except downward.
4. Likewise for “Deselect” except deselecting.
5. Disable “Above” if there’s no item above, or it has the opposite state from this item. This is important; if “Above” works but doesn’t do anything meaningful, you sit there confused wondering what it’s for.

It’s simple yet powerful.

Please copy it! If you’re a product manager looking for a UI to use in your app, you can stop reading now. My source code is below.

But for enthusiasts, here’s my thinking.

Failed approach

I tried imitating Shift-click, which selects the range from your most-recently selected item.

Hence “Select Range From Previous”, which points up if you last selected an item above, and down otherwise.

So if you select A then G, then try a range from C, the range should point down.

But it’s not so simple. What if you then deselect G? The range from C should point up again, right?

Apparently this design needs to remember the order in which you selected each item, which is a lot of hidden state.

And deselection is confusing. What if you select A–G, then want to deselect A–C? The range from C depends on how you selected A–G.

At this point, I realized I don’t fully understand Shift- and Command-click, and I reckon you don’t either. Quiz time! What happens if you do this?

1. Click A.
2. Shift-click G.
3. Command-click C.

Good so far? Now Shift-click A.

Did you expect that? I didn’t.

Elegant approach

My touch-friendly design avoids all these problems.

There’s no hidden state or order effects; you can always see what’ll happen, without ever considering what you did earlier. The resulting clarity is incredible.

Imagine using this UI to select hundreds of images among thousands, or key moments in a long video.

With Shift- and Command-click, you’d give up, because you’re always one misclick away from messing up a range or deselecting everything; it’s a breath-holding operation. So those UIs sometimes give you helper tools like marking, filtering, and splitting.

But with touch-friendly ranges, I could spend hours selecting clips in a movie, and never worry about losing my place.

A shortcoming

One problem is that most of my testers initially thought ranges always reached the top or bottom of the list. They were surprised when they first saw a range stop at the end of a block.

So some people will stick with subpar usage: if they selected T–Z and want to add L–P, they’ll think they need to …

1. On L, “Select Range Below”, temporarily selecting Q–S.
2. On Q, “Deselect Range Below”, losing the original selection.
3. On T, “Select Range Below”, restoring the original selection.

Hopefully you realize it’d be better to …

1. Select L.
2. On P, “Select Range Above”.

(… or select P, then on L, “Select Range Below”.)

“Well, if people think the range always reaches the end, why not just make it do that?” That subpar usage is why.

“Select to End” is only a little simpler, yet an order of magnitude less powerful. Intuitiveness is important, but not the top priority.

Maybe a simple wording change like “region” would communicate ranges better, but I haven’t had luck. If anyone can invent a better design, I’d love to know.

Regardless, even with subpar usage, touch-friendly ranges are still more useful than the statuses quo, which are band selection or Shift- and Command-click.

Please copy my design

I once whinged to a senior programmer with good taste that to delete ten songs on my iPhone, I had to swipe ten times. I thought that was stupid when I was a kid using an iPod Touch in 2009. Yet I assumed we’d surely figure out range selection on touchscreens within a few years. But here we are with iOS 18.

“So make something better, and share it with the world.”

There.

Please copy and improve my design if you think it’s a good idea. Any UI that lets you select multiple items should let you select ranges! In fact, this touch-friendly design also works on computers. In five years, when I want to move multiple emails, contacts, or bookmarks, I don’t want to have to tap or swipe over each one.

Just like you deserve games that inspire curiosity, you deserve computers that help you think great ideas. A simple, powerful way to handle multiple items is an important part of a bicycle for the mind.

struct RangeList: View {
  var body: some View {
    NavigationStack {
      List(0 ..< Self.rows.count, id: \.self) { index in
        let isSelected = selected.contains(index)
        HStack {
          if isSelected {
            Image(systemName: "checkmark.circle.fill")
              .foregroundStyle(.tint)
          } else {
            Image(systemName: "circle")
              .foregroundStyle(.secondary)
          }
          Text(String(Self.rows[index]))
          Spacer()
          Menu {
            aboveButton(index, isSelected)
            belowButton(index, isSelected)
          } label: {
            Image(systemName: "ellipsis.circle.fill")
              .symbolRenderingMode(.hierarchical)
          }
        }
        .contentShape(Rectangle()) // Makes spacer tappable.
        .onTapGesture {
          if isSelected {
            selected.remove(index)
          } else {
            selected.insert(index)
          }
        }
      }.toolbar {
        ToolbarItem(placement: .topBarLeading) {
          Button("Clear") { selected = [] }
        }
      }
    }
  }
  @State private var selected: Set<Int> = []
  private static let rows: [Character] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".map { $0 }

  @ViewBuilder private func aboveButton(
    _ index: Int, _ isSelected: Bool
  ) -> some View {
    Button {
      var inRange = index
      if isSelected {
        while
          Self.rows.indices.contains(inRange),
          selected.contains(inRange)
        {
          selected.remove(inRange)
          inRange -= 1
        }
      } else {
        while
          Self.rows.indices.contains(inRange),
          !selected.contains(inRange)
        {
          selected.insert(inRange)
          inRange -= 1
        }
      }
    } label: {
      Label(
        isSelected ? "Deselect Range Above" : "Select Range Above",
        systemImage: "chevron.up.circle")
    }.disabled({
      let above = index - 1
      guard Self.rows.indices.contains(above) else { return true }
      return selected.contains(above) != isSelected
    }())
  }
  @ViewBuilder private func belowButton(
    _ index: Int, _ isSelected: Bool
  ) -> some View {
    Button {
      var inRange = index
      if isSelected {
        while
          Self.rows.indices.contains(inRange),
          selected.contains(inRange)
        {
          selected.remove(inRange)
          inRange += 1
        }
      } else {
        while
          Self.rows.indices.contains(inRange),
          !selected.contains(inRange)
        {
          selected.insert(inRange)
          inRange += 1
        }
      }
    } label: {
      Label(
        isSelected ? "Deselect Range Below" : "Select Range Below",
        systemImage: "chevron.down.circle")
    }.disabled({
      let below = index + 1
      guard Self.rows.indices.contains(below) else { return true }
      return selected.contains(below) != isSelected
    }())
  }
}

It’s got reorderable albums. Group related releases, or put your favorites on top.

And super fun expandable tracklists!

What’s great

SongPocket is the best damn music viewer I know of. I made it for myself.

You can’t unsee reordering. How come you can reorder your to-dos, but not your albums? Your collection feels so personal when you can arrange it just so.

Artwork goes edge-to-edge because phones are tiny compared to vinyls. You don’t even need to play an album to see it at full size.

And the play confirmation prevents accidental interruptions. It makes other apps feel like hot coals.

But most importantly …

Spatialness

Each album or song appears in exactly one place. That might seem obvious, but other apps let you find each song by artist, by album, etc.

SongPocket feels different: it’s like flipping through vinyls, not querying a database.

Consider how the App Switcher shows each app as a card. If it also had an alphabetical list of the same apps, the cards wouldn’t seem like physical objects anymore. It’d feel more like Activity Monitor.

That’s actually how iOS 14 ruined the Home Screen. App icons now appear on the Home Screen and in App Library (possibly thrice!), so it no longer feels like they live on the Home Screen. It’s no longer spatial.

In SongPocket, “now playing” isn’t a screen that duplicates the current artwork; it’s a button that navigates to the current album. It doesn’t overlay a new view; it scrolls the album list to that album.

This is a surprising tradeoff because you lose your place, but the spatialness is worth it.

In SongPocket, you don’t browse info about albums; you browse albums themselves.

What could be better

SongPocket’s major design flaws are a lack of scaling and hierarchy.

The scaling problem is the horrible information density: you can see like two album titles, and the list is a kilometer long.

I don’t want a grid because it forces your eyes to zigzag.

I tried making closed albums half-height and expanding them to square when you opened them, but it felt too jumpy.

A solution could be like Cover Flow sideways, where albums shrink as you scroll them away from the center. That would be both scalable and spatial.

The hierarchy problem is that you can’t group albums to view or manipulate them.

I used to have multiple crates, but I hated the UI because it broke spatialness: “what do you mean, the crate list is both the main view and inside this sheet?”

I’ve since changed the main view to the album list, and a solution could be a crate menu, which changes the albums in the list.

To move albums between crates, you’d select them, then switch crates, and those albums would move with you to the top of that crate. That would be spatial.

A third problem is select-mode hell. “Select-albums mode” is separate from “select-songs mode”, which isn’t obvious, and in “select-songs mode”, you can scroll away, which is bananas.

A solution could be to hide other albums when an album is open, but when I reinserted them, the table view kept doing an unnecessary animation I couldn’t prevent.

Fourth, there should be an artwork-only view that hides everything except a single album cover, and allows pinch to zoom. There’s no excuse for a music app being a worse artwork viewer than the Photos app.

Anyway, future potential. SongPocket already does things no other music app does, and it’s free, so try it out!

SongPocket – App Store

In Tog on Interface, Tog designs a picker for selecting one or more options, but not none.

Think languages or time zones: you need one; you can have more; you can’t have none.

We actually don’t have a dedicated component for this, even today. We use checkboxes for multiple selection, and disable continuing when none are selected.

But what if?

So Tog gets cracking.

It’s riveting. He makes prototypes that epic-fail usability testing, and ultimately finds this design which makes sense to users:

1. Click to select or deselect.
2. If deselecting would leave none selected, auto-select the next option.
3. … but if there’s no next option, auto-select the previous option, and enable “go up” mode.
4. Disable “go up” mode after auto-selecting the topmost option, or the user manually selects any option*.

It was inspired a drop of mercury, which pops sideways when you poke it. Otherwise, it’s regular checkboxes.

So we’re all dying to find out how this actually feels to use, right? What better to do this fine day than implement a fabled UI component? Are you not entertained?

Drum roll:

struct MercuryPicker: View {
  var body: some View {
    List(0 ..< picker.options.count, id: \.self) { index in
      HStack {
        Image(
          systemName: picker.selected.contains(index)
          ? "diamond.fill"
          : "diamond"
        )
        Text(picker.options[index])
        Spacer()
      }
      .contentShape(Rectangle())
      .onTapGesture {
        if picker.selected.contains(index) {
          picker.deselect(at: index)
        } else {
          picker.select(at: index)
        }
      }
    }
  }
  @State private var picker = OneOrMore(
    ["English", "French", "Japanese", "Klingon", "Lojban"],
    selected: [0])!
}

struct OneOrMore {
  init?(_ options: [String], selected: Set<Int>) {
    guard !options.isEmpty, !selected.isEmpty else { return nil }
    self.options = options; self.selected = selected
  }
  let options: [String]
  private(set) var selected: Set<Int>
  mutating func select(at index: Int) {
    selected.insert(index)
    // squishesUp = false // * Tog’s version includes this, but I find it clearer without it.
  }
  mutating func deselect(at index: Int) {
    selected.remove(index)
    guard selected.isEmpty else { return }
    var toSelect: Int = squishesUp ? (index-1) : (index+1)
    if !options.indices.contains(toSelect) {
      squishesUp.toggle()
      toSelect = squishesUp ? (index-1) : (index+1)
    }
    selected.insert(toSelect)
  }
  private var squishesUp = false
}

… and??

It’s fine.

The hidden state of “go up” mode is a little annoying. It also has hidden logic; so does the checkbox version, but that’s simpler.

I tested it on my parents. Both figured out the “one or more” rule, but only one figured out which way the mercury would pop every time.

The checkbox version is better overall because it’s easier to both learn and implement.

But that was fun!

Open questions

1. What should we call this component? I like “multipicker”; shorter than “one-or-more picker”, and easier to explain than “mercury picker”.
2. Can someone make a web version so everyone can play with it? How about you? [Update: that was quick.]
3. Why doesn’t iOS even distinguish between checkboxes and radio buttons?

To add a line in between line 10 and 20, I just have to pick a number between 10 and 20, like 15. And then I type my line.

—Kurt Leucht

I thought they were just for GOTOs.

There’s more:

I wasn’t happy with line 15 and I wanted it to be different. I could just type in a new line number 15.

That blew my whippersnapper mind.

The trick is, there’s no files and no compiling. There’s no “editor”!

You simply write into the computer’s memory, and tell it to run, from the moment you turn it on.

Even on my TI-83 calculator, the program editor is a separate mode. But on an Apple II, it’s the default environment.

Defaults matter; they express a product’s purpose.

• A Macintosh shows you the Finder. I guess I’ll arrange some files and windows.
• An iPhone shows you the Home Screen. I guess I’ll browse some music and websites.
• A Game Boy? Put in a game, silly.
• And an Apple II? This thing is for programming.

That’s what inspired a generation about what computers should be.

Hence this complaint:

Every step between turning on the computer and running your program loses 30% of the students.

—paraphrasing David Brin

Imagine having to log in to your guitar and create a music document before you could start strumming.

That’s redundancy; the opposite is monotony—having exactly one way to do some action.

Monotony sounds dull, but is actually a profoundly clarifying guideline. I first heard about it from Jef Raskin—yes, the Macintosh guy.

Let’s analyze some examples.

1. Journal entries

iOS’s Journal app has a delightfully short feature set:

1. Create and delete entries
2. Edit and add attachments to entries
3. Bookmark and filter entries

Unfortunately, it lets you bookmark, edit, or delete an entry in 4 ways:

Redundancy distracts.

Imagine if you had exactly one way to edit an entry. You’d focus more on actually journaling; and spend less time learning to use the app, and deciding which way to use it.

Meanwhile, there’s only one way to create an entry, or attach an image.

Would it be better if you could also create an entry from within the entry editor? Or also attach an image by touching and holding an entry?

Quoting Jef Raskin:

When you have to choose among methods, your locus of attention is drawn from the task and temporarily becomes the decision itself.

When there’s only one way to do something, you never decide which way to do it; you just do it.

2. Playlists

There are 2 ways to add a song to a playlist: from the song, or from the playlist.

From the song makes sense. You’re already looking at it: “this song would be good for the party!” Plunk.

From the playlist is horrible. You have to browse your entire library inside a sheet, using views with smaller artwork and no sort settings.

And what if you want a song not in your library? You can’t search the catalog. Perhaps they could add a Search tab here…

No, now we’re cloning the entire app inside one of its sheets. Bananas.

The main UI is the best way to choose songs, because that’s what it’s for. It should be the only way to add to playlists.

Those inferior versions of the albums, artists, and songs lists inside the sheet? It took effort to make those, all for an experience that was incomplete and unnecessary in the first place.

Monotony simplifies development too.

3. App folders

iOS offers one way to create an app folder: drag an icon onto another.

You can’t create an empty folder first, then put icons into it. You don’t even have the option, so there’s no decision to make. If you never noticed that, that’s a good thing.

I designed album folders in Songpocket the same way: the only way to create a new folder is while moving albums. It’s simpler for users to use, and for me to maintain.

Clarification

Monotony doesn’t mean only one way to produce some result. That would eliminate the Backspace key, because it lets you put “hello” on your screen in infinite ways.

So there’s room for interpretation in what you call an action.

You could call it redundant for a keyboard shortcut and a clickable button to activate the same command, but that’s generally fine. Accessible controls too.

Rather, it’s redundant for a toolbar button and menu command to do the same thing. When you explore each area, you have to remember which actions are unique, versus which actions are also available elsewhere. That’s a load of cognitive load.

Monotony improves focus

A monotonous design is easier to learn, use, and maintain.

Plus, it’s easier to support, because there’s only one help article to write, and when users contact you, you know they’re all using it the same way.

Quoting Jef Raskin again:

[A]n interface that is both modeless and, insofar as possible, monotonous […] would be extraordinarily pleasant to use. A user would be able to develop an unusually high degree of trust in [their] habits. The interface would, from these two properties alone, tend to fade from the user’s consciousness, allowing [them] to give [their] full attention to the task at hand.

Design means deciding how things should work: to consider all the possibilities, and choose the best one.

It is irresponsible to waste people’s attention with pointless options by being indecisive. Eliminate what doesn’t need people’s attention, and you free people to focus on what actually matters.

See also:

• The Humane Interface by Jef Raskin
• Zusch Login

How do you design a computer to be easy to use in this situation?

The Apollo Guidance Computer’s idea: numeric verbs and nouns.

Verb, 16: display. Noun, 65: time. Enter.

Bam. Simple yet powerful.

(Also, y’know, because I enter verbs and nouns here.)

Learn more:

• Ars Technica
• Apollo Flight Journal
• 13 Minutes to the Moon