Ryan Singer of 37signals

Ryan Singer of 37signals talks about Rails, design, and “touching the magic wand.”

From RailsConf at the Heroku booth.

Sponsor

Interviewed by Geoffrey Grosenbach

Transcript

It’s the Ruby on Rails Podcast. I’m Geoffrey Grosenbach. June 2, 2008, show number 77.

Been at Rails Conf for the last couple of days and recorded a number of great interviews there. Gonna be trying to drop these every couple of days over the next few weeks just to get those out there so you can enjoy those in a timely manner.

This one is Ryan Singer of 37signals.

The Ruby on Rails podcast is sponsored by Atlantic Dominion solutions, located at TechCFL.com. ADS is a web development innovator that specializes in building user-focused Rails applications and enhancing their performance with Amazon Web Services. ADS also provides 24/7 monitoring and management of EC2 deployments, as well as fully-managed hosting on virtual servers optimized for Rails applications.

Geoffrey Grosenbach: Alright so Rails Conf 2008 first interview right here; (I) have the privilege talking to Ryan Singer of 37signals. So what do you think of the conference so far?

Ryan Singer: “I think it’s awesome. This is the first time that I’ve ever been to Rails Conf, and the energy and the personality of the conference is totally different from the web conferences that I’m used to going to. It’s just, it’s really awesome. You can tell that everybody here is a crafts person; people here are really focused on making stuff and that’s awesome to be around.

Geoffrey: So what exactly do you do at 37signals? Seems like, I see your name on the blog post occasionally. But definitely other members are a little bit more visible. What do you do there?

Ryan: Which other members are you thinking of? (Laughs) I’m a designer. I actually came on board at 37 when we were still doing client work. Jason had this idea to do Basecamp. So, originally Jason, myself and David were putting Basecamp together and since then I’ve helped to design for the other apps and everything. The reason actually I’m here today is because since I got into doing design for Rails apps, I mean, I’ve fallen in love with Rails. I want other designers to learn about how they can start in the view, which is so close to HTML, and actually work their way down to the point where they’re holding the magic wand and they can start to build things and make changes themselves.

Geoffrey: I want to ask a little bit more about that, but, being at 37signals, everybody there is into design, into the user experience. Is it hard to work on apps where you’ve got so many opinionated people who have these great ideas? Does it feel like you’re just a committee sometimes?

Ryan: Uh, no, fortunately. Thank God, it doesn’t feel like a committee. Fortunately we have, even though we don’t really have titles and we all care about things, we don’t really have specific roles. But, there is a notion of how far away you are. Are you working closer to the infrastructure? Is your expertise something like database queries, you know what I mean? Or, are you really closer to the domain and thinking about the user’s problems and thinking about what our customers are doing and thinking about how the app should work?

There’s actually kind of a natural division where the work gets polarized sort of along this tower with the people working at the view and the domain knowledge on top, and people working with code and infrastructure below. Because we have this big thing about “screens first,” right? We’re really big about doing templates first before you do programming. That means that the people who are designing the templates have a bit of a priority when it comes to defining how the features should be and how the app should function, how it should behave. And then, of course, feedback is coming up all the time from all the programmers and everybody is giving feedback. But there’s sort of a natural structure. Are you someone who’s generally working closer to the view and thinking about that or are you working further down into the code?

Geoffrey: Now on Signal vs. Noise you’ve posted several paper sketches and even Photoshop mock-ups but it seems like pretty quickly you get right into there and actually do HTML for mocking up what it’s going to look like.

Ryan: Yeah, for sure. I think a lot of that has to do with the fact that we’re making apps instead of doing marketing sites or something like that, you know? I could imagine if we’re doing stuff that had to be really ritzy that you might be playing in Photoshop a lot more to make like artful curves and shapes and gradients and stuff like that. But really, 90 percent of my time as a designer goes into thinking “How can our apps solve our customer’s problems as best as they can?” So, from that standpoint, because I’ve been hand-coding for awhile and am comfortable with CSS, it makes a lot more sense for me to just dive straight into the code and start putting a structure together that puts the information on the screen that needs to be there and puts also the places for customers to put in the information that they need to provide.

