Episode Transcript

Karen:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week we are dazzled with excitement and anticipation, as we have Colm Tuite and Yav Punchev here from Marvel app. Welcome.

Colm:

Hello.

Yav:

Hi guys.

Ethan:

But before we get started, I’d like to take a moment to thank our sponsor, Media Temple. They’re an LA-based provider of web and cloud hosting solutions that caters to web developers and designers like you and I, as well as to creative agencies and large enterprises. Now, they’ve been around since 1998, so there’s a pretty good chance you’ve heard of them. I mean, heck, one of my earliest sites was hosted on Media Temple. They offer 24/7, award-winning support, that’s based right here in the U.S., available online or over the phone. And Media Temple has one of the highest customer loyalty rates in the industry. They’re incredibly proud of their focus on the digital design community and offer a whole suite of products that are just tailored to its needs. If this all sounds good to you, you can use the code RESPONSIVE when you sign up, and if you do that, you’ll get 33% off the first three months of shared or Wordpress hosting. That’s available at mediatemple.net. Once again, from Karen and I, we’d like to thank Media Temple for sponsoring the podcast. Thanks so much.

Karen:

So I would love it if we could start off by just having you both introduce yourselves. Tell us a little bit about what you do, what your job is at Marvel. Colm, you want to go first?

Colm:

Sure, yeah. So I joined Marvel back in August/September of last year, some I’ve been there like maybe ten months, and I mainly design things, write code. What happened was I was working on a design tool for two, two and a half years previous with a guy in America, and Murat, the CEO of Marvel, got in touch with me and he said he just liked the look of it and they were thinking of doing something similar at Marvel. So we met up and hit it off, and then eventually he ended up acquiring the tool. So myself and Elliot, the guy who was working with me, joined Marvel and now we’re building design tools together.

Yav:

Hi guys, I’m Yav, I joined Marvel pretty much at the same time, September of last year, and I’ve been working on the product since then, and all the marketing parts of it as well, and the blog.

All we do is write HTML basically, all the CSS is written, so whenever we want to build a new component, we just add a bunch of HTML classes on to some markup and that’s our component.

Karen:

So, tell me a little bit about what Marvel app is, and I’d be very curious to understand how the new responsive design that you’ve just launched sort of fits into the broader product.

Colm:

Yav worked mainly on the new responsive marketing site, so Yav, you want to take that?

Yav:

Yeah, sure. When I first joined, we did a big redesign of the whole marketing site, the blog, and alongside that we developed the new style guide, which was based off of a framework that Colm designed. It’s a CSS framework that, Colm, you might want to say a bit more about it before I kick in with the responsive stuff.

Colm:

Our framework is Bantam, I call it Bantam CSS, which is a terrible name. It’s mainly a bunch of CSS classes, just single-purpose classes. So, there’s a class for basically every CSS property in the CSS language, and one for each value, and we just basically used those—there’s a class for each breakpoint that we use, we’ve got four different responsive breakpoints, and it adds up to like five or six kilobytes and gzipped, and we just basically use those in HTML. So all we do is write HTML basically, all the CSS is written, so whenever we want to build a new component, we just add a bunch of HTML classes on to some markup and that’s our component. So, Yav just took that framework, I think that was the first time Yav had been using single-purpose classes exclusively to build apps, so he just took that and ran with it.

Yav:

Yeah, it was amazing because when I started, that concept was completely counter to me. Before that, I was used to just writing huge CSS files with loads of breakpoints. So when I saw that approach, it was quite strange to start with it, but it was really easy to pick up and it actually helps in the long run. So yeah, that’s how we started to build it.

We just wanted to put some strict quality control on that whole process to make sure we were all kind of working from the same resource.

Ethan:

I think that’s great. That style guide post that Colm wrote was one of the first reasons that I had heard of Marvel app and wanted to reach out to you folks, because it was really focused on the technical benefits of it, but it was also really focused on the collaboration benefits you got out of having this central repository. Maybe we could talk a little bit about that collaboration, and specifically I’d like to hear a little bit more about how this new responsive redesign got started. In the early days when you were talking about going with this responsive look, were you fielding any questions from your stakeholders at Marvel about responsive design, what it was going to mean for their content, for marketing materials? Were you hearing any concerns? Tell me a little bit about that.

Colm:

When I joined in August, I think a redesign had already been planned and people had already been talking about that; and also a style guide was kind of on the cards already, the design team was shooting around ideas for a new style guide, but there was no real process in place. When we started, there were no real concerns from stakeholders or executives or anything. It’s a pretty small company; when I joined, there was only eight or nine of us, I think.

But yeah the process, at the time it was kind of just like everything was hashed together. There was maybe three or four designers and when somebody was working on something new, they would just kind of be working in isolation, and everyone kind of had a pretty good feel for how Marvel should look and feel and how things should work. But there were no strict guidelines or rules to tie everything together—even like before something got released, to make sure everything matched up exactly as it should. So we just wanted to put some strict quality control on that whole process to make sure we were all kind of working from the same resource. There were a number of goals, like one was to speed the process up so there would be less back and forth between designers, like, “What do you think this looks like, and what do you think this looks like?” and you might have nine or ten different options for the same thing. Whereas now we can just work from the style guide, like, “Here are your colors. We no longer need to talk about this for weeks.” And if somebody wants to tweak something, then that becomes a project in itself, rather than tweaking things as you’re designing a page. That just kind of breaks down processes, you know?

