Lessons from making mtg.wtf mobile-friendly

mtg.wtf is currently the best search engine for Magic: the Gathering cards. It's reasonably successful and popular, so let's go through its history quickly.

It started as a wishlist of improvements I'd like to see for magiccards.info

Then once magiccards.info stopped being updated, I decided to write a replacement. I started by wring a bunch of tests for how I'd like it to work, mostly using data from mtgjson

After I had tests, I wrote a search engine as Ruby library with command line interface. I thought about making it a standalone gem at this point, but I'm not sure how useful people would find it, considering json data is out there already.

After that I added rudimentary Rails frontend with minimal styling and put it online.

At this point it was text only, so I had to find card scans. WotC only publishes somewhat low quality scans, which are usable enough, but I wished to get something better. For about 2/3 of cards I found those higher quality scans, but it was a fairly slow and manual process. That still leaves some rare promos there's just no source of any kind - it wasn't a huge deal, as few people search specifically for them, the search engine just needed to display card with good picture instead of most recent version (which might be weirdo promo).

Then I added some CSS on-hover animations. Most cards have regular layout, but there are some cards which are double-faced, have horizontal layout ("split" cards), or have content on top and tobbom ("flip" cards). Later they even added pairs of cards which merge ("meld") into one big card with halves printed on their back face. All those cases for decent usability required either completely different display layout, or some animation support, and CSS animations turned out to be pretty easy to add.

Bootstrap

At this point I was getting feedback that it doesn't work too well on mobiles.

Well it's not too hard, we just need to add header telling mobile browsers to not be stupid:

  <meta content='width=device-width, initial-scale=1' name='viewport'>

Then I installed bootstrap, and replaced some existing layout code with bootstrap 12-column grid. It was surprisingly easy retrofit - other that bootstrap's use of .card colliding with my use of .card I don't remember any surprises. Markup looked a bit worse due to extra <div class="row">, <div class="col-md-8"> etc., but it's not too bad thanks to HAML.

Making it responsive

I have a bunch of mobile devices around, and testing on one or two devices is not too much trouble, but I wanted to make sure site will work well on everything, so I used Device Mode in Chrome Developer Tools to make sure everything works in wide range of sizes, portrait and landscape, added a bunch of responsive bootstrap tags, and I pushed the changes to the server.

• For big screens site used desktop layout - 4 column for card picture, 6 column for card information, 2 columns for extra intformation
• For medium screens layout was 6 column for pic, 6 column for information, and extras were hidden
• For small screens layout was full row for card pic, and full row for card information underneath, with extras hidden

That was the most usable configuration in Chrome Device Mode.

Animation problems

There were two immediate problems - first Mobile Safari users reported that CSS animations are broken - it turned out that it required some prefixed properties for backface-visibility which nobody told Rails CSS autoprefixer about.

Second problem was that on very small screen sizes (where card was already full screen width) there was simply no space to do some of the animations - I ended up doing messy screen size queries in my CSS code matching Bootstrap size thresholds to turn them off.

And it was all wrong because "pixel" is a lie

I was quite happy with it, so I expected my users to be as well, but feedback I got was overwhelmingly negative. Users found the site unusable on mobiles, even though I crammed as much information as could reasonably fit in Chrome Device Mode.

The thing that got the most backlash was placing card text under card pic. But if I put tiny card picture next to text nobody could see anything, right? Oh wait, those mobile "pixel" numbers are total bullshit. That 100 "pixel" width is actually a lot more device pixels, so even though card looked like completely unreadable thumbnail in Chrome Device Mode, it looked just fine when I tried to use it on an actual phone.

And even if card picture was too small, so what? It's just as easy to pinch to zoom as it is to scroll down a bit - something that doesn't apply to desktops (where Cmd+ / Cmd- can zoom, but they don't focus on specific area, so they're much less useful).

This also means that 6 pic / 6 info layout on bigger devices was excessive - so I switched all non-desktop devices to 5 pic / 7 info as that's what looked best on actual mobiles and tablets I tried it on, even it looks horrible in Chrome Device Mode.

So now the site looked good on desktop (with big browser window), and on mobile devices with 2x or higher pixel density (of any size).

That doesn't cover using mobile devices with 1x pixel density (which fortunately basically nobody uses any more), or desktop browser with small window size (which happens, but worst case users can resize the window).

That leads to two big lessons:

• Chrome Device Mode is horribly unrepresentative as it uses 1x not 2x pixel density
• Bootstrap device width targeting is fairly unrepresentative as it ignores pixel density

Getting rid of whole-width card pic layout let me get rid of most CSS animation workarounds. There are still some for gallery view, like Nils Hamm's cards from Dragon's Maze where animations need to be aware of which column the card's in.

Soft Keyboard

Now it looked good, but I ran into one more problem. On desktop we want to start search box focused with HTML5 autofocus attribute, so user can start typing the query without clicking anything.

Now most good browsers understand opensearch annotations, so if you ever visited mtg.wtf, they'll remember it, so you can just type mtg<tab>your query from URL bar, and they'll get you straight to search results - but not everybody uses it this way.

But we don't want to autofocus on mobiles - as then huge soft keyboard appears covering half of results and making it all miserable. At least on some mobile browsers, others sensibly require click to show soft keyboard even with autofocus attribute.

Unfortunately I never found any way to query if device has real keyboard or not. So backup logic of autofocusing on home page (which has no results, so soft keyboard covering empty space is no big deal), but not on other pages (which have some result) ended up being a workable compromise.

It would be nice if someone figured out which browser/device combinations have this issue, and created some device specific autofocus library, as it can't be the only site affected by the problem.

Overall, it wasn't too bad

Even with all the surprises, it all went better than expected.

But imagine the world could have been different - once upon a time mobiles tried to create their own separate web with completely separate protocols and formats. How insane would it be if they succeeded?