Speaker - Karen McGrane

Transcript

I’m kind of a high-minded idealist about the web. I think that the web is its own medium. It’s not print, it’s not magazines, it’s not TV, it’s not movies, it’s its own thing with its own value system, its own culture. I think that the fundamental nature of the web is its accessibility, and by that I don’t just mean, although I most certainly do mean, accessibility to people who have—you know, who are disabled or need special assistance with accessing the web. But beyond that I mean the web, writ large, is something that should be accessible and available to everybody. That it isn’t something that is fragmented or splintered for different people with different interests.

The W3C describes this as a philosophy as “One Web.” One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. Now, when you read this it sounds a little bit like responsive web design, doesn’t it? And I think in many ways today responsive web design is the latest skirmish in the battle for One Web. We should strive to deliver a single website that is accessible to as many different people as possible, on as many different devices as possible, and so it is available to the smallest screen or the spottiest web connection or accessing through a screen reader.

If you have one set of content that you are delivering on a single URL, you can maintain a single code base. It means that instead of fragmenting your efforts across a variety of different platforms and screen sizes, everybody is moving in the same direction and you get more value out of your initiatives. Sounds great, doesn’t it? OK, well, we’re done here, let’s go home.

Sadly, for reasons that we can all understand, this is never good enough. Livia Labate, who is the former director of UX for Marriott, says that when she would go into meetings talking about responsive design, she would always get into arguments with people who would say “I need more than a responsive site, I need it to be adaptive.”

This theme comes up a lot. I see a lot of people saying, basically, we need to go beyond responsive design and optimize our site for mobile users. Here we should go beyond responsive design and think context first. How do you do that? Well, you move beyond the responsive web to the adaptive web. This guy says we should go beyond responsive and adaptive design to something he calls adjustive web design. I don’t know what this guy is talking about. So the theme of all of these pieces, I will summarize: they say look at this borked responsive website. This website is broken. You should use adaptive.

Adaptive as a strategy is something that is akin to magic, you can wave your magic wand over your magically created adaptive website and it will automatically do what your users want it to do. So the purpose of this talk today is to clarify a little bit. I want to unpack for everybody, what do we mean when we talk about adaptive?

Unfortunately, when you really start unpacking all of the baggage that goes into essentially what is magical thinking—essentially it is! People, when they bring up adaptive in a meeting, what they essentially mean is “I want something that goes beyond responsive design but I don’t really know how it’s going to work.”

So let’s talk about how people think about publishing information across all devices. Responsive design is one approach, adaptive design is one approach and then the third, everybody’s favorite, is the separate mobile website, also known as the m-dot. Let me just introduce what these things are, just to make sure we’re on the same page.

Responsive web design is fluid grids, flexible images and media queries. Those are the necessary and sufficient things for a design to be considered responsive. Note that this definition doesn’t say anything about the content that you’re serving, doesn’t say anything about the about the information that you’re serving. It just says that you are using these three techniques in order to ensure that your design can flex on a variety of different screen sizes.

An m-dot, often what an m-dot serves is a paltry subset of the content and features that are available on the real website. I think one of the main challenges with an m-dot strategy is because you are serving things on a subdomain, you don’t necessarily get to decide who is going to visit your m-dot site. You’re dealing with multiple competing URLs and it makes your management processes much more difficult.

Okay, so we basically have our arms around what responsive is, we can wrap our heads around what m-dot means, what the heck does adaptive mean? I like to break it down into two things.

The first is adaptive layouts. You may be serving device-specific layouts for a particular page or a particular feature. Usually this is going to require you to serve different HTML to these users. Beyond that is what I like to call adaptive content. Adaptive content, what I like to call it is structured content stored at a finer grain of granularity. You’re getting it down to a more granular bit of information. It’s content that can be targeted. You may wish to target it by device type or you may wish to personalize the content. That’s kind of a mouthful, isn’t it? So let’s just sum that up briefly by saying what adaptive means is that you want to serve something different. Rather than embracing the One Web ethos, you are serving different information to users.

So let’s talk about how you do that. In our model of responsive and adaptive and m-dots, the first question is: Are you using the same URL? With responsive design you’re using one URL, everything is going to that one domain. With an adaptive solution, you are dynamically serving information, different information, different HTML into that same URL. Google likes to refer to this as dynamic serving. What this basically means is you get the server involved.

