所有由张土福发布的文章

iOS 开发初体验 – 上架

想不到上架过程是我遇坑最多的时候,想不到提交一个 App 竟然那么麻烦,而且有还那么多 bug。

注册开发者账号

原来个人开发者的账号名称必须要用真名,也就是身份证上的名字。我注册开发者账号的时候,系统居然默认将我当时注册 Apple ID 时填的名字当作开发者账号名称,并且还不能修改。

我在官网提交反馈,给苹果客服通了电话,然后上传自己的身份证照片,等待苹果去验证,才修改成功。整个过程花了一个白天。

注册 App 名称

原来 App 名称也是唯一的,不能重复。我在新建 App 的时候才知道自己之前定的名称已经被用了。

问题是,苹果不提供 Check Available 的方式,你只能在确定名称后,新建 App 的时候把所有资料填了,提交,才能知道这个名称能不能用。

后来找到一个方法,就是通过 Google 的高级搜索来查找在 iTunes 网站中,是否存在 URL 里带有 XXX 的网页。例如搜索:

site:itunes.apple.com inurl:app facebook libra

隐私条款

所有 App 都需要隐私条款链接。知道这个要求的时候已经凌晨一点了,本来想着提交完就睡觉的我,抱头痛哭。

搜了一下,发现很多人把隐私条款放在简书上。虽然不是很正规,但确实是很方便的做法。

不过我想了一下,发现 GitHub Pages 可能是最合适的方案。成本低,也显得正式一些。

至于隐私条款的内容,网上有很多模版。我找到了一个生成器 App Privacy Policy Generator,输入一些基本信息就能自动生成。不过最后一行会有生成器自己写的推广文案,我残忍地把它删掉了。

提交审核

终于提交成功了。我捡起键盘上几根头发,就去睡觉了。

接下来是一连串的 Are you kidding me?

我觉得自己还算幸运,提交后一天,就收到状态更新说正在审核。然而,几个小时后我的 App 被拒绝了,原因是违反了 2.3.1 条款,说我隐藏了功能,发现我的 App 有赌博相关的功能。

???

然后我回复,诚恳地描述了这个 App 的功能是什么,跟赌博没有任何关系。

一小时后就能收到回复,说重新审核了一下,还是发现我有隐藏了功能,叫我回去改,期待下一次提交。

期待个毛线……我一点都不期待。我查过了,如果因为这个条款重新提交的话,作为惩罚,审核时间会被推延。

关键的问题是,他不告诉我哪里有问题,这不就是让我自我审查吗?敢情因为我是中国人就很懂自我审查?

于是我回复问具体是哪里的问题,还列举了一些可能的原因,并一一解释。一天过去,没有回复。然后我又发了一封。一天后,终于又显示“正在审核”了,十几个小时,终于通过……

这件事情简直摧毁了我对苹果开发体验的好感。回头想了一下,应该是因为我的 App 很小,才几百 Kb,而且我的账号又是新号。所以他们以为我是要发马甲包。所谓马甲包,应该是隐藏了一些功能,然后等到审核通过后,通过一个开关打开隐藏功能。据说很多赌博类的 App 就是这么操作的。

有意思的是,我在搜索怎么解决这个问题的时候,看到很多文章在教大家怎么去隐藏功能不被苹果发现。所以说有些事情上如果你吃了亏,可能只是因为你身边的人占了便宜。

上架了却访问不了

真想不到都上架了还有坑。

App 的状态如果显示为“可供销售”,就意味着已经上架了。然而我却跳转不到那个页面,搜索也没有搜到。按照网上的说法,我改了价格和地区,然后又改回来,过了一个小时,终于可以访问了。

Finally。

我的第一个 App 是跟深呼吸练习有关的,有需要的朋友可以安装来玩玩,真的没有隐藏了赌博功能。附上链接:https://apps.apple.com/cn/app/%E5%91%BC%E5%90%B8%E9%87%8C/id1468461396

呼吸里 Breathin

iOS 开发初体验 – 开始开发

以我对自己的了解,如果不快点做出东西,我很快就会懈怠然后一蹶不振,坐在午后的阳台上悲观地回望过去一个多月的枯燥。

