After resisting for quite a while I am finally coming to the point that I realize I need to optimize my work for viewing on handheld devices. I am not sure if the answer is to design as 2 seperate sites (if so I need to learn how to direct the viewing device to the correct version) or to simply learn the dos and don’ts of designing sites that will work well from screens that range from 24" to 2" screens.
I would welcome links to info on this subject.
Thanks,
Cathy
A great way is to allow your users to choose for themselves. On your web page give them the choice to view either as is or a scaled down version of your site on mobile.
Here is a great tutorial to get you started. http://www.developershome.com/wap/xhtmlmp/xhtml_mp_tutorial.asp?page=introduction
Google also has some good documentation on developing for mobile sites.
I created a mobile site for my company and a recent restaurant site with the .mobi extension. Then I created scaled down pages and saved them as .xhtml for view on mobile devices.
Would you suggest having a different domain name for the handheld site or just a url within the main site domain?
I know this question was meant for alex, but I would suggest so.
I would recommend using m.domain.com or mobile.domain.com for all mobile devices.
You could also get specific, and use some examples i have seen, and do touch.domain.com for multi-touch devices. iphone.domain.com for iphone and ipod touch and then ipad.domain.com.
Also in response the the OP’s original question, one could use php to direct to the proper handled site: so in pseudo-code it would be something like if($device=handheld)
{goto(url:‘http://m.domain.com’); }
else()
{
goto(url:‘http://domain.com’);}
Or one could use CSS3’s media queries, but they are not fully-supported by all browsers yet. This would attach a specific styling or css stylesheet to reconfigure the layout based on device or screen reslution or browser viewport size.
Here is a nice article on css media queries
Hope i was of help!
Regards,
Team 1504
I’ll keep it simple so you don’t have to go through all the confusion that seems to occur: What you want to-do is build two separate sites (as adapting a single site for mobile devices is next to impossible due to the wide range of needs both in content, structure, style and behaviour) but don’t redirect users (firstly it’s impossible due to how many devices you would need to account for - approx 218,000 + 15 new ones every week, secondly it’s a bad thing to force your users into anything). The best thing you can do in regards to getting visitors to use whichever service (desktop or mobile) best meets their devices needs is to simply have all users go to the fully fledged “amazing” site (which you would normally have) and then give a notification somewhere visible on the site that a mobile version is available (with a link). By doing this it means that people will get access to your site like normal, and if their device can use the full experience, then great… but if their having issues, they can click and jump to the mobile edition which is slimmed down. If you try to force redirect them and they have a good mobile device, you’re basically dumbing them down on the assumption that their device can’t do what you assume it can’t - which is probably one of the worst things you can ever do!
As for how to produce the mobile page: Reduce the amount of content and images you have (smaller image sizes - scale it down rather than having huge images on-page), only ever have one column (you will have no idea what size screen they will have - it could be a huge iPad or a tiny iPhone), use a liquid layout (no absolute positioning, floating or pixel widths), keep things simple (lots of whitespace, no stuffing tonnes of junk on the page), other than that, look to other examples for best practices! You will also want to test your mobile friendly version in a variety of devices (either real ones or emulated ones). 
Google also references the benefits of developing for mobile.
I do this with my mobile versions. Simple text pages and easy to use navigation through a paging system. No need to re-invent the wheel. You can add a link to your natural web site on the mobile version.
Free is always good but it also never hurts to spend a little if it helps in the end. I have a keyword specific .mobi URL that points to my site. But yes you could also do the subdomain. Never thought of that.
Although biased, I found this interesting tidbit below at http://www.passani.it/gap/ giving the pros and cons of using each.
Because of its widespread adoption on the web, most mobile microbrowsers can render ‘tag soup’ HTML with varying degrees of success. Such generalized support for HTML-based mark-ups has effectively turned HTML into a candidate language for mobile.
Resorting to HTML for mobile development has positive and negative implications for developers.
On the negative side, by adopting HTML, the number of supported devices would be reduced. In addition, some microbrowsers apply heuristics to adapt web content to mobile when the HTML content type (text/html) is encounterd. This can affect the rendering of a page in unexpected ways. Typically, CSS may be ignored and table layout may be disrupted and ‘columnified’.
Apple’s iPhone will assume that a page served as HTML is a page meant for the full web, and will use tiny fonts also for mobile content, thus forcing users to zoom in and scroll in order to make text readable and be able to select links. This will severely diminish the usability of the site for iPhone users.
Finally, HTML would make errors in mark-up go by undetected, yet those errors would negatively impact the page rendering speed, thus reducing the perceived responsiveness of the system and degrading usability.
On the positive side, by adopting HTML, ‘newbies’ would not have to deal with the intricacies of XML-based mark-ups, such as: the need to validate content, adding relatively obscure XML prolog/doctypes to each page, manage the configuration of unfamiliar MIME types and so on.
A significant extra advantage with HTML would be the ability to preview mobile content with all web browsers, including MS Internet Explorer, which notoriously cannot handle the XHTML Mime type properly [XHTMLMIME].
While this document elects XHTML-MP as the mark-up of choice for mobile, it is acknowledged that HTML may represent a viable alternative for hobbists and semi-professional mobile authors.
Nevertheless, this document discourages developers from adopting HTML as a mobile mark-up, since the extra effort required by using XHTML MP is limited when compared to the advantages in terms of rendering speed and number of devices supported.
I also set the correct mime type and char encoding in my .htaccess.
Just food for thought.
That would indeed work (and be a much better idea as you can totally re-scale the content upon the structure), however it’s worth highlighting that the problem I can see with that is the potential for long documents in the mobile version of the website. Small screens don’t just mean rendering issues - there’s also a very real risk of issues in respect to sizes of files (content heavy or image heavy), and end-users will not appreciate having to scroll 1,000 times on the mobile device (that they would have only 20 on the desktop version) - though that number is probably just me exaggerating but you get the point. I maintain that two sets of content (giving the mobile friendly site a slimmed down “excess free” experience - in both design and content) would be the best all round experience.
I recommend a subdomain, most websites are capable of it and the convention is (as team1504 mentioned) either m.yoursite.com or less commonly mobile.yoursite.com (both have wide public recognition) - you could even use a subdirectory such as yoursite.com/mobile/ but I personally feel the subdomain looks more professional (in that it separates the experience). There are also mobile specific TLD’s (like .mobi) which you could purchase for housing the mobile site independently - but I think with sub-domains available for free, it’s a pointless expense as there’s not really much need for the domain TLD (.mobi) to exist!
I love the return of the mobile stylesheets A List Apart article, it highlights the very real problem of trying to render things within the single page (though their solution is no longer workable due to advances), redirecting is non-productive but CSS3 media queries for where they are supported are a fantastic way of making your mobile site even more friendly (you could have one design for iPad’s, one for iPhone’s for example based only on how much space they have available).
Just for the record, little to no mobile devices actually acknowledge XHTML-MP as they have no need for a slimmed down version of XHTML (when they already support it natively), using WML or XHTML-MP is a pointless endeavour - better to stick with conventional HTML or XHTML 1.0 as their both universally covered.
Thank you Alex, that is exactly the kind of info I needed. It makes a lot of sense. Would you suggest having a different domain name for the handheld site or just a url within the main site domain?
Thanks Again,
Cathy
Alex,
What about having a separate file with content, and using includes to pull the content into both mobile and full-size site?
I get the idea to build two different sites, but if I have two sites, it would be nice to have a way to add to the full site and mobile site without having to maintain them as two distinct sites.
Alex, most of what I posted is quoted from an article titled Global Authoring Practices
for the Mobile Web by Luca Passani. He and a group of colleagues have gathered information and wrote the article. Although I don’t agree or disagree with all of the information provided, I am not the one that you say is ‘wrong’. You might want to re-visit the article and offer a debate with the authors on your views.
I do agree the .mobi extension being a waste, I bought the domain for a year to see if it was worth doing. So far at this time, it appears to have no benefits, at least for me. No harm no foul. It was worth $19.99 to register it for a year for testing purposes.
I was going to setup my blog with a subdomain to my site and then I read it’s better to have it as a subdirectory. This makes no sense to me. Why is there a difference with a directory vs. a subdomain?
Regarding the google information, well I trust them to tell me what is relevant and what is not regarding developing for the web. They are the kings for a reason, the anti-thesis of Microsoft.
“XHTML Basic and XHTML MP are almost identical subsets of HTML, used globally, but particularly in North America and Europe. XHTML dialects are the newest and most expressive of markups, and are gaining usage. XHTML Basic 1.1 and XHTML MP 1.2 are a good choice for new development”
All of my sites work perfectly fine on iPhone, Blackberry and Android phones as they do on a desktop browser.
However a desktop version with an abundance of scripts and database connections etc, is NOT going to download as quickly as a scaled down version of a web page if you are stuck with a 3G network with no wi-fi available.
To me XHTML is a nice alternative to this. Is it a be all end all solution? No. It’s basically HTML with a few quirks. So I see no harm in using this type of markup versus using strict HTML.
There is no benefit of a subdirectory over a subdomain, you were right to question that information - it is incorrect in saying there’s a benefit of one over the other.
As for Google, they never actually say that the mobile profiles are inherently any better than using traditional XHTML or HTML, though I do take issue with them proclaiming their more expressive, when the W3C themselves (who produced the specification) clearly state that the mobile profiles ARE slimmed down versions of the actual specification (which means they have LESS semantic elements to use, not more). While they may be gaining usage, it still stands that as all mobile devices now support traditional XHTML and HTML, there’s no point in using the mobile profiles which don’t actually offer any real benefit over their more powerful counterparts. If you want to believe Google’s advice in saying their a good idea, that’s fine (as they will work). but I’ve based my analysis over the lack of use for the mobile profiles on the actual specifications themselves and the W3C’s advice (who produced them). As such, the mobile profiles still remain unnecessary and pointless.
While I agree that it can pay to spend a bit of money (no pun intended) I’ve always thought of .mobi as a pointless excess. Very few people I know (who aren’t tech savvy) have ever heard of the mobi extension (even those who live by their smartphones), and when a simple alternative like a subdomain can achieve the same effect - with less impact upon the end users knowledge (typing m.site.com is easy) I would say it’s pointless to invent solutions where they aren’t needed.
I don’t honestly think it’s worth coding specifically for micro-browsers anymore, the smartphone revolution has wiped out the issue for weak browser support for modern technologies, and over 90% of the world phone market in terms of Internet usage makes use of a browser which supports decent standards (like Blackberry, Android or Apple’s phones). While you may think of it as a candidate language due to now deprecated rendering engines like OpenWave being used by a small minority, I think it’s about as relevant as supporting the dead language WML (which exists but isn’t really the proper web - and it’s not used much either).
As I’ve already stated, this is entirely wrong. 90% of the phone market as it stands today is comprised of devices which support HTML and CSS to the same extent as a desktop browser. As for using table layouts, that is probably the worst thing you can do (as mobile devices were not built to handle layout heavy designs on small screens). It very much seems like you’re working with knowledge that would have been relevant 10 years ago, but the modern mobile device era isn’t nearly as mangled as you make it out too be. Anyone who has bought a smartphone since the initial iPhone (when all the companies began producing complex devices with full internet capabilities) WILL have a solid ability to render most websites without issue, it just pays to have a separate mobile design for those older devices you mentioned and to ensure that users don’t have their bandwidth or screen space wasted. Proclaiming that XHTML-MP is any better than conventional HTML or XHTML is pure fluff.
Again you’re totally wrong, they don’t use “tiny fonts”, they use regular typefaces that scale based on the amount of screen space available, just like any desktop browser. If you’ve ever used an iPad (which uses the exact same browser and renderer) the typefaces will look “normal” because it has a larger screen to draw relative sizing from. As for the need to zoom in, that’s wrong too, you can use the viewport meta element within the header to determine whether scaling should occur.
How exactly does XHTML-MP differ from this? It doesn’t. You seem to be claiming that using HTML in preference to the MP has a wide range of disadvantages, yet most of what you said is factually incorrect. You have no justification to proclaim the MP as anything more than an unnecessary feature (as I said from the start).