Responsive design is client side, which means that the entire page is delivered to the device, the browser, the client, and then the browser changes the way that the page appears in relation to the dimensions of the browser window. Adaptive design is server side, which means that before the page is even delivered, the server detects the attributes of the device and loads a version of the page that is optimized for its dimensions or native features or some other characteristics. This article comes from the Huffington Post, which is my primary source of information about web design.

I will mention here because I think this is important, when I talk about the domain strategy, responsive design is Google’s recommended approach for building mobile websites. I want to make this clear. Google does not penalize sites that use other methods. If you are using dynamic serving or an m-dot, they will not penalize you in the mobile search rankings. But I think it’s worth noting that there is no organization on the planet that is probably more invested in the idea that you serve one set of content into one single URL than Google is.

That’s how responsive and adaptive work from a URL standpoint. The next thing to do look at is: Are you serving the same HTML to everybody? I bet you can guess what responsive means. What’s different is in adaptive you do not, you serve different HTML. Obviously in an m-dot situation that’s what you’d do as well.

With both an adaptive solution and with an m-dot solution, these sit firmly—or perhaps shakily—on a foundation that is called device detection. Many organizations maintain third party libraries that are proprietary, and many people in the web design and development space consider this to be risky. Without delving too deep, I want to spend a few minutes explaining why someone might wish to do this.

One thing they might wish to do is serve a different page. I worked with a university client this past year, and they had just built themselves a brand new desktop-only website. They hired me to come in, and said, “Can you consult with us about what we should do now on mobile?” I said, “Uhhh... you should build a time machine? And go back in time, and not have done that?” That proved infeasible. So my Plan B was I told them that they should do a responsive retrofit. I said, “Go in and re-code the front end of your website. You can take your fresh new desktop-only design and rearrange it a little bit and make it responsive.” When I made this recommendation, this chill came over the room and they were just like ... “Never gonna happen, don’t even talk to us about this.” And I’m like why, what’s going on? I’m like, dragging the browser window closed. And they were like, “Karen, you obviously don’t understand how political our home page is.” I said, well try me, okay? And they said, “Well, if we go responsive, can we serve a different home page?” And I’m like, of course you can. What do you think, Ethan Marcotte is going to come over to your house in the middle of the night to yell at you for being a traitor to the cause?

If the only thing that is stopping you from going responsive for the 90 bajillion other pages on your website is that you think you want to serve a different home page, so you can more precisely control the layout on that screen, sure, by all means! Let’s get started!

I don’t want to make this seem like it’s a total copout. No less than Chris Coyier, he writes CSS Tricks, he has written about the decisions they made where they mixed responsive designs with separate templates on his product CodePen. He said in many situations they had pages where it made perfect sense to handle them responsively. But rather than trying to ninja their way through all of these templates, he said in some cases they decided to incur the greater maintenance burden of managing two different versions of the page, and getting the server involved, but they’re doing that on a very, very specific case-by-case basis.

Couple weeks ago, I got into a fight on the internet with this guy. Because I read a lot of these articles that are like, “Responsive design is terrible, you should use adaptive.” He wrote one that was like 90% “Look at this layout, it’s kind of borked.” His argument was that, for marketers who are managing campaigns that they actually do want to target to mobile users—like they genuinely believe that they are trying to attract a mobile user—they would want to manage that as literally a separate page because it will make their A/B testing easier. To try to manage a page like that responsively would just make that page too complex, and they would be better off simply serving those as separate pages. And I’m like okay, I’m reasonable.

But in many cases it’s not even that you need to serve something differently, even at the level of a full page. You might even want to do it specifically at the level of a very granular feature. Fidelity, for example, said that they ran into some problems with—can you guess what it is? It’s tables. They said that they had a large complex table, and there was an industry-standard sort order to the way that the columns appear. As they were making decisions about what they should have shown in that table, they rearranged the order of the columns so that they would have the most important information be viewable on the smallest smartphone screen sizes. The problem they ran into is when those screens got larger, the column order was not right, they were misaligned. If they did it in the correct order, people on the smartphones were complaining and if they did it in the wrong order people on the desktop and the tablets were complaining. They don’t need to serve a different version of the whole page, it wasn’t a transaction flow, but rather than trying to maintain one single version of that table, they just cut their losses and made two versions, it was fine.

