關於文件命名雜感、困擾,和悼念已經無效的插件。

交互式文件命名,根本的目的是方便檢索、用3~4個區塊產生的交集,把文檔搜索範圍縮減到最小。
如果在命名浪費太多時間,這會本末倒置,但要是沒有命名的紀律,後續浪費的時間比前面本末倒置的還更多。
如果參雜其他目的,例如:我希望日後能根據標題和文檔本身,在一定時限內(一年?)在網路上找回原出處。
所以在標題已經很克制地補充了文檔來源發文者帳號或暱稱,以及發文日期,又是2個區塊了。
照做的話,還真的能實現目的,代價就是繁瑣的步驟、積少成多的時間。
我被迫思考囤積的問題,除非上述步驟都有辦法自動地、且準確地做到。

說來感傷,直到去年八月為止,有一款twitter的瀏覽器插件,
它可以自動擷取用戶在twitter的發文、轉發、Like、Bookmark的內容,
而且文檔名稱是嚴格有條理的,帳戶名稱、發文的流水號(網址的一部份)、發文時間、我的轉發時間、圖片號碼。

我不認為這種收集行為是無效的囤積,
因為這些圖不是社群平台的推薦,那是我已經有意無意,
經由我的意志和審美主動蒐藏的內容,
它的集合絕對是社群平台推薦的子集合,且和我可能喜歡的內容至少9成重疊。
哪天自動推薦的內容索然無味,我隨時可以瀏覽我確認過的內容。

由於去年中twitter改變API的規則,該插件無法繼續工作,
時候到了就此失效。

我利用此工具自動擷取這麼多文檔,但這些收藏充其量只算半成品。
因為它有條理,我深信很久很久以後總有辦法對其進一步地整理和分類。
它們至少比命名紊亂的內容、比起書籤垃圾場(數量級遠少於此收藏)有可讀性。

就是這堆半成品,我只是完全隨意亂點,都能找到我滿意的內容,
明明只是個附帶有預覽圖片空能地解壓縮工具,本身介面中上,
搭配擷取過的、篩選過的內容,此時我的體驗比在好多地方還舒適愜意。

到此插件徹底失效之前擷取的內容,我在硬碟裡一直保留兩份位置給它們。

1 Like