Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, I couldn’t be more excited to be talking with David Demaree and Jake Giltsoff who are coming to us from Adobe Typekit and talking about their lovely new responsive design. David, Jake, thank you so much for joining us.

Jake:

Thank you.

David:

Thanks for having us.

Ethan:

So before we dive in, maybe you two could just introduce yourselves, tell us a little bit about Adobe Typekit, and what you do on a daily basis. David, do you want to go first?

David:

Yeah, sure. I’m senior product manager at Adobe and I’ve been on the Typekit team since before we got bought about five years ago. Typekit, back in the day, was a web font service that a lot of people who made websites have heard of or be familiar with. For the last few years, we’ve also done desktop fonts through the creative cloud app. So these days, we’re kind of a one-stop solution for all of your fonts, whether they’re for desktop applications, your websites… We also have some really nice integrations with Adobe mobile app, so you can start doing some typography experimentation on mobile, too.

Jake:

I’m Jake Giltsoff, I lead design at Typekit and I also work on front-end development of the website. So I’ll spend kind of typically around half my time split between design and front-end development. I recently relocated from the UK, where I was working remotely for Typekit, to be working out of the New York Adobe office. So I’m currently somewhere kind of mid Transatlantic in my headspace, but hopefully I’ll be coherent today.

Ethan:

Well, excellent. Welcome to the time zone and to the country. [laughs]

Jake:

Thank you.

Ethan:

We’re excited to have you both here, especially since the new website is looking, frankly, quite stunning. So as a long-time user of Typekit, I know the site’s relatively new to a responsive layout, and I think it’s been coming in stages. I’d love to hear a little bit about kind of the origin story for responsive design at Adobe Typekit. Specifically, how did you start the design process? I’d be really curious to hear if there were any questions or concerns around responsive design specifically as it might apply to Typekit.

Jake:

I’ll step in here first and then David can maybe talk about some more stuff specific to what we’ve been working on recently. So around the start of last year I think it probably was, we had one responsive page on Typekit, which was the home page, which was more of the sort of product marketing page rather than part of the UI. So most of the UI was kind of sitting on a standard 960 grid, as many sites used to be, and it was kind of getting past the time where that was being useful for us. There wasn’t exactly a particular project we took on to start pursuing responsive design for the rest of the site, but I started to use some of our more downtime periods to work on rebuilding our CSS architecture and thinking about how we can use some of the more quieter periods to rethink the way that we manage pages, and building in some responsiveness to the pages, which turned out to be no mean feat. And as you said, we kind of rolled it out to a few pages at a time, and even today we’re still not fully all the way there. But I’d say this has definitely been the right sort of approach for us, because we’re quite a small team within Adobe and we don’t have necessarily all that many resources to be putting into working specifically on making all of our pages responsive at once. So, it has been working out okay for us. We still have a long way to go and we definitely want to pursue that.

And David, maybe you want to jump in and talk about how some of the newest pages that we’ve been redesigning and how we’ve been tackling responsive stuff on that.

David:

Yeah—well, first on some of the long-ago origins, I’ve been agitating to do some design refresh of Typekit for a couple of years now. About two/two and a half years ago when Adobe did a big product launch here in New York, Typekit was up on stage, and our UI hasn’t been on stage at Adobe events that often, but this was one of the rare times when it was, and they were showing it on a big 1080p display, and as Jake just mentioned, we’ve been a 960 fixed-width grid for our entire history up until a month and a half/two months ago. And so there was this 960 island of font cards and UI in the middle of this sea of beige because they were just showing it maximized on a gigantic display, and that was like the first—we knew, like all design teams do, that the design was getting a little bit old and there were some problems we wanted to be able to solve by throwing the whole thing out and starting over again. But around there was when it became concrete that, “Hm, there’s definitely some valid use cases that we’re not covering here and responsive might be a way of solving that.”

