是否有取代Airtable 的離線方案?可接受一定要程度彎繞的方式。

想問有沒有類似airtable,notion等呈現表格、簡易資料庫和「預覽圖片功能」的「本地表格軟件或工具」?本地的意思是,離線以後仍然可以使用,可以掌握表格的內容或檔案,類似obsidian或excel。

excel裡面也可以放置圖片,就是邊輯的時候很容易不小心按錯,導致整列圖片比例變形、消失不見。excel本地軟件有時竟然比airtable反應還慢。

anki不知道算不算,有些繁瑣。

或是乾脆利用檔案總管或圖片庫?把文字說明放在備註,利用系統自己的預覽功能、圖片庫主打的功能,解決顯示圖片的問題,但這樣繞一大圈非常憋扭。

上述硬要勉強的方式遠遠不如airtable、notion,然而airtable萬般皆好,就是免費條目數量不多、資料不在自己手上、對於隱私和備份很有疑慮。

稍微試用access,它是不錯的資料庫工具,但似乎無法同時呈現資料表中的圖片。

恐怕最后还是回到 Excel。如果只考虑 Apple 环境,也可以是 Numbers。编辑中的误操作问题,可以具体列一下是什么情况,我是预先设置了单元格格式,从未出现过编辑失误,应该只是技术细节问题。

Airtable 曾经承认,自己是一个“5% 的 Excel”(具体数字可能记错了)。如果你觉得 Airtable 好,那么很可能你需要的是离线方案就是 Excel。

Anki 就算了,它本质是一堆 HTML 网页,然后引用了外部媒体数据,不适合作为表格。

1 Like

对标 Airtable 的开源软件有 nocodb、apitable,你有大量时间折腾吗?

1 Like

主打本地化的Notion like应用好像还有有anytype、 AFFiNE,anytype试过不顺手,AFFiNE听说过没用过。

1 Like

(1) 對於蒐集保存訊息的需求很粗糙的話,大可以完全靠上網搜尋即可。
因為蒐集繁瑣的動作很耗時、又嚴重打斷瀏覽的體驗。
重複藏書、抄寫名單這件事情,很可能和重複造輪子一樣。

(2) 如果要保存什麼,一定要有所篩選。

(3) 不能小看系統的檔案總管,它本身就有預覽圖文影音、顯示metadata、檢索的功能。
再加上以檔案作為容器,在標題命名上只添加重要的訊息,
就可以找到自己想找的保存內容。

然而,airtable除了仰賴雲端的缺點,(親自製作耗時不能算缺點),
其他易用性、低代碼、極為友好的介面、放心的圖片預覽方式,
就因為這幾項關鍵優點符合個人需求,在免費用量有限的情況,我仍重度依賴它了。


這是一個簡易的範例,但是個人實際想記錄的目的沒有像植物圖鑑那樣少量。

在airtable之中,它可以換個方式顯示:


Minja 經常提到 範例應以實際情境為上 (務實不務虛),
如果我把實際情境和現成的表格拿來當範例,溝通更有效率。
但礙於隱私,我只好虛構一個假的、簡易的表格作為範例。

這是 excel中一個虛構的表格

螢幕擷取畫面 2024-01-19 181457

螢幕擷取畫面 2024-01-19 181507

螢幕擷取畫面 2024-01-19 181518

如果在airtable上,會變成這樣:

1 Like

在现有技术的限制下,首先需要考虑是否以图片为本位。

我有个设计素材参考数据库(为避免泄漏个人收藏,随手用 Apple 的产品做了一示例),就是直接使用普通的文档管理工具,在列表视图和图标视图之间切换,效果类似你的图片。在这个例子中,图片是首要的、不可替代的。

而在另一个例子中,我有一个 Apple 产品价格表,其中的产品配图不是重点,重点是价格涨跌和各渠道的差价,图片变糊、扭曲甚至遗失都不是大问题。不以图片为主角时,工具就不那么挑剔了。

1 Like

(1)「以誰為本位、什麼內容是主體」 是優先考慮的問題

a. 圖片為本位,知名景點或建築物為主體,拍攝者作為重要的文字訊息

(2) 過於瑣碎精細的標籤、描述特徵的詞彙,暫時(極可能一輩子)放棄在文檔管理上實現了。即使做得成,也是浪費生命。

到這一步,排除無用功。


(3-1) 標題名稱長度有限,而且在這之前,
(3-2) 人眼能接收的文字長度,比電腦訊息先天規格限制更有限
(3-3) 介面顯示的有限,也是最嚴重的問題。直白地說,螢幕就這麼大,欄位就這麼寬。

關鍵問題在於,關連到這個文檔的、參與到這個文檔的人事物,組合再一起就名稱過長,還真無法簡略。

類似於日本輕小說標題的歪風,都快變成用段落來命名作品了。


(4) 維持取得文檔時的命名、和按照個人需求隨意命名之間的矛盾
(4-1) 維持來源時命名的樣子,雖然極為冗長,但蘊藏的訊息量至少比輕小說標題有用得多。
(4-2) 因為按照個人需求亂改簡稱,先不說日後這個簡稱拿到網路上很難搜尋到
最初的結果,這個自己的簡稱完全只適用於自己(或一小群人)管理的文檔系統,當然這像缺點有時候根本不造成問題,是,又怎樣?
除非,遇到最糟糕的處置方式,連自己都忘記隨意命名的簡稱。

不要小看1個小動作的折騰,
不要小看1個小動作的折騰,
不要小看1個小動作的折騰,
Label標籤這麼方便,一個文檔給3個Label就已經很過分了,
要拿捏準確度和檢索的耗時,文檔命名的藝術沒想像中那麼容易。


(a) 帳號是值得保留的訊息,長度不長,最看重的是對應到一個人或團體,放在標題中任意位置都可以。
(b) 可以的話,具有意義的日期應該出現在標題中。

标签只是临时的辅助。最后都是要干掉的。

当你“内化”了标签以及其他辅助工具,理想情况下,一段时间后你将有一套系统,最终你可以通过名称定位,而不需要冗长的描述,尤其不必照抄原始名称。古人制作草木图鉴的历史,或许有参考价值。

1 Like