我自学阶段用的教程,引导着我把一个 To-do List 的 App 做出来了。也算是把 iOS 开发里最基础最常用的一些概念过了一遍。如果我能做出一个 To-do List 了,是不是很多不复杂的 App 也能做了呢?

我觉得是,毕竟我有 Google。

我觉得自学一样东西是分两个阶段的。第一个阶段你在学基础概念或者基础操作,这个时候你只能不断地摄入,不断地巩固,踏踏实实地把主流程走一遍。这个阶段结束之后,你大概知道这是怎么一回事了。第二个阶段你可以主动去学习了,因为有了第一阶段的基础,你懂得如何去提问,如何看懂别人的回答。这个时候 Google 就能派上用场了。

简单来讲,“是否懂得通过提问来解决问题”是两个阶段的分水岭。

开发过程中的感悟

感谢 Google,感谢 Stackoverflow。顺便谴责一下 GFW,我觉得 GFW 妨碍了很多人学习编程的道路。

跑起来比最佳实践更重要。优化代码的事情留在后面吧。

不写注释就是给自己挖坑。定期整理一下自己的代码是很有必要的,既方便日后维护,也能巩固自己对逻辑链的记忆。

连 Google 都帮不到自己的时候就老老实实地看官方文档吧。

如果做不到最完美的效果,不妨先放弃。做人不能太执着。

国内的 iOS 开发者还是用 OC 的比较多,想找 Swift 版本的实现方式的时候,中文社区几乎没有资源。

很多程序员在简书写技术博客,以及简书的搜索排名很靠前。

对于某一部分人,写代码真的会掉头发……😢

iOS 开发初体验 – 自学

花了一个多月的时间看完 Raywenderlich 的《iOS Apprentice》前两章,然后花了半个月时间试着开发并上架了一个简单的 App,有一些心得体会分享给自学 iOS 的新人。

1. 教程的选择

MIT 有个 iOS 开发的课程,Stanford CS193P。我在找教程的时候,很多人推荐过,甚至最近在 App Store 的专题故事里,也看到一个年轻的开发者说自己是通过那门课程入门的。毕竟 MIT 出品,课程质量自然不会差。而且我相信学习编程需要老老实实地敲代码,而这个课程会有课后作业。

不过在试着听完一节课之后,我发现信息量超多,第一节课就会讲到 MVC 的概念。难怪看到有人说这门课程并不是特别适合零基础的自学者。所以,如果你还是零基础,需要谨慎选择。

另外,我买了一年的 Design+Code。DC 里面也有 Swift 的教程(所谓 Swift 教程其实就是 iOS 开发教程了)。DC 宣称所有教程都是为设计师而设计的,为设计师的思维量身定做。

但我发现,Swift 教程里很多不复杂的概念,讲师要用设计领域的一些概念用来比喻。这没什么,毕竟很多没接触过编程的设计师很可能真的不懂那些概念。可是教程里经常会出现我(一个会一点编程的设计师)看不懂的代码,而这时候讲师却一句话带过。这种本末倒置实在让我懵逼。

我后来选的是 Raywenderlich 那本小书。看书自学的方式有个好处是可以更自由地控制进度,还能方便回溯。也有明显的缺陷,它没那么直观,而且还枯燥。还好我早已经习惯了这种学习方式(感谢大学里考前一周疯狂看书复习的自己)。

iOS Apprentice》是一本很棒的书,作为一个教程,它做得真的很到位:

  1. 你半天之内就能做出一个能运行的 App
  2. 很清楚新手在操作的时候会遇到哪些问题、犯下哪些常见的错误,于是经常能看到及时的提示
  3. 很清楚新手不理解哪些概念。如果是不复杂的概念,直接就当作教学要点来讲述;如果是复杂的概念,会用浅显的话来解释,然后说现在不是很清楚也没关系,后来会涉及到很多次。例如 Optional 类型的概念,可能前前后后解释了不下 10 次
  4. 版本更新很及时

2. 自学建议

