Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, we’re as giddy as somebody walkin’ into their first day at a new job, because we’re both here talking with Cameron Moll and Adam Spooner from authenticjobs.com. Cameron, Adam, thanks so much for taking a few minutes to chat with us.

Cameron:

Yeah, happy to join you.

Adam:

Yeah, thanks for having us.

Karen:

But before we get started, I’d like to say a few words about our sponsor, GatherContent. I am so excited to have them as a sponsor, because I just love GatherContent as a product. Pulling off a responsive redesign means wrangling lots of content and stakeholders. The editorial and migration process can be one of the most difficult parts of going responsive. GatherContent makes collaboration and approval processes a snap, with simple workflows and structured templates. It’s much better than the mess of Word documents, Excel files, and missing emails you rely on today. What’s even better is the API that takes your work out of GatherContent and into a prototype or your CMS. Managing the editorial processes in a responsive redesign is difficult enough, so make your team’s life easier, with GatherContent. Go to gathercontent.com and find out how this content collaboration tool can help you plan, organize, and produce your web content.

Ethan:

Adam, Cameron, thanks so much for joining us. Before we dive in, maybe you could just tell our listeners a little bit about who you are and what you do at Authentic Jobs.

Cameron:

Great. So, I’m the founder of Authentic Jobs. It started on my personal blog ten years ago as kind of a sidebar and then grew from there. My day-to-day involves everything from doing all of the design for Authentic Jobs, some other support activities, and then strategizing what we’re doing as a business. Along the way, over the course of those ten years I’ve had the privilege of authoring or coauthoring a couple books, and I have the privilege of speaking at conferences alongside you two wonderful people from time to time as well, about this topic and other topics.

Adam:

Yeah, so my name is Adam Spooner. I am the developer for Authentic Jobs, came on board in 2012. Like Cameron said, we both wear many hats. Sometimes we look silly with all of these hats, but, you know… I’ve been developing websites since I was in middle school—I’m not going to say a year, because that will date me too much—because I am the son of nerdy parents. So, I got to be around computers a lot when I was a kid, and yeah, I’m still doing it today.

It’s natural that we try to set an example of the very kinds of people and companies that we hope to attract, and so it’s a no-brainer for us.

Ethan:

So, I know I’m personally excited to have you both on because this is actually not only a wonderful responsive redesign, but it’s also not your first responsive redesign, and I’d love to talk a little bit about that over the course of the episode. So, maybe you could tell me a little bit about why Authentic Jobs went responsive in the first place and how did you actually make the decision to do that? And when it came time to do this new redesign, what were some lessons that you learned?

Cameron:

Well those are three excellent questions. Let’s see if we can tackle all three of ‘em here together, and we’ll tag team, Adam, you and I, on these. I’ll go first.

So, why responsive? It’s a pretty clear objective for our audience, because a lot of the people that are going to Authentic Jobs are the ones that are creating responsive sites to begin with, right? And so it’s natural that we try to set an example of the very kinds of people and companies that we hope to attract, and so it’s a no-brainer for us. Maybe there’s more pressure on us to be able to do that than perhaps for other companies in other industries.

But with the two of us having worked in the field for a long time, we both stay abreast of trends in technologies and things like that, so it’s natural to infuse that into the work that we do. So we started the first adaptive/responsive design in May 2011, somewhere around there, and this redesign that was launched in February of 2016 was a fully responsive design—Adam can speak more to that in a minute. But it was really to go even further than where we had gone before, and really make it responsive for just about any screen imaginable to an extent, right? When we talk about screens, there are many different screen sizes, but as many as we could present our website to as possible, that was the objective for this most recent redesign. Adam, what do you have to add to that?

Adam:

I don’t have much. Like Cameron said, before I came on board—I came on board in February of 2012—and before I came on board, the site was adaptive, and since then, coming into responsive. So, not much really to add.

Adaptive makes a lot of assumptions about what your users are doing—that they are on a desktop, that they are on a tablet, or that they are on a phone. Responsive makes no assumptions whatsoever.

Karen:

I’d love to have you both talk a little bit about that responsive versus adaptive question if you’re interested, and I might even expand that out to ask a little bit more broadly if you perceive any difference in mobile use versus desktop use. Especially as you’re picking up on this new redesign, when you’re looking at your data, do you see any differences in the types of tasks or the types of behaviors that people do on mobile devices versus desktop, or is responsive really the right way to go because you just see that handled really consistently?

Cameron:

Adam, why don’t you jump in and answer this one first, and I’ll add to that.

Adam:

Okay, sure. So, when it comes to responsive versus adaptive, adaptive makes a lot of assumptions about what your users are doing. So it makes the assumption that they are on a desktop, that they are on a tablet, or that they are on a phone. Responsive makes no assumptions whatsoever. You could be on a television, you could be on a Playstation, you could be on a Nintendo 3DS, something like that. I think the no assumptions route is much better, especially if you’re talking financially or conversions.

Our adaptive site actually didn’t even have our most profitable section of the site, which is Post, where people can post job listings—it didn’t even have that, so it was basically just a consumption site. So you could go to Authentic Jobs when it was adaptive and you could view listings, you could view the overall listing, and you could apply. And with the responsive site, of course, you know, all the services are there. So, as far as conversions go, it jumped 100%.

Cameron:

Adam, you stole my thunder. I was going to touch on that and the fact that when we launched the first version in May 2011, I remember having discussions, we were like, “Nobody is going to want to post a job listing on their phone! I mean, that’s just ridiculous!” and so we didn’t even touch that part of the website. And my, how far we’ve come since then, right? I don’t know that people will dramatically increase posting jobs through their phone with this new version just because it is fully responsive, but for us it was a big mindset shift in the way that we approached this redesign, to say that it’s possible that users will want to do everything on mobile that they do on a larger screen, and so how can we make sure that the experience will cater to those users that come expecting to do the very same things they do on a larger screen, now on this smaller or mid-sized screen? So that really was a key driver in a lot of the decisions that we’ve made since that 2011 launch.

We really looked at what are the capabilities that can happen on both mobile and desktop, how can we make sure that those are as accessible as possible for any size screen?

Karen:

Let me quickly follow up on that and ask about how the prioritization of different tasks or different features might have changed as you made a completely responsive site. So, how did you look at which things were higher up in the mix, and which things were maybe a few clicks or taps away, and did that change from your initial desktop presentation of the information?

Cameron:

If you look at Authentic Jobs, we’ve got two audiences: we have our paying customers, we have our non-paying customers. The paying customers are the ones who come and post a job listing, the non-paying customers are the ones who are looking for a job. With those non-paying customers, it’s relatively easy to understand what they’re after, they’re after looking at job listings and being able to filter those job listings. With our paying customers, they’re either coming, generally speaking, to either post a job or look at the analytics and so forth for jobs that they’ve already posted.

With Authentic Jobs, it’s a relatively—I don’t want to say “easy” project, it’s certainly not easy—but it’s not a deeply complex project. You have the non-paying customers that need to find jobs and apply to them, and then the paying customers that need to post jobs. So with the non-paying customers, certainly with smaller screens, that comprises a more significant portion of traffic because they’re the ones that, on the go, will be looking for jobs and things of that nature. Whereas we have a lot of people that post within HR departments on Authentic Jobs, and they’re the ones that are typically at their desk, larger screen and that sort of thing.

We wanted to make sure that anything you could do on a larger screen as a job seeker was accessible on a smaller screen, and so while Authentic Jobs is relatively non-complex for most users, there’s still a lot of complexity that surrounds the filtering of jobs and things like that. And so previously, for example, you couldn’t even locate jobs near you. You could do that on a small screen, you couldn’t do it on a large screen, even though technology has come a long way since then. And so we really looked at what are the capabilities that can happen on both mobile and desktop, how can we make sure that those are as accessible as possible for any size screen, for that matter?

To be totally honest, we didn’t have a long list of features and tasks that had to be prioritized as it pertains to responsiveness, but it was the overarching goal of saying, “Can we allow users to do just about anything they’d like to do, regardless of the screen that they might be using?” Adam, what do you have to add to that?

