Tags: learning



Getting griddy with it

I had the great pleasure of attending An Event Apart Seattle last week. It was, as always, excellent.

It’s always interesting to see themes emerge during an event, especially when those thematic overlaps haven’t been planned in advance. Jen noticed this one:

I remember that being a theme at An Event Apart San Francisco too, when it seemed like every speaker had words to say about ill-judged use of Bootstrap. That theme was certainly in my presentation when I talked about “the fallacy of assumed competency”:

  1. large company X uses technology Y,
  2. company X must know what they are doing because they are large,
  3. therefore technology Y must be good.

Perhaps “the fallacy of assumed suitability” would be a better term. Heydon calls it “the ‘made at Facebook’ fallacy.” But I also made sure to contrast it with the opposite extreme: “Not Invented Here syndrome”.

As well as over-arching themes, it was also interesting to see which technologies were hot topics at An Event Apart. There was one clear winner here—CSS Grid Layout.

Microsoft—a sponsor of the event—used An Event Apart as the place to announce that Grid is officially moving into development for Edge. Jen talked about Grid (of course). Rachel talked about Grid (of course). And while Eric and Una didn’t talk about it on stage, they’ve both been writing about the fun they’ve been having having with Grid. Una wrote about 3 CSS Grid Features That Make My Heart Flutter. Eric is documenting the overall of his site with Grid. So when we were all gathered together, that’s what we were nerding out about.

The CSS Squad.

There are some great resources out there for levelling up in Grid-fu:

With Jen’s help, I’ve been playing with CSS Grid on a little site that I’m planning to launch tomorrow (he said, foreshadowingly). I took me a while to get my head around it, but once it clicked I started to have a lot of fun. “Fun” seems to be the overall feeling around this technology. There’s something infectious about the excitement and enthusiasm that’s returning to the world of layout on the web. And now that the browser support is great pretty much across the board, we can start putting that fun into production.


This year’s Render conference just wrapped up in Oxford. It was a well-run, well-curated event, right up my alley: two days of a single track of design and development talks (see also: An Event Apart and Smashing Conference for other events in this mold that get it right).

One of my favourite talks was from Frances Ng. She gave a thoroughly entertaining account of her journey from aerospace engineer to front-end engineer, filled with ideas about how to get started, and keep from getting overwhelmed in the world of the web.

She recommended taking the time to occasionally dive deep into a foundational topic, pointing to another talk as a perfect example; Ana Balica gave a great presentation all about HTTP. The second half of the talk was about HTTP 2 and was filled with practical advice, but the first part was a thoroughly geeky history of the Hypertext Transfer Protocol, which I really loved.

While I’m mentoring Amber, we’ve been trying to find a good balance between those deep dives into the foundational topics and the hands-on day-to-day skills needed for web development. So far, I think we’ve found a good balance.

When Amber is ‘round at the Clearleft office, we sit down together and work on the practical aspects of HTML, CSS, and (soon) JavaScript. Last week, for example, we had a really great day diving into CSS selectors and specificity—I watched Amber’s knowledge skyrocket over the course of the day.

But between those visits—which happen every one or two weeks—I’ve been giving Amber homework of sorts. That’s where the foundational building blocks come in. Here are the questions I’ve asked so far:

  • What is the difference between the internet and the web?
  • What is the difference between GET and POST?
  • What are cookies?

The first question is a way of understanding the primacy of URLs on the web. Amber wrote about her research. The second question was getting at an understanding of HTTP. Amber wrote about that too. The third and current question is about state on the web. I’m looking forward to reading a write-up of that soon.

We’re still figuring out this whole mentorship thing but I think this balance of research and exercises is working out well.


I really enjoyed teaching in Porto last week. It was like having a week-long series of CodeBar sessions.

Whenever I’m teaching at CodeBar, I like to be paired up with people who are just starting out. There’s something about explaining the web and HTML from first principles that I really like. And people often have lots and lots of questions that I enjoy answering (if I can). At CodeBar—and at The New Digital School—I found myself saying “Great question!” multiple times. The really great questions are the ones that I respond to with “I don’t know …let’s find out!”

