Today, after six and a half years, I’m leaving Blip. When I joined the company in 2006, there were seven of us - five founders, two employees - in a tiny converted apartment. Today, Blip has more than forty staff, offices in New York and Los Angeles, and a brilliant lineup of original web series.

I’m moving on to work on my own projects. I’m tremendously excited by what the next few months have in store for me, but I’m still sad to be leaving. Blip is an amazing company, home to some of the smartest, nicest, most talented people I’ve ever met. It’s on course for huge successes in the months and years to come, and even if I won’t be directly involved, I’ll still be cheering from the sidelines.

Thanks for six great years, and all the best for the future. KFTC.

The great Facebook advice experiment

I was feeling a bit stressed the other day. On an impulse, I wrote on my Facebook wall:

I have decided I am in need of advice. Please send me all the advice you have. I will pick whatever seems applicable.

I didn’t really know what I wanted or expected, but it struck me as a funny thing to write. I also thought it might be a little like flipping coins or consulting the I Ching or a horoscope when you’re trying to make a decision: whatever comes up, you just project your own reading onto it (or, in the case of coins, flipping repeatedly until you get the result you want), and end up doing what you secretly really wanted to do all along.

My friends came through. I received lots of advice. Some of it was generic: “Buy low, sell high”, “Wash behind your ears”, “Don’t take any wooden nickels.” Some consisted of popular culture references: “Don’t blink”, “One word: plastics” and “Only an asshole gets killed for a car.” Some of it was surreal: “Don’t wash mushrooms in a washing machine”, “Don’t pat a burning dog.” Two friends shared advice they’d had from their parents: “Tell them to stop, if they don’t then punch them” and “Don’t drink whisky or you’ll have nothing to fall back on when you’re forty.” One person sent me detailed advice on cooking asparagus.

Two people suggested what looked like proverbs: “Never take two camels when a mule will suffice” and “If ye will not when ye may, when ye will ye shall have nay.” Two sent in summaries of their own current ideological programs: “Have no fear” and “Disconnect”. One quoted the great Jon Langford: “Get the money, don’t leave anything behind.” Two couched their advice in corporate speak: “Ideate. Iterate. Keep the throughput in the green zone” and “Proactively leverage synergies across the enterprise.” One whimsically advised me “Don’t stick your prick in daisies”. That one took me a moment or two to figure out. Another told me to “Fallow your heart”. I couldn’t decide if that was a deft epigram … or just a typo. 

Not all of these were easy to apply to my own life, but “Have no fear” and “Disconnect” sound like good ideas. “Have a good time, all of the time” is also a nice goal, but potentially challenging. Something about “Red wine to start. The rest will come” also appealed to me. But in the end, the one that struck the deepest chord was the enigmatic “Run, you clever boy. And remember.”

I can’t explain why that was what I needed to hear just then. But it was, and it made me feel much better.

I feel as if I’ve made a discovery. Specific advice is overrated, unless you’re buying something. The key is to get advice that’s as generic or random as possible, and then you can read into it whatever you want.

Me and Blip's VP of Tech

Jeff: Have you been to Hill Country?
Annie: I'm vegetarian.
Jeff: ...
Annie: Sorry, didn't mean to cut that conversation short.
Jeff: Conversation? That cut our friendship short.
Actually ... having been dragged to Hill Country by Jeff, along with the rest of the dev team ... I can confirm that some of the sides are pretty good and they even do a reasonable salad. If you can get over the incongruity of being a vegetarian at a barbecue restaurant, and ignore the fact that all your fellow diners are tearing into chunks of cooked meat the size of a smallish SUV, you needn't actually starve.

blip:

jefforulez:

.@blip flash mob on the N train

Hey, who let the developers out?

Blip takes over a subway car, in more ways than one.

A teachable moment

Richard Kadrey said it best:

What does the death of Delicious teach us? The cloud isn’t your friend. The cloud will lure you into its van, but there’s no candy in there.

Substitute ‘Google Reader’ for ‘Delicious’, and the lesson is the same.

Today, Google announced that they’re pulling the plug on Reader, their RSS aggregation service. This has prompted predictable cries of outrage in the Twitterverse, as people who love and use Reader daily suddenly face the chilling prospect of life without it after July 1st.

