There is a saying here in Australia: “Don’t throw the baby out with the bathwater”. I’m not sure it it’s common elsewhere, but basically it’s a warning not to discard the good along with the bad.
When Google Buzz was released, people were shocked at the automatic management of contacts. I suspect that people inside Google were quite surprised at this – after all, it was just a logical extension of what they had been doing within Gmail and Gtalk for years.
I also suspect that within Google it isn’t widely known how much people hate this feature. Personally, I’m no privacy freak, but I’m continually annoyed by the fact that I get random people showing up on my GTalk list just because we corresponded about some random open source project 5 years ago or something. I’ve also heard that a lot of Googlers have stopped using public GTalk because too many external people interrupt them. There is a lot I could say about the rudeness of strangers who just want help to diagnose problems etc, but for the moment I’ll just say that software should encourage desired behavior and discourage things you don’t want to happen.
However – I don’t think Google is wrong in thinking that computers could do a better job than humans of managing contacts for them. I’d love the auto-follow-on-buzz (and auto-add-to-GTalk) feature if it did it almost as well as I could do it myself. At the moment I tolerate the feature in GTalk because – while I know I could do better myself – I know from services like Facebook that the continual grouping and pruning of contact lists is a game I don’t have time for.
After the push-back Google got on automatic contact management in Buzz, it would be tempting to just give up on the problem. I don’t think they should do that – instead of pulling away from the problem they should invest in solving it.
Because then maybe I won’t hate my GTalk contact list anymore.
I’m a huge fan of FriendFeed.
I think that too many internet pundits see it as competition for Twitter, which is distracting from the real innovations it has provided. FriendFeed is the first real new way of reading rss feeds since the distinction between river-of-news and source-centric emerged.
The addition of a social layer which allows people to define who they are (by what data they produce) makes the subscription process much easier. I could see myself suggesting to family members to sign up to it so they’ll see what I’ve been doing – rather than the alternative of them having to remember to visit Flickr, and my 4 blogs etc, etc, or use a traditional blog reader wich will just confuse them.
At work, we started building a similar service for a vertical market group (educators in Australia) in roughly the same time frame as FriendFeed. There are a number of differences (we’ve only had 1.5 developers working on it over that time, for a start!), but the one thing FriendFeed has which I want is the commenting on items.
We actually built a proof-of-concept for a social-bookmarking service which would allow commentry on posted items (as well as on tags), but that hasn’t been incorparated into our service yet. However, we didn’t think of building that directly into the newsfeed, which is such a small thing, but makes such a difference.
Apart from that, here’s some things which I love about FriendFeed but most people probably don’t think about:
- The way your profile shows who you follow, not who follows you. Showing the number of people who follow you turns it into a popularity contest, which is kind of silly.
- The subtle influence of “Like” by your friends on what shows in your feed. If one of your friends “Likes” something then it will show up in your feed as posted by a friend-of-your-friend.
- The ordering of who liked something by how far away they are from you in the social graph (or showing your friends first, anyway)
- The search. The fact that it is easier to find one of my own del.icio.us posts on FriendFeed than in del.icio.us itself is scary.
- Imaginary Friends is a brilliant idea, which solves a really big problem. Whoever thought of that – in particular the name! – deserves lots of “Like”s
- The “multi-level” nature of it. You can start with using it just as a way of following people, then discover features just as you think “wouldn’t it be great if I could….”
Things I don’t like:
- “Like”. The meaning of the word makes it difficult to use in some circumstances (eg, reading about something bad which you want to remember). In our social bookmarking prototype we used a system very much like the “Rating an Object” pattern from the Yahoo design pattern library (which is a great resource for social software patterns, BTW). I think that actually rating an object may not quite have the correct social connotations for FriendFeed, but perhaps a “Star” (like in GMail) might be appropriate?
- I don’t think FriendFeed rooms work, yet. Maybe it is that I don’t quite get them, but firstly I can’t see a good way to find them, and secondly the fact that items need to be specifically re-shared into them is confusing. (OTOH, I’m probably wrong here, and they are probably already heavily used. We built a similar feature called communities (eg), and they have worked pretty well. We do have a discovery mechanism, though (as well as a more subtle recommendation thing when a person edits their profile)).
- Sometime a friend will share an item, and because people keep commenting it will remain towards the top of my feed for a long time. I know I can hide it, but I’d prefer the reverse – if I don’t “Like” it of comment on it then it should go away quicker.
Feature requests (some of these are things we’ll probably build into our system anyway):
- Tagging. I want to use FriendFeed as a social bookmark system.
- Direct messages, or a “@”-like syntax which will make sure a message is recived by the target.
Anyway, like I said: I’m a big fan. I think FriendFeed is already beautiful software, and it’s a joy to see the subtle, continuous refinement and evolution it goes though.
I went to the Google Developer Day in Sydney today. It was pretty interesting, even if I can’t say I learnt much new, perhaps becuase I concentrated on sessions about AppEngine and OpenSocial.
The AppEngine ones were excellent, but unfortunately I’d previously watched the video of the same talk from Google I/O. The OpenSocial sessions weren’t as good. I think they suffered a little from being unclear about the exact audience they were pitched at. In particular they seemed to jump around from assuming you knew nothing at all about open social to assuming you understood the difference between a gadget, a container, a REST server and Shindig.
The final session was an OpenSocial code lab, which involved the audience attempting to copy down random tiny urls to pages we saw for a few seconds. If you missed one of the URLs then nothing you tried would work for you afterwards. We used the iGoogle sandbox as a container, which seems to be pretty buggy and confusing. On the upside I did have a good conversation with John Hjelmstad about Shindig etc, as well as some interesting ideas he had for CSS spriteing.
By all accounts, the Gears & Android sessions were really good, so perhaps I should have gone to them instead.
Finally, my team at work were fortunate enough to be one of six finalists for the Google Speedgeeking prize, which seems to be a prize for the best mashups done using a Google API. We didn’t win, but we got a trophy anyway.
The problem with OpenID is branding – people get (very) confused when they get taken off site to login. I’ve watched usability testing of this, and it is truly horrible. Obviously this isn’t unique to OpenID – it applies equally to any federated identity solution (in fact – Shibboleth based federations are even worse than OpenID in this respect).
I think user education will help, but it would be really good to be able to extend OpenID to be able to put a logo on the identity provider’s site so the user can see they are logging into site “blah” via whatever open id provider.
I got a bit of feedback on my previous post about dataportability. The general gist was that because you can move your contacts from one email system to another (or export them) then data portability is good.
I’m not sure I agree. I think that joining a new social application and automatically finding existing contacts on that system is functionality that is likely to cause problems for users.
Each social application is a different context and people use them in different ways. Mid last year I expressed my concerns about this on the Social Network Portability group like this:
Everyone’s heard the stories of how employers are checking out possible
employees on Facebook. This system will not only find them on
Facebook, but find their user id on that new Playboy social network
for college students (http://www.techcrunch.com/2007/08/22/new-playboy-
social-network-built-on-ning/). That’s not a good thing to do to
dahna boyd wrote about similar issues:
I lost control over my Facebook tonight. Or rather, the context got destroyed. For months, I’ve been ignoring most friend requests. Tonight, I gave up and accepted most of them. I have been facing the precise dilemma that I write about in my articles: what constitutes a “friend”? Where’s the line?
I know people generally believe that growth is nothing but candy-coated goodness. And while I hate using myself as an example (cuz I ain’t representative), I do feel the need to point out that context management is still unfun, especially for early adopters, just as it has been on every other social network site. It sucks for teens trying to balance mom and friends. It sucks for college students trying to have a social life and not piss off their profs. It sucks for 20-somethings trying to date and balance their boss’s presence.
Back then I was all over using bloom filters as a way of attempting to preserve people’s privacy. I’ve given that up now – it’s a nice hack but it doesn’t really fix anything.
Moving your email contacts between systems is fine for both parties because it’s the same context – email. Being linked to your boss on LinkedIn and having them automatically find you on a dating site you are both a member of is going to put a lot of users off.
If you believe what you read on blogs, then dataportability is all peace and light and yayness. Unfortunately it seems someone forgot to tell the rest of the internets.
It seems to be that many people who want data portability are either not representative of the general population or have agendas involving trying to get as many people as possible onto their site.
This isn’t just a privacy concern: I continue to think that the difference in context between different social applications is a key constraint that people are missing.
I’m increasingly of the view that moving contacts from one application to another should require both parties to agree that that they want to be visible to each other in the new context. It isn’t clear to me that this a viable process, though.
(Something that should be obvious but apparently isn’t: portable APIs for web based social application – ie OpenSocial – are extremely good. Moving of personal data – ie, data portability – is something I think still is questionable)
Facebook will have a huge leak of personal private information. It will turn out to be due to buggy code, which will finally focus some attention on the fact that Facebook’s codebase appears to be really, really bad.
The Associated Press reported this afternoon that its reporters were able to use an undisclosed method to access private photos on Facebook, including some from Paris Hilton at the Emmys and others from Facebook founding CEO Mark Zuckerberg’s vacation in November of 2005.
I still think there’s going to be worse lapses than this by the end of 2008.
In shipping software I spoke briefly about me.edu.au (which is still taking a good amount of my time). Recently, though I’ve been spending a lot of time preparing education.au’s Java based federated search product (the Distributed Search Manager – OpenDSM) for release as an open source product. That’s been an interesting experience – the code is pretty old, and was glued together using static references. I had to pull it part, replace the static references with factories (changing to dependency injection wasn’t realistic for this release at least) and put it back together. It’s kind of odd working on a project like that – the code almost causes me pain at times, but with a product that is stable and reliable I don’t want to make too many changes just because I don’t like the style.
Some readers of this blog may be interested in it, because it allows federating of results from multiple Solr servers (or OpenSearch services) together into a single result set. That’s useful in quite a large set of places.
It’s also the first time I’ve been paid to create open source code as an explicit goal – most of my open source work has been for pragmatic reasons, not as a goal in itself.
Last week there was a bit of news traffic about some of the content that is on Ning. Whatever…
I think the really interesting story to come from those Quantcast stats (if you trust them) is the Share of Vists. 86% of the vists to Ning come from regular or addicted visitors?! That’s some pretty good stickiness.
So it turns out that it’s 2008 and the thing to do is to do predictions for the next year. Here’s my 2:
- Facebook will have a huge leak of personal private information. It will turn out to be due to buggy code, which will finally focus some attention on the fact that Facebook’s codebase appears to be really, really bad.
- Someone will realize that recommendations are the next search. Some company will work out how to do for recommendations what Google did for search: ie, take what is currently an overly commercial medium (eg, Amazon recommendations etc) and turn it into a consumer facing tool which is generally useful. By 2010 what they did will seem obvious, and by 2011 they will be billionaires.
Update – 1 more thing:
OpenSocial will succeed in a big way – not because of support from the big players (Google etc) but because lots of small open source web projects (WordPress, Drupal, Joomla etc) can easily add support and will finally have a standard way of creating cross-platform compatible software.