Author Archives: Steve Barnett

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.

Work in Progress, Context Switching, and other things

Naga IT Services
Filed under: Process, Productivity

At the moment I think I’m doing quite well limiting my Work In Progress: just working one thing at a time. I’m not doing so well with Context Switching: I’m being moved between projects quite quickly, and I feel like my work is suffering as a result: works feels unfinished, or of a lower quality than I am happy with. Here are some articles that I’ve been reading on the topic.

Limiting Work In Progress

The excellent Personal Kanban site has a “Why Limit Your WIP” Series. In PK Basics: Why Limit Your WIP Series, they talk about What Happens When We Don’t Limit WIP:

Our attention to detail suffers, we leave things unfinished, or compromise the quality of our finished product. All of these outcomes create more work or us in the future.

An excellent way to demonstrate the power of limiting WIP is the Aeroplane game. Karen and Sam of Growing Agile have an excellent write-up of it here: Aeroplane Game.

On Slack

From Slack: Why Limit WIP Series, Post 3:

We need slack for our own optimization. In our work, we’d like to have a degree of slack to:

1. Make sure we are able to focus on the tasks at hand;

2. Make sure we have the capacity to deal with unforeseen events;

3. Make sure we can stop periodically to allow our brains to perform vital functions in memory, processing, and regeneration; and especially to

4. Make sure we don’t work ourselves into an early grave.

On Medium, Marie Poulin talks about slack from a designer’s perspective. She talks about adding margins to leave room for error, growth, planning, and reflection.

The always excellent Alexander Kjerulf writes about slack in his post Why every company needs to give employees Free Time on the job, and includes some practical tips on how to get started.

On Context Switching

Back in 2001, Joel Spolsky talked about task switching in Human Task Switches Considered Harmful:

The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming.

More recently, in The Multi-Tasking Myth, Jeff Atwood talked about distraction and multi-tasking:

We typically overestimate how much we’ll actually get done, and multi-tasking exaggerates our own internal biases even more. Whenever possible, avoid interruptions and avoid working on more than one project at the same time.

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.

Organisational change: sketchnotes

Naga IT Services
Filed under: Books, Process

Over the weekend I reread bits of Designing for Performance by Lara Callender Hogan and Lean UX by Jeff Gothelf. I looked specfically at the bits about organisational change, and made some sketchnotes, which are posted below.

dfp-1

dfp-2

dfp-3-lux-1

Then I went through these sketchnotes a few times. Each time I went through with a different lens, and made a list of things to do. I started on the list today. Let’s see how the rest of it goes.