The Mobile context

The mobile context is being discussed a great deal at the moment in regards to mobile web. What does it mean? How can we use it? How can we make assumptions about the context a user is in, based on their device?

To give a few examples of assumed mobile contexts, and ways sites might work around them:

Perhaps the user was not in those contexts, they were at home, booking a flight, online shopping or wanting to read the local news. On their mobile, in front of the tv or perhaps in bed. Research showing how large a percentage of people use the mobile web at home has been done, lets not ignore this key fact.

The number one crime in the name of mobile context

A number of sites have taken to serving up different mobile content, and allowing no access to the remaining content on the site. Some even redirect users to a mobile site from any link, rendering urls you may want to use inaccessible.

This leads to a broken web, on mobile.

The download speed argument

One main argument for reducing content on mobile is that the download speed is less, or bandwidth is more limited.

I often use my mobile at work and home to browse sites. I am sure I’m not the only one.

I also often use my desktop in hotels and with a dongle.

Mobile != low download speed

Other ways of guessing context

Recently I’ve heard suggestions of other, harder to measure ways of guessing context.

These are harder to measure, and still don’t accurately confirm context. If it were possible to accurately know the context the user is in, we still have a problem.

Context != intent

I’m definitely moving, I’m definitely in a car. I’m going to look at your website.

This still doesn’t mean my intent is to find an address, or quickly use a news site and check the most popular stories. Context can’t predict the way a user is going to use the site.

Mind reading is no way to base fundamental content decisions

So what can you be sure of?

You can be sure the user has a smaller screen. Content may need rearranging, using techniques such as Responsive Web Design.

Content may need to be somewhat repurposed or refocused. This should relate to the priority you set things in on the desktop.

Low priority items may need to be removed. Examples include:

You may wish to give higher priority to certain features research has shown people are more likely to need when on a small mobile device (your own research, into your users).

My guidelines to safely changing sites based on device:

 

15 Comments

Stephanie Rieger

We need more discussions like this. We’ve been talking about intent for a while now but instead everyone seems fixated on context.

As if data is the magic elixir that will reveal all the information we need to design that perfect experience (or as it were…thousands of perfect experiences…that may change at any point.) I think intent is not a popular topic because you can’t easily capture it, analyse it, and sell it… :-P

The most immediately useful context is screen size, then device capabilities (actually, they are both equally important). After that comes location (but only if your product can make use of it). Almost everything else is conjecture because you really don’t know why the person is interacting with your product, what part of the ‘journey’ they’re on, if they’re in a hurry, just browsing etc.

(rant…rant…) :-)

PS- Yahoo and Nielsen have some great data on how people use mobile around the home. http://l.yimg.com/a/i/us/ayc/pdf/mobile_shopping_insight_deck.pdf

Dan Oliver

Bookmarked! I think you’ve done a great job – using scenarios we can all relate to – of highlighting the inherent flaws in making assumptions about context on the web. I’d be interested to hear your thoughts on promoting context-specific apps to visitors of the sites you’ve mentioned.

Daniel Eizans

Totally agree with everything you’re preaching here Mark. Just because you’re accessing via mobile doesn’t mean that you’re necessarily just address finding, but I also believe just optimizing all the stuff for mobile isn’t the answer either.

I think there’s a mix here and a deeper look at the mobile user by site type will start to help us get there in the long run.

I’m fully of the opinion that the content of sites needs evaluation prior to going mobile and certainly advocate to my clients for revision before going to mobile in a lot of cases. Lately, I’ve been taking a deeper look at responsive web design and trying to discover ways to create different content templates to be delivered through the media type call. I was just starting to write about this stuff yesterday myself.

Great stuff.

kirby.mark

@stephanie thanks, I agree 100% device capabilities are equally important, and some sort of feature detection along with media queries can really optimise the experience. Thanks for that research link too!

@danoliver I’ve thought for some time that creating specific mobile sites and linking to them/promoting them from the main site (mobile or otherwise) is a great solution to many issues. Its certainly no bad thing to have a airline check-in service optimised for mobile, and if the user accesses that knowing what to expect then the intent is correctly met.