Beatport is almost like, the Billboard charts for DJs and electronic dance music. When they were coming up with their responsive product they said, “We did everything with the app responsively except for the player.” They just ran into some challenges with the player, where it wanted to be different. They said it made sense for just that one little feature to try to handle it adaptively.

If Ethan Marcotte were here he’d say “Imma let you finish but we need to talk about conditional loading.” So conditional loading is a technique that can be used responsively. What developers can do is conditionally load that information, so at larger breakpoints, they can load in some information that hadn’t previously been loaded. And so here this just starts to get kind of confusing.. I would love it, if I could have a super-solid breakdown of: here’s what responsive is, it’s client side; here’s what adaptive is, it’s server side. I hate to tell you, sometimes adaptive solutions can be handled client-side.

Even worse! Sometimes they can use the same HTML. Responsive solutions are completely fluid, whereas adaptive layouts are device-specific. This means that they are aimed at particular device-specific breakpoints and they snap into place when the user gets there. This is an example from the Obama for America website from 2012, you can see this is an example of an adaptive layout, which snaps into place. In a responsive solution it’s completely fluid, like it automatically flexes. Whereas an adaptive solution will snap into place at particular breakpoints. What you are doing is all the same HTML, but rather than making something that is completely fluid on the client side, you are taking something that is designed for device-specific layouts.

Here’s somebody’s prototype for a modern design tool for adaptive layouts that has iPhone 5, iPhone 6, iPhone 6+ in portrait and landscape modes. And that sounds great if you’re designing native apps. But if you’re designing for the web and you are trying to manage through the literally hundreds—if not thousands—of different Android screen sizes that may appear, the idea that you might be able to target your layouts at device-specific sizes, it’s just not wise.

I had a conversation with Ethan Marcotte, and he said if you are trying to solve a problem that is literally, entirely, about screen layout, handle that fluidly on the client side. I don’t think that’s because he has a dog in that fight. I think it’s because he’s like, look, the best way for you to solve problems that are entirely based on the size and shape of the screen is to use responsive design to solve those problems—based on the size and the shape of the screen. If you can in any way possible avoid getting the server involved and avoid sending different HTML to solve something that you can handle fluidly on the client side, that’s what you want to do.

If that’s the problem with HTML, the next question is, are you serving the same content to everybody? I bet you can fill this out. In a responsive solution, you are sending yes, again the identical content to everybody. In an adaptive solution you are not, and in an m-dot you are not. And I think this is where the rubber hits the road. People who advocate for a One Web philosophy, who advocate for responsive design, are saying you are better off—in a vast majority of cases—simply sending the same information to everybody.

On the m-dot side the idea is that we would serve a completely different website tailored for the mobile user. I think we’ve won that battle. I think most people would agree that that’s not the right answer.

A lot of people are hanging a lot of expectations on the idea that they can use adaptive content to magically tailor the experience for users based on what they know about them from the device or from the content. When I explore my uneasiness on the subject I realize that I literally have only myself to blame. [laughter]

I’ve been talking about adaptive content for the last, I don’t know, three or four years now. The big case study that I think everybody has probably heard, that I’ve walked through many times, is this example from NPR that they call COPE: Create Once, Publish Everywhere. Now, I love this example, because in my mind it’s a fantastic analysis of why it is so important to store content at a more granular, more structured level. It’s the idea that our goal in this whole mobile revolution is to get people away from storing all of their content in wikis or giant WordPress fields or marking it up with with rich text editors, and instead embrace the notion that content must be structured, it must be stored in smaller, more granular chunks that are presentation-independent. I think this is a fantastic thing that we should all rally around. This example from NPR, where they show the same structured content being broken up in different ways, being delivered to a variety of different platforms. On the desktop they can say, “Oh, yeah, give me the title, and the audio file, and the body, and a large image.” And their player can say, “No, I don’t want that, just give me the title, and the summary, and the audio file.” The mobile website can say, “Yeah, yeah, give me a small image there.” An app can ask for something different. A desktop app can ask for something different still.

