Tags: clearleft

63

sparkline

A framework for web performance

Here at Clearleft, we’ve recently been doing some front-end consultancy. That prompted me to jot down thoughts on design principles and performance:

We continued with some more performance work this week. Having already covered some of the nitty-gritty performance tactics like font-loading, image optimisation, etc., we wanted to take a step back and formulate an ongoing strategy for performance.

When it comes to web performance, the eternal question is “What should we measure?” The answer to that question will determine where you then concentrate your efforts—whatever it is your measuring, that’s what you’ll be looking to improve.

I started by drawing a distinction between measurements of quantities and measurements of time. Quantities are quite easy to measure. You can measure these quantities using nothing more than browser dev tools:

  • overall file size (page weight + assets), and
  • number of requests.

I think it’s good to measure these quantities, and I think it’s good to have a performance budget for them. But I also think they’re table stakes. They don’t actually tell you much about the impact that performance is having on the user experience. For that, we need to enumerate moments in time:

  • time to first byte,
  • time to first render,
  • time to first meaningful paint, and
  • time to first meaningful interaction.

There’s one more moment in time, which is the time until DOM content is loaded. But I’m not sure that has a direct effect on how performance is perceived, so it feels like it belongs more in the category of quantities than time.

Next, we listed out all the factors that could affect each of the moments in time. For example, the time to first byte depends on the speed of the network that the user is on. It also depends on how speedily your server (or Content Delivery Network) can return a response. Meanwhile, time to first render is affected by the speed of the user’s network, but it’s also affected by how many blocking elements are on the critical path.

By listing all the factors out, we can draw a distinction between the factors that are outside of our control, and the factors that we can do something about. So while we might not be able to do anything about the speed of the user’s network, we might well be able to optimise the speed at which our server returns a response, or we might be able to defer some assets that are currently blocking the critical path.

Factors
1st byte
  • server speed
  • network speed
1st render
  • network speed
  • critical path assets
1st meaningful paint
  • network speed
  • font-loading strategy
  • image optimisation
1st meaningful interaction
  • network speed
  • device processing power
  • JavaScript size

So far, everything in our list of performance-affecting factors is related to the first visit. It’s worth drawing up a second list to document all the factors for subsequent visits. This will look the same as the list for first visits, but with the crucial difference that caching now becomes a factor.

First visit factors Repeat visit factors
1st byte
  • server speed
  • network speed
  • server speed
  • network speed
  • caching
1st render
  • network speed
  • critical path assets
  • network speed
  • critical path assets
  • caching
1st meaningful paint
  • network speed
  • font-loading strategy
  • image optimisation
  • network speed
  • font-loading strategy
  • image optimisation
  • caching
1st meaningful interaction
  • network speed
  • device processing power
  • JavaScript size
  • network speed
  • device processing power
  • JavaScript size
  • caching

Alright. Now it’s time to get some numbers for each of the four moments in time. I use Web Page Test for this. Choose a realistic setting, like 3G on an Android from the East coast of the USA. Under advanced settings, be sure to select “First View and Repeat View” so that you can put those numbers in two different columns.

Here are some numbers for adactio.com:

First visit time Repeat visit time
1st byte 1.476 seconds 1.215 seconds
1st render 2.633 seconds 1.930 seconds
1st meaningful paint 2.633 seconds 1.930 seconds
1st meaningful interaction 2.868 seconds 2.083 seconds

I’m getting the same numbers for first render as first meaningful paint. That tells me that there’s no point in trying to optimise my font-loading, for example …which makes total sense, because adactio.com isn’t using any web fonts. But on a different site, you might see a big gap between those numbers.

I am seeing a gap between time to first byte and time to first render. That tells me that I might be able to get some blocking requests off the critical path. Sure enough, I’m currently referencing an external stylesheet in the head of adactio.com—if I were to inline critical styles and defer the loading of that stylesheet, I should be able to narrow that gap.

A straightforward site like adactio.com isn’t going to have much to worry about when it comes to the time to first meaningful interaction, but on other sites, this can be a significant bottleneck. If you’re sending UI elements in the initial HTML, but then waiting for JavaScript to “hydrate” those elements into working, the user can end up in an uncanny valley of tapping on page elements that look fine, but aren’t ready yet.

My point is, you’re going to see very different distributions of numbers depending on the kind of site you’re testing. There’s no one-size-fits-all metric to focus on.

Now that you’ve got numbers for how your site is currently performing, you can create two new columns: one of those is a list of first-visit targets, the other is a list of repeat-visit targets for each moment in time. Try to keep them realistic.

For example, if I could reduce the time to first render on adactio.com by 0.5 seconds, my goals would look like this:

First visit goal Repeat visit goal
1st byte 1.476 seconds 1.215 seconds
1st render 2.133 seconds 1.430 seconds
1st meaningful paint 2.133 seconds 1.430 seconds
1st meaningful interaction 2.368 seconds 1.583 seconds

See how the 0.5 seconds saving cascades down into the other numbers?

Alright! Now I’ve got something to aim for. It might also be worth having an extra column to record which of the moments in time are high priority, which are medium priority, and which are low priority.

Priority
1st byte Medium
1st render High
1st meaningful paint Low
1st meaningful interaction Low

Your goals and priorities may be quite different.

I think this is a fairly useful framework for figuring out where to focus when it comes to web performance. If you’d like to give it a go, I’ve made a web performance chart for you to print out and fill in. Here’s a PDF version if that’s easier for printing. Or you can download the HTML version if you want to edit it.