More recently, one of the things I think that was hard is that we had various ideas for wanting to refresh the site, wanting to do something that was more responsive, but a responsive design or a design refresh in and of itself was never enough to get funded. We needed to have some angle or some user value other than just a new UI to push this project through to development and completion. For us, the “Mcguffin” for that was Typekit Marketplace, which we just launched at Adobe MAX. Even though it was still pretty much a secret for a few weeks after we launched the responsive redesign, that was kind of the reason why we did it, because as we dug into Typekit Marketplace, there were a lot of places where the five-year-old UI just stopped making sense. And so in the course of solving other design problems, we were like, “Okay, well if we’re doing a new design in 2016, it should be responsive. That’s just a given.” So we were able to fit that in in the course of doing dozens of other things.

Karen:

Talk to me a little bit about how you might have discussed the needs of the hypothetical mobile user as compared to what we might see as the traditional desktop user. Ethan and I have actually talked to several companies that put fonts on the internet, and one of the things that tends to come up is this idea that people who are purchasing fonts tend to be working a desktop computer, and so perhaps the scenarios for mobile use is a little bit different. Can you describe how you thought about that?

David:

I think one reason why it was kind of slow for us to get a responsive design in is the idea—which is still I think maybe eighty percent true, that responsive is really targeting smaller screens and lower bandwidth or offline situations. And right now partly because there just aren’t a ton of pro-creative apps or even apps that are typographically aware on mobile devices, it’s been a little bit harder for us to make a case. We’ve had little requests for iOS support or better touch support for years, mainly from iPad early adopters who wanted to be able to open up Typekit, browse the library, maybe even create a kit from their iPad, but that’s never been such a strong use case for us that we invest a lot of time in it.

But at the same time as thinking of the responsive case in the other direction, knowing that we have people out there with larger displays who are our more core pro-creative audience, who we could be serving better by scaling up rather than down, we know that there’s also a new class of devices that are sort of mobile but sort of not. Like the new iPad Pro, the Surface Pro, things that have a lot of the characteristics of mobile devices, like touch interaction or pen interaction, smaller screens that need to be just as capable as the larger screens.

So I guess the short answer is, for mobile, as people normally think of it as the smaller hand-held devices, we feel like there may be some really interesting stuff coming down the line that we don’t want to miss out on, and by going responsive, we are really well-positioned to serve those users when they come along. But the fact that we know that there was a responsive case for serving people on touch devices and larger screens made it worth our time to go responsive, and just as a bonus of when or if pro-graphics apps or typography apps come along for the smaller screens, we’ll be in a position to meet those customers the second that they come on.

Jake:

To kind of segue off that point somewhat, something that we did pay particular attention to I think as more of a “realign” than a redesign as such, was thinking about the universal responsive system. So as David was saying about larger screens and smaller screens and touch devices and devices that are somewhere in between desktop and mobile, and maybe they could have touch capabilities but maybe they’re not being used for touch right now, and how we could make our UI for browsing fonts more universal in that we didn’t want to rely on hover interactions, for example, which we’d previously had a significant amount of, whether it was in the font cards, in the browse UI, or with informational tooltips. We stripped those right back and focused on putting information in different places or removing it altogether if it just wasn’t needed anymore.

David:

Yeah, totally. In a few places we also considered the industrial design, if you will, of the application, and moving some things over for touch. One example of this is to sync a font or add it to a website, you just have to go into a modal dialogue which had a bunch of dropdown menus and checkboxes and then change the state of those checkboxes and click another button. Which was fine, and I think it seemed a little bit more efficient from the desktop perspective, but if you’re coming into Typekit for the first and especially if you’re on a touch device, it’s a lot more immediate to be able to just tap one button to sync a font. So that’s a change that we made, as we now have what’s called Quick Sync, where next each font on a family detail page—which are the pages that show all the fonts within a typographic family—instead of having to go into some desktop-like interaction to turn on or off sync settings, you can just tap them on or off right there, which is an interaction that I think works really well with the mouse but also is just as comfortable with a finger, which wasn’t true with what we had before.

Ethan:

I’d love to hear a little bit more about the design process that you used to start in on this really kind of iterative responsive design. Jake, as someone who is sort of realigning an existing desktop-only website, how did you get started as a visual designer? How did you start making this thing responsive?

Jake:

