背景
功能需求
- 如題所示,這篇筆記是針對這些年來筆記系統的數位發展與個人的使用經驗心得。先就筆記系統的重要元件及功能要求、條例如下:
- 介面
- 容易操作、容易上手、軟體介面親人性
- 中文化輸入、輸出
- 有簡潔的顯示版面,最好可以直接展示、用在簡報、教學,不必另外做ppt檔案。
- 項目符號、自動排序
- 是否接受手寫辨識,要按使用者手寫工整程度而定。
- 索引系統
- 目錄系統:文章內、外;無限制、多層次目錄;目錄要能展開、合併
- 時間標籤:文件創始、文件修改日期時間
- 跨檔全文搜尋、置換、關鍵字索引系統
- 圖、表、公式、(程式碼)、索引系統
- (再)訪問次數記錄
- 儲存、分享、透明度管理
- 雲端儲存、異地備援、版本管理。
- 團隊協作時易於分享、URL不能是長亂碼。
- 檔案格式容易轉移、修改。
- 品牌、系列
- 系統持續更新。不更新的棄養軟體趁早轉換,然而更新速度如果太快也很干擾。
- 市佔高、主流化
- 系列其他產品功能
- 介面
- 筆記系統不是…(不能取代…):
- 隨手速記、概念手記、無法分享的手札
- 特殊目的的便利貼app,如記帳、行程約會日誌、
- 完整功能的KM系統、教學平台
網路介紹文章
- 要每年寫這種回顧性的文章不容易,畢竟軟體的領域日新月異、江山代有才人出。
- 筆記系統之比較@wikipedia,這篇是英文更新到2023/9/29,有簡略的中文版。
- 2022筆記軟體
- 2021年7大實用筆記軟體推薦
本文主打方案
- 經過近一年的發展,目前VSCode+GitHubDesktop方案已漸趨穩定,適用在程式說明、文獻回顧等領域,有其值得推薦之處。
- VS Code與GitHub的連結
- VS Code除了編輯本地檔案之外,也能存取雲端GitHub內容。
- 在VS Code內直接進行GitHub的存取,詳見CoderDave: How To Use GitHub with Visual Studio Code,GitHub VSCode showtime,
- 也可經由本地安裝的GitHub DeskTop來存取GitHub。
-
使用github pages的免費服務資源,作為公開發布筆記之平台。
- GitHub也提供了網路版的VS Code介面,只需要在Repository畫面下按下鍵盤“.”。
- VS Code除了編輯本地檔案之外,也能存取雲端GitHub內容。
- 整體作業流程(如果圖形無法顯示請看這裡)
graph LR
A(LocalFileSystem) -- File/Dir. Create/Open/ --> B((VS Code-Local))
B -- Edit/Remove/Save --> A
C((GitHub DeskTop-Local)) -- Open --> B
C -- push --> D(GitHub Repositories)
D -- clone/pull --> C
D -- build --> E(github pages)
D -- invoke -->F((VS Code web)) -- edit/save --> D
MS word/ppt/exls as note editors
- 對於不想面對複雜軟體介面的使用者而言,在日常作業環境中就能滿足筆記需求的軟體,似乎是最好與最後的方案。
- 如果這些日常作業軟體功能都還有很多尚待熟悉,使用其他專業軟體似乎就有點捨近求遠了。
- 例如最常用來作為README、release note檔案的格式,其實是
.txt
,這是迄今每個程式發布時最常用到的格式。簡單的wordpad、小作家、vim就能達到寫作這類筆記的功能。
- 例如最常用來作為README、release note檔案的格式,其實是
- 此處介紹3種常用軟體作為筆記系統的實例。
MS Word
- 筆記寫完馬上就可以印出來、繳交課堂作業,豈不一石兩鳥,這是學生喜歡使用MS Word來做學習筆記的理由,可以參考這篇百萬瀏覽(同時也是first search)的影片介紹,以及痞客邦的中文介紹。MS Word作為筆記系統的強項與問題討論如下。
- 目錄系統(Category)
- Word檔寫完、執行一下參照,就可以更新文件的章節與編號系統,雖然是半自動作業,但對複雜的章節系統來說,已經是非常方便的功能了。
- Category可以插在文章之前或最後,讓使用者自行瀏覽查詢、翻閱。可惜:
- 目錄不能很方便的合併、展開,對多層次的目錄系統而言,要翻好幾頁才能找到所要去的位置,是個龐雜混亂的經驗。
- 沒法很方便的回到目錄、類似browser的回到上一頁(<-);再者,
- 要打開文件才能看到文件的章節,這對跨文件、循目錄搜尋的過程,也是非常消耗記憶體的動作。
- 跨平台轉換時,目錄參照不保證能順利轉換,這對龐雜的文件而言,會是個災難。這對使用者持續發展其筆記系統而言,是逐漸走向災難與滅亡的歷程,應趁早有所醒悟與合理的替代。
- 註腳、章節附註、參考文獻
- Word的註腳參照是個優秀的功能,除了正式的參考文獻之外,也能將重要的註釋、連結訊息等等,都放在這個區塊內,讀者可以追蹤相關訊息、並且不會干擾本文的閱讀。編號也是自動排序,不必擔心插入刪減之後會跳號。如果將太過細節的訊息(檔案目錄、縮寫全名、名詞解釋或定義、法規摘錄等等)放在註腳之內,對讀者來說,會輕鬆很多。搜尋時,word也會搜尋註腳內容。仍可以挑剔的是:
- 轉檔過程註腳參照、連結等有可能會消失
- 註腳篇幅太多會壓縮本文。註腳不是鼠標懸停(mouse hover)呈現方式。
- Word的註腳參照是個優秀的功能,除了正式的參考文獻之外,也能將重要的註釋、連結訊息等等,都放在這個區塊內,讀者可以追蹤相關訊息、並且不會干擾本文的閱讀。編號也是自動排序,不必擔心插入刪減之後會跳號。如果將太過細節的訊息(檔案目錄、縮寫全名、名詞解釋或定義、法規摘錄等等)放在註腳之內,對讀者來說,會輕鬆很多。搜尋時,word也會搜尋註腳內容。仍可以挑剔的是:
- 圖表參照
- word的圖表參照對圖表很多的複雜報告,是一項省時省力的功能。word早先發展了圖檔隨文儲存的作法,不單讓檔案容量倍增,也寵壞了使用者圖檔管理的習慣,好在是提供了參照系統,讓使用者的圖檔管理不會失控。這項功能不利於日常筆記的理由:
- 圖檔並不是文字搜尋的對象,圖檔龐大的word檔案要進行跨文搜尋,會浪費大量記憶體於開關檔案的時間。這不符合一般KM系統、部落格、網頁檔案管理的概念。
- 筆記系統的關鍵在單純、獨立,圖表也是以精簡、必要性為原則,參照似乎沒有太大的幫助,好的圖名、圖說反而是有利搜尋的作法,而不是參照連結。況且,
- 在轉檔發布時,參照可能會消失,還是需要一一重建。
- word的圖表參照對圖表很多的複雜報告,是一項省時省力的功能。word早先發展了圖檔隨文儲存的作法,不單讓檔案容量倍增,也寵壞了使用者圖檔管理的習慣,好在是提供了參照系統,讓使用者的圖檔管理不會失控。這項功能不利於日常筆記的理由:
- 註解:
- Word可以提供右側欄位讓使用者撰寫註釋、修改歷程等等訊息,這在協作過程有非常優秀的表現(中文介紹)。
- 壞處是此類註釋無法關閉。當註釋、批示太多時,會嚴重干擾到本文的閱讀。這是何以正式文件會以頁面、章節之後的註腳來寫註釋的理由,wiki等等電子文件則是以連結(hyperlink)、或鼠標懸停(mouse hover)來呈現註解。
- 大綱模式
- 筆記系統與正式文件之間最大的差異就是文件的格式,後者有較嚴格、容易閱讀(不利查找)的版面格式,為此Word提供了大綱模式、預覽模式、整頁模式等等閱讀顯示方式,其中大綱模式對撰寫文章時、可以快速瀏覽剛剛寫好的段落,讓段落語意保持順暢,是非常方便的介面。大綱模式的章節升降調整功能,對文章的整理也是非常方便。這麼優秀的功能,還是有別的軟體來挑戰競爭:
- 不能同時以不同視窗顯示2種顯示模式,必須寫一段落、切換模式來加以檢查。這在插入圖表時,需要看圖表撰寫討論時,會是個打斷思路的重大瓶頸。
- 大綱模式下的字型、整體畫面(版面)太過粗糙,讓人望之卻步,雖然只是用做筆記系統的界面,但應該還有更好的選擇。
- 筆記系統與正式文件之間最大的差異就是文件的格式,後者有較嚴格、容易閱讀(不利查找)的版面格式,為此Word提供了大綱模式、預覽模式、整頁模式等等閱讀顯示方式,其中大綱模式對撰寫文章時、可以快速瀏覽剛剛寫好的段落,讓段落語意保持順暢,是非常方便的介面。大綱模式的章節升降調整功能,對文章的整理也是非常方便。這麼優秀的功能,還是有別的軟體來挑戰競爭:
- 分享與發布
- 除了列印成書面輸出,Word還能存成pdf檔案、rtf檔案、html網頁、特定部落格(WordPress、SharePoint、TypePad、Telligent Community)等等方式,可供發布。如果有好的發布平台,如KM系統、文件管理系統DMS,對文件的版本、公開對象、內容摘要等等有進一步的管理,pdf及rtf檔案會是不錯的組合。
- 讀者如果要參與協作,很難全抄修改、需要另外的協作系統。
- html結果非常不理想。是個連官方都棄養的功能。
- 大多數的部落客並不使用word內的直接發布,除了格式的問題,主要還有圖檔管理的問題。一般網頁的圖文是分開管理,並不是隨文附圖的概念。(參考傑哥架站教室2022,高效寫作部落格文章的6個技巧)
- 如果沒有好的KM或DMS,發布檔案對讀者來說會有嚴重的版本管理問題。
- 除了列印成書面輸出,Word還能存成pdf檔案、rtf檔案、html網頁、特定部落格(WordPress、SharePoint、TypePad、Telligent Community)等等方式,可供發布。如果有好的發布平台,如KM系統、文件管理系統DMS,對文件的版本、公開對象、內容摘要等等有進一步的管理,pdf及rtf檔案會是不錯的組合。
- 其他word問題
- 一般word檔案(報告)會隨著計畫儲存備份,有開案結案的時間、有良好的管理。但是筆記卻是跨計畫、技術核心的屬性,無法隨每個計畫儲存,這是報告、筆記這2類文件最大的差異。
- 項目序號更新偶爾會不靈
- 程式碼的縮排:容易出錯
- 跨文搜尋:非常慢
- 字型、格式:無法在每台電腦都保持一致
- 分享發布的形式就是直接複製檔案,沒有版本管理、沒有更新日期管理、沒有同步功能。
MS PowerPoint
- 這裡提的不是筆記軟體輸出到ppt、或者在筆記軟體中輸入ppt檔案進行編輯加工,而是直接使用ppt作為跨計畫的筆記檔案格式。
- ppt檔案的條例大綱寫法,跟筆記形式很接近,同時在備忘稿,可以提供類似註腳的功能,將詳細的連結、參考文獻、細節訊息等等,都放在此處,待日後或其他讀者進一步追蹤查詢。此外不同視窗可以同時寫筆記、看圖表,這是非常有助寫作的功能。這些是ppt作為筆記檔案格式的強項。
- 其他跟word類似的強項是
- 筆記與重要圖表整理好,隨時可以簡報、不用另外花時間做簡報。
- 每頁投影片標題、次標題等,會自動彙整到大綱模式,雖然也沒有合併、展開的功能。
- 除了文件外連結,也提供文件內、不同頁面的連結參照。
- 本文、備忘稿、都能快速搜尋
- 缺點:
- ppt基本上不是個完整的編輯軟體,而是單一頁面、專為投影片使用的界面。如果內容超出單頁範圍,編輯起來會很辛苦。筆記的編寫往往會有增減頁面的情況,這是最不利的衝突點。
- 備忘稿不是ppt的主要功能,的它界面不是最優秀的設計,雖然也有些格式設定,但還是很簡略。
- 發布分享、文件管理的問題,與word一樣。
- 沒有人用ppt的備忘稿來寫程式說明文件、至少筆者沒有嘗試、也沒有成功經驗。
MS Excel
- 筆者曾經使用excel來記錄常用的unix指令、使用方法、範例、心得與自製小工具(如unix.csv、unix_kbin)。
- 好處
- 隨意排序、搜尋快速、一覽無遺
- 檔案不大、方便更新。容易傳遞。
- 檔案留在桌面上方便開啟
- 不足之處
- 範例太少、說明文字太少、難以編輯、儲存格內不方便製作多個超連結、(別人看不懂)
- 開啟excel太慢,還不如直接搜尋網路。
- 發布、共筆、版本管理…:無此等功能
VS Code簡介
VS Code是什麼
為何需要VS Code(特色與必須性)
- 與GitHub平台完全融合、持續共同發展
- 多種語言自動編譯、執行、預覽。標記式語言(MarkDown)及插件之解析、預覽。
- 快速跨檔案搜尋、置換
- 低度記憶體使用,以iMac平台而言,開啟Page需要200MB,開啟VS Code只需60MB。
- 跨越平台:MS Window、Mac OS、Linux、Web Service(與MS Window有最好的相容性)
VS Code的使用
- 複製(下拉)遠端Repo
- 創建本地資料夾與檔案
- 檔案與目錄之上傳更新
- Repo全文搜尋、置換
- 標記式語言(MarkDown)之解析、預覽
- 插件安裝
VS Code的充分特性
- 熟悉程式發展作業環境,逐步學習程式語言,工作成果、工具數位化、模式化。
- 與全球優秀資訊人員同步發展
GitHub簡介
- 雖然GitHub平台大量提供了有關程式碼的支援,包括版本管理、協作系統、論壇、以及程式說明的發布網站(github pages)等等,但也有不少人運用在一般性網誌的發布、程式教學的互動平台。
- 因為是社群媒體網站,發布內容還是以社群可能會有興趣的項目為主。
- 各國官方程式碼的公開平台,很多也是選擇在GitHub發布,其中包括美國環保署、大氣研究聯盟等等。
- 除了github pages之外,也開發了Git Book系統,免費提供讓個人使用,讓使用者可以發布整本書的內容。
GitHub的使用
參見[[2022-11-10-code_ug]]
- 登錄會員
- 創建新的目錄(Repository)、設定開放對象、複製網址(假設名稱為notes)
- 貼在本地GitHub DeskTop、創建本地相對應目錄
- 開啟VS Code進行檔案或目錄新增、編寫
- 上推至GitHub
公開網頁github pages之創建
- 點進前述步驟2.所建立的GitHub notes目錄
- 按下齒輪 Settings頁面,在左側點進Pages頁面,選擇一個分支(branch)名稱,如main
,並在root處鍵入新io網頁的名稱(如
docs
),按下save之後,系統將會建立https://USERNAME.github.io/notes 網頁 - 複製網頁模版到本地暫存目錄、貼到本地Repository目錄,將所有個別帳戶名稱處都修改成正確的url,再將其上推至GitHub。
- GitHub將會自行將md碼編譯成html,建立相對應的網頁。
- 如果前述notes目錄不打算公開,就不必(也不能)設定github pages
- 詳參Just the Docs
github pages模版之選擇
- 參考jekyll主題版本比較評估,以JTD與TeXt較為合用。
本地git界面的選擇
- git作為是遠端與本地檔案及版本管理的程式,可以在任何unix-like界面、window命令列上執行,同時也有多個界面軟體可供選擇。如(參DEVART, 2021, Best Git GUI Clients for Windows):
- GitHub Desktop
- 其他GUI Clients tools
- SmartGit
- 選擇GitHub Desktop的理由
GitHub的缺點
- .md檔案可以直接在Repository中呈現,但在公開的Github Pages上呈現會需要編譯部署的時間,複雜的系統可能會花費到5 ~ 10 分鐘以上。
- 下班時間公司會關閉GitHub部分功能、不能進行檔案更新上載。對於長時間工作的程式發展者而言是項嚴重的限制。
標記式(MarkDown)語言
- 標記式(MarkDown)語言是讓文件在各個平台都能保持彈性、並且呈現出相同格式的重要語言。如果要讓筆記軟體不佔據大量的記憶體、又能呈現必要的文件格式,會需要較文字檔
.txt
略為複雜、又比.doc
、.rtf
等特殊軟體格式簡略一些的文件檔案格式。 - 這些格式包括
- 章節標題(用井字號#的個數定義層級)
- 項目符號(-或*)、序號(1.)
- quote或程式碼,以三個引號起訖
- 字型:以1 ~ 3個星號起訖,來呈現斜體、粗體、粗斜體等
- 連結[ ]( )、註釋引用[ ][ ],註釋內容 [ ]: < url> “content”
- 圖形、表格等
- 公式
- 使用範例詳wiki 、Mac範例、markdown math 数学公式语法
- 玉樹芝蘭2017,如何用Markdown寫(學術)論文?
使用經驗與評論
- 此處討論對象以完整的筆記軟體系統(editor+filesystem)為主,前述僅半套的word/ppt作法則不予列表討論。
主要筆記軟體
Evernote
- 使用時間最長、也成為付費會員,現停止付費,仍然使用中。
- 但後來因為對程式碼太不友善、且網路更新速度超慢、分享網站是長串隨機碼,看了許多付費網友紛紛解約,也就不再維護了。
ios APPs
- GoodNotes用在ipad上看報告、改報告很好用,但隨著筆者公司職務的調動不再需要改報告,硬體也沒有持續更新,在iPad平台上就沒有持續發展。
- 值得一提的是noteshelf在手寫界面軟體中有非常優秀的表現,其他iPad平台上的應用比較,可以看知乎這一篇。
notion
使用經驗評論列表
項目 | Evernote | notion | boostnote | GoodNotes | VSCode+GitHub |
---|---|---|---|---|---|
本地記憶體需求 | >1G | >200M | <100M | ~ | <120M |
網頁界面 | 有 | 有 | 有 | 無 | 有 |
離線開啟 | 可 | 否 | 否 | 可 | 可 |
目錄系統 | 無 | 二層 | 二層 | 無 | 無限制 |
跨檔案搜尋 | 快 | 快 | 搜尋完整字 | 慢 | 快 |
儲存檔案格式 | 自訂 | md | md | md | |
手寫辨識 | 無 | 無 | 有 | 無 | 無 |
程式碼 | 縮排會亂掉 | OK | OK | 無 | OK |
費用 | 付費可存3機器以上 | 付費多存 | 5~8 USD/月 | 付費app | 免 |
url發布 | 長串隨機碼 | 長串隨機碼 | 可轉html檔 | 無 | 指定目錄 |
索引系統 | HPL | HPL | HPL | 無 | HPL、ref.、Fig. |
流程圖 | 無 | 無 | 無 | 手繪 | mermaid |
公式 | 圖形 | 無 | 無 | 手寫 | 有 |
IDE | n | n | n | n | yes |
- md:markdown
- HPL:hyperlinks
VS Code安裝使用
- 詳見另文
- 針對筆記內容如果以Markdown語言撰寫,VS Code提供了哪些特別能提高編寫效率的功能(VS Code提供Markdown語言的功能)