TaoSpace

WWDC 09: The usual predictions

I do these every year and seem to get a slightly-better-than-50-50 success ratio. Since nobody reads this anyway, this is mainly for my own amusement.

iPhone

1. iPhone OS 3.0 demo. Shoe in. 
2. iPhone OS 3.0 will have some surprises still. I'd bet on a new, previously unseen, Apple app.
3. New iPhone. Better camera, more storage, compass, video recording and clipping. At the risk of sounding like Bill Gates ("640K ought to be good enough...") I'd wager no faster processor. OS 3.0 will be more optimized and some of the peripheral hardware (video & audio chips) will be more efficient, which leads to a better overall experience. I still feel a much faster processor would put developers in a bind, with a large installed base using slower phones. Then again, I might well be wrong here.  
4. Expect some big announcements/highlights of new companies joining the developer program. Enterprise stuff, like IBM, Oracle, etc. Note that most games produces are already there. iD software might show up and demo a new unannounced game: hardly the first time. 

Mac

1. No new hardware. Certainly not a netbook or tablet. If they did, it makes more sense to do that at a special event.
2. Snow Leopard demo. Expect some actual surprises here. I'm betting on a new UI. Also, Apple quite likely wants everybody to upgrade, so I wouldn't be surprised if this release would be priced in a friendly way.  
3. Social network integration. Several apps in Snow Leopard and iLife have some form of this. Expecting at least some mention of this, if not some announcement of further integration
4. App-store for Mac apps. Haven't seen much mention of this, but I'd say it would be silly not to extend the app-store to include all Mac software. It works and devs are willing to give Apple part of their cash for the privilege.   

MobileMe

1. This was last year's big thing. Expecting some announcement in this area, perhaps related to the social network stuff. Remember that all Apple really lacks to turn MobileMe into a social network is friend lists...

Well, let's see how I did on monday.

Almost one year on: Epson Stylus R2880

Almost a year ago, I threw out my HP B9180 and replaced it with an R2880 and wrote about the initial experiences. Since then, I started the Epson R2880 profile tracker page and have generally printed bucket-loads of photos.

The profile tracker is basically "done". All paper merchants, that I've managed to track down, have created R2880 profiles for their papers and there is little news to report. This is actually perfectly fine. It means the R2880 has become a reliable workhorse, like the R2400 before it. No surprises, stuff can just be expected to work.

It took a new comment on that original R2880 post, to remind me how long ago it has been since a bought it. The printer has been performing exemplary since I got it. In the beginning I was worried it would develop issues similar to the HP, but no. 

Before each print run I print a quick test sheet, and if needed, run a cleaning cycle. Cleaning isn't necessary that often, and if needed, it pretty much never has to be run more than once.

The fact that I can buy ink at several stores, including one 200 meters from where I live, is also nice. It was necessary to order HP cartridges over the web, as no stores carried them. One hint here is to totally ignore the low ink warnings the printer throws out, until it simply refuses to print. I have done this for a long time now and never had trouble with it. It does however save you a lot of money, as you truly use all the ink in the cartridge.

All told I'm very happy with the R2880. It does what I need it to do, and does so without complaining. The results have been consistent and of high quality and regularly draw praise from people that see them.

If you're on the fence about buying this printer for some reason, get off it and buy one.

Open enough?

Ever since the release of Facebook Connect, countless blog-post have been written on the subject of identity management and "delegated sign-in" for the web. 

To fans of the open version of this idea, OpenID, the release of FB Connect must have been a bit of a shock. Not only does it do exactly what OpenID was meant to do, it also adds some very useful features: Friend-lists and messaging.

This means that not only can you use your Facebook identity to log in, you bring your entire social network with you as well as a communications mechanism for actually making use of this network.

To make matter worse, it offers a very simple user-interaction model, as compared to most existing OpenID experiences.

The final insult to the injury is that, contrary to OpenID, Facebook isn't federated, meaning that only Facebook provides Facebook Connect, nobody else. You cannot manage you own identity yourself somehow, and then use Facebook Connect to get you in to other sites using that identity.

But the plot thickens: Now there is "Sign in with Twitter". This lets you use your Twitter account to log in elsewhere. Twitter of course already has friend-lists and messaging, as these are the basis with its entire service. The result is basically a direct competitor to Facebook Connect.

What is more: it is based on open standards. Just not OpenID, but a related standard called OAuth. OAuth allows you to grant a third party access to your content (to be more precise: grant access to API which can access your content at some service provider's site) without giving your password away to this third party. In that sense it is a more generic standard. "Your content" could be your identity information...

That is pretty much how Sign In With Twitter (SIWT) works. Yet OAuth isn't federated and neither therefore, is Sign In With Twitter. You need a Twitter account in order to use it, and you cannot yourself manage your identity and then use it together with SIWT to get access to sites.

It is hard not to see this as a pretty big "No" vote from Twitter to OpenID. They could easily have made your Twitter account become an OpenID (and they still could do of course), but instead they choose simplicity and brand-recognition over a totally open solution. People know whether they have a Twitter account or not. Most people however, have no clue what an OpenID is, how to get one, why it matters, etc. This is main thing Facebook Connect got right.

As Eran writes here, even most current OpenID implementations (Yahoo, Google) are already emulating this. "Sign in with a Yahoo ID" uses OpenID in the background, but it only allows you to log in using a Yahoo OpenID. Got your own? Too bad, it won't work! Whether or not it is OpenID in the background is irrelevant. It is basically their own system, just like SIWT.

The reality here is clear: OpenIDs are URLs, just like your favourite website has, and very few people grasp that concept: "How can a URL be my identity? I have a URL? Scary!". Both Google and Yahoo's OpenID implementations rely on smoke and mirrors to translate something the user knows (their Google log in credentials) to something they don't (their Google OpenID URL). Of course there is a standard for doing this, which has largely gone ignored.

Even with these patches though, OpenID by itself does not provide friend lists or a messaging system. You can argue that OAuth doesn't either, since it only gives access to an API. What that API does is different for every service provider. However, most OAuth enabled sites and those like it (Flickr being a good example), provide these features in one way or another. This is usually a large part of the reason for these sites to provide OAuth in the first place. Completely custom for each site, but available.

To a site developer, implementing 4 or 5 siloed sign-in providers, likely with the option of getting in on the user's social network and having a clear way of messaging the user sounds good. Really good even. Being "open" as in "federated", is nice but delivers little immediate value for the developer.

Messaging and friend lists in a totally generic fashion, based on top of OpenID, does not exist at this point. Some examples of the concept do, but they only work on a specific silo (Google+Plaxo anyone?). So after everything, you are still stuck with implementing different mechanisms for each silo and you still have to get past the "I'm a URL?" issue. 

All these things combined make me believe that OpenID, in its current form, is going to lose this battle. There will not be a grand unifying identity mechanism for the web. Like with most standards on the web, there will be a couple of very big silos with their own "openish" solution and a whole bunch of smaller fry that will try and be compatible with all them. 

That's a sad thing, but still better than where most of the web is stuck today.