UI Sixteen

User Interface 16 The UX & Design Conference


Retro radio

UI16 Media Library


Bill Scott portrait

UI Across Platforms: Q&A with Bill Scott

By Bill Scott | Originally published: February 18th, 2011

The number of places that you can access the web grows every day. People can see your content on TVs, tablets and mobile phones as well as the more traditional desktop and laptop. But are you designing for it? How do your users see it? And more importantly, how are they interacting with it? In this podcast, Bill joins Jared Spool and discusses the challenges and a few of the surprises that come with designing for multiple platforms.

Full Transcript

Bill Scott: Well, it’s director of UI engineering for the e-commerce team. And that’s all of the acquisition, marketing side of the house. It’s the team that’s responsible for bringing in all the members.

Jared: Got it. OK. Director of UI engineering for the e-commerce team.

Bill: Yes.

Jared: Got it. OK. So that’s what Bill is. Bill is director of UI engineering for the e-commerce team at Netflix. I knew I’d get it right eventually. And he is probably the world’s biggest expert when it comes to the deep, down, and dirty of getting interfaces to interact with us. And nobody really understands how to get those things better than Bill does, and so I’m glad that we have him at our upcoming Web App Masters Tour, and I’m glad that we have him here today to talk about these sorts of things. So, welcome, Bill.

Bill: I’m glad to be here, once again. It’s always great to chat.

Jared: Yeah. So, we got this event coming up, this Web App Masters Tour. And last year, when we were at the Web App Masters Tour, we hardly talked about anything other than a desktop browser. But now the world has changed on us. There are so many different ways that people can get to a web app other than just using a desktop browser. It’s incredible. You’re seeing that at Netflix, right? I mean, that’s changed the way you guys are thinking about design.

Bill: That’s right. As early as, well, 2008, we were talking about and trying a few experiments around the TV. 2009, we started an effort to port WebKit over to the PS3. In 2010, we actually launched a PS3 experience for Netflix, which would obviously show up on your TV, and by having WebKit as the underlying graphics engine. In essence, the application wrapper. The same time, we have an iPad app that we came out with last year, too. And obviously, those have the WebKit browser on the iPad and iPhone. But we released those as applications in the application store. In essence, the wrapper for those applications is WebKit.

I think one of the key things that’s given Netflix a lot of success in the user-experience arena is a manic devotion to testing. And that testing is both qualitative, you know, to understand kind of general approaches to take. And from that, we develop hypotheses about what might affect, whether, is less text better, more text better? Is it bigger box shots better? Is it better to have just a big gallery of box-shots content, or is it better to have navigation more upfront and center?

And you sort of develop these hypotheses, and then you test them with A/B testing by putting the experience out to different segments of our members, and getting back, based on certain metrics, consumption, video-watching hours, weekly, monthly, et cetera, to determine how successful a particular interface is. And with the PS3, we actually field 16 different tests at this point, for different experiences.

I think a key drive for this move has been, we’ll have about 400 SKUs, devices that we’re actually on this year. If you have to have everybody develop a unique interface, or we would have to develop all those unique interfaces, it would be a really, really expensive proposition for everybody.

So everybody has a desire to have a separate way to build applications. And the simplest way that we can build applications really is web technology. So, it all started, of course, on the desktops and laptops, but what we’ve seen is a migration now of the browser into these different devices.

Jared: And that was always the promise of the browser, right, or the promise of the web, I guess, is a better way to put it, is this idea that it would render independent of the platform that the user was sitting at, such that they would be able to experience something that looked right to them but, at the same time, didn’t have to be developed with 15 different code bases, like it did in the old days.

Bill: That’s right. And also, with an A/B-testing style environment, you want to be able to field a lot of experiences cheaply, iterate on them fast, and change your mind, just be as nimble as possible.