I have to say, I’m really enjoying the front-end consultancy work we’ve been doing at Clearleft around performance and related technologies, like offline functionality. I’d like to do more of it. If you’d like some help in prioritising performance at your company, please get in touch. Let’s make the web faster together.

The history of design systems at Clearleft

Danielle has posted a brief update on Fractal:

We decided to ask the Fractal community for help, and the response has been overwhelming. We’ve received so many offers of support in all forms that we can safely say that development will be starting up again shortly.

It’s so gratifying to see that other people are finding Fractal to be as useful to them as it is to us. We very much appreciate all their support!

Although Fractal itself is barely two years old, it’s part of a much longer legacy at Clearleft

It all started with Natalie. She gave a presentation back in 2009 called Practical Maintainable CSS . She talks about something called a pattern porfolio—a deliverable that expresses every component and documents how the markup and CSS should be used.

When Anna was interning at Clearleft, she was paired up with Natalie so she was being exposed to these ideas. She then expanded on them, talking about Front-end Style Guides. She literally wrote the book on the topic, and starting curating the fantastic collection of examples at styleguides.io.

When Paul joined Clearleft, it was a perfect fit. He was already obsessed with style guides (like the BBC’s Global Experience Language) and started writing and talking about styleguides for the web:

At Clearleft, rather than deliver an inflexible set of static pages, we present our code as a series of modular components (a ‘pattern portfolio’) that can be assembled into different configurations and page layouts as required.

Such systematic thinking was instigated by Natalie, yet this is something we continually iterate upon.

To see the evolution of Paul’s thinking, you can read his three part series from last year on designing systems:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. Components and Composition

Later, Charlotte joined Clearleft as a junior developer, and up until that point, hadn’t been exposed to the idea of pattern libraries or design systems. But it soon became clear that she had found her calling. She wrote a brilliant article for A List Apart called From Pages to Patterns: An Exercise for Everyone and she started speaking about design systems at conferences like Beyond Tellerrand. Here, she acknowledges the changing terminology over the years:

Pattern portfolio is a term used by Natalie Downe when she started using the technique at Clearleft back in 2009.

Front-end style guides is another term I’ve heard a lot.

Personally, I don’t think it matters what you call your system as long as it’s appropriate to the project and everyone uses it. Today I’m going to use the term “pattern library”.

(Mark was always a fan of the term “component library”.)

Now Charlotte is a product manager at Ansarada in Sydney and the product she manages is …the design system!

Thinking back to my work on starting design systems, I didn’t realise straight away that I was working on a product. Yet, the questions we ask are similar to those we ask of any product when we start out. We make decisions on things like: design, architecture, tooling, user experience, code, releases, consumption, communication, and more.

It’s been fascinating to watch the evolution of design systems at Clearleft, accompanied by an evolution in language: pattern portfolios; front-end style guides; pattern libraries; design systems.

There’s been a corresponding evolution in prioritisation. Where Natalie was using pattern portfolios as a deliverable for handover, Danielle is now involved in the integration of design systems within a client’s team. The focus on efficiency and consistency that Natalie began is now expressed in terms of design ops—creating living systems that everyone is involved in.

When I step back and look at the history of design systems on the web, there are some obvious names that have really driven their evolution and adoption, like Jina Anne, Brad Frost, and Alla Kholmatova. But I’m amazed at the amount of people who have been through Clearleft’s doors that have contributed so, so much to this field:

Natalie Downe, Anna Debenham, Paul Lloyd, Mark Perkins, Charlotte Jackson, and Danielle Huntrods …thank you all!

Altering expectations

Luke has written up the selection process he went through when Clearleft was designing the Virgin Holidays app. When it comes to deploying on mobile, there were three options:

  1. Native apps
  2. A progressive web app
  3. A hybrid app

The Virgin Holidays team went with that third option.

Now, it will come as no surprise that I’m a big fan of the second option: building a progressive web app (or turning an existing site into a progressive web app). I think a progressive web app is a great solution for travel apps, and the use-case that Luke describes sounds perfect:

Easy access to resort staff and holiday details that could be viewed offline to help as many customers as possible travel without stress and enjoy a fantastic holiday

Luke explains why they choice not to go with a progressive web app.

The current level of support and leap in understanding meant we’d risk alienating many of our customers.

The issue of support is one that is largely fixed at this point. When Clearleft was working on the Virgin Holidays app, service workers hadn’t landed in iOS. Hence, the risk of alienating a lot of customers. But now that Mobile Safari has offline capabilities, that’s no longer a problem.

But it’s the second reason that’s trickier:

Simply put, customers already expected to find us in the App Store and are familiar with what apps can historically offer over websites.

I think this is the biggest challenge facing progressive web apps: battling expectations.

For over a decade, people have formed ideas about what to expect from the web and what to expect from native. From a technical perspective, native and web have become closer and closer in capabilities. But people’s expectations move slower than technological changes.

First of all, there’s the whole issue of discovery: will people understand that they can “install” a website and expect it to behave exactly like a native app? This is where install prompts and ambient badging come in. I think ambient badging is the way to go, but it’s still a tricky concept to explain to people.

But there’s another way of looking at the current situation. Instead of seeing people’s expectations as a negative factor, maybe it’s an opportunity. There’s an opportunity right now for companies to be as groundbreaking and trendsetting as Wired.com when it switched to CSS for layout, or The Boston Globe when it launched its responsive site.

It makes for a great story. Just look at the Pinterest progressive web app for an example (skip to the end to get to the numbers):

Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).

