RWD Podcast Episode #31: Adam Luptak

Justin Avery: Hey everyone. Welcome to another edition of Responsive Design Weekly podcast. My name is Justin Avery and I’m your curator. Well no, your curator and your podcast host and the curator of Responsive Design Weekly, a weekly newsletter all about responsive design. This is edition number 31. It’s episode number 31.

I have another lovely guest. Before we get to our guest, I just wanted to say, give a shout out to Media Temple is our sponsor for this week. Media Temple, all about the hosting. They host the Responsive Design website. They host a whole bunch of different websites actually for me. I love them. I think they’re really good. The service that they have, the help desk, is super simple.
There’s always someone online to help you out.

This week, I was looking at, if you go into mediatemple.net/landing/grid, you can cruise in there and you can get $5 for the first month of grid hosting, if you use the coupon code GRID05, so GRID05 when you sign up for this. The grid hosting is awesome. It’s like a shared hosting thing so you can run your WordPress site off it. You can run any site off it really. You can host up
to about 100 websites on that. Get about a terabyte worth of monthly band width, SSD storage, a whole bunch of email accounts. It ramps up based on how much traffic you’re getting.

If you suddenly write some awesome blog that gets picked up on Reddit and you just get a ton of traffic, it will actually ramp up your site so that it will handle that traffic. You won’t go down. That’s kind of cool. Go and check out Media Temple. Thank you very much to those guys for sponsoring the podcast. We’ll move and actually do [00:02:00] the podcast. We’ll welcome along Adam
Luptak from Rally Interactive. Welcome, Adam.

Adam Luptak: Hi Justin.

Justin Avery: How are you doing?

Adam Luptak: I’m good.

Justin Avery: Excellent. Whereabouts are you dialing in from?

Adam Luptak: Salt Lake City, Utah in the USA.

Justin Avery: Nice. What’s Salt Lake City like?

Adam Luptak: Oh my. It’s kind of a strange place, honestly. We love it because we’re an office of guys who we love what we do and we love being able to do digital work. There’s enough of a community and a city to support that. It’s also a great place for doing things outdoors. There are guys in the office who are into skiing, snowboarding, mountain biking, running, fly fishing. From my house, it’s 15 minutes to drive into work and it’s 15 minutes to be up in the mountains.

Justin Avery: Perfect. That sounds like a great place. Is there a, this is showing my poor general knowledge, but is there an Olympic-based event held around Salt Lake City?

Adam Luptak: Yes. The Winter Olympics in, well this is me showing my … I believe it was 2004. I believe it was here. I’m pretty sure.

Justin Avery: Were you around then?

Adam Luptak: I actually was in Idaho then. That was my senior year of high school.

Justin Avery: Nice.

Adam Luptak: A young’un.

Justin Avery: Don’t say that. It makes me feel old.

Adam Luptak: Oh that’s really cool. For those that haven’t heard about [00:04:00] Rally, do you want to just give us a bit of background about who Rally is and what they do?

Justin Avery: Yeah. Absolutely. We are pretty small digital shop. We’re only a couple years old at this point. This is actually I’m going into my 3rd year with the company. They were around about a year before I joined up. So about 4 years old. We grew out of the digital advertising space. A couple of us had worked for different digital advertising shops or production shops that were doing this was coming directly out of the Flash microsite days.

We were a little sick of microsites and advertising in general. We really wanted to do great digital work. We wanted to be able to, push the boundaries is really cliché, but we wanted to experiment with things and prototype and figure out new stuff. We wanted to do some work that, to say work that matters is a little bit lofty, but things that were actually that somebody might use.

Adam Luptak: Yeah. That’s really cool. That’s a good ethos to have around the company.

Justin Avery: Yeah. I mean it’s something that we, it’s not always easy to achieve, but we’ve had a lot of luck with it in our few years being around. We’ve been really lucky to work with some really great [00:06:00] really great clients. We got to work with National Geographic pretty early.

Adam Luptak: That’s cool.

Justin Avery: That was a big part of honestly helping us get to where we are today.

Adam Luptak: That’s really cool. I love National Geographic. Its one of the only … I love their website. I’m going to ask you a lot about their website now. It’s one of the only print materials that I buy on a monthly basis. It’s just something nice about having a National Geographic to flick through.

Justin Avery: Oh yeah. It’s gorgeous work. To be clear, we didn’t do their website. We’ve done a couple IOS apps for them that we can get into if you’d like.

Adam Luptak: Yeah for sure. I like the … I’ll get to that. I’ll get to that stuff. I’ll ask-

Justin Avery: I guess I should say is a bit more background on our company, we like to say we’re technology agnostic in that we want to pick the best technology for the given project. We’ve done some web work, some Native mobile work. We like to say that we could do iPhone or Android or even Windows phone. The reality is, with economics and how the different ecosystems work, so far we’ve only done IOS work.

We haven’t done any of the … We haven’t done Android or Windows phone yet. We’re not opposed to that, even though we are, a lot of us are Apple people. We’re open to anything. It’s kind of about figuring out what’s going to reach [00:08:00] the most people, what’s going to be the best solution for the client and for the users of a given product.

Adam Luptak: Yeah, that’s what’s most important right, what’s best for the clients and their budgets and future things. Talking about being a technology agnostic, when you are building websites, do you favor any particular kind of technologies from a CMS point of view or do you just build on PHP or on Ruby or WordPress or Drupal or Embraco?

Justin Avery: We’re [Jungo 00:08:40] guys mostly partially because it’s what we all happen to know, all of the developers at the moment. We all have more background with Jungo than anything else. That said, we have some Ruby experience and some PHP from back in the day that we don’t like to talk about it. We like Jungo because it’s pretty quick for us to set up. Part of that is the nature of it and part of that is a familiarity with it.

We also really like how flexible it is. The Ruby community is great and I’m hopefully not going to upset people. They have a culture of conventions and conforming to conventions and using the same tool chain. That’s really efficient for some things. We really appreciate the Jungo ethos, which is here’s a set of tools for setting up your data base and your views and, beyond that, you
can configure anything. You can use any [00:10:00] tool chain you want. It doesn’t give you quite as much out of the box but we like it that way.

Adam Luptak: I’ll ask you a little bit more-

Justin Avery: That’s our back end system and then, in terms of front end web stuff, we’re kind of I don’t know about old school but we’re pretty strict HTML, JavaScript guys. We’ve dabbled in SAS and LAS a little bit. There are some nice things in it. There’s not a ton there and, at the end of the day, it’s compiling down into CSS. As far as JavaScript goes, we’re big fans of writing just pure JavaScript.

We don’t go in much for jQuery or we haven’t done anything that’s web app-y enough, if I can use that term, to really necessitate using something like Angular Backbone. I know there are people who think that you should use a framework like that, no matter what size the project. We feel like most of the time for us so far at least, it’s more overhead than we really want.

Adam Luptak: I heard another podcast recently with a guy from Ember.js. Have you seen Ember?

