2021-06
- 付箋の選択・圧縮 UI設計のオーバーレイは「フォーカスが外れた時に自動で閉じるグループ」と解釈できる
- モーダルダイアログとかである必要はない
- 「開きっぱなしのグループ」と「閉じたグループ」があれば良い
2019-06の議論 付箋の選択・圧縮 UI設計
2019-04の議論---
Regroupの実装
- 子の相対位置は保存されるべき
- 位置には意味がある
- これができる点に紙のKJ法よりメリットがある
- 子のスケールは多分保存されるべき
- 少なくとも、圧縮前は密集しているので、それ以上に近づけると重なってしまう
- 拡散してスカスカになるのはダメだと思う
- 子の絶対位置は保存されるべきでない
- 圧縮してから、親の付箋を動かした場合、展開した時に、子の付箋が当初の位置に出現しても嬉しくない
- 子の位置は重心との相対位置で保存され、圧縮した時に親の付箋が重心位置に表示され、展開された時はその重心位置からの相対位置で復元されると良い
と、自然な方法を考えるとこうなるわけだが、そうすると
- 圧縮後スカスカしている
- 親の付箋を更にグループ化する=近接する
- それを展開する という流れを踏んだ時に、展開された付箋同士が重なってしまう どうするか？
案1: 物理演算で反発
- デモ的に格好はいいが、挙動を予測できない
- 一つのグループの開閉が、周囲の付箋の位置に影響を与えるのは筋が悪い
- 没
案2: ユークリッド空間である必要はないのでは
- それはそうなんだが、ユーザが自然に認識できるかどうかはちょっと疑問
- 保留
案3: 収まらないものはズームアウト
- 拡大していけば元のサイズになる
- その際に、Cは等倍以上に大きくはならないようにする
- 単なるView層の実装として「他の付箋と重なりそうだったら、重ならない程度に縮小して表示される」
- この場合、子の相対位置のスケールは保存されていない
- (スケールを保存しつつCの側の絶対位置を編集することも可能だが筋悪)
- Viewの実装としてそもそも「縮小で縮むのは位置関係だけで、付箋のサイズではない」という選択肢も可能
- 直感的ではないが、慣れられるか？
- 意外といける気がする →実体は点であるメタファー
- 視点の拡大縮小をした時に付箋のサイズが大きくなるべきかどうかという問題
- 幅を持った付箋自体が物理的実体だというメタファーだと「人間にとって適度なサイズ」によって暗黙に制限される
- 中央の点だけが実体
- しかも多次元空間上の1点であって、現在のスクリーン座標に投影されているに過ぎない
- 付箋の位置は多次元ベクトル pRegroup2020