@daniel certainly in many real world cases, especially when considering sites with established desktop versions, simply optimising isn’t practical. I wonder how many of those sites could benefit from reduced content on the desktop as well though…

Joe McCann

Great article, but I can’t completely agree with you.

For example, take a webapp like Google Docs. Create a new “Presentation”. Add, modify, edit, etc. A 3.7 inch device with a 320×480 resolution is certainly not the medium for doing such a thing.

Therefore, if you pull up a Google Docs Presentation on a mobile webkit browser, you get the actual presentation as opposed the full feature set of adding/modifying/editing content for the presentation. This is correct.

Google Docs Presentation is just one anecdote, but their are loads of them out there. The key differentiator is that they are mainly web *apps* and not web *sites*. There needs to be a clear understanding between the actual medium used for consuming a web document (like a blog) and a web application (like Google Docs).

“Mind reading is no way to base fundamental content decisions”

With all due respect, no one can read minds, but what one can do is analyze loads of data to make the most educated guess about how to base fundamental content decisions.

A high percentage of mobile usage takes place at the home. What the study does not take into consideration is the total amount of time people are *at* home versus anywhere else. Moreover, when you’re sitting on the couch or lying in bed it sure is much easier to pull out your iPhone/Android to check twitter or search the web than it is to lug around a laptop or get up and move to the desktop computer in the other room.

Myself personally, when I’m not at home, nearly all of my mobile usage is based precisely on my context. Time of day, location, social context (friends with me, alone, etc.).

Basing context *strictly* on the device is a foolhardy move, indeed. But basing on historical user data in conjunction with the device and/or additional items can provide you with the most educated guess on how and what content to serve.

Finally, there is a business proposition that is not covered. What is the cost right now for an airline to fully support a mobile web version of all features for their desktop website? With an ever and rapidly changing mobile landscape how does a large scale organization justify costs associated with constantly hitting a moving target? A trimmed down version of the site with limited functionality may be the best bet economically until the mobile landscape normalizes a bit.

Scott Evans

This definitely seems to have become a hot topic for the day and I agree that we should always look to minimise the number of assumptions we make about mobile visitors. There is a very famous saying: “assumptions or the mother of all fuck ups” and on the whole it appears to be true. However…

This is a little snippet from a Tim Berneers-Lee article entitled “Long live the web” written towards towards the end of last year:

“…That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection. The Web should be usable by people with disabilities. It must work with any form of information, be it a document or a point of data, and information of any quality—from a silly tweet to a scholarly paper. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.”

To achieve universality I think we must make one assumption. At times there will be people with old technology on ropey connections attempting to visit our sites. These people must be catered for and we can use context (location, browser, device) to help make better judgments about our single assumption.

Michael Rose

I’m glad this conversation is getting a good airing. I appreciate the difference between web *sites* and web *apps* and I get very frustrated when sites assume you want a particular version of something rather than presenting the content in a way that suits the device.

@Joe McCann: I don’t buy the GoogleDocs argument, I think it’s probably very common for someone to want to edit a doc or presentation, especially quickly on the road, on the plane, just before a meeting — e.g. new data from marketing needs to be inserted into slide 4 before the big meeting.

Batteries die, desktops and laptops fail, devices are borrowed, there are all kinds of reasons why we’re on different devices.

The Tim Berners Lee quote really nails the philosophy for me.

Peter Cranstone

Mark,

Great blog post. We’ve been working on solving the problem for the last “few years”. In our opinion Context is measured three ways:

1)Who am I
2) What (device) am I using
3) Where am I

All of these elements MUST be captured in real time (whilst preserving the consumers privacy) to deliver context.

We’ve built a cross platform Mobile solution that solves the Context problem, whilst seamlessly integrating with all Open Web Standards.

The solution (while it took a long time to figure out) was very simple. Exactly as Tim Burners Lee would want it to be… According to RFC 2616 the HTTP protocol is extensible. So all we did was to extend it with real time context in the form of a HTTP_X header.

Getting it off the device in real time was also straightforward. Store the meta data in a database and then when the user navigates to a whitelisted site simple inject the new data into the Request Headers.

All you have to do then is read them.

Everything is documented on our web site including demos and white papers and use cases if you’re interested.

Cheers,

Peter
5o9 Inc.

