phillip_davies, the only one I consider valid is to simply have two versions of the website… a slimmed down mobile edition at (m.yoursite.com) and the main one (for normal browsers). The fact is that handheld stylesheets and CSS3 aren’t well supported (it’s as bad as HTML email!) and htaccess or serverside redirections aren’t accurate enough (there’s over 100 new phones released every week worldwide according to stats - each has it’s own unique ID needing targeting). Even playing the odds no longer works now that Android has suddenly taken grip of the handset market (before we could hedge bets on iPhone alone). So I say don’t make the decision for the user, give them the choice and let them browse as their device supports. Mobile detection is impossible (in terms of feasibility VS usability) and pointless. 
hmmm I wouldnt say mobile detection is impossible or pointless, if Im on my phone I dont want to have to look around for a link to a mobile version of the site I’d want to display straight away. Although i would like the option to view the full site.
Although your comment does answer my question in a way as it is (imo) impossible to support all handhelds, although for newer mobiles with well equipped browsers shouldnt we be supplying them with a user experiance tailered to their device?
The dominos site is a good example as it would be difficult to use on a mobile device if you viewed their regular website but if you view it on an iphone the layout and design is different and much easier to use (i.e. big buttons, listed information).
Apart from providing a link on your main “web” site does anyone else have any good ideas on serving mobile devices with tailered content / design / features? So far to me using either php or .htaccess to detect capable devices seems the best way to do it? (if you do it at all)
You seem to be missing my point, targeting mobile devices should have a relatively equal experience no mater what device they use, if you targeted mobile devices based on the level of support they had, you would need a tonne of JavaScript, CSS, and server-side coding to cope with all possible eventualities (which would degrade the whole experience for everyone). Having a mobile version using the m subdomain or a .mobi domain gives people a convention to follow, and it ensures that bandwidth restricted devices don’t have to load all the size heavy elements of a normal page (just visually tweaked).
In respect to browser detection, if someone has an iPhone which can view the full experience, why would you want to force someone using one to use the mobile friendly page in preference? Making decisions for your visitors is a very bad idea, hence why I am in total opposition to detect and redictects.
The biggest issue in mobile web design isn’t the visual appearance of stuff on the page (most truly modern smart-phones can work around that using progressive zooming or panel navigation), it’s the amount of stuff on the page itself, all those HTML, CSS, JavaScript, Flash, Etc bits and pieces add up… even having a mobile stylesheet will still load the screen one (generally) within the mobile device. Having a scaled down minimal design with smaller sized images, less CSS and Scripting (mobile only) and compacted content (not loads of blog posts per page) will seriously improve the user experience for everyone. You could have as many scripts or redirects or tweaks as you like… but the mobile user will have to burn bandwidth on the full page plus it’s optimizations if not separate.
We both seem to be missing each others points
Im basically saying should we design mobile sites for capable devices which we can easily detect / optimise for and leave the less capable (wap, sans js) devices behind or heavily restrict our mobile sites to accommodate all devices?
The detect is probably the only thing we disagree on as (ive mentioned) the mobile site should be in a different sub domain (eg /m) with a link to the main site if the user wishes to view the full “web” version also I like the idea of including a link to the mobile version of the site on the “web” version.
In regards to the re-direct I think mobile users should be presented with the optimised version of the site first. Mainly as the design will be sympathetic to their device, the assets will be optimised for mobile, they have the option of viewing the main site, mobile users have different needs and circumstances compared to desktop users and it would be very annoying if you had to wait to load the full site before finding the mobile version (most users are not going to know to add an m/ or try .mobi in my opinion!
It’s a difficult subject guess it comes down to the old accessibility vs. design/functionality!
I agree with much of what you’ve said there, though I would probably say that a WAP (WML) website is probably going too far. WML has been officially deprecated by the standards body that wrote it in favour of using conventional HTML. Therefore it’s probably best to avoid implementing such a site (as such devices are rarely used anymore). As for Sans-JS, as long as your design gracefully degrades, it should work without JS anyway
what is wrong with Time on Internet?
Sometimes it’s hard to find the Date of a post wherever online, and now this
" Warning! You are replying to a thread which is more than 12 months old "
ok,
i’ve read the entire thread and it was very interesting.
i was looking for some “standard” sheet for mobile sites to start building one and landed on some sites that convert your site and you get the site and some copyright footer.
if you want the list, let me know and i will post it, most sites you may know.
One of them is interesting because it shows 3 different devices’s reactions to the “mobilized” site or blog.
Are there any Open Source tools to guide you to start building mobi sites?
im new on sitepoint
i browse the interweb since '98
live from buenos aires argentina
hola!