浅析手机消息推送设计

消息是提醒用户有更新的内容,可能短信、邮件、好友申请和日程安排。消息的作用在于主动提醒用户,不需要主动刷新程序或者网页去检查更新,比如Android的sina微博,必须手动刷新程序才能更新微博或者查看好友申请。这种做法可以节省流量,对于手机包月用户而言非常有必要的。用户专注于当前任务时,可以接收到其他应用程序推送的消息,用户可以及时处理多任务。

推送机制

ff

最基础的方法是程序实时联网获取消息,但是程序会占用内存,频繁联网耗费电量,程序各自链接自有服务器还会占用很多进程。以轮询(poll)的方式实现时需要程序不定地询问服务器是否有更新,推送(push)的好处在于有消息时由服务器告知手机客户端,手机此时再发起更新,省电省流量,所以智能手机平台都会有推送服务。

apns

iPhone自3.0之后推出消息推送机制,原理是消息由服务器统一处理:

  1. 应用服务器Provider将消息和目标发送给APNs
  2. APNs查找目标iPhone并发送消息
  3. iPhone将消息传递给应用程序,再弹出Push通知

APNs和iPhone保持15分钟的心跳式长连接,维护手机和服务器的联系正常,否则手机会不停发起连接,直到连接到服务器为止。程序不必实时开启和主动检查更新,当收到APNs消息时,iPhone会弹出对话框Push消息并伴随着声音,用户可以选择“view”或者“close”。即使用户当前处在离线状态,用户收到消息之后激活程序,再通过程序链接应用服务器下载邮件或者录音。

mspush

WP7的也有相应的推送服务,无论程序是否开启都可以界面顶部推送Toast Notification,并显示10秒。WP7的Push Client负责于服务器交互,接受到消息时再传送给相应的应用程序,而不需要应用程序各自维护一个进程。如果程序被钉在首页,服务器推送瓦片通知(Tile Notification),改变瓦片的背景图片、数字和标题属性。而弹出框式的原生推送(Raw Notification)只能应用在程序开启时,容许实时更新界面。

除了iPhone的长连接心跳查询,PushMail的IMAP可以支持IDLE特性,邮件客户端登录连接服务器后不会主动检查更新,而是停留在空闲状态,当服务器接收到新邮件再通知邮件客户端,此时客户端会再查询收邮件。或者依靠短信触发,以看不见的短信方式触发程序发起更新,但是短信方式的实现成本较高。(非技术人员,相关技术描述可能有误)

推送形式

iPhone的消息弹出框如果点击“view”会影响当前操作,但是如果点击“close”就再也查看不到消息。由于弹出框形式的限制,没法像Android状态栏那样同时显示多条消息。分散在各个屏幕的badge难以管理,多数badge并没有实际意义,比如花了很长时间更新可能发现某个应用程序只是改了个程序名称。

no2

iPhone的消息缺乏统一的管理,虽然比Android容易推送消息,但在终端没有将消息聚合起来统一管理,所以有设计师对其加以改进,设计了Notifications App。解锁界面显示消息,滑动某条消息可以立即查看具体内容。对现有iPhone的界面操作的基础上加以利用了解锁界面。

no2

双击Home键可以从底部调出消息,而越狱APP Notified Pro和Android一样利用状态栏,两者目的都是为了全局操作。考虑到很多游戏会覆盖状态栏,Notifications的方式较好,同时对用户现有操作系统影响较小。进入该程序中可以对所有消息统一编辑或者清除。

之所以需要统一管理的另外一个原因在于程序越来越多,消息也越多,个别应用程序为了吸引用户注意力,会频繁推送消息,导致消息泛滥和影响用户对重要消息的关注程度。

终端推送设计

除了要了解OS对消息的处理机制和展现形式,消息自身的众多属性可以在设计中加以利用,比如消息的元数据、状态、优先级和同步方式等等。

时效性强的短信、微博私信和邮件处理的优先级更高,可以优先显示在解锁界面。好友申请、系统消息和好友评论等优先级稍低,只以数字提醒并且不带声音,甚至只能在程序开启时提醒。未来情景式消息推送会在手机端发挥作用,优先级会依照信息对用户的有效性有所提升,比如到了某了商店附近触发折扣信息的推送。

服务器在推送消息时,如果可以附带更多样的处理方式、比如查看完整的140字微博、回复、忽略、已读和拒绝,不进入其他程序(如Facebook和短消息)就能操作会提高处理的效率,正如MIUI在主页收到短信时可以立即回复。

