Let's talk about social sharing
The introduction to set the frame of reference and get the people living under a rock up to speed with current events: social sharing is ever present, them mainly being Facebook, Twitter, Pinterest, Google+, LinkedIn. I regard everything else as a runner up, mainly because I really do not come into contact with anything else on my day to day activities, and we do work for a large variety of clients.
These clients have clients themselves that they want to interact with in such a way that it will affect their bottom line: whether it's providing awesome support on Twitter, running competitions on Facebook, tooting one's horn on Google+ or bragging about that awesome thing they made on Pinterest. The necessary side effect of all of this is the social sharing buttons on their pages. These things:
And
TL;DR version:
Please use the box standard brand assets that the social media companies provide. I know you're an amazing designer, but let's save the users, the developers and the industry at large.
Please.
The concerns
Now you, as a designer, a client, or even a developer might think that the design of these things should match your site's design. I mean you just spent a sizeable ammount of cash on the redesign of your website, it's only fair that the social sharing buttons play along, right?
To an extent yes. But let's consider the following.
Brand identity
Let's suppose you're Facebook. You have developed a platform that over 1 billion people on the planet use. You are known. They know that that hue of blue is "yours", and that the letter "f" in its form means the company. People recognise you. You have brand value. You have spent years perfecting the design, and have invested $$$ making sure that that design is consistent across every facet of the Facebook experience: the main page, the iOS app on iPad, the iOS app on iPhones, the Android apps, the help pages, the developer's resources, the printed material, everything that appears about you in any sort of printed or digital media. It would be nice if when people used your like and share buttons, they would look the same, in line with your design.
Let's flip the coin. You have a new company called Trader Bill's Awesome Emporium, and you have spent £2k on a new logo. You would WANT that logo to appear EXACTLY the same EVERYWHERE. Sounds reasonable, right?
Right, let's move on.
Because of this exact reason, every big company, ever, came up with something that's called Brand Guidelines. Here's the five:
Amongst other things, all of those pages go into a lot more detail on the why and the how. Short story is: there are certain ways that the assets can be incorporated. That brings me to the next topic.
Ambiguity
One of the reasons these brands want to control kindly ask you to use their assets they want is to remove guesswork. There is a blue box with a white "f" in it. Awesome. What does it do? Does it uncover a "Like" button if I hover over it? Does it just tell me this site is somehow present on Facebook? Does it link to the Facebook presence? According to the guidelines, it should link to the Facebook presence. Simples. Done. Guesswork removed.
That means, in an ideal world, if you encounter a blue box with a white "f" in it, it would ALWAYS link to the Facebook presence of the thing you're on.
A "Like" button would always like the page in question, a "Share" button would always share the page, etc. You get it. Use the assets they were meant to be used for.
The same principles apply to Twitter, Pinterest, Google+, Linkedin, etc.
"But they look ugly"
Um, yes. Out there someone thinks your logo looks ugly. It is still your logo, you love it, it's been your business' public facing icon for months / years now. People know it. People know what to expect from it. People know how to behave when seeing it, and they know what to do.
Make your developer happy
This is my favourite part, being a developer myself. Because social media companies need the integrations as much as you need the people who are on social media, they made it supereasy to embed these plugins. Hell, there are even aggregate solutions that you can use to embed a bunch of them in one go (looking at you, AddThis!).
If you're working with a developer, you probably know that their time is money. The less time they spend doing something, the less it costs. That usually means the total cost of your website / app / whatever goes down, or they will have more time allocated for nice-to-have functionalities that would make your thing pop.
Let's suppose you ignore all of that, and still decide to go with a custom designed thing. Introducing:
Technical limitations
So most sharing buttons use JavaScript to load themselves on to the page. That JavaScript then dynamically inserts an iframe into the DOM where the JS is, and a Like button appears. Magic. Some social widgets allow you to use iframes directly, and sometimes you can find links that have query strings attached to them.
"Redesign that like button. I mean those are just DOM elements, all you have to do is apply a bit of CSS, am I right?"
Uh, nope. Technically, CSS can not reach into an iframe. End of story. There's nothing I, or any other developer can do about it, it's how the spec and the browsers were implemented.
We can still reach into an iframe and mess about its innards using something like jQuery, but do you really want to have your code adding / removing / reordering / modifying DOM elements inside an iframe? And then do the same with inline styling on those elements? That thing is pretty resource intensive, and while that might work really well on a fairly recent computer, viewing that same page on a mobile device, even on a Samsung Galaxy S2, will cause it to hang. The processor in those devices aren't meant to handle the pain you're throwing at it.
But okay, you did that. Then you wake up one morning, and everything is broken. Nobody touched your code. What changed is the content within the iframe. Because you're loading it via JavaScript, the iframe will always be the latest release version of whichever social media giant you're dealing with. That means their developers will change / optimize / remove / add stuff. Stuff that will no longer match what your code wants to do, so only half of the changes will happen resulting in ugly buttons. You panic, call your developer, and he will most likely do this on the other end of the line: ¯\_(ツ)_/¯. Not his code. Has no control over it. Will charge you by the hour to reimplement fix it.
If the social sharing thing is a link however, go nuts! The viewport is your canvas!
Anyhow, short of that, we could write our own widgets. I mean those social media things have APIs, right?
Yes, but not quite.
Let's suppose you want a custom and aggregate display of all your followers from Facebook, Twitter, Google+, Pinterest and LinkedIn. This was a real world task, something I had to do and ultimately failed. These are things I learned along the way.
APIs are good if you want to do advanced functionality. If it's something simple as a like event, you will be running into trouble. Twitter, Facebook and Pinterest will give you the share / like count from a client side (browser initiated JavaScript AJAX event (look at them clever words!)), LinkedIn will only talk to you from server side, and Google+ will not give you the share count. These two are things I have zero control over. None. No matter how pissed off the client is, I simply can not do it. No aggregate count for me. :(
Initiating an action is even more problematic. I mean sometimes you're lucky, and you can get away with a query stringed link, other times (such as Facebook), you need to enable developer access on the client's account, log in, create an application (or ask the client to do that, but that world is scary...), get the tokens / codes, authorize the dev server (don't even think of allowing localhost. Facebook will not have it), then create the code for the actual event, test it, test it again, find out you can't actually do it with the API, launch, log in, authorize the live site's domain, rinse and repeat for all the others.
This takes an enourmous ammount of time. I've tried estimating, but estimates are just that: they do not take into account stuff you don't know you don't know, and your 1 week estimate grows to "abandon after 2 weeks over budget" or "3 months". Easily.
If you'd only use the things they gave you. Copy code, paste code, move on to next functionality 5 minutes later. Chat up sexy secretary.
Security
An added amazing side-effect of using the provided assets is security.
Let's suppose you have a custom like button that infringes on the brand guidelines of Facebook, but let's put that aside for a second. How do you, as a visitor to that site, know that when you click that button, what you expect to happen is going to be the same as what actually will happen? How do you know that your click won't be hijacked? How do you know that you're not giving the site overly broad permissions to your profile with the click of a button (fairly easy to set up with extensive knowledge of the API and a bit of omission of information). Yes, it would be illegal, yes, can probably go to court, but hey, if they host in the Maldives, good luck finding them. In the meantime, because you gave them permission (and the API doesn't care if you've been lied to), they will post spam on your newsfeed, which could get YOU banned from Facebook. Amazing world we live in, eh?
Note that this scenario probably will not happen, as Facebook will tell you what permissions the app requests, and you can still say no, however raise hands if you've ever read an EULA. Or double checked what permissions the app needs on your Android phone. Or cursed Farmville for spamming your friends. People mindlessly trust strangers, and will click "Accept" or any variation thereof to get to the promised thing.
