大屏时代的生态变迁,看平板手机的拇指热键与界面布局

引言:曾几何时,无数大大小小的触屏设备仿佛泄闸的洪水一般涌入这个世界。面对突如其来的生态变迁,界面设计师们别无选择,只有在急流当中奋力学习游泳,才能让自己不至于被洪潮所吞没。本文带你了解如何面向平板手机的拇指热键与界面布局,为这种转变提供助力。

本文选自《触类旁通:多终端时代的触屏界面设计》。

人们怎样使用平板手机

  iPhone出现之后的几年,手机屏幕的尺寸基本都保持在4英寸以下(以对角线计算),非常便于单手操作。然而,随着大屏手机不断涌入市场,到2014年年中,已经有将近三分之一的移动Web浏览量来自这些设备。大屏手机填补了传统触屏手机与平板电脑之间的空白地带,有些大屏手机的屏幕甚至达到7英寸之巨,因此也获得了一个略显蹩脚的绰号——平板手机。

  

            

            

  这类设备虽然有着巨大的身形,但人们仍然会将其作为手机使用。不过,与小屏设备的情况不同,为了在如此巨大的屏幕上舞指自如,用户必须更加频繁地在不同的持机方式之间切换,而且在多数时间里需要双手同时参与。平板手机用户在将近70% 的操作时间里会同时使用两只手,其中一手持机、另一手食指操作的方式最为普遍,约占35%。不过即便如此,对平板手机来说,真正占据交互主导地位的却依然是拇指:在60% 的时间里,用户会通过拇指进行触屏操作,无论持机方式是单手还是双手。

          

虽然就某一姿态而言,一手持机、另一手食指操作的方式占据的比例最高(35%),但包含拇指操作的所有持机方式的总和却达到了60%。

平板手机的拇指热区

  由于拇指操作同样占据主导地位,所以对平板手机来说,拇指热区的重要程度与在小屏手机上的情况旗鼓相当。不同之处在于,平板手机用户会更加频繁地通过双手拇指同时进行操作。在这种情况下,拇指热区也会相应地分为两部分,分别位于屏幕下方的左右两侧,其中还会产生交集,而屏幕上方的广阔区域则是拇指在正常情况下难以触及的。不过,对设计师来说,需要优先考虑的仍然是拇指热区范围最小的持机方式,也就是单手持机操作。

其实这也正是我们的第一条拇指设计原则:无论对何种规格的触屏设备,都要优先考虑拇指热区最小、操作局限性最高的持机方式,这样才能确保人们在任何姿态下都能与界面进行正常的互动。因此,对平板手机而言,我们首先应该聚焦的仍是单手持机操作的情况。

  这里有个挺有意思的现象:同是单手持机操作状态,平板手机上的拇指热区面积却比普通手机上的小。这是因为,在小屏规格范围内,无论屏幕尺寸如何变化,拇指热区基本都能保持相似的形状及位置,而一旦屏幕尺寸突破了某个临界值,人们通常需要将小指从屏幕下边缘移至机身背后,使其与另外三根手指一起托住手机才能保持稳定,但这种姿态会使拇指的活动范围及相应的热区面积变得比平时小。

            

单手操作平板手机时,人们必须将除拇指之外的四根手指托在机身背后才能保持稳定,这就使拇指的活动范围及相应的热区面积变小了。

  在单手状态下,平板手机的屏幕上方会有很大一部分区域处于拇指的控制范围之外。面对这种情况,人们在实践中也有对策,例如直接握住或托住机身中部靠上的位置,使拇指的控制区域得到变相的扩展。

                     

       高位持机方式可以向上扩展拇指热区,但同时会使屏幕下方的更多区域脱离拇指的控制。

平板手机的界面布局

  随着手机屏幕的增大,更多的界面元素被迫移出拇指热区,布局设计需要针对这一情况进行调整。尽管平板手机用户更习惯于根据不同的情况主动调整持机方式,但作为设计师,我们有义务去降低额外的费力度。无论对何种规格的触屏设备,都要优先考虑拇指热区最小、操作局限性最高的持机方式,这样才能确保人们在任何状态下都能与界面进行正常的互动。因此,对平板手机来说,也要尽可能将高频功能元素集中放置在单手操作的拇指热区当中。或许你还记得,同是在单手操作状态下,平板手机的拇指热区面积实际上比普通手机的更小,不过这两者的形状及位置类似,因此一些基本的设计原则也是相通的。

  在平板手机上,仍然需要将导航及高频功能控件放置在屏幕底部。无论用户怎样持机,平板手机的屏幕顶部区域总是相对难以触及。所以,和在小屏手机中一样,我们在这里仍然要强调“内容在上,控件在下”的原则,从而使高频交互元素尽可能保持在拇指热区范围内,并避免内容被手指遮挡。不过,例外情况仍然来自Android。虽然根据Android设计规范的要求,我们应该在小屏手机中将App的导航与功能控件放置在顶部,以避免与底部的系统导航栏产生冲突,但是在大屏设备上,可以将一些高频控件从标准的Action Bar中移出,并放置到屏幕底部。其实这种分体式Action