So imagine you have a device manufacturer, a consumer-electronics company, like LG or Panasonic or Samsung or whoever, Vizio, and the only way you can get a UI on that is to get it put in the firmware. And that’s been the scenario that’s been there if you’ve had any kind of UI at all. Which, we all know about those TV menus, you try to set your contrast and stuff. Those departments in the companies for user experience, those are probably not the largest part of the company. So to be able to deliver a dynamic user interface, we call it a DUI layer, in these devices was really critical to getting the Netflix web experience into mobile, TVs, of course, obviously our desktop and laptop. So that’s why we’ve invested heavily in that.

And I think what we’ll see in the future, I think it’s already clear from hearing from the device manufacturers, their idea would be to have WebKit, or some other technology, but WebKit seems to be the one leading out at this point, already there on the devices. So you would use that layer to build your applications. It wouldn’t just be Netflix. It’d be other experiences would live on there, right on top of that.

Jared: Now, one of the things that I’m seeing. I have an iPhone. I’m seeing things like the Twitter application, which has an API for their stuff, but then somebody tweets something with a link in it and it jumps to the browser. But you don’t actually go into another app on the iPhone; you stay in the Twitter application, and it seems to be running WebKit right there, in a frame that is obviously the Twitter app’s frame. And so, that idea of an embedded web experience inside of another application, that’s something that I think is also new on the scene now that adds another layer of needing to test.

Bill: Yeah, I think that was a huge innovation on the part of Apple, of course, going with the WebKit as being pretty much almost the OS, and allowing you to embed that WebKit Chrome within your application.

Now, most applications on the Apple store are native apps, written in Objective C and such. And we looked at going that route. Again, the reason we didn’t was because if we wanted to change our mind. For example, our iPad experience, out of the gate, was really more of kind of a tailored version of our website, wrapped in an iPad app. Didn’t take advantage of much of the experience of the iPad, right?

But now we’ve taken versions of our iPhone app, tweaked that, and we’re testing that right now on the iPad. So some users are seeing a totally different experience than what looks like the website. And we’ll see how that bears out. We’ll learn from that. We’re also learning from our TV experiences. And it just gives us a really quick way to iterate.

Jared: All of a sudden, when you’re using these browser-based things on these other devices, some of these devices don’t have mice. So now you have a different way of doing input, right? And you have to think about the differences that hit you. If you’re going from a desktop experience and you’re starting to think smart phone or something like that, what are the big things that jump out at you almost immediately that you have to take into account?

Bill: Well, the first thing is the input device. In the living room, left-right-up-down, or what we call LRUD, the remote, is pretty much king. Now, Google has tried, with the Google TV, to bring a keyboard into your lap on the sofa. This is just me personally. [laughs] I don’t really think that most people want a keyboard in their lap, be it small or large. Sony’s version is a real tiny keyboard.

Jared: Oh yeah, and it’s ergonomically really whack, too. It’s this rectangular thing. It feels like it’s the worst of all worlds.

Bill: Logitech has a nicer keyboard, but do I really want to try to keep track of that in my living room?

Jared: The remotes in my living room have lives of their own. They go out and party, and they don’t come home till late.

Bill: Logitech’s Harmony One, once I set it up and everything, has been our salvation for that, because it’s a single programmable remote. But when you start designing for a TV experience, you can’t say, "Well, you know what?" Because Google TV, for example, has a pointer, on a little trackpad, you can move the pointer around, you can click, and you can use the keyboard, and you could build a completely desktop/laptop kind of experience in the living room. The problem is, you can’t depend upon that because most people have the left-right-up-down.

Luke Wroblewski, as you know, he’ll be at the conference also, and others have started the "design for mobile first" which is really "design for constraints first" right? You take a more-constrained view of what you can do in the application, either through input or screen size, maybe you’re on the go or whatever, and it forces you to kind of think of the main things first. What’s the most important items or tasks, goals that the user has, and design for those.

So, with the living room, with the left-right-up-down, something’s always focused, and you’re always moving from one item to the other. But then, when you move to a pointer-based, nothing necessarily has focus. You could have things totally out of focus. You have kind of random access to things on the screen; you can get to something quicker. With left-right-up-down, your keyboard is usually virtual, on the screen, on-screen keyboards, and those, I think, still need a lot of work. We’re doing some A/B testing in April on some different on-screen keyboards to see what’s the right layout, especially the sign-up flow.