The design process has been kind of a long time in the coming. Towards late last year, we were working on a version of this project which didn’t actually end up making it out of the door. But we built up a new visual style with Elliot Jay Stocks, our previous creative director. He and I worked on a new direction for making things a bit more up to date in terms of styling and fitting in better with the Adobe ecosystem, making it feel a bit more Typekit-friendly, a bit more in place within Adobe as a larger system. And then in terms of when we actually came to look at this project again in terms of making the browse experience responsive, we typically kind of work in—we still use some static mock-ups I think effectively because we have a much larger dev team than we do designers, so we want to have kind of everyone at least on a similar page to get going. So I’ll typically still stick to making some rough mock-ups in Photoshop, and then having conversations with the development team around how I see these working in responsive environments, how I see them flexing and whatnot.

And then when it usually comes down to it, once the back-end infrastructure is sort of in place, I will take a pass at the front-end styling on top of whatever has been built already and then add the sort of key level of polish and of the full responsiveness. So, kind of putting in all the breakpoints, working out where things need to flex and where things need to break.

Our UI is extremely complex and we also have four different localizations, so the site’s in English, French, German, and Japanese, which brings up even more challenges in terms of responsive design, because not only is it flexing in one language, but then when you flip to a German locale, all the texturings for the UI elements are like five times the size, and in Japanese there are other considerations around making the layout more uniform. So, it typically comes down to working from some static mock-ups which are seen as kind of a starting point rather than pixel perfect, and then getting it into browser as soon as possible and working from there.

David:

Yeah, and then as we were going through some of that first bit of prototyping and static mocking, a lot of the thought process of how we would adapt the old desktop Typekit to responsive Typekit was just an ongoing socratic dialogue of, “What happens to this element when you take away two-thirds of the screen space? Where’s this going to go?” Just having ongoing conversations to just vet what information was absolutely essential and whether it would make sense in its current form if it had to scale down or up to a different screen size.

Karen:

Let me follow up, sort of related to your point about different languages, and just ask generally about how the content for the site might have played into your design process. So as you were considering not necessarily the fonts themselves, but as you were thinking about what other text has to be there, how did you think about that editorial side or the publishing process for the site?

Jake:

I guess for this project it was slightly different, because as we were redesigning pages we already had, there wasn’t so much brand new content. For the most recent Marketplace launch, we did completely redo our home page and added a new Marketplace “About” page, which those did have entirely brand new content. So for those two pages, we have an extremely talented copywriter, Sally, on our team who we all worked closely with on this project. So I guess I started by making some rough wireframes and thinking about the content we previously had on the home page and how we could reuse that, and which bits of it were still important for us to keep and which bits we needed to add in. And then I guess there were a number of calls with the wider team and we discussed which bits that we needed and which bits we didn’t, and then there’s a kind of more deeper editorial process of back and forth of changing individual strings in Google Docs with Sally and the rest of the design and product team.

Ethan:

I’d love to hear a little bit more about testing. Specifically, you mentioned all the different languages that this responsive design has to accommodate, so I’ve got to imagine that that just foists a whole bunch of extra complexity on the design itself. How are you testing this responsive design not just across different devices but across different language sets? Is that something you could speak to?

David:

One thing that has been a challenge for our team because as Jake mentioned earlier, we are a pretty small team within Adobe, so we don’t have a lot of people that can be dedicated 100% to testing or to going through like a test protocol, we do work with some other teams that are responsible for quality assurance on the translations themselves. So the testing process—well, for the internationalization part, for the different translations, once the translations are back in, we’ll have a team over in Adobe’s globalization team go through everything just to make sure that they can see and confirm the meaning of all the different texturings, and if they can’t get to something or if it doesn’t make sense or if it breaks the layout, we will occasionally get a bug filed against Typekit that we’ll work through. But we don’t work very closely with those teams, it’s more like just a community bug report within the company. For pretty much anything that isn’t localization, we’re on our own to test it. We have a few people that we lean on in the company who just work with the site while it’s in a pre-release form and let us know some of the stuff that we find, but a lot of our testing was just rallying the team in Slack, sometimes inviting everyone to a meeting virtually, at least bringing bagels, but just encouraging everyone to come in, just go through a bunch of different workflows and check it out all at once. And then also when they had spare time, just come into a Slack room, get some credentials for the staging server and let us know what they found.

