迅速迭代功能的 Heptabase 已成為我最愛用的知識管理工具

P.J. Wu 吳秉儒
heptabase-changelog-screenshot

這張圖來自 Heptabase 的 官方 changelog 頁面,點進去可以看到每個版本大致上改了什麼東西。


Hi!

好久沒有寫 Heptabase 的文了,從上一篇 用 Heptabase 進行卡片寫作的心得 至今三個多月,已經過了超過 60 個版本號的更新(現在是 v0.160.0),這期間我曾一度停用 Heptabase 兩個月,一方面是覺得有些想要的功能還沒有,用起來不太順手,另一方面是當時忙於架設自己的部落格和 wiki 頁面。

但在 5 月底,我重新開始大量使用 Heptabase ,這次不僅只是單純回來逛逛玩玩,而是開始將自己的「第二大腦」從 Logseq 移出,全部都放到 Heptabase 上面

這麼做的原因是,這幾個月來, Heptabase 推出了幾個對於知識管理來說相當重要的功能更新,同時也不斷地在提升整體的使用體驗。

我覺得目前的 Heptabase 已經不單純是個「有潛力的工具」,而是已經可以承載複雜知識管理任務的產品了。甚至可以說,它目前就是所有選擇裡面最符合我需求的、最棒的工具。

以下先從此時此刻的角度回頭看,過去幾個月更新了哪些重要的功能,以及我怎麼看待跟使用這些功能。因為版本實在是不少,我有簡單根據幾個不同的體驗領域來分類。(版本號後面的連結都會直接連到 Heptabase 的官方 changelog 頁面,上面會有簡單的附圖或影片,這邊就不重複貼了!)

而在回顧完不同版本的功能後,會再簡單講一下目前我怎麼用 Heptabase ,以及他在我自己知識管理系統上的定位。


透過 Zola 建立了新的「筆記與想法快照」子網站

P.J. Wu 吳秉儒

從 5 月初開始嘗試透過 Logseq 以及 Dendron 建立個人 wiki 後,我開始更頻繁地產出文字到網路上,這些文字篇幅較短,也比較沒有組織,但這讓我更降低了輸出的壓力,也提高了輸出的快樂與成就感

6 月初,我決定再從用了一個月的 Dendron 搬走,而目的地就是與部落格相同的地方,或者應該說「相同的方式」:靜態網站產生器:Zola 。

最終的結果已經上線一個多禮拜,位址在: https://notes.pinchlime.com/

網址很簡單記,就是在 pinchlime.com 前面加上 notes 就好。

先說結論是,我目前對於這個子網站非常滿意,它在各方面的優點,讓我能夠大幅縮短「輸入->處理->輸出」這個流程需要的時間,進而增加完成整個循環的效率,最終的結果是我能夠順利地累積更多自己的想法,並且公開分享到網路上。

本篇會簡單分享一下,為什麼我要建立這個子網站?這個子網站是什麼?我怎麼建立這個子網站?


生產力就是在對的時間進行對的活動

P.J. Wu 吳秉儒

生產力就是在對的時間進行對的活動

例如,在需要找一份參考信件時能馬上找到。

例如,看到一個好想法時能迅速記在對的地方。

例如,精力充沛的時刻能夠花在重要又耗費精力的事情上。

如果生活中這樣的情境佔了大多數,那麼自己應該很少覺得自己在浪費時間,因為大多數的時間都在執行最適合的任務。

寫作的訣竅是對自己有興趣的領域真誠地寫下自己的想法

P.J. Wu 吳秉儒

跟什麼都想寫一點比起來,針對自己有興趣的領域,更有機會產生有價值的想法。

例如,為什麼喜歡或不喜歡這個領域裡面的某件事?該怎樣做到或避開這個領域的某件事?這些都需要一定的時間去浸淫與理解,才會慢慢產生自己的想法。

而只要能真誠地將這些屬於自己的想法寫下來,這些想法不僅對自己有價值,也可能對其他人產生價值,因為總有跟自己類似興趣的人,可能曾有過類似的疑問或思考,而自己寫下來了,讓對方產生共鳴。

所以,針對自己有興趣的領域寫下想法,不僅比較簡單,也更有價值,如果寫作都專門挑這類型的想法去寫,就沒那麼困難了。

反向連結必須要提供充分的上下文語境

P.J. Wu 吳秉儒

我認為,PKM 工具裡面的反向連結,必須要提供充分的上下文語境。倘若只是顯示「誰連到這則筆記」,是不夠的。