Justin Avery: I think so. Is that-

Adam Luptak: I’ll probably get shot for this as well but it’s like Angular. I think there’s this thing where Angular is going from version 1 to version 2 [00:12:00]. There’s this huge big re-write.

Justin Avery: Oh yeah, I’ve heard about that.

Adam Luptak: Because so many people have built these huge big web apps on Angular 1, it’s going to take them ages to write number 2, which means they’re not advancing the framework quick enough. Embers built a little bit better I suppose. Second to the party, you’ve already learned all of the issues.

I tried it out the other day. It just felt dirty, like all it was doing was it created an index to HTML page and then I just added script tags. It was just all very … It didn’t feel clean to just have all this JavaScript in the head and then no content on the page at all. All the content just gets pulled through an API and displayed using JavaScript, which is kind of what apps do.
It just didn’t feel right. There was something wrong with it.

Justin Avery: Yeah I mean there are some people out there who talk about progressive enhancement, the idea of structuring your pages so that if you’ve got your whole web stack and you take away JavaScript, it’s still going to function with HTML and CSS. If you take away the CSS, it’s still going to work as HTML.

In reality, sometimes that’s just not worth it. The fraction of people not using JavaScript is so low. It’s kind of pointless. It feels, from a computer science perspective, that separation of having your content in one place and your styling somewhere else, as much as you can keep those separate, it just [00:14:00] feels better. I’m with you there.

Adam Luptak: Yeah. I have this constant argument with a friend of mine, Daniel Simmons, about I’m a big proponent of SAS or a CSS pre-poster because it makes my life easier.

Justin Avery: Yeah.

Adam Luptak: I can’t see a situation where I would not want to use it, just because of the way I’ve now started writing my CSS. We always have this argument about, he’s like, “No you just write CSS. SAS produces bad CSS.” I’m like, “Well bad SAS authors create bad CSS.” It’s crap in, crap out. Then he has this progressive enhancement thing as well.

He had a really good point at one point where he was doing a train app, like a train ticket app. You had to choose from a list of 10,000 stations. It was you either loaded those 10,000 in as an option list, which then made the page really heavy, or you would let someone start typing it and then you would load in the bits that they needed. He’s like, “You can’t progressively enhance
that.”

Justin Avery: Yeah.

Adam Luptak: That’s just it. I was in complete agreement and then I sent something back and said, “Well couldn’t that just be a search form field where you type the name of the place that you wanted and you hit submit as the beginning part. Then you got a list of the matches back to choose from in an option list.” He’s just like, “Well that would take a lot longer than just doing this Ajax list” which is right. I suppose that’s the thing, right? How much time do you have on a project and have close to the natural progressive
enhancement do you want to stand?

Justin Avery: Yeah. Absolutely.

Adam Luptak: Anyway, rant over. [00:16:00] Before, like I say, I featured Rally Interactive’s site a couple weeks ago on the Responsive Design Weekly. I think it’s awesome. I think Ethan Marcotte tweeted about it saying that it looked super awesome. That’s how I picked it up and covered it as well. I want to ask you a bunch of questions about that.

Before we get onto what you’ve just recently done, let me go back to Adam in 2004, just graduating from high school, coming out. Had you done much web development before, like in high school? The web was something in 2004. I was definitely working in it for a few years by then. How did you fall into your current role at Rally?

Justin Avery: Oh man. It’s kind of a long story. I’ll try not to go too crazy deep into it. I had done a bit of web work before, even before high school. I think like a lot of kids my age grew up around computers and playing games, that sort of thing. I think I was around probably 12 when our ISP at the time, this is probably right before or right around Geocities, the explosion of that.

Our ISP gave you FTP space for one web page, one HTML file, which is about the most absurd limit. I’m not sure there was actually a file size space but you could have index.htm [00:18:00]. My older brother had his index.htm file, which was I think a Nine Inch Nails site for a few years and then decided he didn’t want to deal with it anymore. He taught me how to use it was Netscape
composer at the time.

Adam Luptak: Oh yeah.

Justin Avery: Yes. I built my first web page, font tags and all, the whole nine yards, animated gifs, as a fan site for a old Sierra game series from the late ’80’s, early ’90’s called-

Adam Luptak: Yeah, yeah, which …

Justin Avery: The Quest For Glory series.

Adam Luptak: I don’t think I even know the Quest For Glory.

Justin Avery: Yeah it was right around the same time as their Golden Age adventure games, your King’s Quest and your Space Quest and whatnot. The interesting thing about them was they were actually an adventure game role playing game hybrid.

In addition to having the adventure game, finding items to use in puzzles and whatnot, you also had character classes and stats and combat. I was obsessed with them growing up and loved them. There was also a heavy mythology component to them. Each of the games is rooted in a particular area’s mythology. I learned, without realizing it, a good deal about different mythologies growing
up with those games. That was my [00:20:00] basis of getting into building a website.

That grew over time into I swam competitively growing up and, for a little bit, I built a website for my local swim team. I didn’t really think about it as a career option, strangely enough. I don’t know why it never occurred to me but it just didn’t. It was something that I enjoyed doing but didn’t think about doing for the rest of my life. Then, when I was in high school, looking
at colleges, I didn’t know what I wanted to do, thought maybe I wanted to get into filmmaking or who knew?

Was looking at schools all over the United States and ended up finding a school in Rochester, New York, Rochester Institute of Technology that was actually near where I was born, was part of the reason why I was poking around that area. They had a program that ended up catching my interest called New Media Design and Imaging. I think New Media is kind of a dated terms at this point but,
at that time, it was a program that was just looking at a lot of different disciplines in the digital area, websites and programming.

They were doing a lot of Flash work with animation. They were doing 3-D modeling and animation web design, just this big smorgasbord of skills that just seemed really interesting [00:22:00] and fascinating to me. That’s what I ended up going to college to do and spent four years at RIT learning in a design program. I have a Bachelor’s of Fine Arts, which is absurd. Came out with a really
broad skill set.

That I think has served me really well because coming out of school, between my junior and senior years of college, I got an internship at a little, to call it a digital production shop is probably reductive, but it’s a little shop that was based out of, at the time, purely out of Salt Lake City, called Struck. Struck Creative. I interned there and then went to work for them full-time
after I got out, which was great. Like I said, this was the Flash microsite days.

At the beginning of my career, we were doing a lot of that. We were getting jobs from the bigger, more established agencies, Butler Shine and goodness, the names are escaping me now, Goodby, [Pra-or 00:23:49] O’Dell, just a bunch of things. The digital team at Struck were also there’s a print team there and a traditional advertising team [00:24:00]. Was there for a couple years. I
was only there for about a year because I was hired as a designer, who had animation skills and this broad skill set but could also program a little bit.

I wasn’t there for that long before I started saying, “You know what? I’m okay at this design thing but these people I’m working with are way better than me, partially because they’ve been doing it longer but also they have a little more natural aptitude than I do. I could beat my head against the wall. I’m also pretty good at this programming thing naturally.” I’d had some exposure to
it in school. We’d been doing a lot of action script.

