0704 - Klib 到底赚了多少钱?

说说 Klib 这一生,以及能否养活他爹。


Klib 这款产品,从最初的想法,到目前第四版发布,已整整半年。而这个产品也走到了分叉路口,也是回顾的好时机。Klib 到底赚了多少钱?往下看。

先前,已经写了 2 篇关于 Klib 的长文:

感兴趣可以先看这两篇文章,相关的部分这里不再重复。

Klib 简要时间表

2017 这半年,便是 Klib 的全部。

版本 日期 主要功能
1.1.3 2 月 26 日 首发上架 MAS
1.5.5 4 月 4 日 从 Amazon、Kindle 客户端、多看导入
- - 在 Kindle for macOS 中回顾
1.6.1 5 月 16 日 从 iBooks 导入
- - 可标记章节
- - 引入实验室
1.7.2 6 月 23 日 新增阅读器
- - 一键分享读书笔记

在产品层面聊聊 Klib

Klib 解决了什么问题?

这应该是我启动一个项目时,最先、最经常问自己的问题,也应该是 产品存在的唯一理由

起初,这个问题很好回答:管理用户在 Kindle 上所做的标注和笔记。

后来,随着产品的演进,引入了很多其他功能,甚至可以从 iBooks 这个跟 Kindle 没有任何关系的 App 中导入笔记,产品的定位和方向就变得不清晰了。关于这一点,在文末统一介绍。

Klib 做得怎样?

值得骄傲的,Klib 做到了很多第一:

  • 首款上架 Mac App Store 的 Kindle 标注管理工具
  • 首款能在 Kindle for macOS 中回顾笔记的 App
  • 能从 Kindle、导出的 html、Amazon 官网中导入笔记,地表最强、没有之一
  • 首款可以导入 Kindle + 多看系统中笔记的 App
  • 目前自动排除 Kindle 重复标注最好的 App
  • 首款可以将 Kindle 的标注一键复制为 Markdown 格式的 App
  • 首款可以优雅管理 iBooks 标注的 App

简单的说,如果你需要管理 Kindle 标注、恰巧有一台 Mac,Klib 是你最好的选择

Klib 的一些功能

牛皮不是吹的,来说说 Klib 中一些不错的点:

「在 Kindle for macOS 中回顾笔记」

这是一个既酷炫、又实用的功能。

我们在回顾笔记时,有时会觉得标注的内容太简洁了、需要回看书的上下文。怎么办呢?很巧妙地,Klib 可以打开 Kindle for macOS、并跳转到标注所在位置,够贴心吧?

「自动合并不同来源的笔记」

如上所述,Klib 支持从 Kindle、Kindle 客户端、Amazon 等来源导入笔记,这也引入了书籍和笔记的合并问题。并且,用户有可能在 Klib 中修改笔记,这会让合并所需处理的逻辑更复杂。

好在,Klib 结合书名、作者、笔记原文、笔记位置等信息,很好地解决了不同来源的合并问题,尽可能地避免重复。

不过,毕竟不同来源的笔记没有标准格式,导入时依然会有重复的可能。于是,Klib 还支持手动合并书籍。看似简单,这却会又一层地增加复杂度:如果在被合并书中增加新标注,如何正确导入到合并的书中?单单是这一整套的合并逻辑,我处理了将近一个星期,梳理了大量测试用例,并用单元测试,保证各逻辑的正确。

当然,这是用户无法感知、却又觉得理所当然的功能。

「自动排除重复的笔记」

之前 Kindle 系统的标注逻辑是:选择文本,然后手动标注。新版系统做了调整:选择文本后自动标注。这带来的问题是:如果第一次没有选择正确、或者干脆就是误解,即使删除后重新标注,之前删除的标注依然会位于 Kindle 系统中,进而会被导入。

Klib 结合笔记的位置、内容的相似度,几乎可以排除所有重复的内容,仅保留最有价值的一条。

同样,这是用户无法感知、却又觉得理所当然的功能。

「标注为章节」

章节对于笔记的管理是很有帮助的,不然就会是一堆标注罗列在一起,没有规律,也会给回顾带来压力。

如何读取到书的章节信息呢?之前辗转联系上一位前 Kindle 在线阅读的工程师,他的原话是:我们内部有接口,用起来很容易。而很可惜,Kindle 并没有开放接口。如果要彻底支持,就需要解析带数字签名的亚马逊私有电子书格式。这工作量与难度,是相当巨大的。

不能放弃呀。于是,我想出了一个方式:

  • 阅读时在章节文字上添加标注
  • 导入 Klib 后,选择全部章节对应的标注,将其「标记为章节」
  • 在 Klib 中复制为 Markdown 时,自动为章节添加二级标题
  • 在 Klib 的阅读器中回顾时,章节会让排版更优雅

虽然需要手工多做一些事情,但与其能达到的效果,是相当划算的。

「阅读器及分享」

之前的 Klib 使用列表来展示所有笔记,虽然可以按下空格显示笔记的预览,但总归没有整体的感觉。

为了提升阅读体验,我在最近的 Klib 中引入了「阅读器」,名字和交互灵感来自 Safari 的「阅读器」,后者可以去除网页中的冗余元素,仅保留文本、图片等核心内容。想法很明确,而设计优雅的排版以方便中英文阅读,并不容易。并且还要考虑网页在电脑、手机等不同设备上的阅读效果,难度加倍。

经过好几版设计后,最终的样式是这样的:

可以隐藏所有干扰因素,仅剩下文字本身。纯净排版,让你沉醉于阅读;全屏体验,效果更佳。

有了优雅的排版,怎能不分享给好友呢?以书会友,共读精彩。当我偶然在一个读书群中看到用户分享使用 Klib 生成的读书笔记时,真的很开心 :)

「实验室」

功能的开发,总是众口难调。而我也可能做出错误的判断,怎么办呢?

目前,Klib 引入的「实验室」功能。对于变动较大的新功能,都会在「实验室」中观察一段时间。如果大家不喜欢,新功能将会调整、甚至移除。另外,考虑暂时不用考虑收费的问题,看试验的结果,延迟决定。

Klib 之于技术

麻雀虽小,五脏俱全。Klib 看似一个很小的产品,涉及到的技术还是很多的。

功能 技术
从 Kindle 导入 多语言文本识别、日期识别
从 Kindle 客户端导入 html 内容解析
从 Amazon 导入 html 内容解析
从 iBooks 导入 iBooks 数据结构逆向解析
导出至 Evernote Evernote 6 年前的 SDK
阅读器 使用 Markdown 生成 html,CSS 布局,SNS 分享
笔记分享 Python + Flask + Nginx + 阿里云 OSS + 服务器

界面开发

这部分没有太多可说的,因为我想尽量保持原生的感觉,大部分都是使用 标准控件。不过,还是遇到了坑,比如:

  • NSOutlineView会出现诸如 UI 刷新不及时、图标丢失等现象。
  • MKWebView 在 macOS 10.11 时有闪退,10.12 则正常

另外,要把标准控件用好,并不件容易。一个原因是,Apple 的技术文档,和 MSDN 不在一个世纪

软件质量

质量是软件的生命。对于我来讲,最大的问题是:时间有限。如果 在尽量少的时间内,覆盖尽量多的场景,减少 Bug,是一个挑战。

单元测试

在开发功能时,立即完善单元测试。既可以保证开发时避免遗漏,又可以一劳永逸地使用单元测试保证后续开发不会影响之前的功能,非常推荐。

截止目前,Klib 共有 133 条单元测试:

不过,在项目复杂后,Xcode 的单元测试变得很慢。尤其是 App 签名时,程序修改后,单元测试首次运行会失败,必须第 2 次运行才可以,很是闹心。

测试用例

人总是会遗忘的。在刚开发功能时,测试时能很好地覆盖功能的各个细节,时间长就忘了。最好的办法是,开发功能时,即写充分的测试用例出现用户报的 Bug,通常意味着这个环节是薄弱的。修复后,我都会 新添加一条测试用例,以保证后续的版本不会出类似的问题。

截止目前,Klib 共有 682 条测试用例:

也就是说,每发一个版本,我都要测试 682 个场景,如果考虑到操作系统版本(macOS 10.11, 10.12),理论上测试工作量还要翻倍。各位自行脑补一下,每发一个版本,我在电脑前久坐测试的场景…尤其是提需求希望支持 10.10 甚至更多版本的朋友。

收集日志

错误是难免的,重要的是及时改进。要改进,首先就要能知道错误。

  • Klib 本身会在错误时输出日志、记录在本地
  • 集成 DevMate 后,可以很方便地收集闪退日志

当然,前提是用户愿意并手动发送日志。

慎用第三方库

或者说,尽量使用稳定可靠的第三方库。在 DevMate 中追踪到的仅有的几个 Crash 中,大部分是 6 年前的 Evernote SDK 引起的,我也是无奈…

软件性能

Klib 最开始遇到的性能瓶颈是:当用户有上万条标注时,导入需要将近 2 分钟。其中,大部分时间用于日期识别、数据合并。经过改进后,导入仅需 10 秒左右,满意。

不过,目前还有待改进的是:当有大量数据时,界面操作会有卡顿。数据越多,卡顿越明显。确实还是有可改进的空间。一方面是减少计算量,另一方面是进一步分离界面操作与后台数据计算。

Klib 运营 & 推广

酒香也怕巷子深。这时代,大家每天要接触的信息太多了,要将自己的产品展现在用户面前,很难。也就意味着,很需要花时间、花心思去研究。我做的并不好,也并没有找到门道,这里只是大致列出我所做的事,供大家参考。

在 MAS 提交版本

这可以说是运营的起点。因为毕竟 MAS 是 Klib 唯一的下载渠道,是脸面。并且,MAS 还是有些自然流量的。即使这个环节不加分,至少不能减分。

每次提交版本,都要处理至少以下内容:

  • 应用名称
  • 描述
  • What’s New
  • 关键字
  • 截图

考虑到目前 Klib 支持 简体中文、英文、德文,工作量实际是上述的 3 倍。

其中,截图部分最为麻烦。因为,不仅要处理图片,关键的,要 事先准备素材(如书、标注内容等),才能生成适当的截图。中文还好,可我并没有标注那么英文原著。即使有,也都是技术类书籍,并不适合用于 MAS 的截图。没办法,我只能找英文中流行的书,从 Amazon 官网中找其分享的标注,合成一样书的阅读笔记。这种工作是非常费时的,德语版我干脆放弃了,直接使用英文的素材。

域名与官网

之前,Klib 是挂在 Toolinbox 官网的:https://toolinbox.net/Klib/

后来,为了方便推广,我又挑选了 Klib.me 这个域名,并建立官网:

这个页面看似简单、却花费大量时间:

  • 编写内容,制作图片
    • 中文、英文
  • 页面排版
    • 适配不同设备
    • 微信分享时显示图标
  • 全球访问加速
    • 期间,为了使用国内的 CDN 等资源,还不得不关站图案,哎…
  • SEO 优化

有个短的域名很重要,这样后来在分享笔记时,就可以有类似 http://s.klib.me/share.html 这种简洁的网址。

使用教程

随着 Klib 功能变得复杂,详尽的使用教程变得必须。目前,中文版的教程 在 13 寸 MBP 上,已经有 28 页之多

其中,最花时间的操作 gif 图的制作。和截图一样,首先要准备好素材。另外,就是要在最小的屏幕范围内,将意图表达清楚。因为,这意味着才能控制最终生成的 gif 文件大小。

之前,我使用 QuickTime 录屏,使用 iMovie 编辑后导出来 .mov 格式,然后再转成 gif. 其中,最麻烦的是 iMovie 仅能处理 16:9 的视频,这就要在录屏时非常小心地控制好比例。

后来,我发现 可以直接在 QuickTime 进行简单的编辑,也就是去除操作中多余的环节,仅保留操作部分,并生成最终的 gif 文件。这大大加快了 gif 的制作,唯一的缺点是:不能在视频中加文字。

媒体运营

媒体的助力,对产品的推广,帮助很大。

国内

效果最好的就是「少数派」了,以及 V2EX、爱范儿、掘金、Mac 玩儿法等媒体,以及自己个人的媒体,如朋友圈、微博、博客、等等。

除了媒体是否愿意报道,对我而言,最困难就是如何写媒体文章。毕竟自己是程序员思维,很难用讲故事的方式,写出吸引人的文章。这方面还得再提高。

海外

其实,国外推广是个非常头痛的事。毕竟文化不同,语言也有障碍。

效果最好的主要是两处:

  • Twitter 上用户自发推广
    • 30+ 次转发,160+ 个喜欢

我曾经要求自己每天在 Twitter、Facebook 发新消息,以建立品牌和影响力;不过可惜没有坚持。找个契机,重新开始运营。

用户运营

都说要口碑传播,最重要的,就是核心用户了。

起初,我是抗拒建立用户群的,因为我担心重复回答基础性的问题这种技术支持,会花太多时间。不过后来想想,还是利大于弊的,毕竟可以直接和用户接触、倾听用户的声音,是非常宝贵的。目前,用户和我直接沟通的渠道有:

  • 微信群
  • Telegram 群
  • 邮件反馈
    • 基本 3 小时内回复

另外一个没做的事:邮件订阅。尤其是国外,这个更常见。用户一旦喜欢一个团队、开发者,很可能是愿意知道其发布的新产品、新版本。很可惜,我还没有在网站建立这个。其中一个原因是,目前我的网站是基于博客的,加这一点不太方便。不过,找机会还是要加上。

软件定价与收入

软件定价是门玄学,里面的门道非常多。最近 Day One 调整收费模式,引来一片骂声。Klib 也没什么经验可介绍,只是罗列一下历史。

刚发布时 Klib Pro 是 ¥50,随着功能的改进,目前是 ¥98. 另外还有 Klib 扩展包,不过由于 Amazon 功能限制,国内用户可以无视;而且,其带来的收入,与 Klib Pro 相比,可以忽略。

如果你觉得书、软件贵,去商场逛一圈,看买 Klib Pro 的钱,都能买些什么

到底 Klib 赚了多少钱?我想这是很多朋友都感兴趣的。不出意料,答案可能会让绝大多数朋友惊讶:Klib 这 6 个月给我带来的收入,差不多等于我过去一个月的薪水。作为独立开发者,要养活自己和家人,我还得坚持很久。

另外一点可以分享的,由于我的影响力主要在国内,85% 左右的收入来自国内用户。在国内盗版的环境下,大家能如此支持 Klib,真心感谢。我也相信,随着大家消费能力、和软件素质的提高,会有越来越多用户愿意花钱购买软件,期待。

Klib 未来会怎样?

面对近 300 件要做的事,Klib 该何去何从?

引申:功能性产品的思考

截止目前,我已经先后做了 6 款 mac App (Klib、iPic、iPic Mover、iPaste、iHosts、iTimer),也都先后到了瓶颈。怎么回事呢?

总体来看,主要是 产品太过依赖功能:当功能基本完成时,就没有更多想象空间了。

如果要增加用户,很可能就要强行加功能。而这些附属的、可有可无的功能,很可能让产品本身变得难用。纠结于此。

再来看看 Klib

Klib 是款好产品,但不一定是个好的商业项目。

  • 使用频次太低
    • 比如,如果读一本书需要一个月,读完后才需要使用 Klib 导入标注和笔记,那 Klib 的打开次数基本就是 1 次/月,这实在是太低了。
  • 用户体量太小
    • 恰巧使用 Kindle 阅读
    • 恰巧想要管理标注
    • 恰巧有 Mac 电脑
    • 恰巧愿意付费
    • 这样的概率,相当于 0.1 0.1 0.1 0.1 = 0.0001,可真是 *万里挑一

怎么办呢?

方向一:深挖 Kindle 辅助工具这个定位

好处是:

  • 可以让 Kindle 用户获得更好的体验

坏处是:

  • Kindle 的用户群体还是太小
  • 更关键的,Kindle/Amazon 并不是一个合适的合作伙伴,不开放数据接口,很多体验很难做好

方向二:做笔记中枢

笔记的来源可以不止是 Kindle,也可以是 iBooks、多看等等;除了在 Klib 中阅读,还可方便地导出至 Evernote、OneNote 等目标应用。

好处是:

  • 可以获得更多潜在的用户
  • 可以增加产品的使用频次

坏处是:

  • 技术上非常依赖于第三方应用的开放程度、稳定性
    • 目测像微信阅读这样的应用,不见得深度开放数据,进而很难在其基础上有所发挥
    • 而且,一旦未来比现在更封闭,届时已经实现的功能就会失效(参见微博接口的越来越封装),这对于产品而言是很大的风险

目前还很难决择,暂定先观察一段时间;等考虑成熟了,再进一步改进。


考虑的同时,我准备挖个新坑:iTips, 碎片信息管理工具。这是我的 iPaste 的一位荷兰用户跟我提的需求,接下来的一段时间,我会跟他进行国际合作,共同打造这样一款国内、国外用户都喜欢,横跨 macOS、iOS 的新工具,敬请期待。