bradKELLETT

I have the utmost respect for the engineers at Facebook. They are a very talented bunch, and the few of them I’ve had the pleasure to meet in person have even been nice folks to boot. Generally, they come up with very innovative and progressive engineering solutions to the huge problems they face, but their new photo uploader is one decision I completely disagree with.

The new Facebook in-browser photo uploader  is detailed well in a post from their engineering blog (along with a slightly more detailed look at security), but in a nutshell, it involves installing a browser plugin to handle file uploads in a separate thread. This plugin also creates Javascript APIs to gain full filesystem access to your computer, and sets up a small web server to allow Facebook to ping back to your local machine to check the status of your uploads. The primary reason to use this plugin-based approach is to allow a user to begin uploading photos and have them continue in the background while continuing to browse around the site.

This is a noble thought, but I really think it’s just engineering for engineering sake. The multitude of issues surrounding creating and maintaining a plugin of this nature far outweigh the advantage of allowing background uploads. And if background uploads are really that important to them, they could have come up with a smart solution to make use of their current AJAX page loading process. This process, currently in place, allows certain browsers like Firefox to surf around Facebook without re-loading the whole page, so technically a simple Flash uploader could continue as part of the original parent page. It’s called progressive enhancement folks – the browsers that don’t support Facebook’s AJAX page loads can just use a normal uploading process.

And apart from all of that, what is stopping users from opening a new tab or window to continue browsing? Seems to work well for every other site out there.

Yes Facebook, your current photo uploader is awful, but let’s not create a huge security hole by exposing filesystem access to Javascript and running a little web server on everyone’s machine. I really don’t want to have to trust you to maintain security on your plugin (on three platforms, even), just so I can upload a photo.

Zizhuang Yang, an engineering intern at Facebook this last summer, recently put up a very interesting and detailed post on the company’s engineering blog describing extensive user testing of various loading styles and times for Facebook he conducted as part of his internship. While the whole post is worth a read, one point really piqued my interest:

Another debate within Facebook pitted two loading schemes against each other. The debate was over whether or not we render the page as soon as possible … [running] the risk of showing users links and content that they won’t get a response from until the interaction scripts load.

His testing concluded that keeping the page blank until the Javascript has loaded resulted in lower usage statistics, and thus it was better to render the page even though nothing would actually work. This is a very interesting problem faced by many developers making Javascript-rich user interfaces, and while Yang’s conclusion might be right in this circumstance, it certainly isn’t valid everywhere, maybe even across Facebook itself.

While I can completely understand that it would be best to render out the Facebook logged-in homepage as quickly as possible, since presumably most people hitting it are there to read their status feed, I think it would not be so great for something like the photo album page. On the photo album page, people are expecting things to happen quickly – selecting a photo from the thumbnails, paging through photos – and all of this happens through Javascript on Facebook.

There is definitely no boiler-plate solution for load order, developers need to assess the situation on a case-by-case basis, but at the very least it provides a great argument for progressive enhancement (starting with a page that works, adding Javascript to make it nicer), since everything on a page would work regardless of whether Javascript has initialized or not.

Launched at Startup Camp Australia last weekend, uTag is a new service aimed at rewarding users for the value they pass onto their online social networks. At its core, it is a URL shortening service – the difference is that uTag place a banner ad frame on top of the redirected website, sharing revenue with the user that originally posted the link.

This sounds simple enough, but what do the members of these social networks think of being advertised to though the links they click? I asked my Twitter followers whether they would unfollow someone monetizing their links through the service, and these are a small selection of the responses I received:

Navarr: @bck: I would unfollow them if they became spam. If they were relevant, and had context, and just fit in, then its all good. And as long as it wasn’t just outright spam. Ads are the driving force of the internet. I recognize this.

rgillettpr: @bck they would need to continue with links the way they were, not increase the noise just to get $$ for it

lindsayevans: @bck probably wouldn’t unfollow, but wouldn’t click on their links any more either

rgillettpr: @bck if i started seeing way more links from that person, and if they didn’t seem like links that person would usually send, would unfollow

shauntrennery: @bck A good idea would be if Google have some type of API that would allow ut.ag to search for ads relative to the tweet. That could work.

The two main concerns overall were that the user continues their current trend of link posting, and that the ads were context sensitive. No one raised the issue of people making money off another’s work, and instead focused on rewarding the user that posted the link for their work in finding it. This is somewhat the same as how ‘guides’ on Mahalo and other link aggregation kind of sites get paid – they didn’t make the content, but they add value to it by indexing it and revealing it to others.

Personally? I don’t expect to get rewarded for linking to other people’s content, since I don’t see that posting a link in my stream is adding enough value to justify that. As such, I can’t see myself using the service, but at the same time I wouldn’t not click a link that is shortened with uTag just because it is using uTag. What it will do is reduce the chances of me ‘blind clicking’ to links without a description – at the moment, I’ll click through to a link that someone posts just out of curiosity, but I wouldn’t do this if it was a uTag link without adequate description. I do believe that in their current form, the ads are slightly too intrusive, but at least there is a close button on them (though it can get hidden depending on the size of your browser window).

Overall, this system is exactly how About.com does things, though in most cases they are adding far more commentary to the links than can be had in the limited space that most social networks allow. I see the use in uTag as a monetizing service for bloggers more than through social networks like Twitter and Facebook.