I kind of fell into it and quickly discovered that was the most effective way for me to contribute to the team. I also found out pretty quick that I loved building a thing and then having it work and being able to play with it. There’s that danger in any project where you finish one thing that feels really nice. It’s a rollover effect or something and you just want to sit and play
with it for hours. Yeah, I was at Struck for a couple years and learned a lot there.

Then I eventually moved on from there to Rally. They had been around for … The company was founded by 3 guys, Wes, Ben, and Thomas [00:26:00]. They’d been around for about a year and had been pulling in freelance help when they needed it here or there. They had just been out to Washington, DC to pitch for a National Geographic project. They had landed it as a 3-person company.

Adam Luptak: Nice.

Justin Avery: They decided that maybe they needed a little help. I had worked with Wes and Thomas before in the past. They had both been at Struck at one point. We ended up having some meetings and we all got along great. We knew that we had from the past. I jumped over then and I’ve been here ever since.

Adam Luptak: When you started working on the … You were saying the National Geographic thing was an IOS-related thing. Does that mean you’ve been designing it or building coding in IOS or are you-

Justin Avery: Yes.

Adam Luptak: Yeah? As well?

Justin Avery: Yup. Honestly, it’s part of I think maybe it’s from our heritage, if you will, as people coming from the advertising digital world. So far, all of the developers here, we’re guys who are used to having to roll in a bunch of different technologies and pick different things up. I mean some of the guys started out in HTML and more basic web technologies in a more professional sense. I suppose I did too but I’m not really counting my experience when I was younger.

I feel like I really started programming in Flash. Over the years, we’ve just learned to pick different things up. I feel like [00:28:00] your first language is hard and intimidating. Your second language is pretty hard an intimidating because you already know one thing and you’re afraid to pick up a new thing. After that, I feel like it gets pretty easy. You start to develop as
a programmer and understand how systems work. So you start getting much better at jumping from platform to platform.

There are idiosyncrasies to everything and different stuff, but a lot of stuff is just syntax and figuring out how to accomplish the same sort of things that you used to and solve the same problems but with different tools or different syntax.

Adam Luptak: Having a background in IOS and developing this IOS app for National Geographic, this is about 3 years ago did you say?

Justin Avery: Yeah.

Adam Luptak: Going back to 2012. As the web has evolved to what it is today, if you were to go back, what’s your thoughts on developing something specifically for IOS [verse 00:29:24] building it as a mobile first website and putting it in a wrapper for discoverability rather than the interactions? Do you think that the web is ready to take that step up or is there still some lag behind that you need to develop an IOS?

Justin Avery: I think there’s still some lag definitely. It’s definitely getting closer than it was. I’m not sure, from my perspective, I’m not sure [00:30:00] that web technology is ever going to be quite as good as Native. We may get to the point with the technology, as it gets more powerful where it doesn’t matter. It’s there’s the joke about Microsoft Word that after how every many years they’ve been building it that, at the end of the day, you’re putting text into a document and the boot time for it hasn’t gotten faster.
It’s gotten slower. It’s because we take for granted the amount of processing power we have available to us and fritter it away now because we can.

Adam Luptak: Yeah.

Justin Avery: Certainly even in the time we’ve been building IOS apps, the devices have gotten a lot more powerful. You can get away with things that you couldn’t before. Those first IOS apps, particularly the ones Apple made before the SDK was opened up, those things had to be optimized to within an inch of their lives because the device just wasn’t that powerful. They’ve come a long way but they’re still just a lot of [cruft 00:31:28] in the web stack. Some of that is by design. There’s some weirdness, JavaScript behaves
in some strange ways, which can be useful to you sometimes but sometimes it’s just weird.

Adam Luptak: That’s the hardest thing, right? You develop with IOS. You know the platform that you’re running on. You know how it’s going to behave. When you do a website, you don’t know what JavaScript whether the engine’s going to be running it [00:32:00]. There’s so many other unknown variables I suppose.

Justin Avery: Yeah that’s one of the big things. There are just so many variables with web work. There are things like when you tap on, I was just discussing this one with Anton, one of my other colleagues here. When you tap on a link in a mobile browser, it needs to wait for a second before it does anything because it needs to see if you’re performing a double tap because that does something different to repress and hold. Whereas in a Native app, you can tell it, “All we care about is taps.”

You can react immediately where if you start trying to get in the way of that stuff on the web, you run the risk of making the experience feel weird and broken because it’s not working how people expect it to because it’s a website. There’s cruft there. You’ve got garbage collection that you have to worry about that we’re fortunate to not have to stress about in IOS. We have other
memory management things to concern ourselves with.

It’s just a different thing that the web is really astounding how far it’s come in the last, really kind of the last five years honestly, as far as all of the different things we can do with it now. It is still just a slightly different platform. I’m not sure if the performance is really ever going to be the same. Maybe I’m wrong.

Adam Luptak: Only time [00:34:00] will tell. I agree with you. The last five years it seems … I don’t know if you’ve felt this as well but I used to consider myself to be reasonably competent with building websites. Over the last five years, I feel less competent because there aren’t just website builders now. There’s just front end guys and just people that work purely on CSS. There’s just JavaScript developers. There’s just performance engineers that just look at a website’s performance and that’s their one role.

Everything is very, compartmentalized maybe is the wrong word but there’s so much involved with the web these days that there are becoming these fractions of jobs and people getting very, very good at very specific things instead of being generalists.

Justin Avery: Yeah. Absolutely. That’s something that we’ve talked about. When we’re starting to grow, finding generalists is harder these days. It seems like everybody’s specializing and we’re saying, “Are we big enough yet to take on generalists?” That’s the struggle of being a company that bounces from technology to technology. We don’t always have a web project going or always have an IOS project.

Adam Luptak: Yeah it’s tough. One project that you have had recently has been your website itself.

Justin Avery: Yeah.

Adam Luptak: Well done that. That’s awesome.

Justin Avery: Thank you. We really appreciate the feature. There’s been a lot of attention around it and it’s been quite flattering.

Adam Luptak: Did you guys internally approach this in the same way that you would approach a client’s project?

Justin Avery: Kind of. I mean there’s [00:36:00] they say that building your own site as an agency is the hardest thing that you’re ever going to do. That’s certainly true in our experience. It’s a tricky one. Part of it we’re perfectionists maybe. We care a lot about getting the details right on everything we do but there’s extra pressure when you’re doing it for yourself.

Adam Luptak: You’re baring your soul kind of thing right?

Justin Avery: Yeah.

Adam Luptak: You can’t then go, “Well this is what the client wanted.” It’s like, “This is honestly what we think ourselves is the best possible thing for our business.” Because if you miss the mark and someone looks at it, they’ll be like, “Well I’m not going to get you to build my site. You can’t even get your own stuff right.”

Justin Avery: Yeah. Absolutely.

Adam Luptak: Huge pressure.