至少必須能夠展示該連結的前後文資訊、上下層級的摘要內容等,才是堪用的反向連結。

因為充分的上下文資訊,能夠讓未來的自己在看到該反向連結時,很快進入情境,理解「為什麼我當時記下這條?他的語境是什麼?」

這樣的理解有助於產生下一步行動,例如回頭編輯連結的源頭筆記,或者是產生更多的聯想,這些都必須要有充分的上下文資訊才能夠促成。

透過 Heptabase 製作閱讀筆記卡片

P.J. Wu 吳秉儒

我會在 Heptabase 裡面針對已經透過「我的閱讀、畫線與註記工作流」初步處理過的文章,視重要程度,在 Heptabase 裡面開設文獻卡片,命名格式為「articles.文章名稱」

建立卡片後,透過 Keyboard Maestro 直接加入固定的 template 。內容包含三個區塊:

  • metadata:包含作者、文章發布日、閱讀日
  • 註解區:包含 Quotes, Highlights, Annotations,並 透過Heptabase進行漸進式總結
  • 筆記區:包含使用 「我撰寫Literature-notes的方式」 這個方法撰寫的筆記
  • References:包含文章連結、Link from(從哪些地方讀到連到這篇文)、Link to (連到哪些筆記)

在製作閱讀筆記卡片的時候,特別需要注意的是把自己的想法寫下來,形成一則一則的原子筆記。此時我會再把他們列在下方的 “Link to” 區塊,後續即可將這些想法擴寫成自己的 random thoughts 或 evergreen 筆記了。

透過這整個流程,我在「閱讀筆記卡片」裡面,會保有一篇文章的畫線紀錄、我的註解內容,也可以連結到基於這篇文章產生的不同想法,留給未來的自己參考的依據。

透過 Heptabase 進行漸進式總結

P.J. Wu 吳秉儒

前一步驟:透過Heptabase製作閱讀筆記卡片

此一步驟: 在註解區,透過 Tiago Forte 提出的漸進式總結方法,註記相關資訊。

  • 第一層:先將 Glasp 裏面有畫線的區段都貼上來。
  • 第二層:把覺得寫得好的地方用成粗體顯示
  • 第三層:特別喜歡的句子用成 highlights
  • 第四層:寫下自己的想法

這些都能在 Heptabase 的編輯器裡面很輕鬆地處理。

聯想羅盤

P.J. Wu 吳秉儒

Version: 1.0

簡介:聯想羅盤是我參考 5/17 介紹的 The Compass of Zettelkasten Thinking 建立的小小 workflow ,透過 Heptabase 的視覺化筆記來實現,使用方式是把需要的卡片放在正中央,此時就開始根據聯想羅盤的東西南北四個方位開始思考新的想法。

  • 中間:放置想法本身
  • 北方:這個想法從哪兒來?
    • 為何會冒出這個想法?
    • 這個想法可能屬於哪個卡片盒、分類
    • 他的上位概念可能是什麼?
  • 西方:跟這個想法相似的有什麼?
    • 別人是否提過類似的概念或想法?
    • 我自己是否提過類似的概念或想法?
  • 東方:跟這個想法競爭、衝突的有什麼?
    • 別人是否提過衝突的想法?
    • 我自己是否曾有過不同的想法?
    • 有哪些想法可以補充這個想法,讓他更好?
    • 這個想法缺了哪些東西?
  • 南方:這個想法可以往哪裡去?
    • 這個想法可能可以延伸什麼下一步行動?
    • 這個想法的下位概念可能是什麼?

由下而上建立關聯性的關鍵字索引比單純建立雙向連結更有價值

P.J. Wu 吳秉儒

我的理解上,正確使用卡片盒筆記法(Zettelkasten)的六個關鍵步驟 | 閱讀前哨站裡面提到的關鍵字索引 (Keyword Index),是某種必須持續維護的東西。

維護的重點在於「由下而上」建構內容。意思是逐步建立關鍵字、擴張不同關鍵字,持續加入卡片,幫卡片們建立連結。

那怎樣算是「由上而下」呢?舉例來說,如果我今天直接建立了一個 [[Zettelkasten]] 的關鍵字索引,然後開始搜集各種定義、名詞解釋等等,這就是比較屬於「由上而下」的建構方式。

但由下而上更注重於持續地、有意識地去跟過去的自己對話。

