The collected witterings of Rich Archer

Why you need a CSS component library

rich@richarcher.co.uk (Rich Archer) — Thu, 08 Sep 2016 12:52:00 GMT

I’ve gone off on one before about the why’s and wherefore’s of being more intelligent about your CSS architectural choices, so I’ll save the long chat, and just assume you’re onboard with the whole idea of styling mostly with classes, tiers of styling specificity, and focussing on reuse.

When I’ve spoken to non-CSS developers, the big concern around updating or removing features from a stylesheet is the worry that other pages that make use of the same styles are adversely affected. This concern then leads to either the developer in question considering CSS to be a “Dark Art” - something that it really doesn’t need to be.

Cascading Stylesheets Gonna Cascade

A lot had already been said about using certain patterns of naming conventions, layering of styles, and separations of concerns to reduce styling side effects and bugs. In theory, being sensible about your approach to naming and using classes prevents most styling clashes. That still doesn’t ease the nervous CSS newbie dipping their toe into a well established CSS codebase - and I can see their point.

Sadly, in order to be the kind of super-efficient CSS developer we all strive to be, we need to have a complete understanding of the site we are working on. Every browser foible, every odd little @media breakpoint, JS fallback and page state takes time to understand, and just isn’t practical for every single case. This is especially true in an agency environment, where team members can change, or several months can pass between development sprints.

Back-enders have it easy.^[1] They get a huge range of testing suites to pick from that will test all their code at a unit and integration level. Once they leave a project, they can offload all their silo’d knowledge into their specs, confident that the tests will serve to remind them if and when they return to the codebase.

Not so the keen Stylesheet Adventurer. No matter how closely to the BEM convention they stick, the moment they add an extended class style onto an existing module, a seed of Doubt will being to germinate in the back on their mind. Are you certain that’s not going to cause issues anywhere else?

TDD-CSS

Having back-end-like tests for CSS would provide a level of confidence for developers with their own styles. Having confidence in your code means that you aren’t afraid to rip out redundant sections or extend upon existing work from other team members.

There have been a some attempts before to solve the ‘how-to-write-tests-for-CSS’ problem, to varying degrees of success. I can’t help but feel, however, that when the success of your code is almost entirely visual, a visual solution is the most effective option.

What would be handy is a facility where a developer could get an at-a-glance overview of all styles, without needing to navigate to every obscure corner of app, or being forced to intentionally misuse a feature in order to see an error message.

In the last few years, living CSS styleguides have become very popular as a choice of development tool. A separate suite of webpages, sharing the same assets as the main site, but comprised of static HTML patterns to document use cases of CSS. The shining examples of this are Bootstrap’s documentation pages, Github’s Primer, A List Apart… and, well, all of styleguides.io

The great thing about living styleguides is that they are the tip of a massive and well-established pattern library iceberg. Let’s ignore for now the established guides we have all seen that for logo usage, voice and tone, or coding conventions. Although all are VERY necessary, they constitute only a section of what is possible. Instead, we’ll stick with HTML and CSS components.^[2]

CSS Styleguides can be interfaces into your world of CSS patterns. The breadth of that interface is up to you. You may choose to simply display the types of headings, copy and colour swatches available. Or you could go deep and display every single component of your site, such as headers, cards and lists. Maybe take Brad Frost’s approach and consider an atomic design methodology; deconstruct your classes from atoms through molecules and up to complex organisms. It is entirely up to you what and how you display your components, as long as you are communicating to your team how a CSS module works, it shouldn’t matter.

Component libraries are an extension upon that idea. Instead of providing a general sense of the look and feel of an app, we go full resolution. Every class, module and component is included. This is not for the designers and brand managers. This is the reference book for the folk at the coal face. If it’s in production code, it should be here too.

It’s not simple work by any means, and like traditional spec writing, it can be seen as a bit of a slog sometimes, but once you have all these components, all on one page… Wow, things start to become very interesting.

Component library all the things

Happy path scenario: Make a global font size change in your CSS. Instead of checking on each and every page, you simply visit your component library page and scroll through to see if there are any adverse affects. Then you pick up your phone and try it on that as well. All good? Great, carry on with your day.
Need to re-theme? Need to test on an ancient browser? Need to test the registration process, but don’t want to spam the servers with fake accounts? Create static components of each state and preserve them in your library for easy checking in the future.
Create static versions of multi-step logins, or invalid form fields without having to manually go through the process yourself, every single time.
Add in some automated testing, for example with Wraith, that compares a screenshot of your current styleguide against, say that of an earlier deployment and reports back with any differences between the two.

A component library, populated well, can be your documentation of why a pattern was chosen, a sandbox for new features, a debugger and a testing tool.

We’ve been using component libraries for a couple of years now, and the results are obvious. No more ‘is that class still needed’ questions, no more creating elaborate data structures to see if an extra long peice of content breaks the layout. Glorious.

My ‘oooh yeeaaah’ moment was when I realised that I could now easily refactor a global component to take advantage of a new CSS feature without needing to create a new component class and replace HTML. I didn’t need to manually check all instances of it in production to see if it worked. I could probably count the number of times I’ve been able to refactor CSS this easily on one hand.