Justin Avery: Yeah. It’s been a long process. Honestly it’s the longest process that we’ve had on a single project so far. Some of that is due to the reality of doing work for clients. We don’t have the money to just endlessly do our own thing. There have been times that we’ve been working on the site that we’ve had to put it on the back burner a bit. The process of building it lasted at least around 2 years from the first time I saw any designs.

Adam Luptak: Oh wow.

Justin Avery: Yeah it’s been-

Adam Luptak: Before you even got to the design phase though, was there a reason behind [00:38:00] the redesign? The 3 guys that founded the Rally Interactive, was there business reasons behind it? Were there business reasons behind it?

Justin Avery: Yeah. Some of that goes back to the formation of the company. When they started it, obviously you’re a company in the digital space. You need a website so that people can find you. There was a lot of discussion about what the website could be. Obviously the 3 guys that started the website, as Thomas was the business guy and Wes was the developer and Ben was the designer. They had all the skills they needed. They could have just built a studio website, a pretty standard studio thing. They talked about different
options.

There was some discussion about more whimsical prototype ideas. Wes was playing with a site that was just a huge Facebook like button that was comprised of small Facebook like buttons. I think they ended up figuring out they could technically do it, but it violated the heck out of Facebook’s [crosstalk 00:39:25]. So ended up not doing that. What they wound up doing, which was really,
as far as I understand it not intended to live that long, was a quick little site with a little information about the guys and what they were about.

Then Dribbble, the website Dribbble, was … I’m sure I’m going to be wrong about this. I want to say it was pretty new at that point. Ben [00:40:00] had been using it a lot as a tool for sharing process and getting feedback so thought we’re a brand new shop. We don’t really have any work yet to speak of so let’s just show off our process. They came up with a way of showing Dribbble
shots and came up with a pretty cool way of doing it, these little triangles that were actually a canvas element with JavaScript. It’s a little triangle element that when you hovered over it, it rotated, and when you clicked on it, it spun around and turned into a circle. It’s actually still, as
we record this, up at rallyinteractive.com.

Adam Luptak: It shows you how many likes and views and feedback and you can view this shot on Dribbble from there?

Justin Avery: Yup. That concept still exists in a modified and updated way. At the bottom of our Rally site, each of the case studies actually has Dribbble shots from that particular project. They came up with the solution to show that off. It was great. Actually, over the years as this site has lasted probably longer than it was ever really intended to, people still talk about it and seem to really enjoy it. Ben and I were actually at a Google through a design conference last fall in San Francisco that we were lucky enough
to snag some invites to.

Having conversations with people, I had more than one conversation where I told somebody that I was from Rally Interactive. They’d think for a second and say, “Oh yeah. You guys have [00:42:00] the website where the triangles turn into circles.” I was like, “Right. About that, we’re working on a new website.” That site did really well for particularly within the design community
because Dribbble has become such a big thing and people love it. A, it started to feel kind of dated to us and the company has grown. It’s not just 3 guys anymore.

Part of the problem was we’d get all of these business inquiries from people who think that it’s just 3 guys or just 1 guy because they don’t read very carefully or they think we’re only a design shop. There was a real impetus behind doing, in our new site, we really wanted to do something that communicated really who we are and that we care about doing the whole thing. We found that
because we’ve done some design-only projects and when we do design and hand it off, we have no control over the end product. Almost invariably, it’s not quite as good as we would like it to be. We always nitpick our own stuff too but we like being able to take projects from the beginning to end.

That’s really important for us to be able to A, get the level of polish that we want out of a project and also there are a lot of things that it’s hard to account for in the design process. By keeping development in-house, when we run into a problem, which we invariably do [00:44:00], one of the developers will go over and bug one of the designers and say “Oh hey, this thing doesn’t
work or doesn’t make sense” or we haven’t thought about this and how are we going to fix this? It’s maybe not the most efficient process time-wise but it’s how we like to work because we feel like it gives us the best product at the end.

Adam Luptak: The product that you have at the end is second to none. It’s awesome. Like the [Beater 00:44:29] is something else. It’s quite cool. Should we have a … When you went through, did you get designs handed to you?

Justin Avery: Yeah. Yeah.

Adam Luptak: The site itself, I suppose it would be interesting to hear how you guys work with interactions. Some of the things I quite enjoy about the site is that when you first get there, there’s this ribbon, like paper folded up across the page, which then moves across and then, at least on the desktop, you’ve got this diamonds which says one of four with arrows going left and right.

As you hover across that, if you hover on the right, then the diamond changes perspective and almost leans, pushes across to the right and everything comes off the page a little bit to indicate you need to click. Same thing with the other way. Those interactions, how are they communicated from design across to development?

Justin Avery: It’s a lot of … It varies from project-to-project. In this one particularly it was just a lot of communication from the designers to the developers. We, particularly in some of our IOS apps, will often prototype things either in Aftereffects or [00:46:00] more recently in tools like Quartz. For the site, we ended up just having a lot of conversations about design elements and how we’d like them to animate and move.

I’m pretty sure, for instance, the diamond element in the comps, even back to some of the earliest ones, that the diamond was just there as a UI element to communicate where you were and how many options you were. Like you mentioned, it’s an element that goes away at certain screen sizes just for screen real estate reasons.

The actual tilt was just an element of a designer throwing something out and trying it in development and back and forth of figuring out how far to tilt, how much to do the alpha to get it to feel right. As for the ribbon, the ribbon is kind of a funny story. The ribbon is kind of my baby.

Adam Luptak: Before you enter the ribbon, just a really quick on. On the diamond and the tilt, is a lot of this stuff you’re doing here do you just fall back to using JavaScript for the interactions or do you try and use the CSS 3 animation things as well?

Justin Avery: It’s actually that’s a funny story because our first impulse is always to use the CSS transitions because what we’ve found is most of the time, 90 percent of the time, you want to use those because on your weaker devices, your iPhones and tablets and whatnot, they’re actually really well optimized to put those animations on the GPU [00:48:00] and you tend to get much smoother animations there. What we ran into on this site was that because of the specifics of the ribbon, which I’ll get into in a second, it had
to be a JavaScript run loop.

We were discovering that by having that running and CSS transitions running on top of it, the weaker devices, when push came to shove, would just completely cannibalize the JavaScript run loop in order to make the GPU animation work, which meant that we got a beautiful, smooth CSS animation while, behind it, the entire canvas element shuddered down to 10 frames a second, if that.
It just looked terrible.

We ended up having to, in that top portion of the site, when that JavaScript run loop is active, everything’s powered off of JavaScript. Then when you move down into the body of the site and we can turn that run loop off, everything switches over to CSS.

Adam Luptak: That’s a great, great solution.

