关于作者

Hum 在应用方面是个遇到好的 App 就会兴奋的人，尤其偏爱折腾度高的效率类 App。他会琢磨每一个功能并且尽可能地设想每一种使用情景。最后，他会尽力用多数人都能懂的语言—尽量少使用术语—介绍这些 App，让更多的人可以了解到使用到这些 App，提高他们的效率和个人生活质量。

2007 年苹果在介绍 Mail for iPhone 的时候追求在 iOS 系统上带来「桌面应用级别」的邮箱客户端1，但之后人们意识到，在移动平台谈桌面级并不合适。所以从 2012 年的 Sparrow 开始，邮箱类 App 才真正找准了自己了位置，并出现了一系列轰动一时的 App：

  • Mailbox 带来了免费、即时推送、结合邮箱和代办事项，以及易用的手势；
  • Cloudmagic 带来 Cards 的概念，将邮箱和流行的网络工具结合起来，让你在邮箱里就能够完成不同的任务指派和安排；
  • Dispatch 则和同出一门的 Due 一样，对 URL-Schemes 和第三方 App 有着广泛的支持；
  • Google 也在去年推出了 Inbox，将邮箱和各种 Google 的服务有机结合，带来了 Pin，在收件箱中就降邮件智能分类等更进一步的效率观念；
  • 其他的还有 Outlook、Mail Pilot、Boxer 等。

这一系列的客户端的共同特征是：都在发现了前人问题上提出了自己风格的解决方案，但却没有一个可以称得上是「终极方案」。这种情况的原因也不是说「人的追求无止境，所谓完美不存在」云云，而更多的是开发者对「电子邮箱」这一服务的理解不同。比如说 Inbox 支持多账户但是不支持多账户共用一个收件箱，这不能说是 Google 弄不出来这功能，而是按它的理解不应该这样。

如今，在这些巨星的名单之下出现了一个新的挑战者——Spark，在使用一周之后，以我个人的感觉来看，和名单上的其它 App 一样，它超越了它的前辈，整体上做得更好了一些，但也有一些明显的问题。

长处

说是测评，这篇文章更多地是「评」价 Spark 的长短处。所以在长处方面，我并不打算写所有 Spark 的功能，而打算只写 Spark 比其它同类 App 「更长」的长处。

智能收件箱

Spark 的智能收件箱是目前有此功能以来设计得最为让我满意的，它足以成为你转换客户端的原因。

我们并不常是有一封新邮件就看一眼邮箱，有时候一觉醒来看到个十来封未读邮件并不稀罕。这些邮件里有的是广告，有的是你订阅的消息，有的是你使用的比如 Apple、Twitter、Evernote 这样的服务发生变化时给你的提示信息，也有的是你的领导 / 老师 / 学生 / 朋友给你发的信件。把这些内容按时间顺序排列很明显是不效率的，但神奇的是直到 Google 的 Inbox 开始才在移动客户端开始有了一个真正的解决方案。

Spark 继承了这个方案，但是又和 Inbox 理解不同。在 Inbox 里：

  1. Google 把邮件判断为购物、旅行、推广等几大类别。
  2. 将以上分类的邮件放入一个分组中。
  3. 对已读邮件和未读邮件不做区分处理。

但在 Spark，当你完成初始设置，Spark 将会对你的过往信件进行分析，并将以此为根据将你的新邮件列入 Personal、Notifications 和 Newsletters 三大分类中2。为了保证你可以看到每类邮件的概况，Spark 在主界面对每个分类至多显示 3 封邮件，如果某类邮件超过 3 封，则在界面上会有 View All 的提示。

Personal 即系统判断为真人给你发送的邮件，它的优先度最高，排列在最上方显示。当你使用多邮箱账户时，它分为多账户显示；当你按系统设定为 Smart Notification 时，只有 Personal 类的邮件会给你推送。

Notifications 是各类网站给你发的关于账户修改之类的重要通知，比如 Apple 提示你最近修改了密码等等。这个分类在智能邮箱中的位置排在 Personal 之下，Newsletters 之上。

Newsletters 是你订阅（或不自觉「被订阅」）的各类网站每一段时间发给你的内容，一般是博客或媒体的一段周期内的信息汇总，比如「xx 每周精选」这样的内容。它被排在三中分类的最下方。