Jake:

And another thing that we use typically when we’re launching something new is an early access program. So we’ll typically kind of put out a very rough-and-ready version to family and friends we like to call them, and then perhaps a week after that we’ll announce via our blog and Twitter that we’re doing early access of a new feature, and then we have a thing in the Typekit account page where you can flip on the new feature and test it out. And we do rely on a lot of feedback from that, and we are very open to listening to support requests as a whole anyway, and I guess that’s kind of one of our biggest methods of testing, is we listen to what people say and make sure that our ideas are being validated as opposed to spending hours and hours browser-checking absolutely everything.

David:

Right. That’s a bit of a—I wouldn’t even call it a methodology change for us, but something that we’ve been trying to prepare for with this design a little bit more. When we go into early access, we aren’t anticipating that things are going to break because we try to go through at least the most common cases, like we make sure that it’s working in all the major browsers and current operating systems, we check it on the most common mobile devices to make sure that it works. But we have tried to clear out a lot of technical debt and cruff from the code so that as feedback comes in from the community, we’re able to react to it very quickly. Because it’s not very nice to put out something that may not be completely perfect to a large public audience, but we try to put ourselves in a position where if something is a little bit broken, a little bit suboptimal, or even if just our hypothesis of how to solve a particular problem could use refinement, we can make those changes a lot more quickly than we used to so that we can take a few more risks out in public knowing that we can only be a day or two away from a solution rather than a longer period of time.

Jake:

Yeah, that was a big part of this redesign as well, was to kind of rethink the infrastructure behind our main browse page, which will give us the ability to iterate much faster, which is a nice place to be in, especially working from a responsive design, because things aren’t always going to be right and there’s always going to be little things that need tweaking. To be in a position that makes us be able to iterate on what we have much faster than we previously used to, from an engineering standpoint, is a really great place to be in.

Ethan:

Since you both mentioned the word “faster,” let me ask a quick question about performance, because I remember this in the redesign announcement as something that was a key goal, for making the overall font browsing experience not just responsive but also feel a little bit faster. How was that measured during the course of the redesign? Was that something that you talked about a design goal, and if so, how did you actually evaluate it?

David:

Well, we didn’t assign ourselves a bit budget or anything, it was more just like we looked at perceived performance as much as we could. So we should probably just say, on a quantitative basis, we are probably not the fastest website that there is out there. It’s going to be a little bit difficult for a site that loads twenty web fonts on a page to achieve the absolute pinnacle of performance. But we were coming from a place that was pretty slow, especially in how we approached font loading and font subsetting. So, we started out just trying to improve performance in the architecture. Like previously we were using Knockout, which is a JavaScript framework that I think not too many people ever used, but certainly nowadays not that many people use, and switched over to Angular. So we’re doing a lot more with AJAX and pushState. Where before we might have had to reload all of the scripts and stylesheets to a full page refresh, we’re doing a lot more that can happen in the browser, so there’s a lot of just perceived speed and a lot less network traffic going over. Do we have instrumentation on that? Actually, that’s a good question… Jake, do you know, have we been monitoring or instrumenting that stuff, or just been going on the gut?

Jake:

Not really. It’s a difficult position to be in with performance on Typekit.com. We very much do follow best practices in terms of image sizes and making sure we’re using SVG assets, which are kind of in a good file size and whatever; we’re not loading in anything unnecessarily. But as we are loading in often hundreds of web fonts on different pages, we are kind of set back, so we haven’t really been measuring anything as such. But one key takeaway for me was early on I was trying to play around with a few animations, I think like the latest version of Framer had come out and I was playing with some prototypes of some nice animations when you loaded in the font cards. Which we managed to get working really nicely, but it was just killing the perceived performance—well, I guess the actual performance as well—but it just made the whole site feel so slow. And then as soon as we were like, “Hm, I wonder if we just kill these and look at what’s going on to see if we can debug what the problem is…” As soon as we removed those animations, everything just felt like ten times faster. So, I had some key takeaways in terms of things that you think might make things feel faster often have the reverse effect.

