Tags: clearleft

56

sparkline

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.

A year of learning

An anniversary occurred last week that I don’t want to let pass by unremarked. On November 24th of last year, I made this note:

Welcoming @LotteJackson on her first day at @Clearleft.

Charlotte’s start at Clearleft didn’t just mark a new chapter for her—it also marked a big change for me. I’ve spent the last year being Charlotte’s mentor. I had no idea what I was doing.

Lyza wrote a post about mentorship a while back that really resonated with me:

I had no idea what I was doing. But I was going to do it anyway.

Hiring Charlotte coincided with me going through one of those periods when I ask myself, “Just what is it that I do anyway?” (actually, that’s pretty much a permanent state of being but sometimes it weighs heavier than others).

Let me back up a bit and explain how Charlotte ended up at Clearleft in the first place.

Clearleft has always been a small agency, deliberately so. Over the course of ten years, we might hire one, maybe two people a year. Because of that small size, anyone joining the company had to be able to hit the ground running. To put it into jobspeak, we could only hire “senior” level people—we just didn’t have the resources to devote to training up anyone less experienced.

That worked pretty well for a while but as the numbers at Clearleft began to creep into the upper teens, it became clear that it wasn’t a sustainable hiring policy—most of the “senior” people are already quite happily employed. So we began to consider the possibility of taking on somebody in a “junior” role. But we knew we could only do that if it were somebody else’s role to train them. Like I said, this was ‘round about the time I was questioning exactly what my role was anyway, so I felt ready to give it a shot.

Hiring Charlotte was an experiment for Clearleft—could we hire someone in a “junior” position, and then devote enough time and resources to bring them up to a “senior” level? (those quotes are air quotes—I find the practice of labelling people or positions “junior” or “senior” to be laughably reductionist; you might as well try to divide the entire web into “apps” and “sites”).

Well, it might only be one data point, but this experiment was a resounding success. Charlotte is a fantastic front-end developer.

Now I wish I could take credit for that, but I can’t. I’ve done my best to support, encourage, and teach Charlotte but none of that would matter if it weren’t for Charlotte’s spirit: she’s eager to learn, eager to improve, and crucially, eager to understand.

Christian wrote something a while back that stuck in my mind. He talked about the Full Stack Overflow Developer:

Full Stack Overflow developers work almost entirely by copying and pasting code from Stack Overflow instead of understanding what they are doing. Instead of researching a topic, they go there first to ask a question hoping people will just give them the result.

When we were hiring for the junior developer role that Charlotte ended up filling, I knew exactly what I didn’t want and Christian described it perfectly.

Conversely, I wasn’t looking for someone with plenty of knowledge—after all, knowledge was one of the things that I could perhaps pass on (stop sniggering). As Philip Walton puts it:

The longer I work on the web, the more I realize that what separates the good people from the really good people isn’t what they know; it’s how they think. Obviously knowledge is important—critical in some cases—but in a field that changes so quickly, how you go about acquiring that knowledge is always going to be more important (at least in the long term) than what you know at any given time. And perhaps most important of all: how you use that knowledge to solve everyday problems.

What I was looking for was a willingness—nay, an eagerness—to learn. That’s what I got with Charlotte. She isn’t content to copy and paste a solution; she wants to know why something works.

So a lot of my work for the past year has been providing a framework for Charlotte to learn within. It’s been less of me teaching her, and more of me pointing her in the right direction to teach herself.

There has been some traditional instruction along the way: code reviews, pair programming, and all of that stuff, but often the best way for Charlotte to learn is for me to get out of the way. Still, I’m always on hand to try to answer any questions or point her in the direction of a solution. I think sometimes Charlotte might regret asking me things, like a simple question about the box model.

I’ve really enjoyed those moments of teaching. I haven’t always been good at it. Sometimes, especially at the beginning, I’d lose patience. When that happened, I’d basically be an asshole. Then I’d realise I was being an asshole, apologise, and try not to do it again. Over time, I think I got better. I hope that those bursts of assholery are gone for good.

Now that Charlotte has graduated into a fully-fledged front-end developer, it’s time for me to ask myself once again, “Just what is it that I do anyway?”

But at least now I have some more understanding about what I like to do. I like to share. I like to teach.

I can very much relate to Chen Hui Jing’s feelings:

I suppose for some developers, the job is a just a means to earn a paycheck. But I truly hope that most of us are in it because this is what we love to do. And that we can raise awareness amongst developers who are earlier in their journey than ourselves on the importance of best practices. Together, we can all contribute to building a better web.