未读的邮件在 Spark 里被分为上述三类，而当你阅读过一封邮件并对其不做归档或删除等移动的处理，它们则会留在收件箱中。收件箱中的已读邮件则分为两类，一种是被 Pin 的邮件（实质上就是旗标），一种是读过以后未作任何处理的已读邮件，都会在读过后落入 Inbox 一栏。优先度自然是 Pin 为先，但是已读邮件整体优先度要比未读邮件低，所以 Pin 在界面排列中低于 Newsletters。

所以按照顺序，Smart Inbox 的分类从上到下依次是：

  • Personal
  • Notifications
  • Newsletters
  • Pin
  • Inbox

其中 Inbox 因为位置最低，所以不会和其它类别一样将内容缩为三条以内，而是全部平铺出来。

这种方法对于我来说非常实用，Google 的 Inbox 对我来说有三个不便：

  1. 收件箱中已读未读不分别处理。
  2. 不支持多邮箱的统一收件箱。
  3. 分类多却折叠导致内容过于缩略，只显示该分类第一封邮件的发件人 ID。

Spark 的智能收件箱方案则解决了这三个问题，所以可以说 Spark 的智能收件箱是目前有此功能以来设计得最为让我满意的，它也足以成为你转换客户端的原因。

智能通知

没有干扰，也不错过重要邮件。

任何一个使用智能移动设备的人都应该养成慎重对待通知的习惯，相信很多人也注意到了「通知过胀」这一情况，已经在尽量地削减自己的通知。但唯有邮箱，我们却不敢怠慢，需要推送和提示。所以相信对很多人来说，自己的设备上传来通知最多的就是邮箱客户端 App。

这里的问题不是不该推送，而是有的邮件不该推送。Spark 提供了多种推送的方式：

  • 全部推送
  • 智能推送
  • 不推送

智能推送的意思是除了 Personal 以外其他两类不推送。这我特别中意，因为首先 Newsletter 类的邮件，并不紧急且早晚有时间看，所以它不需要推送；Notifications 类的邮件的处理上需不需要推送或许有争议，因为它涉及到你关联了什么服务，或者是修改、生成了什么密码。但对于我来说，重要服务全部是复杂密码且上了二步验证，因此改密码授权服务一定都是我自己干的，而我也实在不想每次我做完这些事之后相关服务都再告诉我一遍我做了什么，所以对我来说最不需要被提示的就是 Notifications 这一类。

使用智能推送以后世界清静许多，早上醒来按下电源键再也看不到没边儿的自己不感兴趣的新邮件提示。

没有干扰也不错过重要邮件，是我对 Spark 的智能通知的感受。如果这方面可以在自定义上再加强一些我会更满足，比如黑名单 / 白名单 / 关键字屏蔽之类的。

Cards 系统和 Widgets 部件

Spark 的核心功能基于 Cards，表现于侧边栏、顶栏以及 Widgets。

Spark 内部有一个 Cards 系统，这个系统是个可延伸、自定义的智能邮件分类系统。可以说是 Spark 核心功能的基础。

在设置选项中的 Personalization 这一项你能看到 Add new 这样的选项：

进去之后就能看到 Spark 的 Cards 系统，它分为五大类：

  • Message Cards（消息，正常邮件相关）
  • Service Cards（服务，如 Apple、Amazon 等）
  • Content based cards（特定邮件内容，比如邀请或包裹追踪）
  • Non-email cards（已读回执、统计）
  • Application cards（应用，天气、日历、联系人）

其中大部分看起来非常高端的功能都是 Coming soon 的开发状态，目前支持了的功能，除了默认开启的，有这五项：

  • Folder（Message Cards ，特定邮箱的特定文件夹）
  • Smart Folder（Message Cards，根据条件设定的智能文件夹，下文有介绍）
  • Recently Seen（Message Cards，最近已读邮件）
  • Read Receipts（Non-email cards，万恶的已读回执，下文有批判）
  • Calendar（Application cards，可在邮箱中编辑日历事件）

所有的 Cards 都在两个位置显示：Slidbar（边栏）、Widgets（部件）。