Now admittedly their previous mobile web experience was a dreadful doorslam, but still, those are some amazing statistics!

Maybe we’re underestimating the malleability of people’s expectations when it comes to the web on mobile. Perhaps the inertia we think we’re battling against isn’t such a problem as long as we give people a fast, reliable, engaging experience.

If you build that, they will come.

Clearleft.com is a progressive web app

What’s that old saying? The cobbler’s children have no shoes that work offline. Or something.

It’s been over a year since the Clearleft site relaunched and I listed some of the next steps I had planned:

Service worker. It’s a no-brainer. Now that the Clearleft site is (finally!) running on HTTPS, having a simple service worker to cache static assets like CSS, JavaScript and some images seems like the obvious next step.

You know how it is. Those no-brainer tasks are exactly the kind of thing that end up on a to-do list without ever quite getting to-done. Meanwhile I’ve been writing and speaking about how any website can be a progressive web app. I think Alanis Morissette used to sing about this sort of situation.

Enough is enough! Clearleft.com is now a progressive web app. It has a manifest file and a service worker script.

The service worker logic is fairly straightforward, and taken almost verbatim from Going Offline. As you navigate around the site, the service worker applies different logic depending on the kind of file you’re requesting:

  • Pages are served fresh from the network, falling back to the cache when there’s a problem.
  • Everything else is served from the cache where possible, resorting to the network only if there’s no match in the cache—quite the performance boost!

In both cases, if a page or a file is retrieved from the network, it’s gets put into a cache. I’ve got one cache for pages, and another for everything else. And even if a file is retrieved from that cache, I still fire off a fetch request to grab a fresh copy for the cache. So while there’s a chance that a stale file might be served up, it will only ever be slightly stale, and the next time it’s requested, it’ll be fresh.

In the worst-case scenario, when a page can’t be retrieved from the network or the cache, you end up seeing a custom offline page. There you can see a list of any pages that are cached (meaning you can revisit them even without an internet connection).

A custom offline page showing a list of URLs.

It’s not ideal—page titles would be friendlier than URLs—but it’s a start. I’m sure I’ll revisit it soon. Honest.

Oh, and after a year of procrastinating about doing this, guess how long it took? About half a day. Admittedly, this isn’t my first progressive web app, and the more you build ‘em, the easier it gets. Still, it’s a classic example of a small investment of time leading to a big improvement in performance and user experience.

If you think your company’s website could benefit from being a progressive web app (and believe me, it definitely could), you have a couple of options:

  1. Arm yourself with a copy of Going Offline and give it a go yourself. Or
  2. Get in touch with Clearleft. We can help you. (See, I can say that with a straight face now that we’re practicing what we preach.)

Either way, don’t dilly dally …like I did.

That new-book smell

The first copies of Going Offline showed up today! This is my own personal stash, sent just a few days before the official shipping date of next Monday.

I am excite!

To say I was excited when I opened the box of books would be an understatement. I was positively squealing with joy!

Others in the Clearleft office shared in my excitement. Everyone did that inevitable thing, where you take a fresh-out-of-the-box book, open it up and press it against your nose. It’s like the bookworm equivalent of sniffing glue.

Actually, it basically is sniffing glue. I mean, that’s what’s in the book binding. But let’s pretend that we’re breathing in the intoxicating aroma of freshly-minted words.

If you’d like to bury your nose in a collection of my words glued together in a beautifully-designed package, you can pre-order the book now and await delivery of the paperback next week.

Global Diversity CFP Day—Brighton edition

There are enough middle-aged straight white men like me speaking at conferences. That’s why the Global Diversity Call-For-Proposals Day is happening this Saturday, February 3rd.

The purpose is two-fold. One is to encourage a diverse range of people to submit talk proposals to conferences. The other is to help with the specifics—coming with ideas, writing a good title and abstract, preparing the presentation, and all that.

Julie is organising the Brighton edition. Clearleft are providing the venue—68 Middle Street. I’ll be on hand to facilitate. Rosa and Dot will be doing the real work, mentoring the attendees.

If you’ve ever thought about submitting a talk proposal to a conference but just don’t know where to start, or if you’re just interested in the idea, please do come along on Saturday. It’s starts at 11am and will be all wrapped up by 3pm.

See you there!

Design ops for design systems

Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.

Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.

Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.

There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.

Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:

None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.

There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:

Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.

I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:

Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.

Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.

Getaway

It had been a while since we had a movie night at Clearleft so I organised one for last night. We usually manage to get through two movies, and there’s always a unifying theme decided ahead of time.

For last night, I decided that the broad theme would be …transport. But then, through voting on Slack, people could decide what the specific mode of transport would be. The choices were:

  • taxi,
  • getaway car,
  • truck, or
  • submarine.

Nobody voted for submarines. That’s a shame, but in retrospect it’s easy to understand—submarine films aren’t about transport at all. Quite the opposite. Submarine films are about being trapped in a metal womb/tomb (and many’s the spaceship film that qualifies as a submarine movie).

There were some votes for taxis and trucks, but the getaway car was the winner. I then revealed which films had been pre-selected for each mode of transport.

Taxi

Getaway car

Shorts: Getaway Driver, The Getaway

Truck

Submarine

I thought Baby Driver would be a shoe-in for the first film, but enough people had already seen it quite recently to put it out of the running. We watched Wheelman instead, which was like Locke meets Drive.

So what would the second film be?