I am not a Google Reader user … or rather, I am, but I don’t use Reader on the web to read news. Instead, I use applications - NetNewsWire on the Mac, and Reeder on my iPod. Both of these applications offer the option to use Google Reader to synchronize your news feeds. When I read something on my iPod and then switch to the Mac, the thing I’ve just read is marked as read, so I don’t have to read it all over again. If I flag something to read it later on the Mac, it’s flagged on the iPod. If I subscribe to a new newsfeed on the iPod (or on the Mac, or even on Google Reader itself) it’s there on all the other devices I might use. It’s seamless, transparent, essential.

Come July 1st, Reeder and NetNewsWire aren’t going to be able to leverage Google Reader to provide this very useful functionality. They’ll either have to drop the feature, or switch to another provider that offers the same functionality, or implement it themselves. Google has just pulled the rug out from underneath them, and they - and many similar apps or services - are going to have to scramble to find another solution.

If you go to Reeder’s settings panel, the very first item is “Google Reader Account”. Same thing with NetNewsWire: under Sync settings there’s a checkbox that says ‘Sync with Google Reader’. There are no other options, no alternative services.

The fundamental error that the creators of both these excellent apps have made is that they programmed against an application, not against an API. What they need isn’t Google Reader: it’s something that offers the same API endpoints and the same functionality as Google Reader. That something could be anything. So long as it looks and behaves like Google Reader, it doesn’t have to be Google Reader. My guess would be that an averagely-capable programmer could implement a simple webapp to implement the API and duplicate the synchronization and storage functionality of Google Reader in a weekend.

What the app makers then need to do is to change their apps so that instead of saying “Synchronize with Google Reader” they say “Synchronize with …” and let you specify the service of your choice. Provided that service supports a synchronization API, the app shouldn’t care who or what it is.

I’ve actually wanted this for a while, simply because I don’t see that what I read is any of Google’s business. I would have been happy to deploy a synchronization webapp on my own server and keep it all to myself. Not everyone has their own server, of course, but I’m sure there’d be businesses who’d be happy to step up and provide synchronization as a service - if the apps supported it.

This error - programming against a specific application, not a general API - repeats throughout the app ecosystem. Reeder lets me choose one of three bookmarking services - Pinboard, Delicious and Zootool - to save links to. It lets me save articles to two offline reading services - Instapaper and Pocket. It lets me send updates to two different micro-messaging services - Twitter and App.net. Each one gets a separate entry in the Reeder settings panel.

What if, instead of Twitter or App.net, I wanted to use Identi.ca or Tent.is? Or my own server running tentd? Sorry, no can do. Those options aren’t offered. Even though each of these is fundamentally the same kind of thing as Twitter, and may even support precisely the same API (or, if they don’t, could easily be made to). It’s the same thing with the other options: for all the options that an app developer can squeeze into a settings panel, there are always a few more services that aren’t offered. Yet in many cases, the app could talk to them without changing a single line of code.

I’m not singling out Reeder - a truly excellent application - here. All app developers are doing something similar. They pick the current market leader for some particular functionality, they implement support for it, and they put it in their app. If there are a few equally prominent competitors, they might support two or three. But that’s all.

In the same way, a bunch of other apps that I use offer support for Dropbox. Why not? Dropbox is a wonderful service. But Dropbox is now just one of many similar services. Why support Dropbox and not Box.net, or Pogoplug, or Microsoft SkyDrive, or iCloud? Or a private cloud storage service implemented using an open-source solution running on someone’s server somewhere?

“Oh, but we can’t possibly support all those different applications,” the app makers say. Right. You can’t support a half dozen different applications. But you could support just one API for any functionality you need to implement. One API for cloud storage. One API for bookmarking. One API for RSS synchronization. One API for micro-messaging. One API for sending articles to an offline reader. One, open, documented, well-defined API for each type of service.

The beauty of this is that if a given provider - say Microsoft - doesn’t offer the required API, they will actually be under pressure to implement it. “I’d like to use SkyDrive,” says Joe User, “but it’s not compatible with the apps I like on my smartphone.” When Microsoft realizes that everyone’s using still Dropbox instead of SkyDrive, they’re going to wise up and roll out the necessary API support pretty fast.

