This post is a little bit outside my normal wheelhouse, pertaining to a physical card game. I know it seems to have little to do with web accessibility, but I believe it's important to look to other media to see the problems they face in design and the solutions their creators employ. This article explores one example of a common design problem that has been on my mind for a while.

Popular trading card game Magic: The Gathering is unfortunately not usually accessible to those with limited or no vision. Despite this, there has been a concerted effort in the design of the game's cards to be accessible to the color-blind, and even at least one Magic artist is himself colorblind.

First, the basics. Cards in Magic typically fall into one of five colors. These colors together are called the Color Pie. The colors typically have different philosophies and ultimately win the game in different ways: green focuses on large monsters, white focuses on healing or preventing damage, etc. As a result, it's very important to know what color your cards and your opponents' cards are. So, how do we do that if we don't perceive color?

Magic's designers had a solution: the colors all have associated symbols.

These symbols have changed only very slightly over the course of Magic's almost 30-year history. This is one of many smart design choices that have pointed towards consistency in experience.

Let's look at an example. This is Savannah Lions, first printed in 1993 and most recently reprinted (as of this writing) in 2024.

A number of things have changed in the thirty-some-year life of the Savannah Lions, but a few notable things have not. The name of the card is the same, the symbol in the top right indicating its "mana cost", and it's stats in the bottom right corner. All of the design elements which are key to gameplay have remained unchanged. This is important because the cards are, in a sense, an interface, and consistency is crucial.

In the long years since Magic's introduction, the game has increased in complexity and there are now estimated to be around 30,000 unique cards. Some cards have front and back sides, some have two "cards" on one side, and some combine multiple physical cards to form one large "card." Through all these changes and expansions, the fundamental basics of the design of a Magic card have typically not changed. When they do change, it's usually for the better, making cards more legible and more beautiful.

There's one exception that I'd like to talk about. What happens if the card has no indicator in the top right corner? What if it has no mana cost, but still has a color? How does someone with limited color vision tell what color the card is? Let's look at another, more recent example: Pact of Negation.

In the first of these images, we see a solution. The text of the card simply says "Pact of Negation is blue." This is a simple, if not especially elegant solution. Is this card affected by Red Elemental Blast? Red Elemental Blast reads, in part, "counter target blue spell." As Pact of Negation says, Pact of Negation is blue. Problem solved.

Evidently someone on the design team agreed with me that this solution wasn't especially elegant, and the text "Pact of Negation is blue" has been removed from subsequent printings. In the online rendition of Magic: The Gathering, Arena, there is no indication at all of what color Pact is. On the physical cards, only a tiny vestige remains: a blue dot next to the card's type ("Instant"). But this is no help at all to the colorblind.

Rendering the card in grayscale, we can see that there is no indication at all that this card is blue.

Let's look at another example. MTG Salvation user Kar3w posited way back in 2011 that these color indicators were a poor design choice. They pointed to the backs of double-sided cards, which have no mana cost. The problem is evident when you look at their example: Civilized Scholar, which transforms into Homicidal Brute.

We can tell easily that Civilized Scholar is a blue card by the blue mana symbol in its mana cost (top right). But when its transformation is triggered and it becomes Homicidal Brute, there is no indication that it has become a red card other than its physical color. It's estimated that 8% of men and 0.4% of women globally have some red-green color deficiency.

8% of men and 0.4% of women may not seem like a lot, but that means that about 27 million Americans wouldn't know that they can kill their opponent's Homicidal Brute with a Blue Elemental Blast (which reads, in part, "Destroy target red permanent").

So what's the solution? I don't have a perfect, elegant design solution for this problem. Many accessibility problems don't have perfect, elegant solutions. But I do know one solution, though it may not be especially elegant.

I mentioned earlier that understanding the specific needs of the MetalBard audience is critical. Metal shows are often in small, underground venues, and getting cell service in those spaces can be difficult. But also, metalheads often have older phones rather than the latest devices, so a high quality connection may not even be a possibility. So how do we design for that? Well, there are a few ways:

This is Part 3 of a series on the unique design considerations raised by concert apps. Start from Part 1 here.

Throttle Your Bandwidth

Modern development tools have ways of simulating slower mobile networks. For instance, in Google Chrome, these are tucked away under the Network tab of the DevTools (Ctrl + Shift + C). You can also easily disable caching from here to better simulate using the app for the first time. Set your network to 3G, throw on some acid wash jeans, and you're back in the early 2000s again.

Use Online Tools Like PageSpeed Insights

Google is all about speed, so they've created a ton of useful free tools to ensure your app is faster than a Tuesday night punk show. Check out PageSpeed Insights in particular, an application that easily identifies ways to make your apps faster for your users. Use it in conjunction with Google Analytics and you can even see what kind of experiences your users are getting on the fly.