Adam:

I have nothing to add to that. [laughs] You nailed it.

Ethan:

Flawless answer.

Cameron:

Did I answer your question, Karen?

Karen:

That was perfect.

Even back then, I remember writing that I believed you could do—should be able to do—most everything through a browser, at least have the capability to do that.

Ethan:

Yeah, I thought that was great. Cameron, one of the things that just popped into my head while you were speaking was that you actually wrote one of the first books that I ever read on mobile design, and I was just kind of struck hearing you speak about this evolution for Authentic Jobs, about thinking about the mobile user and the desktop user as somehow distinct, and this sort of path in moving toward treating effectively both contexts as just different facets of the same experience. I guess I’d be curious to hear as you sort of walked that path with Authentic Jobs, has your design process changed as you’ve started thinking about multi-device experiences as just being sort of like points along the same design?

Cameron:

Yeah, I guess speaking for me personally, it’s certainly changed and it continues to change, it seems to be always evolving. I’ve vacillated myself between the start with the desktop sketch, so to speak, or start with the mobile-first comp, or things like that, and I’m still on a day-to-day basis figuring out what works, because the landscape seems to be constantly changing.

It’s funny you mentioned that book, I went back and reviewed that recently and looked at some of the things I wrote about. I, back then, pitched this idea that there were basically four ways to make experiences accessible on mobile devices. The first one was to do nothing; the second was to just simply reduce the images, the styling; the third was handheld style sheets; and then the fourth was kind of a mobile-optimized experience. And even when I wrote the book, it wasn’t clear back then which approach was right, and I think I remember writing in the book the pros and cons of each of those, and that was certainly the case. Thankfully today, because of your efforts, meaning Ethan and Karen, and many other people, it’s much clearer what the right approach is.

But even then, as a designer, as a business owner, it’s not always clear where to start, and I can’t say that I have a process that works for every project. It’s just kind of assessing what does this project need, what are the components? How heavy is a brochure-like site versus a very app-complex experience? And do we have an app, an Android and iPhone app? And all these different factors that didn’t exist in 2007 when I wrote the book. But even back then, I remember writing that I believed you could do—should be able to do—most everything through a browser, at least have the capability to do that. Here we are nine years later and we’re still pitching that case, and so I guess in some respects my approach has not changed at all over the past nine years, and yet it’s changed in every regard over the past nine years.

I think some teams feel pressured that everybody on the team has to know the ins and outs of responsive design, and I just don’t think that’s the case.

Ethan:

Wow, that’s wonderful. You mentioned process somewhere in there, Cameron. Let’s dig into that for just a minute, because I’d love to hear how you and Adam actually worked together on this redesign. How did you actually sit down to plan the design and development of new features? How are you trading ideas back and forth? We can even get as deep in the weeds as the applications and tools you’re using on a daily basis to talk about the responsive redesign. I’d just love to hear a little bit more about your day-to-day.

Cameron:

Let me go first, Adam, and then you dive in and fill in all the gaps that I’ll leave for you.

Adam:

Alright.

Cameron:

I’ll say this just right off the bat… Let’s take that book, for example, in 2007. I was very well-versed in writing markup. That is not the case today. In fact, I write very little markup. I think Adam chuckles when he sees me attempt to write markup. This was a very collaborative effort between the two of us, where I was both the strategist, as was he, but I had to look at this with business owner lenses and with also the design lens; I still do all the design for the site. And so, knowing that Adam would be doing all of the markup as well as some of the back-end and complementing the strategy that we were discussing, this was a big team effort.

And the reason I’m mentioning this is because I think there is some undue pressure today that the designer and/or front-end engineer, anybody on a design/engineering team has to be well-versed in all of these things in order to pull off an effective responsive design. That’s not the assumption of everyone out there, I know that, but I know I feel that way sometimes. It’s almost as if I feel shameful admitting that I can’t write markup anymore, and yet I’m totally okay with that because I think we have a lot of very capable people, like Adam, who knows that space extremely well and can work with me as the lead designer to interpret what our business objectives are and to execute those, rather than me, like I did a decade ago, feeling like I have to master both the design and the markup components.