And then when you move to mobile and tablet, your input becomes more of the finger, more of your thumbs, swiping gestures. And then when you get back to the laptop, of course, you have the mouse and the keyboard. Mouse really is both a blessing and a curse, because it’s an indirect method. You can move it around just on either the trackpad or the mouse on your mouse pad. But you’ve got scrollbars, and scrollbars are really an indirect way to scroll. They’re not as direct, not as physical as flicking your finger.

So, all this leads to that end of the screen. I mean, if I’m sitting across the living room, say 10, 15 feet away, a television, what kind of text can I read on it? You have to think about how you design the text. Then the mobile, the screen’s small but it’s right there in front of you. And then the laptop, which you’ve got real high resolution. So you’ve got this output, the screen changes a lot.

And even the navigation. I mean, when I’m sitting in a living room, and I’m especially browsing for media content, I tend to be in a little bit lazier mode. I want things to kind of show up for me. I don’t want to have to work real hard to find something. If I’m on a desktop and I’m doing some research or something, I’m may be willing to click a lot, maybe type a lot, because I’m writing a paper. So, the navigation, and then just your whole posture, changes.

I think of input, screen navigation, and the posture of the person, not just the physical posture but their mental posture, as they start to use the application in those different scenarios.

Jared: So, being that you’re at Netflix, you are, of course, focused on things like movies and television shows, because that’s what Netflix is in the business of these days. By the way, congratulations on your amazing quarterly results.

Bill: Yes, thank you. It was awesome.

Jared: I know that it was because you came back.

Bill: [laughs] Yeah, right. [laughs] We have a lot of people. [laughs]

Jared: So you’re focusing on that. But a lot of what’s on the web today isn’t those types of movies and videos. Is there a way to know, do you think, what content needs to think about the TV, versus think about the tablet, versus think about the phone? How do you think folks should decide which of these different devices now they want to actually try to design for first?

Bill: I think it really gets down to understanding what the main reason people use your application and what those couple of key scenarios are. For example, if you’re something like Yelp, on the website you’re going to have a lot of features that support writing reviews and searching and a whole bunch of things like that. But if you get down to like just the iPad app, the new Yelp iPad app is actually pretty nice, because it gives you list and map view in one screen. So it picks up your current location. So, taking advantage of geolocation on the device is really important because it’s really a location-based service. You can just get rid of a whole bunch of other noise and search and everything else.

I was actually using the iPhone version on the iPad for a while. For some reason, it would never update till I deleted the Yelp app and then reinstalled the iPad app, and I was like, "Wow." I discovered there’s this one road I was going down all the time, and I’d used Yelp’s iPhone app, and I never found these two or three restaurants. But as soon as I used the iPad app, they jumped out at me because, as I’m driving, the blue dot’s showing and I’m seeing what’s intersecting with me at that moment. And I see, "There’s a great Mediterranean place. There’s a great Chinese place" and I tried both of them and they were huge hits for my wife and I.

And so it’s just amazing. Of course, in that case, the iPad has a little bit more real estate to do some more width, versus the iPhone with a small screen.

And I think the key is, most companies deal with this. They deal with, "I’ve got a more full-featured experience on the browser, on the web, the desktop or laptop. But then I’ve got an on-the-go kind of version." And so the decision has to be, how much do you need an on-the-go? Is your on-the-go more of a brochureware, or is it actually going to take advantage of those unique characteristics of being on the go, like geolocation services and stuff like that? And that’s going to decide it.

And then you have to just kind of pick what’s the most important thing to call out. And the best idea in that is to start as simple as possible and then build up from it. A lot of companies make the mistake of trying to move most of what they have onto the iPhone, or mobile experience, doesn’t have to be iPhone, it could be Android or whatever, and they end up with a lot of menus. And then, with a small screen like that, you have to go up and down, do a lot of pogo-sticking.

