Blog posts tagged "facebook"

You and …

November 13th, 2010

Screen shot 2010-11-13 at 6.52.52 AM

The “You and X” pages are my favorite Facebook feature I’ve seen in a long time. (I’ll admit I’m a pretty limited user of “the Book” so the bar is low, though a new feature we launched adminonly yesterday on Etsy is making me think about bulking up on ‘Book friends).

Also reminded me of my favorite semi-secret feature of Flickr people tagging: the “You + X” pages.

If you visit the “/photosof/kellan” style people URLs you’ll get prompted “Anyone ever snapped a picture of the two of you?” and if you click on the link you can see pictures of the two of you. (us?) You can also hack the URL to string together a longer list of folks.

Screen shot 2010-11-13 at 7.05.19 AM

Henry Blodget: “Facebook’s Approach To Innovation Is The Secret To Its Success”

May 17th, 2010

http://www.businessinsider.com/facebook-privacy-innovation-2010-5

Blodget gets the headline right, and nearly everything else wrong.

I’m really surprised we aren’t seeing more people writing and talking about what I see as Facebook’s key competitive advantage: It’s a data driven company, which is nimble enough to act on that data.

When I look at the Facebook engineering culture I see the best parts of what we’ve done at Flickr, scaled up in a way I didn’t think was possible.

And when you look at the work the data team is doing (which you can get a sense of by the tools they throw off), you know that Facebook’s innovation is being tested, put through it’s paces, and extensively analyzed before most of us are aware of it.

This is a unique combination.

Streams, affordances, Facebook, and rounding errors

March 18th, 2009

I’m not really a Facebook user, but it is impossible to be a serious practitioner of the rough craft of building social software without being at least somewhat a Facebook watcher. So indulge me a bit, as I add my own thoughts to the cacophony of folks writing about the Facebook re-design.

I’ve always thought their status updates design was brilliant. Not because it was usable or attractive, I’ve always thought it was terrible. But because their design didn’t make promises they couldn’t keep.

Think briefly about the platonic ideal of an activity stream, the increasingly common social pattern that makes your traditional CRUD fronted MySQL install cry at anything remotely resembling scale. All the updates from your social network, quickly listed for your viewing pleasure, in reverse date ordering. No two users of your service will share an activity stream view (unless your service tends towards 100% social graph overlap, in which case why bother?), writes are high volume and need to be committed quickly to preserve ordering, and shared caching is right out.

So you go queue-ish, you de-normalize. And now you’re pushing messages around between services, transactional commit are gone, and you’re dealing with the inevitable skew of distributed systems. But even in queue systems, 100% guaranteed, in order delivery is more fantasy then reality (though you can get close).

But Facebook was smarter then that. They specifically designed a page that was lossy. They said, “You don’t want to see everything, here is a subset of things your friends do we think you’ll be interested in.” And so you knew that you weren’t seeing everything, it wasn’t that they were failing their contract with you, but that they had decided not to show you something for editorial reasons. And you knew that if you wanted to see everything you had to dig, because that was the contract. And that digging was scoped to a user, your wall or your friends wall, data scoped by data owner — super cheap look up.

Contrast this to Twitter.

Twitter is infamous for its bad period of down time as growth went asymptotic. But less well remembered is the teeth gnashing and hair pulling of the bad period right before, where update loss, delivery failure, and out of order delivery where the bugaboos of the day. Twitter promised you would see all your friends updates, always, neatly collated. The promise is implicit in the design, the language, the APIs, the very DNA of the service. (in fact Twitter used to make more audacious claims, I still mourn the death of the “With Friends” feature, that allowed you to see anyone’s public updates in the context of their friend network, not just your own).

One of the best, unattributable quotes from Social Foo last year was the data point that Facebook was at one point losing up to 80% of messages across their update bus. As someone whose expectations are shaped by the five nines style promises of Twitter, its a loss at scale which I can’t possibly fathom. And it wasn’t even an issue in the Facebook community. And when they expire updates out of hot storage to less accessible stores, you don’t notice, because they never offered you the option to page back forever. Contrast again to Twitter whose design (if not content) encourages you to page back forever until you smack up against an arbitrary and surprising limit. (whose exact location has changed over the years)

That is designing with affordances. Don’t let your design make promises you can’t keep.

A much smaller and possibly less well known example is the Flickr activity page, where you can monitor activity on your photos, or photos you’ve expressed interest in. For years this page was framed in the language of “which of these limited time periods are you interested in seeing events in?”, that was the question the page tried to answer. Not, “what has ever happened on my stuff?”. Because that was a much harder, and more expensive question to answer. As part of the Toto launch (new homepage) on Flickr last Fall we explicitly changed our contract with our users. Great photography has a 150 year tradition, and we felt that we could at least try to expose 5 years worth of conversations. (and Flickr usage by our members evolves and changes as their lifes evolve and change, something all good social software should design for, rather then living in the ever present now) Our activity streams go all the way back to the beginning now, but it wasn’t a change undertaken without a lot of thinking, architecture, and engineering.

Simon Willison asked this week about best practice for architecting activity streams. And the answer is, “It depends.” Depends on the scope, scale, access patterns, and affordances you’re building — your contract with your users.

Which is a long way of saying think hard about the promises you make to your users, implicitly or explicitly.

And, Facebook, my friend, what the HELL are you thinking? You managed to negotiate the best deal in the business, talk about a racket, and you threw it away for a piece of Twitter’s pain? Are you stupid? Well, best of luck with that.

Facebook on “Scaling Out”

August 21st, 2008

Jason Sobel has an interesting post, “Scaling Out” on Facebook’s BCP work and the move to being multi-colo.

Interesting to me was noting that:

  • they just got around to this 8 months ago, and they’re fscking Facebook (which means you can wait)
  • they’re still doing all writes to a single datacenter
  • they’re hacking an object-level mark/sweep into the MySQL replication stream suggesting a certain parable of a hammer and nails.

via PaulH

Official Digitally Mediated Community Week

October 3rd, 2007

Online Community Summit pre-meetings kick off today, through the 5th.

Then CommunityNext runs the 5th and 6th.

While Graphic Social Patterns will be on the 7th, 8th, and 9th

Facebook Data Store API

August 10th, 2007

When I heard that f.bk had a new Data Store API was thinking “Wow! That’s actually hard!”.

But if you read it closer you’ll notice the operations map to what can de done in memcache (down to transactions are handled via atomic auto-increments) with a bit of cleverness, and some persistence. (pun intended) Still a nice step towards making developing f.bk apps a bit less eye-pokey-outty

Everyone is building the giant hash table in the clouds.