‘WAP’ 分类的存档
-
探索移动Web网页编码设计
如果你正准备为你的网站制作一个移动设备版本,那这篇文章将会对你相当有用,在本文中,将探索移动Web网页编码设计的各种技巧和注意事项:
* 为了移动设备上的用户体验可以被接受,代码得怎么设计。
* “Mobile Web”与普通网站的不同之处?
* 可以让网站成功运行在移动设备和桌面浏览器上的基本技巧
* 一些Mobile Web设计中的建议和禁忌、以及大量资源Mobile Web和普通网站到底有何不同呢?
这是个很好的问题 – 首先,也许我们应该从“什么是Mobile Web”的问题开始。毕竟,用户用移动设备访问的Mobile Web,跟他们在家里用台式机访问的网站是独立的不同的部分。当我说“Mobile Web”时,我指的是“通过移动设备访问的网站”。
在Opera,我们全身心投入而创造出的浏览器允许你查看整个网络,不管浏览设备是否有这个能力。只要你在建立网站时,付出一点儿细心、尊敬并遵循 Web标准,你就可以为所有人所有设备创建只有一个版本的网站 – 唯一的一个网站。但是,有一些例外情况 – 在某些情况下,只有分版本的网站才行得通,一会你会看到这一点。
移动领域的竞争环境并不平衡在桌面领域,对于我们前端开发者来说,形式正在好转 – 大多数现代浏览器已经对Web标准支持的非常好了,无论是Opera、firefox(以及其他 Gecko内核浏览器)或者Safari(以及其他 Webkit内核浏览器),甚至IE带给我们的痛苦都比原来少了。虽然IE6的用户群体数量仍然非常杯具,但这应该归结于大多数人封闭的使用习惯等因素。 但是,移动设备领域在这方面却是不同寻常的:
* 你拥有能为“Full Web”提供支持的浏览器,像iphone上的Opera Mobile和Safari。Opera Mobile使用了与桌面版本相同的渲染引擎,所以对标准的支持相差无几。
* 你拥有并不很爽的浏览器,例如IE,它们对Web标准仅能提供有限的支持。它们中的一部分只支持WAP(例如WinWap),另一些支持其他像 Chtml或HTML-MP这样的标准(例如日本NTT DoCoMo的iMode浏览器),还有一些只支持Web标准中的有限子集(例如Netfront、Pocket IE、以及Blazer)。
* 最后,你拥有OperaMini, 以及其他通过代理机制的浏览器。它主要只是作为连接用户和一个大服务器群的客户端界面。当用户提交一个URL时,客户端会让服务端查找这个页面。然后它会 把页面转换成一个轻量级的二进制标记语言,将它格式化成适合移动设备查看的形式,并发送回客户端显示。这种方式的最主要优势,是可以使页面体积减少90% 左右,帮助用户节省很多带宽费用。这种标记语言表明Web标准并不能很好的表现在移动设备上,因为在这种服务的方式下,OperaMini对 ajax/javascript某些方面将支持的不是很好 – 在这儿有更详细的解释。注意:不要指望你的超级Ajax和DOM脚本动画网站在移动设备上会有良好表现。JavaScript在移动设备上的支持程度千差万别。时刻提供优雅降级吧。这种做法有一个例子叫做Hijax。
我们可以看到,在移动设备的跨浏览器兼容方面,你要思考的问题有很多。但是不要怕 – 我随后的建议会给你指引一个正确的方向;并且随着时间的推移,移动浏览器对标准的支持将会得到改善,届时我们前端开发者真的再也不需要为它们操心了。你问 我这一切什么时候会实现?Who knows!
移动浏览器的其它限制还有那些?当然,在移动设备上开发网站时,除了浏览器对标准的支持外,还会遇到其它更多的限制因素。设备自身的限制因素,你也不得不考虑。例如:
* 有限的控制 – 不要只假设你的用户会使用鼠标来控制页面中的一切,你也要提供键盘的选择。一些手机用户可能没有类似鼠标这样的东东,所以类似这样的结构 :hover 以及 onClick 对 他们来说是没有用的(这对可用性方面也是非常重要的 – 一些残障用户可能在用手方面会有些缺陷)。为用户提供的表单设计也同样重要 – 你可能已经感受到,用手机来填写那些又臭又长的必填表单有多么不爽。为了解决这个问题,试着去把那一坨内容用下拉菜单的方式展现出来,这比等着用户一个字 一个字手动输入来的更靠谱(译者注:目前国内有某些山寨机浏览器对下拉菜单的支持可能有不同程度的问题。例如基于MTK系统的联想i61,默认情况下会显示所有选项,而在某些情况下会产生变形和“漂移”,使用时需要谨慎些)。另外,给表单设置一个最有可能的初始值,也是一个好主意。
* 有限的屏幕尺寸 – 想象一下你那美妙的1024×768的设计在240×320屏幕下,或者更小的屏幕下,它的可用性会是什么样子……有一些方法可以应对这个情况 – 你可以故意把页面设计的很简洁流畅,或者你可以通过采取功能检测或媒体类型检测(诸如此类)的手段,为移动设备提供不同的页面。另外对于屏幕尺寸,有些手 机可能不需要这么麻烦,它们可能会提供“缩放模式”这样的机制,但是你却不能保证这一点。
* 有限的内存和带宽 – 移动设备所提供的可用内存明显比台式机少得多。因此,在你设计站点时,需要特别小心的考虑那些超大容量的相册图片,以及交互式流媒体视频的应用程序。此外,一些移动浏览器提供了关闭图像显示的选项,但是你也同样不能确定这一点。
* 有限的排版 – 我靠,你对台式机上那些排版非常痴情?你没有看到移动设备上的表现!虽然这条规则有很多例外情况,但大多数移动设备对字体的选择非常有限,只有一两种(like 1 or 2)。这个限制是由系统或浏览器决定的。
* 有限的颜色 – 一些移动设备在颜色方面的支持也非常有限。考虑你有多少页面的体验需要依赖于颜色,并确认那些对比色在移动设备上仍然支持。这些限制因素,就是导致Mobile Web的体验与PC Web的体验不同之处的真正原因。千万别欺骗自己,觉得自己的网站在移动设备上的用户体验与台式机上会保持一致 – 这纯属YY。当然,你抛开浏览器,千方百计去确认用户体验这一点仍然值得肯定。
真正的办法,去确保你的网站为移动用户提供一个良好的体验,是测试,测试,再测试!一些Web设计师们已经认识到,除了他们自己的手机、台式机以及游戏机浏览器外,还需要有一大堆移动设备需要准备在手头。
解决问题的不同方法人们普遍意识到,有三种办法可以解决移动开发的问题(已经被Cameron Moll证实了 – 找他的书看看)。可能的话,我建议你试试这三种方式 – 如前所述,在Opera,我们坚持相信One Web的理念 – 但是刚才我也说过,有些情况下这是很难实现的,或者也是没有必要的。下面是这三种方法:
1. 务必坚持遵循Web标准
2. 创建一个完全独立的移动网站
3. 只创建一个站点(One Web),但是根据浏览它的设备和浏览器情况,添加优化代码。现在,让我们开始对这些点逐个讲解。
坚持遵循Web标准和最佳实践一个好网站的基础,是要有一个好的HTML结构,以及美妙的CSS(表现)和JavaScript(行为)。如果你认真地遵循Web标准,大多数移动浏览器至少会很好地解析并至少会基本可用,这是非常有可能的。例如:
* 一个网站,有良好的HTML结构顺序并在HTML中没有装饰性图片,在移动浏览器的单列模式或移动模式中,会呈现得很有逻辑性。
* 如果你的表单元素中含有“label”元素,浏览器将把它渲染得更有表单区域的感觉。
* 如果你给CSS和JavaScript使用了优雅降级/渐进增强技术,浏览器如果不支持、简化、忽略某些属性,这时站点的可用性几率会大大增加。如果你花费时间精力去研究的话,在提升移动用户体验方面,还有更多事情可以去做。如果你的目标受众包括大量使用非HTML浏览器(例如支持WAP或 CHTML的某些日本浏览器)用户,那么你可能不得不检测设备并提供适当的内容。
提供一个完全独立的移动网站如前所述,我认为如果可能的话应该尽量避免使用这种方式。你可以做设备检测并自动重定向来避免给用户使用带来麻烦,但是这意味着你不得不维护两套网站。最主要的方法是通过UA嗅探来识别浏览器,或在服务端进行设备功能检测,然后再给用户提供相应的站点。在dev.opera.com,有很多优秀的文章来讲述如何实现 – 查看最后的资源部分。
但也有例外,对于完全独立的网站来讲 – 你不得不始终考虑用户体验情况。某些类型的浏览设备可能不兼容于特定的网站或者特定的功能。例如,有一个大学校园网,带有部门电话号码的搜索功能,但同时 也包含了一大堆校园历史的网页。如果你想去与某人会面却找不到他们部门时,你大概会想在移动设备上使用搜索功能,但你在外出的时候也不太可能想坐下来阅读 那么多的文字。
在这种情况下,你可以使用下面提到的一些技巧,来为移动设备提供网站中某个功能的一部分,或者干脆为移动设备创建一套完全独立的网站。你只需检测用 户使用的设备类型并自动提供给他相应的站点,并把这个过程完全公开给用户,但是很多很多人并不愿意这个功能把他们完全限制住,所以如果你要这么做的话,就 需要给用户提供一个指向完整站点的链接,用户可以自行选择是否用它来访问完整站点。
一句话警告 – 设备检测很容易被滥用。你可能经常看到一个网站的桌面版本非常牛B,而它的移动站点却非常的垃圾。因为开发者只是将移动站点放在一个非常低标准的位置上。 事实上,目标受众的设备水平并不均衡,现在很多的移动浏览器都具有处理完整Web页面的能力了!你应该尽可能地让设备发挥他们最高的处理能力,并且要发挥 移动设备的特别优势,比如基于位置的服务(LBS),还有 tel: 协议 – 在超链接点击时它可以让设备拨打一个电话号码。
只提供一个网站(One Web)进行到这里时,就开始变得有趣了。你可以再次依靠服务端功能检测,但这次是在单一网站的基础上进行优化,而不是重定向到另一个独立网站。有一些手机所支持功能的数据库可以参考,例如WURFL。它是以XML文件的形式开放的,你可以在设计优化内容之前,先通过它来查询设备所支持的功能。你还可以查询移动设备的UA字符串,找出这些设备的其他细节参数,例如是否有摄像头,屏幕尺寸是多少,以及它的语言种类等信息。
在客户端,你已经得到了为移动设备而优化内容所需的两个条件 – 媒体类型(media types)和媒体查询(media queries)。
媒体类型(media types)就像你知道的那样,你可以指定不同的CSS来实现不同的用途,例如:
手持类的媒体类型允许你针对移动设备使用优化版的样式(例如精简的布局和排版等)。这是一个被支持得很好的机制,实现起来也很简单,但它确实有它的 缺陷。就像之前所说,它经常被开发者滥用,来给网站提供一个蹩脚的最低标准布局。事实上,OperaMini最近改变了默认类型,把默认使用手持型样式表 (handheld stylesheet)改为屏幕型样式表(screen stylesheet)。OperaMini可以处理大多数完整网站,因此它并不真正需要使用手持型样式表(handheld stylesheet)。如果你乐意,你可以在OperaMini的浏览器选项中手动设置回移动视图。
媒体查询(media queries)媒体查询是CSS3的一个构想,它的用途跟条件注释非常相似 – 你可以把一大堆CSS规则封装嵌入到一个媒体查询中,然后把它应用到你的标记结构中,这一切取决于一个条件,类似“屏幕尺寸是否小于480px?”然后把代码放进去,代码类似这样:
img { margin: 0 0 10px 10px; float: right; } @media all and (max-width: 480px) { img { margin: 10px auto; float: none; display: block; } }你甚至可以使用多个媒体查询,像下面这样:
body { max-width:800px; font-family:georgia, serif; } img { margin:0 0 10px 10px; float:right; } .info { position:absolute; left:8000px; } @media all and (max-width: 480px) { img { margin:10px auto; float:none; display:block; } } @media all and (max-width: 240px) { img { display:none; } .info { position:static; } }OK,在这个例子中(源代码点击这里查看),浏览器中的图片在屏幕大于480px时会向右浮动,文本会环绕图片并通过外边距留出一点儿舒服的距离(另有一个信息隐藏在 p 元素中,并命名了一个 class 叫 info – 看看HTML代码)。文本流在一些小屏幕中看起来可能会有些蹩脚,因为那里没有足够的空间来让图片和定量的文本放置在同一行中,所以当屏幕小于480px 时,图片就需要改变一下,让文本不再围绕在它旁边,而是用 display:block 让它们显示在不同行中。等等 – 还有更精彩的!如果屏幕非常小以至于不能有效地展示图片,那就让它们消失,然后让隐藏信息显示在图片那儿,替代那些图片显示文本描述 – 这是一种将信息传达给读者的一种另类技巧,利用它也可以为那些使用屏幕阅读器的盲人用户提供原始文本,以便他们顺利浏览网站。图1展示了三个不同的浏览视 图,这是在那些支持媒体查询的浏览器中(例如Opera 9.5)表现出的不同形式。
听起来挺好,但是有没有不足呢?好吧,目前浏览器对媒体查询的支持程度非常有限。Opera浏览器支持它们,Safari 3也可以(以及其它基于Webkit内核的现代浏览器),但是Firefox 3之前的版本并不支持,IE或其他浏览器也不支持。解决问题的方法之一,是使用媒体类型和媒体查询的组合。这种方法在我的这篇文章中做过解释。这是一种变通方案,但肯定不够理想。这点在将来应该会有所改善。
摘要总结
目前就是如此而已。我希望我的移动开发世界之旅会对各位有所帮助。我在这只是抛砖引玉,要想深入学习的话,可以查看下面这些资源。
资源
* Mobile web design book, by Cameron Moll
* Designing and developing mobile web sites in the real world — 一个实例研究 by Brian Suda
* Server-side capability detection for mobile devices by Brian Suda (包含WURFL, UA字符串等信息)
* Ajax/JavaScript support in Opera Mini 4, by me
* Kristian von Streng Hæhre’s Opera Mini request header reference
* How to serve the right content to mobile browsers, 同样by牛B的me — 包含媒体类型和媒体查询
* Creating safe media queries that work cross browser
* Web design with Opera Mobile in mind, 再一次 by me
* The WURFL homepage
* The Opera Mobile homepage
* The Opera Mini homepage英文原文: Coding for the Mobile Web
中文原文: Mobile Web下的编码设计 -
手机网站开发必修课(2):浏览器兼容性测试
1 为什么要有兼容性测试:比web浏览器还恐怖的手机浏览器
对于web网站,一般来说,目前我们需要兼容的是
1个操作系统(windows)X 3种浏览器(ie 6、ie7、firefox)= 3种情况
要求高一点的web网站需要兼容的是
1个操作系统(windows)X 7种浏览器(ie6、ie7、firefox、chorme、opera、safari、遨游)+ 1个操作系统(mac) X 1种浏览器(safari)= 8种情况
注:以上浏览器除了ie外,均指其最新版本。另,遨游浏览器虽然是基于ie内核,但某些表现却完全出人意料,故也加入考虑。
好了,以上最多8种需要兼容的情况,已经让人大呼头痛不已,何况事实上这些浏览器对html代码本身的解析都是没问题的,你比较需要费心的只是ie6的css和js。
那么手机浏览器有多少种需要兼容的情况呢?
从上一篇文章看来,如果要做到比较好的兼容性,我们要兼容的手机浏览器至少有二十种情况(手机自带的浏览器+用户可安装的浏览器)
web浏览器的兼容性大致可根据浏览器的渲染引擎来确定兼容类型,但手机浏览器,即使是使用的同一个渲染引擎,在不同的手机上表现也可能很不一样。
还有两个更令人头痛的问题:
1. 你没法使用css hack
2. 你也没法逐一去测试各浏览器的实际效果所以,当你涉足手机网站开发的时候,你才会感概,web浏览器们真是太仁慈了。
不过事情还不算太坏,就目前来看,基于手机浏览器的限制,一般手机网站的布局和功能不会太复杂,而高级一些的手机浏览器(如iphone等)兼容性还是很理想的,不用操心。
不管怎样,对于一个专业的手机网站来说,有一份专业的浏览器兼容性测试报告是非常有必要的。面对成百上千的手机型号,还有日益强大的山寨机,我们的兼容性测试要覆盖哪些机型呢?
2 目标用户数据挖掘
我们基本不可能兼顾到所有类型的手机浏览器,所以你必须要根据你的用户数据来决定要测试兼容性的手机型号。
你的手上需要有以下数据:
1. 你的网站访问的手机型号统计
2. 用户访问你的网站的主要行为如果拿不到这些数据,那么接下来的兼容性测试将会艰难很多,你不得不通过广撒网的方式,测试尽可能多的手机(而不是主要目标客户群的手机)来确认某些属性的兼容性,这可不是一个好主意,相信让你的老板掏银子给你采购几十乃至上百台手机不太现实。
总的来说,你需要得到测试手机的以下数据:
手机型号、操作系统、浏览器类型、屏幕尺寸、颜色深度
3 安排测试,整理测试结果
当我们设计测试点的时候,应该涵盖哪些内容呢?
1. 对xhtml代码本身的支持度,如是否支持
2. 对特殊字符的支持度,如★◆
3. 对css的支持度
* 对css不同引入方式的支持
* 对css的属性的支持
* 对css某属性不同属性值的支持,如margin的取负值、background-repeat的不同取值
* 对css选择器的支持,如tag,class,id,选择器的嵌套
* 对css高级选择器的支持
4. 对js的支持度
* 目前还不太可能在手机上创建很复杂的js效果,可以仅测试js的基本功能,比如对事件的支持,当然,使用js最重要的是要考虑好如何优雅降级,确保用户在没有js的情况下也能顺利完成任务
5. 对图片的支持度
* 支持图片类型,包括gif非透明背景、gif透明背景、gif动画图、jpg、png8非透明背景、png8透明背景、png24非透明背景和png24透明背景
* 支持图片颜色,如色彩复杂的图片,光滑渐变的图片设计一个专用于测试的excel表格,方便测试人员填写测试结果也是非常重要的工作,如果这一步没有做好,也许你之前所有的努力都将白费。传承有价值的研究结果,其意义不低于研究本身。
-
手机网站开发必修课(1):手机浏览器
前言: 手机有哪些浏览器?这些浏览器对xhtml、css和js的支持度怎么样?目标用户的手机使用情况?条件限制下的手机界面设计要如何进行?如何快速搭建一个手机网页?如何做好网站的兼容性工作?想必这些问题每个参与过手机网页开发的人都遇到过。头大的是,除了自己公司已有的一些经验,网上恐怕没有过多的(公开的)文档可以参考。 09年上半年的工作重心全在手机网页开发上面,这使得自己某种程度上也成了拓荒者。现将这段时间的开发心得同大家分享以下,欢迎大家跟我交换自己的想法。
手机网站开发必修课系列文章计划:
- 手机浏览器
- 来自wiki的解释
- 对wiki的总结
- 浏览器兼容性测试
- 为什么要有兼容性测试:比web浏览器还恐怖的手机浏览器
- 目标用户数据挖掘
- 安排测试,整理测试结果
- 测试结果对手机网站开发的指导意义
- 对设计的指引作用
- 确保裸html代码具有较高可用性,谨慎使用html标签
- css使用注意事项
- 非常重要:代码的优雅降级
注:由于有些数据牵涉到公司的商业机密,所以在这个系列的文章当中,有些可能不会公布出详细的数据,但会给出方向性的结论或者意见,请大家见谅。
要了解手机网站开发的诀窍,我们必须先了解手机浏览器。虽然百度“手机浏览器”没啥有价值的文章,所幸google“mobile broswer”出来了比较多有价值的文章。那么,站在前人的肩膀上,我们可以看的更远。
以下文字翻译自维基百科》手机浏览器:http://en.wikipedia.org/wiki/Mobile_browser
手机浏览器,又称微浏览器、迷你浏览器或者无线因特网浏览器,是被设计用于像手机或者PDA之类的无线设施的网页浏览器。手机浏览器针对在便携设备上的小屏幕网页显示进行了专门的优化,以使网页内容显示最高效。手机浏览器的软件必须小巧并且能适应无线掌上设备的低存储量和低带宽。它们一度是最简朴的网页浏览器,但是2006年以后有些手机浏览器能够支持象css2.1、JavaScript和Ajax这样的最新技术。那些被设计从手机浏览器访问的网站叫无线门户。
内容概览- 相关的技术
- 先驱们
- 流行的移动浏览器
- 被主流手机和PDA厂商使用的默认浏览器
- 用户可安装的手机浏览器
- 手机HTML代码转换机
- 更多
- 参考
- 更多外部链接
1 相关的技术
手机浏览器通常通过蜂巢网络连接,通过无线局域网连接的手机浏览器数量也日渐增多,后者使用基于TCP/IP的HTTP并能显示那些使用HTML, XHTML Mobile Profile (WAP 2.0), 或者WML (从HDML发展而来)编写的网页。WML和 HDML是适于通过低带宽传送数据的最简朴的形式,而无线数据的连接被称为WAP。
在日本,DoCoMo定义了基于i-mode HTML的 i-mode服务,是压缩HTML(C-HTML)的一种扩展,HTML的一个子集。
WAP 2.0指定了XHTML手机协议和WAP CSS,WAP CSS是是W3C标准的 XHTML和 CSS在移动设备上扩展的一个子集。
2 先驱们
那些被称为微浏览器的技术,诸如WAP, NTTDocomo的 i-mode平台和Openwave的 HDML平台点燃了人们对无线数据服务的第一次热情。
第一个微型浏览器的诞生大约是在1997年, 当Unwired Planet 公司(后来发展为 Openwave)将他们的”UP.Browser”放在AT&T公司的手持设备上以供用户访问HDML内容。
一家英国公司, STNC股份有限公司,在1997年的时候研发了一款叫做 HitchHiker的微型浏览器,并对这款装备设计了全套的UI。这款微型浏览器(Webwalker)的演示平台拥有每秒处理百万条指令的能力。它是一个单核处理平台,在类似于应用堆栈的处理器上跑着GSM堆栈。1999年 STNC被微软收购,并且HitchHiker变身为Microsoft Mobile Explorer 2.0,不同于之前的Microsoft Mobile Explorer 1.0。HitchHiker被认为是第一款拥有统一标准的渲染模型的微型浏览器,它在一个客户端遵从EcmaScript, WMLScript, POP3 和 IMAP 邮件等标准处理 HTML 和 WAP。尽管这个浏览器最终未被使用,但它确实可是使HTML 和 WAP在一个页面上联合使用,虽然这将使得其他的设备无法正确渲染该页面。另外, Amstrad公司倒霉的将HitchHiker作为他们e-m@iler和 e-m@iler+产品的操作系统,手机浏览器2.0在Benefon Q, Sony CMD-Z5, CMD-J5, CMD-MZ5, CMD-J6, CMD-Z7, CMD-J7 and CMD-J70.等设备上都可使用。
还有一款叫Palmscape的用于PalmOS的免费浏览器(虽然后来才成为共享软件的),由Kazuho Oku 1998年在东京编写,他继而发现了Ilinx,这款浏览器直到2003年才放开使用限制。
于2001年发布的 Mobile Explorer 3.0增 加了iMode的兼容性和众多的专利设计。通过假想的将这些专利设计结合到WAP协议中, MME3.0执行了OTA数据库同步、推送了email,推送了信息客户端和PIM功能。已经退出市场的索尼爱立信CMD-Z700深度集成了 MME3.0。MME的开发脚步在2002年中旬画上了句号。
Opera Software公司以他的小屏幕渲染技术(Small Screen Rendering )和中屏幕渲染技术(Medium Screen Rendering)领先于该领域。Opera的的web浏览器可以让普通的web网页在小型屏幕和中型屏幕上重新布局,并达到最优显示。他是第一款广泛支持Ajax和通过ACID2测试的浏览器。
3 流行的移动浏览器
手机浏览器和基于web的模拟器不同,基于web的模拟器使用一种“虚拟的手持设备”在电脑上显示wap页面,使用java或者html转码器。这些模拟器有 Wapjag, TT, Waptiger 和 Superwap。
一下表格列出了一些当下非常流行的手机浏览器。一些手机浏览器是web浏览器的精简版本,因此一些手机浏览器厂商也提供用于台式机和笔记本电脑的浏览器。
3.1 被主流手机和PDA厂商使用的内置手机浏览器
3.2 流行的用户可安装的手机浏览器
- Bolt[5]
- Bluelark Bluelark bought by Handspring Inc.
- Deepfish Beta from Microsoft, proxy-rendering browser.
- Doris by Anygraaf Oy (Vantaa, Finland)
- Fennec by Mozilla Foundation.
- IbisBrowser
- iPanel for Palm OS,
- jB5 Mobile Browser Beta from Jataayu Software.
- JOCA by InteracT!V, another proxy-rendering free software.
- Links2 on the Playstation Portable (requires custom firmware)
- Minimo by Mozilla Foundation (based on Gecko).
- NetFront
- Opera Mini by Opera Software – supports most features of stand-alone Opera, but can run on less capable phones by offloading memory-intensive rendering to proxy server (based on Opera Mobile running on a server).
- Opera Mobile by Opera Software – supports all modern web standards supported by desktop browsers, including XHTML, CSS2 and Ajax. Has advanced Small Screen Rendering that adapts regular pages to small screen (proprietary).
- Pixo by Sun Microsystems (Pixo acquired by Sun July 2003)
- PocketWeb by tlogic.de (Heidelberg, Germany) Official product page
- RocketBrowser Rocket Mobile, Inc. (Silicon Valley, CA).
- SAS
- Skweezer
- Skyfire Open Beta by Skyfire Labs. Supports Flash and Ajax and allows a fully functional PC web-like experience.
- Stanford Power Browser created in Stanford’s InfoLab [3]
- Steel
- Teashark – a free Java-based browser with a desktop-like layout [4]
- ThunderHawk by Bitstream Inc. (Cambridge, MA)
- UCWEB by UCWEB Technology
- Universe by OpenMobl Systems
- Webby Mobile by AnOriginalIdea
- WebViewer – a free Java based browser by Reqwireless
- WinWAP by Winwap Technologies Official product page
3.3 手机HTML代码转换机
手机HTML代码转换机将web内容重新格式化并压缩成移动设备可用的内容,并且必须和内置的或者用户安装的手机浏览器配合使用。以下是几个领先的手机HTML代码转换机服务。
- Skweezer – used by Orange, Etisalat, JumpTap, Medio, Miva, and others
- Teashark
- Opera Mini
4 更多
5 参考
- 无线门户的定义
- 关于Openwave Openwave.2009.2009年2月26日寻回
- Weather Underground网站为手机用户提供天气服务
- Myriad浏览器v9数据表(pdf) Myriad小组. 2009.2009年2月26日寻回
- bolt浏览器官网
6 更多外部链接
- W3C手机网页第一步 — “W3C手机网页第一步的目标是要让用户从移动设备访问网页成为现实——Tim Berners-Lee, W3C 网站的创始人之一如是说.
- 用于小型信息设备的紧凑HTML —1998年2月
- 开放移动通信联盟
- 黑莓浏览器开发者网页
- ItsNat 一个很多手机浏览器支持的基于Java的AJAX网页框架
对wiki的总结
对于wiki中提到的浏览器类型,还有两个页面可供参考
看完整篇文章后,有一些问题要问问聪明的你
- 什么是渲染引擎?什么是浏览器?这是两个最先要搞清楚的概念。
- 内置的手机浏览器,用户安装的手机浏览器和基于web的模拟器
- 每个浏览器都有相应的渲染引擎,因此有必要知道使用同一个渲染引擎的手机浏览器的页面表现是否一致
- 国内主流的浏览器机型有哪些?国内用户是否喜欢使用用户自己安装的浏览器。不管怎么样,作为一个开发人员,应该尽量去体验一下这里提到的各种用户可安装的浏览器。
- 基于web的模拟器是前期测试很有效的工具,推荐使用safari,opera和firefox(需安装插件)
- 如何保证手机网页的开发效率(包括质量和速度哦)?
以上这些问题,前两点在本文中有提到,后面几点希望大家能开动脑筋先想想,答案将在后续的文章中揭晓
建议用你自己的手机访问一些国内较大的无线网站。比如 http://wap.taobao.com,http://wap.163.com等等
- 手机浏览器
-
手机网站开发必修课(3):2009总结版
手机网站开发,有着许多不为人知的困难:
一是可参考的资料太少,大部分手机网站都处于起步阶段,很多的时候都是摸着石头过河,而鉴于淘宝自身的特殊性,也使得我们在参考成功案例之余,要做更多的思考;
二是兼容性工作异常艰辛,难度一点也不比web网站的兼容性工作来的低(关于这点,请参见我之前的文章);
再者作为一个手机网站的前端开发,也往往容易被人忽视(包括我们自己),大家也许会觉得做好一个手机网站能有多难,了解一点XHTML、一点 CSS,甚至不需要对JavaScript有什么研究,事实却不是如此,正因为手机网站的开发受到设备的太多限制,前端们常常为了节约几个字节而纠结万 分,写出语义化良好的代码也显得更加重要,而多版本的开发需求也对于JavaScript的优雅降级要求甚高,这样才能使得网站有分版本需求的时候可以公 用同一套XHTML代码,最大程度的降低开发成本。
对于手机网站来说,相信现在仅仅只是个开始,随着各种新机型的相继面世,这块领域必将成为兵家必争的新高地。
注意:由于手机网站发展迅速,请参阅者注意本篇文章的发布时间。
目录
- 手机用户设备统计分析
- 手机浏览器兼容性测试结果概要
- 手机网站开发中你需要注意的问题
- 推荐参考资料
- 总结
手机用户设备统计分析
拥有全面的用户数据,无疑能帮助我们做出更符合用户需求的产品。内部数据能帮我们精确了解我们的目标用户群的特征;而外部数据能告诉我们大环境下的手机用户状况,并且能在内部数据不够充分的时候给予我们一些非常有用的信息。
从外部数据来看,09年10月到11月期间
国内浏览器品牌市场占有率前三甲为:
- Nokia(78%)
- Opera(OEM) (10%)
- iPhone(Safari) (3%)
国内的手机操作系统前三甲为:
- Nokia SymbianOS(80%)
- iPhoneOS(6%)
- SonyEricsson(5%)
当然,作为中国的手机网站开发者,不能忽视强大的山寨机市场(或者应该叫作做国货精品手机市场?)。顺便提一下,这类手机通常使用的是MTK操作系统。
(以上数据均来自statcounter.com)
手机浏览器兼容性测试结果概要
注意:以下所说的“大多数”是指在我们测试过的机型中,发生此类状况的手机占比达50%及以上,“部分”为20%到50%;“少数”为20%及以下。而这个概率也仅仅只限于我们所测试过的机型,虽然我们采集的样本尽量覆盖各种特征的手机,但并不代表所有手机的情况。
XHTML部分
大多数手机不支持的:
- 表单元素的“disable”属性
部分手机不支持的:
- “button”标签
- “input[type=file]“标签
- “iframe”标签。
虽然只有部分手机不支持这几个标签,但因为这些标签在页面中往往具有非常重要的功能,所以属于高危标签,要谨慎使用。
少数手机不支持的:
- “select”标签:该标签如果被赋予比较复杂的CSS属性,可能会导致显示不正常,比如”vertical-align:middle”。
CSS部分
大部分手机不支持的:
- “font-family”属性:因为手机基本上只安装了宋体这一种中文字体;
- “font-family:bold;”:对中文字符无效,但一般对英文字符是有效的;
- “font-style: italic;”:同上;
- “font-size”属性:比如12px的中文和14px的中文看起来一样大,当字符大小为18px的时候你也许能看出来一些区别;
- “white-space/word-wrap”属性:无法设置强制换行,所以当你网页有很多中文的时候,需要特别关注不要让过多连写的英文字符撑开页面;
- “background-position”属性:但背景图片的其他属性设定是支持的;
- “position”属性;
- “overflow”属性;
- “display”属性;
- “min-height”和”min-weidth”属性;
部分手机不支持的:
- “height”属性:对”height”的支持不太好,奇怪的是在我们的测试当中,仅仅只有很少部分手机不支持”width”属性;
- “pading”属性
- “margin”属性:更高比例的手机不支持”margin”的负值。
少数手机不支持的:
- 少数手机对CSS完全不支持;
JavaScript部分
这部分测试相对不那么让人抓狂,要么干脆不支持,如果支持的话,对基本的dom操作、事件等支持度都还不错。但我们没有测试过很复杂的脚本。
在我们测试过的手机当中,支持(包括不完全支持)JavaScript的手机比例大约在一半左右,当然,对于我们来说,最重要的不是这个比例,而是要如何做好JavaScript的优雅降级。
其他
- 部分手机不支持png8和png24,所以尽量使用jpg和gif的图片
- 另外对于平滑的渐变等精细的图片细节,部分手机的色彩支持度并不能达到要求,所以慎用有平滑渐变的bar设计
- 部分手机对于超大图片,既不进行缩放,也不显示横下滚动条
- 少数手机在打开超过20k的测试页面时,会显示内存不足
开发中你需要注意的问题
- 手机网页编码需要遵循什么规范?
遵循XHTML Mobile Profile规范(WAP-277-XHTMLMP-20011029-a.pdf),简称为XHTML MP,也就是通常说的WAP2.0规范。 XHTMLMP 是为不支持XHTML的全部特性且资源有限的客户端所设计的。它以XHTML Basic为基础,加入了一些来自XHTML 1.0的元素和属性。这些内容包括一些其他元素和对内部样式表的支持。和XHTML Basic相同,XHTML MP是严格的XHTML 1.0子集。 - 网页文档推荐使用扩展名?
推荐命名为xhtml,按WAP2.0的规范标准写成html/htm等也是可以的。但少数手机对html支持的不好。 - 为什么现今大多数的网站一行字数上限为14个中文字符?
由于手持设备的特殊性,其页面中实际文字大小未必是我们在CSS中设定的文字大小,尤其是在第三方浏览器中。例如Nokia5310,其内置浏览器 页面内文字大小与CSS设定相符,但是第三方浏览器OperaMini与UCWEB页面内文字大小却大于CSS设定。经测试,其文本大概在16px左右。 假如屏幕分辨率宽度为240px,去除外边距,那么其一行显示14个字以内,是比较保险(避免文本换行)的做法。 - 使用WCSS还是CSS?
WCSS (WAP Cascading Style Sheet 或称 WAP CSS)是移动版本的CSS样式表。它是CSS2的一个子集,去掉了一些不适于移动互联网特性的属性,并加入一些具有WAP特性的扩展(如-wap- input-format/-wap-input-required/display:-wap-marquee等)。 需要留意的是,这些特殊的属性扩展并不是很实用,所以在实际的项目开发当中,不推荐使用WCSS特有的属性。 - 避免空值属性
如果属性值为空,在web页面中是完全没有问题的,但是在大部分手机网页上会报错。 - 网页大小限制
建议低版本页面不超过15k,高版本页面不超过60k。 - 用手机模拟器和第三方手机浏览器的在线模拟器来测试页面是不是靠谱?
有条件的话,我们当然建议在手机实体上进行测试,因为目标客户群的手机设备总是在不断变化的,这些手机模拟器通常不能完全正确的模拟页面在手机上的显示情 况,比如图片色彩,页面大小限制等就很难再模拟器上测试出来。当然,一些第三方手机浏览器的在线模拟器还是可以进行测试的,第三方浏览器相对来说受手机设 备的影响较小。
推荐参考资料
开发权威网站
- WAPForum:XHTML Mobile Profile规范.pdf
- WAPForum:WCSS规范.pdf
- W3C:XHTML Basic 1.1规范.html
- W3C:Mobile Web Test Suites Working Group.html
- PPK:关于手机浏览器兼容性的测试和研究.html
- Developershome:XHTML MP 教程.html (汉化版)
经典开发文章
- Unknown:移动WAP相关标记语言的演进.jpg
- Flora Graham:Alternative mobile browsers tested.html
- Lucas Pettinati(Yahoo):Challenges of Interface Design for Mobile Devices.html
- Holly Kolman:How to Make a Click to Call Link.html
- Brian Suda:Introduction to the Mobile Web.html
手机型号查询
- handsetdetection:手机查询.html 机型很全,偏国外机型,参数较多
- mobile9:手机查询.html 机型较全,偏门机型可能无内容
- 试手机网:手机查询+模拟.html 机型稍少,可以模拟手机操作
总结
目前来说,手机网站开发是个典型的设备驱动开发的过程,页面被设计成什么样,能做到怎么样,几乎全取决于目标客户的手机设备情况。
所以,对手机设备的了解,对于设计开发过程有着直观重要的作用,对于前端来说,就需要有计划的进行长期的手机浏览器兼容性测试,什么样的设计能被实现,什么样的标签可以使用,这些都需要有数据的支持。
我们必须有这样的认知,开发的手机网页总是会在或多或少的手机设备上出现问题,因为我们永远无法知道所有用户的手机设备情况,所以我们更要尽量的遵循标准进行开发,这样才能将满足用户的比例做到最好。
任何一个领域都有值得你进行深入了解的地方,即使现在看起来,手机网站的开发还有点不入主流,但我相信,随着手机设备的更新换代,总有一天它也会成为我们占领客户的一个重要战场,iphone这类有符合web标准的浏览器的手机发布,也给了我们更多的信心。
感谢:http://www.fool2fish.cn/ 博主分享![转载]
最近文章
- 设计师如何搜集资料?
- Google的设计原则
- Axure RP 快速原型制作软件 – 线框图,原型,规格文档
- SEO优化—挖掘关键词3大秘诀!
- 建新网站要做的四个SEO优化
- 教你如何让google baidu收录网站最快最多
- CSS Overflow属性详解
- CSS网页布局中易犯的10个小错误
- 网站结构设计之关键词群布局
- 使用CSS为图片添加的五种特殊效果
最近评论
- 问道推广员 在 当视觉设计师遇上产品经理、开发工程师 上的评论
- AileenFULTON23 在 当视觉设计师遇上产品经理、开发工程师 上的评论
- 物流服务 在 当视觉设计师遇上产品经理、开发工程师 上的评论
- 小区 在 当视觉设计师遇上产品经理、开发工程师 上的评论
- 色播 在 当视觉设计师遇上产品经理、开发工程师 上的评论
分类目录
- SEO (5)
- 互联网 (19)
- 免费模板 (1)
- CSS模板 (1)
- 前端技术 (25)
- CSS+HTML (16)
- JavaScript (1)
- Jquery (1)
- WAP (4)
- 用户体验设计(UED) (50)
- 紫枫生活 (10)
- 设计制作 (7)
- 设计杂谈 (37)
紫枫印迹
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
|---|---|---|---|---|---|---|
| « 三 | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||