如果你也要用这本书开始学习,以下是我的建议:

  1. 要用最新版,新旧版本的内容很有可能差异很大,无论是 Xcode 版本还是 Swift 版本
  2. 如果你英文不是特别好,第一章可以先看王寒老师的翻译版,他重新演绎了一遍,也加了一些细节,但是内容还是一样的
  3. 从第二章开始,一些操作的跨度比较大,比如要实现一个功能,既需要在 Storyboard 操作,也需要在不同的文件中添加代码。我建议先看完整个操作流程,把关键点记下,再把书“合上”,自己按照笔记实现出来——不记得了的话再回头翻书就行
  4. 一定要坚持。第二章的难度明显比第一章高了,内容也多了两倍,但只要你能坚持下来,你就能跟我一样,有信心开始着手写自己的 App 了
  5. 如果不差钱,支持正版教程吧

另外,小书所在的官网 https://www.raywenderlich.com/ 可以记下来,以后很有可能会用到,因为后来我自己搜索额外教程的时候,发现这个网站的教程质量是最高的,之一。

我希望他们能赢

香港

这几天香港的反送中游行愈演愈烈,我不得不去了解了一下详细情况。看到一篇特别中肯、详尽的文章:《反送中答問集》。读完以后,我算是明白了为什么香港人会如此团结一致地上街抗议。那天还看到新闻说香港警察殴打游行民众,所以感到非常紧张,为对岸的人们感到紧张。

我还发了一条朋友圈,附了这么一张图:

图片来自 FB,据说是一位台湾艺术家的作品。

我的本意是希望更多人关注到这件事,虽然我的微信好友不多,但是如果能让我的好友去关注,也算是微薄之力。没想到,这张图被微信辨别出来了,因为发出去但我的好友都看不到。

我感到震惊,不由得想到 OCR 和图片识别技术,虽说提升了我们的工作效率,但是也为言论控制提供了支持,成了一种助纣为虐的现象。

我在写这篇文章的时候,香港的游行还在继续,因为香港政府仍然没有满足他们的诉求。他们要求撤回送中法,撤回将游行定性为“暴动”的说法,释放学生伤者,林郑月娥下台。昨晚看到新闻说游行人数高达 200 万,是前几天的两倍。

我希望他们能赢。

大陆

这个月四号,比去年这个时候,似乎更加紧张了。

今年最大的不同,是代理工具的集体报废。可谓一片哀嚎。陆续又看到新闻,说以后用翻墙软件可能算是违法行为。有一家外贸企业,因为私自搭建了代理的通道,被罚了。我不禁想,如果以后真的访问不了 Google 了,该怎么办?

我第一次萌生了移民的想法。

前几天又看到新闻说电影《八佰》因为“技术原因”无法上映。我不了解这部电影,但我很熟悉这个措辞。“技术原因”,不就是类似于“不可抗因素”的说法?我想要说谎,我知道你们知道我在说谎,但我一点都不在乎你们知道我在说谎,所以我说出了“技术原因”这个原因。

然后昨天看到反派影评的评论,我觉得他们特别有勇气,“一个谈话节目,如果想说的都不能说了,那这个节目留着有什么意义?”他们在微信公众号发布了这期音频,并且提供了下载的方式,估计是知道微信很有可能会删掉,所以希望尽可能地被传播。

反派影评《华语电影的技术原因》音频

如果香港人不抗议,也许不久他们就成了我们。

所以我希望他们能赢。

活在未来

前几天看到朋友发的一个演讲文字稿,来自 Kant,一个曾经在腾讯后来去了拼多多的产品经理。虽然是好几年前的演讲了,但演讲内容挺不错的,有几点让我受到启发或者深有同感。


别从竞争对手的功能出发。从竞争对手那里找需求,容易被他带到坑里。

以前在魅族做交互的时候,发现很多产品经理总是跟着竞品提需求。然后会发现,有些功能在竞品那边做得风生水起,而在我们这边无人问津。为什么呢?因为提需求的人不了解那个功能的本质。

竞争对手为什么做了 A 功能,而不做 B 功能?为什么做了 A 功能又下掉了,然后上了 C 功能?这些问题背后都有他们的考量。要注意,这是“他们”的考量,而这些考量不一定适用于“我们”。魅族作为一家手机厂商,跟常规的互联网厂商有质的不同,所以人家的功能移植过来,很容易会水土不服。

