Decky on a MacBook

Magic: The Gathering is a collectible card game that is played by thousands of people all over the world. One of the most fun and important aspects of the game is building and sharing your own decks with the world. As a result, a staggering array of online deckbuilding tools for Magic have sprung up in recent years. As an avid player and collector of Magic cards, I found each of these applications to have their own limitations and decided to design and build my own take on the idea. After a year and change of design, development, blood, sweat, and coffee, Decky has come a long way.

With that still on the stack…

Because Decky was (and still is) a personal project I wanted to try to expand my knowledge, especially in the realm of web development. I knew I wanted to further develop my knowledge of languages like Python and Javascript and technologies like SQLite. I opted to use Python Flask to build Decky because this was my first time developing for the web with Python. On top of this I used a Python implementation of Libsass to make development easier on me.

I used the built-in SQLite  implementation that came with it for my database, which would hold all of the thousands of Magic cards in existence along with all of Decky’s users and their collections and decks. Still, this is a fairly small amount of data in the grand scheme of things so I was fine using something lightweight.

I just needed the card data to fill my database with. For this I turned to MTG JSON, a great service that posts public JSON data of every Magic card in every set as it is released. I wrote a series of Python scripts that imported the JSON, formatted it properly for Decky, and inserted it into my new database.

I borrowed various Magic iconography from Keyrune and Mana-cost and simply pointed to the official Magic card search engine (temporarily) for card images.

Path to Exile

Getting my application set up, formatting cards correctly, and then displaying them all in the browser was frankly a significant undertaking for me as someone who doesn’t often dip his toes into the worlds outside front-end development and design. This was, however, only the beginning.

My next few posts will elaborate on the Decky design process from deciding how the deck builder should work to ensuring that the application was accessible for the colorblind and everything in between. Before I sign off, I want to thank Dani Chesebrough, without whom I wouldn’t have even gotten off the ground with this thing over a year ago. Also I’d like to thank the many friends and family members who have offered their valuable feedback on Decky.

Adaptive Automaton

As web applications come closer to matching the capabilities of native applications, one of the most exciting avenues of design that have opened up to us is that of animation. Animation, when executed well, offers a fourth dimension through which we can communicate with the user: time.

New CSS properties allow us to use animation to draw the user’s attention through an application in a very natural way. By using principles of animation that have been honed over a hundred years, we can convey meaning and personality in ways that web designers have never been able to before. These new properties are easy to use, robust, and performant, blending seamlessly with existing CSS techniques.

One quick note: Many of the example animations in this article have been slowed down to show detail. All of the animations throughout Decky are 400 milliseconds long or shorter. Also, I learned a lot of the techniques I used on Decky by reading Designing Interface Animation and A Pocket Guide to CSS Animations, both by Val Head, and used Mozilla’s MDN as a reference.

Watchful Automaton

In addition to showing Magic decks or cards “loading” onto the screen, we can convey important information to the viewer. The deck thumbnails show the deck’s composition by default, but hovering over them displays a more detailed breakdown. Clicking on the deck shows a faux-loading animation to convey to the user that we've received their request and we're working on showing them the deck.

We also leverage animation on the deck listing page selector to tie Decky’s diamond motif into the overall branding. Additional animations are used to respond to the user hovering over interactive elements like buttons or clicking into an input field. These animations are each opportunities to create consistency in the look and feel of the application and to give the sense of attention to detail that is usually reserved for native apps.

Augmenting Automaton

On the subject of animation revealing additional information, a few Magic cards have two sides. Where in the past we would have to show those sides next to one another, now we can show them as they look in real life using an animated 3D effect.

A few fun effects are also used on the card listing to give the feeling of playing Magic as a physical card games. Cards are “dealt” onto the screen when the user hovers over their names using a very quick and smooth fading, rotating, and sliding animation.

Foil cards, also called “premium” cards, are one of the most popular ways to bling out a Magic deck, so having a special treatment for them in Decky only made sense. Therefore, we give them their own 3D hovering effect and an animated foil effect that simulates the way light hits foil cards in real life.

The final, and perhaps most important feature of animation on the web is the ability to turn it off. Using a few simple CSS rules and a bit of JavaScript, we make it possible for the user to disable animation throughout the application. Animation can cause motion sickness for many people and some simply don’t like it. Furthermore it has a non-zero effect on performance so users on lower-end PCs may want to disable it. For this reason, we offer a simple checkbox in the Settings page with which the user can disable all of these effects.

The next article in this series will deal with just this predicament: web accessibility. If you want to read the previous article in this series, you can find that here.