Justin Avery: Thank you. A lot of what we do, it’s i don’t feel like none of us are geniuses. We don’t really understand how browsers work. We’re not incredibly technical guys. We have just done enough experimentation. We only know that because we tried about 8 different combinations of getting things to work and just discovered over and over that the second we took out all of the CSS transitions, all of a sudden the JavaScript [00:50:00] ran great. It’s a lot of it is trial and error. That’s the sort of thing that, in a lot
of cases, there probably isn’t time to do. Because it was our site and we were committed to getting it right, we took the time for it.

Adam Luptak: I just love that. I’ve just been sitting here going back and forth between the transitions of having that header and the ribbon running across and when you go down to the content below it. This is the worst thing about doing a podcast like this is that no one can see what we’re talking about. Everybody should just go check out Rally Interactive. Just that interaction of the ribbon then becoming the header bar, where you have the navigation stuff as well, there’s lots of very small things around the site.

One of the things I noticed is it feels like you were talking about running with something like Angular or whatever else there is, the one page web app kind of things which more and more people are doing these days. This site feels like a one page web app because there’s no you don’t get this loading. The perceived performance is exceptionally fast. I don’t feel as though I’m waiting
for a page to load. As I click through the navigation stuff, I go for the home page and move through the different pages, so to speak. You’ve got the city guides, the snow bird, and then the national parks, which is the National Geographic work that you did. They’re all different URL’s.

Justin Avery: Yup.

Adam Luptak: It feels like a single page app. How are you magically [00:52:00] making that occur?

Justin Avery: It’s magic, Justin. No. I mean honestly what we’re doing is another thing that evolved over the process. The reason it feels like there’s not a load is because there isn’t. We’re cheating. What we’re doing is each, and this is another thing that we love about Jungo. We have our views set up such that when you hit any of those URL’s, you get the HTML you asked for. You get that page and obviously the style sheets in JavaScript and all that stuff.

For instance, if you save it into a reader like Pocket or Instapaper or any of those, it does actually more or less work correctly. Immediately after that loads, we’re going ahead and doing a second Ajax request to a separate URL we have set up that basically says, “I’m on this page. Give me the rest of the pages in a JSON object.

The beauty of that is in terms of memory footprint HTML is just text and text is small. We can just get the rest of the mark up for the site and just hang onto it. At that point, we essentially have the mark up for the entire site sitting in an array so we can just populate a page to each side whenever we need it.

Adam Luptak: If I’m on the home page, do you get the page to the left and [00:54:00] to the right of that or do you just-

Justin Avery: You get all of them.

Adam Luptak: All of them down.

Justin Avery: Yup.

Adam Luptak: Any problems with the storage limits across different devices, different browsers?

Justin Avery: Oh you wouldn’t believe. I mean actually not with that particular request but the big problem we ran into, because I’m sure you noticed, and people who go to the site will notice, the case studies are enormous. They’re super long, just not even bordering on too long didn’t read. You need an attention span for these things. That was kind of on purpose.

Adam Luptak: I think thorough is the word.

Justin Avery: Yeah thorough. I say that. I wrote the first drafts for all of these. I’m criticizing myself. It was on purpose because again we wanted to really take the chance to tell our story, talk about all of the ups and downs we have with projects, struggles, things about our process. I really wanted to write case studies that would be interesting and instructive for different kinds of people. I feel like so many case studies that you see are really marketing speak. They look great and they have beautiful images and
you read them and you say, “Oh well I just learned nothing.”

We really wanted to craft these in a way that if you’re a designer, you can read these and maybe you won’t understand all of the technical details, but you understand the process, how we got there and our design solution. If you’re a developer, you’ll understand these technical things and you’ll get a window into [00:56:00] how our designers think, which maybe is different than how
you think or how the people you work with think. We’re hoping that will be useful to different groups of people. I’ve gone off on a huge tangent but that’s all to say these pages are really, really long.

The problem we ran into was no so much the length but because they’re long and because we want to illustrate things as we go along, there are a lot of images. We found pretty quickly that on devices that are a little old at this point but not even that old, the iPhone 4S, the iPad 3, if you load that many images up, the device will crash. Safari will crash. It will run out of memory
and just go. We actually had to be a bit trickier with loading images as they came on-screen and unloading them when they go off so not everything is sitting in memory.

Adam Luptak: Yeah I noticed that. I’ve just been scrolling up and down the city guides. There’s some great things there. The device Chrome is loaded in. I assume that’s almost like a very small PGN or SVG. All the images load in as you reach there. If you scroll through quickly and don’t hang around … If I scroll past a section where you would normally load in a bunch of images, it’s not like it just loads them in there. Right? You’re waiting for someone to hang on that spot for a second before you’re loading it in?

Justin Avery: Yeah.

Adam Luptak: I would have thought though that once it’s loaded in, is it no being cached [00:58:00] and therefore you don’t have to unload it? You’re saying that unloading it helps for memory on older devices?

Justin Avery: It seems like unloading them helps. This is a place where I have to confess a bit of ignorance. We’re not sure. We definitely couldn’t load them all in at once. I don’t think we can have all of the images for all of … Because if I remember right, and this is getting into pieces of the site that I didn’t build. Obviously something of this size and complexity takes a team. I didn’t touch some of these pieces.

I think the HTML, once it gets loaded in, actually gets created in the DOM and left there but is just hidden when you don’t need it because there’s a hit on the processor when you render things into the DOM. That can cause animations to hitch. We wanted to hide that. We definitely need to, when we went from case study to case study, we would need to unload everything in the case study
left.

We just, for now at least, came up with a compromise where whenever you scroll everything on screen or a screen in either direction should load up and everything else should not be loaded. It seems to, so far, be working out okay.

Adam Luptak: Yeah, it looks super smooth. One of the funny things is when I had the banner going through for a while, the ribbon. It does spin the fan a little.

Justin Avery: Yeah.

Adam Luptak: Mind you, I’m one of those people that have 7 [01:00:00] versions of, or 7 different Chrome browsers open each with an unreadable number of tabs in each browser. I’m not saying that it’s specific just to the site but if you’ve got 78 or more windows open and you leave it on the ribbon, it’s-

Justin Avery: Oh absolutely.

Adam Luptak: -it will spin a bit. With the images and stuff, do you guys have a particular responsive image go to approach? Yeah? I’ll leave that open.

Justin Avery: Yeah. I mean our approach such that it is, I think this applies more generally to all sorts of responsive things. We don’t feel like there’s really any great magic bullet solutions to any of this. We don’t have any magic wands for anything, which is partially why the site took so long is because this stuff is hard, especially when you’re doing something that doesn’t … A lot of responsive sites can tend to look the same. I’m not sure that’s a failure of imagination so much as there is definitely easier ways
to build responsive sites than others.

I think some of the [stops 01:01:31] that we see a lot in responsive sites happen to be the things that are actually more efficient to build. Back to the images specifically, we just started off very simply. A mentor of mine back in the day used to say, “Optimize later.” We just started off with the biggest images [01:02:00] that we had, our retina size images, and we started with
those. Then we sized the containing DIVs.