Since the codebase is fully responsive, there’s no reason why the app couldn’t be responsive also. It would just be a matter of refactoring HTML; it’s pretty simple.

Karen:

I’m always curious to talk to organizations that are managing infrastructure and processes across both web and app, and how something like a style guide might help you maintain consistency or even streamline development processes. Can you talk about how the style guide that you created might influence work that you’re doing not just on a responsive website, but also potentially on the app, either today or in the future?

Colm:

At the moment, the app is not fully responsive, which is something that I would personally like to fix—I don’t know if fix is the right word. The thing is, at the moment, with this style guide, we’re working from the same codebase—the app and the marketing site, it’s all the same live codebase. The style guide itself, the presentation of the style guide, it’s the exact same codebase as the app and the marketing site. There’s potential there to move—we’re currently in the process of reimplementing the whole app in React, and there are options there obviously to use React native for mobile and React in OS X, like if we want to build a native desktop app. So eventually everything could be using a completely shared codebase, and since the codebase is fully responsive, there’s no reason why the app couldn’t be responsive also. It would just be a matter of refactoring HTML; it’s pretty simple.

When everyone is working from the same resource, it’s much easier to refine brand identities, because you’re just going through a single channel.

Ethan:

Nice. I think the last point in that style guide post that you wrote, Colm, was one that was really interesting to me, about sort of “encouraging solid reasoning,” I think it was. It’s not necessarily thinking about a style guide as just a library of front-end patterns and styles, although that’s definitely a big characteristic, it’s really empowering other people to make smart decisions with how and when to use those patterns. Has that style guide—and this could be either for you, Colm, or for Yav—has that changed the way that you’ve done responsive work? I’d love to hear both your perspectives on that.

Colm:

I think one major source of this problem is the way design tools are structured at the moment. Most popular design tools that I’ve used, they’re not really focused on shared styles or global styles, or even a style guide in any way, they’re just kind of like a free-for-all. The only thing that’s shared is color palettes, so you’ve got swatches and you can save swatch palettes, or load them and import them or share them. But aside from that, it’s just a free-for-all, you can use any style you want, there are no restrictions or guidelines. When you’re designing a new page, you’ve just got an infinite amount of values for every single property, and it kind of—I don’t want to say encourages, but it results in designers just going for it with no restriction and no limitations and no thought toward a system, or how this will affect other pages as the user navigates through the app. I think when you’re working from a shared codebase that’s responsive and from a style guide, and the whole team is working from that same resource, it restricts everyone in a good way and limits the creativity in a good way. I know that sounds bad. I just think when everyone is working from the same resource, it’s much easier to refine brand identities, because you’re just going through a single channel.

Yav:

Yeah, I can definitely confirm that, because when we started working from that style guide, we defined all the font sizes and all the breakpoints beforehand, before I started working on the marketing site, and that really helped a lot, it really changed the way I thought about the structure of the site. Because if I had only three breakpoints to work with, that meant I had to think a lot more fluidly in terms of my layout, and that just resulted in a much better structure overall. Me having to choose from eight font sizes, as well, made things feel a lot more consistent.

We ultimately decided to go with a more verbose class naming convention. So, while that resulted in bigger markup, it’s much more intuitive for the whole development team.

Karen:

I’m really interested in how teams that are working on a style guide or a pattern library engage the rest of the organization around the purpose of these different patterns or these styles, and I think specifically how those patterns get named. Can you talk a little bit about how you worked with the rest of the organization in developing this, and did you have to reach out to other people to get their input on how things worked, or what they were called, or how they would be used?

Colm:

In the core team that worked directly on the style guide, there were only about three or four developers and designers working on it on a daily basis. But we were mindful that, at some point after we released it, the whole development team were going to have to use it on a daily basis and implement components and stuff, so everyone had to be able to understand it really quickly and intuitively. And obviously one of the primary concerns there is how to name components and how to implement them so they could just be copy/pasted quickly. So I guess there were two points. One was the CSS framework that we decided to use that I had developed. Initially I was using really short class names, like a short name convention, which was abbreviated. Let’s say you have a text align property, I would abbreviate that to TA, so TA-left is Text Align Left. But one of the guys on the team, Oleg, suggested that new developers coming in who weren’t familiar with the framework may not understand that, and they’re just going to see twenty class names and not understand what’s happening to the markup. So, we ultimately decided to go with a more verbose class naming convention, so we were just listing out entire property names. So, while that resulted in bigger markup, it’s much more intuitive for the whole development team, so I guess it’s more productive overall.

