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

發布於 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


Moby Dick Workout

發布於 2022-05-22 | 最後更新時間 2022-05-22 | 分類: What I Found Interesting

這是推友推薦,在 Bike 的作者 Jesse Grosjean 的網站上看到的文章,或者說一種測試方法,覺得非常有趣。

Moby Dick 是白鯨記,而 Grossjean 這個測試方法,就是拿白鯨記的完整文字檔,來測試筆記軟體或文字編輯器的效能。

具體的測試方法是,透過想測試的軟體打開或 import Moby Dick 檔案(有分 opml 格式以及 .md 格式),然後測試看看下列動作:

  1. 打開它,快嗎?
  2. 滾動到底部,調整視窗大小,快嗎?
  3. 再滾動到中段,調整視窗大小,快嗎?
  4. 全選文字,剪下、貼上、undo、redo,你的 app 還行嗎?
  5. 在文章中段編輯一些內容,是否會 lag?是否會卡頓?
  6. 重複測試步驟 2-5 直到你滿意為止,然後打開 macOS 的 Activity Monitor,看看記憶體的用量你是否滿意。

我嘗試用這個方法測試了 Logseq ,發現,效能不太好。

而 Bike 的效能則是非常好,運行這一些動作都很滑順流暢。這也是最後決定實際用用看 Bike 的原因之一,速度快,真的是很大的優點。

#Bike   #Logseq   #Testing


為何我不在部落格上面放評論系統?

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

過往透過 Wordpress 維持個人網站時,有內建的評論系統,可以選擇要不要打開讓讀者留言。

但自從轉換到 Zola 後,我不再放置評論系統了,為什麼?

第一個原因是,我覺得評論系統的介面都不好看,會破壞整體的閱讀感受。 第二個原因是,評論系統好像會讓網站的 Pagespeed 評分變差,既然目前網站有很好的評分,我不想要變差。 第三個原因是,對於部落格這樣比較成熟、完整的文字,我好像也同樣期待完整一點的討論與回饋,而這些完全可以透過 email 來進行。

這些原因讓我暫時不想去找評論系統的解決方案,但也許未來會改變心意也說不定吧。

#Blog   #Comment System


What 是通往 Why 的捷徑嗎?

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

因為每天給自己設定的最小目標是「一定要想一個 Why」,但有時還是會卡關。卡住的點是想不到今天想問什麼。

但我發現好像有種很容易問 why 的方式是,基於 "what" 的問題去問 why 。

例如,這幾天可能在研究 Bike, umami, Dendron 等產品,除了可以問這些東西是什麼以外,也可以問,為何要發明這個東西?他想解決的是什麼問題?

不過這類的 Why 不是在問我自己,而是在問這些產品的創造人以及團隊。所以如果可以,或許我該先自己猜測看看,這樣也可以訓練自己的觀察力吧?

#What How Why


為何值得投注時間維護個人 wiki ?

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

時間是珍稀的資源,為何要花在建立以及維護個人 wiki 上?

我覺得這件事會有複利的效果,當自己的想法持續累積,並且有良好的機制來引用、重組、展示時,對內能提高自己的思考品質以及提問的能力,對外也有機會累積一個持續學習與分享的好形象。

#Personal Wiki


嘗試開始使用 Bike

發布於 2022-05-20 | 最後更新時間 2022-05-20 | 分類: What I Tried Today

今天開始嘗試使用前天提到的大綱軟體 Bike

我的用法是,把它當成我的簡單 MOC ,或者說 wiki 的快速目錄,把曾在 wiki 這邊寫過 daily journal 都記下來,但不再透過日期排序,而是手動將他們分類。

最直接的體驗是: Bike 真的是快,用起來很絲滑順暢,有很好的體驗。

另一個優點是,把一串文字直接暴力貼上時, Bike 的分段效果很好,能夠直接依照斷行區分,接著只要稍微縮排一下就好。這剛好很符合我「剪貼過去再微調」的需求。

相較之下,若同樣把文字貼在 Workflowy ,就會全部擠在一起。(Logseq 的表現也是好的)

不過 Bike 目前的功能太少,而且不支援 markdown 真的是有點可惜。

就再用用看吧!

#Bike


為什麼我想嘗試 umami ?

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

umami 是一個主打簡單兼顧隱私的數據分析工具。

我是從 Open Source Alternatives to Proprietary Software 這個網站發現他的,當時因為看到 Brian Lovin 在他的網站上提到他在分析數據方面從 Google Analytics 搬家到 Fathom 這個工具上,因此開始研究他為何要從 GA 搬走? Fathom 是什麼?

但當時看到 Fathom 並沒有免費版的方案,最便宜的方案要 14 美金一個月,我覺得太貴,所以放棄。

因此看到 umami 標榜不用付費,就產生了一些興趣。

仔細看了官網後也發現,他的介面很簡單,但該有的好像都有,例如:

  • 流量都在哪個頁面
  • 從哪個地方來?
  • 瀏覽器以及作業系統
  • 平均停留的時間
  • 觀看次數

我好像也只需要知道這些就夠了。

因此如果要回答這個 why ,答案應該是: Google Analytics 的功能太多太複雜,使用起來很臃腫,我用不到這麼多功能,因此想嘗試別的方案,而 umami 不僅看起來簡單夠用,也夠便宜,所以我想嘗試看看。

至於隱私也是一個考量,如果可以,我只想知道大家在我的內容上的瀏覽時間以及次數,這對我來講是判斷哪些內容對大家有價值的方式之一。


Backlinks:

#Umami   #Google Analytics


為何呼籲別人理性很危險?

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

通常被呼籲的人,只會有「被指責不理性」的感覺,即使事實確實如此,但這種「被指責感」很容易引起不悅。

這可能是因為理性的對面可能是「感性」,也可能是「不理性」,這就容易造成潛在被呼籲對象自行帶入「不理性」這個對立面。

而「理性」這個詞也過於模糊,很難作為明確的行動指引。 相較之下,呼籲別人「要禮貌」,大家就比較好想像「禮貌」是怎樣,也可以去想像「自己是否不禮貌、是否粗魯」。(當然,這樣的呼籲還是會有點危險)

該怎麼做可能更好?

若是公眾人物對大眾,那可以提出更明確的行動指引來呼籲大家。 若是對身邊的人呼籲,那可能也不該呼籲,而是應該直面對方令自己不滿的地方去提出建議與改善方法吧。

#Rational