準備を進める月曜日

8:00

おはようございます。今日はもろもろの準備を進めます。

publish:ビジネス書・実用書の展望 / incからsncへ、そして…… / 開き直るしかないこと|倉下忠憲

Scrapboxing:

publish:console.log() - 自作ツールづくりwiki

あと、英語の勉強。

Medical breakthroughs have brought about great benefits for humanity as as whole.

メルマガ:

ファイルの準備を進めます。

* * *

OKです。時間があれば原稿も書きましょう。

Textbox:

タスクの扱いについて。

たとえば、朝一から作業を始めて、まだ一度もTextboxのshutterを開いていません。開く暇がないともいえるし、開く必要がないとも言える。もし、shutterをもっと使っていきたいと思うなら、このワークフローから考え直す必要があるでしょう。

現状、朝一に確実に目に入るのは、作業日誌用のテキストファイルを作る目的でコマンドラインを叩くことで、たとえば、そこでその週のタスクなどをprintする手はあります。つまり、Textboxでjsonデータを作るものの、それはターミナルで利用する、というやり方。

これはこれでありでしょう。

* * *

別に考えたのは、ファイルを準備するためのコマンド(たとえばcommand + O)などを準備して、それを押したらページを切り替えるための選択肢が表示される(インクリメンタルサーチ可能)と共に、一週間の予定やタスクが表示されるというもの。つまり、切り替え動作のために「目に入る」ようにしておくもの。

あるいは、現状 command + control + m でメモの入力モーダルを表示しているが、そこにスケジュールなどを表示させるという手もある。

つまり、大きな流れとしては二つある。一つは、一日一回、必ずどこかで目に入るようにすること。もう一つは、日常的な操作のタイミングで表示させること。まずその選択から。

* * *

一日一度の起動について。

たとえば、何かしらの変数をチェックして、それがfalseならば今週の予定ダイアログを表示し、変数をtrueにする。これで次回は表示されない、ということができる。

たとえば、ページを切り替えるタイミングなどで、それをする。あるいはHomeに戻ってきたタイミングか。

home.mdが表示されたとき、その日まだ一度もそのダイアログが表示されていなければ表示する、というやり方をすると、「一日一回は表示する」が可能になる。デイリーページシステムならば、その日のページを表示したタイミングなどになるだろう。

あるいは、ダイアログではなく、home.mdに表示する手もある。現状、メニューボタンが並んでいるところに週の予定を表示させるという方法。

homeをダッシュボード的にする?

* * *

あるいはマウスオーバーだけで表示されるようにすることで、ほぼページの一部にしてしまう?

* * *

ページ全体を左方向にドラッグしたら、別のページが表示される機能が残っていました。ちょっとびっくりしました。

* * *

入れるだけ入れてみました。

Image from Gyazo

デザインが、モサい。

Image from Gyazo

下のカードとデザインを揃えてみました。

なんだか、まだしっくりくる感じではないですが、あまりこればかりに時間も使っていられないので、しばらくはこの形で運用してみます。

ただ、やっぱりこれは「答え」ではないですね。むしろモーダルの入力時、あるいはmemo.mdに表示させる形がよさそうです。

* * *

ようするに「ホーム画面」では、一つ上の視点を獲得したいということなのでしょう。それをどう考えるか。つまり、一つ上の視点をホーム画面という最上位で表す必要があるのかどうか、ということです。

* * *

やっぱり気持ち悪いので素のバージョンに戻しました。

* * *

command + o を押したら右側からメニューが出てきましたね。これもすっかり忘れていました。これらの機能も踏まえて、もうちょっと検討しましょう。

10:00

TH:

第二章の流れを再検討します。

11:00

メールの返信:

新しい編集者さんからメールを頂いたので、返信しておきます。

12:00

環読プロジェクト:

第一章を続けます。

13:00

Evernote:

ノートの移行作業の準備段階として、エクスポートを進めます。エクスポートだけで一苦労です。

* * *

言葉に関するノートがたくさんありました。たとえば「引用・名言」や「物書きノート」(書き手を勇気づける言葉などが収集されている)そして「読書メモ」。これらを、自分のシステムでどう扱うかを検討する必要があります。

現状のシステムで言えば、それぞれの言葉をJSONの一項目として保存し、それを表示するページを作るか、あるいは「お気に入りの言葉」というようなmdファイルを作り、そこに手でまとめていくのか、です。

もちろん、Scrapboxに一つの言葉について一つのページを割り当てることもできますし、同じように「お気に入りの言葉」というページに手作業で収集していってもいいでしょう。

* * *

たとえば、現状ならば、history.jsonの中に「引用集」というアドレスがあって、そこに記録されたものは、memo.mdにて表示できます。ただしmemo.mdは簡易のビュアーなので、それぞれのアドレスの中身に合わせて表示を調整することはしていません。すべてのアドレスが均一なスタイルで表示されています。

そういうスタイルの均一性はあまり好まないものの、一方でmemo.md上でさまざまなアドレスの中身を切り替えて見ていける、というのは好ましく思います。

で、考えてみると、このmemo.mdの何が良いのかと言えば、すべての保存されているアドレスがボタンとして表示されているので、「何を保存したのか」を覚えていなくても使える、ということです。現状のTextboxはScrapboxの思想に感化されながら作成されているので、そうした「インデックス=サイドバー=ツリー構造」を作らないように努めています。

それ自身は明確なメリットを持つのですが、覚えているわけではないけども、ボタンを見たことで思い出し、その中身を確認するというルートもあるはずです。この辺をうまい感じに処理できたらいいのでしょう。

* * *

一応対処療法的に、memo.mdでボタンを押したら、そのボタンでswich case してCSSを置き換える、というやり方はできます。ただし、事前に指定しておく必要があるので数が増えると(面倒で)対応できなくなります。

あるいは、3種類ぐらいのサイズを準備しておき、何もなければ通常で、ラージとマックスのようなより大きなものが欲しい場合には指定する、というやり方は折衷案となるでしょう。

* * *

たいして、ideaScapeは現状複数のjsonを読み込んで切り替える運用になっています。memo.mdはhistory,jsonのアドレスによって切り替えるので、似ていても異なる処理系があるわけですね。

この辺を意識して、じゃあ「言葉」をどうコレクトしていくのかを見極めましょう。

* * *

単純にmdファイルにまとめておくやり方であれば、他のノートツールやエディタでも開きやすいというメリットはあります。その文、「操作」できることは減る、ないしはその実装が手間になってきます。

* * *

次に「引用集」と「お気に入りの言葉」と「読書メモ」の差異をどのように扱うのか、ということ。すべてを均一に扱うのか、それともそれぞれの性質に合わせるのか。合わせるとして、そこにはどんな性質があるのか。

これも簡単には答えが出ません。

memo.mdであれば、アドレスのボタンがすべて表示されているので、自分がどれに仕舞おうとしていたのか(あるいは過去しまっていたのか)がリマインドされるのですが、そうでない場合、ファイルごとに分けてしまうと、分けるべき場所を見失う可能性は常にあります。複数のJSONにしても同様でしょう。

ここが難しいところです。