I’m writing this to mark a rewarding year of teaching and learning. Now I need to figure out how to take the best parts of that journey and apply it to the ongoing front-end development work at Clearleft with Mark, Graham, and now, Charlotte.

I have no idea what I’m doing. But I’m going to do it anyway.

Notice

We’ve been doing a lot of soul-searching at Clearleft recently; examining our values; trying to make implicit unspoken assumptions explicit and spoken. That process has unearthed some activities that have been at the heart of our company from the very start—sharing, teaching, and nurturing. After all, Clearleft would never have been formed if it weren’t for the generosity of people out there on the web sharing with myself, Andy, and Richard.

One of the values/mottos/watchwords that’s emerging is “Share what you learn.” I like that a lot. It echoes the original slogan of the World Wide Web project, “Share what you know.” It’s been a driving force behind our writing, speaking, and events.

In the same spirit, we’ve been running internship programmes for many years now. John is the latest of a long line of alumni that includes Anna, Emil, and James.

By the way—and this should go without saying, but apparently it still needs to be said—the internships are always, always paid. I know that there are other industries where unpaid internships are the norm. I’ve even heard otherwise-intelligent people defend those unpaid internships for the experience they offer. But what kind of message does it send to someone about the worth of their work when you withhold payment for it? Our industry is young. Let’s not fall foul of the pernicious traps set by older industries that have habitualised exploitation.

In the past couple of years, Andy concocted a new internship scheme:

So this year we decided to try a different approach by scouring the end of year degree shows for hot new talent. We found them not in the interaction courses as we’d expected, but from the worlds of Product Design, Digital Design and Robotics. We assembled a team of three interns , with a range of complementary skills, gave them a space on the mezzanine floor of our new building, and set them a high level brief.

The first such programme resulted in Chüne. The latest Clearleft internship project has just come to an end. The result is Notice.

This time ‘round, the three young graduates were Chloe, Chris and Monika. They each have differing but complementary skill sets: Chloe is a user interface designer; Chris is a product designer; Monika is an artist who knows her way around hardware hacking and coding.

I’ll miss having this lot in the Clearleft office.

Once again, they were set a fairly loose brief. They should come up with something “to enrich the lives of local residents” and it should have a physical and digital component to it.

They got stuck in to researching and brainstorming ideas. At the end of each week, we’d all gather together to get a playback of what they were coming up with. It was at these playbacks that the interns were introduced to a concept that they will no doubt encounter again in their professional lives: seagulling AKA the swoop and poop. For once, it was the Clearlefties who were in the position of being swoop-and-poopers, rather than swoop-and-poopies.

Playback at Clearleft

As the midway point of the internship approached, there were some interesting ideas, but no clear “winner” to pursue. Something else was happening around this time too: dConstruct 2015.

Chloe, Monika and Chris at dConstruct

The interns pitched in with helping out at the event, and in return, we kidnapped some of the speakers—namely John Willshire and Chris Noessel—to offer them some guidance.

There was also plenty of inspiration to be had from the dConstruct talks themselves. One talk in particular struck a chord: Dan Hill’s The City Of Things …especially the bit where he railed against the terrible state of planning application notices:

Most of the time, it ends up down the bottom of the lamppost—soiled and soggy and forgotten. This should be an amazing thing!

Hmm… sounds like something that could enrich the lives of local residents.

Not long after that, Matt Webb came to visit. He encouraged the interns to focus in on just the two ideas that really excited them rather then the 5 or 6 that they were considering. So at the next playback, they presented two potential projects—one about biking and the other about city planning. They put it to a vote and the second project won by a landslide.

That was the genesis of Notice. After that, they pulled out all the stops.

Exciting things are afoot with the @Clearleftintern project.

Not content with designing one device, they came up with a range of three devices to match the differing scope of planning applications. They set about making a working prototype of the device intended for the most common applications.

Monika and Chris, hacking

Last week marked the end of the project and the grand unveiling.

Playing with the @notice_city prototype. Chris breaks it down. Playback time. Unveiling.

They’ve done a great job. All the details are on the website, including this little note I wrote about the project:

This internship programme was an experiment for Clearleft. We wanted to see what would happen if you put through talented young people in a room together for three months to work on a fairly loose brief. Crucially, we wanted to see work that wasn’t directly related to our day-­to-­day dealings with web design.

We offered feedback and advice, but we received so much more in return. Monika, Chloe, and Chris brought an energy and enthusiasm to the Clearleft office that was invigorating. And the quality of the work they produced together exceeded our wildest expectations.

We hereby declare this experiment a success!

