原稿を書く水曜日

8:00

おはようございます。本日はもろもろの原稿作業です。

Textbox:

さて、画像を共有したいのですが、どうしましょうかね。

スクショ

Knowledge Walkers用のimageフォルダにアップロードしてそのURLを使うことにしました。そもそもimgタグがアップロード時に消失していますね。それが問題だったのかもしれません。hugoの変換で消されているのかも。

とりあえずテストとして、Textboxにフロントマターのtypeで絞り込めるボタンを付けました。これまでは、検索ボックスにフォーカスしたらプルダウンで一覧メニューが出てくる形ですが、そのデータを利用してボタン化したものです。

これで特定のグループを一覧させることが容易くなったと思います。あとは、カード一覧形式以外の表示、具体的にはタイムライン(あるいはCosenseのstream)のように縦に一列に表示させる形です。

9:00

メルマガ:

あと、1000字ほど残りがあるので、どうするのか考えましょう。

* * *

1300文字ほどの原稿を書きました。これで本編はOKです。

ブックカタリスト:

アガサ・クリスティーのリスト - BCBookReadingCircle

読書会で話題が上がっていたのでページを作りました。

10:00

note:

記事を書きましょう。

* * *

publish:ちょっとした工夫で良いんです|倉下忠憲

11:00

Textbox:

Lifelog的なものをどう扱うかずっと考えていました。方策は三つです。

現状のnotes/に入れた状態にして、type:lifelogをつける。その際、lifelog/レシピ、のように記述にサブタイプを含められるようにし、それによって親だけ、子だけの集合を作れるようにする。これが一つ目。

次に、lifelog/というフォルダーを作り、そこに集める。その際は、type:lifelogは不要になる(フォルダが名前空間を担保しているから)。代わりに、type:レシピ、などを与える。現状はそれがボタンとなって上部にならび、切り分けができる。これが二つ目。

最後に、一つ上にlifelog/をつくる。これはbooks/やclips/などと同じレベルであり、一つのアプリの単位と同じ。つまりTextboxの兄弟項目としてつくる。こうすると、既存のtextboxの仕組みはすべて使えなくなるかわりに、まったく新しいindex.htmlをデザインできる。つまりノートツールのUI経験ではなくライフログ用ツールを新しくデザインできる。

この三つのうちどの方策を採用するのかを考えていました。で、それぞれには当然一長一短あるわけですが、ポイントは私がライフログ的なものをどこまで「特別なもの」として扱いたいのか、というニーズです。

さほど特別でないならば、notes/に入れて他のノートと混ぜておけばよいでしょう。これは、ほぼ日手帳に予定と日記を混ぜて書くのに似ています。一方でものすごく特別なら新しいアプリ単位でlifelog/を作り、専用のindex.htmlを設計します。これはアナログでは「アルバム」を新しく買ってくるようなものです。

その中間が、textbox/lifelog/を創るというもの。

どれが正解というのはないですし、ある部分で効率化されれば別の部分で非効率になるというトレードオフは必ず存在しています。だから、「効率的かどうか」で考えているのでは判断がつきません。自分のニーズはどういうところにあるのかを見極める必要があります。

* * *

Evernoteの頃から「一ヶ所に何でも集める」が基本的な方針で、単に利便性以上にいろいろなものが一つのスペースに並んでいる雑多さが気に入っていたように思う。それ以降のツールにおいても、同様の使い方をしてきた。

一方でそれは、一つのツールに多機能を求めるか、個別の情報の扱いをややおざなりにすることのどちらかになっていたようにも思う。Evernoteなんてまさにそうだろうし、Obsidianでもやはり限界がある。

こういうのを「コンビニ的」とひとまずは呼ぼう。私はコンビニ的なものが好きで、それをこれまでも使ってきた。

現状のTextboxはまさにコンビニ的になっているし、しかも「多機能型コンビニ」になりつつある。この状況をどう考えるのか。

* * *

めちゃくちゃ考えましたが、とりあえずTextboxと同じ階層にlifelog/を作ることにしました。それでlifelog専用のindex.htmlを作り、閲覧や新規作成ができるようにします。

その上で、そのフォルダの中身をTextboxでも一覧できるようにすればハイブリッド体制になる、というのが私の思惑です。

でもって、そういう兄弟フォルダをたくさんつくっても、中身がmdファイルであるならばすべて同じ機構に載せられます。個別的でありながら、統一も可能。そういう状態をまず目指してみます。

スクショ