我认为,关注竞争对手的功能很有必要,但是必须要深入分析功能背后的逻辑,比如他们是为了解决什么问题?他们的长期目标是什么?这个功能受用户欢迎吗?……我们有机会嗅到一些对自己有益的信息,然后根据这些信息去衍生我们自己的功能设计。

当你真的想创业的时候,你不应刻意地去寻找一个需求,而是活在未来,发现缺失了什么。

我最近刚好在想,如果自己要做一个独立开发者,我应该做什么样的产品。
“活在未来”这一点着实启发了我。

我总是在思考现在的人需要什么,却没有想过三五年后的人需要什么,或者二十年后,有什么是人们离不开的。


骨架-肌肉-血液-皮毛

骨架是结构框架,肌肉是核心功能,血液是次要功能,皮毛是细节。

这个层级关系说得通,并且可以很好地解释了为什么微信的通讯录一直保留在第二个 Tab。但我还是觉得结构框架不应该先于核心功能,只有先思考了产品定位和产品的核心功能,才能把结构框架给确定下来。

《用户体验要素》这本书虽然我还没读过,但它的五要素理论我很赞同:战略层-范围层-结构层-框架层-表现层。

前轻后重

以前做交互设计的时候,铭记在心的一个原则是,把复杂留给自己、把简单留给用户。
所谓前轻后重,其实是同样的道理。

我之前注意到 iPhone 的抬腕显示很准确,然后尝试反推它的判断逻辑,发现跟初始位置、角度、速度都有关系。心想这个逻辑好复杂。后来偶然发现苹果的做法很有可能是利用机器学习的算法……用户在体验这个功能的时候是完全不用多想的,我抬起来要看手机了,它就亮了,但它的背后是工程师们的绞尽脑汁。


一个界面一个主题

如果说我做这几年交互设计有什么心得的话,我第一个想到的就是这个。

一个界面可能很复杂,但是必须要有它的主题和重点,并且只能有一个。所谓流畅的用户体验就是,在操作的过程中毋需多想,不带脑子也能操作顺利。毕竟确实很多用户是不带脑子玩手机的。

都说 Don’t Make Me Think,而要达到这样的目标,一个界面只能有一个 Primary Button。


Android Design 的问题

我曾经是“设计规范”的拥趸。我认为开发者需要遵循平台的规范,只有大家都这样做,用户才能得到处处一致的体验,否则,不同的应用使用不同的控件,用户很容易就懵逼了:这个 icon 竟然是分享的意思?

所以,在我刚出来工作的时候,我非常反感国内的应用在 Android 端也使用底部导航。“这些人都是果粉吧?”我会这样想。

我有个朋友则跟我很不一样,他坚定地认为底部导航是最佳实践,管什么规范不规范的。

我后来才明白过来,Android 的设计有很多问题,如 Kant 所说的,Android 的很多细节都是工程师思维的体现。而当你尝试遵循 Android 设计的时候,会发现你的业务数据和用户口碑会很差。估计 Google 的人也意识到了,所以这几年他们也在改进,虽然很慢很慢。

我们现在知道了,底部导航已经加入了 Material Design 的规范文档中。

设计规范不应该成为镣铐,它顶多只是个指南。我在魅族的后期工作就是负责公共规范的制定。我很担心任何一个规范会对设计师带来不必要的限制,所以新增一个规范的时候总是会考虑再三。如果有一个应用场景没被考虑到,那么将来某个设计师会很抓狂,如果用了公共控件会影响业务和用户,如果不用的话又过不了稿。

当然,针对这个问题的解决方案不应该只是谨慎地制定规范,而是面对规范时的态度。

Apple Music 刚出来的时候,与系统内的其他 app 都不一样。据说苹果内部,也是很欢迎挑战 Guideline 的。

微信群收款的改版

揣摩别人家的改版思路是一件很容易吃力不讨好的事情,但我发现揣摩得对不对并不重要,揣摩的过程对自己大有裨益。

我从前很少去思考产品设计相关的问题,以后要多一点了。

今天朋友在群里说起微信群收款和支付宝群收款的设计差异。

微信是放在首页的 + 里,路径是 “+” > “收付款” > “群收款” > “选择聊天”。 而支付宝是放在群聊的菜单里,路径是 “进入群聊” > “+” > “AA收款”。

我记得微信以前也是将群收款放在群聊的菜单里的,在某个版本之后,他们把这个入口移到了“收付款”里。