My co-worker, well actually both of my co-workers, Anton and Wes, are CSS geniuses, they’re way better than me at it, came up with a system for keeping the device Chromes. I believe those are CSS backgrounds. It’s a container system where that background is there and the whole thing can be sized down. It keeps its aspect ratio and sizes down the image inside it properly. The whole system
just works. Of course a lot of these images, if we’ve got the full retina screen shot, particularly God forbid it’s an iPad or desktop retina screen shot, way too big for a phone.

You don’t need three quarters of those pixels. We started as part of our memory woes also saying, “You know what? We could also have smaller versions of these.” We do have, it’s actually built into the same system I believe that does the image loading. As you scroll, it’s also doing a check. We’ve got some defined break points. It’s saying if the width is smaller than 768 and the
image attribute, because how those work, those image tags that we do the loading with. They’ve just got a very small, and I’m blanking the word for it. It’s a way of encoding images into [01:04:00] text.

Adam Luptak: Of the Data URI?

Justin Avery: Yeah. We’ve got the source in there are just basically a transparent gif.

Adam Luptak: Yup. One pixel by one pixel gif that’s encoded in that way. Then it has additional attributes since HTML 5 allows us to do that and just put whatever we want in there legally. You can get away with it before then but they updated the spec so that we were legally allowed to do what everyone was doing anyways. We’ve just got a URL in there for what the actual image is so we can swap that in.

Justin Avery: Whenever it comes in the view.

Adam Luptak: Whenever it comes into screen. Obviously it’s a little trickier than that because of the CSS transitions, but that’s the basic concept. Additionally, we can just have an additional property on there, which is a 768 image, for screen sizes smaller than 768. It just kind of makes that switch at run time and says, “Oh you’re on a smaller screen. Get this asset instead.”

Justin Avery: That’s very cool. Like I said, it is a really lovely site. It’s just a joy to scroll through. It’s working well. You shouldn’t take too much longer before you push this to the www.

Adam Luptak: Yeah, we’re hoping to do that soon. Honestly, this week we’re working on there are still a couple small issues. We are very focused on WebKit browsers [01:06:00]. There is at this moment and maybe will be fixed within a few hours a Firefox bug that prevents the menu from closing. We haven’t really tested that much on Internet Explorer recently. We’re mostly hoping to just knock out some bugs and do a couple tiny visual polish things before we push it.

Justin Avery: I’m just now quickly loading it up in Opera mini.

Adam Luptak: Oh dear. Oh dear. I am afraid.

Justin Avery: It’ll be fine.

Adam Luptak: I’m afraid.

Justin Avery: I’m sure it will be fine. While I’m typing this into Google mini, Opera mini, the workflow, a little about the design, a little about the front end stuff. Are there specific workflows that you approach from a technical point of view? I’m thinking more of the listeners out there might be using Grunt or Gulp and they might have particular workflow processes of pushing things and working in teams. Do you guys have a set way of working?

Adam Luptak: We don’t really, except for it’s a horrible cliché to say that our process is that we have no process. That may be something that changes as we get bigger. I’ve worked in teams before that had slightly more defined processes. I’ve seen it work and I’ve seen it not work. I’ve dabbled in some Agile methodologies. I see value in some of that. Honestly, so far our process is mostly sit everybody in the same space and make them talk to each other [01:08:00]. We’ve got one shared space that we sit in and the designers ideally,
this breaks down sometimes when people are stuck on other projects and everybody’s jammed up.

Ideally we’ve got designers working on a project and developers, either they call us over or we’re nosy and we go butt our heads in and weigh in. Then when we start building the thing, whether design is done or not, design they’re poking their heads in and seeing things and giving us feedback. Oftentimes the end of a project, particularly IOS projects, we’ll have a big polish push
at the end where we I think we’ve made a name for ourselves a little bit with some of our animations on IOS.

Ben particularly is really picky about easing on animations and he’ll sit over the shoulder of whichever developer has the longest fuse left at that point and kibbutz the easing on an animation for hours sometimes to get them right.

Justin Avery: It does seem to show.

Adam Luptak: Thank you. The site has been an interesting … It’s both emblematic of that process and also it’s been a little bit strange. Like I said, it’s such a long process.

Justin Avery: Two years.

Adam Luptak: Yeah. The original designer, as far as I know, the first designer to start on it [01:10:00] doesn’t work with us anymore, has since moved on to a different gig.

Justin Avery: Hopefully not because of that.

Adam Luptak: No. I don’t think so. In the original comp, that ribbon element you were talking about was just a nice design element, a little bit of visual flair, this little interesting ribbon up there. It really just existed to give you a little bit of sense that there was the notion of having the website exist in this horizontal plane, where you could move left and right. That existed from the beginning. The ribbon was just there to suggest a little movement and be a fun little thing. We played a little bit with web GL
solutions but weren’t real happy with the effects we were getting there so came up with a Canvas solution to do it and had a very rudimentary system for drawing the ribbon kind of how it looks now.

It didn’t have as much movement to it. When you moved left and right, it didn’t actually straighten out how it does now, it actually flexes out a little bit. Instead it started moving faster and, as we created new segments, they just got straighter and straighter. Then as it slowed down, they went back because that was an easier thing to build and weren’t totally happy with it but
it was fine. We got busy with client projects. It got put on the back burner. Other designers got moved onto the project.

One day, one of the designers [01:12:00] calls me over to his desk and says, “We had this idea” which is always a scary moment. He said, “We have this idea because the ribbon up here is really cool and when we move down into the site, we’ve got this sticky nav that we’re header bar that we’re sticking at the top. They’re the same color but it feels disconnected. It doesn’t really
feel the same. Is there any way we could straighten the ribbon out and turn it into that nav?” I had a moment of saying, “I don’t know. Yes, I think. It’s going to take some doing.”

We worked it out and it was okay because I wasn’t really happy with how the ribbon was functioning anyways. It was that extra kick in the pants to say, “Okay go back to the math. Figure out how to actually straighten this thing out and relax it back into its folded-up state programmatically so that we can do that and then do …” It’s from Raiders of the Lost Ark, the Indiana Jones bag of
sand thing where we animate that ribbon up until it’s straight and then immediately swap it out with a HTML element that just happens to be sized the same, the same color. It’s just a seamless hand off.

Justin Avery: Except you don’t have a giant boulder then chasing you down a thin alley.

Adam Luptak: You weren’t here for the development process, Justin. You don’t know.

Justin Avery: It probably was. Look, good news too. I did fire up, now albeit I fired up your site on an iPhone 5 [01:14:00] but with Opera mini and it works. The animation is there as well. The ribbon goes through. It looks good. It scrolls well. I’m on Opera Turbo, whatever that means. I’ve got savings enabled so I saved 7 out of 11 megabytes.

Adam Luptak: I’ll be.

Justin Avery: Yeah so there you go. I don’t know what that means but it all seems to work fine.

Adam Luptak: It means we’re really quite good, Justin.

Justin Avery: Win, win for you.

Adam Luptak: Wow, I’m surprised.

Justin Avery: No, that’s really cool.

