Category Archives: Industry

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

Hands-on device testing

Naga IT Services
Filed under: Industry, Projects

One of my side projects is the Nomad Device Lab. It’s an Open Device Lab: a shared community pool of internet-connected devices that’s free to use for testing purposes by web and app developers. If you do a Google image search for device lab, you see a lot of walls of devices. For me, this feels a bit off.

Having all the devices on the wall is okay for testing layout and general functionality, but it misses a bit part of the testing: the user experience.

One difference is the physical experience: how you hold and interact with the device. Tapping a phone mounted on a wall is not the same as the more usual use case of using it with one hand and one thumb.

Another difference is performance: the speed of the site. Even though phones and tablets (and many other types of internet-connected devices) are getting faster, they’re still slow compared to their laptop and desktop counterparts. It’s hard to gauge just how slow when you’re looking at a wall of devices all updating.

Although I’m a big fan of apps like Ghostlab and tools like BrowserSync (which I use a lot), taking the time to sit and play with your sites manually on a range of devices really lets you feel the pain of loading and interaction times.

Getting into Sass

Naga IT Services
Filed under: Industry, Process

I’ve been discussing Sass, the CSS pre-processor, with a few fine folk over the past couple of days, particularly the “should I use it?” angle. Here’s how I got started, and why I stuck with it. The short version is: it helps me write more readable and understandable CSS.

I decided to make one change at a time to my normal CSS workflow, over the course of a couple of weeks. I chose Sass over Less or Stylus (other CSS pre-processors) because it looked a bit friendlier and there were more resources for help available, based on some quick googling.

Compile a simple CSS file

The first thing I did was to rename my style.css to style.scss and get that to compile. No using of any Sass features: just seeing if I could make a CSS file from a Sass one. (What did I use to do this? See practical concerns below).

Variables

The next thing I looked at was using variables. Rather than having hex codes like #6B0000 scattered throughout my code, I had $primary-colour and $secondary-color. This made the CSS more readable, and made it start to feel more like “real” code: variables and things!

Nesting

Next up was nesting. If you’re styling a link in a navigation list, you might write a CSS selector like this: nav ul li a { /* styles */ }. Sass lets you write those selectors inside each other for much better readability.

I try and write CSS in a SMACSS style, so I wanted to avoid that kind of deep nesting, and using of specific HTML patterns. Something like .nav-main a is kind of okay, so I used nesting there a lot.

What I did find really useful was being able to nest media queries. Rather than having many media queries throughout my CSS, and I could keep all the changes over screen sizes for a particular element in one place. Here’s a short example:

The css:

h1 {
  font-size: 2em;
}

@media (min-width: 30em) {
    h1 {
        font-size: 2.5em;
    }
}

@media (min-width: 60em) {
    h1 {
        font-size: 3em;
    }
}

The sass:

h1 {
  font-size: 2em;
  @media (min-width: 30em) {
    font-size: 2.5em;
  }
  @media (min-width: 60em) {
    font-size: 3em;
  }
}

Shorter and, for me, much more readable.

Partials

The next change I made was to use partials. Regular CSS lets you use @import to pull in another file. This is not great because it means another file to download. Sass does the cunning thing of letting use you @imports to pull in files, but it does that as it compiles, meaning you still end up with one CSS file at the end.

I want to split my CSS rules into base, layout, normalise, typography, and other categories, to make the code easier to read. Rather than have one long CSS file with comments to split it into logical pieces, I have separate small Sass files: much easier to find existing stuff and know where to put new stuff. Sass let me do that using partials: start a Sass file name with an underscore, and it won’t get generated into a CSS file; use @imports to include the partials in my style.css.

Practical concerns

When I was getting started with Sass, I found the command line scary. Actually, I still find it scary now, even though I use it every day! At the moment I’m using GulpJS (a JavaScript task runner: write little bits of JavaScript that let you automate things like compiling sass (and a whole bunch more)) or building things with Jekyll (a static site generator that handles Sass compilation for you), but for a long time I used CodeKit, and I still highly recommend it. It does many awesome things.

But wait, there’s more

These days I’m looking at fancier stuff too. There’s mixins for having little functions, @extend for grouping of things (although now it seems that maybe @extend isn’t so great), and susy for easier grids.

Summary

I find writing Sass easier and more fun than writing straight up CSS. I got into it by changing one thing at a time, and learning Sass in small chunks: variables, then nesting, then partials. There are many command line tools, and a handful of apps to help get you started.

Gathering stats and Herding Cats

Naga IT Services
Filed under: Industry, Projects, Talk notes

On Thursday 5th February, I gave a short talk at the Cape Town Scrum Users Group about RailsBridge.

gathering-stats-and-herding-cats

My slides are up on Speakerdeck. I talked about RailsBridge itself (the upstream organisation and how our Cape Town chapter came to be) and the Cape Town team’s focus on Continuous Improvement. I talked about the various methods we’ve used to gather feedback (and how successful or not they were), what feedback received, and what we did with it (lots of things!).

I’ll be giving a remixed version of this talk at the Cape Town Ruby Brigade in March, where I’ll focus more on the Ruby and Rails bits, and the curriculum.

(Yes, me doing all this Ruby stuff is slightly odd, since where I work now (Praekelt Fuondation) is a Python shop. Vumi, for example, is all Python. ¯\_(ツ)_/¯ )