Question

If I want to implement CMS for Mobile Devices, what kind of points should take into account?
For example, make page size smaller, use optimized (small) pictures. Any other ideas?

Also what kind of rules can be applied while converting web-pages that WERE designed for Desktop Browsers, to the ones that are easily displayed in Mobile Browsers.

I know that Mobile Devices widely vary in there capacity and property, but still trying list out some rules.

Also any other ideas, suggestions, questions and advices are welcome on this topic.

Thanks for your opinions and answers.

Answer 1

Short foreword, all the things I’m listing below are something the main product of the company I work for already does or has worked out a solution for, the whole goal of this answer is to give you pointers.

---

Identifying the phone

When dealing with mobile as a web context, it’s absolutely imperative you identify the phone correctly. That should be the highest priority. Here’s couple of issues with identifying phones and their features:

• Do not use userAgent.contains("iPhone") detection scheme. There’s already loads of web bots and other applications which contain iPhone in their user agent string and thus you’d identify them incorrectly.
• Not all phones even send User-Agent headers. However some of those send UAProf URL:s which contain all the phone’s features in RDF format. Unfortunately this introduces the next two problems:
• Obviously you won’t have access to every single device data out there and you’re bound to use public data repositories such as WURFL. These databases are however incomplete, slightly lagging behind or don’t contain data you’d like to have. They are your best bet for initial data set though.
• UAProfs lie. Yes, they contain false information – lots of it! Partly this is because the manufacturers forget to update the XML:s and partly because the UAProf files are written during the development of the phone and as we know, features do change during development.
• When relying on a feature, make sure you’re not relying on a specific version of a specific phone. For example BlackBerry has a feature called Tile which is basically a really fancy bookmark but you can’t just serve it to all the BlackBerry phones, you have to identify the operating system version of the actual phone to serve the right variation of the Tile. Same goes for touch screen, iPhone wasn’t the first one with touch screen and most certainly isn’t the only one either – also don’t expect a situation where the device has only one form of input, for example Nokia N900 has a touch screen, physical keyboard and even stylus.

Creating the actual pages

Thankfully this is something people have agreed upon and when creating the pages, you’re supposed to use XHTML-MP. But oh how one would wish things were this easy…

• All phones have differing level of XHTML-MP/CSS support. As an example, if I remember correctly, some older BlackBerries don’t support background-color for block elements. Or header tags. We’ve also seen incorrect ordering of span elements when there’s several in a row. Oh and for some reason tables are really hard. Basically, you have to go low on markup/styling tricks.
• You can’t test the existence of the feature by using the feature itself. If you want to detect JavaScript support, you could think that adding a bit of JavaScript to the page for that purpose alone would work, right? Nope, that crashes a significant percent of mobile phones visiting your site. Sure, new phones don’t crash but not everyone has bought their phones in the last 12 months. Also mobile specific JavaScript API:s differ per manufacturer, as yet another example there’s currently at least three different API:s for JavaScript-based geolocation detection, none of them interoperable with the other ones.

Add all these on top of normal CMS features (security, content management and transformation, caching, modularity, visitor tracking and whatnot) and you should have some sort of picture of how everything affects everything and how you really should consider the cost of making your own.

In fact even though this is sort of against the general spirit of SO, I’d strongly suggest for you to get a readily made solution such as ours and use that instead for your site building needs. After all, our product has seven years worth of specialized development under its hood.