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, we couldn’t be more excited to have José Scaglione and Aaron Mentele here to talk to us about TypeTogether. Aaron, José, thanks so much for coming on the show.

Aaron:

Yeah, happy to be here.

José:

Happy to be here, Ethan. How is everything?

Ethan:

Oh, gettin’ by, gettin’ by.

Karen:

But before we get on with it, I’d like to welcome back our sponsor, Gather Content. I’m thrilled that they’ll be sponsoring this podcast for the rest of the year. I recommend Gather Content to my own clients who are going through a website redesign. Gather Content provides some much needed structure and editorial workflow to help manage a large-scale content creation process. Because Gather Content works with so many organizations going through a website redesign, they have unique insight into how content fits into a web project. And because they are such great people, they wrote down their advice for you! They’ve put together a 41-page guide to Content Strategy for Website Projects. Head on over to gathercontent.com/RWD to read their advice or download a PDF to share with your team. Thanks, Gather Content!

Ethan:

Well, before we actually dive into the interview, maybe we could just take a moment and have you both introduce yourselves and maybe tell us a little bit about Type Together. José, do you want to go first?

José:

Yeah, absolutely. Well, I am from Argentina. I studied type design in England, in Reading. There, I met my business partner, Veronika, and together we put together an indie type foundry that is called TypeTogether. It’s been over ten years now; we started at the beginning of 2006, and it has been a nice ride so far.

Ethan:

That’s great. Aaron, how about you?

Aaron:

Yeah, so I work for a company called Electric Pulp, we’ve been around for about twenty years now, and we focus on web only. We say that we’re probably full service, but that amounts to anything online related and some app work. We do a lot of work with lifestyle retailers and maybe even some brands that you might know of, but we have a pretty wide range of clients.

Ethan:

Like I said, it’s great to have you both on the show because the new Type-Together.com site is looking great. So, let’s maybe back things up a little bit to the beginning of the process. I’d love to hear a little bit of how the decision was made to go responsive. José, when you and your partners were thinking about going responsive, were there any questions or concerns that might have come up in your discussions with Electric Pulp about responsive design? Especially for such a graphic-heavy site. Tell me a little bit more about that origin story.

José:

Our previous website was done back in 2009, so by the time we went into building a new website, I think the actual development of a responsive site was well overdue. At the beginning, we did try to kind of revamp the existing website to make it responsive. For that, we tried some mock-ups from the company that does the back-end for the website, and we weren’t impressed with the sketches or with the possibilities of adapting the existing site into a responsive environment. So yes, by the time we contacted Electric Pulp, we had already said that we needed a responsive website, and not only that, but a bunch of new features, like a properly done typography tester, which we didn’t quite have in the previous website. So, we sent a bunch of requirements that Aaron patiently read and replied to, and then we got the ball rolling.

Karen:

Let me ask if there were any questions about whether users would be coming to the website on mobile devices or on desktop computers. Ethan and I have talked to a number of type organizations, and one of the things that always comes up is the idea that people tend to be looking at typefaces on their larger desktop machines. Is that something you considered?

José:

According to Aaron’s stats, we had only about four or five percent of visitors coming from mobile phones. So, the idea was to have a site that was full-featured for desktop computers but that could also present only typography in a very subtle manner, but very directly on a mobile phone. One of the things that we had to tackle was how to diminish the amount of content for the mobile phone.

Aaron:

Yeah, there were a few things going on there. You would think, to your question Karen, that if a person was looking at a font specimen, they’d really want to inspect it, they’d want to see it in a large view. So, the type tester that José mentioned earlier, that’s something that if a person goes in and wants to type, “The brown fox jumps over the lazy dog” kind of thing and see the font change in real time, the question was is that going to work well on a mobile phone? That kind of question came up a lot. What we tried to do is figure out the use for each device type. It wasn’t just a case of, “Is this going to have three columns or one column?” or maybe some of the traditional pattern questions that come up early on a design project. It was more, “How is the site going to be used on each of the different devices?”

What José hasn’t mentioned yet is that the site was a very technically deep site; there was a transactional nature to the site. There’s a lot going on behind the scenes on the site. It’s not just a design site. So, there were really two kind of large challenges, and given what they do, being a type foundry, there were a lot of aesthetic challenges, but in addition to that, there was this transactional nature of the site. So the question of whether or not certain things happened on a mobile phone came up pretty early. Stats came into play to see whether or not people were using it historically, but we also had to kind of factor in whether or not people weren’t using it on a mobile device because it wasn’t formatted for a mobile device. A lot of that information comes into play. So, it wasn’t just statistical background, there had to be a little bit information that went into how people would use it if it was built for it. So, there was a lot at play there.

Ethan:

Given a few of those device-specific considerations, did that change the way that you might have structured the contract or scoped the arrangement for this project, Aaron? Tell me a little bit more about how you actually structured this redesign.

Aaron:

Sure. So, normally what you do with a project is you can think mobile-first and you can factor maybe the design templates, figure out all the different looks that are going to have to go through a design review. You’d start with a viewport, usually a smaller viewport, and you’d work up from there. In the case of TypeTogether, they’re designers, so everything they do is intentional. So, it didn’t just turn into a series of templates and then a pattern library that was going to kind of work as a rule system for what happens at different viewports, it was more of a case of how do we make each of these ranges intentional. So, there was a little bit more that went into that factoring for what the design effort was going to be, and then at the same time we were looking at it from the perspective of which of those device types were going to allow some of the technical functions of the website too. Type tester is a good example; being able to purchase fonts, all of that kind of went into play, too. So, where normally you might look at a site in terms of all of the screens that you’re going to have to design for and build for, this was a case where it was those screens and then each of the different uses on those screens. So, it was a little bit more sophisticated, but it was something that everybody was kind of aware of at the beginning, so we went into the process with the right idea rather than it being something we discovered deeper into the project and then had to backtrack on.

Karen:

Let me ask a little bit about the editorial or the content strategy for this site. I know you don’t really necessarily think about type foundries as having a lot of content, but did you think about how you merchandised the typefaces, how you described things, other marketing or editorial texts that you had to produce?

José:

In our case, I think that was one of the earlier conversations that we had with Aaron and his team. The fact is that we do sell typefaces, but we do a bunch of other stuff, like workshops; we have a scholarship, we give lectures, we have a primer on how to choose typefaces or how to order custom-made typefaces. So, we do produce a bunch of content that needed a home, let’s say, on this new website. On the previous website, we had a whole education area, a news area, and an area that we called Custom Type, and most of that ended up being a single editorial package that we called Blog. We struggled a little bit to find a new, if I remember correctly. But one of the ideas that we had was to convert this blog into a platform that could hold more in-depth articles about typography, how we feel about it, how we produce it, and, let’s say, the history behind the fonts. I think the structure that was designed for this blog is really something that we like a lot about the new website.

For the typefaces themselves, one of the earlier things that we discussed was that we wanted typography to have the leading role on the website. So even when we put some piece of news on the home page, that news is presented with a nice typographic pair that we can choose or design. So, even our editorial content is shown through our own typefaces. I’m not sure if that answers your question a little bit.

Ethan:

I think that was great. In fact, I’d love to maybe drill in a little bit more on that word “design,” because I’d love to hear how Electric Pulp, Aaron, from your standpoint, how you actually partnered with an entire client that’s basically staffed by working designers. How did you actually start talking to them about aesthetics? How did you start teasing out some of their ideas for designing this responsive site?

Aaron:

Yeah, designing for a type foundry, no big deal, right? [laughs]

Ethan:

[laughs] Tell me about that.

Aaron:

That gave us a little anxiety at the beginning—I mean me, personally. Stefan was very involved in this from the beginning, and one of the things that we try to do is not bring our own style but really take the client’s style and bring that to life online. So, that’s a little bit of a more daunting task when you’re working with someone like José and Vik, so it was a big thing. When we got started, we learned from José’s team that it wasn’t just the typography but it was the context of the typography. How does the typography look when it’s in use? That was huge for us, and when we went through the requirements and really started thinking about this, it wasn’t just how do we show the type, it was how do we show the type in context? And so when José says that it’s really about the typography and typography first, it was a lot of background for that. So, how is this font going to look in use? And not just a single element of it, but all of the different possibilities of how you would use that font together. It’s a big thing with their work, is you have font pairings and all of these different things that are going to change the look of the font. So, we were really trying to bring that forward.

It went from something that I think that maybe at least I personally felt a little anxious about, to something that I think Stefan really had a lot of fun with, because you can push something when you have people, again, like José’s team saying, “Here’s how we want the font to be used,” and build off of that. It really turned out to be something that certainly is a lot more than it could have been if we were just building in a vacuum. So, it started out maybe it was a little concerning to be working with people with such high design backgrounds, and I think really what came out of it was a better end product.

Ethan:

Speaking as a longtime fan of the site, I would definitely agree, it’s lovely work. I’d love to hear a little bit more about what kinds of applications and tools did you actually use to tease out some of those requirements. Are you using more traditional design applications? Do you find Electric Pulp’s doing a little bit more prototyping these days? What were you showing to José and his team at different points of the process?

Aaron:

There was a lot of this that was built up in Sketch. That maybe dates the project—again, we’re obviously still using Sketch—but it was something that… I can’t even date this. It’s been just long enough, though, that we hadn’t been using Sketch for a long time, and the tool made it really nice to create the library and be able to show all the different views and how all of these different pages would appear side by side. Where normally maybe we would do a little bit of that prototyping in the browser—and we definitely did some of that—we tried to get a good handle on those looks in the high-fidelity comps prior to even taking them into CSS. So, it was both.

