All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.
Monday, October 9th, 2017
Monday, May 22nd, 2017
Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:
Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.
I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:
I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.
But we can all agree that the web is a wonderful thing:
Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.
Tuesday, May 2nd, 2017
A smart approach to creating patterns as symbols in Sketch. Sounds like diligence and vigilance is required to make it work, but then, that’s true of any pattern library.
Wednesday, April 26th, 2017
I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.
Friday, March 24th, 2017
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.
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.
Wednesday, March 22nd, 2017
Incredibly impressive work from the CodePen team—you can now edit entire projects in your web browser …and then deploy them to a live site!
Friday, March 17th, 2017
This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:
- Figure out what [insert tool] does.
- Figure out what sucks right now
- Determine if it’s worth the investment
- Learn it (if it’s worth it)
- Differentiate opinions from facts
Wednesday, March 1st, 2017
Surprisingly, it helps clients understand the HTML content prototype better. They now clearly see the difference and the relationship between content and design. In general it helps me explain the content-first process better and it helps them make more sense of it.
Monday, January 30th, 2017
David picks up on one of the closing themes of Resilient Web Design—how we choose our tools. This has been on my mind a lot; it’s what I’ll be talking about at conferences this year.
That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities.
There’s a very good point here about when and how we decide to remove the things we’ve added to our projects:
We spend our time adding features without considering at the same pace the removal of useless ones. And still the true resilience (or is it perfection Antoine?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?
Tuesday, October 4th, 2016
I’ve been thinking a lot lately about how we evaluate technologies (it will be the subject of my next talk). Tim is thinking along the same lines. I like his list of four questions to ask when weighing up the pros and cons of any web tool:
- Who benefits from the use of this tool and how?
- Who suffers and how?
- How does it fail?
- Does the abstraction feed the core?
Friday, September 23rd, 2016
PPK reads a Hacker News thread so you don’t have to.
Saturday, April 30th, 2016
Mark has dumped his brains!
Seriously, there is a lot of thought that has gone into this, and it’s just the beginning: Mark recounts the experience that Clearleft has had with delivering pattern libraries, laying the groundwork for releasing the library-generating tool that he has been building.
Watch this space.
Sunday, February 28th, 2016
Linting CSS seems like a very good idea, especially if you’re not the only one writing the CSS. This guide is going to come in very handy when I give it a try.
Monday, February 8th, 2016
Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.
There’s a really good point in here about starting with small-screen sketching:
For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.
If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.
If you nail the small screen design, the larger sizes will be easy by comparison.
Wednesday, December 16th, 2015
Tuesday, June 30th, 2015
Brad Hello everybody! Welcome to another episode of the Style Guides Podcast, a podcast dedicated to all things pattern library and style guide related. My name is Brad Frost.
Anna I’m Anna Debenham.
Brad And today we are absolutely delighted to be talking with the infamous Jeremy Keith. Jeremy: how are you?
Jeremy Hellooo! I’m fine, thank you. How are you, Brad?
Brad I’m doing excellent.
Jeremy Good. How are you, Anna?
Anna I’m good, thanks.
Jeremy Good, good.
Brad Excellent! We’re all doing good. It is a wonderful… well, I don’t know how the weather is there but whatever.
Anna It’s excellent!
Jeremy Beautiful, it’s gorgeous!
Brad We’re on different continents! Jeremy; do you want to kick us off and just give us a little bit of a background? I know you like to have some fun with what you’re exact job title is, but could you just give a little overview about who you are and what you do?
Jeremy Sure. I just updated my job title yesterday, as a matter of fact.
Brad What are you now?
Jeremy I was… I’m currently Shepherd of Unknown Futures.
Jeremy Yeah, I thought that sounded good. Andy Dennis gave me that one. Before that, I was, I don’t know, Commander of the Armies of the Seven Kingdoms, something like that. So generally, I don’t take much stock in job titles. I don’t find them that useful.
But in terms of describing what I do, my stock answer is really glib and I’m like, I make websites. Although these days, there’s so much involved in making a website that that doesn’t really tell you anything at all.
Also, I get bored so easily I just find myself flitting from thing to thing, as a way I guess of turning that to an advantage, my job is kind of flitting from thing to thing on a daily basis; checking out stuff, letting the other people in the company know about stuff I’ve stumbled across, feeding that into the work.
Anna Code reviews.
Jeremy Code reviews, that kind of stuff. We have a Front-end pow-wow every Thursday where we talk through stuff on the front end development side of things, but I honestly don’t know what my job is.
I’m doing client work as well but I’m not exactly clear what I do. I guess a lot of people would talk about their work in terms of their output, so a UX person might talk about wireframes or visual design; they might talk about Photoshop or Sketch and a front end developer would talk about HTML and CSS but I generally don’t have many outputs. It’s a lot of talking and yakking and thinking.
Brad So, as part of this more strategic over-arching birds-eye view look of what your agency is working on and what the relationship of the clients is, you’ve had a lot of experience working with style guides and developing pattern libraries for your clients and things like that. How, at a strategic level, have you seen that evolve into what it is that your company offers the clients and how that all fits in?
Jeremy Yeah. On the one level it’s purely an implementation detail, it’s like whether we hand over a pattern library or whether we’re handing over something else. At another level it’s kind of fundamental to how you approach thinking about deliverables, how you approach thinking about the interface. Depends how you come at it.
For the most part, people don’t hire Clearleft for pattern libraries or for any particular deliverable: they’re hiring Clearleft for design work. Not necessarily even visual design, UX and more like thinky-thinky stuff, I guess. But when it comes to the front end, if we do end up doing front end code for the client, then time has taught us that handing over a pattern library or style guide type thing is definitely more valuable than handing over a set of pages, for example.
So a lot of it’s kind of systems thinking, which has been evolving for many, many years at Clearleft. I know Anna’s mentioned Natalie Downe, who used to work at Clearleft and now she’s at Lanyrd, bought by Eventbrite. She’s an amazing front end developer and she started talking and thinking about this very systems-thinking approach to CSS and HTML many years ago and we started putting it into practice in our deliverables; if we were handing over something, how can we hand over a system instead of just handing over a finite set of pages and expecting the client to extract what they need from those pages? How can we give them the extracted bits that they actually need to put together all the pages that we couldn’t possibly consider.
So a lot of that really started with Natalie. Because Clearleft doesn’t ever do a full site build. For example, we don’t do back end development at Clearleft, so we do UX, we do visual design and sometimes we do front end: not every project; sometimes. But we’d never do actual build, the actual back end PHP, Ruby, Python, whatever, and so over the years we’ve had to get very, very good at delivering our deliverables to the client, whether it’s design stuff or whether it’s front end stuff, because we’re never the last people to touch this stuff: there’s always somebody after us.
That was definitely tricky to do at first, but we’ve been around for ten years now so we’ve gotten better and better at doing it and this idea of a pattern library has definitely been, I’d say, the most important development when it comes to front end deliverables. Not entirely sure whether it works, when it comes to visual design and UX and that kind of stuff, but certainly for front end deliverables, the pattern library idea has been really, really strong and it’s worked really, really well.
Anna And how has that evolved over the years?
Jeremy I’m trying to think back to when we would have first started to do it. I think it would have kind of snuck in the back door. Initially yes, we would have still been delivering pages and we’d kind of throw in this collection of pieces as well: so it’d be more like the pages, the deliverables, but here’s also this collection of the pieces cut out into their individual bits. And then over time, that’s flipped to the extent where we make it very clear that this pattern library is the deliverable now.
We’ll also give you some pages, but these pages, they’re not the deliverable; these pages are just examples of the pattern library in action, and that switch has been a gradual thing over the years, I think, going from, we deliver pages and oh, here’s a style guide to: we deliver a style guide and oh, here’s some pages that use this style guide. That second approach is definitely, definitely more valuable, certainly for other developers taking over who have to build this thing and have to actually put it into action, that’s definitely more valuable.
Now, it can be trickier if it comes to other stakeholders like the boss, the client, the guy who signs the cheques. Maybe they need to see more page-like things; maybe they prefer to have a shiny comp or whatever, and we might have to throw them a bone with something a bit shinier, but in our experience, developers really, really like getting a pattern library as a deliverable.
Brad Right. Do you guys sell this idea up-front and again, is there ever… obviously developers and designers to some extent, at least in my experience, are sort of on board with this, they’re like: yeah, yeah, we get it, we see the value in it, but again, even at that sales process, whenever you’re negotiating the scope of work and what’s going to be done and what you’re actually on the hook for.
Do people ever push back or are they scared or just confused at this concept, or how does that work?
Jeremy Each project’s different, so we don’t like to have a set process or even a set set of deliverables for every project: it’ll change on a project by project basis.
But, that said, broadly I think you could characterise most projects that involve some kind of deliverable as falling into one of two categories and the first category is that pattern library category of, we’re going to do design work and we’re going to hand over this set of components that you then take and you can put together into an infinite variety of pages of patterns and components.
What we’re providing is a way of demonstrating interaction, of demonstrating visual design, of demonstrating animation, something like that. But we are not saying, this is code for you to use. So in a very, very broad way, when we’re doing work that involves front end development, it’ll tend to fall into one of those two camps: either this is code that’s been delivered to the client for them to use in a live site, or this happens to be code, but the code is only there to illustrate the design and the actual final code needs to be written from scratch in a very different mind-set. So, going back to your question about the initial pitching on projects and discussing deliverables, we tend to get a feel pretty early on of which direction the project would be going, like, oh, this sounds like a job for delivering a pattern library; oh, OK, no, a pattern library is not what they need here, this is about some other kind of problem solving and we need to deliver a working prototype, to demonstrate the design but not to be used in production. So we tend to get an idea pretty early on and then I guess sell them on whichever one we think is the right solution there.
Anna And do you tend to work straight in code, or do you come up with mock-ups first and then get them built?
Jeremy There’s nearly always mock-ups first. I guess the question is, how long you spend refining those mock-ups or how quickly you decide, OK, this is good enough to get going, right? And again, that will depend on the client.
On some projects, clients absolutely get it and they’re like yeah, yeah, it’s fine that we’re not deciding in the mock-up.
Backing up a bit, the whole question of mock-ups, or why do mock-ups exist is, I guess, a philosophical question that we’ve been tackling a long time. I mentioned that we had front-end pow-wows every Thursday. There’s also a Design Review, Design Crit that happens once a week. And then inevitably devolves into this discussion of process and workflow and all of this. And it’s a question of what’s a mock-up for? Why does it exist?
(Brad and Anna laughing)
This comes up.
Brad It’s a crisis!
Jeremy Yeah, this existential… here’s my take, is that there’s just three reasons a mock-up could exist:
One is that it’s for buy-in, it’s basically for sign-off. You’re mocking something up to present it to a decision-maker who then says thumbs up or thumbs down, so that’s this decision-making thing, I guess what Dan could be talking about, deciding in the mock-up. That’s use number one.
Use number two is it’s a deliverable for a front end developer, so in other words they’re something a visual designer gives to a front end developer to get turned into code, so that’s a separate use-case.
Now here’s problem number one, is that mock-ups made for the first use-case end up getting used for the second. So, if you’re designing for sign-off, everything’s perfect: everything lines up at the top and the bottom, it’s exactly the right amount… everything looks beautiful. It’s not a real test of the edge cases of content. And unless you then make further mock-ups that are more accurate and reflect the real situation with content and you just hand over this perfect situation to developers, well, everyone’s just going to get disappointed: the developers are going to be frustrated because it’s not accurate, the designer’s frustrated because, hey, that doesn’t look like my mock-up, and the client is frustrated because that doesn’t look like what they were presented with.
Oh, and then there’s a third use of a mock-up, which is for a visual designer to think. They have a tool that they’re comfortable with, like Photoshop, Sketch, Illustrator, whatever and it’s the fastest way for them to get ideas down is to create a mock-up.
Anna Like element collages?
Jeremy Yeah, or even a full interface; even making a page. But the difference is that the reason for its existence is that third use case and not those first two. So, for a designer to go away and create, here’s a page in Photoshop, or here’s a page in Sketch, that’s absolutely fine, I think, as long as the reason for doing that is to get ideas out. It’s not then fine to then present that to a client and say, what do you think? Give us sign-off, and it’s not fine to present that to a developer and say: there you go. Now go and build that. They’re three very different use cases. The getting the designs out of your head, getting sign-off and a template for build. Those are three different use-cases. And yet what happens is, a single mock-up will end up kind of doing all three.
Brad You’d better believe it!
Jeremy So this is the problem I’ve found with mock-ups, we’ve found in general, is this mis-match, I guess, of expectations. And this is why I love Dan’s idea of deciding in the browser, so for that first use-case, you’re talking about deciding in the mock-up; you show the client to give you sign-off. The decision has been made. Then you move on to use-case number two where you’re handing it over to a developer to turn into real code and that’s when reality hits and differences crop up; questions come up that you hadn’t anticipated, but now it’s too late to make the decision to say, oh well, look, that’s been agreed, that’s been decided, that’s what the client signed off on, so I really like Dan’s idea of deciding in the browser where you say, yeah, you do stuff in Photoshop or Sketch or whatever you’re comfortable with; it’s more about that third use case, use whatever tool is comfortable with you. But you don’t go to the client and say, approval or not approval, until you’ve got it in web browsers, until you’ve got it in code, because that’s just so much more accurate to reality. So much more realistic, and makes much more sense to decide in that point, but going back to the original question, would there be mock-ups preceding the mark-up, I guess, the CSS? Yeah, almost always, there’s almost always some kind of mock-up. Now, in an extreme case, that mock-up could be literally paper; could be pencil on paper. More often than not, it is usually a tool like Photoshop or Sketch, something. But like I said, there’s definitely diminishing returns in polishing that mock-up too much, making it perfect because what’s the point? The actual place to do that and make it perfect is in the code, when it’s in web browsers, so the right level of fidelity I guess is the big question and that changes from person to person, from project to project, from client to client. I don’t think there’s a right answer. The right answer is to figure out what’s the right level of fidelity for the mock-up for this project, for this client.
Jeremy Yeah, it’s interesting. I think that the systems approach that came from the front end with people like Natalie thinking this way has definitely infected the visual design part as well: it tends to happen sooner. Even if it’s almost retro-active: the designer maybe finds it easier to just go away and just design screens, interfaces, but that’s retro-actively…
Brad Use-case three, right?
Jeremy Yeah, use-case three, exactly. But then retro-actively, OK, now I’ll extract the patterns and put them together, and that’s when they might notice inconsistencies in their own designs; oh, I thought this button was meant to be the same in all five screens but actually it’s slightly different here and I’ll need to adjust that and make it consistent. Because doing good design, it should be consistent, there should be a logic behind it. Yeah, there’s definitely been more systems thinking happening on the visual design side and we’ve tried things like Style Tiles, Element Collages, these kind of things.
Anna There was a really good blogpost, I think Paul Lloyd wrote it, about how Jon had been doing style tiles and he used to do them vertically, but now he does them horizontally because they were looking too much like a mock-up.
Jeremy Right, again, every client’s different, every project’s different and I was on some project where in showing them a document which is meant to show, here’s a bunch of elements collaged together, the client was mistaking it for an actual page, which you could kind of see, it kind of makes sense that that’s what our brains would interpret that file as, but as soon as Jon flipped it and made it horizontal rather than vertical, then straight away it was clear: oh no, I’m just looking at a collection of components one after the other, but they don’t form a cohesive whole, it’s just separate components.
So that was really interesting and that’s something that Dan, because we got the element collage thing from Dan Mall, and he’s taken that back on board himself: oh yeah, that’s actually really smart and now he does that too.
So again, lots of experimentation, I would say on both the front-end and visual design side, we haven’t got everything figured out and we’re still figuring this out; there’s definitely issues with the tools, some tools seem to lend themselves more than others. Even in small ways like with Photoshop, as soon as you go to create a new document, it asks you what’s the width and the height of the document. That’s a small thing, but straight away you start to think in terms of well, is it a mobile or a tablet or desktop screen, whereas something like Sketch is an infinite canvas. So it has a slightly different take on it, you can just throw things onto this infinite canvas, so it maybe lends itself a bit more to this componentised element collage or style tile way of thinking.
But like I said, the tools don’t really matter, it’s how you approach it. As for designers thinking the systemic way, I think good design tends to do that anyway because you start with a type system, is usually at the root of everything, and a grid system will come out of that but it’s a system; it’s systems built on systems, there’s rules behind that and so good designs will have rules anyway.
I guess the difference is, making those rules clear and bringing them out and showing them. Like sometimes it’s retro-active; well, let’s slap on some translucent pink columns to show what the grid looks like. Nobody yet has decided to slap on a golden ratio Fibonacci swirl onto their design, so that’s good, right?
Brad That’s very good!
Jeremy You know what I mean about the retro-active… oh look, it’s a system; it’s totally a system here! But you know, we’re still figuring this stuff out.
Brad That’s better that you’re pre-emptively getting the designers to think in that way because again, historically, comps have been thrown in my face and I’m like, well, what about this or what if you add this in here, and they’re just no system whatsoever and instead of, oh yeah, I guess that should be more consistent it’s Brad, you’re being difficult!
Jeremy Why can’t you just build it? Why can’t you just do what I…
Brad Can’t you just make the thing? And it’s like well, technically I can but that doesn’t mean it’s going to be good.
Jeremy So, what tends to happen on projects is that there’ll be some lead in with visual design and the visual design would probably begin a bit before front end dev, although it’s always good to have a front end dev around to just look over your shoulder and check stuff.
Then you have a period of both visual design and front end dev happening together, kind of back and forth where, get it into web browsers, look at it and maybe adjust the visual designs, but then there comes a point where it’s like, it’s not worth going back into Photoshop, Sketch, Illustrator, whatever your tool is, at this point; we just need to be doing this in browsers and there’s no point, it’s just wasted effort, to reflect those decisions and those changes in the visual design files because those visual design files aren’t the deliverable: those are tools to get you to the deliverable, which is the final website.
So, it’s different from project to project where that point is, the point at which you don’t need to go back to the visual design files at this point; let’s just sit together and make changes in CSS Web Inspector.
Brad Yeah, working with Dan it will fantastic because we’d do everything in the browser and then it’d be like, at this point in time, things are just looking really awkward and so we’d actually just go in and screenshot things and fiddle with things, move them around in Photoshop and then say, how about this? And what we found is that the vast majority of what he was producing was mostly meant for me; it wasn’t that sort of client deliverable.
Jeremy Yeah, it’s not for sign-off.
Brad That sort of client deliverable sort of thing, yeah, which is great.
Brad So, you’ve been involved with quite a few of, actually a lot of our guests; you’ve touched or influenced in some way a lot of the thinking about style guides and pattern libraries and all of this stuff. We had Lincoln on, formerly of Starbucks. Do you want to share that story real quick about how that came to be?
Jeremy Like I said, at Clearleft I’d been thinking about the system thinking for quite a while and I mentioned Natalie, and when Natalie left we had Andy Hume working at Clearleft, a great front end developer. And he was giving a talk at South by Southwest a few years ago, about CSS systems; now this wasn’t necessarily pattern libraries; things like OOCSS and SMACSS and BEM and all this stuff, just a way of approaching CSS in a more engineering kind of way, I guess.
But he did talk about style guides, the concept of style guides. Specifically he mentioned that the BBC had this GEL, this Global Experience Language, which the whole organisation uses. But he pointed out that one of the problems with GEL is that it’s in a PDF and it would make much more sense for it to be in HTML, to be in the final medium.
It was quite fascinating: when it got to the Q&A, somebody stood up and said, “I’m from the BBC and I’m from the GEL team” and I was kind of thinking, oh shit, Andy’s in for it now, but the guy was like, no, you’re absolutely right, it makes no sense that it’s in a PDF, it should be in HTML. Oh, thank goodness!
Brad That’s great.
Jeremy After this great talk, all these people were coming up to chat to Andy about this, and I was hanging out because I wanted to congratulate Andy and say, great job with the talk, and so this guy starts chatting to me, says he’s from Starbucks; it’s Lincoln and we’re having a chat and he says, you know we actually have a sort of style guide like the BBC thing except it is actually in HTML and CSS and my first question was, “Is it public?” And he was kind of like, no, he hadn’t thought about it, so I was like, “Why don’t you make it public?” and that’s kind of my default reaction when people get in touch with me or come over and say, hey, we’ve got a style guide or pattern library or whatever, because I’ve been blogging about it and talking about it, my first question is, “Is it public, and can you make it public?”
And they did, the Starbucks guys made it public and I don’t think they thought that much about making it public but boy, did that ever get press: it was like, wow, this huge coup for them, it was great, so I think they’re very, very happy they did make it public.
And in general I just love to see people sharing things. Style guide, but in general I like when people blog, I like when people say, hey, I solved this problem and here’s how I did it; this worked for me, maybe it won’t work for you but I’m going to document what worked for me.
Anna It’s kind of how the whole web works.
Jeremy Exactly. When I was first learning to make websites I was viewing source, I was on mailing lists, I was reading Ask Dr Web on zeldman.com; these people were just sharing their knowledge and I want to make sure we keep that and whatever new thing comes along in front end development or visual design or whatever, I like it that our default position should be, let’s share this, let’s just put it out there. Even if it’s something that’s clearly just for you; I link to style guides all the time. Just last week there was, let’s see, Heroku put one live…
Brad Yeah, it’s beautiful.
Jeremy GitHub updated theirs, they put theirs out there, and I say in the link, this is really only useful for the people at Heroku and GitHub but check out how they’re doing it, to see how other people are doing it.
It’s not that you’re going to take that actual code, you’re not going to take their mark-up or their CSS and use it in your own side, but to see how they’ve approached it and what the thinking was behind it and go, oh, I see, and that can influence your own way and what works for you is going to be completely different to what works for Starbucks or MailChimp or Heroku or GitHub, but the fact that you can look at these other examples is fantastic.
Brad Yep, and it’s not all idealistic, although I’m fully supporting that obviously, but guest after guest, one of the reasons why we even have them on is because their style guides are live so that we could look at them but especially with people like Jina Bolton at SalesForce, she specifically joined their team because she was in love with their style guide and I get really frustrated, because I talk a lot about sharing and being open and all of that stuff and it’s always, oh my boss won’t let me or oh, whatever, and it’s like, whenever you think about how you actually reach people and get people on board and everyone is always struggling to hire talented folks, it’s like, you need to show them the goods, you need to show them what you can do, and I think that these style guides are a great way to show, look, we’re working using modern techniques, modern technologies, we can show off how we do things and that becomes a massive recruitment tool, which is awesome.
Jeremy Yep, and my general attitude with a lot of this is, it’s easier to ask for forgiveness than for permission.
Jeremy Just go and do it and if you get flack from the boss, even though you’re getting all this great, positive press say, oh sorry, do you want me to take it down now? And then you should say no, well now you’ve done it… that was kind of my attitude with stuff like the Open Device Lab, I basically just threw the doors open and said hey, anyone can use these devices, without stopping to think or check whether that was OK or what’s the worst that could happen? It’s more like, I’ll just do it and see what happens and it’s fine; everything’s fine.
Anna So, something that I’m quite interested in is, as an agency, how do you, ensure that these style guides are maintained by the client?
Jeremy So, that’s a good question. In a way it’s begging the question, because I’m not sure that the…well, first of all, let’s step back a bit. The terminology here, I’m going to talk specifics about pattern libraries.
Brad Oh, here we go! We were just talking about this!
Jeremy Right. What’s a style guide? What’s a pattern library?
Brad It’s worth discussing for sure.
Jeremy OK, my take is, what we tend to be talking about at Clearleft because as I said, the audience for this deliverable we’re building is other developers; it’s not decision-makers, it’s not designers. It’s developers who have to actually put the site live. And for that reason, the best way I think to describe what we’re providing is a pattern library; it is literally a library of front end patterns.
Now, a pattern library I think can be part of a style guide, and a style guide could contain other things. It could contain tone of voice; it could contain here are the colours, here are the font choices, here are… the classic style guide stuff around where the logo is positioned relative to corners…
Brad Brand style guide.
Jeremy Right, brand style guides. So I guess a pattern library would be a sub-set, a specific sub-set of style guides, so just having cleared that up, what I’m talking about here is pattern libraries.
In the case of Clearleft, an agency handing over a pattern library as a deliverable, I don’t think what we hand over is necessarily what should be maintained. In a way, what we’re handing over’s kind of a one-time thing saying OK, as part of our engagement, we did the design work, we created a pattern library: here you go, we think this is what you need to go on from here.
Now, we might highly recommend that that company have their own pattern library, have their own style guide, pattern library and more, but whether they choose to use our deliverable as the starting point for that or not is up to them. It would make sense in a lot of cases that OK, we’ll take what Clearleft has given us as a starting point and going forward we’ll be maintaining it, we’ll be adding to it, we’ll be changing it, but it might also be that for to really be owned by an organisation, the organisation kind of has to make it themselves, that it isn’t something they’ve inherited, it’s something that comes from within.
I think it’s really interesting that most of the examples out there are from companies and products rather than agencies: the examples of style guides, a lot of your guests on the show, they’ve made this internally, they own it, they’ve put their blood, sweat and tears into it; I’m not so sure whether you can be as invested in something that you get given, something that’s handed over to you, so that might be a bit controversial, but the way I see the pattern libraries that Clearleft are building is not necessarily as things in of themselves to be maintained, but maybe only as starting points.
Anna So kind of blueprints for building the site?
Jeremy Yeah, these are deliverables, we think they’re superior than to delivering pages; we think they’re definitely superior to delivering comps but there’s a whole step again I think into having this kind of living, maintained style guide, and I kind of feel that that needs to come from inside the company.
Brad Yeah, it absolutely does and I think it’s interesting talking to Dan on an earlier episode, Dan Mall, he was talking about his own work and it is, because you don’t work for them so you can’t change their culture to make this a priority for them; it has to come from within, but I think that the opportunity for people working on a contract or agency relationship, what Dan was saying is he’s sort of built it into his contracts now, wherever he is.
The idea typically is, what we’re handing off is something that should take root and you should develop further and what he’s been baking into his contracts has been, I’m going to check in, in a few months and we’re going to see how this thing is working out for you. I thought that that’s just the freaking smartest crap because one, that’s more money and more opportunity for the contractor; it’s not just like, oh well, they just threw it in the trash can so shrug your shoulders and move on to the next gig; he’s building it in as an opportunity to help them through.
Jeremy Yeah, we try wherever possible to have that built into contracts to say, we hand over a pattern library and in a way, that marks the end of our work together, but we want these extra few days, one in a week’s time, another in maybe three weeks’ time, another in six weeks’ time, these regular intervals, to check back in because that’s the only way you’ll ever find out: how clear was this library? How good was the documentation that a company did? How self-explanatory were those class names that we thought were so great?
Brad Didn’t you guys just go through that with Clearleft or with Code for America with the project?
Jeremy That was an interesting one because that was to do with the audience. As I said, usually the audience as in for the pattern library will be developers, other developers either front end or back end developers who are taking this and implementing it, and it was really interesting with Code for America, so we had Anna working with us, which was great, and in the first round we made sure that the CSS was really robust, putting in a lot of the current thinking about really maintainable, robust CSS, which means there’s a trade-off in the HTML where maybe you’ve got a lot of class names.
But if the developers are the ones doing the HTML and CSS that’s absolutely fine. Now, as it turned out with Code for America, the developers weren’t necessarily the ones doing the HTML, because lots of different people were creating new sites or new pages, copying and pasting this stuff, and while it’s perfectly reasonable to expect those people to understand, say, basic HTML, what a paragraph tag is, what an
H1 is, it’s not really fair to expect these people who aren’t developers to now have to learn a whole another vocabulary which has these great class names we’ve come up with, right?
Jeremy And so the second phase of work was really interesting where we started to take some of this complexity that we offloaded the HTML and put it back into the CSS, and we made it clear in the second look, we think this CSS is now actually a bit less maintainable, a bit more brittle, it isn’t as robust as what we first delivered, but it is the right thing to do for this audience because the people making the pages aren’t necessarily developers, so that was really interesting in a kind of every project is different and there’s no right answers and there’s no one true way of doing this stuff: it was a great experience.
It was also frankly great to have a client where we got to re-visit stuff, because so often, you do your work for them and then it goes live or it goes out and then you see all the stuff that you could’ve done better or could’ve been fixed but now that it’s actually live, you want to iterate. And that is one of the downsides of agency work as opposed to product work, is maybe you miss out on the chance of iteration, of being able to re-visit stuff, so the Code for America project was great for a number of reasons, but one of them was the fact that we had a second round that we got to iterate, re-visit the stuff and check our assumptions and re-visit the things we’d decided in the first round.
Anna That was a real eye-opener; I really enjoyed doing that.
Jeremy Yeah, it was good; it was good to see how something we thought was fairly fundamental was maybe not necessarily true and so we need to re-visit it, but that’s OK; it was all out in the open, it was all clear what the problem was and it was a great project.
Brad I’m not speaking because Anna hasn’t talked for a while!
Anna Oh, sorry!
Jeremy Awkward pause!
Brad Awkward pause! That’s right!
Anna Just sometimes when I do this I think that I’m actually listening to the podcast rather than…
Brad This is great!
Anna Yeah, keep talking!
Brad Are you on a treadmill right now? Just running along.
Anna I’ve gone so red!
Jeremy That reminds me; apparently there’s a story of Peter O’Toole being at the theatre, he was taking some friends to the theatre and they’re sitting in the audience and he goes… oh this next bit is great, this is the bit where I come on. Oh shit!
Brad That’s excellent! OK, well all right. Looking at the time, I actually think that we need to wrap up anyway, so maybe it is good that we don’t continue on, although I’m sure we could talk all day.
Anna I really want to but I also know Jeremy probably needs to eat his dinner.
Jeremy You know me; you know once you wind me up and get me going, it’s hard to shut me up. I can talk about this stuff all day but yeah, we should probably be merciful upon the ears of the listeners!
Brad Well thank you, dear listeners, for hanging in there! We covered a lot of meaty bits; I feel like it’s all right to end on a light-hearted note, I think.
But seriously, thank you so much for coming on the show and thank you so much again for your advocacy. It definitely has had a snowball effect; this podcast wouldn’t have existed if the Starbucks style guide weren’t released and so it is as a testament to the openness and sharing nature of the web that this all compounds on itself and thankfully we have people like you that instigate and prod and get people to open up. So, thank you so much for all of that.
Jeremy Well, thank you guys for doing this podcast for the same reason: getting people to share what they know.
Brad Awesome. Well, that’s it for this episode of the Style Guides Podcast. Thanks again for listening and thanks Jeremy for being on and we will see you again. Bye!
Sunday, April 26th, 2015
I think the distinction between ‘how it works’ and ‘how it looks’ is blurrier than we think.
Tuesday, March 17th, 2015
A walkthrough on using the iOS app Workflow to huffduff audio files from just about any app.
Thursday, January 8th, 2015
An important clarification from Stephen:
You don’t actually design in the browser
When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders.
Personally, I think it’s as crazy to start in the browser as it is to start with Photoshop—both have worldviews and constraints that will affect your thinking. Start with paper.
Thursday, October 2nd, 2014
Polyfills and products
A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.
I mentioned that I think that one of the earliest examples of what we would today call a polyfill was the IE7 script by Dean Edwards.
Scott has a great post over on the Filament Group blog asking To Picturefill, or not to Picturefill?. Therein, he raises the larger issue of when to use polyfills of any kind. After all, every polyfill you use is a little bit of a tax that the end user must pay with a download.
Scott takes a very thoughtful approach to using any polyfill, and I try to do the same. I feel that it’s important to have an exit strategy for every polyfill you decide to use. After all, the whole point of a polyfill is that it’s a stop-gap measure until a particular feature is more widely supported.
And that’s where I run into one of the issues of working at an agency. At Clearleft, our time working with a client usually lasts a few months. At the end of that time, we’ll have delivered whatever the client needs: sometimes that’s design work; sometimes its design and a front-end pattern library.
Every now and then we get to revisit a project—like with Code for America—but that’s the exception rather than the rule. We’ve had to get very, very good at handover precisely because we won’t be the ones maintaining the code that we deliver (though we always try to budget in time to revisit the developers who are working with the code to answer any questions they might have).
That makes it very tricky to include a polyfill in our deliverables. We’d need to figure out a way of also including a timeline for revisiting that polyfill and evaluating when it’s time to drop it. That’s not an impossible task, but it’s much, much easier if you’re a developer working on a product (as opposed to a developer working at an agency). If you’re going to be the same person working on the code in the future—as well as working on it right now—it gets a lot easier to plan for evaluating polyfill usage further down the line. Set a recurring item in your calendar and you should be all set.
It’s a similar situation with vendor prefixes. Vendor prefixes were never intended to be a long-lasting part of any style sheet. Like polyfills, they’re supposed to be used with an exit strategy in mind: when the time is right, remove the prefixed styles, leaving only the unprefixed standardised CSS. Again, that’s a lot easier to do if you’re working on a product and you know that you’ll be the one revisiting the CSS later on. That’s harder to do at an agency where you’re handing over CSS to someone else.
I’m quite reluctant to use any vendor prefixes at all—which is at should be; vendor prefixes should not be used lightly. Sometimes they’re unavoidable, but that shouldn’t stop us thinking about how to remove them at a later date.
I’m mostly just thinking out loud here. I guess my point is that certain front-end development techniques and technologies feel like they’re better suited to product work rather than agency work. Although I’m sure there are plenty of counter-examples out there too of tools that really fit the agency model and are less useful for working on the same product over a long period.
But even though the agency world and the product world are very different in lots of ways, both of them require us to think about the future. How will long will the code you’re writing today last? And do you have a plan for when it needs updating or replacing?