Jared: Right. Right. And Luke even is talking about, don’t bother with your first version being a native app to the device. Make your first version a pared-down browser experience, figure out what you need, and then go from there and figure out, "OK, what do we need to have as a browser element?"

Bill: Little side note, but one of the things at Netflix I discovered a few years ago--it was like an epiphany; one day I woke up and realized this, was that, especially the UI layer, we throw away about 95 percent of our code and keep about five percent. And that’s the UI layer. There’s obviously a lot underneath that we don’t throw away. And that sort of changes the way you think about investing in your experience. You don’t want to over-engineer it. You want to be as lightweight as possible and as cheap as possible. When you find something works, you commit more to it. And if that means that building a native application is going to give you the edge, you would do that, right? I totally agree with that.

Jared: Along these lines, so you’re working now in the e-commerce group. As I understand it, a lot of what your responsibility is is that sort of "convincing people to sign up" stuff. So a lot of the people who are seeing your designs are actually people who aren’t yet Netflix customers. Do I get that right?

Bill: That’s correct, the sensitivity of the sign-up flow. And that’s both on the website, obviously, but also on device, which is where we’re focusing more and more of our attentions on device.

Jared: Well, that was my question. So now you guys have it so that people can sign up for Netflix from their PS3 or from the iPad. That’s right?

Bill: That’s correct. The iPad really hits the website at this point. But the PS3 and a number of devices, about a dozen digital TVs and Blu-ray players and such, will have our web-delivered sign-up flow on them in the next couple of months, yes.

Jared: That’s really interesting to me, right? Because everything I’ve seen on the TV up until this point has been, you already have an account, you just put in your user ID and your password, it connects you up, and then it just feeds you, like my Netflix on my TiVo, it just feeds me the things that are already in my queue. And if actually want to add something to the queue, I have to open up my laptop and add it to the queue that way. It sounds like you guys are pushing more and more control to that device.

Bill: That’s exactly right. When we first started, if you look way back when we first started with Roku, all you could do was look at your queue. You could just flip through your queue and decide to play something. That was it.

Jared: Right. And so if it wasn’t in your queue and you wanted to watch it, you had to bring up another device to put it in the queue.

Bill: That’s the whole idea of starting as simple as possible. What’s the simplest thing we can do to get the movie-watching experience to you? Because that’s the main thing people want to do is watch something, and not getting lost in, "We can’t come out with something unless we have all these cool features." Then it progressed to where we developed an API that we call LOLOMO, which is "list of list of movies."

Jared: [laughs]

Bill: Yeah, we like that one. And we’re thinking of one on social called SOLOMO.

Jared: [laughs]

Bill: So the LOLOMO is for device manufacturers. They can actually access it through another set of APIs. But in essence, it brings down those recommendations: what was the most recently watched quirky, 18th-century period films or whatever? You get a personalized experience, but it’s just through these personalized lists.

And then, as you go further, you bring search on, because initially search wasn’t that useful because we had a smaller set of titles. As the titles have grown, we’ve gotten more and more playables, you can introduce search, and search is not a frustrating thing, right? Then you start adding more and more experiences. And the same thing with the sign-up. We would just tell people to go to the website, or we use like a code that you can type in.

And by switching to where you get this Blu-ray player, you plug it in, and, "Hey, are you a Netflix member?" "No, I’m not." And then just a few screens later, you’ve entered your most basic information and you’re signed up. And that’s been really successful, actually beyond our initial thought, how successful it’s been. We’re really just getting started with that.

Jared: As you’re doing this, are you discovering that some things are easier than you expected them to be, and some things that you thought would be easy are harder?

Bill: So there’s two answers to that question. On the member side, which is the team I had, including member and non-member before...we’ve now gotten so big we’ve broken the UI-engineering teams into several groups.

But the team I had before, when we first started that project around the member experience on PS3, the biggest challenge was around memory footprint. Because when you load the player in and the UI and all that, those devices don’t necessarily have a lot of memory, right? Being real cognizant of, on the code side, how you write things is really, really important.

