Style Guides with Ian Feather

Ian I'm good, thanks for having me.

Ian Yes, sure. I work at Lonely Planet and we have offices in London, Melbourne and Nashville and I'm the client side tech lead there which means I kind of take credit for everyone else's work as much as possible! And essentially I oversee some of the major decisions that take place and a lot of my work is spent looking at our developer workflow and figuring out where the bottlenecks are and trying to make that better, which is kind of where the style guide came from in the first place.

Ian Yeah, absolutely. So, we have a lot of similar pages which share a lot of the same components, and historically we have never done a good job of sharing them, so we'd been working on a re-build for about three years and we wanted to make sure we have a single place for these components which we can then share across multiple places. And the style guide came out of the back of that because once we had a single place for these components, we could visualise them somewhere else. But really the main driving force behind it was first to be able to share things and build pages faster and I think we've accomplished that.

Ian It started out as a developer resource. My goal was that designers would be able to make changes within it and distribute those across the sites, and that happened to some extent, so we have some designers who are quite happy to use Git and commit small visual changes such as changing paddings on buttons, margins, that kind of thing; maybe working with the type. And that's really useful because it means that we can concentrate on large problems and let those things take care of themselves, so it does work in that respect. UX don't really have too much of an impact on it because it doesn't really come into that too much. But it is definitely used by product managers to discuss how things should look; the state of things, the progress of things and we also use it with our external partners, so we have an India website, a Chinese website, a couple of other websites and they not all integrate with Rizzo India does, but they all look at it as a next step for them to integrate with it. So it's used as a sort of communication tool, I guess.

Ian Sure. I guess what makes it living is that it doesn't go out of date! I guess… I don't know. I've made two style guides before this one at Lonely Planet, both of which went out of date very rapidly and were never used ever again. This one doesn't go out of date and it means we don't need to actually maintain it. We don't have to have a team working on it to keep it up to date; it just stays mirroring the production environment…

Ian It achieves it by… we abstracted out all the components and the dependencies to these components into a shared component library called Rizzo and each application then talks to this component list to retrieve its components, which means that the applications are just made up of datasets really and data depictions of what the final thing might look like, and then because we have that relationship, we can just add an extra application which in our case is the style guide and that application, rather than calling maybe a left nav and some cards and some text, it calls every single component multiple, multiple times and renders them into a different view. And we put that style guide application inside Rizzo but it could be anywhere else; it's just for convenience that we have it in the same place as the components. That's kind of how it stays in tune.

Ian Yeah. And so does the style guide.

Ian Yeah, absolutely. That's a really useful tool certainly and I think that's the main benefit for our designers that they can actually make these changes within the style guide and know that that's how it will look everywhere; they don’t have to go into each application and look at it as a whole page. It can just be a unit.

Ian That's a good question. I don't know if I have a really great answer for it! I'm not sure we have a particular workflow that we stick to. It's an interesting one. Our workflow would be that we still use Sketch or Photoshop mocks; well, the designers will use that. We'll quickly get something into the style guide afterwards, because that's the fastest way for us to get something into the browser. We're a very small team, so I sit next to our lead designer and we can work back and forth in the style guide sometimes.

But in terms of how we combine components to make large components, I think because we've established this kind of componentisation mechanism, the designers potentially have this new way of thinking about how to build up the page, which makes it easier for us because we already know these things exist in code and hopefully makes it easier for them because they don't have to re-invent the wheel each time.

So I think it helps as a whole to think things, the atoms, molecules, organisms, but in terms of how our workflow specifically deals with that, I don't think we've come up with a perfect solution or anything.

Ian Right now I would say that we have the majority of the components are fully fledged in code and now mostly designers will come up with rough representations of where things might live, how things might lay out, without going into too much detail because there's no longer really a need to do that work up front and we can just tweak it in the browser afterwards.

Ian Yeah, and I think that's a matter of convenience. I think that our designers, the fastest way for them to lay out things is currently Sketch or Photoshop, because that's where they feel the most comfortable. Likely that will change; hopefully that will change and we can create tools perhaps within Rizzo or using third party tools which can make it even easier for them to do that in the browser but at the moment, that's where we are.

Ian I don't think so, no! That's a good question. I wrote a little article about what we would change about Rizzo recently, which addressed a couple of these things.

Yeah, it's an interesting one. They were mostly from a technical perspective, there are things that we would change, such as we would use agnostic templating language so we could use Rizzo in lots of different applications. At the moment it's kind of tightly coupled to Ruby but we then have to write little adaptors or little passes which can make it work across different stacks but there are a few things we would do differently in that respect.

And the big one I would say is how we go about pushing style updates out across our whole suite of apps. At the moment when we push something to Rizzo, It's deployed and it's accessible by all the apps and they have to then pull in those changes, which usually happens fairly quickly, because each application is being worked on constantly and deployed quite often, so usually things stay up to date pretty fast, but it still can become a chore because we have these other applications which may not be used so often and we would then have to go round and update each of them and deploy them individually and manually and I think a next step would be to somehow automate that, which isn't too hard in a simple manner, that idea of having something which maybe on post deploy, deploys them all.

But to do it in a very safe way with visual regression testing or some kind of mechanism to ensure that you're not just hot pushing crazy changes out. That's the part that I think is interesting and it will be interesting to see how that proceeds from here. I know that GOV.UK do that and they're very smart and presumably have a great solution, so I'm interested to see how they do it.

Ian I don't think you're off. That is the ideal. I don't think that we would move it to other platforms at the moment; it would just be the web. But it would certainly be the web in different stacks; whether it be Node, whether it be Ruby, whatever it may be. So at the moment we have… I called this thing a component API but I think that kind of misled in some ways, because an API you tend to think of being over the network by HTTP and that would be kind of somewhat simpler in some senses because then you don't have to worry about what technology stack you're on, and that's how we integrate Rizzo with our old Java apps.

But that brings with it a whole suite of further problems like caching and things like that. But had we done Rizzo again, I think we would approach this as a primary concern, how we do fit it into multiple places. I think cross-platform's amazing. Stuff that the salesforce team have worked on with moving things between iOS and Android and the web is really impressive, but we don't currently have that connection. We do have a native app team but we don't work closely enough with them to yet bridge that gap.

Ian Yeah, and I think to add to that, part of our user base is the developers for the style guide and if they're building it on a stack which we don't really easily support, it's much more likely that they will then veer away from the styles that we have because it just becomes too difficult or perhaps they make different changes and then that finally affects the end user because things stop becoming consistent, so it kind of all loops back into itself I think.

Ian Well, no! I mean we do in a very ad hoc way. We don't have QA teams at Lonely Planet; we practise continuous delivery, so we have a feedback loop which works in production but device testing is something that we want to level up on and make more of a first class citizen. And style guides are a perfect place to do that.

Ian I think the only principle behind Rizzo is that it's the single source of truth for a component, and so once you have that, all these other avenues become available to you, like using visual regression testing on a component in a style guide you know is going to be the same as a component on the website and the same with device testing for a component. It's cool.

Ian I've used a few and to differing degrees of success. There is a tool called SiteEffect. SiteEffect.io, which is still in development but which is really exciting I think for visual regression.

Ian It's browser based, yeah, but it doesn't do diffing in the same way that the current ones do with .png diffing. It's really clever but it's still in development, but I did get a little sneak preview and I was very impressed.

Ian Yeah, definitely.

Ian That's a good question! Do people appreciate it? I think so! I hope so!

Ian Yeah, it sometimes gets to the point where you do hear Rizzo being mentioned in multiple places round the office which is kind of cool, so I think it has become a communications tool.