James Pearce

I always thought it was worrying that responsive web design wasn’t sufficiently positioned as ‘Only Step One’. Now I think you are explicitly saying it is ‘Only Step One. Of One’.

Your argument seems to assume that web sites will not allow users to switch experience, and to force one upon them based upon fantasy heuristics.

But who actually commits your ‘Number One Crime’?

If they do, it’s a bug – not proof that we can all arrogantly ignore likely user context.

Indeed I too would also be furious at a ‘broken web’ if I could only get Amazon in German when I have a German IP address. But the fact is that I am always given a choice to switch between Amazon’s international sites. They are merely guiding users to what they likely to need.

Look at it this way: a web property should provide services for users in lots of different contexts. Sometimes you are on the way to a museum. Sometimes you are in it. Sometimes you are in Germany. Sometimes you are not. You often expect different things in different circumstances. What we are talking about here is simply trying to pre-empt getting the best experience to the right user at the right time – saving a click or two of their precious time.

(And, incidentally, if these different services, sites or experiences are keyed off different URLs or subdomains, we absolutely have not broken the ‘one web’.)

kirby.mark

@james thanks for your thoughts, I was waiting to hear from you ;-) … a few points to respond to:

- I didn’t explicitly say of responsive web design “it is ‘Only Step One. Of One’.”. I mentioned for example that on mobile you might want to give some features higher priority based on research – you can’t easily do this with Responsive Web Design.

- I’ve encountered a number of sites over time which have redirected me from a regular url to a mobile homepage, then when I select switch to desktop, I lose the original url and end up on the main homepage. They are doing it wrong by design and it’s still a problem.

- Your point – “incidentally, if these different services, sites or experiences are keyed off different URLs or subdomains, we absolutely have not broken the ‘one web’” are exactly my thoughts, as I mentioned earlier.

- I agree that a web property should provide services for users in different intents of purpose, and they MAY be related to the context. We should consider all these intents, prioritise them for users on all platforms and then allow the user to select, as only they know what they are coming to the site for.

If the user comes to a inner url, their intent is probably clear, they want to access that information. No redirects or alternatives needed.

If they come to the sites homepage and you decide to redirect or reorder based on research into common use cases for certain devices, and provide access to the alternatives, this seems fine.

kirby.mark

@joe thanks for your comments, answering one specific – if an airline (or anyone) doesn’t allow access to the main site from the key url, they might be better off doing nothing. On many mobile browsers it is possible to peck around and use a regular site. I’d prefer something optimised with intact functionality, but no access is worse.

@scott, @michael, @peter some excellent points and ideas.

Great to have some debate around this, from many different angles.

Matt Oakes

I agree with you that for most websites you should try and provide a mobile optimised version of the most used features (check bookings for a plane or whatever). However there should always be the option to get to the rest of the features.

One website which does provide a mobile optimised version but does it quite wrong is Gizmodo UK.

If you open a link from the UK website (such as this one http://uk.gizmodo.com/5772725/holy-hell-the-heinz-dip–squeeze-package-is-available-nationwide) on a mobile device it will add attempt to redirect you to the mobile site (by adding the m subdomain to the start). However this just gives you a 404 error and no was of stopping it auto redirecting you. Very annoying when you get sent a link by email or click on one in Twitter.

As a side note, the US website works fine and does what you expect most of the time. I have had the odd occasion where it redirects to the homepage, not the article, but I can’t find an example link at the minute.

Good article though. Nice discussion around it as well!

kirby.mark

Hi Matt, I think we both fully agree actually. I’m 100% saying you shouldn’t block access to the sites full feature set on mobile. Ideally you would manage the site so that you could provide the same information to mobile users as you would desktop, simply reformatted. Where that isn’t possible, allowing full site access is key and Gizmodo were one example of my “number one crime”, so thanks for reminding me of that one!

Greg

Well.. There are some good points here, but one size fits all content seems limiting as well. People go to their mobile phones in very different scenarios, usually on the go, buying tickets, checking the weather, more specific things, not browsing as much.

Why not deliver custom content to mobile users.? Yeah, you should not make it hard or difficult if they want to find something, but you should also be aware of why people are using various devices.

Leave a comment: