This one is going straight in to the echo chamber. I doubt that anyone willing to put 10+ social media icons on their blog is prepared to hear this argument. Those of us who recognize how abhorant it is have already trimmed that list down.
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.
Although I think your point about design is very astute, I disagree with your assertion that those who need to hear this are lost cases.
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.
Not to mention if you care about the privacy of your users every share button is a little tracking device that probes into your users habits and pages visited. (Ghostery can help you see the extent of the tracking that is taking place)
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.
If you haven't already, check out "request policy".
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 )
It'll probably stop once this is implemented in browsers, so every article declares a basic set of sharable info, and the social buttons install themselves and read that info. Until then, every one is running in a sandbox, they'll never share info, they'll never allow an intermediary, and they'll all be competing for screen space and article install-base regardless of your existence on a network or the number of networks.
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.
Well, kind of. Bookmarklets you have to click to use, and perform a strange action to install. An integrated 'share' button could do more, like render those Tweet +1 Like buttons inline, and show if you've already <verb>ed it. And have an infinitely larger install-base; in my mind, this would be built in, and sites you can share to would register themselves with your browser, which would make it a one-click operation for people.
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.
I had the idea about 5 years back that it would be nice to share via the browser any kind of content with one's primary email contacts list. There could even be shortcuts or predictive text (like in Gmail when you start to enter someone's email address). Think of it like a box, much like the search box in Safari's top right corner where you could select 'article', 'video', etc from a dropdown and then start typing the email you wish, click send and violá.
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.
The URL bar is Deep Magick to most people, requiring rituals most foul and loathsome to work with, such as the forbidden incantation of Copius Pastious. Less than one in ten simple villagers understand such vile sorcery, and most of those can only use it via the Scroll of Copius Pastious conveniently inserted into the Word Ribbon by the Mad Monks of Microsoftine.
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.)
Good point! It seems that what would make most sense is to move the sharing buttons onto the browser, no?
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?
The "share" icon/menu-item is very common in Android applications too. Seems like the more modern apps and OS's are on top of this and desktop browsers just need to catch up. Firefox does have a "Send link..." menu item, but that appears to assume one means to use email... a somewhat dated assumption.
Yes, they are. They're in Chrome 19, if you're inclined to try them out, and the Chrome Web Store already has a bunch of extensions that use them. (Search for 'intents' or use the intent picker's suggestions)
On webpages, I've lately taken some glee in using RIP (the Remove It Permanently) plugin to permanently remove these buttons, and generally the entire bleeding div or iframe they're associated with, from the page and site.
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.
"Share via barcode" can be useful. Say you want to tell someone some contact info for you, but neither of you currently have any contact info on the other. If your phones have screens and can read barcodes, which I presume they can, no need for one of you to say some number or email address while the other types it in. One person just shares via barcode, and then the person that just got that contact info shares theirs back using that contact info.
Also, emailing or texting links to someone right there at the table with you contributes to needless inbox clutter.
I put those drasted things on my blog... and took them off when I re-did it. God forbid that I spend hours fine tuning the loading of my site only to have some facebook script take up 12 connections loading 6 different iframes into the client.
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.
It's a particularly irritating damned-if-you-do, damned-if-you-don't situation. Avoid using buttons on your site? Then, as another poster pointed out, you don't get nearly as many shares, and your page views go down. Use buttons on your site? They slow your page down and, yes, your page views go down.
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.
Personally, I don't care much about blog views. I write, you can read. If it helps you, great. I'm not out to make money with my blog and as such I couldn't care less about how many readers I have. I do, however, care a ton about how fast it loads and how competently it is built because that reflects entirely on me.
Those buttons do serve a very important purpose, which is to make it simple for visitors to share information. The problem is "website designers" crossing the line between providing the user with a tool to share information and just plain using that tool to "market" or "coerce" visitors into sharing.
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.
- click a button & sign in (if not already signed in), & click share
- 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".
It happens, there are people who will not share content because they have to (god forbid) open a new tab. But if the content is good enough, little to nothing will prevent people from sharing it. If your content is that catchy or helpful or entertaining, people will share it.
Exactly. You shouldn't slap a ton of these buttons on your site and assume your maximizing your sharing potential. The 3 share links I have on imgfave.com drive 10x the traffic of the addthis widget that I used previously. I tried using the facebook like button, but the share link I have on their now drives 15x as much traffic as the like button, even though it takes two steps to post back to facebook. Important to make no assumptions and keep testing.
I think you hit the nail on the head here. It's really about good design and placement of the buttons. The buttons themselves, however, are extremely important to the flow of information through different mediums.
I am surprised no comment mentioned the real obvious solution to this sharing issue: a user should not need to share based on the recipient, sharing should be based on the emitter. I mean, if I am a Facebook user, I should just need this share button. Then my friends on Google plus should see this share in their stream. Just like emails: the social content should flow freely and transparently between social content clients.
The social buttons are here to stay because the people in charge are desperate for traffic. That is the #1 reason, desperation. Sometimes they end up including them 2 or 3 times on the same page. We can thank people like mashable and huffington post for the bad habits.
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.
Assuming /etc/resolv.conf is set up with "search <localdomain>" before any nameserver entries (which it invariably is), then any DNS query will first try the localhost.
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.