程序应该智能识别处理状态,比如已读带处理的消息标记为badge不再重复声音提醒,好友申请可以分为同意、拒绝和忽略,对于在各种手机端被用户忽略的消息可以设定为垃圾消息。

多台设备的消息可以同步处理,如iPhone端的消息未读,切换到PC端时,查阅了更新的内容之后,iPhone端的消息可以取消推送。

未来的消息推送很有可能会向WP7那样往集成化的方向发展,其重要性将越来越高。

参考资料:

MIUI刷机体验

鉴于Android界面丑陋、常有程序自启动和莫名的崩溃等问题,索性刷成MIUI。体验一月有余,感觉良好,官方论坛上用户各种角度对MIUI大加赞赏。毫无疑问,设计已经成了MIUI的核心竞争力之一,个人仅聊聊几个让人印象深刻的设计。

miui12 miui13

之前聊过各种OS的启动画面,MIUI的启动界面做的更为细致,不仅包括了流行的解锁进入常用功能,还可以快速查看短信、未接来电和控制音乐播放。解锁目的是为了防止误操作,也成了触摸屏执行任何操作前的必要步骤,对于查看短信和未接电话等这种短交互显得累赘。将用户解锁之后的常规操作提至解锁界面完成,不会引起误操作的情况下减少了操作步骤,提升了操作效率。

miuico

cooolfire在MIUI主题设计比赛中将解锁界面的形式和功能巧妙结合,视觉上富有美感的同时传达了功能寓意,引导用户操作,和主题也非常统一,称得上是高明的设计手法。取材上选用比较大众的设计风格,有特点但不小众,比起水墨和哪吒等主题更容易获得用户喜爱。只可惜由于ROM的限制,未能在真机上呈现出完整效果。

miui11 miui9

MIUI提升了顶部通知栏的利用率,整合多种常用操作,在全局都可以操作通知和开关。新版本中去掉了通知栏的任务管理,保证了操作入口的一致性,对桌面的编辑模式也有必要按照此法删减,编辑模式中修改壁纸与Menu中的选项重复,显得多余。

ROM本身也加强了任务管理,原先使用Android2.1时,系统启动极慢,开机之后有近30个程序同时运行,安装第三方程序管理器也没有彻底解决这个问题。手机上个别程序开始耍流氓,自动开启或者无法完全卸载,要是遇到街旁这样三更半夜重复推送垃圾消息的应用真让人苦不堪言,非要一一拒绝或者同意好友申请才可关闭消息,希望MIUI能适当管理下消息系统。

miui100 miui110

Android自身对应用程序还区分为桌面快捷方式和功能列表,使用到后期,桌面上可能包括50%的功能和功能插件,这哪里还算是快捷方式?MIUI统一为ios的管理方式,只有桌面功能列表,管理和查找都更为方便。Android的桌面虽然混合了各种插件,但是使用率很低,对操作效率的提升很低,点击插件还要进入程序才能操作,反而让程序常驻耗费电量。

重新了设置项和桌面之后,系统整体逻辑更为清晰,使用过程中只遇到使用习惯上的障碍,基本没有发现信息架构和交互上的大问题。除了桌面管理和程序管理之外,MIUI对联系人、电话和短信等基础应用做了不少优化,比如屏蔽骚扰电话、增加电话录音和删除重复联系人。这些也只有底层ROM可以做好并能获得用户的信任,特别是涉及到安全和隐私问题。(详情参见官方论坛各种评测文章)

miui19 miui20

优化的同时还增加了不少功能,希望不会发展成为臃肿的ROM,毕竟还是有个别功能看起来比较小众化,比如桌面的翻转效果,总是有各种各样的设置项。对于音乐、拍照和天气这样功能,如果不涉及最底层接口,第三方应用也可以做,而且可以做的更好,能费力气刷机的用户肯定也会安装各种应用,避免和其他应用发生竞争关系。除非MIUI已经准备和厂商合作,并期望从这些应用分成中直接获取利益。

miui15 miui17

MIUI对手机管理越来越像PC端,有硬件检测、一键装机、系统备份和DSP管理器,这些功能在手机端非常少见。似乎MIUI不会甘像点心做类似于MTK平台的方案提供商,会和厂商深度合作。一线品牌厂商有能力自行研发和设计ROM,即使使用的话,也会要求独家获得使用权,二三线品牌会选择借助这种ROM提升用户体验和品牌形象。早期番茄花园可以给一些电商带注册用户挣钱或者流量分成,ROM如果植入第三方应用的话也会有这样盈利模式。