不能读取itunes library

前沿拓展:


这群宅男费尽心思做了一款移动阅读版「快播」,最后还是败给了Kindle。真是心与身的淬炼,血与泪的教训。

作者 | Thomas Guigue

翻译 | 花花、林几木、李蔚娜

校对 | 柴俐

在我构建「Read」应用的过程中,我犯过很多错误,其中学到的一件事是——切忌推倒重来。如今,网页中的每一处都完美的体现了这些案例的精髓。我的第一个例子是「Read」——一款能免费阅读Epub 格式电子书的iOS 应用程序。

我的硕士论文题目是关于数字设备上的手势交互,之后从事了电子阅读方面的研究。我前两次负责的产品分别为Addr 和Libr。前者是一款iPad应用程序,用集合注解替代传统阅读方式;后者是一个业余项目,工作原理类似于P2P网络,它可以让读者在应用程序内分享电子书籍

不能读取itunes library

我的第一个作品Addr(中)至今仍未通过App Store 的审核

总之,我就是和电子阅读较上劲儿了

在2015年5月,我、Simon还有Augustin决定研制一款电子阅读的应用程序。它将专门适用于苹果手机由数据驱动早期并不加入社交功能的一款纯效率工具。我的兄弟Simon(坐我边上)和我一起完成了之前的两个应用程序,负责客户支持、公关、宣传材料。Augustin当时刚刚完成了Opus(一款推荐书籍和电影的程序)的开发,正在找新的项目。他用自己的专业技术背景完善了我们团队。

不能读取itunes library

简单团队介绍,我—Simon—Augustin

终于,我们三个好基友成立了一个小组,全心全意解决一个核心问题:如何在手机屏幕上愉快地阅读。

从屏幕入手

我们的目标是引领未来趋势——也就是迎合读者在移动端的阅读需求。小组之前设计的两款只适用于平板电脑(iPad)的App。但自从我们收到某些一星差评——「去你的腊鸡App,我只用手机阅读!」——类似这种,我们就立刻洗心革面、重新做人——将视线转向手机

因此我们买了iPhone 6和iPhone 6 plus在上面测试软件,大家猜怎么着?它们完全适应!大屏大体上给用户提供了良好的阅读体验。人们可以自然而然地在任何时间,任何地点,拿出手机。

关注阅读格式

这是我们探寻电子阅读习惯的切入点。

在图书馆、书店,甚至是巴黎的苹果门店外进行的一些调研后,我们发现电子书籍的主流格式还是PDF。但我们自知无法提升PDF格式电子书籍的用户体验,因为它已被广泛用于印刷行业。现在没有技术可以百分之百的将PDF格式文件转化成可以根据不同尺寸重排(reflowable)的文件。但自打我们打算开发这个产品以来,我们就对PDF坚决「Say No」

这段文字摘自我们发布Read的Medium文章:

「我们坚信Epub将取代PDF成为标准的文本格式,因为用户可以通过Epub自定义文字样式和页边距等。我们想通过Read改变人们在移动端阅读文本的方式.在Pocket,Medium,Flipboard这些成功案例诞生后,我们相信,电子书和网页文章最终会成为一体。」

不能读取itunes library

强迫缩放后的PDF,不能自适应,无法标记Highlight(左)。Epub(右),面向web的格式

所以哪些人会阅读Epub格式的电子书?哪些人会过度使用手机?

不能读取itunes library

谷歌表单里的用户旅程图

从这个问题出发,我们虚拟了一个人物,叫Jared。我们花费一些时间去研究他的品味。他喜欢什么,不喜欢什么?他日常生活是什么?我们发现Read将在以下五个方面发挥作用:

1、 读懂电子书籍;

2、通过电子图书馆表现他的个性;

3、建立读书计划;

4、阅读后产出内容;

5、推荐书籍。

我们将所有关于Jared的想法放在Trello 的白板上。自那以后我们经常用这个方法增加新的内容、思考Read的未来蓝图。

不能读取itunes library

Jared 以及他的问题

我们将Read视为对iBooks的一次变革。我相信通过设计师可以改变iPhone上的标准自带程序。Sunrise、Wunderlist、Mailbox 就成功地让早期用户转向一个更俏皮的设计产品。

全速前进

我们知道自己的工作方式会对产品产生巨大影响。因此从一开始,我们就决定在收集足够的用户反馈之前,明确3项规则:

1、发布产品越快越好;

2、构建微小但稳定的特色功能;

3、保持最精简的UI框架。