CodeBar is always a very rewarding experience for me. It has given me the opportunity to try teaching. And having tried it, I can now safely say that I like it. It’s also a great chance to meet people from all walks of life. It gets me out of my bubble.

I can’t remember when I was first paired up with Amber at CodeBar. It must have been sometime last year. I do remember that she had lots of great questions—at some point I found myself explaining how hexadecimal colours work.

I was impressed with Amber’s eagerness to learn. I also liked that she was making her own website. I told her about Homebrew Website Club and she started coming along to that (along with other CodeBar people like Cassie and Alice).

I’ve mentioned to multiple CodeBar students that there’s pretty much an open-door policy at Clearleft when it comes to shadowing: feel free to come along and sit with a front-end developer while they’re working on client projects. A few people have taken up the offer and enjoyed observing myself or Charlotte at work. Amber was one of those people. Again, I was very impressed with her drive. She’s got a full-time job (with sometimes-crazy hours) but she’s so determined to get into the world of web design and development that she’s willing to spend her free time visiting Clearleft to soak up the atmosphere of a design studio.

We’ve decided to turn this into something more structured. Amber and I will get together for a couple of hours once a week. She’s given me a list of some of the areas she wants to explore, and I think it’s a fine-looking list:

  • I want to gather base, structural knowledge about the web and all related aspects. Things seem to float around in a big cloud at the moment.
  • I want to adhere to best practices.
  • I want to learn more about what direction I want to go in, find a niche.
  • I’d love to opportunity to chat with the brilliant people who work at Clearleft and gain a broad range of knowledge from them.

My plan right now is to take a two-track approach: one track about the theory, and another track about the practicalities. The practicalities will be HTML, CSS, JavaScript, and related technologies. The theory will be about understanding the history of the web and its strengths and weaknesses as a medium. And I want to make sure there’s plenty of UX, research, information architecture and content strategy covered too.

Seeing as we’ll only have a couple of hours every week, this won’t be quite like the masterclass I just finished up in Porto. Instead I imagine I’ll be laying some groundwork and then pointing to topics to research. I guess it’s a kind of homework. For example, after we talked today, I set Amber this little bit of research for the next time we meet: “What is the difference between the internet and the World Wide Web?”

I’m excited to see where this will lead. I find Amber’s drive and enthusiasm very inspiring. I also feel a certain weight of responsibility—I don’t want to enter into this lightly.

I’m not really sure what to call this though. Is it mentorship? Or is it coaching? Or training? All of the above?

Whatever it is, I’m looking forward to documenting the journey. Amber will be writing about it too. She is already demonstrating a way with words.


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.

Starting out

I had a really enjoyable time at Codebar Brighton last week, not least because Morty came along.

I particularly enjoy teaching people who have zero previous experience of making a web page. There’s something about explaining HTML and CSS from first principles that appeals to me. I especially love it when people ask lots of questions. “What does this element do?”, “Why do some elements have closing tags and others don’t?”, “Why is it textarea and not input type="textarea"?” The answer usually involves me going down a rabbit-hole of web archeology, so I’m in my happy place.

But there’s only so much time at Codebar each week, so it’s nice to be able to point people to other resources that they can peruse at their leisure. It turns out that’s it’s actually kind of tricky to find resources at that level. There are lots of great articles and tutorials out there for professional web developers—Smashing Magazine, A List Apart, CSS Tricks, etc.—but no so much for complete beginners.

Here are some of the resources I’ve found:

  • MarkSheet by Jeremy Thomas is a free HTML and CSS tutorial. It starts with an explanation of the internet, then the World Wide Web, and then web browsers, before diving into HTML syntax. Jeremy is the same guy who recently made CSS Reference.
  • Learn to Code HTML & CSS by Shay Howe is another free online book. You can buy a paper copy too. It’s filled with good, clear explanations.
  • Zero to Hero Coding by Vera Deák is an ongoing series. She’s starting out on her career as a front-end developer, so her perspective is particularly valuable.

If I find any more handy resources, I’ll link to them and tag them with “learning”.

Exploring web technologies