从交互设计的角度而言,这是先选操作还是先选对象的差异,似乎并无明显的高下之分。但具体看群收款这个功能的时候,会发现微信改版之后的操作方式更麻烦了。在旧版微信,你只需要点击 3 次就能开始输入金额,而在新版,你需要点击 5 次,而且还不太容易点击。所以微信应该是有别的考虑才愿意改版。

所以我猜测了一下,想到两个可能的原因:

第一,给“收付款”里面的功能带量,引导群收款发起者去关注二维码收款、面对面红包这些可能用得上的功能。

“收付款”这个页面很有意思,它的 UV/PV 应该都很高,但是来到这个页面的时候,用户大都是赶着付款,而付款成功之后就会跳到提示页了。以至于它无数次露脸,却很少人注意到它上面有什么(除了大大的二维码)。

而群收款发起者,往往是一个群体里面比较特殊的人,可能很有钱,可能很受欢迎,而他们很有可能会需要“收付款”里面的其他功能。

第二,增加“查看我的收款记录”功能,所以需要一个独立的页面来承载。可能是微信团队发现群收款的收齐率很低?总之我看了我的收款记录才发现原来有那么多没收齐的……

还有一点,微信敢于为了某些原因而把一个比较常用的功能改得难用了,一定是觉得即使难用我们还是得用。想想是不是还有点悲哀。

警惕咪蒙,也要警惕骂她的人

每每看到人们在谈论咪蒙,我总会想起那本《独唱团》的作者列表里咪蒙的笑容。那个笑容很有感染力,不然我也不会在这么多年一直印象深刻。而现在的咪蒙,比之前更有感染力了,只不过不再是通过笑容,而是通过她的文字和她的团队。

感染力的一个体现是她在微信公众号上的粉丝数,另一个体现是时不时出现在我 Timeline 上的爆款文章。她大概是深谙感染之道,堪比通过分裂繁殖的病毒。但这个本事最近给她带来了个大麻烦。

最近的事情是这样的,咪蒙旗下一家公司写了一篇叫《一个出身寒门的状元之死》的文章,文章被热传,随即被质疑。N 个小时后大家都在算自己的含咪蒙率(关注了咪蒙的微信好友数/总微信好友数),然后感慨自己的交际圈如何如何。N 个小时后咪蒙宣布停更 2 个月。

为什么很多人讨厌咪蒙?有人说是她创造了太多的毒鸡汤。其实更加准确的说法是,她创造了太多的毒鸡汤并且太受欢迎了。她知道怎么写点击率高的标题,知道什么样的话题有更高的受众,知道要怎么说才能诱导读者转发。

可是真的是这样吗?我很怀疑这一点。因为这个原因太奇怪了——毒鸡汤有多害人?毒鸡汤真的比鸡汤更害人吗?这个原因真的能让人相信关注了咪蒙就是 Low?

我不喜欢咪蒙但我也不讨厌她。我甚至觉得她作为自媒体,某些方面是一个标杆。而《状元之死》一文,对社会的积极意义还很值得认可。利用人性的弱点去达到自己目的的人或公司其实有很多,比如抖音,比如拼多多,但是会有很多人认为用抖音就是 Low 吗?

这里的关键在于,为什么反咪蒙能成为一种“潮流”。因为反咪蒙是很容易理解的事情——她的槽点很多,但大众一起反咪蒙,就不是一件简单的事了。

这不过是又一场乌合之众的盲目跟风罢了。源头是一部分自认为品味高级的人(可能确实品味很高级),他们在社交网络上表露出自己对于咪蒙之流的不齿。这么一想就觉得讽刺,这一群人被牵着鼻子去嘲笑被牵着鼻子的咪蒙粉丝。

毒鸡汤确实需要慎用,但试图把你的鸡汤贬得一文不值的人不一定理解这碗鸡汤。所以不仅要警惕咪蒙,也要警惕那些骂她的人。

文艺文案

概要

2016 年初我为魅族读书撰写了一系列提示文案,文案风格是“文艺”,思路是用文学作品中的金句或者桥段来辅助提示。当时因为没有互联网产品这样做过,我在推动这一套文案的过程中受到过很多质疑,庆幸的是最终项目组同事都认同了这个方式。