我先将Read设计为仅适用于iPhone的产品,然后再其做面向iPad的适配调整。我终于不用为iPad单独做线框图了。我们直接从Xcode编写iPad版本,代码可以规定相对显示大小和位置,以及图片文字的绝对大小。

我们在巴黎参加GoogleLauchpad(初创公司活动)遇到结队编程(Peer/Pair coding)的传道者。我和Augustin都会Objective-C,所以我们很快适应这种方式。我认为我们尝试编程并爱上它有3个原因:

1、这种方式避免了编码过程中的所有小问题,程序的运行速度会变快;

2、我们可以写易懂的代码;

3、团队中不会编码的成员也不会觉得这个工程太难,因为我们两个都可以调试代码的任何部分,并且在任何地点任何时间都可以使它运行。

不能读取itunes library

长按会触发动画并促使用户滑动屏幕

如何应对任务不明的情况?

当我们必须编码一些冗长的类(class),重写一些函数(function)时,Augustin会快速完成这边编程任务;而我则有时间构思一些设计原型图,然后将图片用jpg格式发给小组。如果不需要学新的Objective-C技术,我们就可以尽快实现这些设计。

当别人问起我在小组里负责什么,我很难回答。我负责组内的视觉框架,但是我们大多时候也和Augustin一起编程。在建立原型时,非常有效的办法是用Xcode里一些变量,迅速调整颜色、大小和交互动画效果。

我们的第一目标仍然是尽快发布一个产品,然后更新它,越快越好。通过在App内安插的嗅探器(最终都接入Segment),我们能获取尽可能多的数据帮助我们构建产品。(译者补充:嗅探器是一种基于被动侦听原理的网络分析方式。使用这种技术方式,可以监视网络的状态、数据流动情况以及网络上传输的信息。)

高效能工具

Read首先应该是一种高效能工具(productivity tool)。我们认为Read可以作为Hub在输入(源文件)和输出(Hihglight,引用)之间起到枢纽作用,读者可以存储数据供以后使用。

我们最初的问题是:

1.相对于竞争对手而言,最需要改善的是什么?

2.哪些是第一天就要执行的重要方案?

3.如何提升API的价值?(API:Application Programming Interface,应用程序编程接口——译者注)

4.如何整合它们?

5.我们希望用户在屏幕上是什么?

6.什么可能促使用户采取这一行动?

7.我们把嗅探器放在哪里?命名惯例是什么?

我们决定致力于以下方面:

1. 通过Dropbox导入书籍

2. 使用Evernote同步划出的重点

3. 自定义阅读体验

4. 在设备之间同步书籍

5. 每周向用户推送被他们标记highlight的邮件

6. 构建一个极简UI

作为一个立志成为阅读工具之翘楚的应用程序,于我们而言,专注解决一个问题非常重要。例如,我们已经有数百个添加注释、社交共享或支持PDF的请求,但我们并没有急着把这些任务列在我们的list 中。

用户很快就试用了Read,并且表示希望Read的功能在别的App上也能看到。也就是说,我们从第一天就戳中了用户的痛点。

不能读取itunes library

在我们真正开始「Read项目」(我在苹果上的第一个线框图)之前,它并不能很好地适配iPhone(左)。调整后(右)。

对于我们来说,一个高效能工具意味着:

1、集中于单个任务

2、适度的定制

3、API 优先

我们首先集中注意力实现将两个API(输入和输出)插入到我们自己的「EPUB引擎」中。这不是关于新按钮的设计,也不是关于从一个屏幕到另一个屏幕的平滑过渡。

Read遵循极简原则。白色是主导颜色。两个屏幕就足够:

1、主页图书馆;

2、阅读视图。

主页图书馆是一个ePub文件列表,灵感来自于Pocket(文章)和iTunes(歌曲)两个大家耳熟能详的应用。一开始,我们没有在书的单元格(cell)中添加许多信息。我们的阅读视图简直美极了,我们打造了一个完整的文本屏幕

不能读取itunes library

单元格(cell)的进化史:从左至右

设计一个移动Hub (上)

连接Dropbox

Read不提供任何内容,完全由用户自行下载电子书。因此我们不断尝试促进这第一步:让用户用书籍来填满这个App

电子书大多储存在Dropbox 和Drive 中。不要忘记,尽管电子书只是大小范围为200K到50M的文件,却可能含有几十张图片。所以我们面临两个问题:

1、文件大小;

2、API调用的数量。

首先,为了获得一本书的元数据,要解压缩Epub文件。但即便使用全新的iPhone 6S,一次性解压缩几百本书也会花费很长时间。其二,很多用户在他们自己的「云」里都有大量的数据。当Read 只通过抓取位于Dropbox 结构中的1T 数据来检索Epub文件时,应用程序会因为API 被大量调用而崩溃。