It’s sort of easy to see how this example has become the poster child for device-specific content targeting. And that is something that I have a real problem with. So the issue here is that—especially when we’re talking about the web—device-specific content targeting may set up organizations to maintain multiple websites that they simply cannot support.

Guess who just went responsive? Oh, it’s NPR. Patrick Cooper, who’s their director of product management, said “We had a phone website, and a tablet website, and a desktop website, and we really only maintained the desktop website because we didn’t have enough resources to cover all of those fronts. It just wasn’t a tenable situation.”

Now I do genuinely believe there are some situations out there where more granular content is necessary. Organizations have apps. I teach at the School of Visual Arts in Manhattan, where they have a website, they have a mobile app, and then they just bought all these screens, digital signage, that they want to put up all over campus. I think this is a great example. If you store all of this stuff in one giant blob of a WordPress field and your content authors were going in and marking everything up with headings or marking everything up with rich text, you wouldn’t be able to get at the information at a more granular level so that it could render appropriately on that digital sign. You would need something like the image and the overview and the title and the date, and the location, all of those things to be stored as separate fields, so that you can pull them out differently.

To me, when I talk about it, to me the real value there is in the granularity. It’s in the idea that here’s our chance for organizations to think about content modeling, to think about storing structured content, to think about how adding more metadata to their content can make it more flexible and more valuable for reuse.

Where I have seen adaptive content go, as people talk about it now, is that it’s really more about targeting. It is really more about the capabilities of marketers or other people to sidestep what they see as some of the limitations of responsive design and instead, start building websites that send different information to different people based on different criteria.

I’m going to tell you: basically everything that I know about the web is based on the fact that in my first job in the ’90s, I was in the only person in the office who knew how to do a mail merge. And I had to learn how to do it on WordPerfect for DOS. So you kids and your graphical user interfaces can suck it. [laughter]

When I talk about the glories of mail merge writ large, what are we trying to target content against? I think there’s basically three things. The first thing is, we want to tailor content to the device. The second is we want to tailor content to the context of the user. The third is we actually want to personalize that content.

Let me give you some examples. These are just a subset of examples out there. But if you wanted to tailor something to the device type, you might look at the OS. You might be able to target content by mobile, tablet, or desktop.

If you want to target by context—now I want to be real specific about my definition here. What I mean is: What information can you get from the device about the context or the environment that the user is in? That may be things like the time of day, the user’s location based on GPS, could be the velocity, the humidity, the temperature in the room. Variables that you can pull in from that device, known things.

The third thing is, if you wanted to personalize, you might be looking at things like the age of the user, the gender of the user, the lifestage, what language they speak, personal relationships. User specific. So it’s something that you know about that person as an individual.

Let’s talk about all of these. So when I talk about targeting by device, it sounds glorious, right? We’re going to be able to tailor the information or know what some device wants versus a target. Device-specific targeting is already being deployed today for things like serving more expensive hotels to users on Mac.

I want to say, I genuinely do believe that there is device-specific content that exists out there. For example, let’s say you’re AT&T, a mobile phone company in the U.S., you you’ve probably heard of them. If they want to go responsive, you might say OK, does that mean that AT&T is now doomed forever to only serve identical content? No, even I’m not that draconian. Why? Because the content is literally device-specific. I wouldn’t put it past AT&T to do this—but I think would be kind of dumb if I went to their support section and they said “What kind of phone do you have?”

But in most cases, I genuinely believe that the need for device-specific content, device-specific contextual rearrangement of things is genuinely overblown. Chris Balt, who’s a program manager from Microsoft, says “Our data shows us quite plainly and clearly that the behavior of people on mobile devices is really not all that different from the behavior of people on the desktop. The things they’re seeking to do and the tasks they are seeking to accomplish are really quite the same.”

I have heard this from company after company, as they moved beyond that sort of instinctive gut-level belief that people on smartphones and people on desktops must need and want different information presented in different ways at different times with different tasks. When they actually sit down and look at their data and look at their research, they find out that nope, basically people’s needs are pretty consistent. They’re not different people with different needs, they’re the same users, they just happen to have a different device in their hands.