Last week, I had two really enjoyable experiences discussing completely opposite ends of the web technology stack.

Tuesday is Codebar day here in Brighton. Clearleft hosted it at 68 Middle Street last week. I really, really enjoy coaching at Codebar. I particularly like teaching the absolute basics of HTML and CSS. There’s something so rewarding about seeing the “a-ha!” moments when concepts click with people. I also love answering the inevitable questions that arise, like “why is it like that?”, or “how do I do this?”

Fantastic coding tonight! Great to see you all. Thanks for coming and thanks @68MiddleSt & @clearleft for having us.

Thursday was devoted to the opposite end of the spectrum. I ran a workshop at Clearleft with some developers from one of our clients. The whole day was dedicated to exploring and evaluating up-and-coming web technologies. Basically, it was a chance to geek out about all the stuff I’ve been linking to or writing about. During the workshop I ended up making a lot of use of my tagging system here on adactio.com:

Prioritising topics for discussion.

Web components and service workers ended up at the top of the list of technologies to tackle, which was fortuitous, given my recent thoughts on comparing the two:

First of all, ask the question “who benefits from this technology?” In the case of service workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.

The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”

Those two questions turned out to be a good framework for the whole workshop. The question of how to evaluate technologies is something I’ve been thinking about a lot lately. I’m pretty sure it will be what my next conference talk is going to be all about.

You can read more about the structure of the workshop over on the Clearleft site. I’m looking forward to running it again sometime. But I’m equally looking forward to getting back to the basics at the next Codebar.

Class teacher

ES6 introduced a whole bunch of new features to JavaScript. One of those features is the class keyword. This introduction has been accompanied by a fair amount of concern and criticism.

Here’s the issue: classes in JavaScript aren’t quite the same as classes in other programming languages. In fact, technically, JavaScript doesn’t really have classes at all. But some say that technically isn’t important. If it looks like a duck, and quacks like a duck, shouldn’t we call it a duck even if technically it’s somewhat similar—but not quite the same—species of waterfowl?

The argument for doing this is that classes are so familiar from other programming languages, that having some way of using classes in JavaScript—even if it isn’t technically the same as in other languages—brings a lot of benefit for people moving over to JavaScript from other programming languages.

But that comes with a side-effect. Anyone learning about classes in JavaScript will basically be told “here’s how classes work …but don’t look too closely.”

Now if you believe that outcomes matter more than understanding, then this is a perfectly acceptable trade-off. After all, we use computers every day without needing to understand the inner workings of every single piece of code under the hood.

It doesn’t sit well with me, though. I think that understanding how something works is important (in most cases). That’s why I favour learning underlying technologies first—HTML, CSS, JavaScript—before reaching for abstractions like frameworks and libraries. If you understand the way things work first, then your choice of framework, library, or any other abstraction is an informed choice.

The most common way that people refer to the new class syntax in JavaScript is to describe it as syntactical sugar. In other words, it doesn’t fundamentally introduce anything new under the hood, but it gives you a shorter, cleaner, nicer way of dealing with objects. It’s an abstraction. But because it’s an abstraction taken from other programming languages that work differently to JavaScript, it’s a bit of fudge. It’s a little white lie. The class keyword in JavaScript will work just fine as long as you don’t try to understand it.

My personal opinion is that this isn’t healthy.

I’ve come across two fantastic orators who cemented this view in my mind. At Render Conf in Oxford earlier this year, I had the great pleasure of hearing Ashley Williams talk about the challenges of teaching JavaScript. Skip to the 15 minute mark to hear her introduce the issues thrown up classes in JavaScript.

More recently, the mighty Kyle Simpson was on an episode of the JavaScript Jabber podcast. Skip to the 17 minute mark to hear him talk about classes in JavaScript.

(Full disclosure: Kyle also some very kind things about some of my blog posts at the end of that episode, but you can switch it off before it gets to that bit.)

Both Ashley and Kyle bring a much-needed perspective to the discussion of language design. That perspective is the perspective of a teacher.

