views:

145

answers:

3

Hi, all.

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.

+1  A: 

A couple that we used ...

A cms targeted for mobile devices should be able to detect the device type and detect (or have a database of) screen resolutions so that content, particularly images, can be scaled appropriately.

The rendering engine should also be able to determine if the device can handle HTML or WAP and switch markup languages appropriately.

Paging capability on the output as opposed to rendering very large pages (if content mages are large) is also helpful.

Clean integration with the corresponding web site CMS (so content doesn't need to be dual produced) is also helpful if tere is, in fact, a corresponding large form web site.

James Conigliaro
+1  A: 

Hello

You can look at http://51degrees.codeplex.com it is free open source asp.net mobile api which helps is tracking whether request is coming from mobile devices and redirects user to mobile optimized .aspx pages without changing any existing web pages. It makes use of WURFL the most upto date mobile device database. Along with this it also gives you detailed capability information of mobile device making request which you can use to customize pages for each mobile device.

You can see articles for same here http://dotnetslackers.com/articles/aspnet/Mobile-Device-Detection-and-Redirection-Using-ASP-NET-MVC.aspx

Amit Patel
The first link claims I'm using SonyEricsson P1c. Nuh-uh, I'm using Opera 10.
Esko
+1  A: 

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.

Esko
Esko, I think you could link to your company's product, maybe in the last paragraph. I don't think that would be against the general spirit of SO. IMHO the general spirit of SO is to solve problems, and sometimes it's cheapest to buy rather than build.
MarkJ
@MarkJ: We don't currently sell our CMS as-is but as a solution including related service building etc. Besides our current web site looks awful, as soon as it has been redesigned I may come back to add a link.
Esko