At the Ampersand conference, Nick Sherman talked about responsive typography — where typographic displays change to respond to the viewing conditions — and how we can use face detection in the browser to serve up the right size type for a reader. He showed us a nifty responsive-typography-via-face-detection demo, and he demoed his size calculator, which allows us to serve up an appropriate type size based on viewing distance.
These days, being a font geek is the hip, happening thing to do. Everyone seems to have a favorite font typeface, and everyone seems to hate Comic Sans. The ability to install hundreds — if not thousands — of fonts on your computer makes playing with typefaces accessible to anyone. Then there are type geeks, who are also often typographers by trade (because let’s face it — if you’re this obsessive about type, you might as well make it your main occupation in life). Typographers rarely have one favorite typeface, although they can usually expound at length on the superiority of Helvetica over Arial. Instead, different typefaces are designed to do some kinds of work better than others; they also evoke different feelings and connotations. Type is a tool for design, and it’s a really, really powerful one at that.
Sadly, up until recently, the world of type design and the web were frustratingly separate — there just wasn’t support for using most fonts on the web, let alone fine typography. Designers were limited to a handful of web-safe fonts which, while mostly worthy workhorses (except for Arial. Let’s never use Arial again, m’kay?), dramatically limited the degree of typographic expressiveness one could achieve when designing for the web. These days, the advent of online font services such as Typekit and Google Fonts has completely changed the landscape, and web designers have (re)discovered type. For those of us who were trained as print designers, it’s like coming home, a bit.
That’s why I was incredibly excited to attend the Ampersand Conference last week. It was held at the Times Center, which is a very nice space in which to have a conference. Despite (or perhaps because of) it being a one-track, single-day event, the Ampersand schedule was packed with interesting-sounding talks. Usually, despite interesting-sounding topics, you expect most of the day to be full or decent, but unremarkable talks, and to have one or two highlights that really blow everyone away. Well, I’m happy to report that Ampersand exceeded those expectations. Each and every talk was interesting and engaging in its own way (from super cool proofs-of-concept work to wacky and offbeat personal/professional narratives) and there was a distinct earnestness about all the talks, which is reminiscent of some of the things I’ve heard about the xoxo conference. Some highlights:
Type as Brand, Brand as Type by Michael Johnson
Michael Johnson of Johnson Banks opened the conference with a rumination on the growing role of type as a key component of identity design work on the web. Johnson’s presentation did great double duty: it chronicles the progression of the state of the art in web typography from its meager beginnings to the recent flourishing of typographic expression online, while highlighting the absolutely critical role that typography has in developing the visual aspects of a brand identity. He’s been kind enough to post a transcript of his talk here — it’s well worth a read.
Putting the Fonts into Webfonts by Jonathan Hoefler
We’ve been using web fonts at Safari, most notably on Safari Flow, so we’re pretty familiar with the offerings from Google and Adobe. But Jonathan Hoefler’s presentation of Hoefler & Frere-Jones’ new web fonts service, Cloud.typography left a lot of us kind of in awe. His talk was impressive both because of the service’s rich typographical features, and because Hoefler managed to make what could have otherwise been a pretty dry product pitch into a deeply engaging survey of the state of the art in web typography. He’s doing it again this week, at the NY chapter of AIGA.
The Future of Responsive Typography by Nick Sherman
Nick Sherman has been writing really insightful things about typography on the screen and how it relates to readers’ eyes in the physical world. His talk on responsive type fed off of this theme, from the trials and tribulations of font hinting, to the vagaries of compensating for size and resolution-related issues when designing and displaying typefaces on screens.
Jen Lukas: On Icon Fonts & Working with Designers
Jenn Lukas walked a roomful of designers and typographers through what collaborating with developers looks like from the dev’s point of view, highlighting some crucial best practices along the way, with a major detour through a survey of her experience when researching icon fonts. Her liberal and wry use of animated gifs and cat macros (not to mention a radical sandwich metaphor throughout her slide deck) ensured that no one succumbed to the dreaded mid-afternoon slump.
In all, a great way to spend a Saturday (If you’re a type geek, that is. If not, YMM definitely V).
With the release of Windows 8, touch has finally landed on the desktop. There have been some great posts about the design implications of this change, but I haven’t seen much about technical implications, so I decided to write this. Chances are you’ve thought about touch interaction if you were building a separate mobile site, but what does it mean for a desktop site or a responsive site?
Why Optimize for Touch?
Why is this something you’d want to do? It boils down to making things better for those who visit your site regardless of the device they’re using. This is why many people and companies have chosen Responsive Web Design. But what does Windows 8 have to do with any of this? It’s the first desktop operating system to include touch (and pen input, but more about that later) as an OS-wide, first-class input mechanism. So suddenly, if you have touch hardware, your desktop browser is going to be firing real touch events instead of using a third-party software abstraction to fire mouse events in the OS.
I’m going to focus on this last one as I think it’s the most common case. The reason single-touch needs “fixing” is that click events incur a penalty in the form of a 300 millisecond delay on many touch-enabled devices. This is to allow the OS to determine if you meant to pan or zoom instead of just clicking. You can speed up this interaction by checking those things yourself.
Optimizing (allthethings) for Touch
There are a few ways to do this. You can feature-detect touch events and then bind to “touchend” instead of click. (Modernizr is great for this but may be overkill for this one use case.) If you decide to go this route you will have to manage everything yourself: handle touch, determine if the user is scrolling/panning/zooming (if they are: don’t fire the handlers, if they’re not: fire it), and then after you fire it there will still be a click event fired.
What—you were expecting this to be straightforward? We are dealing with web browsers after all! What can we do to make this easier? Use a library, of course! But before doing that, I recommend reading through this Google post (this was the first place I read about the technique) so that you understand everything involved with overriding the default browser behavior. The library I’d recommend using is FTLabs’s FastClick. Be sure to read through the source too, it’s well documented. The nice thing about FastClick is that you only have to bind it once for the whole document and it only inserts itself if your device supports touch, as it has the feature-detection built in.
The Touch Future (or: When Touch is Not Enough)
Touch and click events are closely related as there was some effort to have backwards compatibility. But leave it to IE to break up the party. Turns out IE10 and “Metro” apps don’t have touch events (read more about the problem in this Modernizr issue on Github). Instead, Microsoft has abstracted and unified input mechanisms with what they’re calling pointer events. Instead of binding to touch or click, you bind to pointer event and the OS knows when to fire it based on the input method you’re currently using (touch, mouse, pen, laser, etc.). Boris Smus has written a polyfill for pointer events and has a great post explaining it, though I think it might not be ready for primetime. Recently, the W3C has formed a committee to begin the standardization process for pointer events, so it’s definitely something to keep an eye on.
I think pointer events will be the way forward because they are a better abstraction, and you don’t have to do a bunch of hokey pokey to get things to work properly, you simply let the browser do the heavy lifting for you. Even if that’s true though, touch events aren’t going anywhere anytime soon. They’re something you’ll need to feature-detect (there’s talk of defining
Modernizr.mspointer in the above Modernizr issue) and then do what web developers always do: treat IE differently.