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, and this week, slightly different format because Karen McGrane’s traveling, so I’m flyin’ solo. But that doesn’t change the fact that I am beside myself with excitement to be speaking with Daniel X Moore and Pirijan Ketheswaran, who are coming at us from HyperDev. Daniel, Pirijan, thank you so much for joining us.

Pirijan:

Good to be here.

Daniel:

Thank you.

Ethan:

But before we dive in, a few words about our sponsor. I couldn’t be happier to have Gather Content back as a sponsor on the podcast. You see, Gather Content is a content collaboration platform. It helps teams plan, organize, and produce all their web content in one place. They provide structured templates and simple workflows to make collaboration and production easy without the shuffling around of Word documents and unnecessary emails. Centralizing the editorial process will make approval of content easy, so everyone knows what they’re responsible for and when they’re responsible for it. And what’s more, Gather Content has recently published a free online guide to Content Strategy for Website Projects, which they’ve written for all the people who want to make smarter, content-led decisions on their designs. So every responsive design, I believe, benefits from a content-first approach. But as Gather Content’s guide says, that doesn’t mean waiting until all the content is written. Instead, it means considering and thinking about content at every single stage of your project. And Gather Content’s guide can help you do just that. So whether you’re working in an agency on client websites or maybe you’re working on an in-house team, Gather Content’s guide should help you more effectively contribute to your digital projects. You can read it online for free at gathercontent.com/RWD, or check out Gather Content’s products at gathercontent.com.

So, why don’t you both introduce yourselves and tell us a little bit about what you do at Fog Creek, and then we’ll dive into HyperDev after that.

Pirijan:

Yeah, my name’s Pirijan, I’m the designer of HyperDev and also a front-end developer on it. Basically, I’ll do anything from drawing dumb pictures of cats to writing unit tests, and pretty much everything in between.

Daniel:

Hi, I’m Daniel, I’m the team lead on HyperDev, and I do a lot of the front-end web development, from CoffeeScript, which we use a lot on the front-end, setting up our build environment in Node, and even a little bit of systems stuff, setting up our CI. So, sort of all around but with a primary focus on the front-end website. Ethan:

That’s fantastic. Well seriously, thanks for taking a few minutes to chat with us. So for our audience members who may not necessarily know what HyperDev is, would one of you be willing to tell us a little bit about the product and what it does?

Pirijan:

So, HyperDev is a web development environment for making web applications. It’s pretty straightforward. You just go to hyperdev.com in your web browser of choice, it’s device agonistic, and you’ve instantly got a Node app that you can start editing and building off of, and that’s pretty much all there is to it. And a lot of details come in there, but it just works, essentially.

Ethan:

That’s fantastic, and I think part of the reason it just works is because it is a web-based environment for creating these applications, right? It’s effectively one of those web apps all the kids are talkin’ about, and it’s completely responsive, which I think is impressive, especially for something as complex as this. Maybe we could back up a little bit and tell me about how HyperDev first started. Where did the idea for the application come from? Specifically, for our listeners, I’m really curious to hear how the decision was made to go responsive, and were there any concerns about taking something as complex as HyperDev and making it responsive?

Daniel:

Yeah, I guess I can start, go back in time maybe eight or nine years ago, and it all started with a web-based pixel editor I was working on. This is like when IE9 didn’t even exist, so it was a very weird time to be working on browser-based stuff. But it was a hobby project, and I thought just going to a web page and having an application that does what it’s supposed to do, seems like the simplest way to run software, where you don’t have to download things, you don’t have to mess with stuff. You just go to a web page and your app’s already running. So I built this toy pixel editor, I’ve rewritten it like seven times over the years. But that idea was the start of where I really realized that you can make web apps that are native to the web, that do deliver, that can compete with native apps, that can compete with all kinds of experiences, and have the best quick-start experience for new users—or even for existing users returning to your app; if they just go to it and it works, you can’t really beat that.

Pirijan:

Where it started for me was I guess we started doing a process that we call internally Creek Weeks, about two years ago or something, and Daniel approached me with basically taking that idea from the pixel editor, taking the code part of that out, the idea being similar to what we have today, where you can just type in a browser window and then have a finished product. I remember thinking the original version was pretty whack, because it was front-end only and it seemed kind of complicated. But we just sort of polished the idea and we sort of pitched the vision of the product to the company, and yeah, we just sort of took it from there.

Ethan:

I want to key off something that you both touched on, was this idea of creating a device-agnostic web application. From that, were there ever any conversations about different contexts of use? Specifically, I’ve talked with a lot of product teams where there’s still this assumption that mobile users and desktop users are somehow dramatically different and that we should be sort of siloing different features and different functionality to those different areas of use. Was this something that HyperDev really did, or did you just all decide that the functionality was shared across different screen sizes?

Pirijan:

I think you can make the argument that on a phone you might want to do something differently because you’re on the move or whatever, than you would be at a desk. But ultimately it’s the same people and they want to do the same job, we think. So yeah, to us it seemed like not a hugely contentious idea that everyone should be able to use all of the features of the product wherever they are, whatever device they’re on.

Ethan:

That’s great. Let’s talk a little bit about how you actually started scoping and planning HyperDev. How did you actually structure the project? What was part of that first milestone? And has the fact that it is a device-agonistic responsive design been a challenge for designing something like this?

Daniel:

I think pretty early on, we knew we were going for a web-based approach. Like the whole core of the idea is that it is a web-based editor because that’s the quickest way you can start without downloading, without doing anything. It’s sort of like an added bonus that it works on mobile and that it works on every device by being web-first, I guess. Since that was always the core idea, we were sort of following in the path of Trello in that sense, another Fog Creek product that’s now spun out into their own company a couple years ago, where Trello has these boards, and I think they have native apps now, but in the beginning the idea was very web-first and sort of you have the same experience everywhere, like on your phone, on your computer, things like that. And so it was a way, if we could follow that same model and say you just go to the location of your app, you go to the editor, and you see the same thing on different devices, it might have different form factors or different emphasis, but you can tell it to direct you to the same place and the same application and make the same edits.

Pirijan:

I think for us, also a great thing about being responsive is that we didn’t have to build and maintain this separate m.dot HyperDev site that I’ve seen with a lot of products, that turns into sort of like a ghetto, where people make it and leave it alone while the main product gets shiny new features. We didn’t necessarily want that split.

Design-wise though, I think it’s kind of interesting because the real benefit of a responsive design to me isn’t necessarily about does it work on your phone, does it work on your laptop. I think what it helped us do is force us to ask really tough questions up front. So for example, we have this header at the top of the screen, and the traditional IDE, clip-style model is shotgun all of the features onto buttons everywhere. But when you have this sort of single environment that’s being used on every device, there’s a physical real estate constraint and it puts pressure on you to fight for every pixel. So I think for me, that’s a benefit that you feel even on a 30-inch monitor or on an iPhone SE or something like that.

Ethan:

Man, that’s poetry right there. That’s beautiful. No, I think that’s really eloquently put. Let’s maybe talk a little bit about how you fought for those pixels. How did you actually structure just the visual design process for something like this? Was it very browser-focused? Did you move into prototyping early on? Or was it a little bit more comp driven? How were you actually talking about the look for this new responsive app?

Pirijan:

I think mock-ups were a huge part of the original flow that we had, especially because we started from the Creek Week to having a deliverable, like, “Here’s some mock-ups of how this product could look.” That was sort of like the thing that we started the original version off of. And Daniel already had a version of the editor where it was sort of like plain HTML and it was very functional, and so that was also a great starting point for us. And then over time we moved away from mock-ups as the design language of the product matured and iterated itself, to being less reliant on mock-ups and more reliant on, “Here’s a rough sketch on a napkin.” I kind of got the sense of, “This will work. Okay, I’m confident enough to jump into code and now I can build it because the components sort of already exist now.”

Daniel:

Yeah, I think we try and get to prototyping how the design feels and the real application as quickly as possible, even if it’s sort of a rough initial implementation. And then we can start seeing how does it feel, how does it interact; when you use it, does it feel right? That helps us refine it further.

Ethan:

That’s great. Could you talk a little bit more about some of the tools or applications and frameworks you used to do that? Either visual design or code IDs—how do you actually go about sketching and implementing this?

Pirijan:

Oh, sure. So, visual design tools, I guess I live in Sketch, which probably is a controversial statement these days. But yeah, Sketch has been amazing. We actually published basically my design folder, and it’s just basically a very unorganized collection of Sketch files. But one of those Sketch files is almost 200MB, and it’s just all of the mock-ups of HyperDev over time, kind of divided into pages and a million art boards, seemingly. That’s what I relied on, especially earlier on, to get the look and feel to a place that I was kind of okay with, or just to mock up more radical ideas. And then besides that, of course, paper and pencil. These days, I’m trying to spend more time in text—not necessarily in code, but in just the copywriting stages of things and trying to understand the flow of how a feature should work.

Daniel:

On the dev side of things, we use Browserify and Node.js to compile all of our JavaScript into a single file that’s served on a single HTML page. And we have a single CSS file—we use Stylus for our CSS. And so at the end it all ends up on an Amazon S3 bucket served by CloudFront with Route 53 for the domain. It all sounds pretty complicated, but at the end of the day, it’s just JavaScript, HTML, and CSS. And so then with that as the destination, it’s sort of very easy to host it anywhere, very easy to get it to run on any device, because there is no real server side of the editor piece of it, we have a separate back-end API that actually runs your apps. But for the front-end the user interacts with, it’s all, at the end of the day, just plain HTML, CSS, and JavaScript.

Pirijan:

Actually, I think the deploy process is something you should talk about, because that, I think, is actually a design tool in and of itself.

Daniel:

Oh, yeah. As part of the deploy process, because we do build it in Node, we can run tests on the command line for how the behavior works, how interactions go, using jsdom and Mocha for testing. So we are able to use a lot of the Node modules and packages that other people have written, and we’re able to test them on the command line as opposed to having to test them in the browser or manually. So we are able to develop this sort of security when we try new things, when we build new features, because we have fairly good test coverage. And also as part of the build process, I added a check that if your total JS bundle that we compile down to the end is greater than 110KB right now, it just fails the build. So, we have to be kind of conscientious of what we add in. It has an advantage of when you download on a mobile app, you’re not downloading 4MB of JavaScript. And so every time we add a feature, we’re aware of how much it costs in terms of kilobytes and that helps us to use the right tools, use the right libraries that meet our goal without unnecessarily bloating our distribution.

Pirijan:

The other part of that is—I was kind of hesitant on the idea of, “Oh, unit tests as part of the design or the development process for the front-end…” But what’s great about it is because we have unit tests and because everyone is writing them, the deployment process is basically do a change, make a PR, merge it to master, and as soon as you merge it to master, it’s just out in production, there isn’t a crazy mid-week deployment cycle or whatever. We deploy whenever we want. That flexibility to be able to make a mistake but then to be able to quickly fix a mistake is invaluable.

Daniel:

Yeah, I even forgot to talk about continuous deployment because I take it for granted so much. [laughs]

Ethan:

That’s a really fascinating process. I’d love to hear a little bit more about the performance angle. Specifically, how did you settle on that budget for 110KB? Was that through research? Was that sort of an arbitrary cap that you put on things?

Daniel:

It’s basically arbitrary. I kind of started at a little more than what we’ve got right now, and actually what made me really put it in as a hard limit is, in Node, using Browserify, it’s really easy to just install a Node module and say, “Oh, this is gonna be fine.” But if you actually look at the size, the outputs, it could pull in a hundred other modules underneath it and it could suddenly add a megabyte for just pulling in a little tiny function if you are unlucky or if you’re not paying attention. That actually happened to me. I was trying out some SHA whatever encoding for these files, and it pulled in the whole Node crypto library accidentally, and added like a megabyte to the thing. I was like, “You know, if it’s so easy to do this, I better put in some kind of guard so we can’t just accidentally pull in megabytes.” And so I just put it at 20K or 50K, and every time we started to bump up against it, because we are adding new features and new things all the time, we’ve raised it many times, but at least we’re conscious of when we’re raising it and why, and we know that all the kilobytes going in there are providing value.

Ethan:

That’s great. I love introducing that idea of a little bit of mindfulness to the design process. The other thing I’d like to hear a little bit more about is how do you actually manage device and browser QA with something as complex as this? You talked a little bit about your unit test coverage, but how are you actually looking at how this looks on different desktop browsers, different mobile browsers?

Pirijan:

QA is interesting, because I guess I feel like whoever “smelt it, dealt it,” in the sense of—if you’re writing a feature or if you’re building some UI, you should be the one that tests that it works from a user perspective. And the unit tests are great, but… We’ve talked about instrumenting automated UI testing, we haven’t found a solution that’s particularly great. So I think right now, we’re just sort of manually opening up a device and trying it out, opening up a browser and trying it out before pushing it.

Daniel:

Yeah, I think this is something we could use a lot of improvement on, or at least there’s a lot more we can do on this side of the testing. I think there are a lot of tools—I think Browserscope, and some other ones—that can give you a bunch of screenshots on different devices, and we might want to set that up so at least we can have that record and visually look over the home page or a few different screens. And there’s also Selenium tests and other things, but even on that, once you start going down the road of very thorough testing on every device, it can make your testing take hours basically, because you have to test every browser version across every device. It can be worth it once you really know how your app is supposed to look and it should have exactly these pixels in exactly these places. But early on, since it’s still a fairly young product, we are sort of more flexible in how we move things around. So I think as it matures, we’ll gain a lot more of these integration tests, where, like, “The sign-up button is always going to be visible on this page,” and things like that. But for now, it’s a little bit of too much work for too little gain.

Pirijan:

And faced with sort of that amount of work for benefit… Like, I like the idea, in general, of failing fast in the sense of if we make a mistake, will we see it fast, will a user notice it fast, and can we fix it fast? If that happens rarely enough, maybe it’s just worth being able to move fast. Like the benefit you get from being able to move fast maybe justifies a potential reduction in the rigorousness of your testing.

Daniel:

Yeah, there’s definitely a trade-off in the thoroughness of your testing and how long your tests take. So if it takes an hour to do all the testing but you know everything is in exactly the right place, that has a benefit, but it also has a cost. And then if we don’t even really know exactly the right place for every feature and every button yet, it means when we’re building those tests, they’re somewhat ambiguous, and then if we change something, we have to change the tests. So there are real costs on a deep integration, multi-device approach, and I’m not sure anyone’s really hit the holy grail on that yet.

Ethan:

Yeah, that’s interesting. Well, since you’ve both said that this is such a young application—I mean, it just launched in June I think, is that right?

Daniel:

Yep.

Ethan:

Yeah, so how are you actually managing the review process for HyperDev? As you’re adding new features, how are you getting feedback on the development internally? And are you doing any user testing, getting feedback from people that are actually creating applications in HyperDev? How do you manage that process?

Pirijan:

So for user testing, we went really hard on it initially, like when we weren’t sure, is this a product that people would be into, or what are some of the core workflows that people want. We should do more of it. It’s kind of like an issue, I think. But in terms of design review… Because I’m the only designer on the team, my role is to be as transparent as possible with experiments I’m trying or ideas I’m thinking. But we have other designers at Fog Creek, and we use this tool called Wake, and the idea with Wake is you just drag in screenshots, GIFs, napkin sketches of things that you’re sort of in progress working on. And so, the idea being that you can get feedback pretty early without having to necessarily have a design review meeting or a formal process. So that’s been great as this passive, like, “Here’s a way I can get continuous feedback while I’m working.” And every Monday, the design team at Fog Creek sort of gathers together and we also do something a little bit more formal, as well.

