Transcription
Charlotte Jackson: Hi. I’m Charlotte, and I’m a front-end developer at Clearleft. I am really, really excited to be in Berlin this week.
Audience: [Laughter]
Charlotte Jackson: I love – yeah. I found that street. That was really cool. I love Beyond Tellerrand. This has been absolutely incredible, so thank you all, and thank you to Marc for having me.
I live in Brighton, which is on the south coast of England, so I’m right by the beach, which is awesome. That’s also where the Clearleft studio is.
Before joining Clearleft, I always delivered lots of finished websites as collections of pages, right? So like a homepage, and about page, a product page, and so on. It was always with a view that these sites probably wouldn’t change again after launch.
And so a lot of my class names used to look like these, things like news item, new archive, blue button. You can see these class names either contain references to the pages they live on or their appearance or their content. They’re really specific. My approach to naming things was pretty much just say what you see.
The problem with this approach to naming things is that components can only really have one purpose, and they probably won’t survive the test of time. For example, we’ve got the class name “news archive” here. This works fine if it only ever lives on a news page. But what if that component is needed somewhere else on the page or on a different page like the contact page for example? Then, you know, the name “news archive” just doesn’t really make sense any more.
And so the alternative to reusing overly specific classes is writing new ones. This results in duplicated code, bloated CSS, and unnecessary extra time, which no one enjoys. And so a lack of coding conventions and effective communication of these conventions can result in code that is just difficult to read. Then it gets worse as more developers add to it, and then others struggle to understand it.
Not only can the code become inconsistent, but not having any coding conventions can make the UI inconsistent as well. Every time new developers make adjustments, they might add new styles that don’t fit with the content. They might use the wrong typefaces or the wrong colors, and eventually you can just end up with lots of unnecessary variations of the same components.
This is an extreme case of button variation, but it’s a real one discovered by Brad Frost when he did an interface inventory of a website. I will come back to this a bit later.
As we’ve seen, the name given to a component pretty much decides its length of life, so it’s important to get it right. We know that these two components can’t exist outside of the news page with these names. But if they were named something like “list” and “card,” for example, they would live a much longer and more fruitful life even if their properties change or they move to a new page. This is because the names describe what they do and not how they look.
Many organizations are turning to some kind of component-based modular design system to help them solve the problems we just looked at. Speaking of naming things, we haven’t quite agreed on a name for these systems yet. There are currently lots of different terms you use to describe them. They pretty much all mean the same thing.
There are component libraries, which is one term. Components combine together to create something bigger. It’s a term favored by Mark at Clearleft. He’s been building our pattern-library tools for a while.
There’s atomic design, which is a naming structure that Brad Frost has given to his pattern-library tool called Pattern Lab. It’s used and loved by some, less so by others, and it’s just a matter of opinion in the project. Again, atoms make up molecules. Molecules make up organisms that are combining to create something bigger.
Pattern portfolio is a term used by Natalie Downe when she started using the technique at Clearleft back in 2009. Again, you know, a pattern is repeated multiple times. They’re combined to create something bigger. It’s a design. It’s a decorative sequence.
Front-end style guides is another term I’ve heard a lot. That actually reminds me a bit more of what designers used to communicate language and branding rather than something for developers as such. For example, I’d expect to see something like, “Though shall not use the blue logo on a green background,” or something like that.
Personally, I don’t think it matters what you call your system as long as it’s appropriate to the project and everyone uses it. Today I’m going to use the term “pattern library” partly because it’s the term I’m most used to using and because I quite like the alliteration in the talk title From Pages to Patterns.
In case you don’t already know them, pattern libraries document every component of a site with code snippets and notes for their usage. Every component is considered an individual piece, which can be reused as many times on the site as needed.
It’s a bit like cocktail ingredients. One ingredient can be part of many different concoctions, just like one component of a site can be used on many different pages. It’s really important that components are created and named in a way that enables them to become part of so many different mixtures.
A pattern library should facilitate a shared understanding and vocabulary between everyone in the team. Everyone should be able to refer to a component and understand what they mean. Alla Kholmatova has talked about FutureLearn’s pattern library and how it’s evolved over time.
Their system started out as a one page style guide listing the most common UI elements, but there were several issues with it. For example, it was only used by one team instead of everyone. It fell out of date really quickly. There were no guidelines on how we’re meant to use components and things like that. And there’s a great blog post on FutureLearn’s website explaining how their new pattern library has addressed so many of these issues.
Everything is good? Yeah. It’s great to see how pattern libraries have addressed lots of issues around building and maintaining websites. I love seeing how they’ve evolved, and I love working on these kinds of projects. I love seeing people get excited about them.
But a big part of moving your thinking from pages to patterns is tackling this challenge of naming things. As we all know, naming things is hard. As we said already, a component’s name determines its ability to survive the test of time, so we really need to try and get it right.
It’s even harder to adopt pattern thinking when clients want to sign off page designs before they build their pattern library. As pages make their way through various teams, the managers for sign off, they’re discussed. And before you know it they are known by everyone as the home page, the listing page, the product page, et cetera. Everyone is talking about pages, and I often find that I build pages and patterns in tandem just to satisfy the various requirements across a project, and I think it can get a little bit confusing.
The challenges of working with pages and patterns simultaneously were particularly evident in some of our recent projects at Clearleft where, instead of delivering completed pattern libraries, we were asked to collaborate with in-house teams to help them build and maintain their own. For example, I was on a project with a team of in-house developers and designers, a project manager, a product manager, and a few others. After we spent a few weeks focusing on UX and UI, we asked the team to name some components for the first time. It was just really as an exercise just to start looking at patterns, and we were working from a product page design with very product specific content in each component.
The first component we picked looked like a card, so everyone named it “product card,” and it’s great that there was a common name suggestion because that’s how a shared language can start to form, but you can see the problem with that name. The product card might become a form field card or a location card one day. And so we continued the exercise with similar results and it became clear that just taking this full page design and working inwards can actually be quite confusing. We had a day of really reduced productivity and just frustrations all around because we just weren’t getting past this point of, like, finding appropriate names for components. We realized that we kind of needed to come up with a way to help our team just sort of forget about pages and just step away from where we were.
On the journey home that day I had a train beer with Jeremy at Clearleft and just sort of discussed the challenges we’d been having. This is me opening my beer. It turns out that ceilings on southern rail trains are actually also bottle openers, which is quite useful. It probably wasn’t the intention, but it actually works really well.
Anyway, I decided that the team would benefit from just stepping away from the screens for a bit, just for like a few hours, half a day, whatever, to focus on adopting a new way of thinking and attempting to tackle the challenge of naming things. We decided to use an exercise, which I’ve been calling the Pages to Patterns Exercise. It’s been really useful in helping a team consolidate their understanding of component design and just help encourage everyone to start building a shared vocabulary together.
This exercise is for everybody involved in the pattern library creation. This includes non-developers and non-designers and literally just anyone with a decision to make in the creation of the pattern library. Everyone can take part because no coding is required, unless you want to, of course, which is brilliant because there is a tiny bit of coding there. The goal is just to get everyone thinking about patterns at a granular level, removing any context around them.
All you need are some visual designs. This can be anything from a first cut to a final design. You need a printer, paper, scissors, and post-it notes. It’s really easy to get started.
Part one is all about paper. First of all, we print the designs and then, either in a group or individually, we break the interface down into fundamental building blocks by cutting it up. For this example I’ve just used a couple of pages in the BBC website. Once we’ve cut out components, we mix them up so we don’t know where they came from. Then we group similar elements like buttons, headings, form fields, and things like that.
The BBC News website uses a lot of content blocks like text and image blocks. At some point we would need to look closer at these to determine which styles might make up the default component in this group and then we’d figure out which styles become variations and things like that. But for now, at this stage, we just group them so that we know that they exist.
Then we move duplicates. Duplicates are multiple instances of exactly the same element with exactly the same design. Buttons which look the same, but have different colors would all stay because they’re variations of one another. Then if we find ourselves with lots of instances of an element with only slight differences between them, we can make a note to review the design just to ensure that we create a nice, consistent experience.
This is what I mentioned earlier. Brad Frost uses a technique, which he calls an interface inventory to analyze the interface of a website. Instead of cutting it up, he actually uses screenshots. Then he documents them in a spreadsheet. When he did this inventory of his bank’s website, he found that there was this unhealthy inconsistency of button designs. This technique just helped him uncover a need for design review.
After part one of the exercise, we should be left with something that looks like this. Lots of paper components. They’ve been grouped. They’ve been deduped, all laid out, the design is now in its smallest parts, and we have no idea which pages these components came from. They’re completely independent now.
In part two we extend the exercise by generating ideas for component names. I’m actually going to ask that we have a go at this together if you want to. If anyone has access to a pen and paper or their phone or something just to write down something, we’ll do that now.
Here’s a group of components I mentioned earlier, the content block text images. I’d like you all to just write down a name for this kind of component. It doesn’t matter about variations. I just want one name, so I’ll just give you a few seconds to do that now.
[Pause]
Okay. If you did it, I’ll assume that everyone has a name now. It can literally be the first name that you think of. Now compare the name to the people on your left and right, to your neighbors. Have a look at what each other wrote.
Okay. Some of you may have written down the same name as the person next to you. If that’s the case, that’s a good indication that it’s a pretty good name–did everyone do that? Cool–because you probably have a similar understanding of what this component means.
I’ll just explain this step. Step one, the team collectively agree on a component to look at. Everyone in the team takes a post-it note and writes down a name for the component. We keep the name secret until everyone is finished. Then once everyone has thought of a name, we reveal the post-it note. Then we compare and discuss each name. Names, which appear multiple times are really good candidates because they indicate a shared language and understanding, so coming together. We repeat this with every component until we have a good number of components named.
In my experience, this part of the exercise has prompted some really good discussions around naming, such as finding class names, which bear some meaning to the company and naming methodologies in CSS. I find that this is a really good way to get all of those conversations started. Naming things doesn’t have to be left to developers alone. I found myself in many situations pulling my hair out whilst trying to think of suitable names for components. It can be really hard. Actually, you know, everyone involved in the project can have a go at this and have the opportunity to contribute. It can make this task a little bit easier.
If you’re struggling to come up with an appropriate name for a component, asking a designer why they made something look the way it does can also help identify its purpose. Involving as many of the team as possible also encourages everyone to adopt pattern thinking and continue to use the language after the exercise. If this is being carried out at the start of a project, it’s likely that components will change, the names will evolve and things like that throughout the project, and that’s fine because it can be done again.
Part three is a final step for those who are comfortable with coding. I won’t make us do this one. What we do is everyone grabs a component each, and then we code up the component in HTML and CSS. Sometimes I find it’s good to set a time limit to resist the temptation to perfect the appearances because actually the purpose of this exercise is to just try things out. The code usually gets thrown away. It doesn’t often get kept anyway.
Then once we have some coded components, we compare and we discuss the code. In particular, we might look at how the class names have been written. Then we repeat it for each component.
This example uses the BEM methodology. If CSS methodologies have been discussed, this is a really good time to test them out. At this point we can test as many variations of vocabularies and methodologies as we like because, if it doesn’t work, we can just drop it without investing any actual code in the pattern library.
This whole exercise can be repeated again to identify larger components. Some of these will contain elements from the first round of the exercise. If that’s the case, we can check that they make sense and stand alone in different contexts.
Actually, a common challenge is knowing how granular to go with this and how small should a component be. How many pieces can form one component? What even is a component? I don’t have an answer to this. But in my experience so far, it has varied across projects, and different teams have had different reasons for their choices.
One of the great things about this exercise is that it can be valuable at different stages of a project. It’s valuable at the start when the team are just getting used to working with patterns or when the design has evolved and the team are focusing on naming and coding. The exercise can be carried out really quickly. It can be repeated as often as required. That’s the beauty of paper prototyping, isn’t it? It’s the low cost of change. You can throw it away and do it again.
Natalie Downe used to carry out a similar exercise of prototyping at Clearleft. She used pens and paper to build components and demonstrate their functionality and size. Then this enabled her to see how they might work and fit together before investing any time in the code.
I believe Hayden has done a similar thing at Neon Tribe where he prototyped interfaces out of things like cards and marker, pens, and blue tack and tape. What I really like is that he also took pens, scissors, tape, and everything into the session so that he could rebuild prototypes on the fly.
What happens next? What do we do after we’ve done this exercise? It kind of depends on the goals of the exercise. There are loads of ways to take this forward.
We can make it part of everyday culture. I find it really useful to stick patterns and their names onto a large piece of paper and just fix it to the wall for everyone to see. As designs change, the patterns can be reprinted. They could be discussed and replaced. It actually serves as a really nice reminder of the components, and it should provoke discussions as the project progresses.
Dan Mall has talked about how he uses a Google Doc spreadsheet to compile components so that other people in the team can actually discuss them in a document. Obviously this works better for teams who can’t colocate and can’t see the same wall.
Alla Kholmatova at FutureLearn takes it even further by putting components in front of users of the website so that they can move them around and see where they would put them. I really like this idea. Involving users as much as possible is really important.
To encourage this shared understanding and language, it’s important to make sure that everyone involved in the pattern library’s creation and decision making is familiar with it. People get busy, so the people who are heavily involved in the creation like the designers and the developers should make sure it’s shared with the rest of the team from an early stage and regularly.
Once the language is forming, you can develop it further. Language can be used to make visual connections as well. I mentioned earlier that asking why a designer made a component look the way it does can help you understand its purpose and function, which can then help you find an appropriate name for it.
I really like how Tom Osborne has used the metaphor “visual loudness” to help link the function and appearance of components. In this case the more prominent a component is, the more loud it is on this scale. This is just a scale created by Tom, so something very prominent like a buy now button needs to be right at the top of the loudness spectrum. He would use the term “scream” on this to describe it. Then you have links, which have really little prominence, and they’re described as whistle and whisper.
If possible, try to use a vocabulary which means something to the organization. People are more likely to remember and form connections with teams they know and are familiar with. For example, an e-commerce site for a company like ASOS who largely sell clothes might decide to use a clothes sizing vocabulary for a particular component and its variations.
Skirts and dresses come in different lengths described as mini, midi, and maxi. Mini is the shortest. Midi is in the middle. And maxi is the longest. It could be that these three variations of clothes describe three variations of a component really well.
I built a pattern library a bike register last year. They offer bike security registration schemes. We made use of bike parts for class names on the website. These are just a couple of examples I pulled out. You’ve got, like, pump, which is to do with adding padding. Then there’s a whole load of classes in the frame group, which is for grids. The client really seemed to enjoy it. Yeah, they found it really useful, and the developers enjoyed implementing it and things like that. It relates to their products, and they were all using it.
Once a language starts forming, everyone should make an effort to refer to components by the names they’ve agreed on. This strengthens the system, the communication, and the shared understanding.
I’m a developer and I know that it’s really tempting to dive straight into code. Sometimes that is definitely the right way, but I think there’s a lot to be gained from just getting away from the screen sometimes and just focusing on the right thinking, the right language, and the right approach first. After all, that’s what we’re doing here today, aren’t we? We’re at this conference. We’re sharing our experiences, we’re thinking, and we’re getting away from our screens.
I think these kind of activities might also seem like a lot of extra time, which they could be. But in many cases it can reduce the chances of discovering they need to change course later on, and so ultimately you could actually save time as well. And so in this exercise, just to sort of recap, we identified components, began to name them, and we started to think about code. The key benefit is it creates the same starting point for everyone in the team, it encourages a shared language, and it encourages pattern thinking across the team.
I’ve used this exercise to kick off loads of different pattern library projects now. It’s also a lot of fun. I mean who doesn’t enjoy messing around with paper and scissors, right? Thank you.
Audience: [Applause]