Actually, they probably won’t. This is Microsoft we’re talking about, after all. But I can dream.

The death of Google Reader is a teachable moment. App developers should take note of what just happened to Reeder and NetNewsWire and all the other dozens of newsreaders that used Google Reader for synchronization. They tied a critical feature of their software to one specific implementation. When Google took their ball and went home, they got screwed. Don’t let that happen to you.

Using open, well-defined, standard APIs is the Way of the Web. Locking your product to someone else’s proprietary implementation is a recipe for heartache. Program to the API, not the application. And if the API doesn’t exist, get together with a bunch of like-minded folks and design one. In the long run, it’s better for everyone.

‘Crêuza de mä (live)’ by Mauro Pagani & Joan Isaac
Figge de famiggia udù de bun che ti peu ammiàle senza u gundun.

It’s Valentine’s Day, and we have a chocolate fountain.

I rather miss the days when you just opened a text editor and typed some HTML.

Not real, but virtual

The Verge has a long article about Google’s design process, which talks about the way that Google has tried to create a unified but attractive and effective look and feel to all its applications, across multiple platforms.

In some ways, the article is frustrating: lots of fawning praise for Google’s approach, relatively few actionable recommendations that rise above the obvious (‘have your designers and developers talk to each other’). For me, however, the money quote is when one Google designer interviewed says:

“These are objects. They feel, not necessarily real, but they feel virtual. They’re not trying to be fake things, not … fake leather, fake wood, fake brushed aluminum.”

That, in case you didn’t spot it, is a dig at poor old Apple. For many years, Apple was the company that got design and UX right while everyone else was getting it wrong. It still does to a large extent. The elegance and success of Apple’s products such as the iPhone or the iPad is the product of much more than the superficial ‘lickability’ of its gleaming, futuristic interfaces. It’s the product of the way things work consistently and predictably, the way that the animations and the visual hints work to build an impression of objects that are, in Duarte’s words, “not real, but virtual”.

Unfortunately, Apple has recently tarnished its reputation for making good design choices by embracing skeuomorphic designs (complete with fake leather) for some of its built-in apps in MacOS and iOS. Skeuomorphism isn’t always wrong: if you can give the user a hint about functionality or meaning by alluding to some real-world object, it makes sense. Slavishly reproducing the look or functionality of something in the real world, however, is almost never a good idea. It’s a kind of cargo-cult approach to UX. Apple’s crude and ugly designs for the Calendar and Address Book are particularly shocking, both because they come from a company with a long history of making good choices and because their appearance is so glaringly different from everything around them.

Apple’s clumsy flirtation with skeuomorphism has spawned a backlash in the form of the flat design movement (or, as some commentators would have it, the almost flat design movement). But flat design isn’t a panacea. The flat design of RealMac Software’s Clear to-do list app, for example, works well (so much so that the iTunes Store is full of Clear knock-offs) On the other hand, all the flat design in the world can’t save Microsoft’s bizarre and confusing Windows 8 interface (the UI formerly known as Metro).

The reason Clear works has less to do with the look of the interface and more to do with the way it works. It hinges on a set of easily-learnable gestures that are tied to underlying behaviors. Essentially, Clear gives the user a set of virtual objects that they can manipulate, objects that may not have any direct mapping to the real world, but which behave in consistent and predictable ways. Once you have that, you don’t need skeuomorphism. Flat design is all the design Clear needs. You could implement Clear so that its objects appeared to have depth and texture, but you wouldn’t gain anything by it.

Slavishly adhering to the rules of flat design is probably just as much of a blind alley as trying to minutely recreate every detail of real-world objects. Or perhaps not just as much - at least a flat design won’t create the kind of visual atrocities that you get from excessive skeuomorphism. But really what we should be aiming for is ‘just enough design’: enough detail, in short, to help the user recognize and understand the virtual objects and metaphors that underlie the application. A user interface is the map of a virtual world: the first and most important duty of a designer is to choose a design that accurately and informatively reflects that underlying ‘virtuality’.