pMovidea
ネーミング
一番のコア機能は「思考の断片を動かして整理すること」なので「動かせる」を持ってきた
短縮形movidea
なぜ再実装するのか
試行錯誤の結果コードが複雑化して新機能追加の障害になっている
インパクト重視
「どこかで見たような物」に近づけない
やたらと機能を追加しない
バグらせない
コードの量を増やすと次の機能のプロトタイピングの邪魔になる
必要最小限の機能を最小限のコードで実現する
Not to do
Canvasを使わない
自由な手書き加筆を実装しない
投げ縄選択を実装しない
why?
Regroupを作り出した時はiPad+Apple Pencilを前提として「手書き加筆がスムーズに可能か」を真っ先に検証した
技術的にどの程度まで可能かはわかった(結構いける)が、ユーザニーズ的にはそれほどでもなかった
これの実現が強い技術的制約を発生させているので、一度封印して別のやり方を模索した方が良い
To do
なる早テスト
前回はCanvasだったのでスタイルに関してはJSで定義されていた
今回はDOMを使うが、CSSに分離するのはいまいちなので
前回はReactを学びながら作ったので組み込みのuseState系を使って作り始めた
しかし「巨大なホワイトボードに付箋を貼るアプリ」なので親であるAppコンポーネントがほとんどの状態を持つことになる
次やること
勘違いの検証をテストケースでカバーしてから選択範囲移動を実装する
検証する
Canvasなしで付箋をつくれるか
重要な技術的ポイント
ドラッグでの移動は、まあできるだろう
テキスト選択との干渉が心配ではある
前回はハードコードで実験サンプルを作ったが、後にJSONインポート機能が出来てからそっちを使うようになった、今回はまずそれを作って、テストケースにする データにはバージョン文字列を入れる
1: 今のRegroupからエクスポートしたJSONを読めるようにする
データ構造が前のままで良いかという問題は今考えない
2: それを使ってテストケースを作る
3: テストでカバーされればデータ構造の変更はやりやすくなる
スムーズな拡大縮小ができるか
データの保存フォーマット周り、バグった時に気づきにくかったりデータロストしたりするからしっかりテストでカバーしたい
型では守れない
前回はテストなしで作って、途中からjest-electronでテストし始めた
テストを想定した設計になっていないことや、非同期処理だらけであることから、テスト可能にしていくことに苦労した
結局テストでカバーしきれないままになった
前回はiPad+Apple Pencil前提だったが、今回はMacBook前提
前回は付箋のワールド座標系がデバイスのそれと密結合だったが、切り離した方が良いと思う
グループ構造
子要素へのポインタ
描画順？
表札
これはポインタではない
子要素でもない
子要素になることもできる？？
やめた方が良い
単なるテキスト？
何度でも更新できる
edit titleみたいなメニューで
だからこれは一般の付箋とは違うものだとわかった方が良い
開いた時はどうするか
以前は表札付箋だったが、これは違う
「グループのタイトル」として表示されれば良いのではないか
https://gyazo.com/b181a51e078ac34a54860bed29bc2bf7
🤔これを解体した時はどうなるべきか
タイトルがないならそのまま解体でいい
タイトルがある時、それは知的生産物だから失われてはいけない
付箋にする？
🤔それをもう一度グループ化した時は？
凝ったUIを作らずに付箋を選んでコピペとかでどうか
前回は開いている状態からメニューで閉じ、閉じてる状態からワンクリックで開いた
「デフォルト開」と「デフォルト閉」をトグルするようにしよう
ボーダーで区別する？
考察
done
コンテキストメニュー
これは適切か？
メニューの文言が横に書かれているため、ボタンを横に並べるのは細長くなりすぎる
古来からのコンテキストメニューみたいに縦並びのメニューが表示された方が良い