Posts tagged facebook

Friday (ish) links – January 15th 2010

A few random selections from this week’s reading.

Discussions of online privacy continue to rumble on. ReadWriteWeb had a piece about (facebook’s) Mark Zuckerberg repeating the adage that “the age of privacy is over.” Zuckerberg’s comments would appear to continue the confusion around facebook and privacy. Facebook’s popularity is at least in part due to peoples’ perceptions that there is some privacy (or at least control) inherent in it, but they keep eroding that. I deleted my facebook account a few weeks ago, partly because I was tired of negotiating its plethora of options. Twitter’s “always public” or “private” are really so much easier to handle.

Jeremy Gould pointed out O2’s SIM only iPhone plan on twitter the other day. I really wish I could find an equivalent in the US. On our last trip I was carrying two iPhones and a Palm Pre, but ended up buying a $10 virgin mobile phone from Best Buy.

Perhaps the biggest news in web development this week was the release of jQuery 1.4. The full announcement is here. I’m particularly pleased about all events now supporting live(), the improved support for contexts for actions, and the performance speedups, but many of the API changes look very nice. It’s been great to see several meaty blog posts about how some of the new features/improvements were achieved, such as this one on how the live() support works and Ben Nadel’s piece on handling problems with mouseover/mouseout.

In a similar vein I continue to enjoy Yehuda Katz’ coverage of Rails 3, including this piece on ActiveModel. It’s great to finally have a simple way to use AR’s validations, callbacks, etc. outside of ActiveRecord without resorting to nasty tricks. Gabe de Silveira also deserves some credit, not only for his very useful looking validation_scopes gem, but also for a dissection of its writing.

I missed this month’s LRUG but have been reading up on Dragonfly, a ruby library to handle image uploads and produce resized versions on the fly based on directives in a view. Putting that logic in the view makes a lot of sense and I really like the rails integration being handled by inserting rack middleware. I’ll definitely be looking for a project to try it out on.

Ajaxian continues to be the best source for impressive efforts with javascript. This week I was especially taken by efforts to implement audio sampling in firefox.

Fresh from Silicon Roundabout’s appearance in the latest issue of Wired UK, Ben Terrett of RIG has been working on some merchandise. I guess this joke’s just going to keep going.

TinyMCE is now on github. Chances are it’ll remain a pain to use (as are all editors of its ilk) but at least it can be checked out more quickly now.

And of course it’s been impossible to miss the tragedy in Haiti. The past few years have seen really impressive efforts to harness open source tools and techniques for use in disasters. Andrew Turner’s blog is a good stopping off point to find out what the mapping community has been up to.

Selected (belated, extended) Saturday Links

The past two weeks haven’t really left time to compile my selected links, though there have been many. A few days at SxSWi (on which more, later) followed by travelling with the family and the inevitable work backlog moved blogging way down the priority list. So here’s a mammoth selection to get me caught up. Particularly interesting has been the discussion around the future of newspapers (represented here by Clay Shirky, Steven Johnson and Russell Davies), which seem to have finally pushed beyond “how t ind a good business model for papers” to looking at where the real value for society lies and how we can preserve and extend that in a changing landscape.

Selected Saturday Links

Big themes this week have mostly revolved around twitter, facebook, and openness. Some have focussed on facebook redesigning to embrace a more twitter-like “web of flow” approach, and others on the fact that they’re jumping on various open web bandwagons. It’s been interesting to see some tie in with the government transparency thinking going around, as particularly noted by Chris Messina on FactoryCity. Meanwhile there are quite a few nice new tools emerging, and I really must try heroku one of these days.

Don’t imply privacy

Conversations about privacy are an increasingly vital part of any planning process for a membership-driven website. Having been engaged in such a conversation for a new project and fielding support emails for an existing one, it’s been on my mind quite a bit lately.

We’re all managing a lot of personal data, whether we’re running sites that might be described as “social networks” or simply a blog that provides a way to connect up a commenters contributions. On any new project questions inevitably come up about whether or not users should be able to hide their profiles or specific pieces of information, often influenced by the way facebook’s closed walls give a sense of privacy by not letting google index profile data. I’m given to thinking that facebook’s approach has actually hurt such discussions, by implying a level of privacy they don’t really offer.

The problem is that approaches like facebook’s are far more about an illusion of privacy than any actual protection. The artifacts of our online presence, our comments, our photos, etc. and perhaps more importantly our friends’ comments and photos, are never going to be entirely shielded just because we can hide our profiles, but hiding profiles can make us think that protection is there. Similarly attempts by some sites to hide profiles from users who aren’t logged in offers an illusion. Because there’s a hurdle to see your profile it’s tempting to think that it’s protected, but that’s simply not the case.