In his essay on W3C’s design principles, Bert Bos lists learnability among the fundamental driving forces (closely tied to readability). Learnability and teachability are two sides of the same coin, and I find it valuable to examine any language decisions through that lens. With that mind, introducing a new feature into a language that comes with such low teachability value as to warrant a teacher actively telling a student not to learn how things really work …well, that just doesn’t seem right.

Small lessons, loosely learned

When Charlotte published her end-of-year report, she outlined her plans for 2016, which included “Document my JavaScript learning journey.”

I want to get into the habit of writing one JavaScript post every week to make sure I keep up with learning it. Even if it’s just a few words about some relevant terminology; it can be as long or short as desired or time allows, as long as it happens.

An excellent plan! If you really want to make sure you’ve understood something, write down an explanation of it. There’s nothing quite like writing to really test your grasp of an idea. Even if nobody else ever reads it, it’s still an extremely valuable exercise for yourself.

Charlotte has already started. Here’s a short post on using JavaScript to pick a random an item at random from an array:

Math.round(Math.random() * (array.length - 1))

It might seem like a small thing, but look what you have to understand:

  • How Math.round works (pretty straightforward—it rounds a floating point number to the nearest whole number).
  • How Math.random works (less straightforward—it gives a random number between zero and one, meaning you have to multiply it to do anything useful with the result).
  • How array.length works (seems straightforward—it gives you the total number of items in an array, but then catches you out when you realise there can never be an index with that total value because the indices are counted from zero …which gives rise to an entire class of programming error).

I really like this approach to learning: document each small thing as you go instead of waiting until all those individual pieces click together. That’s the approach Andy took when he was learning CSS and it led to him writing a book on the subject.

When it comes to problem-solving in general (and JavaScript in particular), I have a similar bias towards single-purpose solutions. Rather than creating a monolithic framework that attempts to solve all possible problems, I prefer a collection of smaller scripts that only do one thing, but do it really well; the UNIX philosophy.

Take, for example, Remy’s bind.js. It does two-way data-binding and nothing else. If you only need one-way data-binding, there’s Simulacra.js, which takes a similar minimalist, hands-off approach.

This approach of breaking large problems down into a collection of smaller problems also came up in a completely unrelated discussion at work recently. I floated the idea of starting a book club at Clearleft. Quite a few people are into the idea, but they’re not sure they could commit the time to reading a book on a deadline. Fair enough. Perhaps we could have the book club on a chapter-by-chapter basis? I don’t think that would work all that well for novels, but it did make me think of something related to Charlotte’s stated goal of learning more JavaScript…

Graham has been raving about the You Don’t Know JS book series by the supersmart Kyle Simpson. I suggested to Charlotte that we read through the books at the rate of one chapter a week. The first book is called Up and Going and our first chapter will be Into Programming, starting this week. Then at the end of the week we’ll get together to compare notes.

I’m hoping that by doing this together, there’s more chance that we’ll actually see it through to completion:

Why can I hit deadlines imposed by others, but not those imposed by myself?

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.


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!

100 words 093

There are many web-related community events in Brighton. There’s something going on pretty much every evening. One of my favourite events is Codebar. It happens every Tuesday, rotating venues between various agency offices. Tonight it was Clearleft’s turn again.

At the start of the evening, students and teachers get paired up. I was helping some people with HTML and CSS as they worked their way through the tutorials.

It’s a great feeling to watch things “click”; seeing someone making their first web page, style their first element, and write their first hyperlink—the very essence of the World Wide Web.

100 words 044

It was Clearleft’s turn to host Codebar again this evening. As always, it was great. I did my best to introduce some people to HTML and CSS, which was challenging, rewarding, and fun.

In the run-up to the event, I did a little spring cleaning of Clearleft’s bookshelves. I took some books on HTML, CSS, and JavaScript that weren’t being used any more and offered them to Codebar students for the taking.

I was also able to offer some more contemporary books thanks to the generosity of A Book Apart who kindly donated some of their fine volumes to Codebar.

100 words 025

I often get asked what resources I’d recommend for someone totally new to making websites. There are surprisingly few tutorials out there aimed at the complete beginner. There’s Jon Duckett’s excellent—and beautiful—book. There’s the Codebar curriculum (which I keep meaning to edit and update; it’s all on Github).