And so, I like to think even though we’re a tiny team, we sit in a great place where we both have our thinking caps on strategically, but then we also have tactical expertise that can be applied to be able to execute something like this. And so, again, I say that because I think some teams feel pressured that everybody on the team has to know the ins and outs of responsive design, and I just don’t think that’s the case. I think having people on the team who are T-shaped and have some expertise in one given area but might understand, at a high level, what the objectives are… In my mind, that’s the most effective way to accomplish a redesign, and that’s how we approached this project. Go for it, Adam.

Adam:

Well, first off, I think you’re selling yourself short when it comes to the engineering side of it. One of my first books—I’m turning around, looking at my bookshelf right now—is CSS Mastery which Cameron is a co-author on. I still have yet to get him to sign it, but I’m going to try.

Cameron:

[laughs]

Adam:

So, you have a very good understanding of the higher level aspects—well, even some of the lower level aspects—of markup, and I think that’s good when you go into it, because you can look at the thing that you’ve designed and you can say, “Okay, this should be fairly simple, this could be entirely complex,” and have a pretty good basis for those things. And that’s very good, that crossover that we have between where you are familiar with it enough that you can go, “Okay, I understand that this is going to be something that’s going to be complex,” and I think that’s sort of where we have our sweet spot, in that we both can cross over and appreciate each other’s domain.

And that’s very helpful when it comes to doing something like responsive design, because there is a lot—well, with this redesign for Authentic Jobs, this is, what, three years in the making, I think? There have been a lot of starts and stops, a lot of “You know what? Let’s just wipe the slate and start over again. This isn’t working.” So, it’s been through a lot of changes, and as part of that, we’ve had to re-look at what our goals are, and part of that is, you know, let’s make the posting process, for someone who wants to list a job on our site, let’s make that possible on a mobile device; if it goes all the way down to a tiny watch screen or something like that, let’s make this possible.

You’ve got to use whatever tools not only work best for you but you are most efficient at.

Cameron:

You know what was challenging, too, about that—I’ll add to what you just said—is how the technology used to accomplish responsive design is constantly evolving. Over the course of two-plus years working on this redesign, we have things like Flexbox evolving, we have things like SVG evolving, and you’re like, “Oh my gosh, do we just throw everything away and start over?” And thankfully we didn’t, but that is a definite challenge when you have a two-year long project, to accommodate and adapt to the changes in the landscape.

I’ll just speak briefly to what you asked, Ethan, about some of the tools. I’m still very much a Photoshop guy; I have been using Sketch more and more often over the past probably year. But for me, I just, I don’t know, I guess I’m an old guy in the industry at this point. I just don’t have a lot of desire to entertain “Let’s go find the newest tool and master that and then race to the next newest tool” and so forth. I think you’ve got to use whatever tools not only work best for you but you are most efficient at. It’s still—even though I haven’t used it extensively—it’s still, a year later, a bit of a stumbling block for me to work in Sketch. There are things I can do faster in there, but there are things that hold me up and don’t allow me to act quicker that I know I can do faster in Photoshop, believe it or not, just because I know that tool very well. So, for me, it’s just whatever tool I think works best.

Adam is just a master at being able to adapt to new tools and technologies and things like that, and I think he really pushes our team to make sure we’re staying abreast of that. And if anything, I think my processes are not adaptive in the traditional sense of the word, meaning having to figure out what the most effective measures are. I think I’ve held up our team a little bit because I still like to see things higher fidelity than actually getting it in code, and that’s an area where I know that I need to improve if we want to, especially speaking of responsive design, test these ideas out on different screen sizes rather than trying to think we can prototype them, comp them, whatever, with static designs. So, I think we’re still learning a lot as a team many years into this industry, believe it or not.

Karen:

Let me ask a little bit about the content changes, the actual substantial changes that you might’ve had to make as part of this responsive redesign. So, one of the things that I noticed in the post that you wrote announcing the new redesign, you talked about some of the changes to the filters that you would offer for jobs. As a content person, and I’m sure you realize, that’s not just about the filtering options that are available, it also changes the posting process for your customers, like you’re asking them to enter in new information, different information. Can you talk a little bit about those changes and how you decided to make those changes?