Well, some of those films in the full list could potentially fall into more than one category. The taxi in Collateral is (kinda) being used as a getaway car. And if you expand the criterion to getaway vehicle, then Furiosa’s war rig surely counts, right?

Okay, we were just looking for an excuse to watch Fury Road again. I mean, c’mon, it was the black and chrome edition! I had the great fortune of seeing that on the big screen a while back and I’ve been raving about it ever since. Besides, you really don’t need an excuse to rewatch Fury Road. I loved it the first time I saw it, and it just keeps getting better and better each time. The editing! The sound! The world-building!

With every viewing, it feels more and more like the film for our time. It may have been a bit of stretch to watch it under the thematic umbrella of getaway vehicles, but it’s a getaway for our current political climate: instead of the typical plot involving a gang driving at full tilt from a bank heist, imagine one where the gang turns around, ousts the bankers, and replaces the whole banking system with a matriarchal community.

Hope is a mistake”, Max mansplains (maxplains?) to Furiosa at one point. He’s wrong. Judicious hope is what drives us forward (or, this case, back …to the citadel). Watching Fury Road again, I drew hope from the character of Nux. An alt-warboy in thrall to a demagogue and raised on a diet of fake news (Valhalla! V8!) can not only be turned by tenderness, he can become an ally to those working for a better world.

Witness!

Pattern Libraries, Performance, and Progressive Web Apps

Ever since its founding in 2005, Clearleft has been laser-focused on user experience design.

But we’ve always maintained a strong front-end development arm. The front-end development work at Clearleft is always in service of design. Over the years we’ve built up a wealth of expertise on using HTML, CSS, and JavaScript to make better user experiences.

Recently we’ve been doing a lot of strategic design work—the really in-depth long-term engagements that begin with research and continue through to design consultancy and collaboration. That means we’ve got availability for front-end development work. Whether it’s consultancy or production work you’re looking for, this could be a good opportunity for us to work together.

There are three particular areas of front-end expertise we’re obsessed with…

Pattern Libraries

We caught the design systems bug years ago, way back when Natalie started pioneering pattern libraries as our primary deliverable (or pattern portfolios, as we called them then). This approach has proven effective time and time again. We’ve spent years now refining our workflow and thinking around modular design. Fractal is the natural expression of this obsession. Danielle and Mark have been working flat-out on version 2. They’re very eager to share everything they’ve learned along the way …and help others put together solid pattern libraries.

Danielle Huntrods Mark Perkins

Performance

Thinking about it, it’s no surprise that we’re crazy about performance at Clearleft. Like I said, our focus on user experience, and when it comes to user experience on the web, nothing but nothing is more important than performance. The good news is that the majority of performance fixes can be done on the front end—images, scripts, fonts …it’s remarkable how much a good front-end overhaul can make to the bottom line. That’s what Graham has been obsessing over.

Graham Smith

Progressive Web Apps

Over the years I’ve found myself getting swept up in exciting new technologies on the web. When Clearleft first formed, my head was deep into DOM Scripting and Ajax. Half a decade later it was HTML5. Now it’s service workers. I honestly think it’s a technology that could be as revolutionary as Ajax or HTML5 (maybe I should write a book to that effect).

I’ve been talking about service workers at conferences this year, and I can’t hide my excitement:

There’s endless possibilities of what you can do with this technology. It’s very powerful.

Combine a service worker with a web app manifest and you’ve got yourself a Progressive Web App. It’s not just a great marketing term—it’s an opportunity for the web to truly excel at delivering the kind of user experiences previously only associated with native apps.

Jeremy Keith

I’m very very keen to work with companies and organisations that want to harness the power of service workers and Progressive Web Apps. If that’s you, get in touch.

Whether it’s pattern libraries, performance, or Progressive Web Apps, we’ve got the skills and expertise to share with you.

Designing the Patterns Day site

Patterns Day is not one of Clearleft’s slick’n’smooth conferences like dConstruct or UX London. It’s more of a spit’n’sawdust affair, like Responsive Day Out.

You can probably tell from looking at the Patterns Day website that it wasn’t made by a crack team of designers and developers—it’s something I threw together over the course of a few days. I had a lot of fun doing it.

I like designing in the browser. That’s how I ended up designing Resilient Web Design, The Session, and Huffduffer back in the day. But there’s always the initial problem of the blank page. I mean, I had content to work with (the information about the event), but I had no design direction.

My designery colleagues at Clearleft were all busy on client projects so I couldn’t ask any of them to design a website, but I thought perhaps they’d enjoy a little time-limited side exercise in producing ideas for a design direction. Initially I was thinking they could all get together for a couple of hours, lock themselves in a room, and bash out some ideas as though it were a mini hack farm. Coordinating calendars proved too tricky for that. So Jon came up with an alternative: a baton relay.

Remember Layer Tennis? I once did the commentary for a Layer Tennis match and it was a riot—simultaneously terrifying and rewarding.

Anyway, Jon suggested something kind of like that, but instead of a file being batted back and forth between two designers, the file would passed along from designer to designer. Each designer gets one art board in a Sketch file. You get to see what the previous designers have done, leaving you to either riff on that or strike off in a new direction.

The only material I supplied was an early draft of text for the website, some photos of the first confirmed speakers, and some photos I took of repeating tiles when I was in Porto (patterns, see?). I made it clear that I wasn’t looking for pages or layouts—I was interested in colour, typography, texture and “feel.” Style tiles, yes; comps, no.

Jon

Jon’s art board.

