Tags: train



Design systems

Talking about scaling design can get very confusing very quickly. There are a bunch of terms that get thrown around: design systems, pattern libraries, style guides, and components.

The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.

This is something that Cennydd mentioned recently:

Here’s my thing with the modularisation trend in design: where’s the gestalt?

In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.

I understand the urge to fixate on patterns. They’re small enough to be manageable, and they’re tangible—here’s a carousel; here’s a date-picker. But a design system is big and intangible.

Games are great examples of design systems. They’re frameworks. A game is a collection of rules and constraints. You can document those rules and constraints, but you can’t point to something and say, “That is football” or “That is chess” or “That is poker.”

Even though they consist entirely of rules and constraints, football, chess, and poker still produce an almost infinite possibility space. That’s quite overwhelming. So it’s easier for us to grasp instances of football, chess, and poker. We can point to a particular occurrence and say, “That is a game of football”, or “That is a chess match.”

But if you tried to figure out the rules of football, chess, or poker just from watching one particular instance of the game, you’d have your work cut for you. It’s not impossible, but it is challenging.

Likewise, it’s not very useful to create a library of patterns without providing any framework for using those patterns.

I would go so far as to say that the actual code for the patterns is the least important part of a design system (or, certainly, it’s the part that should be most malleable and open to change). It’s more important that the patterns have been identified, named, described, and crucially, accompanied by some kind of guidance on usage.

I could easily imagine using a tool like Fractal to create a library of text snippets with no actual code. Those pieces of text—which provide information on where and when to use a pattern—could be more valuable than providing a snippet of code without any context.

One of the very first large-scale pattern libraries I can remember seeing on the web was Yahoo’s Design Pattern Library. Each pattern outlined

  1. the problem being solved;
  2. when to use this pattern;
  3. when not to use this pattern.

Only then, almost incidentally, did they link off to the code for that pattern. But it was entirely possible to use the system of patterns without ever using that code. The code was just one instance of the pattern. The important part was the framework that helped you understand when and where it was appropriate to use that pattern.

I think we lose sight of the real value of a design system when we focus too much on the components. The components are the trees. The design system is the forest. As Paul asked:

What methodologies might we uncover if we were to focus more on the relationships between components, rather than the components themselves?


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.

100 words 059

Today was the first day of UX London. I was planning to attend. I decided I’d skip the first couple of talks—because that would entail rising at the crack of dawn—but I was aiming to get to the venue by the time the first break rolled around.

No plan survives contact with the enemy and today the enemy was the rail infrastructure between Brighton and London. Due to “unforeseen engineering works”, there were scenes of mild-mannered chaos when I arrived at the station.

I decided—wisely, in retrospect—to abandon my plan. Here’s hoping it’s better by tomorrow.

Beautiful hackery

While I had Matthew in my clutches, I made him show me around the API for They Work For You. Who knew that so much could fun be derived from data about MPs?

First off, there’s Matthew’s game of MP Top Trumps, ‘though he had to call it MP Fab Farts to avoid getting a cease and desist letter.

Then there’s a text adventure built on the API. This is so good! Enter your postcode and you find yourself playing the part of your parliamentary representative with zero experience points and one hundred hit points. You must work your way across the country, doing battle with rival MPs, as you make your way towards Sedgefield, the lair of Blair.

You can play a Web version but for some real old-school fun, try the telnet version. This reminded me of how much I used to love text adventures back in the days of 8-bit computers. I even remember trying to write my own in BASIC.

For what it’s worth, Celia Barlow, MP for Hove, has excellent pesteredness points. I made it all the way up to Sedgefield and defeated Tony Blair in battle. My prize was the source code of the adventure game in Python.

Ah, what larks!

There’s another project that Matthew works on that I find extremely useful. He has created accessible UK train timetables using the data from the National Rail site, a scrAPI if you will. This is where I go whenever I need to plan a train journey.

The latest feature is something that warms the cockles of my heart: beautiful, hackable URLs. If I want a list of trains going from Brighton to London, I can just type:


It handles spaces (or pluses or underscores) too:

http://traintimes.org.uk/brighton/london victoria

The URL can also be extended with a departure time:

http://traintimes.org.uk/brighton/london victoria/14:00

My address bar is my command line. This is the kind of design that makes URL fetishists like Tom very happy.

d.Construct travel news

If you’re planning to come down to d.Construct tomorrow morning on a train from London, you might want to rethink your travel plans:

A train drivers’ union will decide later whether to go ahead with a major strike which is set to cripple services across southern England.

There’s always the bus, though that takes considerably longer. Or you could just come down tonight and go to the pub.

Update: The strike has been called off! Praise Jeebus!

Virtual trainspotting

The second day of BarCamp London is going great — I’m amazed a the energy and enthusiasm after a night of very little sleep for everyone. The lack of sleep can be attributed to Simon and his damn Werewolf game.

I’ve just seen the most wonderful presentation from the excellent Matthew Somerville. He works on They Work For You… and I just found out that he’s the guy who did the renegade accessible Odeon site!

He’s built a fantastic mashup of maps and train times. Maybe I shouldn’t be drawing attention to it because he’s getting the data by screen-scraping — because there is no National Rail API — but damn, this is sweet! You can find out when they’re due to arrive at a station. You can see the trains moving along the map. Click the checkbox to speed up the movement by ten.

See how Brighton is in the drop-down list of stations? Matthew added that in the middle of the presentation in response to my request. After all, I need to get back down to Brighton later today.

Helvetican crossing

One of the services we offer at Clearleft is on-site training… a bit of this, a bit of that. It’s something that I really enjoy. Not only do I get to spend a day talking incessantly about the technologies that tickle my fancy, I also get to travel and meet web developers who are digging away at the coalface behind their company firewalls.

Thus far, our little roadshow has travelled within the UK to companies in London, York, and elsewhere. This week, we’re spreading our wings a little further. On Friday, I’ll be doing some DOM Scripting training in Basel, Switzerland located right on the nexus of France, Germany and the Confoederatio Helvetica.

It won’t be my first time to Basel. I’ve been there on a few occasions, mostly for the unique annual spectacle of the Morgensterich carnival. I used to live fairly close by, over the border in Freiburg, Germany.

I arrived in Freiburg many years ago with my bouzouki in hand and started busking on the streets. I ended up staying for about five or six years. Along the way I met Jessica, worked in a bakery and played bass in a surf-rock band. Then that whole web thing came along and set me on my present course.

I haven’t been back to Freiburg since moving to England six years ago. Seeing as I’m going to be in Basel anyway, I think I’ll take a trip up to the old town this weekend. I’ll revisit my old haunts and revisit the beer and wurst while I’m at it.

I hope my German hasn’t become too rusty in the intervening time. I guess I’ll find out if I’m able to comprehend the Schweizerdeutsch spoken in Basel.

Expect my Flickr photostream to fill up with pictures of Freiburg’s quaint alleyways and its wonderful cathedral. Tchüß… bis später.