边栏中的 Cards 分为两部分：Top Section 和 Bottom Section。Top Section 意指位置在边栏的顶端，它的下方是邮箱的常见分类：Pins、Drafts、Sent、Trash，再下方就是 Bottom Section 的 Cards 所在的位置。简单来说，你可以把边栏的 Cards 按照优先级放到边栏的顶部和比较靠下的位置。顶部只能放 5 个 Cards，而 Bottom Section 这个位置可以放足够多个。

部件的位置可以由使用者选择是在顶栏或是右下角（如果你手机是大屏，可能放到角落更容易操作）。不管你把部件的位置设置到哪，部件只能选 4 个 Card 显示。

把不同种类不同功能的 Cards 根据你自己的使用情景放到不同的位置是你提高使用邮箱效率的关键。常用的 Cards 放在部件会更好。

1Password 支持

iOS 8 之后最酷也是最实用的软需求一定数得上 1Passowrd，一切需要登录账户的 App，支持与不支持 1Password 体验截然不同。从某种程度上，支持 1Password 本身就是一种优秀的象征。

一个 App 判断优劣的方式有两方面：一从硬需求，二从软需求。硬需求即刚需，是看这个 App 做没做到它该做的事情，软需求就是看它实现地是否舒服。拿微博客户端来说，能不能转发/评论/读微博这些是硬需求，音效如何、支不支持稍后读则是软需求。硬需求因为是必须要满足的所以并不能看出来太多的差别，大部分 App 比拼就是看谁在软需求处做得到位。比如说天气类 App，大多都是用的大公司的 API，UI 画的漂不漂亮则是能不能在同类中脱颖而出的关键。现在由于 App 的进展，越来越多的软需求过渡到硬需求，新的软需求也在出现。iOS 8 之后最酷也是最实用的软需求一定数得上 1Passowrd，一切需要登录账户的 App，支持与不支持 1Password 体验截然不同。

邮箱这么重要的服务，即便不使用二步验证也应该是独立密码。于是当你邮箱有两三个甚至更多的时候，转服务是件很难受的事。Spark 为了让你顺利地从其他客户端跳槽过来，机智地支持 1Password：

Apple Watch App

在所有支持 Apple Watch 的邮箱客户端 App 里，Spark 目前是最好的。

支持 Apple Watch 是 iOS 开发圈的新时尚，有的 App 不管有没有必要、设计的 UI 在 Apple Watch 上能不能用，都要给自己的 App 开发个 Apple Watch 版本。Spark 的不属于上述 App 之列。

Spark 很好地将其智能收件箱的界面放在了更小的界面上，这一点打败了另一款同样支持 Apple Watch 的 CloudMagic 。

对 HTML 比较复杂的邮件会经过特殊地处理使其信息能够尽量完整地显示在表盘上，而不是像 Apple Watch 上自带的邮箱 App 一样只显示纯文本邮件其他一律交给 iPhone。

最后，在 Apple Watch 上你也可以对邮件进行归档 / 推迟 / 删除这些基础操作。Pin 当然也可以做到，只是和 Unread 一起被放在 Force Touch 后的菜单里。

智能文件夹与自然语言搜索

Spark 支持用自然语言进行搜索，也支持使用自然语言筛选内容建立智能文件夹。但是，不支持中文。

在 Evernote 里当我们要搜索一项笔记的时候，可以通过按照一定格式地描述该笔记来进行搜索。比如说你想搜一条笔记是「去年东京旅游拍的照片」，那么你可以搜：

Note contain images created last year in Tokyo

你就会得到：

这就是按照 Evernote 的格式描述笔记时会得到的特定效果，有兴趣的话你可以看 Evernote 的官方文档。

在 Spark 里，你只要像在 Evernote 中一样知道固定的描述格式，就可以完成智能文件夹的创建，Spark 支持 Gmail 官方支持的语法，而且当你想搜索或输入某个语法，比如 with images 的时候，它会在你输入 w 的时候就弹出剩下的内容，并联想其它相关的语法。

在多账户的时候将公司邮件和私人邮件灵活地区分出来是很重要的。利用智能文件夹，Spark 可以让你做到这点。比如想制定一个来自公司的邮件的智能文件夹，只需要在 Spark 的设置界面里按照以下路径打开创建智能文件夹的页面：

然后填入：

From: 公司邮箱地址

然后再把它设定一个名字即可。

如果总是只需要上个月的来自公司的特定形式的邮件，你可以填入：

