为什么iOS等了这么久才支持拖拽手势

做个“显而易见”的决定有多难。

6月初,苹果在2017年WWDC上正式发布了iOS 11,半个月来广受科技媒体的好评。我本人最期待的是,iOS 11让iPad具备了更多生产力工具的特性,包括更灵活的分屏、文件管理应用和跨应用拖拽手势。其中拖拽手势无疑是最亮眼的新功能。

什么是“跨应用的拖拽手势”?简单说,iOS 11允许用户利用多根手指选中文本、图片、链接等富媒体,然后直接拖拽到另一个应用里。这里的突破点并不是手势本身,而是跨应用传输内容的能力。它让人们误以为iOS打破了应用之间的孤岛状态,实现应用间的互联互通。

沙盒机制和低效的跨应用操作

iOS以安全的沙河机制闻名,它不允许应用之间直接传输数据,以此来保证系统的隐私、安全和稳定性。代价也很明显:跨应用的内容传输变得非常不方便,大大限制了其成为生产力工具的潜力。

我们就用添加邮件附件这个最常见的操作举例。在Mac或Windows里只需用鼠标把文件拖拽到邮件窗口就OK了,而放到iOS中就要麻烦许多。

以iOS原生邮件应用为例:

1. 如果需要添加的文件在Word里,需要先打开Word,把它保存到iCloud Drive中

2. 打开邮件客户端,在邮件编写页面点击文本编辑界面,弹出的气泡中有“添加附件“按钮

3. 点击“添加附件”按钮,会弹出iCloud Drive文件选择器

4. 在iCloud Drive中点击指定文件,完成一个附件的添加

5. 要想再添加另一个附件?重新再来一遍!

为什么会有这么麻烦、这么“反人类”的设计?就是因为iOS的沙盒机制不允许Word和邮件这两个应用之间直接传输数据,因而只能通过iCloud Drive作为中介,借由有限的文件选择功能来完成数据传递。

iOS的Share Sheet

iOS 8之后,系统的Share Sheet提供了应用间传输内容的协议,让分享单个附件变得相对简单(打开Share Sheet -> 点击邮件应用 -> 新建邮件并完成附件的添加)。但仍有不少限制,比如不能把文件传输到正在回复的邮件里,不能同时传输多个文件,也不能传输不同类型的文件。

iOS 11的跨应用拖拽手势

相比复制粘贴和Share Sheet,iOS 11的拖拽手势是最符合直觉的,而且非常适合多点触控屏幕。只需要按住一个文件,同时可以用另一根手指点选更多文件,然后打开邮件客户端,把文件拖拽到邮件编写窗口,松手就OK了。有了拖拽手势,跨应用的数据传输变得简单而高效,而这正是生产力工具不可或缺的特性。

为什么这么久?为什么是现在?

那么问题来了:为什么苹果花了这么多年才决定让iOS 11支持拖拽手势,彻底解决跨应用数据传输的低效问题?

当然不是因为交互设计师才想到拖拽手势,事实上拖拽手势早已应用在系统的方方面面。但它一直没有用来跨应用传输内容,主要是因为苹果没能解决两个核心问题:安全性和反馈速度。

安全性即是前文所说的沙盒限制,不能允许应用之间直接传输文件,这是iOS的“金科玉律”,不容妥协。为了保证数据安全,文件传输过程必须是由系统来控制,具体说就是“复制”或“粘贴”。

由此带来了反馈速度问题。设想用户传输的如果是影片这种大文件,在拖拽手势完成后,系统还需要大量时间来完成文件的复制和粘贴,迟迟不能让用户进行下一步操作,体验可谓糟糕透顶。

更何况,用户拖拽来拖拽去,一不留神就占用了大量储存容量,以后清理起来也非常麻烦。

终于2017年,苹果彻底解决了以上的问题,而最大的功臣就是iOS 10.3.3所带来的APFS,即“苹果文件系统”。

APFS和它的好处

APFS改变了iOS底层文件系统的架构,当复制文件时,系统底层并不是把它变成两个文件,而是制作出这个文件的替身,并且之后的修改也都是基于替身做增量修改。它有两个显而易见的优势:复制文件可以在一瞬间完成,并且复制之后只占用一个文件的实际内存。

在iOS 11中,当人们拖拽一个文件到另一个应用时,系统实际上是复制(有时是剪切)了这个文件,并且在另一个应用里粘贴。数据传输依然没有突破以往的沙盒机制,并不是真正的应用互通,安全性得到了保障。只不过无论多大的文件,这个过程都是在一瞬间就完成了,再加上视觉和交互层面的设计,给人一种“直接传输过去”的错觉。

有了APFS的加持,苹果终于放开手脚支持了跨应用拖拽手势,把它变成传输内容最便捷的交互方式。

看似是一个交互层面的改变,实际上涉及到系统底层的重写。

做个“显而易见”的决定有多难

今天讲这个故事,是因为它让我意识到做一个设计上的决定需要多么审慎而有耐心。交互设计师其实不需要花太久就能想到用拖拽手势来传输文件,然而苹果为了实现它却是不走捷径、不惜成本。

因为数据安全问题对苹果来说是不可逾越的底线,因为拖拽体验的好坏比实现拖拽这个手势更重要,所以苹果宁愿花这么久的时间,升级整个文件系统,才肯把这个新功能推到用户面前。

在彻底解决所有关键问题之前,设计师和产品经理是多么希望尽早支持拖拽手势,提高跨应用操作的效率(人们对iOS沙盒机制的批评由来已久)。但他们并没选择“凑合”的方式,比如牺牲一些安全性,或在拖拽完成后显示“加载中”。试想如果迫切需要,总有办法让它迅速落地。

反思我自己做产品的经历,就曾有过为了快速落地而做出妥协,用一个“凑合”的方案去满足时间上的预期。所以我深有体会,做一个“显而易见”的决定,把它做到尽善尽美,有时候是有多难。

然而,在iOS团队内部必定有一套明确的、经过反复讨论的原则优先级,规定安全性和体验流畅比跨应用数据传输更重要,是不可妥协的设计原则。这才让苹果放弃“迅速落地”的诱惑,花费几年时间、不惜成本地解决核心问题之后,才去着手开发拖拽手势。我想这种有耐心、不妥协、不怕麻烦的精神,这种对待产品的审慎态度,值得我们每一个人学习。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,198评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,663评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,985评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,673评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,994评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,399评论 1 211
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,717评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,407评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,112评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,371评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,891评论 1 256
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,255评论 2 250
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,881评论 3 233
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,010评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,764评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,412评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,299评论 2 260

推荐阅读更多精彩内容