The other side of it is component naming. So, this was a little more controversial. I was happy to go with no component class names at all. I wanted to go with, like for a button component for example, you would just have a button tag and latch twenty-five class names onto it to style it like your button, and not name the component at all. Same with a div or any other component. And in the style guide, we would just have the button HTML and list all the class names, and they could just copy the entire component and paste it into markup. The general consensus was that people wanted smaller markup and also a smaller presentation in the style guide, so we decided to go with a component class name. So we used the BEM naming convention for that. Take it, Yav.

Yav:

Yeah, you pretty much covered it all. The one interesting thing that I can think of is color names, because that was something we had to come up with as well, and we decided to come up with just completely meaningless color names—meaningless in the sense that the name basically did not relate to the color at all, which made it easier to add new colors and remove colors in the future, and if we wanted to change the brand color in the future, we could easily without affecting anything.

Karen:

Let me also ask how you managed reviews of work in progress with the rest of the organization. Given that you are making a prototyping app, I’d be curious to know how you socialized this design work with the rest of your team.

Colm:

Yeah, there’s kind of a couple of channels at the moment, depending on who’s working on the project and the nature of the project. A new guy just joined us, Adam, and he suggested that we create a Slack channel, so we use Slack internally, and he suggested that we create a channel for design feedback. So we’re using that Slack channel now, we just post what we’re working on and get some feedback.

We also use Marvel, the product itself. So if somebody has a flow that they’re working on, they can just post the four or five screens that are linked together and we can just whack through them and comment on them and stuff using Marvel internally. For guys who code more, often they will just make some changes in the codebase and open a pull request, and we’ll start a conversation on Github or start a conversation internally on the channel or whatever, and just talk about the code. And then for stuff that’s going live, we have a code review. So there’s like three or four of us who work on CSS front-end, and we have a Slack channel for that, so if somebody needs to push something live, they open a pull request and then the other guys on the team will review the code and make sure it’s in line with all of our naming conventions and guidelines and stuff, and vote it up or down.

Yav:

Yeah, that’s more for day-to-day work, we use Slack for that and, as he mentioned, Github and stuff. But we also have something of a show and tell which as at the end of the week, and we sort of communicate everything that’s happened to the wider team and people who might not be aware of CSS or style changes and things like that. So, that happens once a week, too.

Ethan:

I’d love to hear a little bit about not just how you actually build the UI but how you actually test it and see how well it’s performing. I don’t know, it seems like we’re living in a golden age of tooling and instrumentation for QA, for performance testing, for device testing. How do you actually measure how the site actually feels and looks on different devices, different browsers?

Yav:

So, we use Intercom mainly for that at the moment, and we just observe metrics, and we have an internal person who helps us with the data behind pretty much everything that goes live. But we’re thinking about what tools should we use next, so it’s still a work in progress.

Karen:

What about looking at your analytics data? How do you evaluate or measure the success of this new site?

Yav:

We just pretty much look at the numbers since it was released and see how it affected sign-ups, how many people use the product… And we measure that across the months—if we push a feature, we’ll see how it affects, because we know when we release a certain feature and when we change something, we just look at the numbers.

Colm:

We’ve got two girls on the team, Sophie and Marilyn, and they’re working on research and analytics and data and stuff. Before we launched the new site, they did some research to find out what the numbers were at the time with the old site and then matched them against the data we got with the new site to make sure everything has improved or at least stayed the same.

Just stop writing CSS. Write HTML, you know? When you’re trying to implement a responsive design, you can sometimes get lost in a sea of CSS if you’re not sure how to structure it really well.

Ethan:

Nice. Well, I’d love to hear, as we come to the end of our chat, Colm, Yav, do either of you have any advice for our listeners? If someone’s starting a responsive redesign today, what’s one or two things that you’ve learned over the last year or so working on Marvel that you’d like to share with them?

Yav:

For me, it’s definitely using single-purpose classes.

Colm:

Woo-hoo!

Yav:

I know Colm is pretty proud of me that I started using that, his approach, basically. But it really does help with the way you think about layouts, and I strongly encourage people to check it out.

Colm:

Yeah, I would definitely second that. I guess in general, just stop writing CSS. Write HTML, you know? When you’re trying to implement a responsive design, you can sometimes get lost in a sea of CSS if you’re not sure how to structure it really well. So when you just kind of define all of your styles upfront in a style guide, but also in your codebase in CSS with single-purpose classes, it just makes everything so much easier. You can just whack out layouts without writing any CSS and without worrying about specificity or any other problems that you typically run into.

Yav:

Yeah, it just requires a bit of upfront work to think about what breakpoints do you really need, what breakpoints could you get rid of, and just defining your styles and things beforehand before you start the implementation itself. That definitely saves a lot of time in the long run.

Karen:

Well Yav, Colm, thank you for taking the time to talk a little bit about your process here. I think this has been super interesting.

Colm:

Yeah sure, thank you.

Yav:

Thank you.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Media Temple. Go to mediatemple.net for easy to use hosting and 24/7 customer support.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every episode at responsivewebdesign.com.

Thanks so much for listening, and we’ll be back next week.