Cameron:

Yeah well, a lot of those changes, to be totally honest, are part gut, part based on other metrics, customer input, and so forth. I’ve always believed that if you sit around and have a focus group and believe that you’re going to have all of your decisions made out of that focus group, you’re just fooling yourself. All of the data in the world is not going to tell you how that thing, in the end, may have to be designed or developed or things like that. And so, it’s a blend of, over the course of ten years, hearing customers ask for certain things, looking at data, but also just guessing and anticipating what they might want.

I’ll give you one example of this. We added the ability to specify—and this affects, as you said Karen, both the people posting jobs as well as those seeking for jobs—the ability to filter by salary, or in the case of, if it’s a freelance gig being posted, to filter by the amount that would be expected to be paid for that project. There’s some interesting cultural things that had to play into that though, in that in the UK it’s almost required that, if you’re going to post a job listing publicly, that you state what the salary is going to be, or at least the salary range. It’s just part of that culture. Here it’s not the case, and in fact most employers in the United States will hide that information until they get deeper into the discussions. And because we have an audience that spans not just the United States and the UK but other locations, we felt it would be a good time can we explore can we state what a salary would be, what the project fee would be for the people using the site, and do it in a way that wouldn’t put an undue burden for the people posting those jobs, but also make it comfortable enough that they could expose that data if they wanted to. So, we said, “Why not just come up with some tiers?” and in fact if you look at a job posting that specifies salary, it doesn’t state out, you know, $30,000 to $49,000 or something like that, it just says “tier one” or “tier two,” or something like that. So it’s at least somewhat hidden for the culture here in the United States that might not be comfortable with that. If you hover over on a screen that has a mouse, you can see that data, or on a screen where you can tap, you can tap that and it will show you what that tier equates to.

But that was something where our customers weren’t really asking for that, but we felt this is something we want to push forward and have more open discussion about this, and allow people, if they want to specify this, to do so, and that would enable us then to create a new filter for candidates who wanted to look for those particular salary ranges. We actually went live and forgot to put the “don’t show salary data,” meaning right after launch, how long was it, Adam, for a week or so after launch?

Adam:

Yeah, maybe even less than that.

Cameron:

You couldn’t not specify a salary, we forgot to put that in there, and I realized it days later and said, “Adam, we need to put it in here where they can opt out of specifying salary,” and that’s the case today. But I’d say—we haven’t looked at the stats on this—but I’d say about half of our customers are using this already, and so I think it’s been great to not just see other cultures that are already comfortable with this, but even here in the United States, to see them begin specifying that. And Karen, we had no data to go off of that, and so we had to just make a gut guess and say, “We want to push this for both our paying and non-paying customers, and let’s see what happens with it.” Now, had we’d been smarter—I’ll just add to that—we would’ve done a lot more testing prior to launching with this. But with a two-man team, of course there’s only so many hats we can wear and only so many things that we can do at the end of the day. Karen, does that address your question?

Karen:

Absolutely. I thought it was a great answer.

We got a support request once from Brazil about a Playstation 4 user having trouble using the site, and I just thought that was fantastic, because I test on Playstation 4 now.

Ethan:

One thing I’d love to hear a little bit about is how you went about testing this responsive design as you were working on it. You know, this is something we hear from a lot of companies, that when they start moving beyond the desktop in the first place, they’ve got a whole bunch of new devices and browsers to look at. Is this something that impacted the responsive design in any way, and if so, how did you manage that?

Adam:

So, for as far as like devices that we test, we both have quite a few devices that we test on, and I use—I forget the name of the company—it’s a product where you can put a few devices on it at a time and sync up your browsers… So, as far as like the process goes, it typically starts out with a browser that’s squished down as small as it can go, and then expanding from there on out, and then comes like device testing week or month, depending on how bad it is, and then go through a bunch of different devices. So, I play quite a few video games, so I have quite a few video game systems, so I test across those. I think we got a support request once from Brazil about a Playstation 4 user having trouble using the site, and I just thought that was fantastic, because I test on Playstation 4 now, so that’s a lot of fun.