Having the ability to change your entire site’s look and feel, or conversely, changing the entire way your pages are constructed without changing the look and feel at all, and without having to manually check and re-check all the pages across your site? That’s pretty powerful.

I think that we should be trying to give everyone in a development team ownership of CSS development. Style guides are a step towards that; with a built-in birds-eye-view of all your CSS code, it’s possible to see all the ramifications of updating styles. If we can reduce the fears of introducing regression bugs or developing new features that collide with existing elements, then we can focus on the actual details of CSS, rather than the implementation. You know; the fun stuff!

Oh god, that’s going to be engraved on my tombstone after an angry mob of Rails developers lynch me. If I’m found_dead(Time.now, 1.month.from_now) please narrow the list of suspects down to known Rubymine users. ↩︎
In the Global Library that is all possible types of styleguide, let us venture into the… HTML Pattern section? The CSS Components aisle? Metaphors are hard, man. ↩︎

Taking back control of SASS colour variables

rich@richarcher.co.uk (Rich Archer) — Fri, 01 Jul 2016 08:18:00 GMT

The following is a honest-to-god chunk of SASS/SCSS code we used in a large-ish project not too long ago. I don’t expect you to actually read it - just let your eyes skim over the horror for a moment.

$black: rgb(0,0,0);
$basecolor: #333;
$grey: lighten(rgb(0,0,0), 46.5%); // #777
$lightgrey: lighten(rgb(0,0,0), 58.6%); // #959595
$lighterlightgrey: #a9a9a9;
$lightergrey: lighten(rgb(0,0,0), 79%); // #c9c9c9
$lighterergrey: lighten(rgb(0,0,0), 90%); // #e6e6e6
$lightestgrey: #f2f2f2;
$white: rgb(255,255,255);
$lightblue: #00a5d8;//hyperlink blue
$storyblue: $lightblue;
$blue: #0085ca; //brand colour
$electric-booga-blue: #07d7d5;
$selected-darkblue: #35596d;
$last-minute-orange: #ff8441;
$discounted-red: #ee3124;
$so-many-deals-red: #c91e1f;
$orange-you-glad: #FF780A;
$orange-cta-light: #fc892b;
$orange-cta-dark: #e8640c;
$main-nav-seperator-color: #3b3b3b;
...*snip* (continues for another 30 lines)

A hodge-podge of both over-vague and too-specific variable names, with a scattering of passive aggression in there for good measure. A few trying-to-be-helpful comments, variables assigning other variables, at least 7 different shades of grey^[1] - in short, a mess.

Long lists suck

Lists are handy to have, but their effectiveness is inversely proportional to their length. The longer a list becomes, the harder it is for us humans to parse and channel that information into something useful.^[2]

SASS variables are fantastic. Reading a variable like $facebook_brand in code, rather than a meaningless RGB value is brilliant. But that helpfulness doesn’t scale. Not all colours are as memorable or have such a useful single-purpose name.^[3]

Therefore, it’s easy to see why a combination of 2 useful-but-not-super-useful technologies can become problematic after a while.

In practice, long lists of SASS variables are painful to read, parse, and subsequently, care about. So it’s very easy to end up with one or several of the following:

Terrible variable naming : The developer needs a specific colour, searches through the list and can’t find a colour close enough, so hastily adds another colour variable, with a suitably specific name: $reallyLightGreyThisTimeIMeanIt.
Duplicating colours : The developer doesn’t find the colour needed, even though it does exist, so adds it in a duplicate (or painfully similar) colour definition with another hastily thrown together variable name.
Overriding variables : The developer adds $calltoaction not noticing that variable already exists, overriding the original colour with the new and introducing regression errors.
Rage quitting the whole variable nonsense : The developer hard codes the colour into the CSS rather than using colour variables, because I’m not going to spend five minutes crawling through the variables trying to find the right one.

I wouldn’t blame anyone for doing any of those - it’s not their fault that this unsorted mess of variables is hard to use.

Like a lot of the very useful features in SASS, they are the tools that, when used improperly, allow users to make their own horrible flavours of code spaghetti.

For example, SCSS selector nesting of style definitions are an incredibly powerful function, but nest too deeply and you end up entering a CSS specificity battle with your past self. To the point where sensible SASS guidelines now recommend avoiding nesting unless absolutely necessary.

It’s the same with colour variables. A simple concept that is far too prone to causing more hassle than the problem it was initially meant to solve.

[They] were so preoccupied with whether or not they could that they didn’t stop to think if they should. Dr Ian Malcolm

Mo’ variables, mo’ problems

I’m a simple man. All I ask is for an approach that allows me to:

Globally assign colours to variables The main reason for using SASS variables in the first place. Assigning names to variables and using them throughout the codebase means that it’s easier to keep track of the colours in use should we need to globally change them.
Use a memorable naming convention I know from experience that playing the game ‘How do I spell that variable?’ is a long and torturous process. Having to stop working in one document to look up a variable declaration in another, only to realise you’d used a been misspelling the variable is a morale-sapping experience. Tiny little delays like that can really interrupt a development flow.
Enforce a naming convention You may have come up with a super-simple approach to naming your variables - but no-one has to follow it. Are you going to fastidiously read every pull request, and leave helpful comments about how it should be named? Ain’t nobody got time for that.
Increase the readability Someone very wise once wrote that ‘long lists suck’. You can sort the lists somehow, or add in line-breaks - maybe a comment or two, but again, it’s not enforceable, it is painful to maintain, and it’s even worse to read.
Gracefully handle errors SASS’s default behaviour of aborting compilation when an unknown variable is used is not very helpful, especially when refactoring SCSS code. Isn’t there some way we could have a graceful fallback of some sort should a colour not exist?

