When Will The Social Sharing Button Madness Stop
craigagranoff.com
craigagranoff.com
This disconnect stems from the difference in a core belief about design and motivation. If you believe that sharing is driven by the mere opportunity to do so, you're going to bury your blog in this stuff. If you believe that good design sells itself, you'll prioritize good design in the belief that sharing will follow naturally. This is the argument that must be made.
I have seen some insanely huge, hover as you scroll social sharing panels on blogs of people whom I consider to be luminaries in the field of technology and design. Maybe it's a case of outsourcing the blog design or using templates just because they are there... Let's face it: slapping together a Wordpress template plus Disqus comments and some other frills then calling it 'web design' is all too common these days.
I think that getting some dialogue going on the topic is very worthwhile and I ask that people like yourself, with such astute observations on the topic not take the shoulder shrugging stance and speak out.
I get really mad at share buttons because there's no way to know beforehand if you are going to get to a page filled with those.
From observation I came to a simple law about these share buttons: the amount of content is inversely proportional to the number of share buttons on the page.
You could also use noscript or disable third party cookies in browser settings if you really don't want social media buttons.
It's a plugin I'm using in FF alongside noscript. It makes browsing kind of noisy, but educational. As with your observation about 'like' buttons, I notice the more craptastic sites often try to pull content from 10+ other domains. ( Request policy stops these cross domain requests until approved )
https://addons.mozilla.org/en-US/firefox/addon/requestpolicy...
I, for one, find it crazy that I can Like and maybe +1 a blog entry, but I can't Pinboard it or ReadItLater or Orkut it without the site implementing those buttons, despite them all doing roughly the same thing with roughly the same data.
Perhaps this already exists in some form. Perhaps a Pocket for your friends where you put things on a secondary reading list of theirs so as not to get confused with their own list.
Facebook's open graph tags are everywhere (you kindof need them to make "like" work properly), and what you're describing could be implemented using a javascript bookmarklet that read the tags.
But yeah. Pie in the sky. This would require Google and Facebook (aka, The Internet) to give up absolute control over all that information, which they'd probably fight unless it can demonstrate some other kind of gain.
Mobile Safari does a great job of this with the bookmark/mail link to this page/add to home screen/etc. button, heck even Twitter is catered for as of iOS5. Maybe if desktop browsers had similar functionality we'd see less of this noise on the page.
Good deal that too: get the crud off the actual page and sacrifice but one toolbar button that (like the search bar) has a pull down with all of your selected networks. That makes it more elegant in appearance and opt-in by default.
...seems so obvious, maybe there are already extensions for this?
Less sardonically, even techies seem to get their share-this-with-people neurotransmitters activated by seeing sharing widgets. Its a call to action. People respond to those. My subjective experience back when Delicious buttons didn't suck was that for two roughly equivalent pieces of geek-friendly reference material putting the Delicious button on was worth 10x Delicious saves.
(I hate all the other buttons and rarely use them. That might well be irrational -- I've heard on HN from folks at e.g. TechCrunch that they're worth measurable money to the business.)
On my phone (android), I'm aggravated every time I want to mail a URL to myself or someone else, as it's menu -> more -> share page -> select one of the THIRTEEN share options, including "Share via barcode" (WTF!?), and finally be dropped into my email app. Compare with scroll to top of page -> highlight url -> copy -> home key -> email -> compose. One more step but far less fussy navigation.
And no, you cannot pick a default that will persist for future iterations of the action.
On a desktop, it's a really simple double-click URL -> terminal -> type "mutt" -> paste URL. When doing stuff that is repetitive I've even written short bash functions to, say, mail myself Craigslist postings, including the URL, the body of the post, and using the post title to write the mail subject line. Trivial.
Yes, the SN crap is madness. Usually a good sign the end is near.
Also, emailing or texting links to someone right there at the table with you contributes to needless inbox clutter.
Buttons make your site slow. The only button I have on my site is a twitter follow button. And I kept that in there, begrudgingly, because it waits for onload before it starts downloading all of its crud and is a one-off cost.
My experience is that with tweaking and sane numbers of buttons, b) costs you less visitors than a), but it's still a pain in the posterior.
I run a few sites and I know first hand these buttons are used. What I'd like to see are A/B tests on the various button layouts and designs to show their affects on sharing.
Isn't it simple enough already? I mean, can you see a case where a visitor is like, "Man I'd love to share this post on Facebook, but opening up Facebook itself is just too much trouble."?
Pick one:
- click a button & sign in (if not already signed in), & click share
OR
- Find the permalink of the information you want to share (not always obvious to people. e.g. the links my mom sends me via email), open the service you want to use to share, log in, navigate to the area of the service responsible for sharing information, paste the permalink, click share.
The buttons not only make it more easy and convenient they add a suggestive quality. Especially if the buttons include # of shares indicating a form of popularity.
So no, it's not a matter of something being "too much trouble" or "easy enough already". It's much deeper and if you really knew people well, you'd know there is no such thing as "easy enough already".
The low-down is that you install a bookmarklet and add some contacts. When you want to share a page, you click the bookmarklet, select the people you want it to go to, and click share. That's all.
The recipients don't even need a YourPane account, they just get an email saying that you sent them a link. It's basically very streamlined link emailing.
That doesn't really solve the problem. one is one too many.
I believe Firefox tried to solve this problem, but it didn't go anywhere. It seems logical that a standards based browser solution should be adopted across the board, but ....
I've seen this in some places, but my pet peeve with those is that they usually open up on mouseover, but then don't collapse on mouse leave. IMHO, they should be click-activated ONLY.
Perhaps in a few years the madness will stop and people will focus more on fast loading websites, good content, and a good user experience.
Or maybe I'm wishful thinking.
The buttons are here to stay because people want traffic and _buttons measurably increase traffic_.
I hope that they get faster and more friendly, but until they stop providing a traffic boost, bloggers will keep using them.
https://monzta.maltekraus.de/adblock_social.txt
...as a filter subscription in Adblock Plus and you'll stop seeing most of these sorts of "share" buttons.
Hit the big boys like Facebook (once, please), G+, Digg, etc.
No offense, but you lose some credibility mentioning Digg next to Facebook and G+.127.0.0.1 facebook.com
That said, I use the same technique. :)
Redirect at will.
In the absence of a nameserver on the local host, then the DNS lookup will search /etc/hosts, where it will find an entry for facebook.com that resolves to 127.0.0.1 (localhost).
Now the browser knows where to find facebook.com. It requests the web server at localhost to serve the URL. If there is no webserver, the browser gets back a "connection refused". If there is a webserver, the browser gets back a 404 error.
In either case, the browser just moves on to the next request.
Since it all happens on localhost, it is blazingly fast compared to an internet lookup, and the user won't realise.