Ethan:

Nice.

Adam:

Yeah, so that’s sort of how the process goes, typically starting out on the desktop with a small browser and then going out from there to different devices.

Other important factors are the page download speed and page download times, and we’ve seen a 67.5% increase in the download time of pages. So it’s been a very good change not even just responsively, but just across the board.

Karen:

I’d be curious to talk about how you measure the success of this responsive redesign. So, do you look at your metrics or your analytics data any differently when you have a responsive design? Like, how do you know if the site is working or not?

Cameron:

Yeah, let me answer that maybe generally speaking first. We measure the success of this effort I think partly based on what kind of signal are we sending to our customers, and if we’re trying to attract the very people who are going to build the things that we’re building, what kind of signal are we sending? Are we setting the tone that we are abreast of changes of technology and things like that, and therefore attracting people because of that? Or are we lagging behind and just expecting people to post jobs for cutting edge work, so to speak, even though we’re lagging behind? And so, we check ourselves against that partly, to say are we leading the cause, are we part of the rally cry as well? And that’s a big thing for us. We’re still too new, just a few weeks into this, to say this has significantly impacted revenue positively or something like that, I think that’s going to need a little bit more time. Adam was telling me earlier, though, about some of the changes, as far as metrics are concerned. Adam, why don’t you dive into that?

Adam:

Yeah, sure. So when I think about, especially for our design, where it went from adaptive to responsive and the inclusion of an entirely new service, which is the profitable side of the business, I wanted to look and see how have profits changed, how has the use pattern changed for users? And so for Post specifically, that’s the service that we use for job listings, we’ve seen a two percent increase on mobile devices and 100% conversion increase because it wasn’t even available before. Other important factors are the page download speed and page download times, and we’ve seen a 67.5% increase in the download time of pages. So it’s been a very good change not even just responsively, but just across the board.

Cameron:

We’ve even seen some other metrics, like bounce rate, go down slightly, session duration on smaller screen devices increase, and so I think we know that, right? We’ve seen enough data to indicate that responsive, generally speaking, will lead to those things happening. And so I think by all accounts, it’s still only a few weeks old, but it’s been very positive. We’ve had tons of positive feedback come in through our support channels from users, and so I think we didn’t get it perfect, but we certainly got a lot of things right with this relaunch, and I think we’re proud of that.

Across the board I would say, start with mobile first, it’s just that much easier. Just start there as a small screen and then grow out from there.

Ethan:

Well it’s, like you said, early days, but it really does seem like you have a lot to be proud of so far. With that in mind, I’d really love to hear if either of you have any advice for anybody who might be listening to this podcast. If somebody out there in the audience is going to be starting a responsive redesign today, what’s one or two things you’ve each learned over the course of redesigning Authentic Jobs you’d like to share with our listeners?

Adam:

I can speak from the development standpoint. So, if you are just starting out, it really just depends on—and Cameron mentioned this earlier—if it’s going to be app-like or if it’s going to be more brochure-like. There are a lot of sites that we were looking to for inspiration to see, you know, how do other people do this on smaller screens? And a lot of the websites that we would go to, a thing would pop up and say, “Download our app!” because there is no mobile version in a browser. So, some of the things we had to go, “Okay, let’s take some things from Android and iOS and let’s see if we can put those into our application,” especially the filters and things like that.

So if you’re going to start out on a brochure-like site… Well, across the board I would say, start with mobile first, it’s just that much easier. Just start there as a small screen and then grow out from there. As far as styles go, as far as JavaScript goes, it’s just a lot easier. Three years ago, when we first started this, I did not do that, and there are still some tiny remnants of that code still lingering around, and I look at it with dread every time I see it. So, don’t view source. As far as if you’re going to do something that’s more app-like and have some more complex interactions, you may have to pull from other references, you might have to look at iOS applications, Android applications, as opposed to looking at other websites for inspiration. Yeah, I think that sums it up.

