今日も考えたことメモ。
1.
モダンUIでは、placeholderやtextareaといったネイティブ入力要素の機能をそのまま使わず、実体は別要素（span/label/ミラーDOM）で構成されたインタラクションを作ることがある。
例えばこういう感じの、placeholderかと思ったらフォーカスするとシュッと縮むラベルとか。↓
（Floating label というらしい）
2.
UIを作るとき、ネイティブ機能を無視して独自実装することは、しばしば避けるべきである。
単純に、クラシックな実装のほうが認知負荷が低く、メンテナンス負荷も低く、失敗時のリスクも抑えられる。
一方で。 Google や Apple 等、ごくメジャーなアプリケーション体験においてはリッチな（Floating Label 的な）挙動が普通に採用されている。
あるいはSNSのテキスト入力欄（改行・文字数に応じて自動で伸びる投稿ボックス）のように、ネイティブから強く逸脱した実装が標準的な期待値として普及している。
この状況では、ネイティブを素直に使ったUIが格下に見える可能性がある。
3.
独自実装はリスクだが、現実に広く普及している
“危険だからやるべきではない”という判断は、現代のUI慣習と一致しない。
意外性の評価が一意ではない
見慣れないUIは不快感を生むが、同時に好感を呼ぶ意外性もある。 クラシックを選べば前者（不快）リスクを減らせるが、後者（好感）を取り逃がす。
そもそも「ネイティブ」は期待値の基準でないかも
メジャーなアプリで繰り返し経験した挙動は、ネイティブを超えて「標準の振る舞い」として内面化される。 結果として、ネイティブ準拠は「安全」ではあるが、「遅れて見える」可能性。
4.
リッチさによる魅力の獲得はリスクを孕むが、放棄すればプロダクトが格下に見える危険もある。インターフェースの責務は？
UIは 摩擦をゼロにする装置なのか？
UIは 感情や空気感を設計する媒体なのか？
5.
「独自実装 vs ネイティブ」ではなく、状態を誰に委ねるか。
JSで監視し続けるのか
ブラウザの擬似クラスや構造に委ねるのか
の選択。 最小実装とはJSを減らすというような表現よりも、状態をブラウザに委ねる選択と言った方がよいかも。
「リッチ」の正体を単体パターンから切り離す
Floating Label の例それ自体がリッチなのではなく、 タイミング、スピード、イージング、余白、トーンの統合がリッチさだと考える。 価値は単品の部品ではなく、統合設計に宿る・・・
と考えてみることで、プロジェクトごとに取り込めるリッチさの単位を洗い出すことができるかも。