Fortunately, with SASS’s lovely map data types and a few SASS functions, it is possible to regain some control of unwieldy lists. Let’s run through it.

Firstly, we created a nested SASS map object, into which we can add all the colour variables:

$swatches: (
  grey: (
    light: lighten(rgb(0,0,0), 79%),
    base: #a9a9a9,
  ),
  blue: (
    light: #00a5d8,
    base: #0085ca,
    dark: #07d7d5
  ),
  orange: (
    base: #FF780A,
    dark: #e8640c,
  )
  ...
);

We’ve grouped the colours firstly by broad colour definition, and finally defined each colour either base, dark or light. Already we’re tackling the readability issue - grouping by broader chunks of code makes lists far easier for humans to scan through.

Once a variable is in a map like this, the only real way to get them out is via a custom SASS function and a couple of tasty SASS helpers. The function will require 2 parameters; a colour name and a ‘tone’:

  @function swatch($swatch, $tone) {
    @if map-has-key($swatches, $swatch) {
      @if map-has-key(map-get($swatches, $swatch), $tone) {
        @return map-get(map-get($swatches, $swatch), $tone);
      }
    }
  }

So now we have a basic implementation: swatch(blue, base) will return #0085ca. Nice!

Because we now have programmatic access to our colours, we can build on this wrapper function to start addressing some of the earlier issues.

Let’s make a few assumptions about our variable map. For example, let’s assume that there must always be a base variable for each colour. Working with that, we can then start incorporating some graceful fallbacks for undefined tones, as well as add in some other nice-to-haves.

@function swatch($swatch, $tone: 'base') {
  $swatch-error: #f00;
  @if map-has-key($swatches, $swatch) {
    @if map-has-key(map-get($swatches, $swatch), $tone) {
      @return map-get(map-get($swatches, $swatch), $tone);
    }
    @warn "Invalid tone: `#{$swatch}` - `#{$tone}`.";
    @return swatch($swatch);
  }
  @warn "Invalid swatch: `#{$swatch}`.";
  @return $swatch-error;
}

So given our previous $swatches map - the following should be the case:

swatch(blue) will return #0085ca, swatch(blue, light) will give us #00a5d8, swatch(blue, herpderp) will fall back to the base colour of #0085ca again.

Using swatch(madeup, light) will return #f00 as that map doesn’t exist at all.

Lastly, error logging is added via the @warn method for further bug tracking.

We’re done! By leveraging the built-in functions of SASS, we’ve constructed a far more useful map of colours that can be easily parsed by both computer and coder. We have graceful fallbacks and a sensible naming convention that is simple to understand and extend upon.

Closing thoughts

If you take nothing else away from this article, I heartily recommend you make use of a CSS or SCSS linter. Yes, it will annoy your team members, yes your CI build steps will fail at first for totally infuriating reasons - but you get to enforce some super-useful steps, such as colour literals only being used in variable definitions. No more hard-coding colours into the CSS rules.
The swatch names I’ve chosen here are for demonstration purposes only. Being the old CSS warhorse that I am, I’m still not keen on naming a class (or variable in this case) ‘blue’, just in case the site is somehow redesigned with just the CSS being edited and ‘blue’ is defining a bright yellow colour. That’s my personal preference. I’ve always liked to use names that seem indicative of a colour but ultimately doesn’t mean anything… basically, Dulux paint names… so ‘majestic’ for purple, or ‘jaffa’ for orange.
Also, remember that the names you use are purely subjective and that these names only need to have semantic meaning for your team of developers. If ‘badger’ speaks to your team as ‘green’, and ‘happiness’ is ‘orange’, then all power to you. Remember, rather than having a list of 40-odd variables, the use of maps mean that we’re only going to need to remember 6 or so, and after that, it’s combinations of tone keywords. In this case, ‘Memorable’ > ‘technically correct’.
Most of the time you’re probably going to need more than 3 tones for each colour group, so the illustrated light/base/dark combo is not going to do the job. So far, I’ve found relative success starting with that, and then padding out the extremities and midpoints with x-light/mid-light, and so on. The only thing to remember is that the use of these tone-names needs to be consistent across your colour maps.
The perfect use case: Think of your co-developers trying swatch(ocelot), and needing it to be a little lighter, so trying out swatch(ocelot, light) and getting the exact colour needed, all without the SASS compilation freaking out, or needing to check a list in a separate file, allowing them to get on with their work seamlessly. Lovely.
Only occasionally have I found that I’ve ended up with more than 8 colours in a single map, at which point, I’d suggest taking the opportunity to refactor your code and break those colours out into 2 or more separate objects.

