Episode Transcript

Karen:

Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week, why I don’t think I could be more delighted to have Robert Petro and Nikki Lee from Beatport here to talk to us. Hi guys, how are you?

Robert:

Doing great thanks.

Nikki:

Hey, how are you?

Beatport has always been a store where DJs can purchase high quality tracks to use in their set. This is pretty specific to the electronic dance music scene, so it’s always had a really great niche of selling those tracks. Even in a world where something like iTunes or Spotify exists, Beatport has that niche.

Ethan:

But before we get started, I’d like to say a few words about our sponsor, Campaign Monitor. Campaign Monitor has this new feature they’re really excited about, called Canvas. Canvas is an easy-to-use builder for creating beautiful, responsive email newsletters, that look great basically anywhere, even on mobile devices. What I’ve actually really enjoyed about working with Canvas myself, is that it’s incredibly easy to use. It has this really intuitive drag-and-drop interface, and actually gives me a decent amount of control over fonts and colors, and also takes care of a lot of the stuff you kind of expect to just work. Automatic image resizing is actually one that I find really helpful. And it’s actually very quick to get an email up and running in minutes. So if you’re interested, you can actually try it out without actually starting a Campaign Monitor account, if you go to campaignmonitor.com/templates you can build and export some beautiful and responsive email newsletter designs, again, without having that Campaign Monitor account. So thanks again to Campaign Monitor, and thanks for listening.

Karen:

So why don’t we start off, maybe you two could both just introduce yourselves and tell us a little bit about your background, a little a bit about what you’re working on. Robert, why don’t you start.

Robert:

All right, great. So my current role at Beatport is the product lead for Beatport Pro. And for that to make any sense you have to understand a little bit about Beatport’s history, which I’ll just cover very briefly. Beatport has always been a store where DJs can purchase high quality tracks to use in their set. This is pretty specific to the electronic dance music scene, so it’s always had a really great niche of selling those tracks. Even in a world where something like iTunes or Spotify exists, Beatport has that niche.

Up until this point Beatport has always been geared around just selling tracks as an e-commerce store. Now we’re really making a pretty big divide with what we’re calling Beatport Pro. So my title as product lead for Beatport Pro is considering everything that we’re doing for the professional DJ. And selling tracks now falls under that. We have other plans obviously to do some great things for the fan experience, but for now we’re just duplicating the functionality in this store and that’s where my role comes in. So my background in web is as a front-end developer and a designer. And that transitioned nicely into some client engagement stuff for the company I worked at prior to here called Arc90. From that experience I was asked to be the product lead for everything for Beatport Pro going forward. So that’s currently where I am.

Nikki:

I’m Nikki, I’m the lead designer here for Beatport Pro. I’m responsible for a whole bunch of different fun stuff. The Photoshop comps, wireframes, HTML/CSS, that stuff is all mine. So redesign of Beatport Pro is my vision and I’ve been really excited to work on this project. As far as my background goes, I also started out at Arc90 before it was acquired by SFX and Beatport. And I was a web designer and front-end developer there, so I just kind of merged into this role really well. That’s it, it’s been fun.

We obviously find the value in being able to open the app and have the same experience across any device, any screen size. So it was sort of a no-brainer when we started out that this whole web experience was going to be able to be responsive.

Karen:

That’s great to hear. I’ve known Rich Ziade from Arc90 for many, many years and I’ve been really interested in the Beatport story. So I think my first question for you is, I’d love to hear more about how you made the decision to do a responsive web app. I’m interested especially because, while I would imagine that your audience of professional DJs is on their phones, I might also question—why go responsive versus having a separate phone app, a standalone app or thinking about it as completely separate experiences?

Robert:

Okay yeah, that’s no problem. We’re all coming from the product shop Arc90. We are all sort of tech nerds on this side. And so responsive has been in our blood ever since before we got acquired. Anything that we were developing in our previous lives before Beatport we were looking at in a responsive way. We obviously find the value in being able to open the app and have the same experience across any device, any screen size. So it was sort of a no-brainer when we started out that this whole web experience was going to be able to be responsive. Now that actually, that assumption wasn’t made by the group that was doing all the development before us.

And so Beatport has never really been able to have a responsive site. It was really important to us to offer to our constituents as a feature the fact that they would be able to have this same experience translated down, no matter what device they’re using. So that decision was pretty obvious for us to be able to make.

