论WebApp、HybridApp、NativeApp设计差异

   2015-06-24 0
核心提示:目前主流应用程序大体分为三类:Web App、Hybrid App、 Native App。 本文从技术特性、设计要点等方面纵向对比三类app的设计差异。

论WebApp、HybridApp、NativeApp设计差异

目前主流应用程序大体分为三类:Web App、Hybrid App、 Native App。

论WebApp、HybridApp、NativeApp设计差异

一、Web App、Hybrid App、Native App 纵向对比

首先,我们来看看什么是 Web App、Hybrid App、 Native App。

(1)Web APP

Web App 指采用Html5语言写出的App,不需要下载安装。类似于现在所说的轻应用。生存在浏览器中的应用,基本上可以说是触屏版的网页应用。

优点

(1)开发成本低,

(2)更新快,

(3)更新无需通知用户,不需要手动升级,

(4)能够跨多个平台和终端。

缺点:

(1)临时性的入口

(2)无法获取系统级别的通知,提醒,动效等等

(3)用户留存率低

(4)设计受限制诸多

(5)体验较差

(2)Hybrid App

Hybrid APP指的是半原生半Web的混合类App。需要下载安装,看上去类似Native App,但只有很少的UI Web View,访问的内容是 Web 。

例如Store里的 新闻类APP,视频类APP普遍采取的是Native的框架,Web的内容。

Hybrid App 极力去打造类似于Native App 的体验,但仍受限于技术,网速,等等很多因素。尚不完美。

(3)Native App

Native APP 指的是原生程序,一般依托于操作系统,有很强的交互,是一个完整的App,可拓展性强。需要用户下载安装使用。

优点:

(1)打造完美的用户体验

(2)性能稳定

(3)操作速度快,上手流畅

(4)访问本地资源(通讯录,相册)

(5)设计出色的动效,转场,

(6)拥有系统级别的贴心通知或提醒

(7)用户留存率高

缺点:

(1)分发成本高(不同平台有不同的开发语言和界面适配)

(2)维护成本高(例如一款App已更新至V5版本,但仍有用户在使用V2, V3, V4版本,需要更多的开发人员维护之前的版本)

(3)更新缓慢,根据不同平台,提交–审核–上线 等等不同的流程,需要经过的流程较复杂

二、Web App、Hybrid App、Native App 技术特性

论WebApp、HybridApp、NativeApp设计差异

由上图可见,Web APP 的开发基于Html5语言。而Html5语言本身又有着不可避免的局限性。正是这些局限性的存在,使得Web App在体验中要逊于Native App。

三、Web App受限制因素及设计要点

论WebApp、HybridApp、NativeApp设计差异

相比Native App,Web App体验中受限于以上5个因素: 网络环境,渲染性能,平台特性,受限于浏览器,系统限制。

(1)网络环境,渲染性能

Web APP对网络环境的依赖性较大,因为Web APP中的H5页面,当用户使用时,去服务器请求显示页面。如果此时用户恰巧遇到网速慢,网络不稳定等其他环境时,用户请求页面的效率大打折扣,在用户使 用中会出现不流畅,断断续续的不良感受。同时,H5技术自身渲染性能较弱:对复杂的图形样式,多样的动效,自定义字体等的支持性不强。

因此,基于网络环境和渲染性能的影响,在设计H5页面时,应注意以下几点:

简化不重要的动画/动效

简化复杂的图形文字样式

减少页面渲染的频率和次数

从下图移动Web版 jing.fm和Native版jing对比后可以看出:Web APP首页去除冗余的功能,回溯本源,只给用户提供了jing.fm最初的本质需求—电台。既符合H5精简功能又达到了突出核心功能的设计原则。无疑给用户眼前一亮的气息。

正如书中《瞬间之美》的一个核心观点:重要的并不是我们提供的信息量有多大,而是我们能否给他们提供真正需要的信息。

论WebApp、HybridApp、NativeApp设计差异

论WebApp、HybridApp、NativeApp设计差异

再如:百度最新推出的直达号,以良子健身为例:

从Native App和Web App(百度直达号)的对比中,我们可以看出Native良子以九宫格的形式展现,且属于双重导航,功能入口太多;弊端是用户不知道聚焦在哪里,分散用户 的注意力。而Web版良子整合并减少了导航的入口,增强用户的专注度;界面清爽,整洁,很好地传达了良子本身的寓意——轻松、愉悦、休闲、舒适。

论WebApp、HybridApp、NativeApp设计差异

(2)受限于浏览器

通常Web App生存于浏览器里,宿主是浏览器。不同的浏览器自身的属性不尽相同,如:浏览器自带的手势,页面切换方式,链接跳转方式,版本兼容问题等等。

例如下图:UC 浏览器和百度浏览器自身支持手势切换页面。手指从左侧滑动页面,返回至上一级。百度手机助手H5页面,顶部Banner支持手势左右滑动切换。这一操作与浏览器自身手势是冲突的。

论WebApp、HybridApp、NativeApp设计差异

再如,基于浏览器的Web APP在打开新的模块中的页面时,大多会新开窗口来展现。例如用户在使用购物类APP时,浏览每日精选模块时,每当打开新的商品时,默认新开一个窗口。这 样的优劣势显而易见:优势是能够记录用户浏览过的痕迹,浏览过的商品,以便后续横向对比;劣势是过多的页面容易使用户迷失在页面中。

正如Google开发手册里描述:当用户打开一个Web App的时候,他们期待这个应用就像是一个单个应用,而不是一系列网页的结合。然而,什么情况下需要跳转页面,什么情况下在当前页面展示则需要设计师细致考量。

论WebApp、HybridApp、NativeApp设计差异

因此,Web App基于浏览器的特性,从设计角度应该遵循以下了两点:

少用手势,避免与浏览器手势冲突

减少页面跳转次数,尽量在当前页面显示。

(3)系统限制,平台特性

由于Html5语言的技术特性,无法调用系统级别的权限。例如,系统级别的弹窗,系统级别的通知,地理信息,通讯录,语音等等。且与系统的兼容性也会存在一些问题。以上限制通常导致APP的拓展性不强,体验相对较差。例如百度地图:

论WebApp、HybridApp、NativeApp设计差异

Web版地图基于浏览器展现,因此,不能全屏显示地图,给用户的眼界带来局限感;相反,Native 版地图以全屏展现的形式,很好的拓展了用户的视野。整个界面干净简洁,首页去除冗余功能。

在制定路线的体验中,如图:

论WebApp、HybridApp、NativeApp设计差异

Web 版地图耗费的流量大于Native版,且不能预先缓存离线地图。对于地理位置的判断也是基于宿主浏览器,而非Web地图本身。获取路线后,对于更换到达方式,相对来说是不便利的。

相反,Native 版地图,能够直接访问用户的地理位置,能够很清晰的为用户展现App规划的路线,并能轻松的查看多种路线方案,以便做出符合自己的最佳方案。对于切换公 交,走路,自驾等路线方式也是只需一键操作。Native 版地图相对于 Web版地图增加更多情感化,易用的功能,如:能够记录用户的生活轨迹,记录用户的点滴足迹,能够享受躲避拥堵方案等。而Web版地图基于技术框架,很难 实现以上功能,从用户体验角度来看,弱于Native版地图。

四、小结

综述所述,在设计Web APP时,应当遵循以下几点:

(1)简化

简化不重要的动画/动效

简化复杂的图形文字样式

(2)少用

少用手势,避免与浏览器手势冲突

少用弹窗

(3)减少

减少页面内容

减少控件数量

减少页面跳转次数,尽量在当前页面显示

(4)增强

增强Loading时的趣味性

增强页面主次关系

增强控件复用性

最后:小编给大家推荐一组优秀的Web APP

forecast.io/

m.ftchinese.com/phone.html

thenextweb.com

jing.fm

yuedu.fm

mail.google.com

plus.google.com

snowbird.com

everthing.me

m.vancl.com

pattern.dk/sun/

转载请注明出自”百度MUX”

 
反对 0举报 0 评论 0
 