Adam Luptak: Hopefully very soon. Trust me, we want to get it launched. We A, want the monkey off our backs. It’s gotten a lot of attention on Twitter and Dribbble. Ben’s been publicizing it. We’ve gotten a lot of great attention. Ultimately our goal with the site, we want all kinds of people to see it.

We want designers to see it. We want developers to see it. We want businesses that might want to work with us to see it. We’re hoping that not all of them understood Dribbble necessarily and maybe didn’t quite get what we were doing with our old site. Hopefully the case studies at least, if we don’t scare them off with the crazy ribbon, will communicate who we are and what we like
to do.

Justin Avery: No it is. It is a good advertisement of what you can provide anyway. Well I think it does. I want to ask you. I’ve got a couple of questions which people have sent through. One that I wanted to ask before we go onto those, and I know that I’ve enjoyed talking to you so much that I’ve lost track of time. We’ve actually gone on for quite a while [01:16:00]. Is there anything you would like to see these days? This is just generic.

Anything that you would like to see these days on, and I was going to say responsive sites, but just websites in general? Are there things that people aren’t taking advantage of that you think they can do?

Adam Luptak: Oh let’s see. I mean there’s still it’s hard because as a person who’s built responsive sites, responsive work isn’t easy. We know that and we’ve taken different approaches to different things over time. If people, I won’t get into it, but if people read the case study about the Snow Bird site, they’ll see we took a very different approach to that site than we did our own site. It’s a difficult challenge to make things run as well on a desktop as well as it does on a phone or the other way around usually.

If people take advantage of the modern CSS tools, where they work best. There’s a lot you can do and the devices are getting better every day. It’s great to see sites get better and better at that because you don’t want … You want the experience to be correct for what the user’s coming to. I feel like I think it’s going away. I hope it’s going away.

I feel like when responsive web design became a thing [01:18:00], there was people in the design community got excited about it. You’d get a responsive site and you’d re-size your browser and watch things animate around the screen. It’s like “Whee, isn’t this cool? No one uses the web like that. Why are we doing that?” It’s about providing the right experience for where the user is.
Making sure you do that.

A personal pet peeve of mine is I despise when, because I see this all the time because of Twitter. Somebody shares a story from a news site and they haven’t updated their site in however many years. Suddenly I’m looking at M.dot whatever dot com and I’m looking at the browser layout across my desktop screen. I’m saying, “There is no purpose for this.”

Not to be pedantic but URL stands for Uniform Resource Locator. It’s a place to get at content. I expect that content to be the same wherever I look at it. I don’t expect it to look the same. It should look appropriate to what I’m looking at it on.

Justin Avery: Very true.

Adam Luptak: I think a lot of people are getting much better at that, better every year. I hope that people continue to get better at it and just pay attention to serving the users the best thing for where they are.

Justin Avery: Hear, hear. Well said. I’d cheers you if I had something to cheers you with.

Adam Luptak: I’m raising my water bottle to you [01:20:00] sir.

Justin Avery: That’s very true. I like the. The other thing that annoys me is when you click on a desktop link on a mobile and it takes you to the M.dot site, but not the M.dot site with the article, just the home page.

Adam Luptak: Oh yeah.

Justin Avery: That’s the worst. I know what you’re after but here’s the mobile site and home page in case you were looking for something else.

Adam Luptak: Yeah and that’s the trick. It’s a hard solution and it takes thinking about it. You should, no matter how you’re doing your site, whether you’re making decisions on the back end and serving different content for different devices or whether it’s all one response and uses JavaScript or Media Queries or however it’s making those decisions, every URL has to exist at every platform. It has to give you the correct information in every place.

Justin Avery: There’s a talk a few months ago now by Phil Hawksworth. He used to work with a guy who did some sketches, like big sketches on A-1 sheets. It was a Biro-sketch which says the URI is the thing. It’s just this amazing piece. I’ll shoot you, once we finish with this, I’ll shoot you a link to it and I’ll put a link in the show notes.

Also, anything that Adam has talked about through this conversation, there will be links to all those things in the show notes as well. Yeah, no, it’s this magical thing, really cool sketch. We got it printed up in AO in the office. It’s very cool.

Adam Luptak: Fantastic. I look forward to seeing that.

Justin Avery: Yeah, it’s [welco 01:21:59]. So look, I’ve got [01:22:00] like I said, we’re coming very close to the end. I have two questions for you. One was actually sent in through the newsletter. I get some replies sometimes. I’ve got this thing now of ask me anything. If someone’s having problems with building responsively or just their websites in general, they can write in. Max Angless, I’m going to massacre the names through this process.

He said that he’s designing a portfolio and he’s working on making it responsive, which is good, [Auto Max 01:22:33]. He says he’s done a lot of responsive work before using Media Queries and hamburger menus.

In the latest newsletter when he wrote this in, I featured a company called Red Booth, who had dropped a hamburger menu from their IOS app and put a fixed toolbar menu at the bottom of the app instead. It had a lot better take up of the app. People were finding things more, based on their stats that they’re all looking at as well. I know that the Rally Interactive site, you’ve gone
Hamburger menu all the way through. It doesn’t matter what size it’s at. What are your thoughts around that? Is it, yeah, well what are your thoughts around that?

Adam Luptak: Yeah. Hey, Max, I’ll shout out. I mean I think the truth is maybe people who can quantify things will disagree with me but I feel like there’s not really one right solution for everything. The hamburger menu is, even though it feels new, it actually has a long history. I remember seeing a Medium article about it, something, about the history of the hamburger icon. It is burying your nav [01:24:00] behind a tap.

We were having a discussion about that. We’re working on a new IOS app for National Geographic right now. It’s the third app we’ve done for them. We were having a discussion about a certain feature, whether it should be hidden in a menu or out on the home screen because there’s always that trade-off and it’s even harder on responsive sites or on mobile sizes. Your screen size is incredibly
limited.

If you’re in a position where you don’t have to hide your nav behind a hamburger icon or drop down menus, which have largely gone away I feel like in response to responsive design and hovers that don’t work in responsive sites really. If you can get away with not doing that because of the content and because of how things are structured, by all means don’t. There are times that it
just seems the more appropriate solution … I get why a lot of people do. You’ll see some sites where even on the largest sizes, if it’s one responsive solution, they just go with the hamburger icon for everything. We’re doing that with our site.

Part of that is just in terms of both economy of code and [01:26:00] design thinking, keeping one consistent solution as well as, even though I just said that people aren’t really re-sizing your site a ton. That said, if they look at your site on a phone and they look at your site on a desktop, it should be appropriate to where they’re looking at. You don’t want them to be lost either.
Where you can, be consistent. That’s good too. It’s always so much of design is a balancing act. You’re trying to find the right balance of everything. I think I’ve talked around it a lot but I think there are places where the hamburger is great.

There are places where it’s the lesser of all evils and just the most efficient solution. Then there are places where maybe you don’t need it, so don’t. That’s my thinking about the hamburger icon.

