Ten reasons to support the mobile Web

[Alexander Turcic]

Mobile Design editor Brian Fling has posted ten reasons why he believes every Web publisher should be considering support for mobile devices.

With the mobile product lifecycle is moving twice as fast as computers at their peak ten years ago, mobile publishing will soon be a requirement of doing business. Hype aside, there are really good reasons why you should be looking at your mobile publishing strategy… now.

It shames me to say that Mobileread is still far from being mobile-friendly. Everyone who had his device already crash while trying to download our bloated frontpage knows what I am talking about. Take my word for it, either we'll solve this problem very soon, or we're going to fire our current Web admin (that would be I).

[via Threadwatch]

[Chaos]

You like using that C-series Zaurus image for mobile web things, don't you?


The most efficient design for mobile websites is to use, mainly, CSS for layouts. A large CSS file, a small actual HTML file. Bunch of small <div> and <span> tags, which are empty HTML elements for those who don't know, and define how/where they appear in CSS.

As I said in another post, many handheld browsers don't support the handheld media type, which means you have to jump through some hoops for easy mobile support.

The best way I've found is to use the handheld media type where possible, but also add a way for the stylesheet to be switched by an if statement. Using sessions makes this partly saved, and using cookies would make it entirely save-able. And for convenience, one can have a "mobile.php" or similar file, that defines the session variable, and then redirects to the index page.

That's sort of 'mobile.php' is only a few lines of code. For example:

PHP Code:

<?php
session_start();
$_SESSION['mobile'] = 1;
header("Location: index.php");
?>

I dunno, that's just the way I've figured out to get around the serious deficiencies in mobile browsers. Unfortunately it still loads images, without displaying them, as I also noted in that post, even if img { display: none !important;} is in the CSS... At least that's the way browsers I've tested behave...

You could theoretically use user agent detection, but I'm personally wary of using user agents for anything like that - what happens if/when you run into a new mobile browser? You'd have to add it's user agent to the 'check list'... And user agents *aren't* the most reliable things ever...

[rlauzon]

We are tackling the user agent issues at work when dealing with mobile devices.

One big problem is that the user agent doesn't necessairly tell you what you need to know.

Case in point: The 320x240, 320x480 and 800x600 WinCE devices (the first 2 handhelds, the 800x600 a tablet) all report the exact same user agent string.

Obviously, we can treat the 800x600 device like a PC, but have to provide specialized content for the other two.

What we decided to do was create a pre-page that uses java script to get the client screen resolution, and, based on that information, redirect the user to the appropriate version of the web application.

[hacker]

<rant>
Please stop trying to detect UserAgent and switch your page based on that. Its getting a bit old now.. and it doesn't work in 99.999% of the cases you'll need it to work.

Seriously, there is absolutely zero difference between a "mobile" and a "desktop" webpage, if you design your site properly, and that site design does NOT include sniffing HTTP_USER_AGENT, using Javascript, or having a second duplicate page in "mobile" format.

This whole "mobile web" and "How to build webpages for mobile devices" FUD is really beginning to get frustrating. Its like using tables for layout.. they weren't designed for it, and if you use tables for layout, you're using a crutch.

If you have to make a second physical webpage for "mobile" devices, you clearly don't know what you're doing, so its a crutch.

Learn how to design webpages and mobile content properly for ALL devices (that is, one page, one set of content that looks and works great on ALL devices; past, present and future), and you'll see how much easier it is, with significantly more flexibility in your designs and much less maintenance overhead.
</rant>

[Chaos]

Originally Posted by hacker

Learn how to design webpages and mobile content properly for ALL devices (that is, one page, one set of content that looks and works great on ALL devices; past, present and future), and you'll see how much easier it is, with significantly more flexibility in your designs and much less maintenance overhead.

Out of curiosity, does your aversion to, basically, different pages, extend to using different stylesheets for mobile devices, or giving users a choice of what stylesheet to use? Or is your opinion that only entirely different pages a 'bad thing', and doesn't include stylesheets?


(Slightly offtopic below this point. )

Originally Posted by hacker

if you use tables for layout, you're using a crutch

I was very, very guilty of that 'offence' for a great deal of time... *sweatdrops*

But I'm clean now! No more tables for me! Tableholics Anonymous, maybe?

(Well, except for their intended use - data organization. )

[Antoine of MMM]

I understand the poster that is all but fed up with making seperate versions. I am working on trying not to do that for a large client that I am working with now. The trouble is taking a design that was deisnged in tables and spacer gifs and making it work. Unfortunately, that is easier said than done.

We do have a really fun script that we will try though that will send the text version of the page to any browser that is less than VGA, and then we have two other versions, one for 800x600 and one for larger (basically the front page has a pic and we needed to fill up the screen for some older users). If this works, we will have a script (perl) and then only one site to deal with. God only knows that this is only a parttime solutoin, the CSS one is the one that would work best.

[rlauzon]

Originally Posted by hacker

Seriously, there is absolutely zero difference between a "mobile" and a "desktop" webpage, if you design your site properly,

In my experience (and I write web-based applications for a living, many of which run on handheld devices), this is completely false.

Handheld browsers often do not support all the features of the desktop browser. Case in point: the Pocket IE on Symbol devices happily ignores most STYLE= options.

Also, the customer expectations of each type of app is different. Customers don't want to (or in the case of where I work "can't") scroll around on the screen trying to read the information that they need. Since a mobile screen simply has less real estate than a desktop screen, that means that I can't just reformat the destop screen to put on the mobile screen - I have to change how the web functions, leaving off data from one screen and moving some data to others.

Another case: most handheld browsers either do not support multiple browser windows (or don't handle them well at all).

On the desktop, I can open multiple browser windows to allow the user to control what he wants to see. I don't have that option for the handheld - which means that I need to do a different design.

Making an app (other than a simple data display) work for a handheld and a desktop is far more involved than just a style sheet. You can make one app work for both - if people don't mind your web using only 1/4 of their desktop screen.

[philws]

Originally Posted by rlauzon

Handheld browsers often do not support all the features of the desktop browser.

No kidding.

The company I work for have a product that is dedicated to taking a neutral markup representation of the page content (very similar to XHTML2) along with thematic (style) and (gross) layout information (both of which can vary by device) and translates and combines them to generate markup appropriate to the device.

This includes device recognition based on user agent and other profile information, automated generation of "dissected" pages when the page would be too big for the device, and tailoring of the output leveraging a repository that describes the capabilities of the device in detail, selected from literally thousands of mobile (and other) devices.

This would not be needed, and our company wouldn't be trading, if addressing the mobile web were that simple.