Blog

I am a self-confessed font nazi. I love fonts. Andy, a good friend and housemate, recently asked for some font advice on Facebook, and used the word "masculine" to describe the kind of font he was looking for. This created... a hub-bub within some folks in the gay community, and I posted the following.

Univers, Frankfurt Airport, where I first fell in love.

First, Frutiger's font styling is some of the best out there, and my all time favourite sans is Univers. I own this font; I spent about $1000 on it over the years for its various typefaces. It's clean, easy to read, works on everything from signage down to text, and it's gorgeous, gorgeous, gorgeous....

Now I prefer that by far to its other options, like Helvetica, Arial, and its simulacra. They just feel stranger, less formal, somehow more awkward. Disney, however, is currenly moving to Avenir, another Frutiger font. Avenir Next, specifically, is slightly more informal, a little more streamlined and modernist.

Century Schoolbook is an old hand at serifs; it's considered highly legible, even though it's a serif. (I have a high bias against serifs, I just think they're frilly and superfluous, but they do something for lots of readers.) It lends itself a weird familiarity with the reader, mostly because they've seen it a million times before but can never put their finger on where.

It's widely available. It's a bit... Dare I say basic. I guess. But it's good, it's honest, and it's not Times Fucking New Roman.

Emulating an Android feel requires Roboto. It's a weird, weird frankenfont, with the look and feel - you might argue "the best", and you might well bloody not - of several other fonts: Helvetica, Myriad, Universe, FF DIN, and Ronnia. It's an interesting study into the strangeness that is Google.

Of course, many of these original issues have been fixed, but it's roots are still deeply embedded in the patchwork that birthed it.

Like many derived types, differences can be subtle. Thank you, ive, for not putting little hearts above the lower case i.

Then there's our more elegant and beautiful cousin. Emulating the feel of Apple devices requires San Francisco these days. They're both interesting yet utterly derivative of their Geneva and Helvetica Neue past, Apple's previous system fonts. When you see them, you see lazy. Unless they're trying to associate their product with Apple. Then you see brazen manipulation of the reader.

Consolas was one of the greatest gifts to the programming community. Microsoft's original is still an incredibly beautiful monospaced font - perfect for everything from terminals to the "full screen writing" or "distraction free writing" tools that I occasionally drop into.

And that's great, if you're on Windows. But to be frank, there's really no need to use it anymore. Inconsolata is an incredibly productive and useful replica, which has been altered over time and is now incredibly complete and beautiful. It still lacks some of Consolas' polish, but it's free, and everyone has no excuse not to switch over to using it right now.

For magazine style layouts, sometimes you want something that just kind of bleeds elegant fashion.

Personally, I'm a fan of Chronicle Display, and it's close cousin, Chronicle Text. The latter I almost never use for anything, because, you know, I hate serifs, but the former has a place in any designer's book.

Sometimes you need something less newsy, but still serif'd, stylish yet bold. Mercury was designed for Esquire magazine, and it's the heart of their signature look - you see it instantly when you know, but it's subtly there influencing the mind of the reader when you don't; you've seen it a million times on the cover, and somewhere deep in your soul, you make the connection. Because that's what good fonts do.

Somewhere between the Gothic fonts of old, like Baskerville and its ilk, and the postmodern "humanist" fonts of Frutiger that just scream airport signage at you - because, yes, that's probably where you've seen it before - is Whitney. This one's designed for New York's Whitney Museum.

However you feel about the subject of gender typing, the goal of a designer is to evoke a sensation within the masses, to communicate. You do so using stereotypes; idioms and identifiable thought patterns you know exist in the mind of the reader.

It seems appropriate, on the day that Trump becomes present, to remind readers that we are ingrained with idiotic, pointless, stupid, foolish, and downright wrong stereotypes from birth. All the fucking time.

Your job, as a designer, is to pull every lever, to push every button, to silently manipulate the image you're conveying through both liminal and subliminal to convey your message. This isn't just about what you write, or the images you use, but the shapes, the lines, the foundational design elements, the design language of the piece.

Design requires a deep understanding of the psyche of the individual you're designing for. So describing things as "masculine" or "feminine" is as real as the stereotype that exists in the mind of the reader - and believe you me, most people have that stereotype so well ingrained that you can use it.

Last, a reminder. Yes, I worked in display advertising for years and years. I've always been a fan of the business - Saatchi and Saatchi and Tomato are probably my favorite design houses.

Design, especially within advertising, is often about communicating using every possible element - constructing tiny universes where every single visible element is there to deliver and reinforce a message and identify with a target audience.

But that's design's goal - to build things that connect with humans, to build associations. It's the reason people care about their typefaces; they're literally part of the identity of the brand.

Apple is San Francisco. Android is Roboto. They're not just typefaces, they're full-blown wars over what makes something readable, about what humans like to see, about whether people are more likely to trust what you say when you use one font over another.

For one of the world's most fascinating experiments on this, read The Baskerville Experiment.

One of the biggest challenges in starting the process of bodybuilding is looking in the mirror every day. You see the person you are in the mirror, weighed by the baggage of the person you've been seeing for years - not the person you're intending to become.

Visualisation is key to motivation.

To help with that, I've been working on some... projections of the effects of my workouts, plotting ahead towards the 9/1 deadline I've set for myself for Burning Man 2015.

All of these mathematical endeavours begin with the presumption that Blizzard has a secret formula it uses to compute the amount of mana a card ought to cost. The value on the card will be different on the card for one of three reasons - the influence of mechanics, the effects of rounding (because a card costs 1 or 2 mana, not 1.5), and tweaking based on how it plays (variance introduced through human evaluation).

What we're ultimatley trying to build (for the base card value) is a model of the basic relationships between the values on the card (Attack, Health, and Mana), and these other effects, to 'reverse-engineer' the basic formula.

A standard lm model uses a family of functions for analyzing the variance of a dataset based on the assumption that there's a gaussian distribution in your data, and is primarily concerned with producing a binary predictor for those values.

As always, model fitting is part art, part science, and part throwing shit at the wall to see what works. Or, it is when I do it, at any rate.

So.

Given our belief that there's a direct, additive relationship between the base card value and the attack/defense values on the card, in theory, a glm on a poisson family should get you a better fit than the gaussian; it better represents the expected behaviour of a count variable. But is it true?

If we presume that our outcome value is "count"-like - additive in nature from the base values on the card - we can switch to the generalized linear model, and switch to a poisson distribution - with intriguing results.

Residuals are healthier. The residuals on the poisson distribution have better deviations; LM range was -1.9940 to 0.7611 (~2.75); our Poisson GLM is -1.0093 to 0.9077 (~1.9).

Residual QQ is better. The two graphs are day and night; you now see a nice, clean, quantized Q-Q for the residuals, showing the stair-stepping you'd expect to see when you know that whatever magic formula exists has the effects of rounding (because mana is an integer) applied.

Cook's Distance improved. We go from having some pretty strange outliers to being within 0.06 on all modelled values.

Scale-Location and Residuals Vs Leverage also see huge improvements over their normal counterpart.

In short, the poisson family appears to do a much better job of estimating the base value of the card than the normal family.

So, once you've scrubbed out zero-mana cards from scoring (which are a problem disconnected from value - it costs you in the deck build, but the card in isolation is always a pretty good deal), you clean up a few of the outliers and end up with a pretty solid qqplot.

QQ plot of predicted vs. actual, for *all* monsters and weapons (including those with mechanics)

Our goal in computing a base card value is to look purely at the numbers on the card, without considering the effects of the card mechanics, the rule violations that appear on the card. You do this for a few reasons:

Many mechanical effects have dependencies that are situational or may just not go off the way you hope they would when you built the deck.

Some cards have a "Silence" mechanic that wipe the card text, leaving you with just the base minion.

Most of your deck should be stable, dependable, and work towards a single goal; every card in your deck should help you reach that goal. Like building your first boat, or house, the temptation is to throw every cool thing you ever saw into a deck; what usually happens next is a catastrophic chain of losses.

What makes building a valuation like this interesting is the stuff at either end, the outliers on the outskirts of Value Town. I'm also pleasantly surprised to find a fairly normal distribution.

The outliers are more-or-less who you'd expect them to be.

At the bottom of the value pile is the Molten Giant, at a mana cost of 20 for an 8/8 creature that's really only worth 7-8 mana. It's all in the rule violation of the card text: Costs (1) less for each damage your hero has taken.

At the top of the heap is Mukla's Big Brother... a massive 10/10 creature that costs 6 mana but should cost 9. Again, the card text says it all: So strong! And only 6 Mana?!

Two more cards without card text do well, here:

Emerald Drake, costing 4 for a 7/6 creature, is well known to be great value and at a 92/100 rating for value is a great choice.

Blood Fury is a great value at 3 mana for a 3/8 card.

Its brethren above 90% are all either great value or have debilitating problems with their additional mechanics.

Ancient Watcher at 2 mana for a 4/5 looks good until you see that its big restriction is that it can't attack.

Injured Blademaster has a debilitating Battlecry that deals 4 damage to himself, a 4/7 creature that becomes a 4/3 when you play him.

Earth's Elemental is great value at 5 for a 7/8, but has an Overload: (3) that takes out three of your mana for a whole turn.

Millhouse Manastorm and Flame Imp are right up there with Ancient Watcher , but again, those debilitating mechanical violations come in to destroy their utility.

Even the Oasis Snapjaw and Chillwind Yeti appear in the correct order. (Yeti > Snapjaw, in case you didn't know.)

A cursory review of cards shows a pretty good match for general consensus on perceived value, so I'm going to roll with this for a V1.

Histogram of card$baseScore generated from linear regression

Note that it's hard to read too much from the distribution here; this is data that came out of the model, which iteself presumes a normal distribution of the source data. I'd have to switch to a glm or bayesian model to avoid making that assumption about the source data...

Which is something I'll look at in future passes. For now, I'm comfortable that the fit passes basic sniff tests.

When evaluating the base cost of a card, you might be tempted to say that most of the cost lives in the base attributes; so how would you evaluate that statement for truthiness?

Looking at a linear regression fit from all Minions with an expressed cost >0:

Linear regression model of all Minion cards with mana cost > 0

First, just look at the quantization in the residuals-vs-fitted. Pretty, isn't it? That suggests that the mechanics associated with these cards have clear, distinguishable values; this is Blizzard's own statisticians at work.

Next is the fit to a normal distribution; not bad, and as you'd expect, the outliers are the ones whose mechanics strongly influence mana cost (in either direction).

So a basic LM fit is surprisingly expressive - moreso by far than I was expecting, and it matches Trump's views on base cost of card being a very important factor. In fact, even without filtering out all of the cards that represent more unusual cases, it covers more than 76% of the variance in the dataset.

We can do better, though - if we're looking to fit a model for base cost, let's restrict the model to those mechanics that don't actually express any other mechanics.

In other words, let's go build a linear model that fits only the relationship between Mana, Attack, and Health for minions with no other mechanics.

Linear regression model of all Minion cards with mana cost > 0 and no other mechanics.

The resulting fit is better, too - We're at 93% of the variance of the data covered by the model.

Weathrman was built around a simple idea; search Flickr for a photograph taken near you, showing weather conditions and time of day roughly similar to your current location's weather conditions and time of day.

For the most part, it worked surprisingly well, given that I had limited API capabilities from Flickr, time-of-day is badly managed in images, most of Flickr's images weren't geocoded well, the API is horribly slow, and althoiugh we start searching hyperlocal and step upwards until we find something, each of those queries is run sequentially (due to both limited number of queries per day to Flickr and the cost of AppEngine to me).

It's been many years since I seriously looked at the codebase; the app still worked, but the quality of the images it pulled had steadily decreased, people aren't really using Flickr like they used to.

The net effect is that the app was old (written for Froyo, and last updated in 2011), had bad image choices due to limited API control... and for a while, was actually costing me money to run, as it had enough users to hit AppEngine's limit on free CPU time.

But no longer; it's fallen out of use, gets few requests. The app has bitrotted, people have moved on from being endlessly fascinated with live wallpapers, and there's no point leaving it up.

So down it comes, three years after my last update.

If it brought you joy, thank you; if it brought you tears, I apologize.

For those who've been wondering, life's been a little busy lately. Since moving to Mountain View, I've taken over the role of TL lead and Manager on the advertiser's side frontend of our Display business at Google, what we call the 'Content AdWords Frontend' in Google.

That's left me with precious little time; I first knew about 1.2 six months or more before it got released, and knew I'd have to migrate the dashboard to the API - but I ended up moving to Mountain View to take on this role before I had the chance to do so.

Now, keep in mind I still want everyone to move over to the official app - but it's also true that it's 4.0+ only, and I supported folks on Froyo.

Froyo is no more. If you're still on Froyo, go buy a phone, the OS is much nicer now and you'll be happy you did.

So the AdSense Dashboard is Gingerbread or later now. I've gone and changed a few things to make it easier to maintain and take some of the pain away - including to moving to Play Services for authentication. (Auth used to be particularly ugly under the hood.)

New navigation hierarchy

Local TimeZone everywhere.Everyone but Google thinks in their local timezone. So timezone reporting isn't optional; the app works in the timezone you gave AdSense.

A new widget that supports resizing and lockscreen use.

Goodbye, ViewPager. It was broken anyways, and we now have way too many reports to just blindly page through.

Hello, Navigation The new design paradigm on Android is an ActionBar button linked to a navigation drawer; now that we have navigation, we've added more reporting.

New reports Ad unit and site reporting have been added.

More data A full set of metrics on all of the reports we show.

Pull To Refresh Because I was wrong, Nick.

New icons While playing with the navigation drawer I found we needed some kind of visual indicator. I wanted scaleable icons that worked at all DPIs, but was way too lazy to actually go and make icons of all of those sizes. Enter FontAwesome, a font with a host of icons of just the right style and use case; that, plus a customised TextView that supports specifying a font, and a bit of aggressive caching of typography, and we've got some icons in the app now.

Use of typography I switched everything over to the fonts that are used in JellyBean and KitKat, Roboto. This is temporary, until I can find (or get around to buying for app embedding) something like Trafalgar and Requiem

API 1.4 introduced a change I've been begging for since the first version of the API; at least some of this happened because they're now seeing these problems for themselves as users of the API.

Rewrite of networking I rewrote the networking to make a single batch request at the same time I moved to Play Services for authentication. The refactor cut the amount of code I had in the app by more than half.

Use of Play Services SDK Play Services adds a lot of critical support for doing auth properly across a wider range of devices.

And, of course, moving off of the v1.2 API, which is what broke the app for all of October and November.

I did this in two stages - a 3.0 release in November, and a 3.1 release just a few days ago to make use of some of the earlier cleanup.

Along the way, I cleaned up a bunch of code, imported the 1.4 libraries, followed the daisy chain of required updates, moved to Android Studio, deleted all of that and switched to the maven repository, fixed all the maven conflicts, updated to later versions of support libraries, rewrote a bunch of stuff that the support library changes broke, etc. This has been, undoubtedly, a massive yak shaving exercise; but it's better off now.

We'll see where things go next; as always, send me your feature requests, complaints, and general chatter to the support address.