Forum Moderators: open
I've decided to make one of my sites "mobile friendly". I own a Blackberry, so I have a rough idea of what's entailed. Here's the basic design criteria, off the top of my head:-
- 5-10k page size max
- No Javascript
- No images
- No CSS file
- No cookie requirement
- Nav menu at bottom of page
- HTML headers cut to absolute minimum, possibly containing just title and "NOINDEX" tag.
Standard markup basics will be used - H1, 2 and 3 with Paragraph tags only. No stylesheet. My Blackberry marks up pages quite nicely in that way, I've checked.
That would suit me, on the Blackberry. What would suit you on your device?
TJ
I've read the W3C's Device Independance initiative here:-
[w3.org...]
It seems the, somewhat Utopian, ideal is to have just one set of mark up that can be viewed on the widest possible subset of browsers. So no changes - you build pages that from the get go will render equally on mobile or PC based browsers.
Is User-Agent based delivery something that's frowned upon in this context? Does the fact that my pages don't render especially well (they're not bad, just could be better) on mobile devices indicate a deeper design problem?
I have also now found the @media CSS directive (HTML 4.0) and media="handheld" references:-
[w3.org...]
I haven't seen this before and I'm curious as to the best way to use these directives and references to best effect. Anyone doing anything with this?
Thanks,
TJ
1. Let the markup handle it
The first approach is the W3C way, using semantic markup and table-free designs meaning that you are already sending lean and meaningful markup to all devices. The HTML stays the same throughout, whether you are viewing on a regular monitor or a phone screen. The
@handheldThe advantages are that you are making your site device independent, vastly simplifying your management and leveraging web standards to deliver your content to the widest possible audience.
The downsides are that phone/PDA support for CSS, in particular handheld stylesheets, is patchy (with many simply applying screen rules, often badly), and that if you don't differentiate then you may be serving inappropriate content (large graphics, extra text...) instead of a simplified page, reducing your site's usability.
2. Let the browser handle it
In particular, we are talking about modern phone browsers such as Opera [opera.com]. Opera is a leader in this area, and that browser uses small-screen rendering technology to intelligently modify page layouts to display them logically within the narrow confines of a phone screen. This means that you can continue using tables, fixed widths, etc. and the browser will override when needed and do a great job of reworking your site built for 800x600 screens.
The advantages are again that you need to do very little - just let the technology do the work. Same downsides as the standard markup approach - the browser can only do so much to make your site mobile-friendly, and you are relinquishing any control over how your site will function on a small screen.
3. Let the server handle it
This approach is more complex, but can produce good results. It depends on browser sniffing and server-generated output, serving simplified markup and reduced content specifically designed for small screen situations. This can be a redirect to a mobile-content subdomain or domain or user-agent based page generation.
The advantages are that if you can accurately detect phone/PDA users you can tailor the output specifically for them, with lower page weight, reduced clutter and fewer images.
The downsides include the complexity of the user agent identification process (browser sniffing is fallible), and it requires active long-term management to cater for new phone and browser releases. Also if you use a separate URL structure, it can create a duplicate of your primary site unless you are careful to disallow indexing of the mobile-specific content.
Ideally, you will consider a combination of methods - your site should be using mobile-friendly markup which can be used not just by regular browsers and phones, but screenreaders and other devices too. You can test your sites in Opera - just press Shift+F11 in your regular Opera browser. You can also look at detecting common phone user agent strings of IP addresses for phone proxies and tailor your content output from your database to get a better result for those visitors.
What approaches have others used for dealing with phone users? Is anyone testing their sites on small screens?
1. Let the markup handle itThe downsides are that phone/PDA support for CSS.... is patchy
How about a combination of tactics?
Ensure the original markup renders OK on a variety of devices without the CSS file, then use a user-agent based delivery system to deliver pages without the CSS file in the header, if that user is on a mobile device?
2. Let the browser handle itdownsides.......relinquishing any control over how your site will function on a small screen.
I think that downside rules this out. It's preferable to retain that control as it's impractical to test a site design on every single browser you can lay your hands on, so without knowing what it'll look like, it's probably better to be able to rely on "vanilla" markup. The "just keep it simple" approach.
Is it safe enough to assume that non-styled markup will render reasonably well on a mobile screen?
Let's take some example code (I'm particularly interested in hearing from any mobile users for whom this would render badly):-
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Mobile Test Page</title>
</head>
<h1>An example of "vanilla" markup</h1>
<h2>What does it look like?</h2>
<p>It is hoped that this page would render well on pretty much any browser ever built. If it doesn't, I think it would be fair to blame your browser, not my markup.</p>
</html>
3. Let the server handle itThe downsides include the complexity of the user agent identification process (browser sniffing is fallible), and it requires active long-term management
Is it possible to simplify the user-agent ID process by looking for basic Mozilla etc variants and assuming they're not mobile devices?
Also if you use a separate URL structure, it can create a duplicate of your primary site unless you are careful to disallow indexing of the mobile-specific content.
Most sites I've looked at have a separate URL structure (mobile.example.com or wap.example.com etc). It seems a good idea. Duplicate content issues should be easily dealt with by either putting noindex tags in the page or using example.com/mobile/ and banning bots from the sub-directory from within robots.txt (although interesting thread about google indexing anyway over here [webmasterworld.com]) .
Ideally, you will consider a combination of methods
I'm seeing this as the way forward. My current gut-instinct preference is to use very very standard (what I've been calling "vanilla") markup and just not serving the CSS file to mobile users.
TJ
I'm going to re-iterate your questions so they don't get lost and add one of my own:-
I'm a co-founder of a discussion group about WAP from back when we had "our own markup", and WML/XHTML/HTML convergence is not a new topic. The first made-for-mobile site/service I set up was for a travel destination website. I figured: what are mobiles good for? Calling phone numbers. I made a WAP site that contained tourism sites, restaurants, hotels, alarm calls, credit card theft reporting numbers etc. with links that you can click directly on the WAP page, and your mobile dials the number of the place you're interested in.
When you go for full convergence and use HTML/XHTML then you lose that kind of functionality. Most mobile developers send content based on for one thing the UA reported, and have several differently sized images depending on the receiving model. Convergence is great - if you don't lose functionality. Another of the founders of the discussion group resigned from the W3 workgroup because he was frustrated by the lack of understanding of the level of adaptation that is necessary in the real world for mobiles.
PDA's are another thing. I just visited this thread unsig my iPaq, and it looked quite good. Hadn't considered visiting WW like that before, but I will now. :-)
How can you display ads?
I have tried to shy away on mobiles because you can't monetize on them.How can you display ads?
Not everything on the internet is dependant on ads for revenue, much to some people's utter disbelief.
Informational sites, or even (properly done) ecommerce sites are perfect candidates for conversion to mobile devices. If you are away at a relative's house for an extended vacation and need to order something from the internet, you can do so on your mobile and have it shipped to you. Just one of many many examples.
I have tried to shy away on mobiles because you can't monetize on them.How can you display ads?
Think of it as an investment for the future.
If you can get a stranglehold on your niche now then you'll be in a perfect position to profit from it when the technology improves and the gold rush starts.
Amazon was founded in 1994. It took them a long time to start making a profit.
DoingItWell makes an important point - the small screen is not just an issue when it comes to layout, but also to the kind of content and the length of pages required for an optimal mobile experience. Just as you can't transpose a magazine or newspaper format to the web, if you simply use your standard pages then you are not adapting to the medium. So is brevity as important as simplicity?
example:
mobile.widgets.com
widgets.com/mobile
Any others? Which is best? Opinions?
There's an awesome PHP class that knows what all 800+ mobile variations are and their limitations, lets you query whether the user can accept certain things so you can build a combination of markup and server side differences.... cant remember what its called tho
[phpclasses.org...]
and about this...
Nav menu at bottom of page
he also sez you should put your navigation links on top of the page. but put a "skip to content" link somewhere near it ( e.g. the webstandards.org site ). hehe, now I understand what those links are used for.
[mtld.mobi...]
This is where the future is. Backed by Google, Microsoft, Nokia, Samsung, Ericsson, Vodafone and a bunch of others.
he also sez you should put your navigation links on top of the page.
That's interesting. I can only speak on the basis of personal preference, which is to have them at the bottom.
I guess it depends a lot on the content and how easy it is to get to.
I like the anchor idea - skip to content, though.
The .mobi TLD has been created just for that.
If you have a registered trademark name, registration for .mobi opened yesterday (12th June) - general registration starts 21st August 2006.