Jon kicks things off and immediately sets the tone with bright, vibrant colours. You can already see some elements that made it into the final site like the tiling background image of shapes, and the green-bordered text block. There are some interesting logo ideas in there too, some of them riffing on LEGO, others riffing on illustrations from Christopher Alexander’s book, A Pattern Language. Then there’s the typeface: Avenir Next. I like it.

James G

James G’s art board.

Jimmy G is up next. He concentrates on the tiles idea. You can see some of the original photos from Porto in the art board, alongside his abstracted versions. I think they look great, and I tried really hard to incorporate them into the site, but I couldn’t quite get them to sit with the other design elements. Looking at them now, I still want to get them into the site …maybe I’ll tinker with the speaker portraits to get something more like what James shows here.

Ed

Ed’s art board.

Ed picks up the baton and immediately iterates through a bunch of logo ideas. There’s something about the overlapping text that I like, but I’m not sure it fits for this particular site. I really like the effect of the multiple borders though. With a bit more time, I’d like to work this into the site.

James B

Batesy’s art board.

Batesy is the final participant. He has some other nice ideas in there, like the really subtle tiling background that also made its way into the final site (but I’ll pass on the completely illegible text on the block of bright green). James works through two very different ideas for the logo. One of them feels a bit too busy and chaotic for me, but the other one …I like it a lot.

I immediately start thinking “Hmm …how could I make this work in a responsive way?” This is exactly the impetus I needed. At this point I start diving into CSS. Not only did I have some design direction, I’m champing at the bit to play with some of these ideas. The exercise was a success!

Feel free to poke around the Patterns Day site. And while you’re there, pick up a ticket for the event too.

Open source

Building and maintaining an open-source project is hard work. That observation is about as insightful as noting the religious affiliation of the pope or the scatological habits of woodland bears.

Nolan Lawson wrote a lengthy post describing what it feels like to be an open-source maintainer.

Outside your door stands a line of a few hundred people. They are patiently waiting for you to answer their questions, complaints, pull requests, and feature requests.

You want to help all of them, but for now you’re putting it off. Maybe you had a hard day at work, or you’re tired, or you’re just trying to enjoy a weekend with your family and friends.

But if you go to github.com/notifications, there’s a constant reminder of how many people are waiting

Most of the comments on the post are from people saying “Yup, I hear ya!”

Jan wrote a follow-up post called Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source:

Just because there are people with problems in front of your door, that doesn’t mean they are your problems. You can choose to make them yours, but you want to be very careful about what to care about.

There’s also help at hand in the shape of Open Source Guides created by Nadia Eghbal:

A collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project.

I’m sure Mark can relate to all of the tales of toil that come with being an open-source project maintainer. He’s been working flat-out on Fractal, sometimes at work, but often at home too.

Fractal isn’t really a Clearleft project, at least not in the same way that something like Silverback or UX London is. We’re sponsoring Fractal as much as we can, but an open-source project doesn’t really belong to anyone; everyone is free to fork it and take it. But I still want to make sure that Mark and Danielle have time at work to contribute to Fractal. It’s hard to balance that with the bill-paying client work though.

I invited Remy around to chat with them last week. It was really valuable. Mind you, Remy was echoing many of the same observations made in Nolan’s post about how draining this can be.

So nobody here is under any illusions that this open-source lark is to be entered into lightly. It can be a gruelling exercise. But then it can also be very, very rewarding. One kind word from somebody using your software can make your day. I was genuinely pleased as punch when Danish agency Shift sent Mark a gift to thank him for all his hard work on Fractal.

People can be pretty darn great (which I guess is an underlying principle of open source).

Code (p)reviews

I’m not a big fan of job titles. I’ve always had trouble defining what I do as a noun—I much prefer verbs (“I make websites” sounds fine, but “website maker” sounds kind of weird).

Mind you, the real issue is not finding the right words to describe what I do, but rather figuring out just what the heck it is that I actually do in the first place.

According to the Clearleft website, I’m a technical director. That doesn’t really say anything about what I do. To be honest, I tend to describe my work these days in terms of what I don’t do: I don’t tend to write a lot of HTML, CSS, and JavaScript on client projects (although I keep my hand in with internal projects, and of course, personal projects).

Instead, I try to make sure that the people doing the actual coding—Mark, Graham, and Danielle—are happy and have everything they need to get on with their work. From outside, it might look like my role is managerial, but I see it as the complete opposite. They’re not in service to me; I’m in service to them. If they’re not happy, I’m not doing my job.

There’s another aspect to this role of technical director, and it’s similar to the role of a creative director. Just as a creative director is responsible for the overall direction and quality of designs being produced, I have an oversight over the quality of front-end output. I don’t want to be a bottleneck in the process though, and to be honest, most of the time I don’t do much checking on the details of what’s being produced because I completely trust Mark, Graham, and Danielle to produce top quality code.

But I feel I should be doing more. Again, it’s not that I want to be a bottleneck where everything needs my approval before it gets delivered, but I hope that I could help improve everyone’s output.

Now the obvious way to do this is with code reviews. I do it a bit, but not nearly as much as I should. And even when I do, I always feel it’s a bit late to be spotting any issues. After all, the code has already been written. Also, who am I to try to review the code produced by people who are demonstrably better at coding than I am?

Instead I think it will be more useful for me to stick my oar in before a line of code has been written; to sit down with someone and talk through how they’re going to approach solving a particular problem, creating a particular pattern, or implementing a particular user story.

I suppose it’s really not that different to rubber ducking. Having someone to talk out loud with about potential solutions can be really valuable in my experience.

