次の開発はネットワーク接続か、ドラッグ中原寸表示問題の解決か
まとめ
Q: Movideaの次の開発をネットワーク接続にするか、ドラッグ中に原寸表示になる問題の解決にするか
A:
一行回答「データをクラウドに置く機能」
ドラッグ中に原寸表示になる問題は個人的には気持ち悪いがアート的な完成度へのこだわり
過剰品質の可能性があるのでユーザに見せて反応を観察するべき
ネットワーク接続機能は「付箋はクラウドにある」という状態をつくるもの
「書いたものが消えない」という文房具の本質的な機能
なのでさっさと作る
明日やるのはネットワーク接続機能の方
「付箋のデータはクラウドにある」と言える状態をつくる
過去のバージョンでは接続してない状態を「Not connected」と表現してた。これは本質を掴んでない表現
「データがクラウドにある」「ローカルにしかない」が適切な表現
「ネットワーク接続機能」と呼ぶのをやめろ
考察
二つの開発タスクを前にしてどちらを優先すべきか迷った事例
迷うということは大差ないのであり、迷うことで時間を浪費するくらいならコインを投げて決めた方がいい、そこでコインよりはだいぶマシなKeichoに相談して決めることにした
片方のタスクは見た目の自然さに対する作り手のこだわりだとわかった
もう片方のタスクは技術的な側面から見た呼び名で呼んでいたが、もっと本質的なものだとわかった
この整理で後者のタスクの名前が変わり、優先度の均衡が崩れて次にやることを自信を持って選べるようになった
---
あなたはこの会話で何がどうなるとよいのでしょう？
Movideaの次の開発をネットワーク接続にするか、ドラッグ中に原寸表示になる問題の解決にするか決まるといい
その「Movidea」は、どんな「Movidea」ですか？
付箋をドラッグして考えをまとめるツール
その「付箋」は、どんな「付箋」ですか？
考えの断片が書かれてる
その「断片」は、どんな「断片」ですか？
(これは本題でないところを掘り下げすぎてる)
ドラッグすることによって並べ方を試行錯誤できる
その「ドラッグする」は、どんな「ドラッグする」ですか？
今回はブラウザのDragDropAPIを使って実現した文字通りのドラッグ
その「DragDropAPI」は、どんな「DragDropAPI」ですか？
ブラウザの標準化された機能でドラッグを実現するためのもの、ドラッグ中の対象物の表示などをブラウザ側がやってくれる
その「実現する」は、どんな「実現する」ですか？
うーん、ドラッグ中の見た目を、かな。
あなたが価値を感じているのは何ですか？
なるべく自然に付箋を動かしてる見た目を実現すること。で今はドラッグ中の対象物の表示が原寸になってしまうことが自然でないと感じている。
その「ドラッグ」と「実現する」の関係は何ですか？
ドラッグとは移動する操作で、実現するのはその移動する操作の見た目。
その「ドラッグ」と、「実現する」とは同じですか？違いますか？
違う
> ドラッグとは移動する操作で、実現するのはその移動する操作の見た目。
この「実現する」について、他に何かありますか？
いくつか要件は明らかになったからDragDropAPIを使わなくても実現できる、よりよく実現できるかも
> ドラッグとは移動する操作で、実現するのはその移動する操作の見た目。
あなたはこの「実現する」をどう知るのですか？
気になる点がなくなったときに「実現した」って感じる
その「実現する」は、どこにありますか？
僕の中だね、僕の理想が高すぎるのか
> 気になる点がなくなったときに「実現した」って感じる
この「実現する」は、どのあたりにありますか？
「僕が気になる点がなくなったとき」はアート的だね。「ユーザが不都合を感じるかどうか」にすべきなのかな。
> 気になる点がなくなったときに「実現した」って感じる
この「実現する」は、何のようですか？
アート
> 気になる点がなくなったときに「実現した」って感じる
この「実現する」は、どこから来るのですか？
それはさておきもう一つのネットワーク接続について
> 気になる点がなくなったときに「実現した」って感じる
この「実現する」に関して、何が起こるとよいですか？
(あれ、おかしいな)
🙁
> ドラッグとは移動する操作で、実現するのはその移動する操作の見た目。
この「ドラッグ」は、どんな「ドラッグ」ですか？
🙁
> ドラッグとは移動する操作で、実現するのはその移動する操作の見た目。
この「ドラッグ」について、他に何かありますか？
🙁
> なるべく自然に付箋を動かしてる見た目を実現すること。で今はドラッグ中の対象物の表示が原寸になってしまうことが自然でないと感じている。
この「ドラッグ中」は、どんな「ドラッグ中」ですか？
👎ドラッグ中
> ドラッグとは移動する操作で、実現するのはその移動する操作の見た目。
この「ドラッグ」は、どこにありますか？
🙁
> なるべく自然に付箋を動かしてる見た目を実現すること。で今はドラッグ中の対象物の表示が原寸になってしまうことが自然でないと感じている。
この「付箋」について、他に何かありますか？
付箋を並べた配置は知的生産物だから保存したい、そこでクラウド自動保存機能が必要
その「付箋」は、どこにありますか？
ブラウザのメモリ上にあるのだけどブラウザやユーザの端末はいつ終了するかわからないから変更したその場でクラウド保存する必要がある
> 付箋を並べた配置は知的生産物だから保存したい、そこでクラウド自動保存機能が必要
この「付箋」は、何のようですか？
紙に書いた文字みたいなもの。中断してもそこに前回のまま残ってるので思考を再開できる。
> 付箋を並べた配置は知的生産物だから保存したい、そこでクラウド自動保存機能が必要
あなたはこの「付箋」をどう知るのですか？
そっちじゃなくてクラウド保存の話を掘り下げたいな
その「クラウド」は、どんな「クラウド」ですか？
Firestoreに保存する
その「保存する」は、どんな「保存する」ですか？
ユーザは何も操作しなくて、付箋の配置などが変わったときにバックグラウンドで保存が開始される
その「付箋」に関して、何が起こるとよいですか？
付箋に対する操作は巻き戻せるといい
それには「付箋」に何が起こる必要がありますか？
(これはUndoの話も混ざってるな)
Reactの状態更新のうち、保存やUndoの対象である変更を検知できる必要がある
「付箋」に関して、それができますか？
React的に破壊的更新が禁止されてるから付箋の状態に関するオブジェクトの同一性を見るだけで検知できるはず、フックでできる。以前のバージョンでなんか複雑なことをした気がするが何のためだったかな…
その「付箋」は、どこから来るのですか？
(今確認したら3秒ごとに更新されてるか確認する関数が走って、更新されてたときに保存を呼び出してる。これは更新レート制限だな)
(思い出した、共同編集でサーバからの情報で更新されたときに保存処理が走ってはいけないからローカルでの変更だけ送るようになってるんだな)
つまり付箋はローカルの更新で作られることもあるし共同編集での更新がクラウドから来ることもある。単に保存するだけなら前者だけでいいのだけど、共同編集をアリにするなら後者の方が必要。
その「付箋」は、どのあたりにありますか？
共同編集は一旦なくていい？と考えたが、その場合サーバ側に最新の状態があるのに古い状態のを編集して上書きしてしまうと悲しいし「新しいものがサーバにあります、リロードします」ってやったら、やっぱりサーバ経由の更新は起きるわけなので、共同編集を積極的に推すかどうかと無関係にサーバ経由更新のケアは必要だな。付箋が手元だけにある状態をなる早でなくして「クラウドにある」にしたい。消えないために。
その「付箋」と「実現する」の関係は何ですか？
(まとめ、ドラッグ中に原寸表示になる問題は個人的には気持ち悪いがアート的な完成度へのこだわりなのでユーザに見せて反応を観察するべき、ネットワーク接続機能は「付箋はクラウドにある」という状態が「書いたものが消えない」という文房具の本質的な機能なのでさっさと作る。明日やるのはネットワーク接続の方)