Web Fonts

Tack, Top Nerd in Residence (a term I use with much due respect and deference) here at Traction, let the team in on a really interesting update on the current state of fonts on the web.

I'd like to take the opportunity to go into the current state of fonts on the web. There actually has been a mechanism in CSS for using any font you want, even if it isn't on the user's computer, for a long time. It's called @font-face. The thing is that this is another case where everybody at the party is wearing tuxes and evening gowns, except internet explorer which is wearing a leisure suit and swim flippers. Because fonts are copyrighted, browser vendors have taken 2 approaches to linking to them. All the sane browsers assume we're all adults, will purchase the fonts like we do with stock images and allow you to throw any truetype font you want on your web server and link to it in your code. Microsoft wants to have central repositories of fonts and DRM in cahoots with font vendors. So they've got another completely different font format they are pushing and don't support truetype. Well... your font may not exist in both formats so we end up in the same verdana et al situation. If we want uniform typography across browsers we can only use fonts that are everywhere.

If we ever get a web project where we don't care about IE, go nuts with fonts.

Thanks to Tack for all this blog post fodder. You are the wind beneath these wings.

Dealing with multiple APIs

I had a conversation with Tack, one of the lead web developers at Traction, last week about APIs. I had this theory that interactive agencies were facing a new problem I was calling "API fatigue." From my vantage point, it seems like there is a new API every week for our engineering team to learn: First there was ActionScript, then Facebook API, now OpenSocial, iPhone, Android, Salesforce.com, YouTube API, Amazon, API, Twitter API... the list goes on and on.

Surprisingly, he was dismissive about my concern. Here's an email he sent me following our conversation:

I was thinking about this a bit more since out discussion the other day. I don't think it [API fatigue] exists, at least in its semantic meaning. Programmers are constantly exposed to new API's throughout their careers. It would be akin to talking about plumbers getting "wrench fatigue." Every time we do something new, which should be constant in a fulfilling career, we learn parts of a new API or learn more about one we're already familiar with.

I think what you may be more wary of is the seeming explosion of new APIs available. And, the work of keeping up with it all that goes along with such growth.

This would have been a big hill to climb before wiki's and blogs. It used to be that in order to evaluate and learn a new API you'd have to take a blind leap into a book on the subject (after doing the work of discovering the subject) hoping the book was decent. And you'd have to go through that cycle every time you wanted to learn some new tricks. Now the work of discovery can be done passively via RSS. Blogs like ajaxian for instance are constantly reporting on developments in AJAX that you can scan via RSS and bookmark for later. And wikis allow people to outline the strengths and weaknesses of a new API along with collectively documenting how to get the most out of it. You buy the book after you've decided it's a worthwhile skill to develop.

As far as how to keep companies and teams abreast of the state of the art, I think that it's important to factor in time for developers to do a little research and share what they've learned with the rest of the team. This could be in the form of making allowances for side projects (like Google's 20% time or just allowing developers to pursue hobby development in slow times) and scheduling time for teams to gather socially. Like a team lunch or happy hour. This encourages developers to research what they're passionate about and think outside of their workaday box. And, share the roadblocks they've faced with each other so that the others can offer suggestions they'd never have thought of on their own.

The surge in innovation in this space is built on the tools you need to keep up with it. Group discovery and the knowledge of crowds. Nurture that and you may get both a great team and great innovations.

There you have it, boys and girls. The cure for API Fatigue Syndrome: the wisdom of crowds and a pint of beer.

UX: it's the little things

I was just reading an article in the NYT and inadvertently selected a word. A little icon of a question mark popped up and when I clicked it, it launched a new window with search results for the selected term.

It's little human-centered things like this that make for a great user experience. There were no instructions telling me about this, but it was discoverable, it was intuitive and it was helpful. The term 'design thinking' has been latched onto lately and you're sure to see loads of articles in marketing publications featuring it. Here's a great example of it.

One agency guy's New Year resolutions - iMedia Connection Blog

iMedia Connection Blog: One agency guy's New Year resolutions

View >>