フロカン名古屋
デザインとコードの境界を溶かす
境界
どこで何が切り替わるか
どこでどうやって情報が渡るのか
境界で何が失われ、そのズレにどう責任を持つのか
ハンドオフの境界
デザイン to コードでズレが生じることがある
デザインデータはスナップショットである
条件分岐や画面の横幅、コンテンツ量、ユーザーの状態
重要度を明言するべき
両方の観点から見える問題と、その融かし方
デザイン上ではちょっとした条件分岐でも、コードでは複雑になる場合
→100点ではなく、90点を選ぶ。バランスを取る
提供価値とのコスパを考える
必須の機能は複雑にしてでも100点を目指すべき、など
図形の視覚調整
これをWebのUIで毎回やるのは厳しいので、デフォルトでいい感じにしてくれるアイコンライブラリを使う、とか
デザインで表現されていない領域
デザインシステムのデフォルトに従う
アクセシビリティ
見た目は同じでも実装によって良し悪しが変わる
atomic design
メンタルモデルだけでも実装モデルだけでも足りない
デザインシステム
最初期に価値が出やすいのはPrincipleやLanguage、Token
→これらがある状態でComponentを作るのが大事
Qiitaでは最初、カラーパレットとタイプスケールを整備
立ち上げ期はglobal tokenだけ、その後alias tokenで頻出パターン、その後ギャップ埋めてドキュメント整備
デザインデータはデータベースとユーザーを接続する
DB的にあり得ない状態のUIを作らない
どこからデータを取るのか、技術的に可能か、代替表現が可能か、ユーザー価値に繋がるのかなどを早めに確認
個別の値より、原則を議論する
ギャップを一気に埋めようとしない
大きく始める気持ちと、長期的に改善する気持ちの両方が大事
組織構造が境界を生んでしまっていないか
「誰が悪いか」より「どの境界が問題か」
AI
AIは境界を自動で消さない
隣の領域の苦労を少し知ることが大事
言語化力だけでなく、読解力も大事
デザインデータやコード、レビューの一言の裏にある意図、Slackのスレなど
境界に立つ人は翻訳者に近い
片方の言葉を読解して、もう片方に言語化する
具体的に言語化しないと、AIが平均的に埋めてしまい、独自性がなくなってしまう
エンジニアへ: デザインの原則を理解してほしい
知ってた？JavaScriptの"正しさ"を検証するテストが5万以上もあること(Test262)
262, 402, 404の3つの仕様を対象
414のStandard Suiteにまとめられている
DOMやfetchはwptの範囲
V8のテストが始まり
小さなアサーションライブラリも含まれている
エラーの中身も厳密に判定できる
内部で使うアルゴリズムの違いもテスト
ヘブライ歴の閏月のテストも
stage 2.7でテスト執筆が本格化し、stage 4になるには「2つの互換な実装が262のテストを通過していること」の条件がある
失敗することのテストも
test262.fyi
テスト通過状況が見れるところ
V8で見つけて直したバグ
直接evalと間接eval
前者だとローカルスコープが見えるけど、後者だとグローバルスコープで実行されるという仕様
しかし、末尾にスプレッドがあるときに壊れてた
直接じゃなくて間接evalになってしまっていた
FIXMEになっているので、失敗することがテストされていた
F8キーだけがバグる話 〜日本語IMEとフォームバリデーション設計〜
F8キーだけじゃなかったらしい