David:

Well, I had actually totally forgotten about that animation, that’s probably a sign that that was the right move to take it out. But yeah, I don’t think that there was anything wrong, unless I’m remembering wrong, with the browser performance, memory usage, none of the metrics, other than just the fact that the page was taking an extra couple of seconds to do its job for an animation that, I think when we first put it in there, seemed like it was a good idea to transition from one state of the UI to a different one. But as Jake said, once we took it out, the transition was totally clear. I come from a film background, so I’m used to the idea that people might need a little bit of a transition or something to segue them from one state to another, but in this case switching things around was imminently logical and we were just wasting people’s time, so we took that out.

Karen:

Well, I think that all of this has been so interesting to get your perspective on. I bet everybody in the audience would actually like to get some advice from you on what they might do to make their project or their process go a little bit more smoothly. So if you had to give some advice to our listeners, what would you say?

David:

Trying to push forward a responsive design, I think my big takeaway is just to consider the whole spectrum of responsive use cases. For us, it was a little bit hard to make a really concrete case for who our mobile users were going to be, because that was how a lot of the discussion around responsive was anchored. And one, by having some other really great, valuable features that we wanted to develop, and also knowing that the responsive methodologies, like having stuff in our toolbox that would serve both the small screen and large screen users alike, knowing that the larger screen ones probably are a more traditional persona for who were going to be using Typekit… Those things taken together made a really strong case for doing a responsive redesign and knowing who it was for and what we were trying to get out of it, and then having a much more flexible framework to serve everybody, even people who may not be using Typekit yet on smaller screens, knowing that we’d be able to serve them because we had these tools in place. So I guess the takeaway is just don’t hesitate to go responsive just because you don’t have mobile users. The tools are there to support all kinds of different use cases.

Jake:

I’d say one of the biggest things that I’ve taken from the last couple of years is not to be afraid of breaking up a responsive redesign into several separate projects. I think it’s kind of amazed me how people are very forgiven or receptive to separate pages becoming responsive at a time. I remember thinking that when we initially started launching some newer responsive pages that they all needed to be responsive at once, and at the time, even still now, we just don’t have the resources to make that all happen in one chunk. So, I’d say be receptive to feedback but think about how, if you do have a massive site, that you can kind of get away with breaking things up and thinking about which are the key pages that would be more useful to be responsive and then working from those, and then some of the pages that might be more useful on desktop, they can perhaps wait until a bit later. I think we kind of stole that idea from GitHub—or I’m sure several places have done that before.

David:

Yeah, GitHub is who I kept bringing up, because they did a mobile redesign—their site is not even strictly responsive, because if you do the thing where you resize your browser window, you don’t end up with their mobile site, it’s more like they actually sniff user agents and push a totally different mobile interface. But the fact that they did that for like—I think they did repository pages and then they did profile pages, like they had half of their site that was not mobile-friendly for years and years—I think there still are some pages that are just not really working on mobile. But the stuff that you’re most likely to get to through a hyperlink, where you might be coming from a mobile view of Google or a mobile view of someone’s blog, those are the ones that they started with first, which I thought was a good guideline for how we approached it. We started with the family detail page, like a previous version of it, because that’s the thing that people link to most often. So, we wanted people to have a great experience coming to Typekit from something else that might be mobile-friendly and then went from there—where else could we find opportunities to put a little bit of mobile or responsive friendliness on the way to doing the full redesign.

Jake:

Yeah, I’m so glad that we finally have a responsive font browsing experience now, as well. Hopefully soon we’ll be able to get to some other pages that we won’t mention. [laughs]

Ethan:

[laughs] Well, I have to say, this has been a wonderful case study of a very carefully planned and iterative redesign process, and I can’t wait to see where the Typekit site goes next. So Jake, David, thank you so much for taking a few minutes to chat with us.

Jake:

Thank you.

David:

Thanks so much for having us.

Karen:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near 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 podcast episode at responsivewebdesign.com.

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