- So Karen McGrane has been working on the web, possibly longer than I have.
So we are talking quite a while.
And has had roles including the head of user experience in Razorfish in the United States. One of the iconic names of user experience and actually web and digital design.
She is synonymous in many ways with content strategy and has two amazing books at A Book Apart on content strategy including content for mobile.
I really recommend you to go and have a look at them if you haven't got a copy already.
She is here to close Response 2016.
So would you please welcome and thank for all her many contributions to the web over quite a few years now.
Karen McGrane.
- Thank you.
I'm kind of a high minded idealist about the web. I think that the Web is its own medium.
It is not print.
It is not television.
I believe that the values that define this medium, the values that make this medium great are its fluidity, its flexibility, its availability. The web can be accessed by people using screen readers or alternate input mechanisms.
The web can accessed by people on slow or fast connections. The web can be accessed using every type of device with a browser.
The web naturally works this way.
We don't need to splinter and fragment the web to get it to do this.
It naturally wants to do this.
Well as long as we don't break it.
The W3C sort of sums up this high minded philosophy by calling it One Web.
The W3C says that One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device that they are using.
Now when you read this, it sounds a little bit like responsive web design, doesn't it? I believe that today responsive web design is really just the latest skirmish in the battle for One Web.
It is sort of the latest take on how do we make the web available to everyone? With responsive design, you have a single set of content that you serve up against a single URL.
To do so means that instead of fragmenting your efforts across a variety of different platforms and screen sizes, you maintain a single code base. That means that your entire team can be working together, pulling in the same direction against the same release cycle.
Frankly, from my perspective, as a result you get more value from your initiatives.
This sounds amazing doesn't it? I mean why would you ever want to do anything else? Well sadly, if there is one thing that I have learned from my 20 years of web consulting, it is that nothing ever is this simple.
Livia Labate who was the former head of User experience from Marriott, she led a large scale responsive re-platforming of marriott.com said that she would often go into meetings with stakeholders and people would tell her, "I need more than a responsive site.
"I need it to be adaptive." And the problem is that nobody knows what that means, and yet today when you go around the web, there's all kinds of people telling us that we need to move beyond responsive design. We need to go beyond the responsive web and optimise our website for mobile users.
We should go beyond responsive design and discover context first.
We should go beyond responsive, to the adaptive web.
This guy says that we should move beyond responsive and adaptive to something he calls adjustive web design. I don't know what this guy is talking about. When you read these articles, what you will just basically glean is that adaptive is something akin to magic.
You will wave your magic wand over your automatically created website and it will magically do exactly whatever it is that your users want at that moment in time on that device.
In this talk today, I'd like to align three different perspectives on how we approach publishing on the mobile web.
Responsive design, perhaps you've heard of it. Adaptive solutions, let's try to figure out what those are.
And in contrast let's look at our old favourite, the M-DOT or the separate mobile website.
In the course of this talk today, I'm gonna outline a little bit of a model, different perspectives on what all this means, but just to get started, let me outline a few definitions so that everybody is on the same page. Now I know you all are here because you know what responsive web design is.
Responsive web design is fluid grids, flexible images, and media queries.
It enables you to maintain a single fluid website that will adapt to different devices.
An M-DOT site in contrast, as you realise, is a completely separate website.
Usually served out against its own sub-domain, often M.URL.COM, hence the moniker M-DOT, and the trouble with an M-DOT is that, well one problem, is that in most cases you are serving up only a paltry subset of the features or content that you imagine a mobile user is going to want.
By guessing what it is a mobile user is going to want, we have to make choices about which website we are serving to which devices. Another challenge that you run into with M-DOT is that it is far too likely that in the great guessing of which website goes to which device, that we will send the wrong information, the wrong services, the wrong layouts, to the wrong type of device.
A study last year by Radware looked at whether M-DOT sites, which types of sites were being served to larger Android devices, and they found that about 30% of the time, a larger format android device was served the M-DOT version of the website.
Even though, those devices like the Nexus 6 and the Galaxy Note had a very similar form factor to the iPad Mini, which only 6% of the devices were served. So trying to guess, which device we should send which website to is always going to be problematic. Okay we are all here.
We know that responsive is.
You can wrap your head around what an M-DOT is. What the heck is adaptive? I would like to offer a loose definition of adaptive, which is that it means that you are serving something different.
Serving up something different to the user or to the device based on a set of characteristics. Now I couldn't stand up here today without if you are talking about adaptive, without expressing what I think is probably one of the common definitions of adaptive.
It is that in a responsive framework, this site is completely fluid across all break points. Whereas adaptive is often used to mean a site that snaps into place, at particular device specific sizes in a responsive framework.
If you look at the boxes here, you will notice that they are completely fluid. The boxes fluidly expand across every screen size in between the break points.
If you look at this example of adaptive, it looks really choppy.
The reason that it looks so choppy is that those boxes stay in a fixed size and they snap into place.
Often when designers are thinking about adaptive designs, it is because they are imagining they are designing around device specific sizes. Here is a hypothetical layout tool.
An adaptive layout tool that contains pre-loaded canvases for iPhone 5, iPhone 6, iPhone 6 Plus in portrait and landscape.
Now this might be a fantastic solution if you are designing native apps only for the iOS infrastructure, but it is a terrible solution if you were trying to deal with the sheer diversity of screen sizes, form factors, orientations, in in-app browser windows that you will encounter on the real web.
Now I have to confess.
This definition of adaptive, the idea of creating fixed width sizes that snap into place at particular breakpoints is my least favourite definition of adaptive. If I could fiat one thing into place on the web today, it would be to stamp out to that use of the term adaptive.
We have burdened the word adaptive with far too many definitions and this one I might just replace it by calling it badly implemented responsive design or not completely fluid responsive design.
And the reason that I have troubles with this is, I'd like to call your attention back to what I think my definition of adaptive is, which is that it means you are serving something different to the user.
So let's look at the first characteristic that we want to keep in mind, if you are serving something different.
That is are you serving information into the same URL? With the responsive side obviously, you've got one website, one domain, easy to main. With an adaptive site, you do as well, which means that an adaptive solution you are sidestepping some of the more problematic issues with an M-DOT site.
Rather than maintaining a completely separate sub-domain to solve for some of the thorn of your problems with design or layout or content.
In an adaptive solution, you can dynamically serve information into the same URL.
Google even sometimes refers to this as dynamic survey.
Luke Wroblewski coined the term RESS, which stands for responsive and server something. I think that also is probably another term for adaptive. Responsive design is client side, which means that the whole page is delivered to the device browser, to the client, and the browser then changes how 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 optimised for its dimensions and native features.
I got this definition from the Huffington Post which is my most trusted source of news and information about the web.
Ethan loves it when I use this definition because honestly like who has got a better source to sites than the Huffington Post right? I think it is important to know.
When we are talking about, whether we are serving information into the same URL, that responsive design is Google's recommended approach for building mobile websites.
Now I want to be clear.
Google is not going to penalise you if you have a properly managed M-DOT site or if you use adaptive solutions or dynamic survey. Heck Google uses dynamic survey themselves for many of their products.
I would say if you have the time and the money and the developer resources of a Google, then I say go to town on adaptive solutions, but for the rest of us mere mortals that are concerned with SEO, I think it is really important to note that there is probably no organisation on the planet that is more invested in the idea that you will serve up a single website with a single set of content against a single domain than Google is.
It makes their job of searching and indexing the web that much easier if you use responsive design. Okay, so it is pretty clear.
We are serving up information into the same URL with an adaptive solution.
What might be different then when I say we are serving something different. Well the first thing might be that you want to serve different design.
With a responsive solution, obviously you've got a single set of code, a single design.
With an adaptive solution, you don't have to. And obviously with an M-DOT solution, you aren't serving the same design as well.
Under what circumstances might it make sense to use an adaptive solution to serve different information, through a different design than you would with a responsive solution.
One example might be in scenarios in which you wish to serve a different page. Last year I worked with a client, a large university client.
And they had just done a full scale, bottom-up soup to nuts, burnt to the ground and start from scratch, desktop only redesign of their website.
They hired me to come in and consult with them about what they should do now on mobile.
I did a little audit of their website and I came back and I said, "You should build a time machine, "and go back in time and not have done that." This proved infeasible.
I did a little review of the site and I came back and I recommended that they should do a responsive retrofit of the front-end. I said, "Why don't you go in, recode the front end, "you can you know drop in some media queries, "drop in some break points, and it is not going to "be a 100% perfect, but given that you just did "all of this work, it is probably going to be "the most efficient a solution for you "in the immediate term." When I made this recommendations in the meeting, it was like this chill came over the room.
You could just see people's body language get all hostile and they are like, "Mmm, No, no, that's never gonna work." I'm sitting there.
I'm like dragging the browser window close going, "No you could totally do this." Finally like after some time, one of their executives speaks up and he is like, "Karen you obviously don't understand how "political a university homepage is." I started laughing.
I was like, "Try me." He says, "Well if we go responsive, can we serve "a different homepage?" I'm like, "Of course you can. What do you think? "Ethan Marcotte comes over to your house "in the middle of the night and yells at you "for being a traitor to the cause." I mean if literally the only thing stopping you from making the other 11 D bazillion pages on your website responsive is that, you don't want to deal with a stakeholder battles that you would have to have and like swishing down and rearranging your homepage, then by all means like cut a different version of your homepage and we will all go out for an early lunch.
This is like the easiest consulting job I've had all year.
I don't even want to make this sound like it is like a total copout.
No less than Chris Coyier of CSS-Tricks, Chris Coyier, he of CodePen, talks about how they decided to mix responsive templates with separate mobile templates, with adaptive templates for their own product CodePen. And Chris was on the Ethan had a nice podcast recently, and they talked a little bit about how they ran into some challenges particularly with some of the more complex flows that they found in their editor.
He said that there were some pages where it just made perfect sense.
There was literally no question at all that they would handle those pages responsively, but he said that they ran at a particularly screens, particular types of pages, particularly in the editor, in which he said we just didn't feel like we could provide the best experience to people on smalls screens and large screens using the exact same design.
And so let's face it, if there is anybody out there who could Ninja his way through a responsive solution to this problem, it is probably Christ Coyier. They just decided that it would be better to incur the higher maintenance burden of having two different versions of those particular pages, than it would be to try to handle those responsively.
I've seen other people describe the value of handling particular templates adaptively.
I recently got into a fight on the internet with this guy Brian Massey, the Conversion Scientist. He wrote a post that I believe was short-sighted and ill-informed about the value of adaptive design over responsive that frankly didn't take into account any of the things that responsive design can actually do and made an argument that you should adaptive solutions without also fully understanding what was involved in using adaptive solutions.
After I unpacked his arguments and took out all of the little bits that I thought were completely irrelevant because he didn't know what he was talking about, we managed to settle on the conclusion that he said if you are doing a campaign that is aimed at mobile users or you want to segment your campaign into mobile and desktop users, and you wish to AB test this campaign in order to test out different versions of your landing page, he said that in those scenarios, the amount of code that you would have to have on the page to both handle the responsive aspects and also handle the AB tests to serve up different messages, is simply too complex and so as a result, in those scenarios, you are better off serving a separate mobile landing page rather than trying to deal with it adaptively. I'm not a conversion scientist.
I don't know that this is true, but I can imagine that there are other scenarios out there in which a principled and reasonable discussion amongst your team and your developers and everybody who is involved in the process might conclude that in particular scenarios, it would make sense to handle a particular page adaptively, but in many cases the problems that you are trying to solve don't even encompass the entire page.
So there maybe scenarios that instead you just want to serve a little bit of the page. A little feature.
Just a little object on the page differently. Beatport is like a combination of Spotify and the Billboard charts, but for electronic dance music.
So it is one of the leading sites out there that's aimed at DJ's.
They recently responsively re-platformed their entire app. The entire music experience, the entire purchasing experience is all responsive, but they said they decided for one particular feature, one crucial feature for them, which was the player that they decided to handle just that little bit adaptively.
They said they really just struggled with the idea that the player wanted to be different and wanted to be a different experience on small screens and large screens.
They cut two versions of just that player.
They do a little bit of testing to figure out what size screen they are sending it to, and that's the only thing that they handle adaptively. Fidelity is an investment bank in United States. They ran into a similar problem with, can you guess what it is? Oh its tables.
Yeah so tables are a big problem, especially when you are trying to serve the same information to large and small sized screens. Fidelity said that they ran into a particular problem with one table that it is kind of like this industry standard table and it has an industry standard sort order to the columns. They said they ran into problems because when they wanted to handle that table responsively, they couldn't just squish it down or they couldn't just cut off some of the columns that were on the left because some of those columns were really important.
They made the choice to rearrange the column order so that people on small screens would see the most important columns, but when they did that then people on larger screens complained because the columns were out of order.
As they scratched their heads about how they would solve that problem they said we decided to handle that adaptively. We cut a small version of the table and a large version of the table and we dynamically serve those up to people so that we feel more confident that everybody is getting the right experience.
Let me tell you a little secret though.
Fidelity came back to me later and said no, no, turns out that was not the right way to handle it. We were better off instead doing conditional loading to try to load everything and then make some determination on the client side based on the size of the browser window, which columns for that table we were going to show.
It is possible to do this kind of conditional loading without necessarily having to fall back to a server side adaptive solution.
I want to be clear.
When Fidelity is talking about this, what they do not mean is that they are hiding that information from mobile users. They are not setting that those particular columns to display none.
That is not a content strategy, but rather they are testing to see how large that browser window is and so that they can serve up only the information that is needed for that particular screen size.
They can do that all completely client side. My advice for you is in general if you have a problem that is completely about the size of someone's screen. If the problem that you are trying to solve is literally a problem about the layout of the design in relation to the size of the browser window, then you are always better off handling that problem client-side, handling that problem completely fluidly, handling that problem with responsive design. All right, another way to put that would probably be, if you don't need to get the server involved to solve your problem, don't get the server involved to solve your problem. When do you need to get the server involved to solve your problems? It is when you want to serve different content. In a responsive solution, for better or for worse, you are serving the same content to everyone. Adaptive content is what has been touted as a solution, for providing a different experience for users, for tailoring the content to the device or the characteristics of the device, or to the context of use.
In an adaptive content solution, you are serving up different information and presumably with an M-DOT you are also serving up different content.
Now I'm an advocate for One Web.
I'm an advocate for responsive web design.
I believe that in most scenarios, people are better off embracing the flexible fluid nature of the web rather than trying to target content based on device specific variables.
When I really explore my reservations around the idea that adaptive content should be used to target different information or different content to devices, I realise that I have literally only myself to blame for this problem.
I popularised the term adaptive content.
I have been speaking about it for four or five years now. It is the centre piece of my book, content strategy for mobile.
As I have seen as many people see, you put your ideas out there on the world and then you see what people do with them, and I start to have some concerns about where we are taking this.
When I talk about adaptive content, I popularised a case study from NPR, in which they outlined their catchily named approach to publishing web content, which they called COPE.
It stands for Create Once, Publish Everywhere. In NPR's model, they maintained a single content model for their article form.
In this content structure, they would have foreign article, a title, a short title, a teaser, a short teaser, several images attached to the article, an audio file, the body text, whatever metadata was attached to the article, and they could serve up a different combination of that more granular content based on the type of device someone was using. Their desktop website could have one version. Their audio player could say you know what? Don't give me all of that stuff.
Just give me title and the teaser and the audio file. That's all I need.
Their mobile website could ask for a completely different combination of objects. Native apps could query their API and also choose a different set of objects to display. They could even do this to desktop applications, like iTunes, which frankly at this point is just showing off.
It is pretty easy I think when you look at this case study, when you look at this example, to see how it has become the poster child for device specific content targeting.
I have some concerns about this approach.
Not least of which is, hey guess who just went responsive? Oh it is NPR.
Patrick Cooper who is their head of digital says, "Yeah we had a phone website, and a tablet website, "and a desktop website, and we really only maintained "the desktop website because we just didn't "have enough resources to cover all of those fronts. "It just wasn't a tenable situation." Now let's do think that I'm standing up here and recounting my position that the earth goes around the sun.
I believe that there is huge value on the web for having more structured, more granular, more modular content.
We must, as John Elsop told us more than 15 years ago, move away from using the examples based on print, in which our content is locked up in a presentation format, inextricably tied to one particular layout or one particular form factor.
And rather think of our content as flexible, fluid, presentation independent chunks of content.
Ted Nelson says that imitating page on a computer screen is like tearing the wings off a 747 and using it as a bus on the highway.
In order for us to truly live up to the values that make the web as a medium great, we must embrace flexibility and fluidity and accessibility in our content.
I will argue until the end of my days about the value of storing content in more granular ways.
Rather than treating content is if it is like a brochure, is if it is like a web page, as if a web page is a giant Wikifield or a big WordPress blob, instead having that content be semantically rich, stored in more granular ways, stored in presentation independent ways, allows us to do more with that content.
There is huge value that organisations can get simply by choosing to store and manage their content or their web pages or their website in this way, but it is very easy I think for people when they start talking about what it means to create granular content to make a leap to saying oh wait but that means that I can then target that content.
If I have content that is stored in more granular chunks, I can create alternate forms of that content.
Then dynamically target them to people based on device or based on other characteristics. I have to make a confession here.
Basically literally everything I know about publishing on the web, everything that I know about adaptive content comes from the fact that I was the only person at my job in the early '90s who knew how to do a mail merge.
I had to do it using WordPerfect for DOS.
And you kids in your graphical user interfaces can suck it.
So I think that when you talk about this kind of adaptive content, when you talk about the idea that we can dynamic, get the server involved to dynamically target chunks of content to people based on a certain set of characteristics, it is nothing more literally than a glorified mail merge. It is just that we are taking little different fields of content and targeting them based on a set of characteristics. One characteristic, that people often want to target content on is the device.
We should be able to know something about that device, whether it is the operating system, whether it is desktop or mobile, whether there are some other devices in mind or the capabilities of that device, and we should be able to tailor the experience to that device.
It there are some limitations to using device in this way. And that people might wish to move beyond thinking about device specific content targeting. And instead think about what is often called contextual targeting.
Now I have for the industry I believe a very, very specific and limited definition of what I mean by context, and it is this.
It is information that can be gleaned from the device sensors in order to tell you something about what the user is doing, or where he or she is.
That maybe things like time or location.
It could be other things that you can get from the device sensors like how fast it is going, or you can use the barometer to tell you the altitude of the device.
You can get the temperature from the device. There's other things that you can get from the device sensor that may give you some idea about where the user is or the environment that the user is operating in. From that you can make assumptions about context. But those assumptions that you will make based on device sensors are also always going to be somewhat inadequate definition of who that user is or what they want.
So a third way that people talk about targeting or tailoring the experience to the user is based on the person him or herself.
Personalization.
That may mean things like trying to figure out the person's age, or their gender or their life stage, or what languages they speak or do they have kids, are they married, using that to personalise the experience to them. There are many people who talk about the value of personalization, particularly for marketers.
I would like to side step that particular conversation and focus really just on the first two.
To clarify what we mean when we talk about context or what we mean about tailoring things to the device. So when might you wish to try to tailor tailor the contact, tailor the experience to the user, based on the type of device that he or she has. If you look back, the world that I operate in, if you look back over the history over the last 20 years or so, operating system is actually something that people have used to tailor the experience. Even beyond the idea of having desktop or mobile or the capabilities of the device.
So if you've ever looked at support content that was provided for both Windows and for Mac computers, and kind of gotten the sense that they were doing some, a glorified mail merger work to try to explain how different tasks could be completed on Windows or Mac, you've gotten a sense of how that might be used. On the web today, we also have the ability to tailor the experience to the operating system. Orbitz, the travel company discovered that Macintosh users were most likely to purchase more expensive hotels.
And so just as a favourite of them, really just to I mean just to be convenient obviously they were gonna want the more expensive hotel, they decided to make those higher up in the search results. This type of tailoring, this personalization can be done for good or for ill.
When people talk about tailoring information to the device, they may also mean the idea that we want to deliver different information based on the type of device that someone has in their hand.
I want to make it clear that this is something that can be done even in a responsive framework.
AT&T phone company in the US, discovered that they might be running into a problem with maintaining a whole suite of different native apps. Their customer service reps found it difficult to provide people with help when they called in for help on their account because with a handful of different native apps out there, customer service reps were never quite sure what the customer was actually looking at.
So on a scenario like that, AT&T might choose to responsively re-platform their account servicing.
So rather than maintain their desktop website, a mobile website, and a suite of native apps, they might decide to serve the entire account servicing function up responsively.
In a scenario like that though, it doesn't necessarily mean that they have to deliver identical content to every user. They can still serve up adaptive content to people targeted to the device.
Why? Because the content is literally targeted to the device.
If you were coming in looking for support content on your particular phone model, the last thing in the world that you want AT&T to ask you is what kind of phone do you have? Instead they might serve adaptive content.
They might know what type of device it is and then dynamically serve up the support content to you that is most relevant to your device. But I want to be clear about that.
That is a measure of personalization, not a measure of filtering out content.
I wouldn't necessarily want them to not show me content for Android phones on my iOS device because there are plenty of scenarios in which I might have a friend whose Android device is borked and I want to able to look up some support content for them on my phone, but the idea that we could target content, personalise content, tailor content to the device if it is actually device specific seems pretty reasonable to me. I also think there are scenarios in which we do need to tailor different information to different device types that may go beyond the web or mobile devices.
I teach at the School of Visual Arts in Manhattan. They have a responsive website.
They have a native app.
They just bought all these digital signs that they want to put up all over campus.
So when I look at an example like this, to me this is a perfect case study of the value of storing more granular content in order to support device specific targeting. To support these digital signs, you don't jut want to take the responsive website and squish it down or rearrange it in order to have it appear on a digital sign. The experience for someone looking at a digital sign, from a 20 foot view needs to be different.
It is the same information but it has to be presented with a different layout, a different priority, a different hierarchy, to have it work in a context in which it is a sign that is not interactive. When I look at an example of a page like this, I can totally see that if this was all just like one giant WordPress blob, they would not be able to target the content in a granular enough way to be able to pull out the title of the event. A short teaser of the event.
The time and date, the location of the event. The information that needs to be stored in a more granular fielded way.
Because the information was stored that way, they were able to pull it out and present it with a different design and a definition context that would be appropriate for a larger sized screen. But when people talk about adaptive content, this was an article written recently by the content marketing institute, in which they touted the value of adaptive content for being able to tailor the language that we use to communicate with people what they should be doing in an interface.
So they said with adaptive content, you'll be able to know if an user is on a laptop and you could change the verb that you are using to say click.
If they are on a touchscreen, you could say tap.
If they are driving in a car, perhaps the action you want to take, the select. So this sort of tailoring of the verb to the experience.
As a writer, I'm very sympathetic to the desire to really provide people the right language and explain things to them in terms that make sense.
But as a web designer, I have grave concerns about adaptive content being touted this way because we got no reliable way to detect what sort of input mode someone is using.
We can't possibly know whether someone is on a laptop or whether they are using a keyboard or whether someone has a touchscreen or not or frankly we can't possibly know if someone has a device that does all of those things and thus we have to account for every input mode available. Designers and developers that wrestle with this problem, settle on the idea that yes you are better off just assuming all possible input modes and designing for the broadest possible scenario. The same is true for writers.
Even though it is frustrating to not know whether someone should tap or click, we have to provide we can't assume that we can dynamically target that kind of language.
Device type is never going to be an effective way to tell you what it is that the user wants. The guesswork that we try to do to understand what type of device someone using. Is it mobile? Is it tablet? Does it have these capabilities? We want to personalise the experience so that people are getting the exact right thing for them usually turns out to be a false errant.
It is not worth putting the level of effort in to try to customise the experience to the device, when frankly you are likely to guess wrong, and then guess work that you are going to do isn't going to provide that much value to the user anyway.
Christ Balt who is the programme manager, who led the responsive redesign of Microsoft.com says, "Our data shows us quite plainly and clearly "that the behaviour of people on mobile devices "is really not all that different from the behaviour "of people on desktop.
"The things they are seeking to do, "and the tasks they are seeking to accomplish, "are really quite the same." I think this is one of the most unintuitive aspects about designing for our crazy multi-device feature, about why responsive design is the right approach. Sometimes I will post this up on the internet. Benedict Evans the mobile guy retweeted a post that had a screenshot of the slide, and people got angry.
There is this sense that this just can't possibly be true, but in fact when you actually sit down and you look at the data, it turns out that trying to tailor the information through the device is rarely going to provide an experience that someone is going to prefer. If device isn't the right way to do it, what about trying to tailor information to the context of someone's use.
Now I want to remind you, I have a very specific definition of context. It means things like time of day, location, velocity of the device, the altitude of the device, the temperature of the device, things that can be literally gleaned from the device sensors.
I gave this talk a while back and someone came up to me afterwards and she said, "Karen why is this context? "Isn't context something like waiting in line?" And of course it is but here is the thing.
We got no way of knowing whether somebody is waiting in line or not? I will give you an example of this.
I have worn hearing aids for the past like I don't know 35 years or so.
And if you know anything about digital hearing aids today, they come pre-programmed with these different soundscapes. I have a restaurant programme.
I have an auditorium programme.
These particular hearing aids come with a car programme.
Now what's interesting about this particular programme is that it will automatically switch over to the car programme when it detects that I'm in a car.
How do my hearing aids know when I'm in a car? Well the iPhone will monitor speed and will automatically change to the selected programme when the iPhone is going faster than 10 miles per hour. Now that's an interesting decision on the parts of the device designers to assume that going faster than 10 miles an hour must mean that I'm in a car.
I could be running faster than 10 miles an hour. I could be bicycling.
I could be a human cannonball.
Out of those options, the human cannonball by far the most likely.
But you can see that making assumptions based on the information that you can glean from the device sensor is always going to be somewhat inadequate proxy for what the user is actually doing or what the user actually wants.
So there are some scenarios in which using contextual cues from the device makes perfect sense.
Here is an example of a city guide from Leeds, in which when they are looking to do restaurant recommendations, they made the choice to pull information in from the device sensors. If you are looking at a restaurant and they want to show you a list of other restaurants that you might look at, there's a lot of different ways that you could pull that information.
You could show other similar restaurants, so you could show you know if its a Pizza place, you could show other pizza place.
You could show editor's picks, so I'm gonna tell you which restaurants I think you should go to or you can dynamically pull the location of that device and show people nearby restaurants. That maybe actually a contextual cue that provides a lot of value to the user.
Like if they are standing there on the street corner and they are looking for some place that they want to go eat, and this particular restaurant is closed, they may not necessarily want to know what the other pizza restaurants are.
They may want to know just tell me some place that's nearby so I can go eat there.
But I want to make it clear that when I talk about this as a contextual cue, and this is something people get real confused by, location does not mean mobile.
Location information is something that can be gleaned on every type of device or many types of devices.
Here is an example of an article from the New York Times, in which they talk about income inequality in the US. They do some dynamic information based on location, a little glorified mail merge here in the New York Times, in which they say consider Manhattan.
Our best guess for where you might be reading this article. I'm sitting in my home in Manhattan and I've got my laptop here and I'm reading this article. So they sort of dynamically personalise this based on the location information from my device, but this is coming from my desktop.
So you don't necessarily have to assume that location information or that if you want to do something that's based on location, then that is something that is a mobile scenario. It is not.
It is a location based contextual cue.
There are limits, however, to what you can do with location.
Google, Google at this point knows everything about me.
Google, I have my mail through Google.
I have my calendar.
They have my search history.
Franny at this point, Google knows me better than anybody. They even know me better than I know myself. This past year, I went to Israel.
What do you think the first thing that Google asks me when I open up my laptop in Tel Aviv? They say do you want to switch to the Hebrew version of our interface? Now I'm just going to put this out there for you Google. Based on all of the information that you've been able to glean about me in our 15 year history, have I ever shown the slightest indication that I can speak Hebrew? And yet I think we waste a lot of money and time trying to target information to people based on their location.
And yet just because someone happens to be at a particular location, like my friend Kim Goodman just found herself in Finland, doesn't necessarily mean that that location based targeting is going to provide something of value. I think when I start hearing people talk about the ability to tailor the experience based on contextual cues, what it starts to sound to me when I sit in some of these meetings with people, it starts to sound to me a little bit like personalization fan fic.
They are like, "Yeah it would be really cool" is that we could scrape people's LinkedIn profiles and then based on that, we are gonna be able to know where they went to college, and what type of relatioship they are in, and then we are gonna be able to dynamically target messages and services to them based on what we know.
Yeah no possible way that could go wrong.
In an article that I think was basically created in a lab with the sole purpose of annoying me called responsive design is failing mobile UX. The author outlines a scenario for people working in the consumer packaged goods industry that want to capture attention from people across the buying lifecycle.
He says you want to get to know your customers and determine whether they are pre-store, in-store or post-store.
You'll need to create a different experience based on where the customer is on the path to purchase.
Now I have a lot of concerns with a scenario like this, because you just can't possibly know where someone is on the path to purchase right? But if I want to take this in the most conservative way possible you can certainly use contextual cues like location based cues in order to know whether someone is in store or out of store and tailor the experience to them a little bit differently if they are physically in the store.
That should be based on location right? No wrong, not according to this guy.
He says adaptive design enables the customer to have a customised experience based on the device he or she is using.
Optimise the customer experience by tailoring the design and information through the device. No don't do this.
Do the exact opposite of this.
This is the exact wrong way to think about it. If you are hoping to capture customer attention because they are physically in the store, that's not the same as tailoring information on surfaces through the device.
It is always going to be less.
It is going to be more risky, less accurate to use device as a variable when you could be using location based targeting to know when someone is physically in the store. But even if you want to do that, I am going to put a little damper on your enthusiasm here and tell you people don't even want this.
A study by Forrester recently talk to people about where they are likely to use their mobile device and what context they will complete particular tasks on particular devices, and what they found is that essentially there is no difference.
There is no distinction in the types of tasks that people will perform on their smartphone.
People will use their smartphone in every context if you make it easy enough for them.
Really the only places where there's any variation in what someone will use their phone for is that people are less likely to check the hours of the store on their mobile device while they are physically in the store, but other than that, most people today when they've unpacked the data about the types of tasks that people perform on different devices, they find that there really isn't a lot of variation on the types of tasks that people will perform based on type of device. Similarly, people also hypothesise that people may want different experiences based on time of day.
I do a lot of work with the publishing industry and my gosh, have I seen this slide a million times? There is this idea that well people use their smartphones while they are on their commute and then they use their Pcs during the day, but then at night, they use their tablets.
We should provide a completely different experience for people on tablet devices, so we can capture that valuable lean back evening time that people obviously want from us.
Strangely enough the entire country of Canada has decided to participate in a large scale AB test of this approach.
So the first one, the La Presse, has innovated by basically saying they are going to stop their print editions and go all in on a tablet only strategy.
With some concerns however that this may not work out so well given that people don't buy tablets very often and tablets are most certainly everybody's third favourite device.
Similarly Postmedia.
So Postmedia is a large newspaper chain and they have titles in most of the large Canadian cities. They found that after they released a variety of device-specific editions that the tablet edition wound up being the least popular edition.
And most interestingly, the Globe and Mail went all in on a mobile only, tablet only strategy.
Turns out users hated it.
You want to know how you find out that users hate your tablet only strategy.
It looks like this in the app store.
It turns out again people don't want you to decide what information they want on which type of device.
A study by ExactTarget found that 91% of people said access to content anyway I wanted is the most important criteria for them in evaluating whether a mobile brand is successful.
Beyond that, 83% of customers said that a seamless experience across all of my devices is important to them.
That number went up to 87% when you talk to people who own both a smartphone and a tablet.
You don't get to decide which device somebody uses to go on the internet.
They get to decide that.
It is our mission, it is our responsibility to provide a great experience to people on whatever device or platform they choose to use. Rather than trying to guess what someone wants. Scott Liewehr is a CMS consultant.
He is based in New York.
He is a really great guy.
I gave him some crap for this article that he wrote recently called Netflix, you don't know diddly about context. In this post, Scott hypothesises that Netflix they of the personalization engine are failing to take customer context into account when providing recommendations. He outlines a scenario that I think is probably very familiar to some parents out there, in which he says that he has three children, aged two, four, and six, and when he takes them out to a restaurant, he likes to give them his phone in order to entertain them.
Scott says, "Hey why can't Google know, "why can't my phone know "that when I'm in a restaurant, it should serve up "serve up the latest episode of Mickey Mouse. "Like I got there using Google Maps on my phone. "You know where I am and why can't Netflix know "that later that night after 9 PM, "when I'm back in my man cave that "I don't want to watch the Little Mermaid." He is hypothesising that Netflix should invest in doing contextual targeting.
So location and time of day based targeting in order to dynamically serve up recommendations or you know suggest idea.
I think that this is a solved problem.
It is called user accounts.
Why? Why would Netflix invest in expensive and complicated and risky contextual targeting to try to assume what Scott wants to watch on his phone based on where he is or what time of day it is when he can avoid ever having to see the Little Mermaid simply by setting up a separate account for his kids.
So device, device is always, always going to be the least accurate proxy for context.
If you want to tailor the experience to someone, you are much better off using contextual cues that you can glean from the device.
But just to put a little damper on that.
Even that I think is often unnecessary.
Scott Kelton Jones is the VP of Global UX for travel brand Expedia.
They have been experimenting and doing a lot of AB tests on their responsive platform, and he 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." This is a travel brand y'all.
Like this is the most specific example of a scenario in which people think you need to do contextual targeting and even they have come back and said, "You know what? We are going all in on responsive design. "It is simply not worth it.
I will leave you with this.
Most of the time, most of the time, you'll be better off serving the same information to everyone.
I'm gonna call it like 95% of the time responsive design will solve your problem.
I think the best thing that organisations can do before they jump down this path of needing to dynamically target information to the user or based on context with the device is to get a really solid responsive design working. Build it from the ground up.
Get it coded really well.
Make it lightning fast and that's gonna solve I mean 95% of your problems. Bill Scott, who is the VP of Next Gen Commerce from PayPal says, "Thinking of responsive was just table stakes. "It's just a default thing that should always happen. "You may later decide to create a custom experience, "but you don't have to go there first.
"You can start with responsive." The thing with this is that adaptive solutions, whether that is adapting the design or adapting the content that isn't some magical panacea for all of the problems that you might encounter with a responsive design. Adaptive isn't a better solution.
It is just a different set of problems, and so rather than touting the idea that you should jump to adaptive solutions when you run into issues with responsive, I would encourage people if you are in meetings trying to debate this to say, you should always, always try to solve your problem using responsive design first.
You should always try to solve the problem on the client side first rather than getting into what will frankly be a more complex and more costly route if you don't need to. Forrester brings this back to the One Web issue by saying if your customers are expecting a coherent experience across touch points, why are we siloing our efforts by a narrow device category definition? Practically, One Web reinforces the needs for unified system, processes, and teams that drive real-world cost savings and digital business efficiencies.
Finally, okay so let's say two years from now, you come back to me and you are like, "Karen, we did it.
"We rebuilt our site.
"It is completely responsive.
"It is lightning fast.
"It solved 95% of our problems.
"Yaay, we did it.
"It solved 95% of our problems.
"We still have 5% of our problems." Fine, now you are in a position to be able to in a selected, limited, and targeted way try to solve for problems that you think are literally device specific or literally contextual solutions. You don't have to jump into solving those problems immediately from the get-go.
Get the responsive solution working first and then realise that the adaptive solutions will be complement to responsive design.
I often hear people talk about adaptive and responsive as if they are in competition.
They are not.
They work together.
If we are gonna deal with all of the challenges that we will face in this crazy multi-device feature we are all living in, we need every tool in our arsenal.
I will leave you last with this quote, again from Livia Labate from Marriott, in which she says, "It is important to acknowledge that most activities "are universal even if there may also be "device specific needs.
"by having the web experience unified "through a responsive approach, "we cover the basic scenarios across the board, "and can later do a better job "at handling device specifics." Thank you all.
Thank you all so much for coming out.