Our designs need to guide people to be careful about what they’re putting in their profiles rather than having those profiles hidden, and to remember that their online artifacts will last even if the attention given to them dips from its initial high. Unless we’re providing something much more secure than a “hidden” profile, we should avoid the implication that our tools (rather than their behaviour) are what will offer privacy.

[Obviously there are some cases where our architecture needs to work harder to offer privacy, but that's far from the general case]

Why we’re not quite ready for everyone to build their own social networking site

Whether or not you should build your own social networking site and/or make use of sites like facebook is currently a hot topic within the not-for-profit web developer/consultant world. The launch of sites like Amnesty International’s “unsubscribed”, which bears many hallmarks of a social networking site, combined with growing attention for facebook campaigns and tools like SuperBadger bring the options and potential into clear focus. Elizabeth Dunn’s post last month “social networks, walled gardens, and decision trees” makes a compelling argument that non-profits should be focussing on these questions now even if they’re not key for their current audience: sooner or later they will be and you don’t want to be playing catchup.

There are certainly many advantages to having your own social networking site. A facebook or myspace presence may attract attention, but the data you’ll be able to gather about your supporters and the potential for inserting your own branding are limited. Set up your own social network and you have full flexibility to integrate that data with your supporter databases, and to tune the site to your very specific requirements. But not only are they a significant investment of resources, there’s also a significant cost of time for supporters who will need to sign up for yet another site, identify their friends once again and give their attention to even more online data. Online campaigning’s great strength so far has been its low barrier to entry; for cause-specific social networks to really make sense their barriers need to fall.

That desire is definitely not unique to non-profits. As Brian Suda’s “Portable Social Networks: Take Your Friends With You” highlights, finding ways to let users move their data from site to site is a hot topic across the web development world. Sites like traveller network dopplr have succeeded in part by letting their (so far highly tech savvy) users import data from other social networks such as twitter. The real breakthrough will be when the mass-networks of the moment (as facebook is today) become similarly open. That won’t make it easy, but it will mean that there is suddenly a huge audience who can become fully signed up for your site with just a couple of clicks.

Right now most efforts hinge on a set of emerging standards, two of which will be familiar to anyone who’s been reading this blog for some time but which bear some more attention. There’s plenty of information around the web on these so I’ll just touch on them briefly:

Microformats are a way of taking plain old HTML and, by following some conventions, adding meaning to the content that could be understood by machines. While a human might be able to look at some information and infer that it is describing an event, machines aren’t so good at that, so we need standardised ways to say “this is describing an event, that bit is the date,” or “this link is to the homepage of my brother.” There were already ways to do that, but it involved adding extra things to your website. With microformats, so long as you (or your content management system) follow some simple conventions when creating a page, a machine can get the content out of the page as easily as a human reader can. That lets us identify friends/contact lists in a portable way, among other useful functions.

OpenID is a way to get rid of the frustration of having to create a username and password for every new site you visit. Instead when you visit a new site that you want to sign up for, you enter a URL that is your OpenID and that site will check with a central system (which may require you to log in) whether you do in fact own that OpenID. Rather than having to remember dozens of usernames and passwords, you’ll probably just have to remember one URL, one username, and one password. And because you’re using that same OpenID for lots of sites, when you sign up for a new site you can be identified on others. So if you sign up for a new site I’ve created using the same OpenID you use on livejournal my software can identify you on livejournal and import your posts from there. So there’s less work for you to tell that new site you’re creating a profile on how to find your blog and to import the posts, and an easy way to make your profile active and informative.

OAuth is the newest of the standards and goes hand-in-hand with OpenID. It allows you to grant one web application permission to access certain parts of your data in another application without giving your usernames and passwords all over the places. If you’ve ever used a site that redirected you to flickr to get your permission to do something with your photos, you’ve seen something like it. If OAuth is widely adopted, no longer will you have to give every social networking site your webmail username and password in order to have your address book checked for other users of the site, simply trusting that they won’t abuse it. Instead, it becomes easy to give a one-off permission while keeping your details as secret as they should be.

What these pieces add up to is a significant reduction in the psychological hurdles that might prevent your supporters from joining your new social network. Instead of pouring hours into their friendster profile only to find everyone has moved to myspace, and so not signing up for your site because they’d have to go through the whole process all over again, they can sign up with their OpenID, perhaps grant you a few permissions with OAuth (knowing that they’re not handing over the keys to their email, online photos, or whatever) and be signed up with an already complete profile.

In other words, persuading people to sign up and build their profiles is no longer the issue and you can focus on providing them with compelling reasons to keep coming back.

So if you’re wondering whether now is the time to start building out your campaign’s fancy new social networking site, it just may be, but chances are a few months from now will be a better time. As OpenID and OAuth become better established—and maybe even get adopted by some of the big players—your life is going to be easier and provided you pick web developers who’ve been keeping up you’ll be able to focus on your campaign strategy rather than coaxing visitors to spend another few hours re-entering the same old details.