Daniel:

Yeah, we are a pretty small team and we have a lot of autonomy. If we’re kind of on the same page, then it moves forward. What I really take, and what informs my design decisions of how the product should behave and how it should work—we have a support forum where people who use the product can post anything, and I take anything that people say very seriously. Like, not necessarily if they have a feature suggestion, but if they have a problem, if they have a feeling, if they’re trying to do something that doesn’t work the way they think it should work… Those are the best data you can get, is how real people are using it, how they experience it. And they might not have the solution built into whatever they’re saying, but the truth of how your product works is in how people use it, so I take that information very seriously.

Pirijan:

Yeah, that’s a really good point. Some of the benefit that we used to get from bringing people into the office, we’ve been able to get that from sort of the community forum, like our users. Yeah, I guess that’s kind of taken the heat off of that. We’ve designed entire features around workflows that people have identified that they’ve really needed, and that’s been pretty cool because then you’re like, “Oh yeah, that totally makes sense. I didn’t think of that.”

Ethan:

In addition to this community feedback you’re looking at, how do you actually measure the success of this new responsive web application? What kind of metrics or data are you looking at to see if this new look is actually successful?

Daniel:

We have some Google Analytics that show various user interactions on the site, and that informs us a little bit. I think we’re still working on getting the most out of our metrics. I think it’s probably a never-ending challenge for everyone in the industry, is how do you get the right metrics? And so they inform us a little bit, but again, what people actually say, how people actually use it… If I can observe someone trying to solve a problem, like where they get stuck—that’s sort of the most valuable metric to me. But to tell like, oh, people have edited ten percent more files this week than last week—that’s not extremely actionable other than, “We broke something and it went down to zero because it doesn’t work anymore.”

Pirijan:

Yeah, I found working with HyperDev kind of interesting, because we get a lot of great feedback, like not just from the forum but people tweeting about it or whatever. To me, I like the idea of a product that’s either love or hate, and we haven’t gotten a lot of hate, surprisingly, actually. But the love we’ve gotten seems, yeah, pretty legit, so that’s been encouraging to me. Not an official metric, but still pretty cool.

Daniel:

“We got five percent more love this week than last week.” [laughs]

Pirijan:

The love rating!

Ethan:

[laughs] You always want that trending upwards and to the right, so it seems like you’re in a pretty good position. Well I’ve got to say, this has been a really great chat, and I can’t thank both of you enough. But before I let you go, if there’s somebody in our audience who’s reading this interview or listening to this interview, if they’re about to start on a responsive redesign or build a new responsive web app today, do you have any advice for them? One or two things you’ve learned working on HyperDev that you want to share with them?

Daniel:

I would say everything on the web is a lot of work, especially responsive web, so really think through your goals and what you’re trying to accomplish, because it’s an incredible amount of work to get something to actually work well for many people, across many devices, across many different goals as users. And so if you really understand what you’re trying to do, that will then inform all of the hundreds of small decisions you have to make that have to add up into a coherent project.

Pirijan:

So for me, the more and more I work as a designer or the longer I do designer-y things, what kind of stands out to me is copy matters more than anything else, it’s sort of like the base of the pyramid or the foundation of the house. If you start with really strong copy and you think through what do people need to see, when do they need to see it, and how you want to communicate with them, it means you can make a far simpler design, like the design doesn’t have to apologize for the content. When you can do that, usually a lot of user-friendly decisions fall off from that. So yeah, that’d be my recommendation, is to start from the copy and work your way up, as opposed to starting from a visual place.

Ethan:

Well now I’m doubly sad that Karen couldn’t be here. But I have to say, Pirijan, Daniel, this has been a really fantastic chat. I mean, HyperDev is already in a really impressive place and I can’t wait to see where it goes next. So, thanks so much for your time.

Pirijan:

Thanks, Ethan.

Daniel:

Yeah, thanks.

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.