Marshall McLuhan’s assertion that “the medium is the message” may not have stood the test of time entirely, but the one-time futurist would probably agree that the same app can feel different depending on where you encounter it.
Why are we thinking about this?
Evolver.fm reviewed Slacker’s web and mobile apps in May, likening the web page’s player to an old Winamp interface and criticizing the iPhone app for its non-linear progression. With its new iPad app, which we first saw in Las Vegas in January, Slacker abandoned its black-and-blue colors and archaic design for a sleeker, more fluid interface.
The nuts and bolts of the radio service haven’t changed, but on the iPad, Slacker is more conducive to exploration and discovery. Developers simply have different choices, options and limitations when constructing an app for a 3.5-inch smartphone than with a ten-inch tablet like an iPad, or a webpage.
With that in mind, Evolver.fm spoke with developers and product managers from four music app companies about their experiences developing for these various app platforms (edited for length and clarity):
Jonathan Sasse, senior vice president of marketing, Slacker
Our web application is an Ajax client, it’s very complex, and no tablet could run it effectively. We looked at this about a year ago holistically: “What does our experience look like 12-18 months down the road on a larger screen?” and started defining the prototype for our new web platform.
At about that time is when these ten-inch tablets were starting to surface — the iPad and Android tablets. We took into account that it was still a short-distance interface, unlike a TV. There was a lot more opportunity for putting information up along with navigation and controls, much like with a web site.
Tablets let us design for certain types of devices, rather than all these different browsers and all the limitations that various browsers have with HTML5. On a super-high level, what you’re seeing on these tablets is what Slacker will look like moving forward. It just so happens that we started on tablets rather than starting on the web.
Richard Slatter, general manager, We Are Hunted
I’m not sure I can directly compare designing We Are Hunted for web vs. Hunted for iPad since the Hunted idea started on the web and the iPad was not around when we launched. Any Hunted presence on iPad was always going to be a ‘transposition’ of the website to an iPad app.
There are possibly constraints on what you can do with music in an iOS app, given that Apple controls the store, and has pretty firm ideas about what they want in the store and what they don’t, compared to what you can do on the web, where things are more open. So to date we haven’t released a native Hunted iOS app, iPad or iPhone. Instead, we’ve built mobile optimized sites targeting each device.
Now, web vs iOS aside, here are just a few of the things we think about:
- An app should do one thing extremely well. The Hunted website was designed with this idea in mind, although when you scratch beneath the surface, the site provides a lot more functionality than the app versions do. With apps this definitely doesn’t work. (It doesn’t work on the web either but you still see lots of websites designed like this — too many features and functions, crammed in.)
- Single-purpose apps are quicker and easier to develop. You can get them out quicker, and it’s easier for users and commentators to get their head around what the head does. It’s simpler to use.
Demian Perry, senior product manager, NPR Mobile
HTML5 performance sucks, because most HTML5 solutions send the entire presentation layer to the device on every page request. That makes for a very slow page load and ugly performance when you’re hopping from page to page.
There are all kinds of ways that various HTML5 solutions have tried to work around this. JQuery touch loads multiple pages into the first page load, so you essentially are building in a single document structure. I just had coffee this morning with a company that’s looking at each individual device, and deciding which CSS [cascading style sheet] is appropriate for the device; everything else, they’re holding back. So they’re just sending over a really tight CSS feed. But you’re still sending over the presentation layer every time.
The great thing about native apps is that the presentation layer is built into the client, so when you download the app the first time, you’ve got it. From then on, you’re just getting these tiny content blocks. There are solutions that do that as well. The problem is the build process is really complicated, so it consumes a lot of developer time — more than building for iOS. It’s not 100-percent there.
Our main NPR iPad app has a different look altogether with different view controls and binaries and everything. We’re probably going to combine the binaries eventually, but we’ll never do the 2x. We’ll have different view controls. We don’t have a music tablet app right now (read our review of NPR Music’s iPhone app), but if we were to build one, we would probably put the same design effort into it that we put into our main app.
The technical limitations in both the iPhone and iPad are similar, though. There’s nothing new about the iPad. It was just kind of a bigger screen and a different design, but we didn’t consider doing an HTML5 implementation on the iPad for the same reasons that we didn’t do that for the iPhone. We just felt like it was not going to perform very well.
Jon Maples, head of product, Rhapsody
(Rhapsody does not yet offer a native iPad app. Maples plans to begin development “in the second half of this year.” Thus, our conversation focused on developing Rhapsody’s iPhone app.)
We wanted the iPhone app to be an outlet of the user experience within what our customers usually use. We thought of it as another hub of the client, so we built in a lot of features, thinking that our customers will need a queue and a rich catalog area and a bunch of stuff that didn’t get used in the app. In fact, these features actually frustrated and confused mobile users. Once we recognized that we had too much of Rhapsody in the app, we started to look at ways that we could change it to make it more friendly to those who listen to music on the go.
We started to come up with a number of concepts that would basically flatten the app and make it more useful at the top level. So we put an emphasis on browsing, and we figured out a way to create playback immediately through the browsing menus; that’s a big part of how we started this revamping.
We have plans to do this with all of our apps — we started with the iPhone because it’s our first app and it’s our most developed, and then we have the same plan for Android and Blackberry as well.
We all know that the tablet is the next level. We’ve been careful with developing a tablet app and have really focused on thinking its planning through — not just for use cases, but also the financial model behind it. Most people who have an iPad probably have an iPhone, so in terms of acquiring new customers, it’s probably not a significant driver.
We want to get a better understanding of how people are using these devices. One of the things we’ve done is really taken a look at where people use tablets, and how they’re using them. Tablets aren’t replacing your mobile device; they’re replacing your PC. You’re using it for web browsing and email, and then you’re using it for media.
We fall into the latter, and we think that people use iPads for media in two ways: for playing in a party mode, where you’d show the breadth of your catalog and incorporate some eye candy with it, but also as a companion to listening — a contextual mode for how people consume music. We have a strong editorial team with top-notch writers all over the world, and we want to showcase that, so we’ll probably build out a tablet app to feature both.
(Front page image courtesy of Flickr/independentman)