In which Christian Grey reveals a shameless amount of ankle. ↩︎
Remember this next time you’re wandering around a supermarket with a list in hand, and have to make the long trek back to the bread aisle because you didn’t notice ‘bagels’ further down. ↩︎
I’m looking at you, $main-nav-seperator-color - I mean, you’re not even spelled correctly! ↩︎

(Over)thinking about custom elements

rich@richarcher.co.uk (Rich Archer) — Sun, 12 Oct 2014 08:01:00 GMT

With the promise of encapsulated new behaviours and styling, the ability to create new HTML elements, and to have all that power easily share-able within the community - Web Components hold enough promise to be the Next Big Thing.

If you haven’t yet got the full skinny on Web Components and their potential, I can’t recommend reading Peter Gasston’s excellent introduction to Custom Elements enough. In fact, even if you consider yourself fairly up-to-date and you haven’t read it, go do yourself a favour. I’ll wait. Go on.

It’s cool, right? We have in our hands the power to add new features to browsers as technologies and requirements of the web change. We essentially short-cut the previous routes of going through the labyrinthine halls of the W3C spec writers, and can quickly prototype an MVP, deploy, learn, and iterate.

The theory is that once developed, you can decide to publish you shiny new component somewhere so other folk can use it. In theory, the best will rise to the top of the heap, gain the most visibility, be adopted by everyone, make the web a better place and everything is awesome^[1].

Full disclosure: I had my concerns about web components when I first heard of them. The examples I read about and had explained to me by enthusiastic early adopters were setting off my Progressive Enhancement and Accessibility senses^[2].

To utterly misquote Dr. Strangelove: The technology of web components is easily within the means of any developer; it requires only the will to do so.

Anyone. Like, really? Anyone could develop these? Surely that’s a terrible idea!

Have a look at how many jQuery plugins are there that provide some level of JS functionality without a PE-style fallback. How many plugins, developed with the best of intentions, break on newer browsers, are ill supported, left to go stale when the author moves on to pastures new?

It seemed to me that aspects of accessibility and maintainability are important to spec writers but not to enough developers of plugins and polyfills, and so it would continue with Web Components. With the web components atomic bomb, I reasoned, we were going to break the Web.

“People are stupid,” I said, “we’ll end up with a hundred different variations of link elements, one for each social platform, none of which are as good as the original accessible HTML element.”

Accessibility is hard. As much as people reassured each other that fallbacks to standard elements and ARIA roles will be the way forward with regard to making web components future friendly, I remained skeptical, and that we would end up developing the components we deserve, not the components we need.

But again, I need to remember that the web is an ever-evolving continuum. As much as I want backwards compatibility for as long as possible, I also want the web to be forging onwards in bold new directions. And that is cool and amazing, but also scary and terrifying. I look forward to the introduction of the <hologram> element, but the backward-compatibility concerns are potentially staggering.

If I want that, then I should trust other people do as well, and with these tools we have the ability to get coding now. As Bruce Lawson put it: My message to accessibility advocates is ‘passion – great. But with pull requests, please.’

We have a unique opportunity to shape the future of the web at a grass-roots level right now. I’m off to start developing.

Required reading from far smarter folk

Sidenote: Is there a such a thing as an anti-sarcasm element? <earnest>, maybe? Because reading that last line back sounds VERY sarcastic. It’s not. I think this stuff is brilliant. No really. No really. ↩︎
Kind of like Spider Senses but with better screen reader support ↩︎

Do we still need Progressive Enhancement in web apps?

rich@richarcher.co.uk (Rich Archer) — Tue, 04 Mar 2014 07:02:00 GMT

There has been a heck of a lot said about PE in the last month or so, most notably from my favourite super-smart thought leaders, Jeremy Keith and Ethan Marcotte about the need to remember the lessons of the past, and keep progressive enhancement a key concern in one’s daily development cycles.

It’s a good thing to keep front of mind, especially when (to my mind, deliberately inflammatory) articles about PE being dead gain traction and encourage what I would consider a step backwards in that aspect of web development.

It’s an important question to ask, however. Why, when we have a proliferation of amazing JS web-app libraries that allow us to do magnificent things in the browser should we have to develop the same application twice? We live in a world where screen reader JavaScript penetration is 97.6%, and one of the Big Four browsers doesn’t even allow users to easily turn off JavaScript.

Why should I have to develop (and pay for) an app that renders once in HTML, before being overwritten by the same app written in a different language? – Recalcitrant Crowd of Developers

Does it take a lickin’ and keep on tickin’?

Of the 3 main aspects of front-end development, HTML, CSS, and JS, JavaScript is by far the most fragile. HTML (especially HTML5) handles malformed structure in a reasonably understandable way. CSS silently chooses to ignore rules it doesn’t understand. JS needs feature detection. Drop in an unchecked document.getElementsByClassName into anything less than IE9 and, well, the results may yeild unexpected results. Heck, forget to add a semi-colon to the right place, a dependancy fails to download, accidentally redefine a variable; JavaScript packs up and goes home at the first sign of trouble.

PE is not just about feature detection. It’s about ensuring that when parts of the site is broken, can other aspects still function. In other words, the parts of a site that do not cut the mustard in a browser shouldn’t cause the entire site to become unusable.

