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.
Making it responsiveI 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
And it was all wrong because "pixel" is a lie
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
Soft KeyboardNow 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?