So we all thought this one experience we creates, we actually christened the name Special, the interface was called Special, and it has a navigation on the left that comes up in the forefront when you’re on the nav menu, and then it goes down the background, and then the gallery of movies comes up on the right hand side when you’re in a menu.

So you still see your menu. It’s like this focus plus context principle, where you’re keeping some focus, but you have the context around how you got where you’re at. And so that we thought would be the successful one, and it’s done well.

But one of the other experiences one of the designers thought would be a hypothesis that’s simpler would just be better, was just to provide a, just those, those list of lists of movies, had them bleed off to the left and to the right where you could see them. There’s a wrapping around effect, so you feel like there’s a lot more movies. And then on the right hand side, you always see the movie information of whichever one you’re focused on, if you’re left right, up, down, on top of.

It doesn’t feel like there’s any depth to it. What happens is you just see this gallery of movies. You see all the detailed information on the right panel, kind of a slide out panel. And if you click on one, another little panel slides out from that right hand side just underneath it that lets you start watching a preview of it, and you can move right into play mode. So, that actually has done a lot better, or a good bit better, I should say, than the one we thought would be more successful.

We keep seeing this all the time, in our environment, simpler usually is better. So that surprised us. On the sign up arena, I think it’s pretty much what you’d expect to have happen, is that every tiny thing that you introduce in the sign up flow usually has a negative effect on conversion.

Jared: Oh, really?

Bill: So there’s a balance between, you have to give enough choices to make sure people aren’t confused, and enough information to make sure they’re not confused. But you can’t give too much because if you do, then people get exhausted in the process or get distracted and they don’t sign up. I’m sure you’ve seen that a lot in your testing.

Jared: Oh yeah, for sure.

Bill: And so we’re testing certain bits of information, pages of information we may not need. when you go from DVD model, where you have to have a physical address, to a streaming model, you may not even have to have an address, right? Just an email and password. And those are things we’re testing to see how they affect the sign up flow.

Jared: Now, one of the things that you and I were talking about on my last trip out to Netflix was how you guys were using Hack Days to actually come up with some of your novel ideas. Can you say a little bit about what the history of the Hack Day is, and some of the things it’s brought, and how you guys have been using it?

Bill: A number of us came from Yahoo! a few years ago and Yahoo! had developed a good hack culture and had their Yahoo! Hack Day. They even had an external one at some point. I know Facebook and Google have similar kind of days now.

But the idea was basically, take 24 hours, usually it would start Thursday at noon, go to Friday at noon. And teams get together and they come up with things they thought of through the year that we don’t ever get a chance to try out, that we’d like to cobble some technologies together and see...

We’ve done things with full control of the experience from an iPhone as a remote. Some teams met about a year ago, we looked at productizing those kinds of things. But it may not be something we’d actually do, but it certainly innovates. There’s been a bunch of experiences that have shown up on the site and even on the TV based on what people have tried in that 24 hour period.

You’re usually building something that’s mostly functioning. We’ve recently opened it up a little bit wider, a section where people present ideas. And we try to lean heavily on the idea of something working is better than just something shown.

It’s good because it’s an outlet. It gives people a chance to showcase what they’re thinking. You walk away from it with a whole bunch more ideas in your head to try out. Every Hack Day leads to a few ideas that end up on the site.

Jared: Well it sounds to me like it’s also a fun, morale builder. And it’s better than just going out to an amusement park, in terms of actually staying within the domain of what you’re trying to do for work. But at the same time, it has a lot of those attributes of a team building activity.

Bill: That’s right.

Jared: I’ve always been intrigued by that, because organizations that have these Hack Day things seem to have some real innovative elements to what they end up doing, that bleed through. Even if you don’t use something, the way it was implemented in that 24 hour period, it becomes this nascent that sits in the back of people’s minds, and people say, "Hey, what if we did that thing we were playing with during Hack Day?"