我認為,這種方式比單純透過雙向連結來期待「未來的自己能察覺到筆記與筆記之間的關聯」是更好的作法。

產品的功能不是越多越好

P.J. Wu 吳秉儒

從 Wordle 的例子來看,我覺得產品的功能不是越多越好。

Wordle 的核心功能很單純,一天猜一個字,猜完可以用單純的 emoji + 文字進行分享,這個分享有著足夠有意義的資訊卻又不會爆雷,而分享完之後你就不能玩了,只能等待下一天。

Wordle 捨棄了複雜的通關、等級、不同玩法的可能性,專注於把核心的功能(玩法)做好,配合好的分享機制設定,讓成癮用戶時常有動力分享,讓未成癮用戶能時常看到分享,進而被勾起遊玩的慾望。

我覺得這種在產品設計上的克制,值得效仿。

打字速度快的好處是想法能更快從腦中卸載成為想法快照

P.J. Wu 吳秉儒

打字速度快的好處是,想法能更快從腦中卸載,成為一個固著的「想法快照」。

很多時候我們的靈感跟想法會出現在打字的過程中,因為大腦必須思考接下來要打什麼,就會自動運轉起來,此時若打字打得快,自己心裡想的事情跟靈感就能夠更快產出,不會被卡住。

Brian Lovin 認為1,打字打得快是有複利效應的,從輸出的角度來看,打更快代表更容易形成草稿,也更容易編輯成可以輸出的文字,而輸出頻率增加就更容易收到回饋,此時自己的想法就會更完善,也會產生更多靈感,從而形成一個正面的循環。


Output: 用鍵盤打字逐漸成為稀有技能? - by P.J. Wu 吳秉儒 - Pin起來電子報


[1] Typing fast is a high-leverage skill ↩︎

專案文件應該寫清楚需求與限制

P.J. Wu 吳秉儒

一份好的專案文件,應該要清楚列出這個專案需要什麼資源,以及有哪些限制。

這樣做的用意,是讓讀文件的人能夠跟提出文件的人,站在同樣的角度評估與思考。

假設這個需求沒那麼重要、或者做不到,就能提出來討論。 假設這個限制,有其他方式可以繞過,就能提出來討論。

把需求與限制釐清,再透過良好的審視與討論流程, 就能讓大家好好地討論,進而有效率地往下推進專案。

透過 Curius 在閱讀文章時畫線與註記 (已於 2022.06.25 歸檔)

P.J. Wu 吳秉儒

