Dendron 跟 Zola 哪個好?

發布於 2022-06-04 | 最後更新時間 2022-06-04 | 分類: Random Thoughts
  • 透過 Dendron 建立個人 wiki 剛好滿一個月了,這個月我養成了每天至少提一個問題的習慣,而連帶的好處是我的各種思考更多了,也開始把他們都連在一起。

  • 這週開始用更成熟的 Heptabase 來實踐這個習慣,發現也非常順手,甚至因為圖像化的連結,比 Dendron 更勝一籌。這也讓我想起,既然 Dendron 在實踐習慣這一環已經不需要了,那在 Publish 這環是否也有必要維持呢?

  • 曾被淘汰的 Logseq Publish 就先暫且不論,我想比較的是拿來寫部落格的 Zola 。

  • Zola 的優點是,部署極快,網站跑起來也極快,而且隨著我四月那波認真玩的經驗,我對於自己的整個 zola site 裡面的各項程式碼有一定的了解程度,這樣的了解一方面是了解「Zola 可以辦到什麼」,另一方面則是了解「我還無法透過 Zola 辦到什麼」。

  • 我無法辦到的是像 Dendron 那樣內建的階層架構以及資料夾的呈現方式(但可以學習命名方式),我也無法辦到 Dendron 方便地建立雙向連結。(但若只是把 Hepta 裡整理好的資訊更新上去,則有機會手動辦到。

  • 所以看起來,Hepta 補足了 Zola 這種單純的 SSG 在管理知識系統上的功能缺陷,那這樣看起來就更有使用 Zola 的理由了。

#Dendron   #Zola


嘗試在部落格加上 navbar

發布於 2022-06-04 | 最後更新時間 2022-06-04 | 分類: What I Tried Today
  • 今天比較有空,就來處理 blog to-do list 上面的其中一項:加上 navbar。

  • 先研究了 zola 官網的各種 themes ,發現好像都是用 sass 的架構,跟我從 Owen 那邊承襲而來的單純 css 有些落差。所以最後還是看回 Owen 的作法。一開始糾結在他的版本,但後來轉念一想,他放置的地方是在 Section Root ,那我只要放到 Section Top 不就好了?

  • 於是經歷了一番亂搞,最後終於製作完成了,整體感覺我還蠻喜歡的,雖然肯定還可以更好,但目前也夠用了。

  • 附上截圖

  • 這個研究的過程也讓我開始思考,是不是個人 wiki 還是用 Zola 來建更好?

#Zola


結構化與去結構化的筆記工具優劣

發布於 2022-06-03 | 最後更新時間 2022-06-03 | 分類: Random Thoughts

這是從雙向鏈接的一點思考這篇文章延伸的一些想法。

一開始會棄 Obsidian 朝向 Workflowy 跟 Logseq 是因為,我在 Obsidian 裡面實踐 MOC 的形式是 top-down 的方式,但那讓內容太難增生,每次產生想法都在想這個該放哪,久而久之就壓力很大,覺得無法順利進行。

後來到 Workflowy 及 Logseq 後的確感到了無壓力的輸入體驗,但累積久了卻發現 Logseq 讓我無法全心投入(見我為何無法全心投入 Logseq ),現在想起來可能是因為 Logseq 提倡的「去結構化」,也就是沒有資料夾,單純倚賴連結的架構。

在讀了發現問題思考法後,察覺到「分」跟「連」的意義,覺得 Logseq 這類工具擅長連,但不擅長分。

開始接觸 Dendron 後,被他們對於層級化架構的理念吸引,開始覺得有結構還是很好的一件事。

隱約感覺,還是必須先有結構,再來產生去結構化的好處,有點像是我在打這串 thoughts 時,串連的這幾個東西,都因為有明確的層級,所以我反而更好聯想,能讓他們串在一起。

#PKM Thoughts   #Hierarchy


更新卡片內容的最佳實踐方式是?

發布於 2022-06-03 | 最後更新時間 2022-06-25 | 分類: Random Thoughts
  • 在 Heptabase 裡面,如果某張卡片的內容需要更新,但也想留著之前的版本,該怎麼做最好?

    1. 透過卡片的命名去處理新版本,例如原本是 卡片A 2022-03-04 ,更新後變卡片A 2022-06-03 ,然後在 03-04 的卡片連結到 06-03 但白板裡的卡片就換成 06-03
    2. 卡片命名都是卡片 A ,但直接更改 03-04 的卡片內容為 06-03 的版本,不特別標注日期跟版本差異
    3. 卡片命名都是卡片 A,在 03-04 的卡片內容下方,補充 06-03 的內容。
  • 我覺得更好的作法,可以把卡片 snapshot 起來,當前還是顯示最新版本的卡片,但 UI 上面可以看到有點類似文件夾那樣的「卡片組」樣式,然後點開就可以看到過去版本的卡片內容。

  • 而這樣的卡片是「整組綁定的」,也就是說在任何白板加入卡片時,都會直接加入這個卡片組。

  • 我覺得卡片組的方式優點在,本質上,這張卡片的主題一樣,方法一會過於冗余累贅,方法二會看不到變化的過程,方法三也可能會感到混亂。


但在還沒有這種「卡片組」的概念前,我想到的實踐方式是:

  • 類似方法一的內容,只是把舊卡片後面標註為「archived on 日期」,並且在 Hepta 裡面的新卡片內部連結到這張卡片。部落格上面則不需要特別處理。

#Heptabase


我為何無法全心投入 Logseq?

發布於 2022-06-03 | 最後更新時間 2022-06-03 | 分類: Daily Why

我覺得使用 Logseq 幾個月下來,似乎讓我沒辦法有「累積」的感覺,我只知道我建立了很多東西,但他的搜尋體驗沒有太好,很難直覺找到我想找的東西,而即使要透過連結,我也必須要先知道「我有這個東西可以連結」,才能連結的到。

這兩件事都會造成我使用上的心智負擔。

還有一個是 Logseq 的 block embed 功能我也沒有特別信任,之前就發生過錯誤,不知為何過一陣子回去看某則筆記後,發現讀不到 embed 的東西,但又因為整串 embed 資訊是一串亂碼,導致我根本不知道我 embed 了什麼東西,結果那則筆記也失去它的意義。

綜合以上幾點,自從 Heptabase 出現後,我就感覺 Logseq 蠻難作為第二大腦的儲放地點,最多最多只能當作想法隨意萌芽迸發的地方,而一但有了某種固定的結構,就適合放到 Heptabase 裡面當作我的原子筆記。


Backlinks:

#Logseq   #Heptabase


為何我想把工作記錄由 Logseq 移到 Dendron?

發布於 2022-06-02 | 最後更新時間 2022-06-02 | 分類: Daily Why

今天動起了這個念頭。也不知從何而來的,感覺好像是發現,我雖然工作上很倚賴 Logseq ,但拆解實際的使用情境後,真正會用到的只有快速的雙向連結(關聯性連結)以及迅速的大綱紀錄體驗。

但缺點也是有的, Logseq 缺乏文件夾的架構,讓我在資料多了以後,必須更仰賴雙向連結,而無法 top-down 式的查找資料。

另外,Logseq 的編輯體驗說不上太好,每次都抓不準有序列表跟無序列表的切換跟 indent / outdent 。

再者,我在工作上的路徑是「Logseq → Slack & Email」,但 Logseq 複製出來的效果也都不是特別好,常常需要重新排版一下。

這時就想到了目前在 Wiki 上用的蠻喜歡的 Dendron ,覺得好像可以擔負這個責任。

首先, Dendron 也有 daily notes ,可以讓我每天記錄事情。

再者, Dendron 也可以透過雙向連結跟 note references 去建立基本的反向視角。比方說,我在 2022.06.02 下面紀錄 [[ 專案 1 ]] 時,記完就可以把整段 reference 到專案 1 的主頁面。長久來說,這樣好像更能有組織地累積內容。

那就先來試試看吧!

#Logseq   #Dendron


什麼是「鑄幣稅(seigniorage)代幣」?

發布於 2022-06-01 | 最後更新時間 2022-06-01 | 分類: Daily What
  • DeFi 穩定幣的過去與未來:寫在 Terra UST 崩盤後 這篇好文裡看到這個有趣的概念。
  • 鑄幣稅代幣引用鑄幣稅的概念,指的是直接與該貨幣對應,並且會直接基於該貨幣的流通使用量影響價值的代幣。
  • 以 USDC 為例,該穩定幣的鑄幣稅代幣可以理解為發行商 Circle 的股票。
  • 而之前崩盤的 UST ,其鑄幣稅代幣就是 LUNA ,而 DAI 的鑄幣稅代幣是 MKR。
  • 這篇文章認為,如果鑄幣稅代幣本身就是對應穩定幣的價值支撐,那麼就有可能會讓穩定幣的「穩定效果」受到負面影響,因為鑄幣稅代幣的流通性跟需求若容易觀測,那就會讓市場處於悲觀情緒時,更難逃離悲觀的賣壓漩渦。
  • 因此這篇文章提出的主張是:對等無知(symmetric)的不透明貨幣市場有利於流動性。

#Stablecoins


為何「為什麼」比其他類型的問題都還難產生?

發布於 2022-05-31 | 最後更新時間 2022-05-31 | 分類: Daily Why

每天在想問題時都會感覺到,Why 類型的問題比 What 跟 How 還要難產生。What 跟 How 可以透過很純然的好奇心來支撐,例如,我現在桌子上擺著一個杯子,我可以問這個杯子由什麼組成(what)、這個杯子是怎麼做的(how)、我該怎麼使用這個杯子(how),這個杯子跟其他杯子有什麼不一樣?(what),但我好像問不太出一個關於杯子的「why」。

或者說,我知道即使我問了,我好像也回答不出來,或者對我來講好像沒什麼特別驚喜感,所以也不想問。例如,為何這個杯子上面要印 Beatles 的圖案?因為他是在利物浦賣的,觀光客喜歡呀。

如果要回答今天這個問題,我的答案好像會是,因為 why 是複合的元素組成的,有著他的情境,例如「我為何喜歡某軟體」,是由「我」跟「某軟體」組合而成。「為何某某狀況在台灣時常發生」,是在討論「某狀況」與「台灣」的關係。

這樣複合的狀況需要花更多力氣去觀察,也更難回答一些,而這個「更難回答」因為可能要花很多力氣,就會讓我潛意識傾向尋找「比較好回答」的 why 問題,但並沒有那麼多又好回答,我又感到有興趣的 why 問題,所以就容易卡住了。

#What How Why


為何我喜歡逛 Heptabase 的 discord?

發布於 2022-05-30 | 最後更新時間 2022-05-30 | 分類: Daily Why
  • 這裡的頻道分類架構很好,不會很混亂(除了 feedback 跟 feature-request 有點像),基本上大家可以很容易找到可以討論的地方
  • 團隊成員對於問題的回覆很即時,參與感很高
  • 團隊成員(尤其是 Alan)會提到很多決策的理由,這點可以讓人快速同理他的想法,進而認同。
  • 社群的討論品質很高,常有人分享有趣的問題。
  • 這些上述元素綜合起來是:
    • 這裡有我欣賞的人,會發表我認同與有收穫的觀點,並能接觸到我有興趣的主題與討論。

#Heptabase   #Discord


短想法的終點都是 Evergreen notes

發布於 2022-05-29 | 最後更新時間 2022-05-29 | 分類: Random Thoughts

剛剛在整理自己該怎麼使用 Heptabase 時發現,我的目標好像是要盡量累積 evergreen notes,因此無論是 why, how, what, 或者是 random thoughts ,好像都應該盡量提取可以成為 evergreen notes 的片段。

也因此,整個工作流的目標可以設定為,如何讓自己更有效率的提取可以成為 evergreen notes 的想法?

另外,從另一個角度來想, daily WHW 則是我的內容引擎,能持續讓我產出 evergreen notes。

#What How Why   #Evergreen Notes


為何我認為 Heptabase 的層級化白板是 game changer?

發布於 2022-05-29 | 最後更新時間 2022-05-29 | 分類: Daily Why

這兩天密集使用下來,我覺得 0.143.0 推出的層級化白板功能是 Heptabase 非常重要的一次更新,因為它讓筆記、卡片的後期整理變得容易。

在沒有層級化白板前,卡片的分類方式一直是我困擾的點。比方說,我原先開了一個「生產力工具」的白板,然後在下面放各種生產力工具的卡片。但假設我最近都在用 Hepta ,那麼我寫出來的內容都會跟 Hepta 比較相關,此時我就會不知道、會猶豫,我該開一個「Hepta」的白版,還是要在「生產力工具」底下把某一個區塊都留給 Hepta 相關的卡片。

這件事在任何主題的場景都有可能出現,這是因為 Hepta 原先規劃的層級太少,僅有 Map, Whiteboards, Cards 三類。而 Map 也只有一個,等於要把一個人的所有想法都透過「白板/卡片」這樣兩層的方式劃分,我用一用就覺得太限縮了。

但層級化白板出來後,這個問題被解決了大半。以剛剛的情境為例,假設我一開始創了生產力工具這個白板,但我後來持續在加入的都是 Heptabase 相關的卡片,我就可以在生產力工具裡面建立一個叫 「Heptabase」的白版,或者也可以直接透過命名表達他們的階層關係,例如「生產力工具-Heptabase」,然後再把這些相關的卡片丟進去。

這個功能上的更新,讓卡片的分類跟整理變得容易與直覺許多,讓人可以更肆無忌憚地新增卡片,反正即使亂了,或者一開始不分類,後來都很容易可以再細分類。

這樣程度的無壓紀錄,我覺得已經快可以趕上 Workflowy 或 Logseq 這些大綱編輯器,甚至更好,因為 Logseq 也有著自己特有的缺點,相較之下,Hepta 的綜合分數更高。

但假設有了層級化的白板,那麼「白板」跟「卡片」這兩個屬性還有必要同時存在嗎?還是說可以理解為,卡片只要裡面有卡片,他就是白板?

#Heptabase   #Nested Whiteboards


怎樣程度的抱怨最剛好?

發布於 2022-05-28 | 最後更新時間 2022-05-28 | 分類: Random Thoughts

大部分的人可能都不喜歡聽到別人抱怨。 大部分的人可能都喜歡向別人抱怨。

除了發洩情緒之外,抱怨的好處可能是拉近與接收抱怨者的距離(對同樣的事不滿)。 但倘若對方對於這件事沒有不滿,或者無法同理自己的感受,抱怨可能就會讓對方產生負面的印象。

所以,抱怨的對象必須限定在「理解自己不滿」、「有類似不滿」或「可能被自己說服產生類似不滿」的人身上。

好的抱怨可能可以迅速拉近雙方距離。 但壞的抱怨就會讓大家迅速遠離自己。(不止對方,因為對方可能會把這件事傳出去)

#Complaining


輕量的評論系統 Cusdis

發布於 2022-05-28 | 最後更新時間 2022-06-18 | 分類: What I Found Interesting
  • 這兩天從 Twitter 網友 Reorx 那邊看到一個很有興趣的服務是 Cusdis
  • 他看起來是一個非常簡單輕便的網站評論系統,且主打 privacy first。
  • 我曾在「為何我不在部落格上面放評論系統?」這篇裡面寫過,我暫時不想在部落格放評論系統的原因之一是,覺得既有的評論系統介面都不好看,而且好像會拖累網站效能。
  • 但 Cusdis 看起來有機會成為那個例外,他的介面很單純,可以看他們官網的 blog 頁面如: Hello Cusdis | Cusdis Blog 。
  • 整個評論的介面跟 Disqus 比起來也相當乾淨,如下圖:
  • 我覺得好像是個值得試試看的方案,決定排入 queue 裡面,放在 umami 之後預計會想裝在部落格上面的東西。

Backlinks:

#Comment System   #Cusdis


為何我要把 Dendron 的 notes 搬回 Heptabase?

發布於 2022-05-28 | 最後更新時間 2022-05-28 | 分類: Daily Why
  • 前天晚上 Heptabase 更新到 0.143.0 版本,上線了 nested whiteboards (層級化白板、巢狀白板)的功能,這是我期待已久的重要功能,試用了一下發現體驗很好,決定把累積了快一個月的 Dendron notes 全部搬回 Heptabase。
  • 但這樣搬移的意思並不是未來就不再用 Dendron 了,而是讓流程調整一下,把原本「直接在 Dendron 撰寫 daily notes,並發布到網路上」的程序,調整成為「在 Heptabase 撰寫 daily notes ,貼到 Dendron 上,再發布到網路上」。
  • 為何要這麼做?因為 Heptabase 的功能更全面,他能滿足 Dendron 沒有的兩個功能:
    1. 把 notes 一次攤開,一起檢視
    2. 實踐在 5/17 提過的 The Compass of Zettelkasten thinking 的功能(還需要調整成我自己的版本)
  • 這兩個功能都是基於 Heptabase 的空間屬性,覺得更有助於建立連結以及進行聯想,因此在有層級化白板後,就決定這樣做了。
  • 但 Dendron 仍然在建立公開 wiki site 這件事情上扮演重要的角色,而且從 Dendron 上面學到的 hierarchy 命名概念非常實用,讓我現在在 Heptabase 裡面也透過同樣的方式來命名以及識別。
  • 一個多月沒用 Hepta ,中間有 Dendron 這樣的練習與累積真是太好了,感覺離自己的 workflow 完整體又更近了一步。

#Heptabase   #Dendron


我的純文字沒那麼純

發布於 2022-05-27 | 最後更新時間 2022-05-27 | 分類: Random Thoughts

我的純文字沒那麼純,還有用到 Logseq 這樣的大綱渲染架構,也有 Drafts 這種文字內容還是存在軟體裡的狀況。

但我覺得「沒那麼純」或許才是最好的方案,因為太純文字的話,就少了連接的便利性、少了排版架構的可視性、或者是拖曳的可互動性。

或許不該一味地推崇純文字,只要剛剛好,就好。

最好的選擇應該是那些以純文字為基底,卻能夠產生出不同變化,而且也能讓用戶保有資料、方便 export 的軟體。從這角度來看待純文字可能會更有意義一些。

#Plain Text


為何有時候問不出為什麼?

發布於 2022-05-26 | 最後更新時間 2022-05-26 | 分類: Daily Why

最近發現,有時候會想不到當天該問什麼。可能的原因是:

  • 更新速度太頻繁,目前每天都要問一個,可能太密集。
  • 我的 input 太少,在既有 routine 工作裡面沒有發現太多「為什麼」(有的則是涉及到個人或特定的事,無法公開)

可能的作法:

  • 更有意識地收集各種 why (目前已有在做,效果還不錯。
  • 把更新頻率降低,目標改成「每天至少 PO 一則 Why, What 或 How」

我覺得好像可以兩個做法並進看看!畢竟重點是無壓的輸出,如果發現某種壓力太過,可以嘗試適度降壓!

#What How Why


為何我對 Timestripe 有興趣又馬上沒興趣?

發布於 2022-05-25 | 最後更新時間 2022-05-25 | 分類: Daily Why

我好像在兩年前就註冊了 Timestripe 這個有趣的服務,但很快就不用,因為當時覺得還太不成熟。

這兩天收到 Timestripe 寄給我的促銷信,說有 20% 折扣,就跑回來看看,但一下子就放棄了,在這邊記一下原因。

有興趣的點:

  • 介面很漂亮
  • 能直覺從日、週、月、年、Life來規劃事情,並且移動任務
  • 能最直覺地察覺時間跟歲月的流逝

喪失興趣的點:

  • 中文輸入很糟,一樣會有選字的 enter 直接輸入的問題。
  • 沒有看到 export 的功能,感覺累積越多會越被綁定。

應該說,這兩個缺點,就讓我喪失探索功能、研究 workflow 的動機了。

但介面真的蠻美,附上三張圖。

第一張是我很喜歡的看板介面

第二張是「今年過了多少」的視覺化呈現

第三張是「你活了幾年」的視覺化呈現

#Timestripe


為何 Freddy 認為 SOP 是重要的?

發布於 2022-05-24 | 最後更新時間 2022-05-24 | 分類: Daily Why

今天來嘗試用點不一樣的方式寫 Daily Why。

想透過這種直接引用的方式,作為某種 Literature note 的變種,但又可以有明確的人以及主張。

這是從臉書上的 Freddy Business & Research 專頁看到的貼文

Freddy 描述的 SOP ,包含像是:

  • 怎麼分析股票和產業
  • 資料要怎麼找最快
  • 每天例行的檔案要怎麼更新
  • 聯絡人的檔案在哪
  • 常見的錯誤是什麼&如何防呆
  • 檔案命名的格式要怎麼訂
  • 檔案裡面的字型字體顏色等格式長什麼樣子
  • 這些東西,怎麼跟順利無誤地達成目標這件事結合在一起。

Freddy 認為, SOP 重要的原因是:

  • 透過結構化所知道的做事方法、態度,以及對於工作流程的洞察與拆解,可以大幅度槓桿團隊的生產力,把時間和注意力留給更有價值的事情。
  • 這過程同時也會訓練出有紀律又有長遠目標的將才。

我蠻認同這篇的想法,也一直覺得工作流程的標準化有助於提高效率

而這部分如果要歸納出下一步動作,或許可以是:

  • 想辦法去拆解自己每個常見工作的標準化流程
  • 需要去留意那些「無法標準化」的工作流程,是無法,還是自己辦不到,還是需要取決於他人?

#SOP   #Teamwork   #Productivity


為什麼我要在部落格上放電子報的備份?

發布於 2022-05-23 | 最後更新時間 2022-05-23 | 分類: Daily Why

從 4 月底開始,我在部落格上面開設了電子報的頁面,把每一期電子報的全文都放上。

為什麼我會想這樣做?最直接的原因是,SEO。

在這樣做之前,我曾嘗試在 Google 搜尋了我的 Substack 電子報內容,但發現幾乎搜不到,即使直接搜尋標題,還是看不到。

即使 Substack 上面每篇電子報都有獨立的網址,但看起來 SEO 沒做很好,所以我想要有更好的表現。

尤其我在電子報裡會分享一些特定 app 的 workflow ,或者是針對某些議題分享想法,如果這些內容都不容易被搜尋到,感覺有些可惜,所以我想要把文字放到網站上。

但也因為目的就這麼單純(希望多一個搜尋引擎的曝光機會),所以我在分享電子報到 Twitter 等平台時,還是會放上 Substack 的連結,因為這樣可以讓大家更容易訂閱。

下一個可以問的問題是,為何我要在意網站(或自己內容)的 SEO?

#Blog   #Newsletters   #SEO


如何從一個點子產生更多點子?

發布於 2022-05-22 | 最後更新時間 2022-05-22 | 分類: Daily How

The essence of the Zettelkasten method, demystified. 這篇文章裡面提到一些方法,例如針對點子 X,可以問:

  • What kind of connection am I looking for?
  • What relationships are worthy of calling a connection?
  • Do any connections work, or do some work better than others?
  • Should I categorize the connections?

對於如何解決這個問題,作者提出的方法是 5/17 分享過的 The Compass of Zettelkasten Thinking

我雖然沒有對他的問題特別有感,但覺得根據自己的狀況調整一下,應該就可以得出不錯的做法。

#Ideas