Really when we got into some of the things that were maybe more functional in nature, like the type tester, that was really prototyped in the browser, and there was a lot that went on with the functionality of that type tester that we were constantly having to test. Not just simply from a scripting perspective, but testing from a usability perspective. That’s really hard to show in a design mock-up. So, that was something that this process was maybe a little bit more nuanced in that—back to the comment about this needing to be designed intentionally for all the viewports—we were doing a lot of that viewing as we went. So, we were trying to capture a lot of that from the very beginning, comps in Sketch, but really that was multiplied when we got it into the browser and starting testing it on more and more sizes. It was a pretty traditional model of how you’d build: we’d design in Sketch and then we’d produce it and then continue to test out in the browser. But in this case, it was just maybe that there was a little bit of a deeper look at each of the different viewport ranges. So, it was standard model but maybe just kind of with a multiplier on it, a little bit deeper.

Karen:

Let me ask about the rest of the team that was involved in this process. Did you have to share this around with multiple people? And were there tips or tricks that you have advice on for presenting this work so that everybody understood what they were giving feedback on?

Aaron:

On José’s team, it’s José and Vik, and they’re both really good to work with there. They had different personalities, but we were getting a lot of really good instructional feedback early, and so we had those two. On our side, we had Stefan, who was the primary designer on it, we had Brian, who was the primary front-end developer on it, and then we had a lot more people on the team. It was a constant case of we’d have a lot more eyes on it than we’d have hands on it, and I think that was primarily kind of back to this idea that the site had to appear intentional on all of these different browser sizes and had to be useful in all cases. So, we had a lot of user testing going on. In our case, most of that user testing was the users were on the team, so it was a little bit different in nature but we definitely had a lot more people involved in it.

The share-out probably happened sooner and more often than maybe it normally would. When we dig into those certain areas, like the type tester, those really kind of turned into a case of a development in terms of what could be done, because some of the things that were wishlisted were things that weren’t going to work across all the browsers. There was a lot of JavaScript involved in creating something that would allow that type tester to work that would also degrade down, and it was something that we really kind of had to go back and forth on, it was a little bit of experimentation. That put us sharing out earlier and more often as well. So, I think the case was that even though we had maybe five primary stakeholders—I was involved and the project manager was involved as well, so let’s call it six—we had a lot more people involved and giving feedback throughout the process.

Ethan:

I’d love to hear a little bit about some of those trickier features you mentioned, Aaron, like the type tester, for example, and you mentioned how they’re going to degrade. How did you actually talk about browser and device support in the course of this project? Did you work with José and his team to figure out which browsers needed to have access?

Aaron:

The ongoing request was, “Let’s get it to work with everything,” and then we’d see how far we could take that. Then it was mostly a case of can we live with it not working with this set of browsers on this OS, or whatever. It’s the question of, “How important is IE” type of process. So, there was your base functionality. Aype tester on the surface, seems pretty simple, but when you start looking at all of the potential characters and all of the potential languages, and the font sizes and all of that, it kind of grows exponentially. And so to do that, you also have to consider that you’re loading web fonts that you need all of the special characters for. So if you can flip font specimens and every font specimen has to have all of these possible characters, it gets pretty large, pretty quick. There was a lot of that that went into it. It wasn’t just a case of which of the modern browsers that can accommodate scripting, it was also a case of what can we do in terms of file size and bandwidth, and what’s going to require certain processors. What’s going to happen on an iPad when we get in there? And are people even going to use it, so is it worth the effort and worth the payload? So, there was a lot at play on it.

I think that primarily we were really trying to come up with use cases first so that even though ideally we would have it work for everybody, we wanted to be realistic about whether or not people were going to be able to get everything out of the type tester on a mobile device, for instance. That’s a question that’s maybe not real popular. I know a lot of people think that it’s presumptive to say that your audience is going to not use a certain set of functionalities on a mobile device, but in this case there really was some viable cases for that. So, we did have scenarios and use cases, so we had segments. From there, it was more of a case of okay, so now if you have a use case where maybe a person isn’t going to do all of the font testing on a phone, does it even belong there? So, it was partially a case of can we get it to work, partially a case of should we get it to work. There was a little bit of that going on throughout, and there were other places that it kind of come up. I think the font tester, the reason why I keep falling back to that one is that’s such a big part of being able to understand and then purchase a font: you need to be able to see it in action. They had a particular case where that would seem like maybe that wasn’t a real difficult part of the overall scope, but it was really kind of a focus feature of it.

José:

If I may add to that, one of the things that happened with the font tester is that after Aaron and Stefan and their team prepared the front-end for it, then we went back to the company that built the actual back-end, the commercial process for the website that is called Dynamic, is here in Argentina, and we realized, for instance, that some of the features we wanted to present in the font tester weren’t even included on the back-end. So, the back-end had to be somehow redeveloped to have those features in. Things like allowing for writing from right to left, or things like the OpenType features, all of those had to be somehow added on the back-end.

Aaron:

Yeah, that’s definitely important. There was that hand-off of, okay, so on the front-end you can display it, but if there’s no handling for final implementation, that was definitely another consideration as to what went into this.

Karen:

How did you think about measuring the success or the effectiveness of this site? Aaron, I know you tend to have a lot of thoughts on how you go about measuring the business performance of the site.

Aaron:

Yeah, so this case is a little bit different. Primarily the goal would be let’s sell some fonts, and you can typically set up analytics to show conversion rate. In a case like this, really you need to look at a period of time to see whether or not your conversion rate goes up, whether or not your revenue goes up. They have kind of a branding consideration also, so there’s is a tough one to measure. I think that there are certain cases where just getting customer feedback is as important as getting statistics, say, out of Google Analytics that will tell you where your revenue goals are at, all the different key performance indicators. So, theirs has a lot of both. I don’t think we went into this one really with some of the modeling that we go into with typically e-commerce clients in that the conversion rate really was not the key goal. It’s probably one of the only times I can think of where an e-commerce site didn’t have that as the primary focus. So, maybe José has some more thoughts on that, because this is really one where normally there’s a mix of art and science—I think there’s a lot more art that goes into this one than the typical revenue site.

José:

From our point of view, it’s still very early. We wanted to increase traffic a lot and, if possible, yes, sell a bit more. But the first thing that we realized—and the site has been online for a month and a half or something like that—is that people starting the purchase process now tend to finish it more often. So, our system can tell us where people stop the purchase process, and that number changed drastically with the new website. It seems like when people start the purchase process, they tend to finish it now. So, that is something that was kind of impressive as a result. But other than that, I would say in terms of branding, the new website was very well-received.

Aaron:

Yeah, they definitely have a funnel. The previous site, there was a point of confusion where they had kind of a purchase drop-off. So the checkout flow from the cart to the checkout was totally recreated, and actually I think it was recreated twice, and that was where a little bit of the consideration of the back-end platform had to come into play. At first it was, “How far can we take it using the current platform?” and then it was, “What would we do if we didn’t have to worry about the back-end platform?” and so that’s where it ended up. Definitely the checkout flow changed. But again, it’s not a case where their average order is twenty-five dollars, and so you watch conversion rate and that’s your metric. This was more of a case of the use came from a lot of different places. Checkout flow, that’s an easy one to address. Overall usage in their case, again, there’s kind of a few different ways to look at it and they’re not all statistical.

Ethan:

Well José, Aaron, this has been a really fantastic chat. We can’t thank you enough for coming on the show. But before we let you go, I would love to hear if you have any advice for our listeners. If someone out there in the audience is about to start their own responsive redesign, what should they be thinking about or working on so that they can produce something half as beautiful as Type-Together.com.

José:

I have very good advice for them: just go and pick a nice, nice typeface!

Ethan:

[laughs] Do you know anywhere we can get one?

José:

Oh, I have a couple of ideas, yes. [laughs]

Ethan:

Words of the wise. Aaron, how about you? Any advice for listeners?

Aaron:

Yeah, I think you go out and pick a really nice design agency. [laughs] So, this is really a case where I think in this particular project, José and Vik really knew what they were going for. So, the first thing is really to consider who’s your audience or what’s your best audience, and how can you get them to interact with you the way you’re looking to do it, and what are your goals? All of those things, you need to know those first, and from there personally I think it’s really important to not get lost in best practices too early or to get into patterns too early. I think the patterns come from your style guide rather than the other way around. So in a case like Type Together, that was really something where I think the patterns came really late in the process, and I think that those are the cases where you’ll end up with maybe the most aesthetically pleasing version of the site. So, just really kind of come to the process rather than start with the process. I think that’s really important.

José:

If I can add something, and this is not because Aaron is hearing this, but it is important to work with people—and I think Electric Pulp is one of them—who are willing to take a risk, who are willing to be proven wrong, or who are willing to hear about a different direction. It’s challenging at times, but it’s good to try something new and see where you can get.

Karen:

Well, I think that’s good advice for everyone. Aaron, José, thank you so much for taking time to talk with us today. It’s been fascinating. I always enjoy our conversations, Aaron, and the next time you have somebody amazing to bring on the show, please do.

Aaron:

Sounds good. Thanks for having us.

José:

Thank you to both of you.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

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.