Now there’s a new resource by Damian Wielgosik called How to Code in HTML5 and CSS3. Personally, I would drop the “5” and the “3”, but that’s a minor quibble; this is a great book. It manages to introduce concepts in a logical, understandable way.

And it’s free.

Codebar Brighton

There’s been a whole series of events going on in Brighton this month under the banner of Spring Forward:

Spring Forward is a month-long celebration of the role of women in digital culture and runs throughout March in parallel with Women’s History Month.

Luckily for me, a lot of the events have been happening at 68 Middle Street—home of Clearleft—so I’ve been taking full advantage of as many as I can (also, if I go to an event that means that Tessa doesn’t have to stick around every night of the week to lock up afterwards). Charlotte has been going to even more.

I managed to get to Tech In Ten—run by She Codes Brighton—which was great, but I missed out on Pixels and Prosecco by Press Fire To Win which sounded like it was a lot of fun. And there are more events still to come, like She Says and Ladies That UX.

What’s great about Spring Forward events like She Codes, 300 Seconds, She Says, and Ladies That UX is that they aren’t one-offs; they’re happening all-year round, along with other great regular Brighton events like Async and UX Brighton.

And then there’s Codebar. I had heard about Codebar before, but Spring Forward was the first chance I had to get stuck in—it was being hosted at 68 Middle Street, so I said I’d stick around to lock up afterwards. I’m so glad I did. It was great!

In a nutshell, Codebar offers a chance for people who are under-represented in the world of programming and technology to get some free training by pairing them with tutors who volunteer their time. I offered to help out anyone who was learning HTML and CSS (after tamping down the inevitable inner voice of imposter syndrome that was asking “who are you to be teaching anyone anything?”).

I really, really enjoyed it. It was so nice to meet people from outside the world of web design and development. It was also a terrific reminder that the act of making websites is something that everybody should be able to participate in. This is for everyone.

Codebar Brighton takes place once a week, changing up the venue on rotation. As you can imagine, it takes a lot of work to maintain that momentum. It’s thanks to the tireless efforts of the seemingl indefatigable Ruby programmers Rosa and Dot that it’s such a great success. I am in their debt.

Brighton workshops

There are some excellent workshops coming up in Brighton soon.

Seb will be teaching a two-day course on CreativeJS Fun and Games on the 13th and 14th of March. I went on one of Seb’s workshops a while back, and it was really, really good. He really does make it fun.

Then on April 2nd, Remy will be teaching a one-day workshop called Debug, and know thy tools. It sounds like it will be an “I know kung-fu” moment for front-end dev tools. Alas, I will be out of the country at An Event Apart Seattle at that time (I say “alas”, but of course I’m really looking forward to getting back to Seattle for An Event Apart).

Anyway, if you’re in Brighton—or looking for a good reason to make a trip to Brighton—I can highly recommend these workshops.

Workshoppers of the world

Three weeks ago, myself and Jessica went to Israel. It was a wonderful trip, filled with wonderful food. I took lots of pictures if you don’t believe me.

But it wasn’t a holiday. Before I could go off exploring Tel Aviv and Jerusalem, I had work to do. I was one of the speakers at the UXI Studio event.

We arrived on Saturday, and I was giving a talk on Sunday evening. At first I thought that was a strange time for a series of talks, ‘till I realised that of course Sunday is just a regular work day like any other.

It was a lot of fun. I was the last of four speakers—all of whom were great—and the audience of about 200 people were really receptive and encouraging. I had fun. They had fun. Everything was just dandy.

Two days later, I gave a full-day workshop on responsive design. That was less than dandy.

I’ve run workshops like this quite a few times, and it has always gone really well, with lots of great discussions and reactions from attendees. The workshop is normally run with anywhere between ten and thirty people. This time, though, there were about 100 people.

Now, I knew in advance that there would be this many people, so I knew I wouldn’t be able to get as hands-on as I’d normally do; going from group to group, chatting and offering advice—it would simply take too long to that. So I still ran the exercises I’d normally do, but there was a lot more of me talking and answering questions.

