Responsive content and user context

Editor's Notes

• #2: Hi. My name is Andrew Fisher and I’m an web developer and interaction researcher and tonight I want to talk to you about responsive content and user context for the next 25 minutes.So why am I talking about responsive content and not responsive design? Well responsive design is definitely a worthy goal but I think it’s symptomatic of our shift to mobile. Instead I want to think beyond our current devices and try to prepare more fully for the future.
• #3: Who saw this picture last week? I think this is brilliant as it perfectly sums up the state of the world these days for technologists.We get so immersed in the technologies we use that we forget that they haven’t been mainstream for very long at all. I started doing mobile work in 200 because I was lucky enough to work with Sonera so I take mobile use for granted. Just like all of us do these days when it comes to most technologies we use. By the time they hit mainstream we’re already looking at something elseBut this picture shows how rapidly the mainstream is moving now. These two pics were taken only seven years apart and you can see the massive change evident here. It’s not that mobiles didn’t exist seven years ago but smartphones weren’t commonplace. In that period we’ve gone from limited use to almost total use. Given that we get new popes on average every seven and a half years, what changes will we see in the way consumers interact with our services by the time we get the next pope? It’s an interesting yardstick to measure progress with… the Pope Technological Index.. Or something.
• #4: So this is why I want to talk about responsive content. We’re doing a reasonable job and getting better at making our design respond to to this or to that but we need to go beyond simply device. We need to make our content and our services respond to our users, in the way they want to interact. We don’t know what the next common method of interaction will be for consumers yet, so my aim tonight is to help prepare you so we don’t have to go through the transition we’ve had from desktop to mobile again.
• #5: Covering everything to do with responsive content would take quite a bit of time so tonight I want to concentrate on three key areas:Considering content first.Understanding the role of user contextsAnd how to make your content responsive.That’s a fair amount of stuff to get through and I hope there should be some time for some questions at the end so let’s get cracking.
• #6: So when we started talking about responsive design, there was a push towards what was called mobile first. This was lead by those doing a lot of mobile work and realising that it was really hard to go down to a smaller screen once you’d already built a desktop site or application. Have any of you had this problem?
• #7: Mobile first was supposed to solve this by moving to the smallest screen size first then scaling up progressively to more capable screen sizes or capable devices. So we start with mobile, then design for tablet, then desktop. The problem is that a lot of tablets now have pixel capabilities bigger than laptops. Even mobile phones like the Nexus and iPhone 5 have higher resolutions than netbooks. Also arguably mobile devices are more capable than laptops. Maybe not in raw processing power but certainly in terms of things like touch and sensor capability. So the line has blurred. We don’t have the clean line between devices that we had even as little as two years ago. This stuff moves so fast it’s hard to keep up.
• #8: This has since precipitated a move towards what is being called content first. This accepts that the lines between devices will get increasingly blurry and we should think about our content first and foremost and how we work with it and create it and then choose the appropriate ways to deliver it based on device.
• #9: So whilst I’m a fully signed up member of the content first crew, I go a step even further than this and consider how content should be used given the different contexts our users are in and the experiences we want them to have in that context. Device comes into this but it isn’t the only consideration. This is a much more human centric approach and I think it isn’t sufficient to only react to the device a person has, we should create much more responsive experiences across all the points a person touches our service.To give you an example of what I mean then. What does a non-device centric responsive experience look like?How many of you use twitter? Okay a fair number of you. So how many of you signed up to twitter in the last 18 months or so? A couple. Do you remember this?Image: http://www.flickr.com/photos/yourdon/2681687374/sizes/o/
• #10: This is the twitter new user walk through.For all of us that signed up many years ago we were pretty much chucked in the deep end – here’s your feed, type tweets in here and get on with it. The team at twitter realised this wasn’t the best way to onboard new users at scale so they created a new user mode that pretty much guaranteed that all new users would hit a critical mass with the number of people they follow and then realise a nicely populated feed they could interact with.This is how responsive experiences and content works. It doesn’t matter about the device, it’s more about the context of the user – in this case, a new person to the service – and making the experience react based on them.
• #11: So I’ve said content many times so far and used it in a lot of different ways. What am I talking about. Is it just the paragraphs and pics in your main column div?No not really as I define it anyway. Content for me is everything you deliver to your users no matter what their context is. It’s the totality of their experience with your service.So this move towards a content first approach means that we think about the type of experience we want to deliver based on the service we’re providing and the way that our users want to interact with it. This is a much more human centred design approach and will naturally take context into account as a result.
• #12: Now we understand what content first means, lets consider user context.Context is the situation that a user finds themselves in and this is usually a combination of variables.
• #13: Obviously we can consider the type of device. A laptop is very different than an ebook reader in capability.
• #14: But we can also consider things like time as well – is it day or night, weekday or weekend. This can also change our behaviour.Image: http://www.flickr.com/photos/martinaphotography/7482296868/sizes/l/
• #15: We can also consider location - is the person moving or stationary? You can infer location but you can also ask a user for their location if you think it will make it a better experience. Does the person’s location overlap with known places like a train station, a train line or say you were a retailer one of your stores (or close to it).These are just a few points that can create a whole bunch of different contexts that the user may be in.
• #16: If I visit a site on my phone at about 8am every morning through the week and I’m moving chances are I’m on my commute. This is very different to me using a tablet in landscape mode at 9pm where I’m connected via a high speed wifi link from a static location. Image: http://www.flickr.com/photos/henry_stradford/5348910688/sizes/o/
• #17: So I can start responding to that user’s context now – for example, By looking at connection speeds I can start shaping what they see. A mobile phone on a WiFI connection is a fundamentally different to one on a 3G network especially when you change cells and the network has to do a hand off.
• #18: As such we can change assets based upon this. As well as our media queries, we can send different quality images to users on poorer connections. Indeed we can even consider removing heavy images altogether and making them request based. Reacting to these types of external events can really make the difference between a great experience and a terrible one. Make the external factors that go into the experience something you can start to control.
• #19: Now, a lot of companies when they “go mobile” have this belief they need to be able to offer everything on their site on the mobile site as well. This is rubbish. The user might tell you they want something but actually when it comes down to it, they’ll do something else entirely. The reason for this is because of task oriented context.
• #20: I’ve been told anecdotally that when ANZ came to build their GoMoney application for mobile devices it was based around the insight that the majority of users logged in to the existing web application on their phone, looked at their account balance and exited again. As such in their mobile app they put it front and centre and then tacked on making a payment as well as that was the number two task. Context drives need and requirements.When I’m out and about and I’m really mobile, I don’t need the full capabilities of the entire ANZ online banking platform. I just want to see whether I’ve been paid and whether I have enough money to buy that new Vita game or not. Don’t underestimate task oriented context as it’s a massive factor in behaviour.
• #21: Once you start going down this path you can start shaping really tailored experiences. There’s a whole bunch of other things such as looking at behavioural states, expert user modes such as the search box in github or using levelled capability all of which can make your contexts even more complex.Start by just considering device, location, time and speed and you’ll get a surprising number of contexts from them to consider in your design.Now we understand user contexts, lets look at how to make our content respond to it.
• #22: There are loads of techniques around this which I won’t go into serious detail on. But the key to good responsive content is this:Impose good structure on your contentMake things chunkable so the content modules can be reused in different ways.And create good meta data around each individual piece of content.
• #23: People hate structure. No one wants stinkin rules man. But with content it does make life easier. Teaching content creators to use hierarchy and structure, even if it’s just basic content levels in Word, or you can teach them real, structural HTML makes your content much more organised. Creating the right structure and applying it and potentially working it into your QA process underpins everything else you want to do. Getting people to understand how good structure plays out in all the different ways you use your content across all the different experiences and how it breaks when they don’t makes a difference.
• #24: Once you have a good structure, you can start chunking it up which sounds disgusting but is practical. An immediate benefit of this is that any large document can be broken up in an intelligent and automated way and potentially delivered as one file or else over multiple ones. This is great for advertisers. However it also means you can load the first chunk if your users are bandwidth constrained and then lazy load in just the additional content as the user scrolls down and reads it. This is like a finite version of infinite scrolling on say twitter. You can also syndicate it via an API and then use things like handlebars to load content selectively instead of having to round trip to the server all the time.
• #25: So if chunking makes your content more portable, meta data makes it more understandable.When I talk about meta data I’m not just talking about keyword and description elements that we all didn’t put into our documents for search engines before google. Meta data can exist around every single chunk of content.
• #26: For example, say for an event like this, we could have meta data about the speakers and their topics. We could have links to live streams or github accounts etc. We could also have locational information. This would be useful for the comedy festival for example where performers are at different locations all the time.There’s no magic recipe for meta data though, it’s entirely domain driven but if you got to the effort of creating it then use it.
• #27: A good example of this is say for an image. I can store the raw asset at high resolution then create crops of it to use across all my different instances. The issue is that if I change my aspect ratio I can create problems in where to crop it. Centre just doesn’t work in most cases. Any of you had this problem?So if I store cropping hints with the images, I can inform the system as to where my perceived centre should be and I can crop outwards from there very simply. This is stored with the asset and becomes portable as well.So we’ve covered quite a bit of ground there and hopefully I’ve given you some things to think about with regards to content first design, considering context and how we can make our content respond a bit better.
• #28: Now as it happens there’s a book which launches this week from SitePoint called Jump Start Responsive Web Design.It was mostly authored by CraigSharkie who some of you may know, but I helped out on the content side of things so that has heaps more detail in there about technical approaches for responsive web design generally and around content too if you’re interested in the topic.Book link: http://ajf.io/rwdmobmelb
• #29: Plug over – if you have any questions or pointI’ll be around tonight but here’s my details if you wanted to chat further.Thanks a lot.