Bill: That’s right.

Jared: Well, cool. So, at the Web App Masters tour, can you give people a little bit of preview as to what you’re thinking you’re going to be talking about?

Bill: Yeah. So I’ll start off with discussing a little bit about what we’ve gone through at Netflix, just a couple slides I’m showing, examples of some of the experiences we’ve been working with and trying it, high level results from those.

And I’m going to talk about the... what I mentioned earlier, about the differences of when you have a web application or website showing up in different devices, different modes. I’ll talk designing for mice and men. The play there is is basically, indirect interface is like mice and track pads versus more direct, using your fingers, using your limbs, waving your hand or whatever, flicking stuff on a tablet.

The thing I think that’s apparent to me as I looked at experiences, as I moved to different devices, is that underlying design principles, it’s not a surprise, haven’t changed. I mean, the design principles that Theresa and I put in our book, "Designing Web Interfaces" which is more focused on web applications and websites, rich ones, they weren’t new design principles. We didn’t invent those. Tognazzini and others and you have been talking about them for years.

So it’s not a surprise that some of the same ones, like for example, the physicality of the interface. That’s something that you really see as we move to more of gesture based devices, versus the mouse. In fact, my granddaughter was in, she’s three, and she loves the iPad, she calls it the oppod. And she likes playing something called SpinArt, which she calls Spinheart.

It’s like a Spirograph, the disc can spin, and you pick up a piece of paint and you click on it with your finger and you put your finger down on the wheel and it makes the paint whirl around on the drum. First day she got here, she was playing with it and she was so excited.

And there’s a bug in the software that if you clicked just a little bit off one of those color swatches and just, in between, it wouldn’t actually set the color, even though it looked like it did. And so she came to me and just had this concerned look on her face and she had her little finger pointing out in front of her face and she says, "It’s out of purple."

Jared: [laughs]

Bill: It’s just like, "Wow." [laughs] Talking about physicality. And the next thing she wanted, she wanted some markers so she could draw on the iPad. [laughs]

So that’s a great example of just of the magic of the interface, the illusion of the experience. Physicality, we’ll talk about that as a principle, and we’ll look at the ways its working and not working. We’ll look at where, like for example, the Kindle on the iPad breaks the metaphoric pages. It didn’t have page numbers, it has locations, whereas iBook has pages. Then you get into the calendar. On the iPad you try and flip it, but you can’t flip it, you have to use the scrub bar and... we’re going to show some examples there of that.

And then the other principle is just keeping a good flow, and that’s what we talked about before in our other talks. But making the main thing the main thing, and not interrupting or causing the person to pogo stick around a lot to do what they want to do, the main task, are quick and easy and straightforward. Twitter’s a great example. On the iPad, and the way I’ve been, even on the Mac app for keeping it really simple and keeping it right in front of your face, a one page metaphor.

And then the third principle and the last principle, we talk about being responsive. That’s choosing animations correctly and interactivity reinforcing the experience, making a lively interface. We’ll talk about those three design principles, and we’ll look at them across the spectrum of web browsers on the desktop, mobile and tablet, as well as TV where appropriate. And we’ll probably touch on a few pitfalls or anti-patterns. I think that’ll round up a good hour of discussion.

Jared: Well that’s awesome. I’m looking forward to that. The Web App Masters tour is going to come up this spring and we’re going to be in Philadelphia, Seattle, Minneapolis, and if I remember correctly, you’re going to be there at most of those, right?

Bill: I’m going to be at all the ones planned so far, that’s right.

Jared: Absolutely fabulous, that’s great. And we’ll be happy to see you there. Well I want to thank you for taking this time to talk to us today.

Bill: I am glad to always do it, and I can’t wait to be on the tour with you.

Jared: I can’t wait till you’re there, either. It’ll be a lot of fun. So we will see you at that, and I want to thank our audience today for listening in and hearing all the great things that Bill has to say. As usual, thank you all for encouraging our behavior. We’ll see you next time. Take care.

Download (16.7MB)