Cameron:

Yeah, this is a fun question to answer, Ethan, because I think for me it’s two things. One, you announced this, what, five years ago on stage? Has it been that long?

Ethan:

Oh, man… Just about six, I think.

Cameron:

Oh my gosh, that’s crazy!

Ethan:

Yeah, it’s terrifying.

The general concept of responsive, that’s the idea, in a traditional sense, of making our content accessible anywhere, whether it be through the browser, or through an app, or both of those things.

Cameron:

Here we are six years later and we’re still talking about it like it’s six years ago, meaning that it’s still fresh, it’s still exciting, there’s still so much change happening. And so, on the one hand it’s a very exciting time to be looking at things like responsive design. On the other hand, we’re still figuring out a lot of it. And when we were trying to do that figuring out part, for us, we really did look at some other products that we looked to as examples. Rdio unfortunately no longer exists, but they were one, and if you would pull up Rdio in your browser, on a small screen, on a phone, for example, you got the go downloader app kind of thing. And so we were trying to find examples of more complex interaction, and unfortunately we didn’t find that with Rdio and some other resources, and so, to be honest, we felt a little bit in the dark. Not to say that there aren’t many sites now and there weren’t, you know, two years ago when we started, but we were really trying to find other people that had figured out the more complex interaction that we do on our side and things like that. And so when I look now at what we’ve accomplished and what everyone around us is accomplishing, I think there’s a lot of enthusiasm that remains, six years into this, for continuing to do what we do, because we’ve figured it out, right? And now somebody can look at Authentic Jobs and say, “A-ha, they managed to figure out complex filtering with responsive design, so we can go pitch that to our team as someone that’s figured that out!”

I do want to add to that, I want to say a word of caution, but just to think about the overall strategy, and recognize that if you’re just starting out or looking at diving into responsive something, you have to recognize that it’s not a complete package in terms of all of the touch points that people have with the screens in their lives, whatever screens those are and wherever they are with those screens. And what I mean by that is this: If you look on Apple.com right now, as an example, of the products that are listed across the top, you’ve got Mac, iPad, iPhone, watch, TV. Two of those products do not even have a browser, and responsive design, as we know, ends where the browser ends. But I think if we step back and look at the broader concept of responsive design, meaning not just exclusive to the browser but some of what you, Ethan and Karen, have been evangelizing, we look at the general concept of responsive, that’s the idea, in a traditional sense, of making our content accessible anywhere, whether it be through the browser, or through an app, or both of those things.

And so, for those that might be starting that journey right now, my encouragement is to take inventory of all the places that your users might encounter your content and the screens in their lives that they might encounter that with, and their preference for using browsers versus apps and so forth, and look at the opportunities to deliver your content in the most accessible ways possible, or to use, again, the broader term, the most responsive way possible, whether that be in the browser or outside of it. That is a very significant shortcoming of Authentic Jobs as a product right now in that we don’t have an Android app or an iPhone app. We did at one point; we had to kind of refactor things and we still have that on our road map. But we recognize that for people who might want to access Authentic Jobs on a regular basis and may prefer an app to do that, we’re falling short in that regard, and so we know that that’s something that needs to be figured out hopefully this year.

So I don’t know, I have nothing but encouragement for people to figure out the challenges of responsive design. There is a lot of hair pulling that might come as part of that, certainly there was for us over the course of two years. But you know, the rewards in the end are significant, and we’ve seen nothing but justification for going down the path that we’ve gone and others who have already paved that path for us.

Karen:

Well Cameron, Adam, I really want to thank you for taking the time to come and talk to us today. You know, I personally will say that one of the things that’s most important to me when I look at job listing sites in general is to be aware of the number of people out there who are low income people, or less educated people, who really don’t have access to broadband computers and their only way of finding jobs is on their mobile device. Pew Internet just published some research about that recently. So I think that the scenario in which someone needs to find a job or post a job from a mobile device is a really important one for us to consider, and I just want to thank you for taking the time to talk to us about it.

Cameron:

It’s been a pleasure.

Adam:

Yeah, thanks for having us.

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.