blip:
.@blip flash mob on the N train
Hey, who let the developers out?
Blip takes over a subway car, in more ways than one.
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.
[video]
I rather miss the days when you just opened a text editor and typed some HTML.
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’.
Four years ago, I watched the inauguration of Barrack Obama at the old blip.tv offices on Lafayette Street. That was two offices ago; looking at this picture makes me realize how much has changed since then … and how much hasn’t.
In my distant youth, I wasted a great many hours playing a space trading game called Elite. Elite ran on an early 8-bit computer called the BBC Micro and, despite the crudity of the graphics, was seriously addictive. David Braben, one of the authors, went on to leverage the greater power of the PC to produce more ‘realistic’ and complex variants under the title Frontier, but for me Elite will always be the game.
Now there’s going to be a new Elite, the Kickstarter-funded Elite: Dangerous, which has passed its funding target with more than £1.5M raised.
One of the most interesting aspects of this Kickstarter is that science-fiction publisher Gollancz kicked in a big chunk of funding, in return for rights to the tie-in novels. Elite and Frontier were always sold with booklets that contained SF short stories and novellas, intended to flesh out the universe. The most famous of these was the novella The Dark Wheel by SF writer Robert Holdstock, which accompanied the first game in the series, but later games were also sold with collections of short stories, mostly by lesser-known writers.
The list of authors included one very little known writer indeed. Via a friend who worked for Frontier Developments, I ended up contributing a bunch of short texts and one complete short story, for which I was paid quite generously. Thanks to fan-site Life on the Frontier, I’ve just re-read my own story for the first time in close to twenty years. It’s not a classic of the genre, but it’s not as embarrassing as I feared. Perhaps I should reach out to Gollancz …