With so many social media sites in circulation today, badge soup can become a real problem for web sites trying to squeeze the most out of their traffic. Everyone has a different set of core social media sites that they use -- from del.icio.us and Ma.gnolia, to Digg, Reddit, and Diigo, we all have our favorites. But appealing to your users' varied tastes often means an overwhelming sea of site badges that is both unattractive and ineffective. Web developer Aza Raskin has a solution based on a browser history leak introduced due to CSS.
"Not everyone uses Digg. You have to decide on which bookmarking site, if any, to dedicate your precious screen real-estate. It's a hard choice. If you choose poorly your reader won't vote," writes Raskin. "On the other hand, if you take the bird-shot approach, it overloads your reader with branded badge after branded badge. It turns your page into the village bicycle. Not pretty."
As a solution, Raskin devised SocialHistory.js, a handy bit of JavaScript code that detects which social media sites your users frequent. Armed with that information, you can display only the relevant badges to each user.
SocialHistory.js works by exploiting the feature in modern web browsers that automatically uses a different link color for visited links. The JavaScript loads up a bunch of links from a list of top social media sites in an iFrame and looks at which have been visited based on the change in link color. From there, it can assume which you are most likely to use (or in my case, which I may have visited recently while doing research for a story).
Raskin notes that the same browser leak can be exploited using his bit of JavaScript to check out what other sites your users are visiting. You could ask SocialHistory.js to load up a list of competitor's web sites, for example, to see how much of your web site audience overlaps.
There are some drawbacks to the approach. For example, your users need to have JavaScript enabled (95% of people according to W3Schools), and the detection only works for sites that the user has visited recently (dependent on his or her history settings). Nonetheless, it is a clever way to clean up the badge overload on your site and find out a little bit about your visitors' surfing habits.
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/4072
Comments
Subscribe to comments for this post OR Subscribe to comments for all Read/WriteWeb posts
Hmmm... I don't know about this - creating a hidden iframe on the fly for each user and then loading bits of other sites into it? Seems a bit of an over kill to me.
Of course I am biased here, but I always felt that the buttons should not be on the page, they should be in the browser, personalized for each user.
Posted by: Alex Iskold | May 28, 2008 9:30 AM
The most interesting hack I've seen in a while!
Posted by: Wil Tan | May 28, 2008 9:37 AM
It is interesting, but I see beacon-like privacy concerns coming on.
Posted by: Tom Pimental | May 28, 2008 9:46 AM
@Alex it's only creating anchors ( tags) to the sites in the iframe, not actually loading the sites.
I agree that having the "Digg it" or "Reddit" buttons on the browser chrome is ideal, but not every user is a Flocker ;-)
Besides, aside from the "Share this" links, there are other use cases for badges so this is definitely a useful hack.
Posted by: Wil Tan | May 28, 2008 9:46 AM
What are the privacy concerns about this?
Posted by: wesley | May 28, 2008 9:53 AM
...but who will want to use your service after they find out that you've been spying on their personal browsing history? The deadpool awaits all who use this tactic!
Posted by: Marcello | May 28, 2008 10:00 AM
There's no privacy concern if the script isn't reporting back to the site owner. All it's doing is filtering which links you see by which links you've recently visited
Posted by: Slippy Lane | May 28, 2008 11:01 AM
A good example of why I selectively allow javascript
Posted by: Joffi | May 28, 2008 12:09 PM
Niall Kennedy brought this idea to life earlier this year.
Posted by: Jackson | May 28, 2008 1:47 PM
A bit sketchy...would browsers fix this "leak" in the near future?
From a purist perspective, this kind of problem is ultimately better solved with a standardized url prefix (e.g. mailto:)
Until then, clever hack!
Posted by: Q dub | May 28, 2008 3:46 PM
I agree with the idea that one should know one's target audience. What do the like in social media and then to go their to address them with your product offering.
Posted by: Faisal Riaz | May 29, 2008 3:58 AM
Launching a movie in theater and on dvd right after week or so will temper sales through Cinema houses. But good thing is that if any body wants to see the flick DVD or in Cinema, it is possible
Posted by: Faisal Riaz | May 29, 2008 4:12 AM
I saw a white-hat presentation at a security conference last year showing how this hack, combined with collecting email address, helps phishers target people. Substitute banks, brokerage and other financial institutions for social sites and you can see who people do business with. The bad guys combine that with collecting emails and then send targeted phishing emails based upon who you do business with.
The other thing they do is take user login information from their site combine it with this and try to break into accounts.
Perhaps the real story is about the security risks this kind of js script creates for end users.
Posted by: Alex Nesbitt | May 29, 2008 7:54 AM
This looks pretty neat, but you have to admit that the way it's done is pretty evil :)
Posted by: Farley Knight | May 31, 2008 1:07 PM
Horrible.
Posted by: Johnny | June 1, 2008 4:42 AM