From: 公司邮箱地址 with Subject: 邮件名称或关键字 Last month

在创建智能文件夹时 Spark 在添加联系人的时候支持中文，这是因为它会直接获取你的通讯录信息。所以对于 Subject 这一项中文就不管用了，会导致数据不全。

在 Spark 搜索邮件时当然也支持自然语言，而且 Spark 还会保存你的近期搜索记录，也支持让你手动保存搜索记录。当你每次进入搜索栏，你之前的搜索过的关键字或语法就会跳出来。

另外，在发送邮件的时候你大概会发现 Spark 没有抄送和密送的选项，除了在阅读和整理邮件时可以用这些描述，这些也是要在发送地址栏里使用描述的，抄送是 Cc:，密送是 Bcc:。

其它长处

  • 支持主流云服务、稍后读服务、笔记服务。
  • 支持 Share Sheet。
  • Spark 可以在 2 秒内撤回你发错的邮件。
  • 支持对删除等操作的撤销。
  • 写到一半的邮件可以最小化到屏幕底端，可以继续写的时候唤出。
  • 可以在直接在 App 内编辑日历事件。

不足

一个力图打造连贯体验的 App 的不连贯处。

在文首我在写 Google 的 Inbox 时说了我认为 Inbox 不使用多账户联合收件箱是有意而为之，是开发者的理解问题而不是失误或能力不足。这种主观理解上的问题都是争不出个结果的，所以下文中将谈到的 Spark 的不足，大多是与其整体的体验所矛盾的地方。即，在使用中我认为 Spark 在力图打造连贯的体验，竭尽全力减少跳出和违背常规的操作方式，然而在一些「不可能犯错」的地方，它的体验又惊人地不连贯。

没有内置浏览器

如果一个 App 经常有网页链接这种内容，而且这个网页链接是要人来点击的，那么它应该有一个内置的浏览器。

在 iOS 上的用户体验已经探讨了几年，其中一个通识是减少跳出，或者说是非不可避免的情况下不要跳出本应用3。从 CloudMagic 这个 App 体现出来的 Card 概念就是要减少用户的跳出跳入，而 IFTTT 这样的服务是更上一层楼，一切操作在云端完成。

所以在这个时代，如果一个 App 经常有网页链接这种内容，而且这个网页链接是要人来点击的，那么它就应该有一个内置的浏览器，比如微博客户端或邮箱客户端。然而 Spark 竟没有内置浏览器。而且我想这不是本就设计如此而是失误，因为如果你注意 Spark 的交互你会发现，它甚至不想让你从邮件页面返回到邮件列表，你只要处理完一封邮件它就自动给你呈现下一篇了，而且你也可以通过手势来翻看下一封或上一封邮件。如果 Spark 这么在乎体验的连贯性，它应该不会希望用户每开一个链接的时候都跳到了 Safari，想要看下一封邮件的时候再按两下 Home 键再回来。

CloudMagic 就自带内置浏览器。就是因为这一点它从我手机上代替了 Mailbox。

手势体验不连贯

这是个每次我都会碰到，每次碰到我都会皱眉头的问题。

iOS 8 不仅将视觉设计上进行了平面化，很多操作也因为时机成熟，且为了适配大屏幕而将按钮操作转化为了按钮与手势并用的形式，其中最常用的我想是后退的手势。

在 Spark 里，单封邮件的界面是可以用手势返回的，但是到了邮件列表的界面却不能用手势拉开藏在屏幕左边的抽屉菜单，必须按按钮了，在这个界面使用手势的话会对单封邮件触发手势。这个逻辑我很不理解，甚至不敢相信。但在我甚至在任意两栏之间的蓝色区域尝试手势未果后死心了。

Spark 这里应该是有意为之的，原因大概是前文所推测的，返回手势和操作单封邮件的手势可能会有冲突。但首先，这是设计上的缺憾，为什么要把每一栏的宽度都顶到头而不在一定程度留白？其次，即便要坚持这样的设计，应该也可以设定一个阈值4，当划动起始位置在某个范围内时，使用返回的操作即可。

即时通讯化

回一个拇指告诉对方你 Like 他的 Mail 是邮箱该有的用法吗？

快速回复适不适合 Mail 这种相对严肃的交流工具我个人是怀疑的。回一个拇指告诉对方你 Like 他的 Mail 是邮箱该有的用法吗？我想我肯定不会喜欢群发了一封邮件然后收到一堆通知结果一看是一堆赞的感觉……

我想不出它的定位是什么，除了……广告。

当你使用了快速回复以后，对方看到的是如下界面：

像个微博客户端的尾巴一样，Readdle 在邮件末尾打上自己的商标。

大概是 Readdle 的人知道即便和其它客户端一样，先偷偷摸摸地对邮箱签名动手脚，现在的用户也足够聪明去把这些签名给删了换成自己的。所以 Readdle 在签名的地方做的很地道——自动地获取你曾用过的签名，而且会问你选择使用哪个——不去悄悄地帮你设定一个 Spark 的签名然后还悄悄地帮你打开。但是 Readdle 还是没忍住在快速回复这里给自己打广告。

即时通讯除了可以回复笑脸和赞，还能做的就是知道对方「已读」自己发出去的消息。Spark 也能做到这一点，通过它的 Read Receipts。

Read Receipts 是前面的长处中提到的 Cards 系统中 Non-email cards 中的一项。

把它放到边栏或者顶栏或者 Widgets 里，你就可以在这一项里看到你发出的邮件是否在对方手机上被打开了。我对这功能的抵触第一时间就产生了，而且是双向的，即不论是我看别人还是别人看我，我都会觉得不舒服。在 iMessages 上我也把「已读回执」这个功能给关闭了，我同样赞许把这个功能给关闭了的人。但首先，Spark 上这个没办法关。

开启已读回执给自己平添了很多责任，作为个人，在这个时代，你回或不回别人的信息完全是自由，不论你和对方关系如何。但是好听话谁都会说，人们并不完全这么想，人们的思想太容易被引导。「为什么你读了不回？」这个想法会在明确知道对方已读的人的脑子里徘徊不去，但如果最初就没有一个手段知道对方是否已读，这就不会对他造成困扰。

工作环境上，有已读回执这样的功能或许对效率有帮助，但我并不认为会对人际关系上有好的作用。

其它不足

  • （墙内问题）翻墙才能够推送。
  • 不能多选邮件。
  • Bottom 的部件必须按两下才可以进入相应项，完全可以设计成 Launch Center Pro 那样的以「手指按下为触发，以手指离开为选中」的操作吧。

结语

使用 Spark 的时候最先接触到的是 1Password，这给我奠定了很好的印象。接着遇到了智能通知这个功能的设定，我就明白再也不会一醒来解锁手机的时候满屏都是邮件了。当我把账户都登录以后，看到 Spark 的智能收件箱把我的邮件精准放到各个分类的时候，我已经决定就用这客户端并给它写篇文章。发现了智能文件夹以后让我意识到它还有很多折腾的余地。

它和文首提到的那些邮件客户端一样都在发现了前人问题上提出了自己风格的解决方案，Spark 的解决方案非常全面，但也称不上是「终极方案」。它有很多部分都可以说是未完成，也有一些地方操作逻辑有点奇怪。但对于我来说，它没有「硬伤」。我用的所有邮箱服务它都支持，有着统一收件箱，及时且有筛选的推送。而其它诸如手势等功能 Spark 的表现也都符合或高于「业界标准」。

所以我觉得它目前的瑕疵是可以忍受的，改进也是可以等待的。在下一款「发现前人问题并提出了和我胃口的解决方案」的邮箱客户端到来之前，Spark 会是我手机上唯一的第三方邮箱客户端。

  1. 资料来自 Spark Review: Smart Email ↩

  2. 遗憾但不意外的是，Spark 并不支持中文分析，所以所有中文邮件都显示在 Personal 分类中。 ↩

  3. 在这里大概会有人说 URL-Schemes 的跳出跳入，但是请注意，URL-Schemes 所自动执行的跳出跳入都是不可避免的。URL-Schemes 是代替人完成了操作。 ↩

  4. 阈值的意思其实就是一个在设计软件时预设好的界限，开发者在设计软件时设计当某个数值大于它了触发 A 结果，小于它了触发 B 结果。比如 Tweetbot ，你可以设定在什么屏幕亮度以下使之成为黑色主题，那个亮度值——虽然你看着不是个具体的数字，但它实际上就是阈值。 ↩