Christian Heilmann uses the ‘escalators and elevators’ analogy. When an elevator breaks down, it’s broken and useless. When an escalator breaks down, it becomes a staircase; still useable, just without the extra polish it had before. That’s how we should develop our sites. Embracing the meaning of PE ensures that we can be confident that when (not if) things go “kaka” it should function to some extent.

“Not supported” !== “Ignored”

One of the big points I took away from Jeremy’s post was that “The web is not a platform. It’s a continuum”. From Ethan’s it was that in this business “we play the long game”. Browsers do not pop out of existence the moment we stop supporting them. They’re still out there, used by certain demographics for various reasons, and they still require access to your content.

Development time costs. If it didn’t we’d probably end up “supporting” all browsers ad-infinitum. At some point, however, the project purse-holder will decide that it’s not worth the time and effort required to support a particular browser, and you’ll not spend as much time ensuring the HD experience for that section of the audience. They may get the lesser, degraded version without fancy bookmarkable URLs, indeed, they might not even get anything beyond a linear layout and a nod towards typography if that’s what the product owner deems acceptable. What matters is that they can always reach your content.

What “support” means to you and your team can be a many varied thing - but as long as you’ve coded your site using proper web-standards, the risk of your site not working at all is minified.

I like to ensure that the site I work on can be accessed via the lowest featured browser I can find, arguably Lynx - a command line based browser that only understands HTML. It’s not perfect, but it’s a good indicator of what is available on your site to the lowest common denominator.

PE provides you with the confidence that the content is at the very least available to every single one of your users, even if the CSS isn’t rendering or JS playing nicely.

SEO

This is the one that usually has the biggest impact in a discusson regarding PE, because it is the one that has the potential to hit the wallet hardest. If you want search engine traffic coming to your site, you need your site to be readable to search engines.

Much discussion is made in the JS web-app world about how to achieve this. Talk of developing a server side generated equivalent that is hidden behind a hashbang, or that renders HTML in PhantomJS, using 3rd party services that will make your content avilable to (some) search engines via a proprietary specification.

Whichever way, the user is still required to develop 2 versions of the site, one client and one server, which no-one really likes, and is a practice that does raise familiar sounding questions.

For my money, if the HTML first layered on JS and CSS approach is not for you, and you absolutely, positively have to have the latest and greatest web-app running on your site - the hard work achieved by the likes of AirBnB, Meteor and Artsy looks the best bet - a single codebase useable on both the server and front end.

Perhaps this is the Holy Grail we’ve all been looking for?

Every time you say “it depends”, we all take a drink

Ultimately, Progressive Enhancement is an opt-in thing. If you genuinely don’t think you’ll ever need the benefits of PE, don’t utilise it. If the “content” your site provides is transient and shouldn’t be indexable, it’s goals simply do not have a fallback alternative, or you just don’t care, then maybe you can skim through this article with casual indifference.

I feel, however, that the cases when that is justifiable are limited. For the majority of cases, PE is still highly relevant, and necessary.

Generating, Adding, and Using Multiple SSH keys

rich@richarcher.co.uk (Rich Archer) — Tue, 04 Jun 2013 17:54:00 GMT

Having “One Key to Rule Them All” can be a little concerning when it comes to SSH keys. Single points of failure are not amazing. Let’s spread the risk a little.

If you find that you need to work with multiple servers (quite likely), multiple Heroku accounts (very likely) or the myriad other services that require a SSH key to get started - Github, BitBucket et al (very, very likely). No-one enjoys having a single point of failure, and going on past experience, it is incredibly annoying having all your services suddenly fail on you if your private key corrupts, mysteriously vanishes or is somehow compromised.

Creating SSH keys

From your command line, navigate to the directory that stores your SSH keys

$ cd ~/.ssh

Run the key generation command:

$ ssh-keygen

This will return the following:

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/buzz.lightyear/.ssh/id_rsa):

Here you would enter the location and name of the key you wish to save - for example foo/new.key.for.github. As the prompt says, leaving this blank generates the standard key id_rsa.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Enter your secret passphrase, and you’re done.

The key fingerprint is:
e8:bf:af:71:b4:b3:32:3a:45:5a:c5:a6:53:d4:74:13 buzz.lightyear@Infinity.local
The key's randomart image is:
+--[ RSA 2048]----+
|         +ooE..  |
|        . + .o   |
|       o +       |
|      +.+        |
|      S.S.       |
|     . ...       |
|      o.*        |
|      .* +       |
|      o+=.       |
+-----------------+

With regard to passphrases, the temptation might be to leave this blank. Try not to do this; it’s the equivalent of locking your car and then hiding the keys under the back wheels. All it would take is for someone to access your computer and they’ve also access to your remote business.

Adding to the key manager

If you are frequently accessing a server and, frankly, the constant requests for your passphrase are becoming a little draining, then you might consider adding your key to the SSH agent.

The SSH agent takes care of the authentication for you so that you don’t have to type in passwords at the terminal. Obviously, the tradeoff for convenience is the drop in security - anyone with access to your personal machine could gain access to your servers that use this particular key - the choice is yours.

With the default SSH key (id_rsa) this is as simple as typing in ssh-add into your command line, but you’ve got so many more keys now - so add an extra parameter as follows:

$ ssh-add foo/new.key.for.github

