David Storey
Mon, 21 Jul 2008 07:23:10 -0700
On 21 Jul 2008, at 14:52, Keryx Web wrote:
All right. I will stop complaining about "designing for the iPhone" and try to attack this from a positive angle.How can we go about making our mobile websites according to sound principles. Bearing in mind that mobile browsers often lack the features we wish they had. Borrowing the terminology from Yahoo:
It is hard to say. I'd ask, do you really want to make a mobile version in the first place? Same issues hold true about making a specific mobile version as does with making a specific print or accessibility version. In many cases giving the regular desktop version is as good or better, plus any optimisations done for mobiles can also benefit those with disabilities as there is a lot of synergies between making a site accessible and making it mobile friendly. We at Opera also experience a huge flood of bug reports every time a site blocks our mobile version from accessing the regular version of a popular site and give it a reduced version. Our experience is most users want the regular version and don't like reduced mobile versions. Your milage will vary on a case by case basis however.
You can also use media queries and/or handheld media to optimise styling for mobiles (you can give a different style to menus to avoid the issue browsers like Mobile Safari has with not supporting :hover for example) .
If the best option turns out that you want a mobile site, and can cope with the overhead in maintaining two web sites, then a) always make sure you give the user a way to access the regular version if they do so choose to (and not hidden away where it can't be found), and b) don't remove too many useful features.
There is a W3C document on Mobile Web Best Practices, from the Working Group that I've just become a member of. The URL is http://www.w3.org/TR/mobile-bp/ and the mobileOK checker is at http://validator.w3.org/mobile/
These seem to be restricted to mobile specific sites and to the baseline of support, as they recommend XHTML Basic and using no JavaScript, which almost excludes regular web pages that have been made mobile friendly, and high end mobile browsers such as Opera Mobile, Opera Mini and WebKit based browsers can cope with more than what is recommended.
More or less the same as desktop browsers. Transcoded browsers will have some issues with JavaScript that requires user interaction as they are compiled on the server, but can cope well with regular DOM scripting.- What is the current baseline of A-grade browser capabilities?
Difficult as there are so many mobile browsers, and depends what market you want to target. It is easy to say to exclude any browser that can only cope with WAP (WML). W3C MWBP recommends XHTML Basic 1.1, so I would think that should be a base-line at the very least. It should probably be higher in my opinion though.- What browsers should receive A-grade support?
There is also the case of which browsers are the most popular as you don't want to cut off the most potential visitors to your site (one of the reasons why IE6 is still A grade).
This link http://theregoesdave.com/2008/07/18/iphone-users-only-a-small-percentage-of-overall-mobile-we/ shows the most popular OS on the mobile web (hint: not iPhone), from that studies point of view (always take stats with a pinch of salt, they never even agree with each other), but doesn't show which browsers are being used. From the information we know, Opera Mini is very popular in the US with Palm and RIM Blackberry users (the default browsers are not exactly standards compliant modern browsers).
Many of the basic browsers will not render the CSS (or do it very badly) and wont process the javascript, so as long as you use progressive enhancement and semantic well structured XHTML then that may be enough, but there needs to be more studies on what all of these browsers support. You can, if building mobile specific versions, apply the Mobile Web Best Practices, and progressively enhance for better browsers such as Opera and WebKit. I'd recommend not using browser sniffing at all possible as that is not scaleable and often breaks. For CSS you could add CSS with media queries (modern browsers support media queries), so the low end browsers will not be able to read the CSS- and you can even check for larger screens and give different styling for those screens. For JavaScript you can just use Object Detection.- How do we on purpose disable CSS and/or JS for our C-grade browsers?
- Should we perhaps have A-grade (Safari, Opera, Fennec and ?) and B- grade (MSIE Mobile, Netfront, Blackberry, Dillo, Obigo???)- And perhaps A- (for devices without a pointer and cursor)? Oh, and while we are at it, check this out: http://www.w3.org/WAI/mobile/experiences-new Lars Gunther ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
David Storey Chief Web Opener, Product Manager Opera Dragonfly, Consumer Product Manager Opera Core, Mobile Web Best Practices Working Group member Consumer Product Management & Developer Relations Opera Software ASA Oslo, Norway Mobile: +47 94 22 02 32 E-Mail: [EMAIL PROTECTED] Blog: http://my.opera.com/dstorey ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************