In light of it being made, as opposed to a native app, well we had some help there. Things like, in iOS if we put an app in iOS that’s specifically selling music, we get in a little bit of trouble with Apple, and there’s also a bit of a profit share that we’d have to do there that, I don’t think from a business perspective we were wanting to do. So responsive was really the way we wanted to go for all mobile right from the start. It ended up being a no-brainer for us.

Now, that decision ended up causing a lot of difficulty along the way for development. There’s a lot of things that I think are unique to Beatport that might not be unique to some other sites. But for us, we knew from the very outset that we would be going responsive with this.

Beatport has about 5 million active users and gets 50 million uniques a year, so we’re not dealing with a small group of people. We knew that we would be dealing with a large user base that we did not want to upset.

Ethan:

Can you tell me a little bit more, Robert, about how you started to have that discussion about going responsive when you’re looking at this redesign of Beatport? When you’re talking to stakeholders at SFX or at Beatport, was there much convincing you had to do?

Robert:

I wouldn’t say it was too difficult to convince people that we wanted to offer a mobile experience to our users. Sometimes when you have those discussions and they come at the cost of “Yes, but this is going to extend the timeline for which we want to develop these things,” then that’s where the rubber meets the road sometimes and you have those tough decisions. But overall, it was pretty easy to get stakeholder buy-in to convince them that this was an important route we wanted to take.

As far as the way we went about it, we had at the outset—Beatport has about 5 million active users and gets 50 million uniques a year, so we’re not dealing with a small group of people. Something like Facebook, when they change a button, the world flips out—we knew we would have that, shrunk down a little bit by scale—but we knew that we would be dealing with a large user base that we did not want to upset. What we were wanting to do was go for feature parity between what they currently have and what we could offer them, and then the entirely new mobile experience was where we were really going to shift their thinking and see new workflows develop, and we would take their lead on that. That’s part of the reason, actually, we launched in a beta alongside the current store, was to get that feedback and see what people were saying about that experience and then be able to incorporate that.

When we attacked it, we started whiteboarding and we spent a good two months every week just tackling a different feature from the current store and saying “What does this look like? Is this the right way, as it is right now, even on the desktop experience?” Then “How can we begin to break this down?” I would say that our approach was not mobile first. We started with the desktop because it already existed, and then we worked down from there. We’re going to let our users really help define and fine tune the mobile experience based on their usage. So those are some of the things that we had to deal with when we started attacking this and getting all the stakeholder buy-in.

We attacked it as if they were modules, really. For us to be able to say, as the screen size gets smaller, “What do we need to do with these modules?” actually was not a super difficult task.

Karen:

Talk to me a little bit about how you achieve feature parity. I ask that simply because one of the topics that comes up a lot in planning responsive designs is how do you prioritize, how do you re-prioritize, how do you make decisions about what should be more or less important or how heavy it shows up on the page. How did you take an existing product and re-prioritize what you showed so that it worked in a responsive format?

Robert:

We attacked it as if they were modules, really. If you look at the current Beatport homepage, and by current, I mean the old store, which is currently up at Beatport.com—if you look at that, we have very distinct layout features. We have a big hero advertisement section of merchandise content that highlights other things that are going on on the site. We have a big top ten section, we have new releases—all these things are very modular in nature and you can imagine just being able to pluck them out and put them somewhere else on the page if you wanted to, based on something like analytics saying “More people use this, so this needs to be more important.” Which we have those discussions; we decided the layout almost entirely based on the current usage.

We did take a very modular approach. If you flip through Beatport, you notice that we do have a design language that is repeated throughout.

For us to be able to take that and then say, as the screen size gets smaller, “What do we need to do with these modules?” actually was not a super difficult task. The real trick was with what Nikki was doing in changing the way those modules looked. Obviously we have a hover functionality, like if you want to add to cart and things like that. All those considerations for something on a mobile device had to become now either touch or some other way of getting around that being hover, and so there were considerations like that.

But we did take a very modular approach. We would take what tracks looked like on a desktop and we’d say “This is the language that we want to use when we scale down” and “This module will always look like this no matter where it occurs on the site.” If you flip through Beatport, you notice that we do have a design language that is repeated throughout. There’s a place where you have track listings, there’s a place where you have releases, which generally have the square album artwork with it. We took all those things and we established, one by one, what those would look like on a desktop. And then we said this is what they look like somewhere down by iPad, all the way down to if we have to get into a single column on something like a phone device.

