【业务知识】浅议基于系统规范的设计创新(二)
----by samson
自定义手势
触摸手势如今成为了移动设备的一种标志性交互方式。Iphone通过触摸手势给用户带来了“直接操作”的体验概念——人们发现可以像在现实物理世界中操作物体那样去操控软件,这也是手势交互被大众广泛接受的原因。良好的触摸手势,能让用户自动映射到日常生活中的交互行为,让用户感觉亲切、自然,这些动作发自本能,一学即会。反之,一些动作不是来自熟知的物理世界或非系统既有,那就没那么容易发现并易于使用了。
手势的创新大抵可以分为两种,一种是对系统标准手势的功能扩展,即手势动作是系统既有的,但其对应的功能或响应的反馈做了改变;另一种则是完全自定义手势,譬如iphone平台上的多点触控(超过两点)。一般而言,前者的学习成本低,易于发现,发现之后又易于记忆掌握。在一些优秀app中,这种手势扩展方式已经运用的非常娴熟了。
关于手势有太多的话题,这里我们只聚焦于原生系统与那些优秀创新的app在手势操作设计上的相通之处。生硬的模仿往往是蹩脚的,但有时当我们想创意地解决一些问题时,灵感常常从经典中来。
iphone常用标准手势[1]
Pull-to-refresh
Pull-to-refresh(拉动刷新)如今几乎已是业界的一种标准交互设计模式。最先发明这种手势触发刷新模式的是Twiiter的设计师。但这个设计并非是一蹴而就的,在第一个版本中,加载按钮被塞到了列表顶部,当用户滚动(Scroll)屏幕至顶部时,很自然地就会看到这个按钮,比起单纯把刷新放在工具栏上,这已是一个不小的创新进步了。接下来,Twiiter的设计师又进一步地改良了这个手势操作:滚动至页面顶部,会出现一条隐藏的文字信息:“pull down to refresh”(下拉刷新),当下拉了足够距离后,又显示“release to refresh”(松手吧)。整个交互过程是一种对标准滚动操作的一种功能扩展,非常容易发现、学习、使用。
twiiter的pull-to-refresh[2]
回到Twiiter第一版的设计,当初Twiiter设计师是如何走出第一步,福至心灵,把加载按钮隐藏在页面顶部的呢?我们来看一看系统的信息应用,在短信列表界面,同样把搜索栏藏在了列表顶部,当用户滚动短信列表时,搜索栏会很自然地出现。我们可以发现,两者的设计模式是如此相似。
信息应用中滚屏显示搜索栏
Clear——将标准手势发扬光大了一遍
Clear是一款全手势操作的任务管理应用。它绕过了通用的控件,让一些通常作为快捷方式的手势来作为唯一的交互方式,配合动态、积极的反馈,使得整个交互流程酷炫无比。可观察这些眼花缭乱的手势后,我们可以发现clear采用的全是常用的系统标准手势。
Clear的每个界面都是列表视图,向左滑动(swipe)列表项可删除任务。这也是iOS中一种删除信息的快捷手势操作。但是clear对其进行了“加工改造”,它省去了二次确认的步骤,在交互流程中,加入了直观的动效反馈和细腻的UI变化,这样一来用户对这个手势仍然熟悉,但对整个设计的感觉却是耳目一新。接下来仿佛是水到渠成般地,clear按照对称法则加入了向右滑动的手势,功能也是与“删除”所相对应的功能——“完成”。
Clear另一个出彩的手势是双指缩放(Pinch&Spread),在iphone中该手势用于缩放图片内容。Clear巧妙地利用这个手势完成类似的目的——把一堆任务条目归到一起或分开;这与现实世界中的操作体验也是非常一致的。唯一遗憾的是两指捏合这个手势在手机屏幕上使用起来并不是非常舒适高效,如果是在ipad上,5指的缩放可更大有可为。
Pinch手势归拢信息条目
结语
在标准手势的基础上进行扩展设计,可以大大降低用户发现手势操作的门槛和学习的成本。另外,从传统中衍变往往会比平地建新楼更让人感到功力和底蕴。
待续……
【1】 图片来自来自http://gesturecons.com/
【2】 图片截自《Tapworthy.Desiging Great Iphone Apps》,作者 Josh Clark
本文原创自无线技术运营空间: http://wireless.qzone.qq.com 及 http://blog.csdn.net/wireless_tech (专注无线技术运营——无线技术(操作系统/数据库/WEB前端/负载均衡/系统容灾/系统安全/短信接入/WAP接入/3G等)、无线业务运营、无线开放平台、统计分析(用户行为分析/数据挖掘)、CP合作,联系我们:1780551083@qq.com)
2007年在手机游览器领域,WAP是主流标准. 当时全球掌握WAP浏览器核心技术的公司大概只有4家:
美国的Openwave(Motorola);
瑞典的Teleca(Obigo);
日本的Access(Netfront);
韩国的Infraware;
手机上浏览器的实现架构分析:
UC, 最先推出C/S(客户端/服务器)处理架构,将主要数据处理内容交由中间件服务器去做,手机端只负责简单的数据加/解密以及页面重排展示,解放了软件对手机硬件的依赖.
Obigo浏览器, 直接在手机本地进行数据解析,对手机硬件性能以及网络状况依赖很大.
EMCS mBrowser, 直接在手机本地进行数据解析,对手机硬件性能以及网络状况依赖很大
Opera Mini,使用C/S架构,但软件对手机硬件有一定的要求.
NetFront, 直接在手机本地进行数据解析,对手机硬件性能以及网络状况依赖很大.
WAP浏览器架构和实现原理:
移动嵌入式设备的局限性:
由于嵌入式设备的CPU能力、屏幕大小、网络环境、内容容量限制等问题,手机上的浏览器的软件架构和实现要比PC复杂一些.
1.CPU:
一般的feature phone上的主频在104MHz或以上.因此要确保手持设备上的浏览器能够访问web,那么该浏览器应该能够工作在104MHz一下的主频环境.
2.内存:
目前的feature phone上的RAM配置一般是在4M RAM 和16~32M Nor Flash.
3.显示屏:
在mobile上,LCD都是比较小的比如:176X220 , 240X320等,现在的智能机很多都开始朝大屏幕发展.由于显示屏的大小的限制,那么UI排版方面就要根据具体的LCD大小做调整.
4.操作方式:
mobile上的浏览器操作方式已经从键盘操作方式开始往触屏方式演进了.因此对触摸屏gesture事件的支持是必须的.更有甚者还要达到多点触控的效果.
5.低功耗:
对电池的续航能力是一大考验.
移动嵌入式设备上浏览器的技术点剖析:
1.通信协议:
Feature phone上必须支持WAP协议[目前的WAP2.0],而且现在也必须要对HTTP协议的完全支持.如果有敏感数据的交互的话,需要使用SSL协议[secure sockets layer].
2.技术规范:
a. HTML的支持,未来看HTML5了, [超文本标记语言,Hypertext Markup Language];
b. CSS的支持,未来看CSS3了, [Cascading Style Sheets, 层叠样式表单];
c. XML的支持,支持DOM[Document Object Mode,文档对象模型],W3C 文档对象模型[DOM]是一个使程序和脚本有能力动态地访问和更新文档的内容、结构以及样式的平台和语言中立的接口, 使用DOM接口便捷的访问XML;
d. JavaScript的支持, JavaScript是一种广泛用于客户端网页开发的脚本语言,最常是于HTML上使用,用来给HTML网页添加动态功能。
e. 图片和动画格式的支持, Jpeg,BMP,PNG,GIF 和Flash格式的支持;
f. POP3 和SMTP的支持,这个是可选功能;
目前流行的移动浏览器:
Opera/UC浏览器/腾讯浏览器/但是这几个都是Smart phone上的弄潮儿.
Feature phone上有:
Access EMCS WAP 2.0浏览器:
Teleca的 Obigo浏览器:
WAP网络架构图:
WWW模型:
传统浏览器的客户端服务模式:
WWW logical model
www programming model
WAP model:
WAP programming model
Feature/Performance-Enhancing Proxy
WAP Proxy提供了很多功能,包括:
1.Protocol Gateway, 协议网关翻译来自无线协议栈的request到WWW协议[HTTP和TCP/IP].网关同时也根据client请求的URL执行DNS查找服务名.
2.Content Encoder and Decoder, 内容编码被用来转换WAP内容为一种压缩格式,便于压缩后更好的利用下层链路.
3.User Agent Profile Management, 提交给应用程序的描述客户端的容量和性能的配置文件.
4.Caching Proxy, 通过维护频繁访问资源的cache,来提升性能和网络利用率的体验.
WAE模型:
WAE是基于无线通讯网络开发应用和服务的一个行业标准和规范, 是一个在手持移动终端上被标记语言[包括WML和XHTML]、脚本、层叠样式表、电话服务以及编程接口使用的微型浏览器环境.
WAE Model
WAE环境架构:
从下图来看,WAE包含两个逻辑层:
1> User agents, which includes such items as browsers, phonebooks, message editors, etc;
2> Services and Formats, which include common elements and formats accessible to user agents such as WML, WMLScript, image formats, vCard and vCalendar formats, etc.
WAE Client Components
用户代理是在移动终端上用于解释和执行内容的软件。 WAE中的用户代理包括WML用户代理和WTA(无线电话应用)用户代理,当然也可以有对应于其他应用的其他用户代理。
WML用户代理,是基本的用户代理,支持WML和 WMLScript,可以向WAP网关发出请求,接收WAP网关发送过来的内容(WBXML或 WMLScript字节码),正确解释、执行并显示
WTA[Wireless Telephony Application] user agent, 是一组对电话呼叫和特征控制机制所做的特定扩展,向内容创建者和最终用户提供高级移动网络服务.
WML 用户代理逻辑架构:
WML User Agent Logical Architecture
WML 是WAP定义的一种XML文档类型,它以HTML 和HDML为基础,针对无线网络和移动终端的特点做了简化和优化,因此,从语法、语义到文档结构都与HTML非常相似.
在WAP中,一个WML文档称为一个“deck”,一个 “deck”内包含若干个“card”,“card”是用户浏览和交互的单元,包含了呈现给用户的信息以及用于收集用户输入的指令.
WMLScript 是用于 WML 页面的脚本语言;
WML 页面可以在 WAP 浏览器中显示;
WMLScript 用于验证用户输入、生成对话框、显示出错消息以及访问用户代理设备等等;
WMLScript在WAP浏览器运行之前,需要先在Server上编译成字节码;
WMLScript并不嵌在WML页面中,WML页面仅仅包含对WMLScript URL的引用;
WAP客户端架构:
WAP Client Architecture
WIM,Wireless Identity Module,包含设备标识符和加密信息,意味着
EFI,External Functionality Interface
WAP 详细架构:
WAP stack architecture
WAP1.x 和WAP2.0协议架构比较:
WAP1.x WAP2.0
现在基本上都是双栈架构.
浏览器工作原理:
浏览器的软件架构
现在开始看看WAP browser的架构:
WAP浏览器的软件架构
其实看上面两个架构其实很相似的,只是WAP浏览器多了WML的解析,以及WML script引擎.因为WAP的页面格式就是基于WML的,而且脚本语言是基于WML script的.
随着手机终端的硬件的不断提升,以及未来网络带宽的升级.WAP浏览器和PC端的浏览器差异会越来越小.
WAP浏览器的访问网络的过程:
1.设置接入点名称[APN]:
// APN, Access Point Name
AT+CGDCONT=1,"IP","CMNET" //通发送AT指令来设置移动网关的接入点
2.拨号
ATD*98# //通过PPP协议拨号连接, 连接成功后手机终端就可以访问网络了.
整个过程和PC拨号上网过程一样.
到此,关于WAP浏览器的实现原理和架构大概就这些.