设计思路

  1. 大前提是保证关键信息不能丢,用户能快速明白提示内容
  2. 文艺文案需要匹配上提示的场景,避免生搬硬套
  3. 控制文艺文案的字数,简洁是必要的
  4. 页面排版要美观

成果展示

网络相关的提示:

“人生总有许多的意外……”摘自几米的《向左走向右走》;“海明威曾写过一个谎言……”演绎自海明威作品《老人与海》。
 

空状态的提示:

“2300 年前亚里士多德……”演绎自典故;“想要了解一个人……”摘自加·泽文的《岛上书店》;“天下万物的来和去……”摘自三毛《谈心》。

内容下架的提示:

“我不知道该怎么和生活中无法失去的人说再见……”出自王家卫《蓝莓之夜》;“再好的东西都有失去的一天”出自莎士比亚。

上线后

文艺文案上线后几个月,我看到一则很有意思的新闻,讲到 Windows 10 最新的中文版安装程序出现了多句古文和诗词。例如出自李白《蜀道难》的“一夫当关,万夫莫开”:

我觉得微软所在尝试做的,跟我当初的想法是一致的。我们在产品设计中,如果能找到一个合适的切入点,多花一点点力气,让某个细节更加情感化,是非常值得的。

我很久之前在知乎上面偶尔看到一个回答,答主提到她喜欢 Flyme 的细节,我一看,最后一张图竟然就是我们魅族读书的无网络提示。我感到莫大的惊喜和欣慰。昨天去微博搜了一下,发现也有人提到:

这对于一位设计师,就是所谓的小确幸吧:)

火星文小翻译

概要

火星文小翻译是个微信小程序,也是我的一个练手作品。我花了一天时间,独立完成了设计和开发工作。

你可以扫描下方的小程序码来体验:

缘由

小程序很火,我恰好懂一些 Javascript,于是就想做点什么。而之所以要选择火星文翻译工具,是因为:

  1. 我是 90 后,对火星文有一种怀旧的情愫
  2. 现在网络审查这么严,说不定火星文以后会迎来第二春
  3. 最重要的原因:以我的编程水平,也就只能做这种小工具了……

开发路线

  1. 阅读微信小程序开发文档 · 1 小时
  2. 设计 · 1 小时
  3. 开发核心功能 · 3 小时
  4. UI 调试 · 4 小时
  5. 跨平台适配 · 30 分钟
  6. Logo 设计 · 10 分钟

设计细节

  1. 实时翻译,省去“翻译”按钮
  2. 复制按钮只有在有文本的时候才会出现
  3. 输入的文本和翻译结果上下对应,形成强烈的映射关系
  4. 输入文字过多时,文本字号会自动缩小

如果跟友商进行对比,你会发现火星文小翻译无比简洁:

总结

这当然只是一个小玩具一样的程序,但它对我有很重要的意义。

我在整个过程中感受到的是,学习新技能和长时间心流的乐趣。人总是很容易就呆在舒适区,不愿出去,我觉得我可能也会,而这个小程序是我真正迈出去的第一步。

对了,有一段时间,后台看到的日活增长还蛮高的,我一度以为我会火……
 

OK Camera

概要

OK Camera 是我们在 2017 年初做的一次相机重设计的作品。我们一共做了 7 个优化点/新功能,以下仅介绍其中一个由我主导设计的优化点。

前期调研

在前期,我们分析了 10 款同类竞品,对 14 位用户进行深度访谈,回收了 200 余份调查问卷。另外,借助大数据平台,我们得知很多关键的相机使用数据。其中对我接下来的设计影响较大的是这个数据:

从这个数据可以看出,用户在使用系统相机的时候,单次使用时长极短。而在访谈中,也有好几个用户提到,除了自拍,拍照基本都能在 30 秒内完成。

因此,“高效率”必然是系统相机需要追求的目标。但我发现,现如今的相机产品对效率的追求分别朝着两个不同的方向。

系统自带相机,比如 Flyme 相机、Pixel 相机和 iOS 相机,通常是点击快门拍照之后,照片生成,但仍然停留在取景界面,等待用户快速拍摄下一张:

而很多第三方的相机,比如微信、Instagram、黄油相机,则是拍完一张,随即给出拍摄成品给用户预览,以决定是使用照片还是重拍一张:

换句话说,前者认为保证用户可以迅速拍摄下一张更重要,而后者认为让用户迅速预览拍出来的照片更重要。你会发现,它们都不得不牺牲了另一个任务的效率。

系统相机有没有可能兼备两种任务的高效率?

方案探索

查看相册其实是一个临时态,它终将导向下一个任务:要么是编辑、分享,要么是回头重拍一张。对于临时态,在移动终端上有一个手势非常合适,那就是长按:

长按相册入口即呼出临时相册,左右滑动快速浏览,向上滑动则打开该照片,松手则退出临时相册。这个流程看上去一气呵成。

然而,在准备深入完善细节的时候,我发现……iOS 的自带相机已经做了一个几乎一样的方案……区别只在于它用到的手势是 3D Touch 的 Peek 和 Pop:

我感到沮丧,因为我这个方案已经失去创新的价值;也感到高兴,因为发现 Apple 也在尝试解决同一个问题。

继续探索!

在产品设计中,我们常说的“操作成本高”,其实包括两方面,一是触发操作不方便,二是撤销操作不方便。而在我们的相机界面,想要优化查看相册的效率,最好也能兼顾这两方面的操作成本。

除了长按,还有没有办法让进入相册和退出相册都非常便捷?我想到了滑动手势(在达到以下方案之前,其实经历了非常曲折的变更,篇幅所限,不再话下):

  1. 拍摄照片后,屏幕底部会露出照片的一小块,暗示可以点击或上滑查看
  2. 上滑呼出相册,左右滑动浏览,随时下滑收起相册

无论是进入相册,还是退出相册,都只需要一个全屏可以响应的滑动操作。并且,由于整个流程没有跳转新的页面,用户对相册的感知会是非常“轻量”的,因此操作成本也会因此降低。

还不够

在提出上述方案的时候,我意外地发现,相册出现的动画轨迹与手机拍摄后恢复正常姿态的轨迹是恰好相对的。这意味着——我们可以增加一个体感识别,当用户手持相机拍完照,把手机拿下来准备查看照片效果的时候,相册自动弹出。

要知道,当我们使用后置摄像头拍摄的时候,手机与地面的夹角通常接近 90º;而当我们在浏览相册的时候,手机与地面的夹角通常在 30º ~ 60º 范围内。

我为这个想法感到兴奋。我的小伙伴们也都觉得很有意思。我们决定为此做一次用户测试。

原型制作

其实从一开始的方案探索,我就已经开始做原型了。可交互的原型能帮助你深入了解设计方案的优劣,从而更早地发现问题。

我用的原型工具是 Framer,它最大的特点是功能强大,能精确还原设计方案。

整个原型一共包含 600+ 行代码,4 个开源组件和 3 段音频。

(你可以通过这个链接体验原型。但是通过浏览器打开的原型将无法展示取景框和“拍完拿下来”的体感识别功能,如果你想要体验完整功能,需要先在手机上安装 Framer 客户端。)

用户测试

我们前往北师大珠海校区进行用户测试。

测试步骤的是:

  1. 请用户自主使用原型拍摄几张照片(原型只是模拟拍摄效果,并非真实拍摄)
  2. 请用户自主查看刚才拍到的照片
  3. 设法让用户自主发现“拍完照拿下来”的功能

经过 5 轮用户测试,我们得出结论:

  1. 新的相册入口在可用性上完全 OK
  2. 用户在发现体感识别功能之后都很感兴趣(也让我们感到惊喜)
  3. 部分用户习惯横屏拍摄,所以我们需要针对横屏做相应的适配方案

总结

这次概念设计持续一个多月,我们完整地走了一遍通用设计流程。其实一开始我们觉得相机已经没有什么可以做的了,无非就是把现在流行的第三方相机整合到系统相机里(三星相机就是这样做的)。但在第二轮头脑风暴之后我们发现,原来可以探索的方向还有很多。我们最终的方案也是超出了一开始的预期。

备注 1:本次概念设计是合作项目,上述任何工作,如果没有特别注明,有可能不是我独立完成的。

备注 2:上述方案并未上线。