Personally, I think the work they’ve produced is very strong indeed. It would be a shame for it to end now. Perhaps there’s a way that it could be funded for further development. Here’s hoping.

Out on the streets of Brighton Prototype

As impressed as I am with the work, I’m even more impressed with the people. They’re not just talented and hard work—they’re a jolly nice bunch to have around.

I’m going to miss them.

The terrific trio!

Brighton device lab

People of Brighton (and environs), I have a reminder for you. Did you know that there is an open device lab in the Clearleft office?

That’s right! You can simply pop in at any time and test your websites on Android, iOS, Windows Phone, Blackberry, Kindles, and more.

The address is 68 Middle Street. Ring the “Clearleft” buzzer and say you’re there to use the device lab.. There’ll always be somebody in the office. They’ll buzz you in and you can take the lift to the first floor. No need to make a prior appointment—feel free to swing by whenever you like.

There is no catch. You show up, test your sites on whatever devices you want, and maybe even stick around for a cup of tea.

Tell your friends.

I was doing a little testing this morning, helping Charlotte with a pesky bug that was cropping up on an iPad running iOS 8. To get the bottom of the issue, I needed to be able to inspect the DOM on the iPad. That turns out to be fairly straightforward (as of iOS 6):

  1. Plug the device into a USB port on your laptop using a lightning cable.
  2. Open Safari on the device and navigate to the page you want to test.
  3. Open Safari on your laptop.
  4. From the “Develop” menu in your laptop’s Safari, select the device.
  5. Use the web inspector on your laptop’s Safari to inspect elements to your heart’s content.

It’s a similar flow for Android devices:

  1. Plug the device into a USB port on your laptop.
  2. Open Chrome on the device and navigate to the page you want to test.
  3. Open Chrome on your laptop.
  4. Type chrome://inspect into the URL bar of Chrome on your laptop.
  5. Select the device.
  6. On the device, grant permission (a dialogue will have appeared by now).
  7. Use developer tools on your laptop’s Chrome to inspect elements to your heart’s content.

Using web inspector in Safari to inspect elements on a web page open on an iOS device. Using developer tools in Chrome to inspect elements on a web page open on an Android device.

Storyforming

It was only last week that myself and Ellen were brainstorming ideas for a combined workshop. Our enthusiasm got the better of us, and we said “Let’s just do it!” Before we could think better of it, the room was booked, and the calendar invitations were sent.

Workshopping

The topic was “story.”

No wait, maybe it was …”narrative.”

That’s not quite right either.

“Content,” perhaps?

Basically, here’s the issue: at some point everyone at Clearleft needs to communicate something by telling a story. It might be a blog post. It might be a conference talk. It might be a proposal for a potential client. It might be a case study of our work. Whatever form it might take, it involves getting a message across …using words. Words are hard. We wanted to make them a little bit easier.

We did two workshops. Ellen’s was yesterday. Mine was today. They were both just about two hours in length.

Get out of my head!

Ellen’s workshop was all about getting thoughts out of your head and onto paper. But before we could even start to do that, we had to confront our first adversary: the inner critic.

You know the inner critic. It’s that voice inside you that says “You’ve got nothing new to say”, or “You’re rubbish at writing.” Ellen encouraged each of us to drag this inner critic out into the light—much like Paul Ford did with his AnxietyBox.

Each of us drew a cartoon of our inner critic, complete with speech bubbles of things our inner critic says to us.

Drawing our inner critic inner critics

In a bizarre coincidence, Chloe and I had exactly the same inner critic, complete with top hat and monocle.

With that foe vanquished, we proceeded with a mind map. The idea was to just dump everything out of our heads and onto paper, without worrying about what order to arrange things in.

I found it to be an immensely valuable exercise. Whenever I’ve tried to do this before, I’d open up a blank text file and start jotting stuff down. But because of the linear nature of a text file, there’s still going to be an order to what gets jotted down; without meaning to, I’ve imposed some kind of priority onto the still-unformed thoughts. Using a mind map allowed me get everything down first, and then form the connections later.

mind mapping

There were plenty of other exercises, but the other one that really struck me was a simple framework of five questions. Whatever it is that you’re trying to say, write down the answers to these questions about your audience:

  1. What are they sceptical about?
  2. What problems do they have?
  3. What’s different now that you’ve communicated your message?
  4. Paint a pretty picture of life for them now that you’ve done that.
  5. Finally, what do they need to do next?

They’re straightforward questions, but the answers can really help to make sure you’re covering everything you need to.

There were many more exercises, and by the end of the two hours, everyone had masses of raw material, albeit in an unstructured form. My workshop was supposed to help them take that content and give it some kind of shape.

