As mentioned in the project description, this is a fork of the solution presented by the German magazine c't a few years ago. Since then they came up with the successor Shariff, which is also able to display the number of likes and shares.
My company works with a lot of active duty US military personnel and when I was starting out in our Helpdesk almost all of our military customers used government issued computers to use our product. These guys and gals all used IE because that is what they had. I don't know if the government only allows IE or if they just don't have the privileges needed to install anything else but this is why we unofficially support IE still.
We also had a lot of customers who didn't know that the internet existed outside of "the blue 'E'". With those ones I usually helped get Firefox installed.
Has anybody ever measured the impact of share buttons? Do users really share the page more often when those buttons are present? And if so, how much more often?
To me it seems like this function is not something the page should provide buttons for. Just like it offers no buttons for saving, bookmarking, printing, resizing, scaling, scrolling etc. That is stuff you do with the page. Not something the page does.
I did click tracking on major Canadian websites such as Sportsnet.ca on these buttons (and everything else); we found that they're very rarely clicked and removing them would mean a completely insignificant change in the number of shares.
People do of course share those articles, but they don't seem to look for or trust web page share buttons. Even I rather copy/paste the URL into Facebook myself while on a desktop/laptop, or use my browser's built-in sharing functionality on a mobile device. This is all anecdotal but also based on data from hundreds of millions of page views.
Me neither! Especially when it's a Like button, it's not at all clear to me what that will actually do. That post doesn't actually exist on Facebook; perhaps it's linked to from there? So it'll have me "like" some unknown Facebook post that's associated with the article I'm reading? Which Facebook page will have posted that actual post? Etc. Uncertainty about what a button will actually do is a huge deterrent for users.
You're right! If current phones that had a persistent share prominently in the UI came first then this trend might not have happened. But it started with desktop browsers where this concept didn't really exist.
> But it started with desktop browsers where this concept didn't really exist.
Correct, mainly because "normal" users didn't know how to copy/paste URLs or didn't bother to, supposedly. If desktop browsers had gone in the right direction, they'd have added a "share:" scheme (similar to "mailto:").
Even then the browser would still need to know to which websites the user could share. The user would first need to select websites and services they want to use.
In the past, desktop browsers kind of tried to provide such features with the concept of the bookmarklet [1]. The idea was that users would drag&drop a link to their bookmark toolbar to add functionality to their browser. I think it is still used by some Read-It-Later style collection services, but mostly has been replaced with browser extensions.
> Even then the browser would still need to know to which websites the user could share. The user would first need to select websites and services they want to use.
They managed multiple search engine options just fine and mobile browsers implemented sharing without issues. I don't see a pressing need for user configuration (websites with share buttons don't allow this either), it would have meant potential additional revenue also for Mozilla & Co.
OTOH, they failed to fix "mailto:" for webmail ...
I measure them and they do work. Email is clicked the most by users, but Facebook provides the most traffic back to the site. The native sharrow (on iOS) doesn't mean anything to older users, but a Facebook/Twitter/Email icon does.
GET requests and web scrapers. Many a DB has been corrupted due to incompetent web devs not understanding http verbs.
(In this specific case, it will most likely only ruin analytics. However, it's a good habit to use POST when you don't want automated access. E.g. if the social media also didn't implement their end properly and used GET requests for submission, the bot or crawler or whatever will fall through two layers of checks and your social media may be filled with gibberish, this scenario is however mostly theoretical. In general, you don't want a URL can modify state related to your core business logic. See HN's infamous "This Submission Upvotes Itself")
One slight difference however is that on Facebook you have to use the 'share' button versus using a 'like' button. In some ways I feel like a share is more meaningful than a like due to the extra step involved.
It uses plain links (no JS) for the social buttons, and writing that article was actually what urged me to remove social buttons from my site.
Shariff is cool, but there's really no reason to use JS just for some social buttons, so what I ended up doing was just using its CSS and visuals and nothing else. This has been working very well, the buttons are fully functional (even with JS off!) and quick to load.
Hm. I've been in the practice of figuring out plain old URLs to use as hrefs for social share. No JS. No loading of images or other content from the third party social network.
This, when it is doable, of course provides no tracking (until/unless a user clicks the share button anyway) with no need for "two clicks" -- the remote site receives no network traffic at all unless you click the button, it's just an ordinary static link.
I have generally been able to figure this out for major social network sites, either from documentation, third-party documentation, or watching HTTP requests made by the 'official' JS solution. I guess it's possible it violates the "ToS" of the remote site to do this, although I'm not sure ToS can really restrict my linking to the site with a URL. I guess this technique could be more subject to breakage, if the remote site changes it's URL patterns, and the "official" (JS/tracking) solution from the remote site is updated, but I'm not using that.
So there are potential downsides -- but I'm curious which of them (or something I'm not thinking of) leads people to a more complex (and slightly worse UX) solution like this, instead of just using static URLs.
Oh, is that why people dont' want the plain links, cause they want the 'modal' popup within their site for the share? OK, that could explain it. Obviously `target="_blank"` is an option, but not quite the same indeed.
Fighting JavaScript with more JavaScript seems like a losing proposition. You can just make all the links be static links. I did this will a server side redirect so I could still track clicks:
It just needs a stylesheet and vanilla JS - so no dependency on jQuery and node.js, no build shell script required, and makes no external HTTP requests (uses simple SVG icons embedded in the JS).
If you've decided that the passive surveillance which social media companies perform on your page is an invasion of your users' privacy, wouldn't it be even more respectful of those users to avoid having share buttons at all?
We made the decision to use non-JS share links for a couple reasons.
One was to speed up the load time of the site, another was to limit social button tracking all users for the sake of the very small minority of users who use them.
Our reason for keeping them was that people were sharing/saving anyway and this gave us a little more control vs something like the Pinterest browser plugin which users might use to save/share.
Can someone explain why there is a need for the "double-click" solution? Can't one simple have a row of fontawesome-based social media buttons with links to their respective share URLs?
I feel like the solution to that is to fetch those numbers server-side and cache them, then present them statically to the user. No tracking, no JavaScript, no cookies, it just works.
I ask as someone who legitimately doesn't know (don't use them so haven't read), but does that violate the various social networks' dev terms? I've heard that Facebook and the like won't agree to you capturing Facebook data (messages, posts, etc.) in such a manner. Not sure if metrics are fine or what.
Compared to the effort of... you know... building an entire website, this seems like a tiny bit of effort. Is it really that hard to add three lines of server code to serve some content statically? Are we seriously saying that ANYTHING even trivially complex HAVE TO happen on the front-end, even if it means tracking all our users?
Come on. Surely there's like a plugin to Django or whatever that could do this. You're serving the dang article from some database with some server logic, after all.
This is a common engineer's problem. You're missing the point.
Convenience is a massive selling point. It's the same reason Dropbox is a thing rather than "hurr durr build your own FTP server, it's cheaper and more effective".
Sure, it's cheaper. But count the 2 hours you have to spend debugging and making it work, then maintaining the server...
Personally, I have other things to spend time on. Things like, you know, building a product, rather than maintaining a contraption that fetches social stats from the very convoluted social APIs.
Ever tried to get your Instagram follower count via their API? Good luck doing that without access tokens or some hack.
I get the point, but I don't think the analogy holds. Dropbox is a consumer product, so of course convenience counts for a lot. But using Dropbox on your personal computer doesn't expose anyone (except maybe yourself) to being tracked by advertising and social media companies when they don't want to be.
This is maybe just me, but I believe that as engineers, we have a duty to consider ethical ramifactions of the things we are building. Saying "I'm going to do the easy solution, and I don't care about what kind of tracking I'm exposing my users to" shouldn't be acceptible behaviour any more.
We do have a duty to consider the ethical ramifications of what we're building.
But I won't spend hours of engineering time building a share button system because there's other priorities. Say spending that time building a "delete account" button.
There's other more relevant ways to build privacy conscious features than to focus on a share button.
Also, you underestimate share button providers by saying they aren't a consumer product. Your average WordPress user doesn't know (or care) about building share buttons.
This got to pole position on HN, then some mod flagged it as spam,
It’s spirit was relevant then, and it’s spirit is relevant now.
Fully GDPR compliant.
This is ironic. You want people to share your content on social media but you don’t want social media tracking which is the entire business model of the very social media you are supporting by encouraging sharing. Whatever happened to sharing by email?
That’s like selling guns while complaining about bullets.
1. Social Media has become a necessary Evil if you are in the marketing of any kind.
2. I don’t care about the business model of social media sites as that is not my business, I am happy just to provide the options for readers to share if they care and I use a simple sharing (without tracking).
> for example against a dedicated attacker with a botnet
Do you have experience with this? My understanding is that there's still trivial work arounds (See chrome extension "Buster") or services where you pay to have a human go through it for pennies.
If somebody is targeting your site then your captcha will be useless no matter what.
https://github.com/heiseonline/shariff