Things about Google+

Some thoughts about Google+.

First the simple one. I understand / appreciate Twitter’s simplicity a lot more now. It only does one thing. You don’t need to keep track of notifications and posts and tags and checkins and comments. You just read the timeline till you get bored or catch up.

Secondly, on an Android phone, with the Plus app installed, I’m now able to share my photos and comments, and links, you name it, into Plus from the system-wide Share menu, using any application on the system that supported sharing. On my iPhone, I need to wait for the G+ API to be released, then for all of the applications I use to individually invent and implement their own seperate ways of adding a “share to Google+” button, then for Apple to approve new releases of all their software, then I have to upgrade them all on my phone.

One of the reasons that Apple makes products with such nice experiences is because they control the stack from the hardware level right up to the applications on the phone. Everything works together. But that’s where Apple’s work stops – all the applications are (intentionally) silos that don’t / can’t talk to each other. The assumption is that once you have an application to do a thing, you’re finished. To do a different thing, use a different application.

Google’s management / control doesn’t reach down as far as the hardware, or even the OS layer (as the operators / manufacturers can do a lot of things to the platform in the name of differentiation), so Android suffers from a framgmentation problem at those levels. But at the network ecosystem level, they’re stronger than Apple – all of their internet products play together reasonably well. It’s not great, but it’s decent. Google+ can recommend contacts from my address book, or because I’ve sent them mail in the past. It can use the profile I already had. I can use photos that are already in Picassa in my posts without me having to faff (if I used picassa..).

Android has better Share support because Android is a platform that understands the Internet, whereas iOS stops at the Application layer. If you care about having nice applications, iOS is better, because everything about it is aimed at having nice applications. But in the next version of iOS, Apple might manage to ship system-wide support for Twitter, just as everyone I know stops caring.

(Related – when I get a notification on iOS that I have a new @reply tweet, or a new message on some service, it’s merely a notification. I have to launch the app to see what it is. If I’m underground when I see the notification, then I’m just stuffed. On Android, I’ll have the notification because the app already has the data. When I lived in Berlin, this didn’t matter, because you can get decent data everywhere, even on the u-bahn. In London, data is a lot spottier, and it’s changing the importance I put on offline support and background-fetching of data.)

Stars make search more invasive

Possibly Google didn’t notice last time they did this and it went badly. Let’s try again.

Stars sync with your Google Bookmarks and the Google Toolbar, so you can always see your list of starred items in one place and easily organize them.

HOW DARE THEY take a list of things I’ve saved in one context, and expose them in another context? You can’t read my bookmarks when you’re sitting next to me, but if I search for something and all my goat-mutilation bookmarks leap to the top of the results list I’m going to be upset.

Contact sync is scary

So what the Nexus One did was decide that my device was the Master, and the Gmail server hosting all of my contacts should be overwritten with this master content. [..] I had 5 years worth of contacts in my gmail, from so many projects and encompassing so many people I’ve met and done work with.

Alfie lost his GMail contacts. I feel for him; contact (and calendar) sync can be magic, annoying (because now you have two of everything) or _lethal_, because everything is suddenly gone, and there’s no undo. But there’s an important lesson here. Back things up. Just because it’s in the cloud doesn’t mean you don’t have to have backups. It just makes doing them harder.

Shelf and the Google Social API

The current trunk version of Shelf uses the Google Social Graph API to figure out who owns the web page you’re looking at. If it can’t find a person in the local address book who owns the URL, Shelf can now ask Google if there are any other pages on the internet that link to that page with a rel=”me” relation, and look for those pages in the local address book. So for instance, if I visit my linkedin profile page, Shelf will display context about me, as linkedin links to Likewise, any page that I link to from will be considered mine as well. This elevates Shelf’s context-finding ability to practically magical levels in some cases.

Alas, there are disadvantages. Most superficially, the context-deriving part of Shelf was never designed to make long-running network queries, and so lives in the GUI code. Calling the Google API blocks the GUI thread. This sucks. Fixable, of course, but it makes the current development version somewhat choppy.

More serious is that Shelf now sends the URL of every web page I visit, and the homepages of everyone who’s twitters I read, and the base URLs of every RSS feed I read, to Google. I want to look for context in the email signatures of people that send me mail too, so soon it’ll be sending the homepages of everyone who mails me as well. Some people would consider this creepy. Actually most people would consider it creepy. And I don’t blame them. I don’t really have a solution for this one either, other than a big clearly-labeled option to turn it on.

On the API

For this sort of use the Social Graph API is great. Although all this information is available through just fetching the source of the current page and looking for links myself, there’s no way I’d want Shelf as a local GUI app to be doing that sort of thing. Google aren’t exposing anything I couldn’t have found out myself, but they’re doing it in a simple and fast manner, and using the API is trivially easy. No API keys, dealing with XML, registering my app or anything. I love that they just went with JSON as the format, and hang everything else.

Where’s the next release?

On a related note, Shelf development has been a little slow recently. Partially I’ve been distracted by shipping important features for Dopplr, but mostly it’s because I’ve hit a sort of psychic barrier of progression. Shelf needs a decent caching layer. And a threaded context discovery layer. And a much better event-driven model for display stuff, so it makes a more controlled number of network requests to fetch RSS feeds. Basically, now I’ve explored the problem, I want to rewrite the whole thing to take advantage of my understanding. And that’s boring. So I’m not doing anything. I’ll get over it.

Google Earth placemarks from Dopplr

Thanks to a combination of dopplr, XML, mattb and Zimki, you can now display the locations of your Dopplr fellow travelers in Google Earth.

I’ve been wanting to use zimki to make a Google Earth KML file for some time now – not for any particularly good reason, mind, it’s just that Zimki is good at XML and Google Earth is fun technology. I just haven’t had an idea worth building till now. Then dopplr turned up, with its lovely geographical data and data on fellow travelers exposed in a simple XML format, and I had my project.

The next thing I’d like to do is expose information about the home cities of the travelers, to indicate people away from home, or perhaps an arrow to where people are going next. Any useful ideas?