I mean, it’s just, if you start with Photoshop, you can make everything pixel perfect and you can’t click on it. So it’s kind of a waste. For me, I’m anxious to see stuff that works. Doing HTML gives me a great chance to have something I can click on and something I can feel. The other thing that’s really great about doing HTML is that we get to get our domain language in from the beginning. So when I’m doing divs, I’m like doing a template and I have divs and stuff like that, I’m giving them class names. Those class names aren’t arbitrary; it’s not like blue box or red box. The class names are like “person.” And that maybe is inside of a class called “company.” So there’s actually domain language that’s getting defined and articulated in the process of laying out the screen because we have to start naming things right at the beginning.

Geoffrey: So it’s definitely focused from the beginning even as you’re writing code you’re still thinking about the user experience and what they’re going to be doing?

Ryan: Yeah.

Geoffrey: Do you distinguish between, you have graphic design, you have user interface design. You have user experience design. Is there a difference? Does it matter?

Ryan: There are so many different words for the same thing, right? It depends on if you get into the navel-gazing-title thing.

My job is to think clearly about people’s real-life problems and figure out how I can make a screen that presents information to them and accepts information from them in such a way that can help them out. That’s my job. And I don’t really know what you call that. There has to be graphic design in there because, for example, if you study Edward Tufte, color matters. Line-weight matters. All those different relationships have an effect on how information is presented and how easy it is to absorb.

Of course you want things to have some style and be artistic, so there’s that factor. At the same time, you’re making software so maybe you’re using this word, usability, which we don’t really use very much now. I mean, you just want to make it good. (Laughs). I mean, there are a lot of levels going on. Ultimately it’s just a question for me of, “I work at a shop on Rails and I’m making views.” That’s kind of like my territory.

Geoffrey: A little tangent here: talking about the interface, the graphic design (it) seems like for so many people recently it’s just, they center on a few different fonts.

Ryan: Oh sure.

Geoffrey: Hoefler Gotham. Everybody uses Gotham. If you do it, then that’s a good graphic design.

Ryan: You get the waves of graphic design and all of that, yeah. You see that on the code too. It’s not quite as easy to change code around, but it’s just a question of what’s popular. The hard part is always trying to concentrate on what’s important so that as the fads change, maybe we decide that we want to use a different typeface on our app or something like that, the underlying structure; which parts are easy to change and which parts are actually a fixed part of solving the problem? We really need to keep that distinction clear in mind. Because it’s totally cool to roll with trends and be stylish, but it shouldn’t interfere with concentrating on making software that really provides value. So we try to keep a clear distinction between “What are the things that need to be really solid and concrete like a foundation?” and “What are the things like paint color that we might be flexible to play with?”

Geoffrey: You said as a designer you’re starting at the view level, eventually you’re getting down to the “magic wand.” Do you feel like Rails provides a benefit to the designer?

Ryan: Oh, absolutely.

Geoffrey: Or is it more that it’s in the backend and it just makes things happen.

Ryan: Rails is a magical thing for a designer. What happens is, as a designer, if we’ve come at all from this sort of lineage of caring about standards and caring about separation of content in presentation, it is a minority of designers, but we have that culture.

If you’re part of that, you already have learned about software, architectural layers and stuff. If you think about HTML and CSS, they’re two different layers. You have different kinds of code in different files, and the only thing that ties them together is the fact you’re using the same word for a class in the HTML, and the same word for a selector in the CSS. That’s really no different from creating an instance variable in the controller, and referring to that exact same word in your view and being able to get access to some data that way.

Actually, designers who have familiarity with hand-coding and separation of content and presentation are extremely well-poised to look at the top end of the Rails stack and start moving down toward the code because it’s using basic abstractions that they’re already familiar with.

Geoffrey: You talked about getting down and touching the “magic wand.” What is the “magic wand” and why would designers want to get down into the nitty gritty of it?

Ryan: What happens with design is that you make a template and you’re all excited. “Oh, this template is really going to solve the problem and it’s beautiful.” When you’re doing that, you have half the information you need because the template is static and you can’t really click on it and get to the next template in a certain flow.

You aren’t seeing all different kinds of live data in it and all that. Half of the design is sort of hypothetical when you first design a template. And then that template gets plugged in by somebody who has the magical ability to write code so that div gets saved and it moves around and it gets processed and whatever. That’s the magic wand; being able to do controllers and models and databases and stuff like that.

After that gets plugged in by a developer, you look at that and you have suddenly all that information that used to be hypothetical. “What would it be like if I actually typed in a name here and then clicked save and went to this screen?” It becomes real information that you can act on.

