独自一人,如何开发和运营 Klib
在复杂的世界里一个就够了:ONE一个- 少数派 / JasonZone
说说 Klib 这一生,以及能否养活他爹。
Klib 这款产品,从最初的想法,到目前第四版发布,已整整半年。而这个产品也走到了分叉路口,也是回顾的好时机。Klib 到底赚了多少钱? 往下看。
先前,已经写了 2 篇关于 Klib 的长文:
感兴趣可以先看这两篇文章,相关的部分这里不再重复。
Klib 简要时间表 2017 这半年,便是 Klib 的一生。
在产品层面聊聊 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 中一些不错的点:
1.「在 Kindle for macOS 中回顾笔记」
这是一个既酷炫、又实用的功能。
我们在回顾笔记时,有时会觉得标注的内容太简洁了、需要回看书的上下文。怎么办呢?很巧妙地,Klib 可以打开 Kindle for macOS、并跳转到标注所在位置,够贴心吧?
2. 「自动合并不同来源的笔记」
如上所述,Klib 支持从 Kindle、Kindle 客户端、Amazon 等来源导入笔记,这也引入了书籍和笔记的合并问题。并且,用户有可能在 Klib 中修改笔记,这会让合并所需处理的逻辑更复杂。
好在,Klib 结合书名、作者、笔记原文、笔记位置等信息,很好地解决了不同来源的合并问题 ,尽可能地避免重复。
不过,毕竟不同来源的笔记没有标准格式,导入时依然会有重复的可能。于是,Klib 还支持手动合并书籍。看似简单,这却会又一层地增加复杂度:如果在被合并书中增加新标注,如何正确导入到合并的书中?单单是这一整套的合并逻辑,我处理了将近一个星期,梳理了大量测试用例,并用单元测试,保证各逻辑的正确。
当然,这是用户无法感知、却又觉得理所当然的功能。
3. 「自动排除重复的笔记」
之前 Kindle 系统的标注逻辑是:选择文本,然后手动标注。新版系统做了调整:选择文本后自动标注。这带来的问题是:如果第一次没有选择正确、或者干脆就是误解,即使删除后重新标注,之前删除的标注依然会位于 Kindle 系统中,进而会被导入。
Klib 结合笔记的位置、内容的相似度,几乎可以排除所有重复的内容 ,仅保留最有价值的一条。
同样,这是用户无法感知、却又觉得理所当然的功能。
4. 「标注为章节」
章节对于笔记的管理是很有帮助的,不然就会是一堆标注罗列在一起,没有规律,也会给回顾带来压力。
如何读取到书的章节信息呢? 之前辗转联系上一位前 Kindle 在线阅读的工程师,他的原话是:我们内部有接口,用起来很容易。而很可惜,Kindle 并没有开放接口 。如果要彻底支持,就需要解析带数字签名的亚马逊私有电子书格式。这工作量与难度,是相当巨大的。
不能放弃呀。于是,我想出了一个方式:
阅读时在章节文字上添加标注 导入 Klib 后,选择全部章节对应的标注,将其「标记为章节」 在 Klib 中复制为 Markdown 时,自动为章节添加二级标题 在 Klib 的阅读器中回顾时,章节会让排版更优雅
虽然需要手工多做一些事情,但与其能达到的效果,是相当划算的。
5. 「阅读器及分享」
之前的 Klib 使用列表来展示所有笔记,虽然可以按下空格显示笔记的预览,但总归没有整体的感觉。
为了提升阅读体验,我在最近的 Klib 中引入了「阅读器」,名字和交互灵感来自 Safari 的「阅读器」,后者可以去除网页中的冗余元素,仅保留文本、图片等核心内容。想法很明确,而设计优雅的排版以方便中英文阅读,并不容易。并且还要考虑网页在电脑、手机等不同设备上的阅读效果,难度加倍。
经过好几版设计后,最终的样式是这样的:
可以隐藏所有干扰因素,仅剩下文字本身。纯净排版,让你沉醉于阅读;全屏体验,效果更佳。
有了优雅的排版,怎能不分享给好友呢?以书会友,共读精彩。当我偶然在一个读书群中看到用户分享使用 Klib 生成的读书笔记时,真的很开心 :)
6. 「实验室」
功能的开发,总是众口难调。而我也可能做出错误的判断,怎么办呢?
目前,Klib 引入的「实验室」功能。对于变动较大的新功能,都会在「实验室」中观察一段时间。如果大家不喜欢,新功能将会调整、甚至移除。另外,考虑暂时不用考虑收费的问题,看试验的结果,延迟决定。
Klib 之于技术 麻雀虽小,五脏俱全。Klib 看似一个很小的产品,涉及到的技术还是很多的。
界面开发 这部分没有太多可说的,因为我想尽量保持原生的感觉,大部分都是使用 标准控件 。不过,还是遇到了坑,比如:
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、Facebook 发新消息,以建立品牌和影响力;不过可惜没有坚持。找个契机,重新开始运营。
用户运营 都说要口碑传播,最重要的,就是核心用户了。
起初,我是抗拒建立用户群的 ,因为我担心重复回答基础性的问题这种技术支持,会花太多时间。不过后来想想,还是利大于弊的,毕竟可以直接和用户接触、倾听用户的声音,是非常宝贵的。目前,用户和我直接沟通的渠道有:
另外一个没做的事:邮件订阅 。尤其是国外,这个更常见。用户一旦喜欢一个团队、开发者,很可能是愿意知道其发布的新产品、新版本。很可惜,我还没有在网站建立这个。其中一个原因是,目前我的网站是基于博客的,加这一点不太方便。不过,找机会还是要加上。
软件定价与收入 软件定价是门玄学,里面的门道非常多。最近 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 x 0.1 x 0.1 x 0.1 = 0.0001,可真是万里挑一 怎么办呢?
方向一:深挖 Kindle 辅助工具这个定位
好处是:
坏处是:
Kindle 的用户群体还是太小 更关键的,Kindle/Amazon 并不是一个合适的合作伙伴,不开放数据接口,很多体验很难做好 方向二:做笔记中枢
笔记的来源可以不止是 Kindle,也可以是 iBooks、多看等等;除了在 Klib 中阅读,还可方便地导出至 Evernote、OneNote 等目标应用。
好处是:
坏处是:
技术上非常依赖于第三方应用的开放程度、稳定性 目测像微信阅读这样的应用,不见得深度开放数据,进而很难在其基础上有所发挥 而且,一旦未来比现在更封闭,届时已经实现的功能就会失效(参见微博接口的越来越封装),这对于产品而言是很大的风险 目前还很难决择,暂定先观察一段时间;等考虑成熟了,再进一步改进。
考虑的同时,我准备挖个新坑:iTips, 碎片信息管理工具 。这是我的 iPaste 的一位荷兰用户跟我提的需求,接下来的一段时间,我会跟他进行国际合作,共同打造这样一款国内、国外用户都喜欢,横跨 macOS、iOS 的新工具,敬请期待。
博客原文:0704 - Klib 到底赚了多少钱?
Original Article:
https://sspai.com/post/39855