And so I’m way less interested in device-specific targeting—literally to the device—than I am about what does it mean to target content by context. I gave this talk about a month ago and I outlined a variety of things that I might consider to be contextual variables. A woman contacted me afterwards and asked “Why is this context? Context is something like waiting in line.” I think that’s the rub with context. That we as designers, as content strategists, may wish to know the context in which a user is operating. But a device has no way of knowing that the user is standing in line. All they can know is data that they can pull in from that device. They can know the time of day, they can know the location, they can know the speed at which the device is moving, but all of those things must stand in as a proxy for the user’s context.

I have worn hearing aids for 40 years or so. I give Apple a huge amount of credit for their accessibility work. These things are amazing. What they do, is they have a set of “programs” that you can use to serve different audio pre-sets—like different audio programs in different environments. I have a restaurant program and an auditorium program. One of the things that they offer is a car program. How do you think they know whether the user is in a car or not? Well, they have a tool that enables them to automatically switch to the car program when the iPhone is traveling more than 10 miles an hour. That’s a beautiful example of using data that can be pulled in from the device as a proxy for context. But you can also sort of see how that tailoring for context is perhaps somewhat risky. I mean there may be other scenarios in which I might be going more than 10 miles an hour in which I’m not in a car. I could be riding a bicycle. I could be running faster than 10 miles an hour. I could be a human cannonball. Of those three, the human cannonball scenario is probably the most likely.

The example here is that you are using context, you are using some cue that you can know about the device and that tells you about the user’s context. So the most obvious one is location, right? And I think that location is a fantastic example—if you have something that is genuinely location-based, then why not use information that you can pull from the device in order to tailor the experience? This is an example of some location-based content tailoring using a product called Contentful. If you’re in the city of Leeds, why would you want to see editor’s picks or whatever, what you would want is to be able to pull data from the phone. If you pick a restaurant and that restaurant is closed by all means show another nearby restaurant.

But there are lots of other examples of things that you might want to use location-based targeting for. This is an example of a piece from the New York Times where they were writing about income inequality. Here’s why, this is coming from my desktop computer, this is not a mobile-only example. What they did is they used location data from a computer to say “We think it’s likely that you’re reading this article from Manhattan. Feel free to switch to another place.” Let’s be clear about this, this is a glorified mail merge. They have a big set of data and they have a whole bunch of different options that they are tailoring to you based on that one piece of data.

The obviousness, the logicalness of location targeting leads people to start thinking that they can use other things as a proxy for context. I think one of the biggest ones that I’ve seen people talk about all the time is the idea that users use their devices at different times of day. People are more likely to be using their mobile device while they’re commuting, and more likely to use their PC devices during the day, and more likely to use their tablet devices at night when they’re on their sofa. Now, in my mind, this is an extremely risky strategy, because you are relying on the device type to stand in as a proxy for something that you actually have a way better way of knowing—which is the time of day. Rather than thinking you would need to serve different websites to different users on different device types, why not say let’s serve the same website to everybody and then target our publishing processes to different times of day.

My advice here is don’t use device as a proxy for context. I really have to drive home the idea that no one should be making assumptions about the context of someone’s use, what they expect to want from something, simply based on the type of device that they are holding. You simply cannot know. And yet, alas, I assume that you’ll get all kinds of examples of people saying that this is the right way to approach it.

In an article that was not designed at all to make me furious, titled “Responsive Design is Failing Mobile UX,” this author offers a scenario where he says you’ll need to create a different experience depending on where the customer is in the path to purchase. So here’s a breakdown to each path. When they’re pre-store they’re probably going looking for coupons, offers, or recipes. When they’re in-store, they probably want coupons, reviews, or price comparisons. Post-store they probably want branded content. His assumptions are that you can use adaptive design based on the device that the user is using. You are intended to optimize the customer experience to the device. I think this is a really flawed way to think about the problem. If you need those sorts of contextual cues, you’re going to have to get them from some other data. If you want to know how to serve information differently based on the fact that the user is in-store, then why don’t you use the location-based data that you tells you the user is physically in the store?

Here’s the rub on this: Nobody wants it. Users, when asked to rate what they thought the most important criteria were for judging the success of a mobile brand, 91% of them—by far the largest group—said that “access to content any way they want it” was the most important variable. The second one, when users were asked if they wanted a “seamless experience across all of their devices” 83% of them said that was important—that number went up to 87% when users were surveyed who had both a smartphone and a tablet. The idea that users want you to try to guess what they want is simply flawed. It’s not something that you should try to do. You would be better off trying to serve the same website to everybody, serve the same information to everybody, and then only in the most limited scenarios layer something on top of that.