Sometimes I worry what I've created! Because everyone just suddenly goes, "oh yeah, Rizzo will sort that out, don't worry about that; Rizzo can fix that." And I have no idea what they're talking about!

I think in one respect… so how's it helped the business? I think it's helped the website mature which ultimately helps the business. I think it's definitely helped with recruitment because we have had people apply who've known about Rizzo, who've known about the style guide, and that's been a really nice thing and because we are trying to grow teams in America, recruitment has kind of been a big deal for us. I can't think of… there are no empirical sort of ways for me saying that this has been successful but I think broadly people would agree that it has been beneficial for us.

In terms of these partner sites that we have, time will tell on that. I think it will be a great thing if they can integrate it; it's certainly a challenge because we don't have localisation on Lonely Planet, so we partner with third party companies to provide different language support. It's basically different sites but they use Lonely Planet's brand and image and that's a reflection of Lonely Planet and some of these sites are pretty bad, it's fair to say, which has an impact on the brand.

Ian That's definitely true. Before this, they were further away for sure. The problem is that our design iterates quite fast and if these third party companies put a significant amount of energy and money into updating their site to look like ours and we then change the design altogether, that's not a brilliant experience for either of us, so if they can link directly into Rizzo, we no longer have that problem because they're always going to be in sync.

Ian No, we don't really worry about it because they'll get it automatically anyway. Unless we've pushed a breaking change which does happen, we will then have to inform all the apps, you're going to have to update this, because there are certain things to do with perhaps the scaffolding of the page which we can't turn into a component and those things will break, so then of course we have to go through the whole rigmarole of updating all the other apps, and that can be a pain.

But we don't have a mechanism where we have to go and inform people. And I think that's partially why Rizzo was born in a sense that we don't have the manpower to do that either; we're a small team. I think we've averaged, since the time I've been there, three front-end developers has probably been the average amount we've had, so we would never have had time to go back and update all the apps once we make one change, one place. So Rizzo is the facilitator for that and mean that we didn't really have to.

Ian It wasn't so bad, actually. We introduced this thing called Dev Days which is every other Friday, developers can work on whatever they like as long as it in some way benefits Lonely Planet, and in the first two or three I built the frameworks for Rizzo and then the other two developers at the time used it.

I got a bit excited about it and started building features on top of it and on top of it and it just happened really organically and it got to the tipping point, which didn't take very long, where it was much faster to build a component directly into Rizzo than it was to build it into another application. Then we were sold, basically; then it was OK.

Ian It's Open Source in the sense that anyone can go and look at it and dig into it. It's not Open Source in the sense you can just plug it into your site; it won't work like that. I think that… I have toyed with the idea of trying to make that but it's a bit too opinionated and it really does depend on your environment and the structure of your project and your organisation. I think it's a bit of a leap too far.

Ian Yeah, absolutely. And hopefully some other people figure this problem out as well. I guess…

Ian I hear of about all these companies who've taken something from Rizzo and built their own version and there must be some… if we can reap those back in, there must be some way of finding common patterns between them which can help us figure this out. But I think it's really specific.

Ian Yeah, that's really cool. I didn't do that!

Ian That's one of our developers at work; Remy. He did that on one of the Dev Days, and that's a really cool feature. Really nice.

Ian Yeah. It was something I've been wanting to do for a while. We took performance very seriously at the start of the project and for so many organisational reasons, it became less of a priority as it continued, and I was aware that the asset sizes had spiralled a little bit out of control and we weren't just really aware how big they were, so I wrote a few scripts to scrape the assets from the different applications and then create these stats and these sizes and because we have developers working and living essentially in Rizzo, that was their area of work; it made sense to just add that into Rizzo, and so we trialled over time the size of the different JavaScripts and CSS stuff, and it would be nice to make that bigger and cover things like images and stuff. But that again is something that will happen I guess on Dev Days organically whenever we have time.

Ian Thanks mate. Thank you! I like that section.

Ian Thank you.