This is only scratching the surface of ways to make an app faster, and the opportunities are nearly endless, but this is important stuff. It's easy to forget in our world of high speed internet and local development that our app's users often won't be so lucky.

In 2021 an app was announced that was basically exactly what MetalBard is, but for the entire DC music scene: DC Music Live. This was a bittersweet occasion: finally I would have a way to keep track of local shows on my phone, but I was disappointed in myself for not having completed MetalBard and letting another developer eat my lunch, so to speak.

This is Part 2 of a series on the unique design considerations raised by concert apps. Read Part 1 here.

I instantly downloaded the app and have checked in on its development progress every once in a while ever since. It's important to me to understand MetalBard's place in the ecosystem of music apps, especially when an application exists that's so similar. However, I always bounced off DC Music Live, and there are a few reasons for that that I think are worth dissecting here.

From a visual design perspective, I think DC Music Live is fantastic. Dark colors, high contrasts, clear text. When the app first launched, it looked a lot like Google Maps: bland, white, and dreary, but it's come a long way.

But from a user experience perspective, hard choices are made as a result of the app's larger scope. When someone first opens the app, they're asked to create a profile, selecting what genres of music they're interested in. Because creating a lean, quick user experience was critical to the way I saw MetalBard, we forego all of this. We don't need to know who you are or what kind of music you came here for. You're a metalhead and you're looking for metal.

This is another choice that could explode in the face of MetalBard, but we're also not interested in linking with social media or collecting email addresses. Metalheads use social media as much as anyone else, it's true, and more robust sharing options are definitely on the roadmap, but this isn't about data collection or selling ads. It's a small, vibrant community, and the app's scope needs to reflect that.

Read Part 3 here.

Live music is unlike any other experience. If I told you that for around fifty bucks you could stand for hours in the dark surrounded by strangers while bright lights are shone directly into your eyeballs and loud sounds pummel your ears and brain, you would look at me like I was crazy. In the DC area and around the world, people are signing up for that unique ordeal each and every night.

As designers, we owe it to people to be cognizant of how their circumstances and stressors can affect how they experience our apps, and using a phone application before, during, or after a concert poses a very specific set of challenges. It also offers some exciting opportunities to perfectly tailor our experiences to the needs of our users.

A Brief History of Mobile-First Design

