针对移动设备的内容管理系统 [英] Content Management System targeting Mobile Devices

问题描述

如果要为移动设备实施CMS，应考虑哪些方面? 例如，使页面尺寸更小，使用优化的(小)图片.还有其他想法吗?

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?

在将WERE为桌面浏览器设计的网页转换为易于在移动浏览器中显示的网页时，可以应用什么样的规则.

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.

感谢您的意见和答案.

推荐答案

简短的前言，我在下面列出的所有内容都是我所服务的公司的主要产品，已经或已经为该公司制定了解决方案，这个答案的整个目标是为您提供指示.

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.

在将移动设备作为Web上下文处理时，绝对必须正确识别手机.那应该是最高优先事项.这是识别手机及其功能的几个问题:

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:

• 请勿使用userAgent.contains("iPhone")检测方案.已经有很多网络漫游器和其他应用程序的用户代理字符串中包含iPhone，因此您可能会错误地识别它们.
• 并非所有电话都甚至发送User-Agent标头.但是其中一些电话发送 UAProf URL:包含 RDF 格式的所有电话功能.不幸的是，这带来了接下来的两个问题:
• 很显然，您将无权访问那里的所有单个设备数据，并且您将不得不使用诸如诺基亚N900 具有触摸屏，物理键盘甚至是手写笔.

• 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.

谢谢您，这是人们已经同意的事情，在创建页面时，应该使用 XHTML -MP .但是，哦，人们多么希望事情如此简单...

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...

• 所有电话均具有不同级别的XHTML-MP/CSS支持.例如，如果我没有记错的话，某些较早的BlackBerries不支持background-color块元素.或标题标签.当连续多个元素时，我们还发现span元素的顺序不正确.哦，由于某种原因，表真的很难.基本上，您必须降低标记/样式技巧.
• 您无法通过使用功能本身来测试功能的存在.如果要检测对JavaScript的支持，您可能会认为仅为此目的在页面中添加了一些JavaScript会起作用，对吧?不会，这会使访问您网站的大量手机崩溃.当然，新手机不会崩溃，但并不是所有人都在最近12个月内购买了手机.每个制造商的移动专用JavaScript API也不同，例如，再有一个示例，目前至少存在三种不同的API:用于基于JavaScript的地理位置检测，但它们之间无法互操作.

• 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.

将所有这些添加到常规CMS功能(安全性，内容管理和转换，缓存，模块化，访问者跟踪等)上，您应该对所有事物如何影响所有事物以及您真正应该如何考虑制作自己的成本.

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.

事实上，即使这与SO的一般精神背道而驰，但我还是强烈建议您获得一个容易解决的解决方案(例如我们的解决方案)，并将其用于您的网站建设需求.毕竟，我们的产品在引擎盖下需要进行长达七年的专业开发.

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.

这篇关于针对移动设备的内容管理系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！