Social sharing buttons

Naga IT Services
Filed under: Industry

I don’t like sharing buttons. Here’s a short Sunday afternoon rant about why.

Very low share rates

Shares as a percentage of page views seem to come out at less than 1%. That’s shockingly low.

The UK government did a great write up of their analysis of some of their stats: GOV.UK social sharing buttons: the first 10 weeks.

The always great Luke W has gathered a bunch of data together: What Percent of Page Views Share on Social Media? All of them shown share link clicks at less than 1%, the average being about 0.25%.

Share icon code tends to be bad

On top of that, the code for sharing icons tends to be quite a lot of JavaScript. This mean a heavier, slower, page, and a worse user experience. Philip Walton wrote about this in Stop Copying Social Code Snippets and Jonathan Suh did in Responsible Social Share Links.

There are lightweight alternatives out there, like Kurt Noble’s Ridiculously Responsive Social Sharing Buttons, but many people still use the heavier defaults provided by Twitter, Facebook, et al.

Sharing without reading

The final kicker is covered in You’re not going to read this (But you’ll probably share it anyway) on The Verge. Even when someone shares an article, it doesn’t necessarily mean that they’ve read it.

It depends what your goal is, of course. Do you just want more page views, or do you want people to actually read and take in the content? For the kind of thing I do at my workplace, we’re more interested in the latter.

Further Reading

Don’t rely on JavaScript for key functionality

Naga IT Services
Filed under: Process

Inspired by seeing Everyone has JavaScript, right?, I decided to make a similar list to remind myself of all the reasons why it’s a bad idea to rely on JS (JavaScript) for key functionality.

The Request Fails

The first level of failure is the request for the JS file. Sometimes there’s a problem on the network and a request fails. Sometimes there’s a problem on the server (perhaps your CDN), and the request fails. Sometimes the user is behind a corporate firewall and a particularly eager sysadmin has blocked access to JS files.

This is made worse if your file is particularly large (easy if it’s not been minified), or if you have multiple JS files.

JavaScript is loading

As Jake Archibald says “all your users are non-JS while they’re downloading your JS.” The network can be slow: your users might be on a crappy mobile connection or a throttled ADSL connection.

Couple that with the fact that JS parse times can be slow for large files, especially on mobile devices, and some users will be waiting a while before they have all your JS.


If your users have any browser extensions installed (such as AdBlock), they may inadvertently interfere with the execution of your JS. If your page has any 3rd party JS, such as ads or tracking, they can also interfere with your code.

Errors in your JavaScript

As much as we might hate to admit it, errors creep into everyone’s code sometimes. Yes, even yours (and definitely mine!). It’s probably more likely that your user will be served broken JS than not served your JS at all. JS is brittle and fault intolerant: one mistake and your code goes boom.

Browser Support

Even if you’ve managed to pass all the hurdles above, you still have one more: Browser Support. If the user’s browser doesn’t understand your JavaScript, if will throw an error. Tools like and Modernizr can help you figure out what browsers will support the code you’re writing.


Depending on JavaScript for key functionality could mean stopping your users from achieving their goals. There are a lot of things that could wrong! Your JS file might not reach your user, it may not load quickly enough, it may get messed with, it may have errors in it, or you might be using a feature the browser doesn’t understand. Building with Progressive Enhancement means that they’ll still be served a usable experience when things go wrong.

Testing for feature support (for example, by cutting the mustard) lets you serve a browser only the code that it will understand. Conditionally loading your JS file based on passing that test (for example, using Filament Group’s loadJS) means that you won’t waste your users’ data by sending them code their browser can’t use.

Notes on Show Your Work

Naga IT Services
Filed under: Process, Projects

Over the weekend I read Austin Kleon’s Show Your Work. The book is about getting discovered and self-promotion, but I picked it up with a more general vibe in mind. Skimming through the preview I was hoping I would get some nuggets of good advice by reading it, and I wasn’t disappointed.

The book is divided into ten sections:

  1. You don’t have to be a genius.
  2. Think process, not product.
  3. Share something small every day.
  4. Open up your cabinet of curiosities.
  5. Tell good stories.
  6. Teach what you know.
  7. Don’t turn into human spam.
  8. Learn to take a punch.
  9. Sell out.
  10. Stick around.

Show Your Work sketchnotes - page 1

Early in the book, Austin talks about collaboration and connections, in the context of being part of a group. I really dig this because that’s how I feel about all the meetups and things I’m involved with (CTFEDs, SPIN, RailsBridge. I loathe the term “networking,” but I do really enjoy hanging out with smart people, and talking about interesting things.

Other themes in the book were things like honest, openness and vulnerability: humans like connecting with other humans.

I also enjoyed his discussion around sharing something small every day (even though I mostly fail at doing that!): over time, doing lots of little things can add up to a big thing.

Show Your Work sketchnotes - page 2

Having recently read Sharon Bowman’s excellent Training From The Back Of The Room, I really liked the section in Mr Kleon’s book on teaching what you know. He talks about how, by teaching other people what you know, you learn things yourself.

Perhaps the biggest takeaway from the book for me was the section that explains why sharing your work won’t put you out of business: quite the opposite in fact. I’ve had many arguments with people about this before. I’ve mostly tried to talk about how there is plenty work to go around and that it’s on a continuum (my clients aren’t necessarily the same as your clients). I’ve also tried to talk about how keeping things secret doesn’t work. If your only value to the client is that secrecy, then your business won’t last long.

Mr Kleon talks about how knowing the technique is very different from mastery of it. The various activities of User Experience are an excellent example of this. Usability testing has very simple steps (or so it seems): find a person, watch them use a product, and take notes. Doing it well is another matter entirely: who do you find; what tasks do they do; what do you ask them (and what do you not); what things are important (and not); how do you interpret the results? That knowledge only comes with practice and mentorship.

I guess it’s not surprising that nowadays I find myself working on Open Source projects like Vumi and Universal Core.

Show Your Work sketchnotes - page 3

One last thing I took away was to “find my knuckleballers” – the people who share my mission and principles. For me, that’s focusing on Progressive Enhancement. I want to always be mindful of the worst case scenarios and build things that will work on bad connections on hostile browsers. I want to build things that work when JavaScript fails to load, things that load fast and don’t cost the users lots of money.

It seems that there are very few people like that in Cape Town. Justin, Alex, and Rich are people whose work and principles I hold in high regard.

Show Your Work sketchnotes - page 4

Two quick front-end performance-related things

Naga IT Services
Filed under: Process

At work I’m doing some researching and setting up of things to help improve the front-end performance of our stuff. Here are two quick things that keep bubbling up.

Prefer fewer, larger, files

Avoid many, smaller, files.

This is because, broadly speaking, latency trumps bandwidth when it comes to performance concerns.

Prefer simple CSS selectors

Rather have an extra class in your HTML.

This is because browsers can figure out simpler selectors faster.