When using web fonts from Google Fonts, it generally makes sense to take advantage of the files hosted on Google’s CDN. However, there are legitimate reasons to host fonts yourself sometimes. If you need to keep your tinfoil hat on at all times, because your site attracts bad guys, you may not want to take the risk of running code from a third party, even one as respected and august as The Google. That is indeed the case at Braintree, where we decided to host fonts on our own servers.
So we downloaded the TTF files from Google Fonts, and ran them through Font Squirrel’s web font generator to get a bulletproof font stack. Everything looked brilliant on the the Mac, but the font rendering was corrupted on both Chrome and Firefox on Windows.
Recently, Drew Crawford’s excellent article Why Mobile Web Apps are Slow got a lot of attention on the intertweets. It is a worthwhile read, and I recommend it.
As someone who has been a proponent of the open web and HTML5 apps, I have to admit to participating in some of the blind booster-ism the author identifies at the beginning of the article. While some of the technical discussion in the piece is beyond my expertise, I find it to be a pretty compelling argument against my default position.
But while I can’t dispute his arguments for the advantages of native apps, I can’t agree completely with Crawford’s conclusion. Basically he makes a super-compelling argument for why native apps are faster than mobile web apps (and will likely remain faster) and then concludes that people shouldn’t create mobile web apps. I think what he ignores is that web apps can achieve perceived performance on a par with native apps in many cases. There are apps out there that prove it is possible to create beautiful, responsive, web apps on current hardware.
I’m going to explore more mobile UI antipatterns, starting with what I call “hinting instead of acting”. This is when a UI hints at the proper action a user should have taken, rather than just doing what the user expects.
I love the Google Maps app on iOS (huzzah for public transit directions!), but it employed this antipattern when it launched. When you touched a pin on the map, it caused the bottom of the screen to bounce, hinting that you should swipe upwards to get directions and other options. Why not just open the panel when a user touches the pin?
I’m currently reading Jonathon Haidt’s The Righteous Mind. It’s a book about morality and politics, but it is challenging some of my long-held conceptions about the design process, particularly critiques.
In the first segment of the book, Haidt makes a compelling argument that judgement and justification are two separate processes. Judgment is immediate and intuitive, and whether we choose to believe it, justification comes only after we’ve made our intuitive response to something. As he states it succinctly Intuitions come first, strategic reasoning second.
This has some pretty profound implications for design critique. No matter how much we try to rationally analyze whether a design solves a given problem, we are actually going to judge it first on an intuitive level. When we analyze it’s effectiveness, we will inevitably come up with reasons that justify our our initial intuitive reaction.
I kicked off this series of posts without really delving into what qualifies as a UI antipattern. I was talking about my UI antipatterns posts with a couple of developer friends at Braintree, and one commented that “it’s fun to point out when people are doing it wrong online”. I wouldn’t disagree, but just because some site is doing it wrong, doesn’t mean it’s an antipattern. Sometimes it’s just crappy design, or total lack of design.
To qualify as an antipattern, it has to be a repeated pattern that appears to be beneficial at first, but turns out to create more unintended problems. Additionally, a better answer to the problem has to exist and be documentable and repeatable.
1 of 3