So, we took a very modular approach and with the way we attacked it as far as priority, the first thing that we wanted to get out the door was we wanted people to sort of get excited. We do have a lot of stakeholders between SFX, which is the parent company, and then all of the people that work at Beatport who are also concerned with what we were doing.

We started with the homepage and redesigned that, just to get people excited to see what responsive design could look like and how it would work. We started from the very top down. The way we have that page laid out, the homepage, is a reflection of exactly the usage we’ve had over about the past ten years of usage, to say what’s important to the users and how they go through their work flow. We just attacked it that way and, one by one, started breaking those modules down. As they appeared in other parts of the site, it was extremely easy to sort of plug and play with those. There were different places where that would be in conflict—which Nikki, you’ll probably want to talk about in a little bit—but for the most part, we were able to plug-and-play with those modules once they were developed that way.

We started with the homepage and redesigned that, just to get people excited to see what responsive design could look like and how it would work. We started from the very top down.

Ethan:

That’s really great. Nikki, I’d be interested to hear a little bit more about that process, as you started designing this responsive site especially from a desktop-only legacy version. How did you begin? What kind of mockups or prototyping did you do? How did you actually put your feet in the water?

Nikki:

Robert mentioned whiteboarding sessions, so it was him and I and a couple of other project managers and another designer, and we would sit and we would pick something wanted to attack that day or that week, such as the player or the header or the homepage slider. We would just sit and brainstorm and whiteboard together and figure out what actually had to be in this thing. What has to be in the header? What has to be in the player? What’s working on the current player? What’s not working on the current player? How can we make it better? Then we would just whiteboard and sketch together and come up with ideas and figure out what we could do. I would take those whiteboard notes and bring them into Photoshop and make more solid wireframes and we would go over those together and figure out what is and isn’t working. We’d iterate on the wireframes and eventually turn those into designs. We would do this for every chunk on the website—again, the player, the header, the different pages, the track modules, release modules, etc. We were able to piece all of this stuff together into the site in the end. But yeah, like Robert said earlier, it was very modular thinking and just working through these chunks.

Ethan:

That sounds great. Would you say that your process has changed pretty significantly as you’ve been doing more multi-device work? What kind of applications are you using these days to do some of this design thinking?

Nikki:

I design everything in Photoshop, that’s just what I am most comfortable and fastest using in. But I also do all of the front end development myself, all of the HTML and CSS, and so that helps because I can have a plan. Going into Photoshop, I know how I’m going to make this work or I know how I’m going to code this out and if I have any issues, I can go and open up a coding application and try something out. It’s a very flexible process. It’s a combination of Photoshop and just getting in and playing with some HTML and CSS.

Ethan:

That’s awesome. So, are you doing much breakpoint-centric work in Photoshop as you’re planning these modules or these layouts? Or is it pretty much get to a point and then moving into prototyping?

Nikki:

I would work with some standard breakpoints, so we would have a large desktop size and the typical iPad size, typical iPhone size. We were working with Apple products since they are so standard—well, not anymore since the iPhone 6—but those were our basic breakpoints. Then I would just make sure that my designs were flexible enough that they would look good at all the in-between sizes too. So, working with those standard Apple breakpoints but being very flexible to make sure that designs encompass all devices.

Everybody on the team has built responsive sites before, but I don’t think to this scale and in front of this many people. So it presented a little bit of a challenge that way.

Karen:

Can you talk a little bit about how this process changed the way that your team worked together? I imagine you all have worked together for awhile and are comfortable with your process, but does responsive change the way you collaborate?

Rob:

It’s an interesting question. The teams—so, there’s maybe a little bit of history here that’s important. We were acquired by SFX last year. We were a product shop, like I said, working all together for different clients.

Beatport has always been a product and SFX acquired them shortly before they acquired us; Beatport carries the brand and also, obviously, the legacy of users and everything that we would be then integrating with. So the team, as it stands, the first thing we ever built as a team was this product. Which presented a couple of challenges. I would say that in combination with a pretty aggressive timeline we were dealing with, also presented some challenges for us to work through.