I thought that was working out quite well—there were plenty of questions, and I was more than happy to answer as many as I could. In retrospect though, it may have been the same few people asking multiple questions. That might not have been the best experience for the people staying quiet.

Sure enough, when the feedback surveys came back, there were some scathing remarks. Now, to be fair, only 31 of the 100 attendees filled out the feedback form at all, and of those, 15 left specific remarks, some of which were quite positive. So I could theoretically reassure myself that only 10% of the attendees had a bad time, but I’m going to assume it was a fairly representative sample.

I could try to blame the failure of my workshop on the sheer size of it, but I did a variation of the same workshop for about the same number of attendees at UX Week last year, and that went pretty great. So I’m not sure exactly what went wrong this time. Maybe I wasn’t communicating as clearly as I hoped, or maybe the attendees had very different expectations about what the workshop would be about. Or maybe it just works better as a half-day workshop (like at UX Week and UX London) than a full day.

Anyway, I’m going to take it as a learning experience. I think from now on, I’m going to keep workshop numbers to a managable level: I think around thirty attendees is a reasonable limit.

I’m about to head over to Munich for three solid days of workshopping and front-end consulting at a fairly large company. Initially there was talk of having about 100 people at the workshop, but given my recent experience in Tel Aviv, I baulked at that. So instead, the compromise we reached was that I’d give a talk to 100 people tomorrow morning, but that the afternoon’s workshop would be limited to about 30 people. Then there’ll be two days of hacking with an even smaller number.

This won’t be the first time I’ve done three solid days of intensive workshopping, but last time I was doing it together with Aaron:

I’m in Madison, Wisconsin where myself and Aaron are wrapping up three days of workshopping with Shopbop. It’s all going swimmingly.

This last of the three days is being spent sketching, planning and hacking some stuff together based on all the things that Aaron and I have been talking about for the first two days: progressive enhancement, responsive design, HTML5, JavaScript, ARIA …all the good stuff that Aaron packed into Adaptive Web Design.

This time I’m on my own. Wish me luck!


Emil has been playing around with CSS variables (or “custom properties” as they should more correctly be known), which have started landing in some browsers. It’s well worth a read. He does a great job of explaining the potential of this new CSS feature.

For now though, most of us will be using preprocessors like Sass to do our variabling for us. Sass was the subject of Chris’s talk at An Event Apart in San Francisco last week—an excellent event as always.

At one point, Chris briefly mentioned that he’s quite happy for variables (or constants, really) to remain in Sass and not to be part of the CSS spec. Alas, I didn’t get a chance to chat with Chris about that some more, but I wonder if his thinking aligns with mine. Because I too believe that CSS variables should remain firmly in the realm of preprocessers rather than browsers.

Hear me out…

There are a lot of really powerful programmatic concepts that we could add to CSS, all of which would certainly make it a more powerful language. But I think that power would come at an expense.

Right now, CSS is a relatively-straightforward language:

CSS isn’t voodoo, it’s a simple and straightforward language where you declare an element has a style and it happens.

That’s a somewhat-simplistic summation, and there’s definitely some complexity to certain aspects of CSS—like specificity or margin collapsing—but on the whole, it has a straightforward declarative syntax:

selector {
    property: value;

That’s it. I think that this simplicity is quite beautiful and surprisingly powerful.

Over at my collection of design principles, I’ve got a section on Bert Bos’s essay What is a good standard? In theory, it’s about designing standards in general, but it matches very closely to CSS in particular. Some of the watchwords are maintainability, modularity, extensibility, simplicity, and learnability. A lot of those principles are clearly connected. I think CSS does a pretty good job of balancing all of those principles, while still providing authors with quite a bit of power.

Going back to that fundamental pattern of CSS, you’ll notice that is completely modular:

selector {
    property: value;

None of those pieces (selector, property, value) reference anything elsewhere in the style sheet. But as soon as you introduce variables, that modularity is snapped apart. Now you’ve got a value that refers to something defined elsewhere in the style sheet (or even in a completely different style sheet).

But variables aren’t the first addition to CSS that sacrifices modularity. CSS animations already do that. If you want to invoke a keyframe animation, you have to define it. The declaration and the invocation happen in separate blocks:

selector {
    animation-name: myanimation;
@keyframes myanimation {
    from {
        property: value;
    to {
        property: value;

I’m not sure that there’s any better way to provide powerful animations in CSS, but this feature does sacrifice modularity …and I believe that has a knock-on effect for learnability and readability.

So CSS variables (or custom properties) aren’t the first crack in the wall of the design principles behind CSS. To mix my metaphors, the slippery slope began with @keyframes (and maybe @font-face too).

But there’s no denying that having variables/constants in CSS provide a lot of power. There’s plenty of programming ideas (like loops and functions) that would provide lots of power to CSS. I still don’t think it’s a good idea to mix up the declarative and the programmatic. That way lies XSLT—a strange hybrid beast that’s sort of a markup language and sort of a programming language.

I feel very strongly that HTML and CSS should remain learnable languages. I don’t just mean for professionals. I believe it’s really important that anybody should be able to write and style a web page.

Now does that mean that CSS must therefore remain hobbled? No, I don’t think so. Thanks to preprocessors like Sass, we can have our cake and eat it too. As professionals, we can use tools like Sass to wield the power of variables, functions (mixins) and other powerful concepts from the programming world.

Preprocessors cut the Gordian knot that’s formed from the tension in CSS between providing powerful features and remaining relatively easy to learn. That’s why I’m quite happy for variables, mixins, nesting and the like to remain firmly in the realm of Sass.

Incidentally, at An Event Apart, Chris was making the case that Sass’s power comes from the fact that it’s an abstraction. I don’t think that’s necessarily true—I think the fact that it provides a layer of abstraction might be a red herring.

Chris made the case for abstractions being inherently A Good Thing. Certainly if you go far enough down the stack (to Assembly Language), that’s true. But not all abstractions are good abstractions, and I’m not just talking about Spolky’s law of leaky abstractions.

Let’s take two different abstractions that share a common origin story:

  • Sass is an abstraction layer for CSS.
  • Haml is an abstraction layer for HTML.

If abstractions were inherently A Good Thing, then they would both provide value to some extent. But whereas Sass is a well-designed tool that allows CSS-savvy authors to write their CSS more easily, Haml is a steaming pile of poo.

Here’s the crucial difference: Sass doesn’t force you to write all your CSS in a completely new way. In fact, every .css file is automatically a valid .scss file. You are then free to use—or ignore—the features of Sass at your own pace.

Haml, on the other hand, forces you to use a completely new whitespace-significant syntax that maps on to HTML. There are no half-measures. It is an abstraction that is not only opinionated, it refuses to be reasoned with.

So I don’t think that Sass is good because it’s an abstraction; I think that Sass is good because it’s a well-designed abstraction. Crucially, it’s also easy to learn …just like CSS.

Retreat 4 Geeks 2012

As the year draws to a close, I find myself casting an eye back on the past twelve months. There are two events that stand out for me:

I learned a lot at both events. I think there’s enormous benefit in getting together with your peers for days of intense geekery—it’s quite the learning experience.

Looking ahead to next year, there’s one more such event on the horizon.

Aaron started up Retreats 4 Geeks last year and kicked it off with an outstanding week in the woods with Eric. From March 25th to 30th Aaron and I will be leading Retreat 4 Geeks on Progressive Enhancement. Here’s the best bit: it’ll be taking place on a horse ranch in Clark, Colorado.

I’m expecting an intense three days of hands-on coding bookended with some fun outdoor activities. Based on my experiences this year with these kinds of in-depth, focused gatherings, I think it’s going to be pretty special.

If that sounds like something you’d like to be a part of, you can register your place now. Everything—except your airfare—is included: excellent food, luxurious lodging and multiple days of learning and practicing progressive enhancement and mobile-first responsive design. And if you need any assistance in convincing your boss to fork out for the event, there’s a handy factsheet you can download, print out and leave in convenient spots around the office.

So …maybe I’ll see you in the Rockies?