So I’m going to start doing more code previews. I think it will also incentivise me to do more code reviews—being involved in the initial discussion of a solution means I’m going to want to see the final result.

But I don’t think this should just apply to front-end code. I’d also like to exercise this role as technical director with the designers on a project.

All too often, decisions are made in the design phase that prove problematic in development. It usually works out okay, but it often means revisiting the designs in light of some technical considerations. I’d like to catch those issues sooner. That means sticking my nose in much earlier in the process, talking through what the designers are planning to do, and keeping an eye out for any potential issues.

So, as technical director, I won’t be giving feedback like “the colour’s not working for me” or “not sure about those type choices” (I’ll leave that to the creative director), but instead I can ask questions like “how will this work without hover?” or “what happens when the user does this?” as well as pointing out solutions that might be tricky or time-consuming to implement from a technical perspective.

What I want to avoid is the swoop’n’poop, when someone seagulls in after something has been designed or built and points out all the problems. The earlier in the process any potential issues can be spotted, the better.

And I think that’s my job.

Small steps

The new Clearleft website is live! Huzzah!

Many people have been working very hard on it and it’s all looking rather nice. But, as I said before, the site launch isn’t the end—it’s just the beginning.

There are some obvious next steps: fixing bugs, adding content, tweaking copy, and, oh yeah, that whole “testing with real users” thing. But there’s also an opportunity to have some fun on the front end. Now that the site is out there in the wild, there’s a real incentive to improve its performance.

Off the top of my head, these are some areas where I think we can play around:

  • Font loading. Right now the site is just using @font-face. A smart font-loading strategy—at least for the body copy—could really help improve the perceived performance.
  • Responsive images. A long-term solution will require some wrangling on the back end, but I reckon we can come up with some way of generating different sized images to reference in srcset.
  • Service worker. It’s a no-brainer. Now that the Clearleft site is (finally!) running on HTTPS, having a simple service worker to cache static assets like CSS, JavaScript and some images seems like the obvious next step. The question is: what other offline shenanigans could we get up to?

I’m looking forward to tinkering with some of those technologies. Each one should make an incremental improvement to the site’s performance. There are already some steps on the back-end that are making a big difference: upgrading to PHP7 and using HTTP2.

Now the real fun begins.

Charlotte

Over the eleven-year (and counting) lifespan of Clearleft, people have come and gone—great people like Nat, Andy, Paul and many more. It’s always a bittersweet feeling. On the one hand, I know I’ll miss having them around, but on the other hand, I totally get why they’d want to try their hand at something different.

It was Charlotte’s last day at Clearleft last Friday. Her husband Tom is being relocated to work in Sydney, which is quite the exciting opportunity for both of them. Charlotte’s already set up with a job at Atlassian—they’re very lucky to have her.

So once again there’s the excitement of seeing someone set out on a new adventure. But this one feels particularly bittersweet to me. Charlotte wasn’t just a co-worker. For a while there, I was her teacher …or coach …or mentor …I’m not really sure what to call it. I wrote about the first year of learning and how it wasn’t just a learning experience for Charlotte, it was very much a learning experience for me.

For the last year though, there’s been less and less of that direct transfer of skills and knowledge. Charlotte is definitely not a “junior” developer any more (whatever that means), which is really good but it’s left a bit of a gap for me when it comes to finding fulfilment.

Just last week I was checking in with Charlotte at the end of a long day she had spent tirelessly working on the new Clearleft site. Mostly I was making sure that she was going to go home and not stay late (something that had happened the week before which I wanted to nip in the bud—that’s not how we do things ‘round here). She was working on a particularly gnarly cross-browser issue and I ended up sitting with her, trying to help work through it. At the end, I remember thinking “I’ve missed this.”

It hasn’t been all about HTML, CSS, and JavaScript. Charlotte really pushed herself to become a public speaker. I did everything I could to support that—offering advice, giving feedback and encouragement—but in the end, it was all down to her.

I can’t describe the immense swell of pride I felt when Charlotte spoke on stage. Watching her deliver her talk at Dot York was one my highlights of the year.

Thinking about it, this is probably the perfect time for Charlotte to leave the Clearleft nest. After all, I’m not sure there’s anything more I can teach her. But this feels like a particularly sad parting, maybe because she’s going all the way to Australia and not, y’know, starting a new job in London.

In our final one-to-one, my stiff upper lip may have had a slight wobble as I told Charlotte what I thought was her greatest strength. It wasn’t her work ethic (which is incredibly strong), and it wasn’t her CSS skills (‘though she is now an absolute wizard). No, her greatest strength, in my opinion, is her kindness.

I saw her kindness in how she behaved with her colleagues, her peers, and of course in all the fantastic work she’s done at Codebar Brighton.

I’m going to miss her.

Looking beyond launch

It’s all go, go, go at Clearleft while we’re working on a new version of our website …accompanied by a brand new identity. It’s an exciting time in the studio, tinged with the slight stress that comes with any kind of unveiling like this.

I think it’s good to remember that this is the web. I keep telling myself that we’re not unveiling something carved in stone. Even after the launch we can keep making the site better. In fact, if we wait until everything is perfect before we launch, we’ll probably never launch at all.

On the other hand, you only get one chance to make a first impression, right? So it’s got to be good …but it doesn’t have to be done. A website is never done.

I’ve got to get comfortable with that. There’s lots of things that I’d like to be done in time for launch, but realistically it’s fine if those things are completed in the subsequent days or weeks.