As far as the dynamic of how we worked together, we came together pretty quickly. We do have a pretty amazing team. We currently stand at four Python developers, which is what the back end is written in. Then, we have three front end developers, including Nikki. Nikki is also the lead designer and so, Nikki was not short of any work at any point in this project. But, working together was a process by which, once we had these designs, and Nikki and I were able to run out in front of everybody even before the team was fully formed to establish the designs, all the way down to creating Photoshop comps in each of the sizes that we wanted to display. So, we had a really great idea when we presented to the rest of the team what we were doing. There was a very clear direction and that helped a lot to sync us up.

Once Nikki would start coding these things there would be all sorts of issues that would come up. Specifically, functionality wise for like, oh when the player breaks down. We’re keeping a lot of state in the DOM, and we’re moving things, and emptying out divs, and replacing them. That felt a little weird, so Darren, one of the front end developers, the lead front end guy on the project, started making recommendations for—okay what if we specifically had a different player when you hit this media query and on desktop we keep the player this way. So, all of those suggestions started to make a whole lot of sense once we started working together. I would say the process of the team work going throughout has been really fluid. We’ve never been short of work, like I said, mostly because of the large task ahead of us and the short timeline we were working on. So, there was always something to talk about and the team ran pretty fluidly. Plus it helps that we all like each other and enjoy beer together and things like that. So, it really came together.

Specifically, the issue of responsive, because it was from the outset that we knew that we would be developing this responsively, that sort of added, I think a lot of motivation for people. Everybody on the team has built responsive sites before, but I don’t think to this scale and in front of this many people. So it presented a little bit of a challenge that way, but for the most part the team really united around that opportunity to build something so creatively that works on so many different devices.

Karen:

Okay. I have a follow up on that. You mentioned having conversations within the team about shifting to a different player at a different breakpoint.

Robert:

Yep.

So, at this point we’re dealing with more than media queries, right? We’re sniffing for the actual device that’s being used. When we notice it’s a mobile device, we go ahead, in combination with that media query, and we will use the appropriate player for the size.

Karen:

Can you talk about, give me some more information on what those conversations were, like why did you decide to do that, what were the benefits and tradeoffs of doing that?

Robert:

The player was one of the first things we built. So, I really appreciate this question, because it gets us to get to go back and sort of revisit that thinking. But, the main issue with the player is there’s a playlist, every time you play or, you have the opportunity to play a track on the site and listen to it, it ends up in your playlist that’s attached to the player. Its a pop-up playlist, or you can just add directly to that then, once one song is done it goes to that next song. As you’re cruising around the site the player, obviously stays on while you visit all the other pages.

That playlist presented a lot of problems, because it completely shifts form when we get down to iPad, then once again when we get down to iPhone size. That presented quite a bit of problems when in shifting around state when the playlist was open versus closed. Even keeping it open and closed in the different states ended up being a challenge. So, we started to see all these problems that we were having as we were shifting down. And, not just rearranging content, but really pulling out a lot of content and having to reinsert it. That felt a little bit like a smell to us, so we went and said, “okay what is the likelihood, what is the use case, for somebody who’s going to be shrunk down to something like 500 pixels on their browser, on their desktop?” And, we looked at the stats, and as you can imagine not a very popular way to cruise around our site. So, we made the executive decision, sort of to keep the player in the state as long as it’s on desktop.

So, at this point we’re dealing with more than media queries, right? We’re sniffing for the actual device that’s being used. When we notice it’s a mobile device, we go ahead, in combination with that media query, and we will use the appropriate player for the size. The player was really a specific, sort of, from the ground-up rebuild of some technology that existed there that we had to make those tough calls on. We think it ended up working really well in our favor for making those calls. It’s not that it saved us development time, because we sort of had to go ahead and make those mistakes as we were trying it and then we made the calls, but it does give us, we think, the right answers in the end for how we should display this content.

Some of the things that I would do differently: First off would be setting more realistic expectations for everybody. From my perspective, it would be buying the team more time to be more careful.

Ethan:

One thing you said at the end there Robert, which is my favorite word, which is “mistakes.” So hypothetically, and I’m going ask both of you guys this—good job, you got the site launched, you are going to now start redesigning it today, responsive redesign again, what would you guys do differently from a process standpoint? What are some of the lessons you’ve learned, either from a product design side or from a visual side?

Robert:

I’ll take the first stab at it here. I think our perspectives will probably be different here. A lot of my job is dealing in interfacing with a lot of… trying to marry together the craftsmanship that we strive for in everything that we’re building. Because we came from a product shop and this is sort of in our blood, we really wanted to take our time balancing that with a lot of the business requirements for what was coming down the pipe for this larger entity, now SFX, and even more concretely for Beatport.