(本則 Workflow 已有更新版:我的閱讀、畫線與註記工作流

我的資訊處理第一步驟是:閱讀、畫線、註記

目前只要透過瀏覽器閱讀的文章,我都會在上面透過 Curius 畫線,有些特別有感的段落也會直接註記在上面,包含我自己的換句話說、我自己的疑惑、或者是靈感。

而讀完一篇文章後,我會透過 Curius 的 tags 功能,把文章分成「單純讀就好」、「待做筆記」、「做完筆記」這幾類。

每天晚上或週末比較有空的時間,就挑那些「待做筆記」的文,在 Heptabase 上面進行漸進式總結。

我撰寫 Literature notes 的方式

P.J. Wu 吳秉儒

我撰寫文獻筆記的方式,可以參考正確使用卡片盒筆記法(Zettelkasten)的六個關鍵步驟這篇好文的寫法,重點是把自己有感的段落,用自己的話條列式記下。(記得,不要照抄,也不要複製貼上)

這邊的關鍵在於「自己的共鳴」跟「自己的話」,一開始會不太習慣,但慢慢練習就會越來越熟悉。

因為這件事相對花時間與精力,所以在前段閱讀時就要控管好,找出真正想寫文獻筆記的好文去寫就好,其他可以看過、隨意寫一些註記或閃念筆記(fleet notes)就好。

另一個訣竅是,不要怕竄改作者的意思,總之用自己的話寫就對了,反正 Literature notes 沒有要輸出用,輸出時的嚴謹性可以輸出時再控管處理。

當我寫完 Literature notes 時,會趁著記憶猶新,從剛剛寫完的筆記裡面,挑一兩個疑問或論點出來發展成自己的 Evergreen notes。

透過 Raycast 檢索 Raindrop 的書籤

P.J. Wu 吳秉儒

隨著我寫的東西變多,交互引用的次數也變多,若每次都要點開網站瀏覽就有點沒效率,因此我把我寫過的電子報以及 blog post 都存到 Raindrop.io 裡面,並且透過 Raycast 的 extension 來取用。

比方說我只要打 rl ,再輸入我想要的關鍵字,就可以搜到我 PO 過的文章了。

(但目前只能搜尋標題而已,看起來還無法進行全文搜尋。)

工作流程的標準化有助於提高效率

P.J. Wu 吳秉儒

我認為,工作流程的標準化有助於提高效率,原因是:

  • 標準化後,可以提高對工作的熟悉度,進而讓人進入某種「自動化」的節奏,這能讓個人提高效率。
  • 標準化後,也更容易橫向比較,例如,專案 A 的步驟 2 跟專案 B 的步驟 2 差別在哪裡,為何前者比後者少花了五個小時完成?這樣的比較有助於找出提高效率的機會,進而讓工作流程達到最佳化,這能讓團隊提高效率。
  • 標準化後,更好紀錄單位工時,這讓每個流程的成本以及預估時程都更容易計算,進而可以做出更精準的專案排程與成本規劃,這能提高公司整體資源運用的效率。

如何透過 Logseq publish 在 Netlify 上建立個人 wiki?

P.J. Wu 吳秉儒

今天想來分享一下,如何將自己的 Logseq graph 透過內建的 publish / export 功能,直接發布到網站上,藉此建立一個「個人 Wiki」頁面,或者也可以稱它為 Digital Garden。

如果一切順利,完成品就會是一個類似這樣的東西:

https://logseq.pinchlime.com

點開來以後會很像自己 Logseq graph 的樣子,可以有超連結、可以建立頁面、可以設定雙向連結,也可以看到 graph view 。

logseq-publish-demo

這個頁面是 4 月底到 5 月初我自己的小小嘗試,透過這個嘗試我發現建立「個人 Wiki」有非常多優點,但 Logseq 還有一些不足的地方,因此後來我又找到了 Dendron 這個工具來建立我自己的個人 wiki。(2022.12.25 後記:已關閉)

但 Dendron 更小眾一些,使用起來門檻也比 Logseq 高一些,如果你對 Logseq 有興趣,或者本來就已經是 Logseq 的使用者,也對建立一個個人 wiki 頁面有興趣的話,相信這篇簡單的教學應該還是可以提供一些幫助!


電子報的優點是可以直達收信者的信箱

P.J. Wu 吳秉儒

一則內容,如果在社群平台上面寫,內容會是屬於該社群平台的,讀者單純消費,若喜歡可能會存到稍後閱讀或其他 PKM 工具。但未來若想回來找,也很難再找到。

如果在部落格寫,內容會是屬於自己的,但讀者一樣看過就離開,通常不會存起來。未來若想回來找,必須記得作者或文章的關鍵字。

如果透過電子報寫,發出後是直達收信者的個人信箱,即使讀者迅速看過,不特別儲存到什麼地方,內容還是會靜靜地待在信箱。未來若想回來找,因為目的地明確,就更容易找到。

若能直達收信者的信箱,就更容易佔有收信者的注意力。

Evergreen notes 的命名必須是主觀的論點

P.J. Wu 吳秉儒

Evergreen Notes 的命名必須是主觀的論點。

這樣做的優點是:

  1. 未來自己或他人要閱讀時,可以節省查閱跟重新理解的時間。 例如,假設命名是:「Evergreen notes 的命名方式」,就會不知道可能會連到怎樣的內容。

  2. 當格式是主觀的論點,就更好遵循 Andy Matuschak 提出的「atomic1」以及「concept-oriented2」這兩個原則。

  3. 當格式是主觀的論點,也比較好聯想明確的子論據。

2022.05.29 補充:Evergreen notes 的句型必須是「肯定句」,而非「疑問句」。疑問句則會放在 Daily WHW 或 Random Thoughts 裡面。


[1] Evergreen notes should be atomic ↩︎

[2] Evergreen notes should be concept-oriented ↩︎

部落格新增了 Footnotes 註腳的功能

P.J. Wu 吳秉儒

昨天在 Zola 的官方討論區看到有人在提問某個程式碼的問題,但發現他那段程式碼的目的是想要自訂 footnotes ,也就是註腳的功能,這就讓我很感興趣。

雖然我一開始完全看不懂他的 code ,但還是留言詢問了一下可否分享他寫的完整代碼給我,結果他真的很好心地分享,還寫了一段說明。我簡單照著做之後,就真的實現了這個功能,覺得這對我來說是個很有意義的功能,因此想簡單分享(搬運)一下他的做法。