It should ask for your passphrase if you provided one, and will reward you with your equivalent of this message:

Identity added: /Users/buzz.lightyear/.ssh/andys-house (/Users/buzz.lightyear/.ssh/andys-house)

SSH-Agent will securely save your passphrase so that you don’t need to type it in each and every time for this session. I find that on closing my terminal, I’m required to repeat this process the next time - which is a good compromise for me.

For the fully automated approach, you could tie your ssh-keys into your OSX keychain, the Github.com help docs are pretty useful for getting started.

SSH keys, spying, and such

rich@richarcher.co.uk (Rich Archer) — Sun, 02 Jun 2013 17:03:00 GMT

Do you push stuff up to GitHub? Heroku? A remote repository of any kind? Chances are that you’ve been asked to “simply upload your SSH keys” to some site or another.

If you are anything like me, you’ve nothing but a vague idea what SSH keys are, you’ve simply googled and found a link similar to the Github help pages, followed the 4 steps and everything seems to work. Huzzah! What exactly did you just do? What does SSH actually mean? It’s time for an elaborate explaination.

Excruciating Cold War analogy of SSH keys

Let’s say that you need to pass a secret package of microfilm securely with another person in return for nuclear plans, but don’t know what he/she looks like and don’t want your package to fall into the wrong hands. How do you know who to trust?

You could arrange to meet at a ski resort and pass long, elaborate coded phrases between one another about favourite brands of cigarettes until both of you are convinced of the other’s credentials.

At this point you could (most likely) swap microfilm baked into a ceramic cat with the nuclear plans embedded in a Kandinsky painting, and disappear into the night.

The problem with this approach is that at some other point in the past - someone will need to have arranged shared passwords. These passwords could be intercepted by unscrupulous types, and before you know it, ‘Comrade Zero’ has gone to your rendezvous point, used your secret phrases and stolen your nuclear plans and given your contact a microfilm full of holiday photos in what will ultimately prove to be another powerful blow against the Capitalist West.

Alternatively, both parties could have a padlock and a key. They send their padlock to their opposite number with instructions to bring it to the meeting point, with respective packages locked inside boxes.

Once they meet, all it takes is a simple check to see that each padlock can be opened by the other person’s key and you’re home free.

If both padlocks cannot be opened, then there is a reasonable chance that one of you is a fraud, the deal is seen as a bust and what follows is almost certainly an exhilarating car chase through Prague.

What I’m saying here is that passwords have a single point of failure; giving the opposing party the a padlock that can only be unlocked your private key reassures both sides that the other isn’t a KGB operative, and can be trusted enough to deal in microfilm/nuclear-plan barter-based processes.

But that’s not really how SSH keys work

No, not really, but close enough. If you squint.

Instead of literal private keys and public padlocks, think of public and private SSH keys. Public keys can encrypt a message, and the corresponding private key is the only one that can de-crypt it.

When you first connect to a remote machine for the first time, it will send you its public key. If you’ve uploaded your computer’s public key to the server, it will use that to encrypt a message and send to your machine.

If your machine can decode that message correctly, that’s half the job done. Next, your machine uses the remote’s public keys to encrypt that message and send it back.

If the remote machine can successfully decrypt that message, both machines can be reasonably sure that other can be trusted and get on with the business of transacting.

That was a lot of text. What do I need to do?

Create a SSH public/private key-pair.
Add the public key to the remote server’s ‘trusted keys’ list.
SSH to the remote server.
Accept the remote server’s public key.

Basically, do the same steps as outlined on the Github help pages. But now you know more about what is actually going on there – great!

Next time we will be doing a lot more of the hands–on work, and should act as the one–stop reference page you actually need to get this SSH stuff done.

Cape Town Front End Developer meetup

rich@richarcher.co.uk (Rich Archer) — Thu, 14 Mar 2013 19:48:00 GMT

Yesterday I got to give a small presentation at the newly formed Cape Town Front End Developer Meetup about a subject very close to my heart; CSS, or rather modular CSS.

Here are the slides:

link to speakerdeck

It was both terrifying and exiting to give my first technical talk to a room full of experienced and knowledgable peers, and if it’s something you haven’t done yet, I cannot recommend it enough. In the words of the smart chap that convinced me to give it a go: “There’s got to be someone that doesn’t know about this stuff”.

Wise words indeed.

If you do have any questions about any points raised by the presentation, please don’t hesitate to get in touch with me on Twitter (@slocombe) or drop me an email (howzit@richarcher.co.uk).

Also, if you’re in the Cape Town area, please drop by the group sometime – it’s got a fantastic vibe that’s only just started and going to get better.

Pointless carousels can burn in hell

rich@richarcher.co.uk (Rich Archer) — Thu, 10 Jan 2013 13:42:00 GMT

A little challenge I set myself when designing a site is the “Don’t use a pointless carousel of images on the front page” game.

If I can design a site that is useful to the user across all platforms, conveys the message of the site quickly, converts the user to the purpose of the site easily and doesn’t rely on a constantly changing section of site to fit as much information into already crowded screen real-estate, then I Win. 10 points to Gryffindor and all that.

I don’t always manage this, and the plain reality of carousels is that sometimes they are very useful indeed. But that doesn’t stop me trying other approaches first.