In the beginning, the web could be viewed only in the cool light of the cathode ray tube (those old beige monitors people had in the 90's), and the webmasters, as they called themselves, saw that it was good.

Shortly after the turn of the millennium, cell phones became ubiquitous, a Nokia brick in the pocket of every child. And those people wanted to use the internet on them. Designers set up subdomains (something like m.google.com) that mobile users would be redirected to when they accessed websites: a whole second site specifically for the low bandwidth and tiny screens of early cell phones.

Enter the smart phone, around 2010, and everything changed. Suddenly the screens in people's pockets were higher resolution than those old beige monitors ever were, and people who didn't have internet in their house now had it in the palm of their hand.

A number of philosophies cropped up to deal with the novel use cases that this paradigm shift created, some competing with one another, some building on existing ideas. "Well," thought some, "we spent all this time making beautiful web sites for big screens. Let's just make sure it's functional on smaller screens and it'll be fine." "No!" shouted others, "Mobile is the wave of the future; web sites must be built for phones first, lest we be left in the detritus of time." It's possible I'm remembering some of these articles being more dramatic than they were.

So, where did we land? As with all things to do with UX design, it depends. As Patrick Clancey writes for A List Apart, "things can easily get convoluted and less efficient if we prioritize one particular device—any device—over others."

When I began work on MetalBard, it was with these decades of context in mind. I thought it was important that the application work on whatever device the user was coming to it on. One of the things I find interesting about MetalBard, however, is the surgical precision of trying to target very specific use cases, and cater to them perfectly. It could have been an app for finding metal shows in your area, wherever that may be. It could have been an app for finding all concerts in the DMV (District, Maryland, and Virginia) area. But it wasn't; it was a specific app for a specific type of user, in a specific circumstance, and that meant focusing on mobile design. As a result, MetalBard is not only one of the only mobile-first applications I've ever designed, it's also almost mobile-only. It's a gamble, and time will tell if it ever even made sense in the first place.

Read Part 2 here.

All over these United States one hears about local cryptids (an animal that has been claimed, but never proven, to exist), some more famous than others. West Virginia has the supernatural Mothman. Even our neighbors in Delaware have the Selbyville Swamp Monster to call their own. Here in DC we have, well, Demon Cat.

With a name like an ’80s hair band and a terrible pun (DC. Demon Cat. Get it?) it's hard to feel like an overgrown black cat really represents a District of 600,000 people. And that's what made it the perfect mascot for a uniquely terrible bar trivia team.

When my roommate and I moved into the city, we decided to visit our local haunt at Atlas Brew Works for their bar trivia. They served great beers that they brewed on site, the place was rarely crowded, and they occasionally had metal shows going on in the back room. Also notable: they offered a dubious last place “prize,” which was usually whatever they could find around the bar at the last minute.

After a few weeks using the Demon Cat name, I decided I'd try to create a simple illustration of the cryptid. I started from a football shape, demon horns, and a wall-eyed stare. A friend took one look at it and asked if I'd ever seen a cat before.

I refined the design and tried a few variations in color scheme. I have orange cats, so I leaned that way with my design. But he's a demon, I thought. Surely he should be a sinister green. Finally, I decided to stick with existing depictions of our local demon cat, and made him an off-black color.

Choosing the accompanying typography was a challenge for me. I went through a number of options. I tried scratchy fonts to reflect a cat's scratch, hand-drawn fonts to evoke the slapdash nature of the team, and demonic fonts to call to mind another local favorite: the Exorcist.

I liked the idea of tying the look into classic movie designs, but Demon Cat was just too cheesy to be associated with such an iconic film. He was more like a 1950s creature feature. I looked at old movie posters, including the one for the iconic schlocky giant ant movie "Them!", and knew I was heading the right direction.

I ended up using a font called Chantal Bold, and nudging the characters around slightly to give it a more compact appearance.

As the weeks wore on and the team grew, I thought of doing t-shirts for all of us. My first thought was a riff on this overused, Etsy-y list of names and ampersands. Looking at it I realized sometimes when you try to riff on something, you can end up just replicating it with all its flaws.

I decided ultimately to just use a simplified version of the DC flag. It's such an effective design: it isn't widely known but people who live around here will recognize it anywhere. All I had to do was recreate it in a way that matched the text I had chosen.

I ended up using this Demon Cat illustration all over the place. I used it as my profile picture in a lot of places and I created stickers in a number of different styles. As the number of applications for the little guy grew, I decided to create a number of variations. A personal favorite is the "tears of blood" one, which I used in JQBX (rest in peace) whenever I was playing music.

This little case study is a great microcosm of how designers can always use their creativity, even when working within an established, rigid design system. In the end I designed a fairly simple logo, but a lot of thought went into it, and I'd love to share it with you.

At Total Wine & More, I worked on a new application, code-named Photon. The app was intended for a power-user audience, but we still wanted it to reflect Total Wine & More's commitment to sleek, modern design. I was assigned to create a logo to represent our app.

My first instinct, because the app was internal and Photon was just a temporary code-name, was to use the strong typography and colors that are at the core of Total Wine & More's design system to create something functional, if not especially exciting.

As we began to evangelize our application internally, we felt that it needed a logo that more accurately reflected its name. I sat down and wondered, what is a photon? Scientifically speaking, what is it? I turned to trusty old Wikipedia, and I'll be honest: the vast majority of the article on photons went clear over my head. Simply put, to my understanding, a photon is a particle of light, so I took that idea and ran with it.

This version of the logo was bolder, stronger, and had that mid-century vibe I really enjoy. I used Futura Bold to create that chunky look. The only issue that really stuck in my craw was that it reminded me more of an energy company, especially the old Texaco logo. It communicated a seriousness that I liked, but it still wasn't right. I returned to the Wikipedia page and found this diagram:

That's the basis of a strong design already, I thought to myself. Pattern is one of the principles of design, and what stronger pattern could there be than light itself, depicted as a wave? I sat down with a paper and pencil to play with this new idea and before long ended up with a design like this:

I found myself now leaning almost in the opposite direction of my earlier design, this time into the world of science fiction with Eurostile as my font and these abstract lines that seemed to have no relation at all to the text. "This is even worse," I thought. "There has to be a common ground."

I brought Futura back in (it's one of my favorite fonts), and used colors that were derivative of the Total Wine green but not exactly the same. I made the lines of the logo bolder and more deliberate. The waveform of the photon was now enclosed in a tidy circle so the lines didn't seem to just be floating.

After a little more tweaking, this is essentially the logo we landed on. We ended up not using the Futura text in the application, and using Total Wine colors in the logo in most places, but I felt this was the strongest version of the logo. The lines in the circle have been made even bolder and a deep, almost black, purple is used throughout. Finally, orange and blue are a classic complimentary color pair, and here their slightly muted forms remind me of retro-futuristic depictions of mountains on the surface of Mars.

I'm sure I'm getting away from myself a bit here, in my description of this simple logo. Ultimately we ended up using Total Wine branding fonts and colors to fit the logo into the application, but I feel that this creative process is what led us to a successful logo, and without these iterations it would have never worked. So, this is just a short case study to remind myself and others that it's important to always stretch your creative legs, even when working within an existing design system.