The structure of stories

Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.

This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.

So I was interested in separating the plot of a story from the narrative device used to tell the story.

To start with, I gave some examples of well-known stories with relatively straightforward plots:

  • Star Wars,
  • Little Red Riding Hood,
  • Your CV,
  • Jurassic Park, and
  • Ghostbusters.

I asked everyone to take a story (either from that list, or think of another one) and write the plot down on post-it notes, one plot point per post-it. Before long, the walls were covered with post-its detailing the plot lines of:

  • Robocop,
  • Toy Story,
  • Back To The Future,
  • Elf,
  • E.T.,
  • The Three Little Pigs, and
  • Pretty Woman.

Okay. That’s plot. Next we looked at narrative frameworks.

Narrative frameworks as Oblique Strategies.

Flashback

Begin at a crucial moment, then back up to explain how you ended up there.

e.g. Citizen Kane “Rosebud!”

Dialogue

Instead of describing the action directly, have characters tell it to one another.

e.g. The Dialogues of Plato …or The Breakfast Club (or one of my favourite sci-fi short stories).

In Media Res

Begin in the middle of the action. No exposition allowed, but you can drop hints.

e.g. Mad Max: Fury Road (or Star Wars, if it didn’t have the opening crawl).

Backstory

Begin with a looooong zooooom into the past before taking up the story today.

e.g. 2001: A Space Odyssey.

Distancing Effect

Just the facts with no embellishment.

e.g. A police report.

You get the idea.

In a random draw, everyone received a card with a narrative device on it. Now they had to retell the story they chose using that framing. That led to some great results:

  • Toy Story, retold as a conversation between Andy and his psychiatrist (dialogue),
  • E.T., retold as a missing person’s report on an alien planet (distancing effect),
  • Elf, retold with an introduction about the very first Christmas (backstory),
  • Robocop, retold with Murphy already a cyborg, remembering his past (flashback),
  • The Three Little Pigs, retold with the wolf already at the door and no explanation as to why there’s straw everywhere (in media res).

Once everyone had the hang of it, I asked them to revisit their mind maps and other materials from the previous day’s workshop. Next, they arranged the “chunks” of that story into a linear narrative …but without worrying about getting it right—it’s not going to stay linear for long. Then, everyone is once again given a narrative structure. Now try rearranging and restructuring your story to use that framework. If something valuable comes out of that, great! If not, well, it’s still a fun creative exercise.

And that was pretty much it. I had no idea what I was doing, but it didn’t matter. It wasn’t really about me. It was about helping others take their existing material and play with it.

That said, I’m glad I finally got this process out into the world in some kind of semi-formalised way. I’ve been preparing talks and articles using these narrative exercises for a while, but this workshop was just the motivation I needed to put some structure on the process.

I think I might try to create a proper deck of cards—along the lines of Brian Eno’s Oblique Strategies or Stephen Andersons’s Mental Notes—so that everyone has the option of injecting a random narrative structural idea into the mix whenever they’re stuck.

At the very least, it would be a distraction from listening to that pesky inner critic.

100 words 087

Clearleft is ten years old this year (and yes, we do have some celebrations planned). It’s funny to think back to 2005 when Andy, Richard, and myself joined forces to make a little design agency with no clients and no office.

Here we are in 2015 and we have our own building, we’re working with great clients, and there are 21 of us now …not that growth is any indicator of success—we’ve always stayed cautious in that regard.

Andy, Richard, and myself got together for dinner this evening—a surprisingly rare event these days. It felt like old times.

100 words 079

Today was dogtastic at Clearleft. I knew in advance that Daphne the dachshund was going to be coming by—Kate had given us all the heads-up. But when I arrived in the office, who should greet me but …Poppy the beagle!

I hadn’t seen Poppy in years. But she remembered me. See, when Poppy was just a young dog, we’d play together. I’d get the dog all worked up into a frenzy and then say goodbye, leaving Richard to deal with a hyperactive puppy. That’s why, even now, Poppy’s reaction to me is to howl in a “let’s play!” way.

100 words 074

We had an epic front-end pow-wow today. With plenty of Beerleft Goldenrods on hand we ploughed through discussing current client work and then turned to our guests. Today we were joined by Tracy Osborn, who told us all about her lovely new self-published book, Hello Web App. Then we got a demo from our friends at the confusingly named Ind.ie—no relation to the indie web—who gave us a demo of what they’ve been working on. We gave our feedback, including a heartfelt plea to dial down the rhetoric in their public pronouncements.

Then we went to the beach.