房子比工作更难找，但他们依然选择来这奋斗打拼。
这一天几乎全村的老百姓都到他们家里道喜祝贺。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　?点击上方“交互设计学堂”关注我们,送电子书
　　移动大潮席卷了你我。
　　如何利用数据可视化帮助改善移动端的交互体验？来自华尔街日报、Bloomberg 等顶级新闻工作室的新媒体从业者们是这样思考的。
　　本文编译自 niemanlab，原标题 Small screens, full art, can’t lose: Despite their size, phones open up new opportunities for interactives。
　　如何将台式机上优美的交互体验搬到手机上？在我肤浅的认知里，数据是很重要的一环。但目前的问题是，数据太多，甚至没有足够的位置去展现。
　　手机有大量不同的功能，用户随功能产生不同的行为，开发者和设计师必须考虑这一点，不能想当然地认为移动端是桌面端的简化版。
　　「移动设备若具备了能够感知倾斜和移动的陀螺仪、优秀的定位功能和内置摄像头，它将大有可为，」华尔街日报全球视觉负责人 Jessica Yu 说，「所有终端都有它独一无二的特点」。Yu 告诉我，期待在 2050年的新闻交互世界中，人们倾斜手机，就可以看见透镜状的图像，获得为读者准备的彩蛋。那时，台式机交互会变得不那么重要。
　　有时候，「移动端」优先的思考决定了「桌面端以何种方式组织图片与交互行为」，甚至决定了内容团队组织信息的方式。
　　「我们正在努力摆脱『大屏设计』的习惯，所有人的思考全部向『移动化』转变。」NPR 视觉负责人 Brian Boyer 强调道，「如果这个设计在移动端行不通，它就不是好设计。我们已经基本放弃那种华丽的、大型图表设计了。」
　　当我要求开发者和设计师详细解释一下他们如何在交互中融入「移动端」的考虑，所有人都觉得，智能手机提供了更多创造性的方式呈现内容。但同时也在一些方面表达了相同的挫折感：
　　全屏地图、iOS 禁止自动播放视频、数据过载、同时适配平行和垂直界面。
　　下面是这些从业者的声音。
　　洛杉矶时报：好的交互需要大胆取舍数据
　　Len DeGroo，数据可视化总监
　　时间的紧迫度决定了我们使用哪种交互方式，同时，你一定得明确数据对用户具体的意义。比如，在「洛杉矶老化水管」的案例中，我们认为读者最想知道离他们最近的水管泄露点在什么位置，所以我们使用「地理位置」服务，让读者在手机上能查到离他们最近的泄露点。
　　某些交互方式在手机上行不通，所以我们有时干脆在移动端禁用这些功能。如果移动端的阅读体验太差，我们会将地图的内容推倒重来。
　　如果信息图必须呈现为「纵向」，而且数据很繁杂，那么它在移动端往往就行不通。当你缩放它，它在小屏幕的终端就无法正常阅读了。我们应该做的是――在更大的框架中收集并简化信息碎片，以便读者把握数据，并看到数据的趋势。否则就只能变换图像的方向了――当然，让读者翻转他们的手机体验不太好。
　　要优化移动端的阅读体验，就要放弃复杂的数据和结构。我们很爱用 D3.js，但很可能 HTML 就够用了，要从追求「高科技」的状态中走出来，为页面减负。
　　但我们会一直为复杂数据在移动端的呈现思考好的交互方式。
　　在移动端加载视频确实是个头疼的问题（尤其是iPhone不允许视频自动播放），但我们不是没有解决方法。比如在「迦迪纳的警方监控录像」这个案例中，你可以选择不同的camera，倒放或者略过，在移动端我们则简单做成了小的 GIF，放入 HTML canvas 元素中。
　　柏林晨邮报：远近交互都要行得通
　　Julius Tr&ger, 交互负责人
　　在柏林墙崩塌 25 周年之际，我们打算调查柏林这几年的城市变化，并向城市数据库申请了解所有「柏林居住者」实际的出生地，但数据并不详细。但当一年后再度申请，我们拿到了一张巨型 Excel 表。
　　当时我们脑子里有两件事。第一，这些数据的新闻性在哪儿？答案是，在柏林，你很少能遇上一个在柏林出生的人。第二，我们怎么吸引读者？交互有个规则：远处和近处的信息交互，必须都能行得通。且读者看到第一个画面时就要感觉有意思：啊，这是「与我有关」的新闻。
　　对于 Zugezogenen Atlas 互动工具所显示的「柏林人」的实际出生地，详细信息（即近处信息）的展示非常重要，因为人们很可能需要在地图上放大他们的家乡，观察周边设施。
　　我们把交互地图的中心展现为整个德国，如果你想要更大的图景，缩放即可。你能在地图上找到具体的乡址和相关数字，并将它们分享出去――它在脸书上有上万次分享，对于我们这样的地方报纸来说真的挺多了。
　　后来我们又加上了「出生地最多的 100 个城市」，和关于「柏林的外来人居住在此的理由」的视频内容。
　　在手机上操控地图并不容易。在台式机桌面上，你可以用鼠标「悬停」，但在手机上你必须「点击」，结果就没有太多容纳提示信息的空间了。但我们找到了解决方案――至少现在没人抱怨过这个方案――那就是当你输入地址，地图就将它即刻放大。这样用户只要集中精力把地址输对就行了，不用漫无目的地平移和缩放。
　　桌面端和移动端需要同时考虑。当我们有了一个基础的想法后，就用文字或一些其他元素把它展现出来，交给设计师。设计师会为桌面端和移动端设计两套模型，接着开发人员去建模。
　　我们并没有特别严格的工作流程，只是通 Slack 和 Trello 交流模型的好坏，并保持产品迭代。
　　视频是个大麻烦。苹果公司不允许 iOS设备自动播放视频，你必须首先点击「开始播放」，然后视频变成全屏（所以你就从主页面跳出了）。我们这个产品中，「不断变化的天际线」的交互非常复杂，当你滑动阅读到特定文字的时候，地图也会显示到相应的位置。这套方案必须也能在移动端跑通。最后我们使用了我一个在纽约时报工作的大学同学所写的一个叫canvid 的开源 hack，先抽取出视频的不同框架，生成图像，然后合并为一个镜头。这样你就能在 iPhone 上看到柏林「变幻的天际线」了。
　　我很高兴能听到来自读者的称赞――而非数据分析师或技术人员的。因为我们真的为之付出了巨大心血。
　　公共廉政中心：为移动端做交互设计，你就是在设计内容本身
　　Yue Qiu, 新闻 app 开发者
　　交互图的设计重点并不在于设计，而在于怎样通过个性化的设计让数据与读者的位置、家乡、职业（或某些他们已知的东西）相关。简而言之，就是让读者在乎数据。然后才到设计环节。你需要找到一个吸引人的数据呈现方式，同时它兼容不同设备。
　　桌面和移动端需要两种完全不同的设计，并不是随意平衡一下屏幕大小就算完了，小屏的交互只能吸引有限的注意力。为移动端做交互设计，你就是在设计内容本身。
　　台式机上「点击」的动作在手机上很好实现，问题在于你不可能做到「悬停然后释放出更多信息」，用户不会喜欢这样的功能。
　　如果手机上也要实现悬停数据交互的话，就必须分步实现，不然用户会很迷惑究竟是该「点击」还是该「滑动」。从数据图中就要得到你的目标信息，这才是移动端好的交互设计。
　　手机地图是个大工程，尤其是当它需要横向全屏的时候。有时候，你提取出一些有趣的数据制成信息图，那就足够了。在移动端可以少提供一些数据选择，用户不可能去点击每个细节。
　　当展现时间序列数据时，在台式机上可以做小模块。在手机上也有很多方法可以让读者一眼就看懂数据，比如做一个 GIF，或者另外一些直观的方式。
　　一个叫做 Modernizr 的 Java 库是个非常有用的工具，它可以帮助探测屏幕是否是触摸屏，以及屏幕尺寸大小――主要是探测读者使用移动端读数据的概率。移动数据可视化的工具不多，所以每个项目的工具都得看情况去找。
　　华尔街日报：越简单可靠越好
　　Jessica Yu, 全球视觉负责人
　　在移动流量占据 50% 的今天，移动设计绝不再是什么次要的东西了。最初的设计方案需要具有流动性和平台未知性。
　　首先，我们确定下需要展现的内容；其次，钻研如何实现――一个游戏、一系列信息图表、动画、时间线或是视频，我们在头脑风暴中所想的创意，或多或少可以在某些型号的设备上实现。
　　桌面和移动的UI设计有根本区别。桌面设计允许鼠标悬停和点击交互，而手机允许滑动、倾斜或更为随意的物理摇晃。在手机上，你要设计一种靠滑动展现信息逻辑的路径。比如「From Pluto to theSun」呈现给玩家的是整个「宇宙」，桌面用户可以在屏幕上随意点击任意星球。但在手机有限的视野中你不能呈现这种效果。所以我们设计了一种垂直滑动的交互方式，默认展现打开的信息图（在桌面上你需要点击进入）。
　　我们利用所有可利用的工具为产品建模，不管是代码、Illustrator、Sketch，还是传统的纸笔，这都影响了我们最初的断点设置。我们的模版预先确定好了手机、平板和桌面视口的网格断点，这有助于对模块化的思考。同时，也要为这些项目的社交推广做考虑。
　　为了容纳这样的交互设计，我们创建了一种基于用户引导的 HTML模块，关联到我们的网格断点和样式表上，以此容纳基本反馈和类型层级。客制工作不可避免地要置于最高层级。考虑到我们的交互器模块，我们创建了一整套内置的内容响应工具容纳新闻编辑室的需求。移动体验是输出的一部分，不需要编辑进行额外的客制工作。
　　一些建议：
　　尽量减少不必要的交互。这通常意味着禁用图表提示和地图缩放。
　　固定地点的覆盖在移动端的精度要求很高且操作复杂，可尝试使用「折叠式」设计或干脆链接到一个新页面。如果你必须使用固定元素，确保即使延展开来，也不会超过屏幕的 30%。
　　最适合桌面的图表样式通常在手机上水土不服，别觉得换成柱状图就一定 LOW。动画也是相同的道理。越简单可靠越好，比如只是一个简单的渐变或是直线运动。
　　如果你使用单柱式设计，拒绝把一切藏在下拉框中的需求，因为交互体验太差。用户更习惯简单的滑动和有限的按钮。
　　对于时间相关的图表，要尽量展现更近的数据。
　　美国国家公共电台：别让我必须交互才能读到些什么！
　　Brian Boyer，NPR 视觉组负责人
　　我们最大的成绩是创建了开源系统 DailyGraphics，一款让懂代码的人更易创建图表的工具，它不支持点击指向和所见即所得，也跟 chartmaker from Quartz那样的工具有所不同，使用它首先要对Java、CSS 等语言很熟练。
　　它就像一套我们使用的初始模板。从柱状图开始，慢慢变成一个常用图表样式库，你可以直接复制并加工。NPR 的图表在视觉表现上并不突出，那是因为人们通常拿它和印刷的杂志页做比较。我们 Elections 的网页是以移动端优先考虑的，你浏览下网页版就知道了，它是我们移动版的延伸。
　　Elections 的图表被置于一个标准框架中，没有给本身体量很大的州太多位置。我们曾想尽力展现州的力量，但最后出来的样子像俄罗斯方块。
　　所以我们给各州做了垂直频道，每个州有多少选票都被分开展现。选票会一夜之间填满，当票数达到某个临界值，那位竞选人就赢了。对我们来说，这样的页面就已经足够优美，它在手机上行得通。
　　做地图很难。我们不太做国家地图，除非地理位置真的非常重要――比如河流走向、山峦范围、鸟类迁移等。我们做的是主题地图，最近大家喜欢去做各州的比较统计地图，每个州都是一个正方形，但我们觉得六边形才更接近地反应了实际地理状况。
　　我们反对过多的交互。别让我必须交互才能读到些什么！许多像悬停交互一类的东西，移动端根本走不通。我们最近做的交互都是步进式的：点击、加载进程，然后你看到一些变化。
　　最近我很满意的一组可视化成果，是关于沃尔玛城市分布点变迁的一组图。在桌面上它们一排三张，但在手机上它是一个 GIF。
　　还有别的妙招。我们设计了一个叫 MapTurner 的工具――基于代码线性控制，生成基于定位的矢量地图，虽然我们同样会使用扇形工具。MapBox 已经不再用了，虽然惊艳但在手机上行不通。
　　我们还在日常图表系统中植入了一个响应式框架库 Pym.js。使用 Pym，图形会告诉页面需要多少容量，图形尺寸也同时支持纵横变化。
　　彭博商业评论：减少用户在获取重要信息过程中不必要的「摩擦」
　　Blacki Migliozzi, Mira Rojanasakul, Alex Tribou, Bloomberg 图像组
　　Rojanasakul：
　　研究了文本后，我可能会先开始在 Illustrator 中建模，然后别人开始在 HTML 页面中建模，我们使用大量 D3。我知道别的组也会使用像Highcharts 这类工具，虽然简单但非常受限。
　　但最终还是内容决定了设计和交互展现的形式，有些可以做成巨大的桌面工程，有些只能在小小的移动端展现。
　　Migliozzi：
　　从网页开发者的角度看，我们更推崇自适应设计。我们需要考虑能适应所有界面的所有可能的版本，然后再去决定哪个最好。
　　有时一个动画会拖累网速，但我们又想留下它，所以只好妥协把它做成静态的形式，但同时读者可以在小的移动设备上看懂它是什么意思。
　　Tribou：
　　不管怎样，你最终的目的都是要让读者能非常容易地得出结论。要让读者在各自的平台上读懂图表，每个平台所需要的交互形式都可能是不同的。
　　Rojanasakul：
　　「budget quiz」这个案例非常合适我们。我们一直在想的是如何只通过一系列的点击让产品完型，减少用户在获取重要信息过程中不必要的「摩擦」。
　　我们曾建了一系列步进式图表，但后来放弃了，因为「滑动」的体验似乎更好。
　　Tribou：
　　我们用滑动取代点击式体验。因为对用户来说，不用再次进入某个页面，获取信息会更容易。
　　Migliozzi：
　　「是什么让地球变暖」是我们一个简单却非常棒的案例。没花多少时间，没有太多信息，但它非常棒。
　　与之相对，「二氧化碳时钟」这个案例耗时数月。我们创建了室内模型预测大气中二氧化碳的含量，验证模型的精确性耗费了我们大量精力，但图表的效果是干净简单的。因为「二氧化碳时钟」是个常青项目，所以耗费那些精力也是值得的。但有时你一周做的东西也能常青，很难说。
　　我们被赋予很大权限去追求不同的展现形式。我们基本上是一直在考虑怎么把想法真的做出来。一年光景，情况就会截然不同，有些旧的数据可视化形式会显得很过时。但其实不是这样，我们还是会在工作中提取旧的图表，然后不断优化旧图表，跟它们死磕。
　　图片来自 niemanlab
　　回复003看8-12月精华文章目录
　　加微信，和老D一起学交互，我会在朋友圈多发些好文章哦。
　　另外新手小伙伴可以提问咨询，不过仅限3个问题哦。
　　欢迎投稿：
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
交互设计学堂
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：手机软件交互设计经验分享–硬件、系统平台和设计规范的影响
Iphone和Android系统手机风靡全球的同时，移动互联网的发展也掀起了一股热潮。最近发现身边一些朋友纷纷在做手机上的第3方应用，或多或少碰到了些困惑，也许对于做惯了基于浏览器的产品的设计师来说，有一些比较典型的要点容易被忽略，这就容易引发出：找不到手机软件的感觉、布局经常改变、设计和优化时找不到明确的立足点等等一系列令人困惑的问题。本人有过一段手机交互设计的时光，将在这里罗列一些总结或感想，带一些建议，供看官们斟酌和评判。
抛开定位、使用环境这样的用户研究体系的大头，专注于说明手机交互设计的特点，其难点在于如何有效的结合硬件、软件平台和设计规范。
以硬件区分手机类型：
仅以物理硬键控制操作的机型（后文简称按键机）
主要以触摸方式操作的机型（通常包含主页、挂机等物理键）
物理硬键齐全，但支持触摸操作的机型（外形和按键机型一样）
主流的可安装第3方应用的软件平台：
塞班s60（第3和第5版）
Windows Mobile for PPC
Java（目前有非常巨大的智能和非智能机型群是包含java平台的）
其他还有很多，诸如plam os、UIQ等
交互设计规范：
一个有经验的设计开发团队，在项目初期会率先着手建立或检查相应平台的设计规范。和web控件规范一样，手机交互设计规范定义了一些常用控件、组件等的布局和响应方式，提炼设计中的公共部分，减少设计和开发的重复思考，并确保整个设计体系的一致性。不同的是，手机交互设计规范不仅有着限定作用，它同时还是一个信息架构的体现、一个创新的过程、并且它还对后续的交互设计起到一定指导作用。我们了解到的iphone的无菜单的风格、各种操作手势、弹出框、标题栏和返回按钮，都是在这个阶段就需要定义好的，而不是具体到某个功能中才任由设计师发挥（所以说创新应该作为一个系统工程，而不是在某几个细节上灵光闪现）。
从设计第三方应用的角度看，大致可以浓缩成以下几个版本的设计规范：
S60第3版—有一套比较经典和严谨的规范 。另外S60第5版虽然是触摸屏机型，但是对于交互设计师的工作来说两者区别并不巨大，只是把OK键替换换成了点击，以及零碎的一些变化。
Java版—事实上由于左右物理控制键和方向键、OK键是按键机型的普遍配置，S60第3版规范的适用 范围是非常广泛的，稍微修改一点就可以适用于Java平台。区别在于手机的“删除”和“返回”两个物理硬键的配置不太一致，所以需要统一将右下角的命令默认为“返回”，在编辑文本时，临时变为“删除”。这样牺牲了某些机型的某些操作的效率，保证了这个整体的机型都可使用。
Iphone OS—Iphone的出现一举打破了之前若干平台固有的设计定势，硬键和操作模式都精简了许多。 不过其缺少固定的menu模式，这对第三方软件的设计来说是个巨大的挑战，要么需要很大程度上脱离iphone自身的设计规范体系，要么就极端精简功能。
Android—跟从了一些iphone中的经典手势，操作和页面布局风格上相对保守一点，保留了menu和back两个硬键，虽然不够独树一帜，但是在功能和设计之间做的了一个不错的平衡，对于第三方应用来说，这是一个可以有宽广发挥空间的平台。
根据上文所述，接下来我就主要以S60第3版、Android、Iphone OS为代表，通过抽取手机交互设计规范中的部分，来说明他们的特性和区别，顺带展开一些个人经验的叙述。
大家请看以下截图：
上面几幅图并没有刻意选择同一类型的界面来对比，我们不妨先仅关注硬键/全局功能键，会发现他们之间的显著不同，实际上反映到设计过程中，这样的区别对界面设计造成的影响要来的更大。
下面以摘取手机交互设计规范的形式来陈述：
1.硬键和手势控制
以上硬键和手势对于操作的控制，需要我们在设计前有个十分清晰的认识，并且整个团队达成一致，如有精力则需要专门写到设计规范文档中。硬键控制是没有什么改动余地的，两款触摸机型可以对手势适当进行取舍，毕竟有些应用用不到所有的手势，能精简操作最好。
（从下面开始，会有一些功能界面，请允许我偷懒一下，用线框代替实际界面截图）
S60第3版的菜单是由左软键或OK键调出，需要定义以下几点：
（注：聚焦到某一条目上时，通常按OK键是打开，但有一些内容包含几种看起来级别相当的操作，此时会弹出菜单选择）
背景是否雾化
每屏最多显示多少条
有无二级菜单，如果有，怎样调出和收回，和一级菜单的位置关系，焦点条的区别
菜单项文字靠左
数字标号，如果整个软件能保证菜单项目均在10位以内，建议加上，这样可以与数字键盘对应
对聚焦项或当前页面不适用的菜单项，是不显示还是文字变灰处理。
OK键菜单只包含针对聚焦内容的操作项，需控制在一屏之内，避免二级项
菜单项的排序规则：针对聚焦项的在上，其他的在下，这两部分中分别按照使用频率从上至下排列
Android传统的菜单是由menu硬键调出，比较多的是2-3行，每行2-3项，看起来像是一些按钮，所以里面的图标和文字都居中。作为第3方应用，如果菜单项稍多，做成一纵列的文字项从操作上来看也未尝不可，毕竟用户刻意记住其默认的菜单形式也没有什么好处。只是仍然需要注意控制一下数量，如果需要二级，可以考虑做成弹出的，比如在一级项中选择“排序”，之后弹出选择框来选择
Android还有一种长按菜单，按住某个项目达到一定时间后，会弹出在触点附近的位置
Iphone并没有一个明确和固定的菜单模式，较保守一点可以说是没有。一些类似菜单的操作通常是通过弹出选择，或者是拆分成几层，一次次点击进入更深层的页面去寻找按钮的形式来达成。所以要做Iphone平台的第3方应用的同学应当提前做好准备，从产品策划开始就着手考虑这个问题。最有效的办法是首先尽可能的缩减功能，其次尽可能的缩减操作方式。否则会发现为了一些细枝末节的操作，还需要设定好几层页面。当然，也可以加入一条操作栏来作为辅助，只是整体风格和操作就不Iphone了。
说到这里，不得不结合前两点延伸一下，对导航系统进行说明：
众所周知，导航系统主要担负着几个任务：展示内容架构、表明当前位置/状态、表明可以去哪里。在网页上的典型形式为全局导航条。在手机上，导航系统同样重要，但是受限于屏幕尺寸，一般没有足够的空间放置这样的组件，但手机有着自己的体系：
我们可以看到各平台对导航系统的规划：
标题–显示当前位置，可以是文字、图标+文字、也可以是一系列tab
菜单–显示可以做些什么，通常包含两种类型的选项：a只针对选中项/只针对当前页，b全局功能如设置和帮助，也就是说菜单大多数作用是发起针对当前页的操作，或者转到和当前页面没直接关系的页面
返回–这个比较复杂一些，也是最需要设计师注意的。鉴于第2条对于菜单形式的描述，如果再加入关联页面的选项，项目数量和类型会使菜单不堪重负。并且页面标题通常无法准确表达出相应页面的内容，即使放入菜单，也需要用户花时间去理解和回忆。所以“返回”很重要：一个固定的位置，简单机械的一个动作，一按—一看—一按—一看，不需要刻意寻找和思考。在一个没有全局导航的环境里，一步步后退到自己浏览过的页面，从而了解当前的页面体系，或者重新发起一系列操作，是个能保证用户找到位置的简单高效的模式。
在做第3方应用时，需要尽可能严格保持以上几点的规范化
焦点更大的意义是在按键机型上，用一个带底色的条框衬托出当前选中的项。
对焦点的设定和控制应当尽可能的简单，需要定义默认聚焦的位置、是否允许上下左右循环
在按键机型上，4个方向键控制焦点向4个方向移动。 通常一个方向只限一种移动方式，如上左图：上下键控制列表区的焦点在列表项间移动，左右键控制标题栏的tab左右切换。 如果列表区也分左右的话，处理起来就复杂了，应极力避免。如上右图：需要先向上移动焦点到标题栏，然后才能按左右键切换tab？但如果当前焦点所在的项处于第2屏，第3屏，或者更靠下呢？是否需要一直按住“上”，直到上边的内容滚好几屏后才聚焦到tab上？
在一些情况下，焦点容易被遗忘，其中某些对触摸屏机型同样适用：
如上图，页面中包含了一些可操作的元素：人名、图片、网址，这里也会隐藏着一些典型操作，例如对网址可能有“打开”“复制”“保存为书签”等操作，此时聚焦并按OK键或者点击则需要出现弹出菜单。
另外还需要注意上文提到的横向和纵向切换焦点的问题，正文中同一行如果有两个名字可以聚焦，但是左右方向键已经被标题栏占用，那么切换人名的优先级应降低，改用别的形式，即使是按上下方向键来左右切换人名也是可以的。
除了菜单功能的以外，弹出框一般出现在屏幕底端，同时其他屏幕其他部分背景雾化，这有利于用户的视线从密密麻麻的小屏幕中快速找到关键：
弹出框有很多种类型，除了“确定”“取消”等元件的基本布局以外，几个平台区别不是很大，大致可以分成几个类型和对应的处理方式，以下是我归纳和建议的一些处理方式，只列最适用于S60第3版的：
列表项的呈现可以集中定义几种模式：常态、编辑/被调用：
编辑/被调用：
6.还有一些方面可以事先定义：
事件处理：无信号、低电量提示的形式和时机、来电、来短信、闹钟时间到、缓存已满、发现新版本等
文本输入：光标的移动、删除和复制粘贴、选中地址/人名等
复杂逻辑的返回路径：有时候会出现操作路径中断并跳转的情况。比如正在写短信时，弹出提示收到新短信，用户此时通过弹出框直接转到了查看短信的界面，此时“返回”是返回到查看短信的上一层，还是回到编辑短信的界面，这些情况想要集中处理，是比较令人头疼的问题。不久前我大概归纳过一套返回逻辑，大意是：a路径默认是从操作步骤向前一步一步返回，或者逐层向上返回；b如果遇到路径跨页面体系转移，先按照a的方式返回，到达跨页面跳转的界面时，允许跨一次跳转，之后按a的方式返回。
以上罗列了一些我的归纳和心得，开始新项目的时候基本可以按此思路先把这些方面统一规范，提及都是习惯用法，追求稳妥的项目可以直接套用，追求创新的项目也可作为一个评判依据。
最后，用一个简单的例子提及一下：设计与系统规范尽量保持一致的重要性。
假如我们把mac系统的软件风格直接搬到windows中，那么在切换不同软件的时候，最小化、关闭等按钮的忽左忽右，会使我们经常默认就把鼠标移动到了相反的方向。
每1个第3方应用在手机中都不可能一个程序在战斗，手机中会自带很多系统应用，例如电话本、短消息、设置、浏览器等，他们都遵循着一样的规范，用户每天也会在这些程序中切换若干次。如果一个第3方应用和他们的基本操作方式不同，每次都会使用户经历仔细观察、出错等过程，想象一下每切换一次软件就要转换一套思维的痛苦吧。当然，规范是可以打破的，如果我们找到了简单高效并且操作方式和习惯用法没有冲突的方式，可以尝试一下。例如以前触摸屏的列表项点击一次是聚焦，再次点击为打开，后来普遍改为点击一次就打开
————————————————————————————————————————————
下期可能的内容：手机交互设计的表达
内容详实，举例丰富}