Logseqについて、あらためて考えたい
こんにちは。前回の記事で 新しいLogseq db版(データベース)について書きました。(https://note.com/p510hv/n/nbc18227893ce)
実際にdb版に移行するとなると、使い方などの変化に適応しなくてはいけません。それで自分自身も「これからもLogseqを使うべきなのか」と改めて思うところがあります。
新しくなれば便利になる部分が多いのですが、
ほかにも多くのソフトウェア・アプリがあって、それらとどう違うのか、
そして何がよくて何を使いたくて、今Logseqを使っているのか
を考える必要があるなと思い、考え直すために、まとめて書き出してみたのでここに載せます。
Logseqの魅力と課題
情報を文脈に基づいて整理するのがLogseq
Logseqは、情報を文脈に基づいて整理し、リンク付けしてログとして扱う機能が主体となっています。
優れている点
アウトライナー式
ブロック(箇条書き)で書く
ブロックをインデントすると、階層構造になる。
思考を視覚的に構造化できる。
ブロック単位の操作
あとから部分的に文章の入れ替えが可能。(「・」をドラッグして移動)
ネットワーク・リンク型
基本的には、ブロック内で編集中にリンクを作成して情報をつなぐ。
ページに直接ではなく、ジャーナルに書き溜めていくような使い方ができる。
あとでページのLinked References(ログ)を見ながら、正式に自分のノートとしてまとめるやり方がある。
ジャーナル
その日のページが自動生成される。日々の自分の活動を1日ごとに記録していく。
ただし、書きたくない日もファイルが生成されてしまう ★要改善箇所
1ページずつではなく、下にスクロールして、数日分チェックできる。
タスクも扱える
一般的なタスク管理アプリとは異なり、文章メインのタスクを処理するのに向いている。
何かを考えてタスクが発生するため、その過程で生じた「思考やその文脈と結びづけて、タスクを扱いたい」場合に適している。
無料かつローカル
無料で使えて、ローカル上にファイルを置ける。
不便なところ
Logseqを使い込むほど動作が重くなる。
リンクが多くなるとLinked Refrencesが使いにくくなる。
バグがとても多い。
ブロックやページの作成日と更新日を保持できないバグがあるため、時系列で確認できない。
プラグインは大量にあるが、バグが残ったままのものも多い。
ブロック埋め込みなどを使った場合、なんらかの不具合で無効になってしまうバグがあり、uuidというブロックを特定するキー番号がマークダウンにそのまま残ってしまうことがある
基本設計
エディターとしてのアウトライナー式の欠点
ブロック(箇条書き)で書くのが常にデフォルトであり、文章が分断しやすいため、長い文章の記述に向かない。
文章内での改行も可能だが、前後の箇条書きに挟まれて、見た目のバランスがあまり良くない。
ネットワーク・リンク型としてのデメリット
すべてのページが、ルート(初期地点)に存在する
ページの階層構造(Hierarchy)を作れるが、実態としてはルート上に存在する
ページ名に階層が含まれていると、ページ名が非常に長くなってしまう。
ファイルの階層構造を作成できない
安定したファイルの同期機能がない。
ほかのアプリにあるようなプロパティの扱いは困難。
プロパティの使用は、入力中のサジェストくらいで、特定のオブジェクトデータを持たせる機能はほとんどない
マークダウンでありつつ、Logseqでしか使わない記述も .mdファイルに残されてしまう
db版で改善されること
全体的に、動作が軽くなる。
ブロックでの編集操作のほか、ページ、クエリー(Linked Referencesなども含め)、ホワイトボードなどの読み込みも速くなる
グラフにページが多くなっても重くなりにくい
ページに対して Class 型を指定でき、ページの分類やプロパティの再利用が可能になる
Class 型の画面にもLinked Referencesが用意される
コンテンツのないページを減らせる
プロパティの改良
タスクの状態(TODO、NOW)などをユーザーが変更できるようになる
プロパティの指定が、「選択肢から選ぶ方法」に代わる
すべてのページやブロックに対して、作成日や更新日の日付情報が正確に付与されるようになる
たとえば、今日作成・編集したページあるいはブロックの一覧など、日付に基づく履歴を閲覧できるようになる
(プラグインもしくは標準機能にて)各ページを開いたときに、作成日や更新日を表示できる
純粋なマークダウンとしてのエクスポート機能が用意される見込み
db版で廃止される可能性がある機能
Hierarchy (= 階層)ページ名を「/」で区切ると、親ページにリンクされる
Namespace (= 名前空間)同じ階層にあるページ (共通のトピックをもつページ)
同じトピック名のページ
db版でも残る課題
細かい使い勝手に対する標準性能が高くない
右サイドバーが使いにくい。
複数のページを開くには、サイドバーを使う必要があるが、操作性が良くない。
Obsidianの「ペイン」とは異なり、サイズや位置の調整ができない
文章量の多いページでは見にくくなる
スクロールしないで済む範囲であればよいが、たくさんスクロールしないといけないようなページをどう扱うべきか悩ましい
あくまで「ログである」と考えれば、それはそのままでよいかもしれない
マークダウンヘッダーで分割する方法があるが、標準ではヘッダーの目次機能が存在しない ★要改善箇所
リンクが多くなるとLinked Refrencesが使いにくくなる。
Linked Refrencesに表示されるブロックの件数が数十件、数百件、親ページだと千件以上になってしまうケースがある
Class 型でも同じことが起きてしまいそうな予感
ワークフロー
何かについて「時期ごとに、同じことに対してページを作成して文章をまとめたい場合」にどうすればよいか が定まっていない
ジャーナル
任意の日付ページに移動できない
プラグインを入れないとカレンダーが使えない
たとえば、一週間分を同時に見ることはできない
サイドバー上では開けたとしても見づらい
1日単位のためのページしか生成されない
Logseqで満足できるかどうか
Logseqでは、ノートと呼ばずに「ページ」と呼ぶが、ページ内の文章全体ではなく、ブロックの集合体がページコンテンツを構成しているため、Webページを作っている感覚に近い。
「日々の記録、経験したことや知見などのログを残すため」にツールを使いたい人に向いている。
結果的にはLogseqという名前のとおり、記録ログとして見つける(seek)ことができればいい、という考え方が一番適している。