这就是Read 不能自动下载每个可用Epub文件的主要原因。就好比Read 只能用来管理股票,而无法控制现金流动。因此我们必须用一个简单的「添加」按钮让手动添加电子书变得容易。(我们没想到还需要一个「刷新」按钮……)

不能读取itunes library

两种书本目录的设计原型图

用户必须是积极主动的,它不像社交或新闻应用程序——这些应用程序使用户被动地接受滚动的新闻推送。在Read 中,当一个用户增加了三本或更多的书时,我们就认定他「被锁定」了。这些用户会每星期都会使用Read,并且每次用上20分钟。

当使用「MyDropbox」时,我们想让用户直接访问他们所有的书,并让这些书在一个简单的视图里显示。

然而我们失败了,有两点原因:

1.他们没有立即认识到这些是他们的书;

2.如果他们在Dropbox中有大量的数据,并且如果他们的电子书远离Read 的根目录,App就会崩溃掉,显示不出任何东西。

不能读取itunes library

用右上角的“+”按钮从库中添加书籍。

我们用更简单的方式改进了这个功能:Read 可以显示用户的Dropbox 结构。用户显然更熟悉自己建的结构及导航,他们就可以更轻易找到自己的要找的文件。一次点击即可下载书;第二次点击即可打开书。

不能读取itunes library

(左)所有Dropbox里的书;(右)设计后更简单的视图

现在我们已经证明我们的用户在他们自己的Dropbox 中存了很多书。他们当中数以百计的人直接要求我们提供像Drive 和Box 那样的服务。

下一步做什么?

克里斯多夫·陶泽特给了我一个提议,可以减少上传新书这种麻烦的重复动作。Read可以推送通知让用户直接导入Dropbox中的最新书籍。这都是关于用户行为的精准预测。。

他的见解令我明白了简约设计的力量,从而避免了一个恼人冗余的任务过程。

不能读取itunes library

精简的选择菜单

设计一个移动Hub (下)

连接Evernote

一般用户都会在文本上标出重点以便专注阅读。Simon 采访了数十名骨灰级读者。他们保留引号为了以后产出内容。(采访建立在Medium,Quora和Evernote的论坛。)使用移动端的专业读者会把每一个重点内容一个接着一个的复制/粘贴,对他们来说,这是个非常痛苦和重复的过程。Simon 在他的伯克利写道:

「很多人都有同样的体会:读了书,却记不住讲了什么。那么如何记录一本书的精华呢?我们为此建立了最简单的工具:Read 可以把每一个标记保留成Evernote 里的专用笔记,而且每个都能在设备间同步。

不能读取itunes library

「取消」是被隐藏的,用户点击「OK」后就会跳转到Evernote的权限询问。(左)同样的提醒但多了是/否选项设计。(右)

标记功能的实现是最好的例子:说明软件本身讲如何对用户界面带来好的影响。两者相呼应:

1.一个按键用以突出显示选定的文本(text Menu)。

2.一个按键用以显示所有的重点(highlight Menu)。

Highlight 是Read的核心价值之一。我们在很早之前就深入进行了用户测试——我们问了一些简单的问题:这些符号在你看来是什么意思?并不是所有参与测试的用户都能确定图标、高亮显示、注释或引号之间的联系。我们测试了几十种图标,直到选出那个每个用户都能轻而易举地识别出的图标

不能读取itunes library

用户测试的图标

然后我开始定制iOS 默认的文本菜单(text Menu)——长按一个文本选项之后出现的弹出式菜单如复制、编辑和分享——这是一个棘手的代码操作。我们决定反过来思考这个问题。如果我们不能在Objective-C 中自定义菜单,那我们就得想出一个基于默认的iOS 文本菜单UI的图标。在几个小时内,我们就设计并实现了新的图标。

这个图标现在是动态的,通过它我们可以看到标记重点在随时间流逝而增加。它以新鲜的、游戏化的方式使读者看到自己的阅读进度,可以这样说,程序员的福音往往也是用户的福音。

不能读取itunes library

iOS 系统默认按钮(左),改进中(中),最终方案(右)

字体的选择

细节决定体验

不能读取itunes library

突出全段的长按手势

选择合适的字体是个非常纠结的过程,特别是做用户测试的时候。但这很重要!当在移动端阅读时,字体的正确选择能帮我们解决两大问题:

1. 阅读长段文本;

2. 移动设备上阅读(比如iPhone 6)。

字体设计师们关注阅读舒适度,很明显,对他们来说衬线字体是提高阅读体验最好的选择。一句话平均有10个单词,如果这句话;但移动端屏幕比纸页小。

有两条规则使我选择正确的衬线字体:

1. 能够在一个句子中不修改字间距,在有限的屏幕宽度容内纳最多词数;

2. 这个字体的字母「e」中的空白区域比较大。由于Read提供了五种字体大小选择,我需要注意的是最小文本的易读性。

不能读取itunes library字体Garamond 与字体Tiempos Text 的对比

最困难的,是在不牺牲阅读体验的前提下每页尽可能放置更多的单词。我试图选择一个尽可能窄的字体来限制断字,同时避免过多收缩。我选择了Tiempos 字体,它的大多数字符较小,间距较为收紧,整体的对比度也比较适应手机屏幕。

不能读取itunes library

字体名:(1) LyonDisplay, (2) Karol, (3)Tiempos Text, (4) New Fournier BP, (5) Dolly, (6)Georgia, (7) Novel Pro, (8) Suisse BP Serif, (9) Brill, (10) Merriweather, (11)Romain BP, (12) Galaxie Copernicus.

创新」VS「体验」

作为地道的艺术生,我着实费了好些时间才将创业公司的需求与我的个人品味及价值观区分开来,同样也费了好些工夫才搞清楚,也许对很多人来说都显而易见的一点:使用某个产品时,良好的体验实际上和那些花里胡哨的手势,并没有什么关系。

我设计的第一个应用叫M. Proust,我为其眼花缭乱的交互而自鸣得意,但这样的应用并不适用于创业思维。由于改动了一些基本的可用性原则,用户基本无法适应M. Proust那样的使用方式。我才明白,预测用户行为是现实应用程序市场中唯一需要遵循的法则,这无疑有悖于我在艺术院校里所接受的教育 2012年,我以「数字设备上的手势交互」为题写下了硕士论文,那时还想着如何用最创新的方法让用户用数字屏幕愉快地阅读。然而我错了,「创新」只是手段而并不是「目的」, 「体验」才是。

一些用户喜欢能设定很多功能的菜单,但是考虑到在电子书的App里,太多个性化可能会不利于人们实际阅读的方式。

「新功能」VS「核心功能」

一旦建立了应用的核心功能,新的问题就随之而来。是围绕新功能进行迭代,还是巩固核心功能

不能读取itunes library

由谷歌表格罗列的按优先级排列的用户反馈功能

在用户的要求与我们自己的追求之间维持平衡,这毫无疑问是困难的。我们几乎是在没有任何指导的条件下,发布了第一代产品。发布后,我们还是把重心放在了巩固原有应用上,这意味着

1. 不放弃考虑加入新功能;

2. 突出并提升现有功能;

3. 修复小漏洞。

失败的教训

如今我们已经停止了对Read 的运营。鉴于用户量的有限,我们无法再对这个App进行更新(但我很感谢你们对Read 的厚爱)。

我们时常会思考Read的下一步该怎么走,我们原先是计划先做成一个实用的工具,再做到商业化,最后做成社区。但以现有的用户量,我们无法证明确保第一步能否实现。不仅如此,在众多创业公司失败后,也许没有人会再去开发电子书市场。

我们还曾带着Read到Y Combinator(成立于2005年,是美国著名创业孵化器,Y Combinator扶持初创企业并为其提供创业指南)参加评选,我想那时他们就意识到亚马逊即将瓜分图书市场,他们也最后没能给我们投资。Y Combinator 非常认可我们对用户体验的尊重,也认可我们确实解决了一些用户的痛点,但相比于Kindle Store而言,似乎我们从开始就搞错了目标用户

我选了一些给了我们五星好评的用户留言,但我希望你先看看那些差评:

显示不了西里尔字体的书…

在加载书的时候它崩溃了!!

另一方面,近距离聆听用户的声音是值得的:

这是最好用的阅读软件之一。从每个细节,例如滚动视图和笔记,到简便的反馈方式和团队的回复,我真是爱不释手哇,你们也是吧!

这个应用在慢慢变好呢。期待landscape(译者注:一种文件打印格式)格式和Spritz的融合。(译者注:Spritz,一个来自美国的初创团队,要让小屏幕上的高效阅读成为可能)力荐!

不同于iBooks,这个应用可以充分利用整个屏幕,我能在屏幕上多阅读至少30%的内容,干得好!

哈哈,我真是做了一款有史以来最「完美」的「失败」作品……

拓展知识:

原创文章,作者:趣淘网小编,如若转载,请注明出处:http://www.3322388.com/75790.html

发表评论

邮箱地址不会被公开。 必填项已用*标注