Bar模式最初是面向小屏设备设计的,但如今已被证明对大屏手机更为适用。

            

在默认情况下,Android的Action Bar会将所有的导航及功能选项整合到界面顶部(左),而分体式Action Bar则会将一些重要功能放到屏幕底部,使其更便于被拇指点击(右)。

  

  然而,适用并不等同于理想。在Android中,将交互元素堆叠在屏幕底部的做法确实容易增加误操作的可能性,这是客观事实。但是,鉴于平板手机巨大的屏幕尺寸,单手状态下又难以触及屏幕顶部区域,所以权衡下来,将一部分控件移到底部的做法还是合理的,哪怕要冒一定的风险,也至少可以让人们在单手操作的时候能够轻松点击。我们在前文中提到过,系统平台复杂的环境特性需要设计师不断进行各种权衡与妥协。在举棋不定时,要记得“两害相权取其轻”的原则——一方面是误操作的可能性增大,另一方面是无法操作,在这种局面下前者显然更有利。

  此外,悬浮按钮也是很实用的设计模式。这类按钮通常位于界面右下角,悬浮于内容之上。可以通过这种方式将App全局或当前界面中最重要的功能提供给用户,例如发表照片或签到、发消息等。点击之后将悬浮按钮变形为横向工具栏或辐射菜单也是不错的交互模式。

           

  与分体式Action Bar模式类似,位于屏幕底部的、有可能导致误操作的悬浮按钮同样体现着妥协的初衷。不过毕竟单一按钮的尺寸较小,不会像在系统导航栏上堆叠一层工具栏那样带来很大的影响。在Android的UI体系当中,这种悬浮按钮称为“FAB”(Floating Action Button)。读者有兴趣的话不妨阅读Android设计规范(http://bkaprt.com/dft/01-16/),进行更加深入的了解。

                 

  可以通过屏幕底部的悬浮按钮触发更多功能,同时避免与Android的系统导航栏产生大范围的冲突。

  

  此外,也可以尝试将控件放置在顶部,但使其能够响应某种作用于屏幕下方的辅助交互形式。例如,可以将Tab导航放在内容上方,但使其切换能够被内容区域的左右滑动手势控制,这也是一种变相的拇指友好模式。

                  

    Android的“通讯录”是一个典型的例子。用户可以直接点击Tab本身,也可以通过左右滑动操作来切换Tab。

  这种模式通常适用于Tab导航。在小屏手机上,用户可以相对轻松地点击顶部Action Bar中的Tab;而在平板手机上,直接在内容区域左右滑动实现切换显然是最为便捷的。实际上,早已普及的下拉刷新模式也是相同的道理,用户不必与界面远端的某个控件产生交互,只要直接在内容上进行手势操作即可。

  对于移动版本的网页,仍然建议使用前文中介绍过的锚点链接导航模式。我们在小屏设备上遇到的诸如CSS兼容性局限或页面元素与浏览器自身布局冲突等一系列问题,在平板手机中依然存在。诚然,将锚点链接放置在顶部的做法算不上对拇指友好,但综合考虑,这个因素在浏览器环境中的重要性就没有那么高了。我总会在用户研究中观察到这样的现象:对移动设备上的网页,除非用户在主要内容区域实在无法找到自己需要的信息,否则他们几乎不会想起主导航。从这个角度讲,将导航菜单放置在主要内容的下方,让用户在最需要的时候能够用到,也是非常合理的做法,同时不会使拇指受苦。

  避免手指跨屏操作。多数人的拇指长度不够在平板手机上进行横跨屏幕的点击。在单手持机的情况下,不用说对角线,即便让右手拇指去点击位于屏幕左端的元素也是相当困难的。所以,要尽量避免将重要的交互元素紧贴左右两侧边缘放置。在尺寸方面,要尽可能使元素的宽度达到屏幕宽度的三分之一以上,最好可以接近屏幕宽度,从而最大程度降低拇指操作的费力度。

  不要随着屏幕的增大而放大手势操作的触发区域。以横滑展开菜单为例,在平板手机上,不要放大横滑所需的距离,别让用户必须在整个屏幕范围内使用手势才能达到触发效果。人们使用屏幕巨大的手机,不代表他们有着巨人般的手,手势应该围绕手指进行设计,而不是围绕屏幕。

  整体移动。界面中的多数元素是静态的,需要我们自己伸手触及。我们要去点击按钮,而按钮从来不会主动移到我们手边。但事情也并非完全如此。三星为其Android平板手机创造了一种独特的单手操作模式(如图1.26所示),整个界面会缩小到普通小屏手机的尺寸,这样就使几乎所有的交互元素都能位于拇指热区当中了。实际上,这种模式相当于临时把大屏手机缩小了。虽然操作便捷了很多,但经常这样使用又显得很尴尬——既然大屏无法得到充分利用,当初何必要购买这样的设备呢?

  iOS则采用了一种称为“触达性”的设计模式。连续两次轻触“Home”键,界面便会整体下移,从而使顶部元素进入拇指热区。当用户完成接下来的操作之后,界面便会自动上移至初始位置。这种模式使得界面顶部的元素更容易被单手拇指操作,在效果上等同于用户将自己的持机手上移。相比三星来说,苹果的实现方式有一个显著的优点——将界面移位而非缩放,可以避免交互元素本身的尺寸或布局发生变化。

             

三星的单手模式可以将界面整体缩小至小屏手机的规格(左),而苹果的“触达性”则是将界面下移至拇指的控制范围内(右)。

  除了苹果与三星提供的这类系统级的解决方案以外,我们还可以在自己的产品中采用类似的思路,例如通过滑动面板的形式来承载内容。与系统提供的上下移动界面的方式不同,在App或网页内部,一种更具实践性的做法是在界面边缘放置某种“抽屉把手”,形如按钮或Tab,点击之后即可展开整个面板。

  

               

       TIME在其移动版页面侧边放置了一个“抽屉把手”,点击之后会展开一个完整的近期新闻面板。

  

  在屏幕左右边缘放置的交互元素很可能处于平板手机的拇指热区之外,但无论怎样也比放置在顶部更加容易操作。你也可以为这种模式添加横滑展开的手势,只要不与界面整体的横滑回退效果产生冲突即可。总体上讲,功能控件位于屏幕左右边缘的模式更适用于双手拇指同时操作的情况,因此在平板电脑的界面中更为常见。

  本文选自《触类旁通:多终端时代的触屏界面设计》,点此链接可在博文视点官网查看此书。

                    

  想及时获得更多精彩文章,可在微信中搜索“博文视点”或者扫描下方二维码并关注。

                       

时间: 2024-10-22 17:12:38

大屏时代的生态变迁,看平板手机的拇指热键与界面布局的相关文章

徒手教你制作运维监控大屏

公司业务的不断发展,紧接而来的是业务种类的增加.服务器数量的增长.网络环境的越发复杂以及发布更加频繁,从而不可避免地带来了线上事故的增多,因此需要对服务器到应用的全方位监控,提前预警. 建立在Zabbix上的服务器监控.基础应用监控(mysql.redis.ES等).预警功能 基本满足底层的监控预警要求,超过设定的阀值就会提前通知相关人员去解决. 有了Zabbix为什么还需要Grafana? Zabbix图表聚合功能非常薄弱,这不是它的强项,而且数据源只限定自己的收集器,图表展示类就是Grafa

一个大屏监控的项目

写大屏监控,本人选择的是用vue.element ui.echarts.axios.vueg来构建的. 1 vue init webpack my-project 2 3 //安装依赖 4 cd my-project 5 cnpm install 6 7 //加入elementUI 8 cnpm i element-ui -S 9 10 //加入echarts 11 cnpm install echarts -S 12 13 //加入 axios 14 cnpm install axios -S

简单几步教你如何将手机投屏到电视,1秒小屏变大屏

不知道大家有没有一种手机看电影,看视频,屏幕限制太大,总觉得好像少了点东西? 修姐,就是!总是赶紧我好像少看了一些画面,让你瞬间体会满屏的效果! 简单几步教你如何将手机投屏到电视,1秒小屏变大屏!高中之前一直看的电视,投影电影等:大学也是躺在宿舍用电脑刷剧:演变到现在基本上都是手机刷,电影院也是很少跑.可是手机屏幕还是太小了,很多画面看着总感觉不够震撼,少点感官需求! 但是把手机上的画面投到电视上,不论是看剧还是打游戏,那个体验一定是很爽!既享受到了手机的丰富资源和便利,又可以享受电视高清大屏的

Qt编写项目作品大全(自定义控件+输入法+大屏电子看板+视频监控+楼宇对讲+气体安全等)

一.自定义控件大全 (一).控件介绍 超过150个精美控件,涵盖了各种仪表盘.进度条.进度球.指南针.曲线图.标尺.温度计.导航条.导航栏,flatui.高亮按钮.滑动选择器.农历等.远超qwt集成的控件数量. 每个类都可以独立成一个单独的控件,零耦合,每个控件一个头文件和一个实现文件,不依赖其他文件,方便单个控件以源码形式集成到项目中,较少代码量.qwt的控件类环环相扣,高度耦合,想要使用其中一个控件,必须包含所有的代码. 全部纯Qt编写,QWidget+QPainter绘制,支持Qt4.6到

乐视狂推的大屏游戏生态,是否会成为又一潜力市场?

5月31日那天,乐视在北京又双叒叕召开了一场发布会. 这场发布会推出了三款全新生态电视,按照乐视一贯的风格,这几款电视不仅都是"高体价比"的买卖,而且在配置与性能让面完全秒杀其他友商三条街,总之就是非常值得"买买买"的典范.不过,对于我自己来说,全新的电视固然吸引关注目光,但这场发布会更吸引我的另一个焦点是乐视推出了大屏游戏生态.从整场发布会的比重来看,虽然大屏游戏生态的内容在整场发布会中所占的比重并不是很大,但从乐视擅长的生态经营方法来看,这次全新尝试的乐视大屏游

乐视电视成生态完美落地第一案例,大屏商业化加速

在这周的媒体沟通会上,乐视方面表示今年6.18的生态全通路销售目标为30亿人民币,又一次成为行业关注的焦点.而去年919的销售额则为17.8亿元,刚刚结束的"414硬件免费日"销售额是23.2亿元,不断刷新着行业纪录. 笔者认为,乐视能够不断创造奇迹,与其创造亦或顺应了趋势密不可分.就在近期在5月15日乐视"超级爱+"发布会上,乐视致新营销传播副总裁任冠军,在演讲中曾提及乐视超级电视发布之初,曾有言论质疑乐视生态能力,而这三年风雨的冲刷和辛劳的耕作,创造了行业的新玩

大数据时代数据库-云HBase架构&生态&实践

摘要: 2018第九届中国数据库技术大会,阿里云高级技术专家.架构师封神(曹龙)带来题为大数据时代数据库-云HBase架构&生态&实践的演讲.主要内容有三个方面:首先介绍了业务挑战带来的架构演进,其次分析了ApsaraDB HBase及生态,最后分享了大数据数据库的实际案例. 2018第九届中国数据库技术大会,阿里云高级技术专家.架构师封神(曹龙)带来题为大数据时代数据库-云HBase架构&生态&实践的演讲.主要内容有三个方面:首先介绍了业务挑战带来的架构演进,其次分析了A

柯南君:看大数据时代下的IT架构(5)消息队列之RabbitMQ--案例(Work Queues起航)

一.回顾 让我们回顾一下,在上几章里都讲了什么?总结如下: <柯南君:看大数据时代下的IT架构(1)业界消息队列对比> <柯南君:看大数据时代下的IT架构(2)消息队列之RabbitMQ-基础概念详细介绍> <柯南君:看大数据时代下的IT架构(3)消息队列之RabbitMQ-安装.配置与监控> <柯南君:看大数据时代下的IT架构(4)消息队列之RabbitMQ--案例(Helloword起航)> 二.Work Queues(using the Java Cl

看大数据时代下的IT架构(1)业界消息队列对比

一.MQ(Message Queue) 即消息队列,一般用于应用系统解耦.消息异步分发,能够提高系统吞吐量.MQ的产品有很多,有开源的,也有闭源,比如ZeroMQ.RabbitMQ.ActiveMQ.Kafka/Jafka.Kestrel.Beanstalkd.HornetQ.Apache Qpid.Sparrow.Starling.Amazon SQS.MSMQ等,甚至Redis也可以用来构造消息队列.至于如何取舍,取决于你的需求. 由于工作需要和兴趣爱好,曾经写过关于RabbitMQ的系列博