For me, some of the things that I would do differently: First off would be setting more realistic expectations for everybody and saying “Look, this is going to take a lot longer than you think it’s going to take” and winning some of those battles. I think that we could be more careful; I think you can always be more careful in your work. If we had more time to really hash these out with the entire team, like we had mentioned before—this was Nikki and I able to run out in front with a couple other people at Beatport but not really the people that built the app in the end. So, they were being handed this from us and I would like to go back and take more time with the team and say “Look guys, what do you think as a consensus across the board as this breaks down? Is this the right decision?” If we had done that in the first place, then the mistake that I just mentioned prior would have come up in those discussions and we could have made that decision if the main front end developer were involved. From my perspective, it would be buying the team more time to be more careful.

As we’ve launched this beta now, I think we’ve done just that. So going forward, we hope to work in this new world where we’re not beholden to some pretty aggressive timeline that’s being decided mainly for business purposes.

Nikki:

For me, to go off of what Robert said, how he and I ran ahead of the rest of the team, we kind of got started a few months beforehand with designs and thinking around this product, and I wish that our team was formed right from the beginning. Like you said, we have this awesome Javascript developer who would just solve all of our problems for us and to have been able to work with him from the very beginning and get his opinion on things. Because for the player, for example, we designed that with this pie-in-the-sky attitude, like “What is the best experience on each device for the user? What is the best user experience?” We reshuffled around a lot of data and it had a lot of crazy stuff in there. We were just like “We’ll fix it later if this design doesn’t work. If we talk to the Javascript guy later and he decides that this doesn’t work, we’ll fix it later.”

We ran into problems and we made some mistakes, and we were able to fix it all in the end—but I just wonder what it would have been like if he was there to give his opinion beforehand. Maybe that process would have gone a lot more smoother and he could have told us right from the beginning what’s going to be impossible or very difficult to do.

Once development started in earnest and we could get it into some comps, to be able to code them out actually, where we could make changes pretty quickly, we’d have across the board design reviews, that people would come in and everybody would call in.

Karen:

How did you get approval for this product from the broader organization within Beatport or SFX? Did you show working prototypes? How did you do reviews?

Robert:

Depending on who you might ask, we took a better-to-ask-forgiveness-than-permission perspective at some points. But that’s not really, in the end, how it all worked. We tried to keep as many people informed about our process and what we wanted. And then where we needed approvals, we sought those people out pretty early on in the process.

This, for us, was more of a challenge because we were marrying two companies. SFX, as a whole, is a very large company but it was run, at this time, a bit like a startup, so everybody’s hair was on fire all the time and it was hard to remember all the people that needed to be in what conversations.

From the very beginning, we decided pretty early on that we were going to—even in the design phase—what we were going to do, and we did this for quite awhile, was as soon as we were done with our process of whiteboarding, wireframing, and then eventually getting it to comps, before we brought it all into code we wanted to get signoff from the right people. So we created shared Google Drives that we could pass out to a list of people along with a status update, saying “This is what is intended for this feature.” We included with those documents that the eventual developers could use to know exactly what was expected of that feature and, as well, we would outline some of the things that we were looking for from an analytics perspective. Like, “This click needs to be tracked for this reason” and stuff like that. A lot of work went upfront into creating those documents that we could just share out. That was one way that we attacked stakeholder buy-in and that worked pretty well.

The design reviews were extremely helpful for me. Being able to go to these other teams within the company that are working on other Beatport products and show them where we’re at and getting their opinion just really brings me out of that bubble. I’m really thankful for all of the design reviews we had throughout the Beatport company.

From there, once development started in earnest, we had pretty regular design reviews. The way we’re set up is that we are the Pro team, there’s another team here working on what’s coming out next for Beatport from a fan experience, there’s other offerings. We’re broken down basically by different products. They’re all under the Beatport banner but the teams are set up that way. What we would do across the board once development started in earnest and we could get it into some comps, to be able to code them out actually, where we could make changes pretty quickly, we’d have across the board design reviews, that people would come in and everybody would call in. Once you do that across an organization the size that we were, we were finding designers in places that we didn’t even know we had. We were getting their thoughts in there too, and so it was really a great feedback loop to be able to get into these large, expansive design reviews, that once we were in HTML and CSS, we could iterate pretty quickly on. That was a big part of getting through the process as well.