Adding a service worker and making a nice offline experience? I really want to do that …but it can wait.

What about other performance tweaks? Yes, we’ll to try have every asset—images, fonts—optimised …but maybe not from day one.

Making sure that each page has good metadata—Open Graph? Twitter Cards? Microformats? Maybe even AMP? Sure …but not just yet.

Having gorgeous animations? Again, I really want to have them but as Val rightly points out, animations are an enhancement—a really, really great enhancement.

If anything, putting the site live before doing all these things acts as an incentive to make sure they get done.

So when you see the new site, if you view source or run it through Web Page Test and spot areas for improvement, rest assured we’re on it.

Fractal ways

24 Ways is back! That’s how we web nerds know that the Christmas season is here. It kicked off this year with a most excellent bit of hardware hacking from Seb: Internet of Stranger Things.

The site is looking lovely as always. There’s also a component library to to accompany it: Bits, the front-end component library for 24 ways. Nice work, courtesy of Paul. (I particularly like the comment component example).

The component library is built with Fractal, the magnificent tool that Mark has open-sourced. We’ve been using at Clearleft for a while now, but we haven’t had a chance to make any of the component libraries public so it’s really great to be able to point to the 24 Ways example. The code is all on Github too.

There’s a really good buzz around Fractal right now. Lots of people in the design systems Slack channel are talking about it. There’s also a dedicated Fractal Slack channel for people getting into the nitty-gritty of using the tool.

If you’re currently wrestling with the challenges of putting a front-end component library together, be sure to give Fractal a whirl.

On the side

My role at Clearleft is something along the lines of being a technical director. I’m not entirely sure what that means, but it seems to be a way of being involved in front-end development, without necessarily writing much actual code. That’s probably for the best. My colleagues Mark, Graham, and Charlotte are far more efficient at doing that. In return, I do my best to support them and make sure that they’ve got whatever they need (in terms of resources, time, and space) to get on with their work.

I’m continuously impressed not only by the quality of their output on client projects, but also by their output on the side.

Mark is working a project called Fractal. It’s a tool for creating component libraries, something he has written about before. The next steps involve getting the code to version 1.0 and completing the documentation. Then you’ll be hearing a lot more about this. The tricky thing right now is fitting it in around client work. It’s going to be very exciting though—everyone who has been beta-testing Fractal has had very kind words to say. It’s quite an impressive piece of work, especially considering that it’s the work of one person.

Graham is continuing on his crazily-ambitious project to recreate the classic NES game Legend Of Zelda using web technology. His documentation of his process is practically a book:

  1. Introduction,
  2. The Game Loop,
  3. Drawing to the Screen,
  4. Handling User Input,
  5. Scaling the Canvas,
  6. Animation — Part 1,
  7. Levels & Collision — part 1, and most recently
  8. Levels — part 2.

It’s simultaneously a project that involves the past—retro gaming—and the future—playing with the latest additions to JavaScript in modern browsers (something that feeds directly back into client work).

Charlotte has been speaking up a storm. She spoke at the Up Front conference in Manchester about component libraries:

The process of building a pattern library or any kind of modular design system requires a different approach to delivering a set of finished pages. Even when the final deliverable is a pattern library, we often still have to design pages for approval. When everyone is so used to working with pages, it can be difficult to adopt a new way of thinking—particularly for those who are not designers and developers.

This talk will look at how we can help everyone in the team adopt pattern thinking. This includes anyone with a decision to make—not just designers and developers. Everyone in the team can start building a shared vocabulary and attempt to make the challenge of naming things a little easier.

Then she spoke at Dot York about her learning process:

As a web developer, I’m learning all the time. I need to know how to make my code work, but more importantly, I want to understand why my code works. I’ve learnt most of what I know from people sharing what they know and I love that I can now do the same. In my talk I want to share my highlights and frustrations of continuous learning, my experiences of working with a mentor and fitting it into my first year at Clearleft.

She’ll also be speaking at Beyond Tellerrand in Berlin later this year. Oh, and she’s also now a co-organiser of the brilliant Codebar events that happen every Tuesday here in Brighton.

Altogether that’s an impressive amount of output from Clearleft’s developers. And all of that doesn’t include the client work that Mark, Graham, and Charlotte are doing. They inspire me!

Content Buddy

I have a new role at Clearleft. It’s not a full-time role. It’s in addition to my existing role of …um …whatever it is I do at Clearleft.

Anyway, my new part-time role is that of being a content buddy. Sounds a little dismissive when I put it like that. Let me put in capitals…

My new part-time role is that of being a Content Buddy.

This is Ellen’s idea. She’s been recruiting Content Guardians and Content Buddies. The Guardians will be responsible for coaxing content out of people, encouraging to write that blog post, article, or case study. The role of the Content Buddy is to help shepherd those pieces into the world.

I have let it be known throughout the office that I am available—day or night, rain or shine—for proof-reading, editing, and general brain-storming and rubber-ducking.

On my first official day as a Content Buddy on Friday I helped Ben polish off a really good blog post (watch this space), listened to a first run-through of Charlotte’s upcoming talk at the Up Front conference in Manchester (which is shaping up to be most excellent), and got together with Paul for a mutual brainstorming session for future conference talks. The fact that Paul is no longer a full-time employee at Clearleft is a mere technicality—Content Buddies for life!

Paul is preparing a talk on design systems for Smashing Conference in Freiburg in September. I’m preparing a talk on the A element for the HTML Special part of CSS Day in Amsterdam in just one month’s time (gulp!). We had both already done a bit of mind-mapping to get a jumble of ideas down on paper. We learned that from Ellen’s excellent workshop.