A while ago I was building a small, single purpose site that did one job very well. The copy for the site was short, succinct and to the point. On coming up with a layout, the clients and I were exploring options to give the page a bit more ‘pop’. The consensus was that a carousel was the best thing to use.

The first question is “Why”? The second is "What should appear in there?

To slap on a rotating image carousel of laughing women eating salad or a racially diverse collection of directors smiling around a boardroom table would do a disservice to a product specifically designed to work without frills.

This is something that pretty much all websites must go through – the fear of perceived lack of content or the struggle to organise content into a respectable hierarchy, usually followed by a panicked attempt to “fluff up” the content a bit.

Maybe we should have a carousel with each panel sliding in explaining some facet of the product that had not yet been considered by the user? To do the job, in fact, that a single bullet point list could do in a second?

Maybe we should use carousels as an interesting way to direct users to other parts of the site that they hadn’t considered before? Yes… a sliding interactive gallery of “Hey guyse we got us some case studies” or “lol! contact us!”.

While this approach might work for a while; your dark corner of the site has a tiny torchbeam of recognition shone into its crevice, but what about when you change the carousel to point somewhere else? Are you assuming that all that crazy traffic will somehow be retained? If you’re relying on a carousel to direct users around your site, you’ve bigger problems than what to put on your front page – SEO, IA and frankly, the general usability of the site is brought into question.

If we entertain the carousel notion for a little longer, more questions arise – how should this function without javascript enabled? It is to be an infinite carousel or to scroll back to the beginning? If it’s a combination of text and images, is the text separate from the images? Is each panel to be distinct and unique with it’s own ‘feel’? How would one manage the styling of these special little snowflakes? Is it possible to skip panels, is it possible to pause? How do touch screen interfaces work with it? How do skinny viewports interact with it – and is it different to the full-fat equivalents? Scroll left-to-right, top-to-bottom, fade in-out?

There’s no such thing as “Just” using a carousel. Unfortunately that’s how they’re treated – a graphical flourish that somehow is meant to bring extra gravitas to a design without much thought as to what they’re actually meant to do.

To me, carousels are heading on a course that is sending them very close to the same school-of-design-dustbin in which Comic Sans and Flash splash-screens reside. Needless overuse eventually will make it a reviled option amongst designers and stop people using them when they are a good idea.

(Update 24th Jan) Required reading from far smarter folk

Flickr's new iOS app made me fall in love with the service again

rich@richarcher.co.uk (Rich Archer) — Wed, 19 Dec 2012 09:38:00 GMT

When Flickr released their new app amongst a fanfare of delighted tweets last week, I was, I admit, a little cynical. But the after a few days of usage, I’ll happily put my hands up and admit just how very wrong I was.

I didn’t, I admit, use Flickr to it’s full potential. Back in the day I would upload photos of various holidays or parties to the site, and emailed the url of the set to my compadres, and that was really it. Unfortunately, no-one in my social circles really used Flickr, and all (at the time) were all using Facebook.

I also used the service as nothing more that an online repository of my various photographic attempts; away from the frailties of my own hard-drives that had failed too many times in the past.

Other offline storage options emerged, and when the time came to renew my Pro membership… Well, let’s just say we parted company. In fact, I very nearly closed my account down entirely serveral times - but never quite got around to it.

Enter the Mobile Revolution; we’re all on phones now - taking instragraming, tweeting, whatsapping - everything we currently want to do, we can do from our phones.

The app capitalises on the amazing success of Instagram and their ilk, working on the axiom that the ‘best camera is the one you have with you’ - usually your iPhone - to capture those occasional moments that should be immortalised and shared amongst your friends. It has the vintage filters, should you need them, plus some additional editing tools, as well as the ability to easily follow your contacts as easily as in Twitter.

For me, what’s different this time is that the photos are being saved to a photo service. Not a Facebook timeline or a Tumblog or Twitter stream - a service for storing and keeping your random photos of coffee secure. They feel safer there in a site designed for them exclusively - alongside the photos I may choose to take and upload via my larger cameras, rather than lost amongst the status updated and animated Doctor Who gifs.

What really sold me though, was that the app takes the core service of Flickr, and then enhances it with the native app functionality of the camera and editor. This kind of progressive enhancement of a web app with native apps is exactly the sort of setup tht flies my flag. A smashing mobile-optimised web site as a baseline, with all the features available to non-iPhone viewers - with an additional layer of interactivity on the native app with the camera and editor. With the web site in place, the native app pivots incredibly well on the social/sharing side of the service, without excluding anyone who doesn’t have a particular type of smart phone.

All in all, the Flickr app is a wonderful layer of app-like beauty draped over an already excellent service that is at a stage in its lifetime where other services would simply have rolled over and died. Flickr has resurrected itself and in turn reinvigorated my love for the place - to the point where I’m most likely going to upgrade my service to Pro status again, no longer for me just a storage option, but somewhere where I can enjoy being part of a community just as much as I do on other sites.

I’m probably not going to be the only one either - I’m certain that there are plenty of people just like me that are going back to her, looking sheepish and trotting out a mumbled apology about asking to be let back in again - Instagram was a once-off mistake. We’ll not do it again…

That Zuckerberg HTML5 Quote