Nikki:

The design reviews were extremely helpful for me because I am pretty much the lead and sole designer on this project. I go to Robert with questions and opinions and he approves all my work in the end, but otherwise I’m pretty much the sole designer, so being able to go to these other teams within the company that are working on other Beatport products and show them where we’re at and getting their opinion just really brings me out of that bubble and lets me see my work from someone else’s perspective and gives a lot of great ideas. I’m really thankful for all of the design reviews we had throughout the Beatport company.

Robert:

I can probably add a little bit of light to that. One of the ways it would help us were things like: if you go to the desktop version of our site, the main banners that scroll, those big hero images, we sort of duplicate those in the background and blur them out and they give us a really great effect. We had that in the original comps in Photoshop, going all the way down to the smallest sizes. Through some feedback that we got in those sessions, we were noticing a lot of performance problems on mobile devices and things, and so people were making suggestions like “Why don’t you just drop this in the mobile versions?” That sort of increased—which we weren’t even thinking about, was coming from that area, it was a great suggestion. Something small like that, it was caught pretty early on by that process that we had set up, so we really appreciated that.

Nikki:

I think the slide outs actually came from a design review. On the mobile view, if you click on a track or something, there’s the ellipsis icon, where you click it and you get the play, you get the add to queue and you get the buy button. Originally, we tried to squeeze all those buttons into one flat view and somebody said “Why don’t you just add one slide out button and stick them all into a shelf? It will really clean up the visuals there and still give everyone the functionality that they need on the smaller screen sizes.” That was a great idea that came out of one of those design review meetings.

We don’t necessarily have revenue goals specifically from a mobile experience. I think instead what we’re looking for is in our feedback—and we do go out to a lot of DJs and festivals and shows to get feedback on this stuff—is that this workflow is actually be used.

Karen:

Can you talk about how you will measure the performance or the success of this responsive redesign? I’m really interested in how do you compare whether this works as a responsive product against how it worked when it was just desktop only.

Robert:

Yeah, I think that’s a great question. The way we’ve always decided whether the site is successful or not up until this point for Beatport has been obvious revenue things. It’s an e-commerce store, we’re selling tracks, so it’s easy to say “If we put in a feature and the revenue goes up, then yeah, that’s success.” That’s not necessarily true in our mobile experience and I’ll give you the reason why. What we do when we sell a track is make it available for the person who bought it to download it, and we also do something that a lot of other places don’t do, which is we offer lossless quality music. This is one of the reasons I think a lot of people come back to Beatport. Well, those files are really, really large and the workflow that a DJ establishes is mostly desktop-based. So, on a mobile device, there’s really no reason to be able to download a lossless track because it’s just too big for the limited amount of storage that you’re going to get on that, and then there’s not too much you can do with it from that point. And so we took a look at that and said “Well, you don’t really need to be able to complete the checkout on the mobile device. What you need to be able to do is basically add to your cart so that you can complete that when you get back to your desktop, which is where the users are used to being.”

We don’t necessarily have revenue goals specifically from a mobile experience. I think instead what we’re looking for is in our feedback—and we do go out to a lot of DJs and festivals and shows to get feedback on this stuff—is that this workflow is actually be used. For our initial milestones for what we’re looking for is the usage of the site on those devices, really. It’s as simple as that. If we start seeing those numbers skyrocket, we know that they’re at least doing something on mobile and that’s success to us.

In the future, we would want them, once we’ve defined what a good workflow would be for the DJ based on the DJ’s feedback, we would want to start tracking those sorts of clicks and seeing them move around in that manner, adding a lot of things to their playlist, previewing from their playlist, or letting it play just right through all the songs, or adding to their cart and then seeing that fulfillment later on desktop. Those sort of become our milestones for success with the mobile site.

But for right now, it’s really about adoption and seeing some of the numbers from what we would normally see. Like there was really no mobile experience to be had, so people would hit it and then leave and now we want to see some engagement and users staying on the site. I think if we see that for those devices, then we’ll know that we’ve had that first little bit of success.

Ethan:

Nikki, Robert, I just want to say thanks so much for both of us. We really appreciate you guys chatting with us about Beatport and we can’t wait to see where it goes next.

Robert:

Great, thank you so much.

Nikki:

Thank you.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan:

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Karen:

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Ethan:

Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.