针对移动设备的内容管理系统

发布于 2024-08-13 12:44:15 字数 209 浏览 9 评论 0原文

如果我想为移动设备实施CMS，应该考虑哪些要点？例如，缩小页面尺寸，使用优化的（小）图片。还有其他想法吗？

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

我知道移动设备的容量和属性差异很大，但仍在尝试列出一些规则。

也欢迎就此主题提出任何其他想法、建议、问题和建议。

感谢您的意见和答复。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不打扰别人 2024-08-20 12:44:15

简短的前言，我在下面列出的所有内容都是我工作的公司的主要产品已经做过或已经制定出解决方案，这个答案的整体目标是给你指点。

识别手机

当将移动设备作为网络环境进行处理时，正确识别手机是绝对必要的。这应该是最优先的。以下是识别手机及其功能的几个问题：

不要使用userAgent.contains("iPhone")检测方案。已经有大量网络机器人和其他应用程序包含iPhone 在其用户代理字符串中，因此您会错误地识别它们。
并非所有手机都会发送 User-Agent 标头。但是，其中一些手机会发送 UAProf< /a> URL：包含 RDF 格式的所有手机功能。不幸的是，这引入了接下来的两个问题：
显然您将无法访问那里的每个设备数据并且您必须使用公共数据存储库，例如WURFL。然而，这些数据库不完整、稍微落后或不包含您想要的数据。不过，它们是初始数据集的最佳选择。
UAProfs 撒谎。是的，它们包含虚假信息 - 很多！部分原因是制造商忘记更新 XML:s，部分原因是 UAProf 文件是在手机开发过程中编写的，而我们知道，功能在开发过程中确实会发生变化。
当依赖某项功能时，请确保您不依赖于特定手机的特定版本。例如，黑莓有一个名为 Tile 的功能，它基本上是一个非常漂亮的书签，但您不能仅仅依赖它将其提供给所有 BlackBerry 手机时，您必须识别实际手机的操作系统版本才能提供 Tile 的正确变体。触摸屏也是如此，iPhone 不是第一款配备触摸屏的设备，而且肯定也不是唯一的设备 - 也不要指望设备只有一种输入形式的情况，例如诺基亚 N900 有触摸屏、物理键盘，甚至还有手写笔。

创建实际页面

值得庆幸的是，这是人们已经同意的事情，在创建页面时，您应该使用 XHTML-MP。但是哦，人们多么希望事情能这么简单...

所有手机都有不同级别的 XHTML-MP/CSS 支持。举个例子，如果我没记错的话，一些较旧的黑莓不支持< code>background-color 块元素。或者标题标签。当连续有多个 span 元素时，我们还发现了错误的排序。哦，由于某种原因，表格真的很难。基本上，您必须减少标记/样式技巧。
您无法通过使用功能本身来测试该功能的存在。如果您想检测 JavaScript 支持，您可能会认为仅出于此目的向页面添加一些 JavaScript 就可以了，正确的？不，这会使访问您网站的很大一部分手机崩溃。当然，新手机不会死机，但并不是每个人都在过去 12 个月内购买了手机。此外，每个制造商的移动特定 JavaScript API 也有所不同，另一个例子是，目前至少有三种不同的 API：用于基于 JavaScript 的地理位置检测，其中没有一个可以与其他 API 互操作。

将所有这些添加到正常的 CMS 功能（安全性、内容管理和转换、缓存、模块化、访问者跟踪等）之上，您应该对一切如何影响一切以及您真正的情况有某种了解应该考虑自己制作的成本。

事实上，尽管这有点违背 SO 的一般精神，但我强烈建议您获取一个现成的解决方案例如我们的，并使用它来满足您的网站建设需求。毕竟，我们的产品经过了七年的专业开发。

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.

回复收藏 0 原文