rich@richarcher.co.uk (Rich Archer) — Mon, 03 Dec 2012 21:09:00 GMT

Misappropriated quotes from billionaire social media tycoons are misappropriated.

I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native…

As part of my research into the native versus cross-platform apps debate, I saw this quote a lot. I understand why; it’s a great quote – even if it’s taken entirely out of context.

I was recently invited to participate in a great meetup at Cape Town SPIN – “Native vs Cross-platform for Mobile Development” (hence my previous post).

We all know by now about Facebook’s fairly high profile ‘ditching’ of HTML5 in favour of native development. It was hailed as the apparent final nail of the markup coffin, with native apps proving to be the all-conquering hero.

Okay. To an extent, we HTML5-ers were probably due a little bit of hubris after rubbing Facebook into the collective faces of the web-app dissenters a few years ago. Fair enough.

But before someone churns out the quote verbatim again, can we just check our sources a little here?

When I’m introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there. And it’s not that HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us. Mark Zuckerberg @Disrupt SF 2012

Context is always important.

Native vs Cross-platform for mobile development

rich@richarcher.co.uk (Rich Archer) — Tue, 20 Nov 2012 17:01:00 GMT

I don’t have a problem with native mobile apps. In fact, I love them. But then again, I’m an iPhone owner. We get all the cool stuff.

Apps can be wonderful if you have access to them. But if you are not one of the blessed few that has a device with a matching app, where does that leave you? Forced to use an actual… *gulp* website?

In South Africa in May, there are 8 million mobile-web users out there, the top 3 platforms being used on the day of writing being Symbian, Android and the Nokia Series 40, each with approximately 22% of the market.

Not quite so shortly behind them are iOS (iPad, iPhone, iPod Touch), “Unknown”, Blackberry, Samsung, the mysterious “Other”, and Windows Phone.

Even if we elected to develop only for a small portion of these phones, there would be a costly amount of developer time needed to develop (and maintain) specific apps for each. And how do you choose which one to develop for?

Oh! If only there was some sort of standardised markup language that would be understandable by anyone with web connection – Sarcastic Greek Chorus

Does your phone have a browser? Boom! Instant access to your web-app by potentially hundreds of thousands of users.

Developing a web app is faster and easier to develop for, easier to iterate upon with feature releases and is truly the “create once, publish everywhere” environment. In short; less cost across the board.

As a web-app, it is possible to leverage the basic nature of the web; it will instantly be more ‘findable’ on the web as opposed to being lost amongst hundreds of similar apps in an app store somewhere, as well as being easily linked to and shared in Twitter, Facebook, LinkedIn or any other site.

As a web-app, your service remains unencumbered by the slings and arrows of a 3rd party app store. By developing a web app, you are avoiding having a cut of any revenue made from within the app being taken by the app store, such as the Financial Times chose to do when Apple wanted a cut of their users’ subscription fees.

As a web app, if you need to redeploy your app after a minor release, you are not penalising your user’s bandwidth caps by forcing them to re-download a 10MB binary for a small tweak.

As a web app, if a new web-enabled device arrived on the market, we know that device will be able to access your app already without any delay. Your app is Future Friendly.

There are differences between devices. All devices render differently, and on different screen sizes and resolutions. Fortunately, dealing with an uneven playing field is what us front-end developers have been doing for years; by embracing the principles of accessibility, graceful degradation, feature detection and adaptive design, we have been creating web pages that take advantage of newer technologies as they are made available to us, whilst allowing the web experience to fallback to a more basic interface for the older browsers.

You are not preventing any users from accessing your content, and you are not penalising the newer users by catering soley to the lowest common denominator.

A dash of reality

As much as I would love to hitch up the HTML5 wagon and ride off into the sunset, the simple facts of the matter are that some people EXPECT a native app of some sort. The simple fact is that native apps are in the main faster AND they can currently do more than traditional HTML5 apps. iOS users expect a higher polish to their app experience, and will freak the hell out if that experience does not match their expectation.

Put simply, it’s a case of comparing the richness of native apps against the pure magnificent reach of HTML5.

Trying to replicate an native app experience in a HTML environment is setting yourself up for a fall. People will inevitably make comparisons and at some point they will notice that there is an uncanny valley effect, in which the web app will come out the loser.

But that doesn’t mean that you should go racing ahead and develop a native app straight away. Don’t instantly reduce your market by developing for a specific platform.

Start wide and then focus in

Here is what I would suggest. Develop your web-app first, quickly, publish, get it out there. Minimum Viable Product. Iterate. Learn from your users. Develop your brand. A/B test. If there is a need for a native app after that and you have the resources, you are better positioned to take the lessons from your website and improve them in the app.

Native development as a form of progressive enhancement

Here’s what you gain from this approach:

You know which segments of your potential market you are missing out on entirely, or which segments of your market you want to capitalise upon.
You “pave the cowpaths” – watch the interaction patterns your users navigate the site and enhance them in the app. Not sure which platform to develop for first? You do now.
Less waste of expensive native development time trying to position your app correctly within the market.
Less chance of annoying your userbase with an ineffective app.

In summary, there’s no reason why native and web apps need be in direct competition; they can exist perfectly well together.

But seriously. Do the web app first.