So as a designer, now you get some feedback about what you did right and what you did wrong now that your template’s plugged in. You naturally want to use that feedback to make your app better, to make it as good as possible. Now I know more, and I can make my template even better based on this information.

But if you have to go through a whole bureaucratic cycle of creating a new mockup, reflecting the changes, explaining it to a developer, giving them your intentions, explaining the problems to them so they can go in there and make the code changes … If you have this big wall where you have to explain your change it takes away all of the magic out of that moment of having the perfect little thing that would make this better. And all of those individual, 10-minute, 20-minute changes where you’re like “Oh, this would be so much better if I could move this a little bit here and move this here and change this,” that gets hampered by the long distance relationship between the designer and the developer.

The designer is like the eyes that see, and the developer is like the legs that walk. If the eyes have to send a telegram to the legs to tell them where to go, there’s a sudden obstacle that’s not so nice what the result is. So having the designer being able to go into the code and make some changes for himself is putting some eyes into the legs and letting them move in concert.

Geoffrey: A lot of people would freak out about that. “What, I’m going to let my designer actually touch my executable code that’s going to affect this. But it seems like the line is a little bit more blurred when you have the power …

Ryan: It’s not your code. The code is a product. It’s a product for somebody else and it’s not yours.

If you’re going to be able to make better work by having those designers do their job inside the code alongside you, you’re going to be able to share a lot of knowledge that you didn’t even know you could share before, and you’re going to be able to make some awesome stuff together.

Geoffrey: Very inspiring. I have to ask at least one potentially controversial thing here. A big part of Rails that I really appreciated all along is this whole thing of rjs, you generate JavaScript, you can send it back …

Ryan: Oh yeah, it’s awesome.

Geoffrey: It’s seems like from the user experience, one ends up just seeing these spinning …

Ryan: Spinners all the time? (Laughs)

Geoffrey: … spinners of waiting a lot more. And if I use an app like facebook, for the majority, they’re going to just show you the result immediately and go hit the server. Whereas Rails is built around this thing of “OK, let’s go talk to the server and then we’ll tell you after it really happens successfully.”

Do you see that as a problem? I know some of your 37signals apps use rjs a lot and can do some amazing things. Does it cheapen the user experience?

Ryan: It’s hard to prioritize. For me, my life as somebody who’s working at 37signals is basically a two-mile long laundry list of things that I wished were better. And it’s a question of, “Where can we really put our energy to make the biggest difference?” I totally know what you’re talking about. But at the same time a lot of the places we’re using rjs right now, we’re getting a lot of benefit from the quick development and the app is doing what it needs to do for our user. When we use ajax, we use it pretty intentionally. What we want to do is we want to control change on the screen.

Generally the unit of change on a screen when you navigate is the browser window. And what we do with ajax, we want to reduce the unit of change to a div. So, if I’m adding a task in Highrise and what I want to see is, I have a list of tasks below my task form. I type in my task, I hit add, and then that task appears in the list. The only thing that should really be changing is that list because that’s what I’ve acted on.

So for us, it’s just a very practical matter of how rjs enables us to decide what our unit of change should be. There might be some aesthetic things where we can do better and I hope that we’re learning about that when we spend more time with that. But we have a lot of time to improve a lot of things.

Geoffrey: Great answer. One question about the future to finish up: Rails has definitely made life a lot easier for backend programmers and then front-end developers and people who are interested in the whole stack.

Do you see that there would be any benefit of, let’s see, a future web framework being built with both designers and developers right in there hand in hand trying to build it specifically around design, or maybe Rails is that already?

Ryan: Rails is that. We totally have that with Rails. As a designer if you come into the top end of Rails and you’re working with views, it’s very familiar territory. We’ve had things like, there’s been a lot of different projects out there (where) people are trying to replace html.erb or trying to replace just using plain CSS and getting variables in there and stuff like that. For me, none of them have worked because … well I don’t know why, it’s just that I keep finding that html.erb is really flexible and powerful and close to what I know as a designer. Being able to have CSS and JavaScript there, it’s just like working on a static site, but I have so much more power and I have all the power of Rails underneath me with that. So I can’t really imagine how I would want a framework to be different in order to have a better development as a designer.

Geoffrey: Well thanks for taking a few moments. It’s great to meet you and talk. Thanks a lot for the stuff you’re doing at 37signals. Definitely some great apps and of course we appreciate the framework as well.

Ryan: Yeah, thanks for your excellent questions.

Thanks also to Rails Machine for providing hosting and bandwidth to this show.