Humane Alphabets

Published June 3, 2024

Briefly: human-friendly alphabets to be used in URLs & the like where similar-looking characters can cause problems:

23456789abcdefghjkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ

Characters like 1, i, I, l, L, 0, o, and O can all look similar to each other depending on the typeface used to render them. By omitting these characters it reduces ambiguity and improves the user experience.

Consider the URLs https://example.com/aIlobi0OcL1D and https://example.com/a7xwbt8vcNrD. Sure—a contrived example—but one is admittedly much more friendly to use.

Here’s an implementation example using Sqids (formerly Hashids) which takes numbers as input and outputs a unique string which can be then decoded back to the original input. It’s particularly useful when taking auto-incrementing datastore IDs and rendering them on the frontend or URL in a way that doesn’t directly expose the original ID number. Maybe you don’t want to be open with how many entities you have.

new Sqids({ alphabet: "23456789abcdefghjkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ" }).encode([dbEntity.id])

I used this strategy on a project years ago which was an event scheduling web app: create an event with time slots, invitees mark when works for them, and the UI renders the union of times that work for everyone. The main interface of this product was leveraging human(e)-friendly URLs that could be manually typed if necessary, so avoiding ambiguous characters was paramount.

But what if I need a larger alphabet?” you might ask. Valid question. I’d recommend special characters in that case—the shortened alphabet I started this post with could easily have 8–10 special characters appended if you’re trying to mimic the length of a normal” alphabet or base64-compatible one.

Here’s some additional links for your reading pleasure:

Last modified June 3, 2024  #words   #programming   #ui   #ux 


← Newer post  •  Older post →