免责声明:本文仅代表作者个人观点,与乐学笔记(本网)无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
    本网站有部分内容均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责,若因作品内容、知识产权、版权和其他问题,请及时提供相关证明等材料并与我们留言联系,本网站将在规定时间内给予删除等相关处理.

  • Handlebars模板引擎介绍和开发指南
    Handlebars是一个Javascript模板引擎,能让你轻松高效的编写语义化模板,它是Mustache模板引擎的一个扩展,Handlebars和Mustache都是弱逻辑的模板引擎,能将Web前端的视图和代码分离,降低两者之间耦合。
    06-26
  • KendoUI2014移动调查报告:HTML5vs原生之辩
    KendoUI2014移动调查报告:HTML5vs原生之辩
    Telerik Kendo UI一直比较关心移动开发领域的使用情况,在最新的2014 HTML5全球开发者调查中,Kendo UI面向3500+个开发者,从普通程序员到CIO/CTO,从大型企业到小型企业,对他们的移动开发偏好展开了调查。
    06-26
  • WebComponents-面向未来的组件标准
    WebComponents-面向未来的组件标准
    对于前端开发者而言,W3C组织制定的HTML标准以及浏览器厂商的实现都是“鱼”而 不是“渔”,开发者在需求无法满足的情况下通过现有技术创造了各种组件,虽然短期满足了需求但是由于严重缺乏标准,导致同一个组件有成千上万的相似实现但 它们却无法相互重用,这很大程度上制约了组件化的最大价值-重用,Web Components则在组件标准化方面向前迈了一大步。
    06-26
  • AppCan:HybridApp技术已经成熟
    AppCan:HybridApp技术已经成熟
    在移动开发技术里,Native App和Web App之争一直没有停息,而介于Native和Web之间的Hybrid混合App异军突起,以其接近Web App开发简单、跨平台能力,以及接近Native App功能和性能表现逐渐为开发者们所接受,那么,现在Hybrid App发展到了什么程度呢?正益无线技术支持总监邱革节在接受51CTO记者采访时表示,Hybrid App技术已经成熟。
    06-26
  • 什么是ShadowDom?
    什么是ShadowDom?
    如果我需要把每个自定义的按钮都放到iframe里,你是什么感觉,会不会疯掉?所以,我们需要一些更好的东西。事实上,大部分的浏览器已经变相地提供了一种强大技术去隐藏一些实现细节。这个技术就是所谓的“shadow DOM”。
    06-26
  • 使用ShadowDOM创建Web组件
    使用ShadowDOM创建Web组件
    Web Components(组件)标准是一系列最新推出的标准,它可以被用来创建可被复用的Web部件,当页面中所使用的Web部件被更新为新版本时不必修改 页面中其他任何代码。这里所说的部件,是一种可实现与用户之间的交互的可视化组件,开发者可以使用HTML代码与JavaScript脚本代码来开发这些 部件。Web Componnts标准定义如何开发这些部件。
    06-26
  • GooglePolymer以及WebUI框架的未来
    开发者Axel Rauschmayer在自己的博客上详解了Google Polymer的设计理念与组成架构,深得Polymer开发者的认同。他认为Polymer这样高互操作性的设计才应该是Web开发的未来。
    06-26
  • WebComponents实例:移动UI组件库GMU介绍
    GMU(Global Mobile UI)是百度前端通用组开发的移动端组件库,具有代码体积小、简单、易用等特点,组件内部处理了很多移动端的bug,覆盖机型广,能大大减少开发交互型组件的工作量,非常适合移动端网站项目。
    06-26
  • 移动应用新趋势:离线WebApp
    移动业界已经最终放弃了不分时间、不分地点为用户提供互联网连接服务的幻想。我们也看到了一系列新型产品与服务,它们的兴起标志着我们将以更为灵活的方式在无法接入网络时继续享受功能与便利。
    06-26
  • 2014年Web开发的7个转变方向
    2014年Web开发的7个转变方向
    很多读者喜欢预测网页设计趋势,让自己能够在网页设计、甚至网络发展中保持先机。找准每一年的发展趋势很重要。那么,2014年会有怎样的发展?我们一起来分析。
    06-26
点击排行