JavaScript archives
Compatibility
CSS coaching
Thidrekssaga
QuirksBlog
Donations
Politics
Mobile
About
COH
While attending Brian Fling's presentation on desiging for a mobile phone, I suddenly had an idea that might solve one of the problems he mentioned. I thought I'd document it immediately, before tonight's beer will cloud my mind and make me forget all about it.
If you want to use only one site for both mobile devices and desktop computers, you'll be running into the following problem: You probably don't want to show most of the data on the page to phone users. For instance, showing the main navigation will only confuse them, since it'll contain far too many links for easy use. Instead, they'll only want to see a contextual navigation. Similarly, you don't want them to see images because they'll take up far too much screen real estate.
Brian pointed to two possible solutions: build a mobile and a desktop version of the same website, or hide the elements by CSS (display: none on the main navigation, the images, etc).
I don't like the first solution; it kind of defeats the interoperability principle, and it costs more time and money, too. Although the second option looks promising, there's a problem with it, The users will still download all the data, including the stuff they'll never see, because the HTML will still be in the page. Since most phone operators charge per Mbyte of downloaded data, mobile phone users will effectively pay for content they never see (and shouldn't see).
I had an idea that can possibly solve this problem. I think we should try the following:
Sort of like
<html for desktop AND mobile>
<php: if not mobile browser { >
<html for desktop only>
<php }>
In this way you can restrict the mobile phones to downloading only the information they really need,
Despite quite liking the general idea, I see three problems with this solution:
float-based layouts become much more difficult. You have to somehow move up the navigation to the top of the page. That's not impossible, but it's not exactly easy either, especially if you don't want to use JavaScript.Regardless, my solution may be too complicated. When you're using PHP or whatever, you might opt to create two versions of the site anyway and use the browser detect to point to the user to the right one.
Thoughts?
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Comments are closed.
1 Posted by Joost de Valk on 12 March 2007 | Permalink
Yes, this would break spidering by bots, and would probably be seen as cloaking by the search engines... Not a good thing, I think...
2 Posted by Daniel Parks on 12 March 2007 | Permalink
This could make it easier for the web designer by writing a generic script that parses the CSS and then strips out all elements that start as display: none.
Of course, if you want to send hidden elements to the phone (to be displayed via JS), this won't work.
Alternatively, you could have the view layer of your CMS do it. That's more like writing two separate versions of the page, though.
I think this will cease to be a problem before too long — mobile plans will allow more data, and phones will have better screens. Hello iPhone.
3 Posted by pauldwaite on 12 March 2007 | Permalink
> "this would break spidering by bots"
How? Only if a bot is pretending to be a mobile device - and even then there's no suggestion that we make content unavailable, just some navigation.
I'm not quite sure this is the way to go. It's a neat idea, but I think either make your site slim enough that it's fine on a mobile (do we really need all that navigation in the first place? http://www.goodexperience.com/blog/archives/000028.php), or bite the bullet and put some serious interaction design thought into a separate mobile version of your site, that purely solves the needs of mobile users.
4 Posted by wioota on 12 March 2007 | Permalink
I tried to think of a few ways to do it (try overload the noscript tag with the mobile content, for instance) but all were very flawed. I wonder if the requirement to send down different content doesn't just point to a general requirement to do all the work on the server side. Some mobile browsers are designed to just consume special mobile-specific content well but more and more you see mobile browsers which seek to be able to consume standard web content and push it into a workable format for consumption. For those browsers it may be preferable to just serve up the standard page in most cases...
5 Posted by zcorpan on 12 March 2007 | Permalink
This just looks like an implementation detail to having two versions of your site. You effectively get two versions.
I'd suggest serving all content to everyone, then hiding whatever you don't want to appear in mobiles with CSS, and then use gzip compression for markup and style sheets, which will save the additional bytes you would by cropping the content anyway. Cropping and gzipping won't save you many bytes compared to just gzipping.
6 Posted by Andrew Ramsden on 12 March 2007 | Permalink
This may sound like a crazy idea, but here goes: Why not just have simple primary navigation and context-driven secondary navigation for eveyone?
That way the site is usable and universally accessible from any device.
If you want to then provide magnificant flyout/dropdown multi-level navigation for desktop visitors, consider it a "progressive enhancement" and take an AJAX/HIJAX approach.
For extra usability points: Give the user an option to turn off the HIJAX menu and/or have it off by default for mobile visitors.
This would save visitors the extra bytes...
...just an idea...
7 Posted by Nathan de Vries on 12 March 2007 | Permalink
This might be a useful case for the "303 See Other" redirect. Take requests for site.com and redirect them to mobile.site.com if they are a no-doubt-about-it mobile client. Otherwise, load the full page with navigation items up the top which link to the mobile version of the page.
That's how I'd approach it, anyway.
8 Posted by Binny V A on 12 March 2007 | Permalink
I would use a different template for mobile users. Since the data is coming from a DB(as in my case), there won't be much redundancy.
PHP has a '$_SERVER["HTTP_USER_AGENT"]' that provides the name of the browser. That could be used to find whether the user is on a mobile or a desktop browser.
My code(the controller) will look something like this...
if($mobile) {
$template->render('mobile.php');
} else {
$template->render('default.php');
}
Thats what I will do.
9 Posted by Scott on 12 March 2007 | Permalink
I was recently doing some mobile browser testing (Pocket Internet Explorer and BlackBerry), and I had an issue with the BlackBerry not applying stylesheets regardless of method (even though BlackBerry supposedly supports stylesheets). I had to hide a bunch of images in the header and ended up having to check the user agent string for the existance of "BlackBerry" (it occurs at the beginning). Any mobile browser that isn't going to follow standards needs to be dealt like this IMHO. I'm open to doing it another way but can't think of one.
10 Posted by Marko Samastur on 12 March 2007 | Permalink
I'd be very surprised if all (most?) mobile browsers support gzip. So relying on it to solve bandwidth problems seems wrong.
Anyway, which mobile website are you talking about? The one I might read while commuting on train, with all the time in the world (well, at least until the stop) or the one I'd use while being on the move and trying to find a particular information?
I'd be very surprised if later case mobile site shared even navigation with a "desktop" version.
11 Posted by ppk on 12 March 2007 | Permalink
Andrew: Good idea! I'm not sure if it would solve all problems, and supporting noscript desktop browsers would become a challenge, but nonetheless your idea has merit.
Scott: Writing the actual browser detect is definitely going to be a HUGE problem. Right now I'm kind of assuming we will have a reliable one, since we're going to need one anyway.
Or can you somehow detect mobile style sheet support? That would be the most object detection-like solution.
12 Posted by Grey on 12 March 2007 | Permalink
If the mobile browser is Opera, it won't even start downloading elements with display:none ... that most desktop browsers do that is actually a design flaw... if you want to "hide" stuff (so it'll be loaded, but not rendered) you can always use visibility:hidden and height: 0px and width: 0px.
Opera Mini even has a server backend that filters out the useless stuff, so phone users only download what is absolutely necessary...
13 Posted by Terren on 12 March 2007 | Permalink
The solution I've been using is to use a different CSS style sheet for handheld devices. For example:
if ($handheld)
echo "<link href='style_handheld.css'>";
else
echo "<link href='style.css'>";
I have found that there are a lot of rendering bugs in handheld devices, requiring far simpler layouts, so this allows me to simplify the layout without writing creating two different sites, or otherwise writing a lot of redudant code.
Occasionally I have to write PHP code along the lines of:
if ($handheld)
do_this(); // i.e. hide something
else
do_that();
but these are mostly in the header and footer sections of the page. The meat of the application is identical for both kinds of clients.
14 Posted by Joost Diepenmaat on 12 March 2007 | Permalink
Maybe I'm oversimplifying, but it seems to me that the biggest reason you want another layout for mobile devices is because of screen size.
So why not base your script on that - i.e. check out the available screen size, and serve the "mobile" version if the window is smaller than, say 500 x 500 or so, and load a bigger additional stuff if the screen space allows. This will also allow visitors to downscale their browser windows while still having the "essential" content available.
I can name a few problems with this approach (mostly, what to do if javascript isn't available - by the way - some mobile devices report the screensize directly to the server via the user-agent header) but it might be an interesting approach.
15 Posted by Vasil Rangelov on 12 March 2007 | Permalink
It is times like this that I'm prowd to call myself an "XSLT fanatic". XSLT in conjuction with PHP can do EXACTLY what you're asking, and a lot more.
XSLT can contain parameters. Those parameters can be adjusted at runtime and based on the value passed, XSLT can change something from the output (the XHTML layout).
So, this makes the PHP code something like:
(gThen)(qMark)php
$xml = new DomDocument;
$xsl = new DomDocument;
$proc = new XsltProcessor();
$xml->load($xmlFile);//How exactly to get the XML file's URL is another story
$xsl->load($xsltFile);/* Add "if"s around this to select a different XSLT. */
$xsl = $proc->importStylesheet($xsl);
if ($mobile) {
$proc->setParameter(null, "device", "mobile");}
print $proc->transformToXML($xml);
?>
The issue remaining is detection itself. How about detecting support for WML's MIME type? If that MIME type AND (X)HTML's are supported, do the above. If only WML, use another XSLT specifically for WML. If only (X)HTML is supported, use the desktop version without this paramter (or with a different value). After all, even modern mobile browsers support WML as far as I'm awared. I would write this negotiation in the code, but I'm almost out of space now.
16 Posted by Adnan Siddiqi on 15 March 2007 | Permalink
first we should decide tht whether we are talking about WAP/xHTML browsers or modern mobile browsers who can now run javascript and other complicated elements. There is Mobile IE and Opera so user agent might not be helpful.
In case of WAP browswers which are very restricted, there is a Server variable "$_SERVER["HTTP_X_WAP_PROFILE"]" which I used to detect a mobile based browser. The condition which I used was something like:
if($x_wap_profile=="" ||$x_wap_profile==null ){
//print "This is not a Mobil Device";
}else{
//print "This is a Mobil Device";
}
and this worked pretty fine for me.
17 Posted by Tourist on 15 March 2007 | Permalink
You can check for a browser as you said. HTTP_QUOTE_VARIABLES are our choice. Also we can make brutally - on the main page ask what surfer is using - mobile phone or desktop and then load information dependant on his choice
18 Posted by Sander on 16 March 2007 | Permalink
I agree with zcorpan. You're actually creating 2 different versions of the site. So why not use 2 different templates then?
I guess that'll cost less time (and money) than the option you propose, because you can easily match the structure of your code with that of your layout (assuming your layout has a logical structure of course)
19 Posted by Stuey on 16 March 2007 | Permalink
You also need to make sure that you are not breaching any of google's TOS by serving different content or javascript redirects. I'm sure that they will however understand that it is for a mobile if you make it clear!
Alternatively why don't you use a .htaccess rewrite condition or redirect, based on the different types of mobile agents?
Stu
20 Posted by Justin Stockton on 17 March 2007 | Permalink
The WURFL project on SF (http://wurfl.sourceforge.net/) should do exactly what you want to do. It is server based and allows you to conditionally control how your your site is presented based on what features a given phone supports. Its still a work in progress and support for new phones is user contributed so the list might not be 100% correct, but it should get you most of the way there.
- Justin
21 Posted by Andreas on 3 April 2007 | Permalink
I agree that using different templates sounds like an easier sollution than a lot of if/else.
Although i strongly believe all users should get exactly the same content (with different styles ofcourse).
Regarding mobile-detection, couldn't one simply import a media="handheld" style that sets #foo {background: red;} and then use JS to check whether #foo's background IS red or not?
If it is, it's a handheld, if not, it's not.
(I don't really like the additional html-element this would require in the markup, but since JS would be required for this to work one could add the div using JS aswell).
Do you think that could work, or am i just way too tired to think clearly?
22 Posted by James DP on 4 April 2007 | Permalink
If we're talking about pragmatically reducing the amount of data sent to mobile users, I'm with Justin re WURFL: With a reliable mobile browser detect you could "virtually page" the long page by simply splitting it server-side for mobile user agents and adding a link to the whole page or next part on the fly e.g. longPage.php?virtualPage=2 etc...
That way search engine spiders can spider the real page and the user can load bite-size chunks until they find the relevant bit.
Ideally it'd be nice if Google Mobile could be fed the "virtually paged" page so mobile searches went straight to the relevant "virtual page"...