0704 - Klib 到底賺了多少錢？

時間 2019-11-30

標籤 klib 到底賺了少錢简体版

原文原文鏈接

說說 Klib 這一輩子，以及可否養活他爹。html

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 中導入筆記，產品的定位和方向就變得不清晰了。關於這一點，在文末統一介紹。post

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 官網的：toolinbox.net/Klib/

後來，爲了方便推廣，我又挑選了 Klib.me 這個域名，並創建官網：

這個頁面看似簡單、卻花費大量時間：

編寫內容，製做圖片
- 中文、英文
頁面排版
- 適配不一樣設備
- 微信分享時顯示圖標
全球訪問加速
- 期間，爲了使用國內的 CDN 等資源，還不得不關站圖案，哎…
SEO 優化

有個短的域名很重要，這樣後來在分享筆記時，就能夠有相似 s.klib.me/share.html 這種簡潔的網址。

使用教程

隨着 Klib 功能變得複雜，詳盡的使用教程變得必須。目前，中文版的教程在 13 寸 MBP 上，已經有 28 頁之多。

其中，最花時間的操做 gif 圖的製做。和截圖同樣，首先要準備好素材。另外，就是要在最小的屏幕範圍內，將意圖表達清楚。由於，這意味着才能控制最終生成的 gif 文件大小。

以前，我使用 QuickTime 錄屏，使用 iMovie 編輯後導出來 .mov 格式，而後再轉成 gif. 其中，最麻煩的是 iMovie 僅能處理 16:9 的視頻，這就要在錄屏時很是當心地控制比如例。

後來，我發現 能夠直接在 QuickTime 進行簡單的編輯，也就是去除操做中多餘的環節，僅保留操做部分，並生成最終的 gif 文件。這大大加快了 gif 的製做，惟一的缺點是：不能在視頻中加文字。

媒體運營

媒體的助力，對產品的推廣，幫助很大。

國內

效果最好的就是「少數派」了，以及 V2EX、愛範兒、掘金、Mac 玩兒法等媒體，以及本身我的的媒體，如朋友圈、微博、博客、等等。

除了媒體是否願意報道，對我而言，最困難就是如何寫媒體文章。畢竟本身是程序員思惟，很難用講故事的方式，寫出吸引人的文章。這方面還得再提升。

海外

其實，國外推廣是個很是頭痛的事。畢竟文化不一樣，語言也有障礙。

效果最好的主要是兩處：

Product Hunt
- 多人討論，300+ 個贊

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，可真是 *萬里挑一