ReadBurner's BurnURL Fires Up Social Web Sharing
It’s easy to understand why URL-shortening tools such as TinyURL and bit.ly are popular on the social web. For web workers, the ability to quickly absorb, organize, package, and redistribute information is a critical and demanding task. BurnURL, a new service produced by ReadBurner (first mentioned here, and currently awaiting relaunch), seeks to add value to this process by making it easy to allow people you’re sharing with to do additional sharing.
It’s a matter of reducing the steps to the bare minimum in order to allow a piece of content to “go viral.” BurnURL does its part by with something called the “ShareBar.”
BurnURLs are created in the same way as other URL-shortening tools. Head to BurnURL.com, or grab the bookmarklet so it’s a simple one-click operation, enter the URL, “burn” it, and you’re provided with the shortened URL (for example, here’s the link to the announcement on the Official Readburner Blog: http://burnurl.com/ejwnvF) so that you’re set to fire off the BurnURL via Twitter, e-mail, instant message, and so on.
The real power of this tool presents itself when you click a BurnURL and find the ShareBar that runs at the top of the destination page. While services like Adjix and Linkbee use a header space on destination pages to run ads, BurnURL carves out a social media and redistribution area that has the potential to be highly effective for web workers.
Front and center at the top of the screen is a share area that easily allows recipients of the BurnURL to reshare the web page that they’re using via Twitter, Facebook, Digg, Mixx, Reddit, Delicious, and StumbleUpon. I’d like to see BurnURL expand this area to aid people who use such tools as Yammer, an enterprise version of Twitter that includes task management tools, and ididwork. Again, the ability to quickly and efficiently find important content and then pass it along to colleagues and clients (who then, in turn, are empowered to do the same) is a powerful web utility. It would be especially interesting and useful to see a simple “Shared” meter, noting the number of times a web page has been “burned.”
That said, we are told how many “hits” a page has received, which I presume to mean the number of click throughs an individual instance of a unique BurnURL has received. It would be all the more useful to be able to see this number, as well as the aggregate number of views that the page has received through the total number of instances in which a web page has been burned and shared.
There’s also a really simple ability to vote a BurnURL page up or down, which helps to tally the percentage of people who “liked” the page. Again, I’d love to be able to see the individual page statistics vs. the aggregate here.
But even as it stands, this tool provides a strong means for organizations of all kinds to track data usage. For example, I can find an online article, burn it, share it on Twitter with a note saying, “What do y’all think, vote up if you like it.” Then later in the day I can check back to see how many people visited the story via the BurnURL link, and the percentage of them that liked it. This is pretty powerful stuff in terms of the lightning-fast ability to distribute content on the web and receive feedback in real time.
And finally, if I may add one more item to my BurnURL wish list: Google Reader-style “share note” comments, which would allow people to leave short notes on web pages that can be added to as they are redistributed.
What URL shortening services do you use?
Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.
Really nice review Eric. We’ll take note of your suggestions and I’m hoping we’ll be able to continue to impress you as we add more and more.
Eric, thanks for the support and for the article….and most importantly your ideas and feedback. We have quite a bit planned for BurnURL and ReadBurner as well, and all of it stems from feedback like this.
We are dedicated to creating useful tools that people will actually use.
Keep burnin’!
Yo, is this similar to twitpwr.com ?
Also doesnt shortening the URLs impact the ability for spiders to follow links and give credit to the linked page (SEO stuff). Might be nice to have the option to NOT shorten already-short URLs…
Strange you didn’t mention ginx.
Mike and Drew, thanks very much and look forward to seeing more.
It looks like twitpwr is related to BurnURL but not all that similar, gruvr. I’m guessing there are SEO implications (and I know Google doesn’t see Twitter click throughs because of a “no follow” rule?) but perhaps someone can elaborate who knows more about this aspect.
I’m not that familiar with ginx, Stowe, checking it out now, thanks!
Looks quite annoying actually. If you use Twitter, Digg, Facebook, Reddit etc., you tend to probably already have a way that you post URIs to it. What I want from a URI shortener is for it to be lightweight and not get in the way. And any service which adds frames to the site gets in the way, as it means that it’s not the actual URI in the location bar but something else entirely. So, no use to me at all – the features take away from the simplicity of what’s needed. I’ll keep on using urlb.at and is.gd.
A BurnURL URI returns 200 OK. is.gd returns 301 Moved Permanently. That is the expected behaviour for a URI shortener, not returning a 200 OK. If one wishes to dereference a is.gd (or similar) URI, one can simply get the header and read the Location: field, whereas with BurnURL, one has to load the HTML and parse it manually. Header-level redirect (a 301, not a 200+HTML) also means that things that don’t speak HTML can use the shortener. If I wanted to post a link to a very long e-mail address on Twitter, I could use is.gd safe in the knowledge that a user agent could read the 301 header and then access the resource – the mailto: – without necessarily having a browser open up.
Good web resource architecture is far more important for me than social media frills. I preach these principles, and the products I choose to use to redirect people to web resources need to match those principles.
@Tom – We’re now returning a 301 and the location if you do a “HEAD” request versus the typical “GET” request. This should provide access to the things you mentioned.