Regroup2020-01-27
無限に広いキャンバスよりも、無限にページが縦につながってるノートの方が使いやすいのかも
無限に広いキャンバスは「どこに書くのか」の意思決定が書き始める前に必要
ノート風の形になっていれば、一番下に書くことがアフォードされる
まずは書いて、それから事後的に整理する
過去に書いたものを後から整理するとき、過去のものを壊さないようにしたい
過去のものはロックされて、明示的にロックを外さない限り編集されないようにすれば良い
そうするとロックされたものは解除されるまでレンダリング済みの画像で表示していて良い
整理するために2ページ並べて表示
古い方を選択して新しい方へドラッグドロップ
したら古い方を更新せずに新しい方に複製ができるとよい
今作ろうと考えてた便利な手書きノート、Regroupではないのでは？
共通部分はあるけど別物
Regroupは、紙の付箋を用いたKJ法のペインポイントを解消したくて生まれた
その過程で手書き機能をつけた
手書きはサブ
主目的は100枚を超える付箋を画面上で整理することができること
その目的に関しては
CCSEの準備に使って
「グループ出し入れ」「画像」がボトルネック
画像ちらつき問題は解決の糸口が見えてる
この目的には「無限に広いホワイトボード」の状態の方が適切
「無限ページのノート」スタイルの方は、この頃日々使っている手書きのノートに関する改善
データの持ち方自体が変わるわけだし。
両方のプロジェクトで共通して使うコードは共通化しても良い
が、最初から一体化してると無理な抽象化をしてしまう
Regroupの方は複数行テキストの流し込み機能がある
今の状態でも書き出しツールとの連携は簡単
Scrapboxから読む機能でもつければ僕のユースケースには十分
一旦複数人での共同編集をスコープから外せば状態管理周りもいまのままで良い
画像表示のためにプロキシを作った
それをcloud functionとかに任せられるかどうか検討
lambdaは生でバイナリを返せないのでどうかなと思ってた
他のものも軒並み返せないのなら(ありえる)諦めて別の対策を考えなければならない
ec2の小さいインスタンスでいい気もする
Regroupの側
一つのテーマに対するアイテムが数百件置かれて、破壊的更新が行われる場
手書きノートの側
日々手書きのメモを蓄積していく場
過去のログは基本的に破壊的更新をしないで溜め込んでいく場所
手書きノートのパスの塊をエクスポートしたりRegroupに取り込んだりできればいい
素朴な手段は画像
Scrapboxに貼るなら画像しかない
変更可能なパスの形で保管され、そこへのリンクを保っていればそれで良い
Regroupが解決したかった問題
認知的に大変さを感じる規模の情報の断片を前にして
それを構造化していくプロセスの支援
実際のところは100枚程度なら僕はグループ化がなくてもできちゃう
でもグループ化はより負担の大きな課題に対しては必要性を感じる
そこを支援するツールがないことがより良い構造化を妨げてる
だから支援ツールが欲しい
いまのRegroupの問題
グループに表札をつけるのが強制されてるところ
グループの解体やアイテム追加などが未実装なところ
その辺りを直すのが必要
raw
無限に広いキャンバスであるよりも、無限にページのあるノートが縦につながってある形の方が使う側にとってやりやすいのかも
無限に広いキャンバスは「どこに書くのか」の意思決定が書き始める前に必要、ノート風の形になっていれば、一番下に書くことがアフォードされる
まずは書いて、それから事後的にせいりする
過去に書いたものを後から整理するとき、過去のものを壊さないようにしたい
過去のものはロックされて、明示的にロックを外さない限り編集されないようにすれば良い
そうするとロックされたものは解除されるまでレンダリング済みの画像で表示していて良い
整理するために2ページ並べて表示して、古い方を選択して新しい方へドラッグドロップしたら古い方を更新せずに新しい方に複製ができるとよい
今作ろうと考えてた便利な手書きノート、Regroupではないのでは？
共通部分はあるけど別物
Regroupは、紙の付箋を用いたKJ法のペインポイントを解消したくて生まれた
その過程で手書き機能をつけた
手書きはサブであり、主目的は100枚を超える付箋を画面上で整理することができること
その目的に関してはCCSEの準備に使って「グループ出し入れ」「画像」がボトルネック、画像ちらつき問題は解決の糸口が見えてる
この目的には「無限に広いホワイトボード」の状態の方が適切
「無限ページのノート」スタイルの方は、この頃日々使っている手書きのノートに関する改善
こっちは別プロジェクトとして新しく作った方が良さそう
データの持ち方自体が変わるわけだし。
両方のプロジェクトで共通して使うカードは共通化しても良いが、最初から一体化してると無理な抽象化をしてしまう
Regroupの方は複数行テキストの流し込み機能があるから今の状態でも書き出しツールとの連携は簡単、Scrapboxから読む機能でもつければ僕のユースケースには十分
将来的には、長文コンテンツを自動で付箋に刻む機能があると面白いが、それは別の話
一旦複数人での共同編集をスコープから外せば状態管理周りもいまのままで良い
画像表示のためにプロキシを作ったが、それをcloud functionとかに任せられるかどうか検討。lambdaは生でバイナリを返せないのでどうかなと思ってた
他のものも軒並み返せないのなら(ありえる)諦めて別の対策を考えなければならない
ec2の小さいインスタンスでいい気もする
カード→コード
Regroupの側は、一つのテーマに対するアイテムが数百件置かれて、破壊的更新が行われる場、手書きノートの側は日々手書きのメモを蓄積していく場であり、過去のログは基本的に破壊的更新をしないで溜め込んでいく場所
手書きノートのパスの塊をエクスポートしたりRegroupに取り込んだりできればいい、素朴な手段は画像、Scrapboxに貼るなら画像しかない、変更可能なパスの形で保管され、そこへのリンクを保っていればそれで良い
Regroupが解決したかった問題は、認知的に大変さを感じる規模の情報の断片を前にして、それを構造化していくプロセスの支援で、実際のところは100枚程度なら僕はグループ化がなくてもできちゃう、でもグループ化はより負担の大きな課題に対しては必要性を感じるし、そこを支援するツールがないことがより良い構造化を妨げてる、だから支援ツールが欲しい
いまのRegroupの問題は、グループに表札をつけるのが強制されてるところと、グループの解体やアイテム追加などが未実装なところ
その辺りを直すのが必要