Justin Avery: Good advice for Max. Hopefully Max, that has given you some insight into how to approach your portfolio site anyway. It’s never finished anyway. Try it. Try two different ones. See how well you go-

Adam Luptak: Yeah. Absolutely.

Justin Avery: -as well before. Right?

Adam Luptak: Yeah. If you have the appetite for putting analytics onto your own site, that would be a great way to AB test some solutions if you’ve got the free time for it.

Justin Avery: Yeah. Exactly. I love doing that sort of stuff. I do and I don’t. The things that I learn from it, there’s two things. One, I learn how to apply analytics and do AB testing. The other is I work out what works best. Both things are beneficial. For Max, if he’s doing work for clients, both of those things are beneficial [01:28:00]. One, you have a better recommendation for a particular scenario and the other is you know how to implement analytics for them to measure their own stuff as well.

Adam Luptak: Absolutely.

Justin Avery: Win, win, win. I have one more question before we’ll wrap up. Thank you so much for coming on. This question is a post from our last guest. Each week, I get a guest to ask a question of the next guest. Once I ask you this question, I’ll get you to ask a question for our guest next week. This one is, what is the single most interesting current mobile pattern that you’ve seen come out?

Adam Luptak: Oh dear.

Justin Avery: That’s the question to you.

Adam Luptak: Single most interesting mobile pattern. I’m going to assume that he’s talking about design patterns.

Justin Avery: It’s your question. It might be. You can take it in any way, shape or form. It’s your own opinion whereas I don’t have the answer written.

Adam Luptak: That’s convenient.

Justin Avery: It’s not hamburger icon just [crosstalk 01:29:16].

Adam Luptak: Wouldn’t dream of suggesting it. I really think it’s that tray that Facebook pioneered four years ago. No. I mean I will be the first person to admit that I don’t troll for inspiration quite the same way that designers do. They’re out there looking at Dribbble and looking at sites a lot more than I do. They see a lot more of the fancy stuff going on. My use of the web is a bit more utilitarian. That being said [01:30:00], I like that we’re finding ways to go back to doing I think what the web is good at.

There was, at least from my own perspective being in advertising, there was this big exodus to Flash. “Oh my gosh, we can do all these things with Flash. The web used to be so boring and now we can do all this stuff.” The beauty of the last maybe decade, five years, however long that period’s been going on, people have been simultaneously figuring out how to do fun stuff with more Native
technologies.

I’ve never been a Flash basher. I came up on it and it was a great experience but it’s clearly not the best tool for everything going forward or even most things going forward. Now we can do a lot of those things. We’re also figuring out you can make great experiences, beautiful sites, with pretty simple design. More than anything else, the web excels at delivering images and text on a
page. I think that’s beautiful in a pure way.

It’s like the work of Massimo Vignelli  or any of those old amazing graphic designers. They didn’t complicate everything. It’s about [01:32:00] clarity of vision and communication. I actually really like that a lot of people have been going back to that, both on the desktop and on mobile devices.

Justin Avery: Cool. Nice. That was very well answered.

Adam Luptak: Thank you.

Justin Avery: I’m glad you didn’t stick with the tray.

Adam Luptak: No, that was-

Justin Avery: That was good. Now for the next guest though, do you have a question that you can pose for the next person on?

Adam Luptak: A question for the next person? I assume related to technology and digital design and the web ideally?

Justin Avery: As a responsive design podcast, it can be related to anything you choose but something to do with the web is always good.

Adam Luptak: I think I would be curious to hear what the next guest thinks. It’s so hard to predict where technology is going, whether Hollywood is always playing with things and your minority reports and whatnot. I’m curious what the next guest thinks what they’re excited about, what they’re just seeing glimmers of in the technology space now, whether they think it’s not really going to be useful but just a fun toy or if something that might genuinely change how we use our computers and interact with information and learn
things [01:34:00]. I think I’d be curious to see what they think might coming next and what they’re stoked about.

Justin Avery: That’s a good question. It is very interesting at the moment as well with the number of input devices we have now. We’ve got these Smart Watches coming out soon, the internet of things or stuff that talks to the internet. They’re all going to be things that we’re going to have to deal with in one way, shape, or form. Good question. I’m going to be very interested to hear the answer.

Adam Luptak: Me too. I’ll have to tune in.

Justin Avery: Which you do every week though, right?

Adam Luptak: Of course.

Justin Avery: It doesn’t matter. It’s just part of your normal week. Adam, thank you very much for joining us. I’m sorry I kept you for so long. It has been wonderful talking to you and hearing stories of Rally and your past and how you’ve put together such an amazing site. If people want to hear more about that or more about the work that Rally does or that you’re doing, how do they follow you and get in touch? Things like that?

Adam Luptak: Let’s see, well first I’d direct them to, for them time being, beta.rallyinteractive.com. As soon as we have that pushed over to, once we’ve worked out our Firefox bugs and our last polish issues, that will be redirecting to rallyinteractive.com, without the sub-domain. As for me, my Twitter handle is [Zoomgoo 01:35:42] 777 and I will just let you put that in the show notes. That’s probably the best place to shout out to me. There are also [01:36:00] if you’ve got questions for the studio, I think there’s an [email protected]
email address that you can hit. Obviously there are email addresses on our website.

Justin Avery: Awesome. Very, very cool. Like I said, thank you very much again for joining in. Thank you everyone for listening this week. I hope that you’ve learned. I’ve definitely learned something. I’m sure you will have as well. Feel free to write the podcast up in iTunes or share it with any of your friends if that’s what you’re into. Next week, I’ll be here with another edition of the podcast with another special guest, answering Adam’s very tough question. Adam, thank you again for joining us. Yeah.

Adam Luptak: Absolutely, Justin. Thank you. I should mention Rally is @let’sgorally on Twitter.

Justin Avery: Oh yes. Good.

Adam Luptak: Be sure to follow the company there and I think we’re @rally on Dribbble, if you’re on Dribbble.

Justin Avery: Or just scroll to the bottom of the site and see-

Adam Luptak: Or scroll to the bottom of the site. It will get you there.

Justin Avery: Yeah, good triangles. Are you guys hiring soon if anyone’s interested in working for a cool?

Adam Luptak: We definitely are. We’re always on the lookout for new talent, particularly developers right now. We’re a bit overstaffed on designers I would say, not that we don’t love our designers. We want a good balance and, like I said, we love building things from beginning to end. That said, we’re always interested in [01:38:00] getting, touching base with people if they’re interested in us, if they think they might want to come work with us or just want to say, “Hey.” We’d love to hear from people. We like keeping an
eye on the community and saying, “Hey.” Absolutely reach out.

Justin Avery: Good to hear. You can go and live in Salt Lake City.

Adam Luptak: It’s beautiful.Justin Avery: Lots of outdoor sports stuff. Famous for Olympics. It’s a good place. Yeah, thanks everyone for joining in. Thank you again, Adam. We’ll see you guys next week.