Talk prep, phase 1: doodling.

Then we started throwing ideas back and forth, offering suggestions, and spotting patterns. Once we had lots of discrete chunks of stuff outlined (but no idea how to piece them together), we did some short intense spurts of writing using the fiendish TheMostDangerousWritingApp.com. I looked at Paul’s mind map, chose a topic from it for him, and he had to write on that non-stop for three to five minutes. Meanwhile he picked a topic from my mind map and I had to do the same. It was exhausting but also exhilarating. Very quickly we had chunks of content that we could experiment with, putting them in together in different ways to find different narrative threads. I might experiment with publishing them as short standalone blog posts.

The point was not to have polished, finished content but rather to get to the “shitty first draft” stage quickly. We were following Hemingway’s advice:

Write drunk, edit sober.

…but not literally. Mind you, I could certainly imagine combining beer o’clock on Fridays with Content Buddiness. That wasn’t an option on this particular Friday though, as I had to run off to band practice with Salter Cane. A very different, and altogether darker form of content creation.

Design sprinting

James and I went to Ipswich last week for work. But this wasn’t part of an ongoing project—this was a short intense one-week feasibility study.

Leon from Suffolk Libraries got in touch with us about a project they’re planning to carry out soon: replacing their self-service machines with something more up-to-date. But rather than dive into commissioning the project straight away, he wisely decided to start with a one-week sprint to figure out exactly what the project would need to go ahead.

So that’s what James and I did. It was somewhat similar to the design sprint popularised by GV. We ensconced ourselves in the Ipswich library and packed a whole lot of work into five days. There was lots of collaboration, lots of sketching, lots of iterative design, and some rough’n’ready code. It was challenging, but a lot of fun. Also: we stayed in a pretty sweet AirBnB.

Our home for the week. This is a nice AirBnB.

You can read all about it in our case study. You can also read all about from Leon’s point of view on his blog:

I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project – all in the space of 5 days.

I think this approach makes a lot of sense. By the end of the week, James and I felt pretty confident about estimating times and costs for the full project. Normally trying to estimate that kind of thing can be a real guessing game. But with the small of investment of one week’s worth of effort, you get a whole lot more certainty and confidence.

Have a look for yourself.

One day in London

I don’t get up to London all that often—maybe once every few weeks; just long enough for the city’s skyline to have changed again. Yesterday was one of those days out in the big smoke.

I started with a visit to the Royal College of Art to see the work in progress exhibition that’s running until Sunday. Specifically, I wanted to see the project by Monika, who was one third of the immensely talented internship collaboration at Clearleft that produced notice.city. Her current project is called Watching the Watchers, all about undersea cables, surveillance, and audio—right up my alley. I think Ingrid, James, Dan, and Georgina would like it.

Checking out Monika’s work in progress at the RCA. Watching the watchers

After that, I entered a metal tube to be whisked across the city to the Hospital Club, where a room had been booked for a most enjoyable Clearleft event. Anna had organised a second of her roundtable gatherings. This time the theme was “going responsive.”

The idea is to gather people together for one afternoon to share experiences and challenges. Anna invited people from all sorts of organisations, from newspapers to e-commerce and everything in between. Some of them were people we already knew, but most of them had no connection to Clearleft at all.

Everything happened the Chatham House Rule so I can’t tell you the details of who said what, but I can tell you that it was very productive afternoon. Some of the companies represented were in the process of switching to responsive, some had already done it, and some were planning it, so it was a perfect mix.

We began with a variation on the lean coffee technique. Splitting into groups, everyone jotted down some topics that they wanted to discuss. We shared those, grouped them, and voted on which order we would discuss them. Each topic got 5 to 10 minutes of discussion. In my group, we discussed strategy, workflow, tools, and more. We could’ve easily talked for longer. Some outcomes (very badly summarised):

  • The vision and strategy for a responsive redesign needs to be communicated (and sold) up the chain to stakeholders as well as to the designers and developers in the trenches.
  • “Mobile-first” For The Win! Solve the harder problems first.
  • Multi-disciplinary teams For The Win! Works well with Agile too.
  • A pattern libraries is probably the best tool you can have. So pattern libraries For The Win too!

After a break, we switched over in to a sort of open space exercise. Anyone who has a burning question they want answered writes that question down on an oversize post-it and slaps it on the wall. Now we’ve got a room with questions written on different parts of the wall. If you want to take a stab at answering any of those questions, you write it down on a post it note and slap it next to the question. Everyone does this for a while, going from question to question and having lots of good discussion. Then, at the end, we go from question to question, with the person who originally posted the question taking ownership of summarising the answers.

Some of the questions were:

  • How to help people to stop thinking “desktop first”?
  • Should designers code? Should developers design? Or Both?
  • How do you start to deploy a responsive version of an existing site?
  • How do you do responsive ads?
  • What is the best tool to use to create responsive designs?
  • Would every project benefit from a design system? Is it always worth the investment?

You get the idea. The format worked really well; it was the first time any of us had tried it. We slightly over-ran the time we had allotted for the afternoon, but that’s mostly because there was so much meaty stuff to discuss.

Playback

With that productive afternoon done, I made my way to the Bricklayer’s Arms, where by lucky coincidence, a Pub Standards meet-up was happening. I went along for a pint and a chat while I waited for rush hour to ease off: I wanted to avoid the crush before I started making my way back to Brighton. See you next time, Londinium.