You might say “Yes, but Karen, there are genuinely local scenarios.” Like in the travel industry, truly people who are trying to book a hotel, who are sitting in their car and it’s raining, want a different experience than someone sitting at their desk. Scott Kelton Jones, VP of Global UX for Expedia, says “What we’ve discovered as we do our ethnography research, our lab studies, as we watch the mechanics of our sites from an analytics perspective: People make the same decisions regardless of the context.”

The amount of effort that I see organizations put into spinning their wheels, trying to guess, trying to tailor the experience to the context of the user, or the context of the device, does not pay off nearly as much as simply laying down a solid foundation of responsive design, where you serve the same stuff to everybody.

Scott Liewehr works at Digital Clarity Group—he is a lovely human being, but I have to pick on his blog post here. He said, “I have daughters who are 2 and 4 and 6 and I like to entertain them with my phone on Netflix when we are at a restaurant or in a car.” He ran into a problem, which is that then when he gets home, Netflix is serving him cartoon videos from Disney. What he asked was, “Couldn’t Netflix learn that when I’m back watching television in my man cave that I don’t want to watch The Little Mermaid?” When I look at this, he’s using this as an example for Netflix needing more contextual variables. I would like to say that this is a solved problem. If you can solve your problem using something as straightforward as user accounts, why would you imagine that you needed to back into it by evaluating some sort of inaccurate, potentially risky contextual cues?

So when I read a lot of this stuff what I tend to think of it is as a personalization fanfic. Companies are basically sitting around spitballing in conference rooms being like, “Wouldn’t it be cool if we could scrape people’s LinkedIn profiles and find out what sports teams they like and then we could serve up information based on what sports teams they like?” And I’m like, why don’t you just ask them?

I think there are scenarios, and many, many fine scenarios out there, where marketers can use some sorts of genuine personalization. When I visit overstock.com as a new user, they would have a set of marketing messages and various product promotions. I bought a blanket from overstock.com, and so when I come back as a logged-in user, they do some very subtle personalization. Because I bought a blanket they are now featuring more housewares-type products for me and while that’s perfectly appropriate, I’m not sure how successful it is. Just because I bought one blanket, that doesn’t mean my entire lifestyle now is blanket-centric, but it’s cool. Something like this makes sense, and I genuinely tend to believe all of the sensible people who are thinking about what they can do with adaptive content already have a clearcut scenario for how that’s going to work.

The problem is that now we’re starting to get into genuinely scary territory. Where for example, Google’s algorithm shows prestigious job ads to men but not to women. The Washington Post tells you “Here’s why that matters” in case you are the world’s greatest monster and can’t figure it out on your own. [laughter]

This is what happens. I mean this is what happens when algorithms start targeting information based on gender, right. The idea that this is something that a lot of people are going to start doing, and it’s going to get worse, really scares me. A new product called AdMobilize exists so that advertisers can “pay per face,” and to warm the hearts of demographers everywhere, AdBeacon is designed to track the age of customers, their gender, their emotion, and even their ethnicity. Can’t see any way that could go wrong. Maciej Ceglowski, the person who runs Pinboard, says “Race detection at points of sale is part of the bread and butter of my scary internet talks, so I’m glad someone actually went and built it.”

So as one of the web’s leading advocates for adaptive content, I feel like I really want to say, trying to guess what users want is extremely problematic. Okay? The idea that you can tailor the experience for customers based on some data that you have gleaned from their browsing behavior, or from the context of their device, or from the data that you can pull from their device—it’s one of those things that sounds real neat when you talk about it in a conference room and it’s one of those things that goes horribly awry when you do it in real life.

Microsoft realized that their products were getting bloated. Navigation systems were too complex, they had too much information. This may sound like some websites you’ve heard of. What they did was, they created these things called adaptive menus. They tried to guess which of the features people were more likely to want. To be clear, Microsoft had a ton of data about which features users were more likely to want. They had a lot of information about: these are the things that people use most frequently, and here are the things that people use less frequently. So these adaptive toolbars had a short form, and then a longer form that you could click into, expand it to get to the stuff that was less good. People hated these, okay? They were really hard to use because it was frustrating to scan a menu and run your mouse over all the other menus. It forced users to click too many times and they couldn’t make good decisions. This feature didn’t really get as much attention—it wasn’t really criticized nearly as much as you might think, probably because people were distracted by the fact that at the same time they launched a little feature called Clippy. Which, frankly, is the same kind of deal. The computer thinks that it knows better than the user what the user wants. It’s just so unlikely that that’s going to be true.

Even in scenarios where we think, we think we know what you’re going to like because you bought this bucket of KitKats so we’re really pretty sure that we have a variety of bucket-based products for you. [laughter]

Google. Okay, Google knows everything about me. Google literally knows everything there is to know about me. I travel a lot. I was just in Israel lately, and so what do you think is the first thing Google asks me? Google says “Do you want to switch to the Hebrew version of Google?” I’m like, Google, you know literally everything there is to know about me, you have my e-mail, you have my calendar, you have my search history. If there’s one thing I think you could state with confidence at this point, is that I have never ever shown even the slightest inclination to speak Hebrew. Every time I come to Canada, the maps switch over to the metric system, which is flattering but probably dangerous.

When we talk about this kind of genuine personalization, I think there’s this expectation that we’re going to have truly innovative one-to-one personalization. It’s going to be this really meaningful experience. And the reality is—I don’t know that it is. We just aren’t very good at this. These are things that we are actually only capable of doing in the simplest, most finest-grained, like—somebody bought blankets, so maybe you should go show her some more blankets. We are still at the “Dear First Name” level.

And yet when I go on the web today, I hear people advocating for adaptive solutions as if they are going to be this magical solution that’s going to solve everybody’s problems. I want to make it really clear, that even as somebody who thinks that adaptive content is a great thing—I sometimes say, if you only have 5% of cases where you genuinely have a solid, justifiable business reason for doing some adaptive solutions—then by all means I want to help you solve for those problems. But when you look at all of these different scenarios, all of these different use cases, all of these different examples that people talk about, different ways that they want to serve adaptive content, I want to remind everybody that the only thing, literally the only thing that we can know from a device reliably is the size of the browser window. That is it. And if Ethan were here, he would be like “and even that is a vale of tears, by the way.” The network connection speed, or my velocity example, all of those things are generally unreliable, inaccurate, risky proxies for what the user is actually doing. So I want to make it clear that even though I think adaptive content is a thing that we should be able to talk about, I still believe deep in my heart in the fundamental value of the “one web” concept.

I don’t want to sound too much like a high-minded idealist here, so I’ll quote Forrester in saying “Practically, one web reinforces the need for unified systems, processes, and teams that drive real world cost savings and digital business efficiency.

Lay down a solid foundation. Get your content cleaned up, have it make sense, figure out what’s most important to people, but serve the same information to everybody. If you get that in place, you are going to be better off 95% of the time. I see organizations waste a ton of time sitting around debating, “Well, maybe that won’t work, maybe they want something different in mobile, maybe we can tailor this experience somehow, maybe we examine take advantage of the capabilities of the device.” Stop it. Get the responsive design in place. Clean up the dreck on your website, serve the same stuff, and then when you are ready you can consider adaptive solutions.

The last thing I ever want to hear is people treating adaptive solutions as if they are going to be some magical panacea. Adaptive solutions aren’t magic. They aren’t even better. They are just a different set of problems that you’re signing yourself up for. If you can solve your problem on the client side, if you can solve your problem using responsive design, then start there. It’s going to be way easier for you to manage and maintain.

If you come back and say “I get it, Karen, but in this situation I genuinely need device-specific content,” accept that you’re going to do that in a very, very limited scenario.

The last thing is, I don’t want to hear anybody pitting adaptive and responsive against each other as if they are in some kind of competition, because they’re not. The fact that you may have identified a scenario or a case in which responsive design couldn’t or doesn’t solve for every problem that you might ever encounter on the mobile web is not a failure of the technique. We need every tool in our arsenal to try to deal with this crazy landscape. If you want to serve some adaptive content, it doesn’t mean that you’re not using responsive design. It means that those two things work together. Thank you.