前回は、課題をCaseとStepという共通モデルで持つ話を書きました。今回は、そのデータをどう画面に並べたかです。確認観点を一画面に集める、というのが設計の狙いでした。
経験者の頭の中を、画面に出したい
第3回で、チャットだと課題全体の現在地が見えにくい、と書きました。その反省から、まず考えたのは「経験者の頭の中にある全体像を、そのまま画面に出せないか」ということです。
経験のある人は、いま自分が課題のどのあたりにいて、あと何が残っていて、目の前のステップで何を見て何を判断すればいいかを、頭の中で同時に把握しています。この三つを同時に持っているから、迷いが少ないのだと思います。逆に言えば、初めての人はこの三つのうちどれかが欠けて、手が止まります。
だから、「全体・現在地・目の前の作業」を一度に見せられれば、初めての人でも迷いにくいはずだと考えました。三つを別々の画面に分けず、一画面に並べる。ここが出発点でした。
そこで、画面を左・中央・右の3つに分けました。
左は全体、中央は目の前、右は補助
- 左: 課題全体の進捗です。進捗率とバー、完了した数と残りの数、全体で何ステップあるか。ステップ一覧には、完了・現在地・未着手が一目で分かるマーカーを付け、現在のステップに左アクセントを添えました。課題名も強調しています。ここを見れば「今どこで、あとどれだけ」が分かります。
- 中央: 現在のステップそのものです。目的、背景、確認手順、確認値、正常と異常の判断基準、証跡の入力欄、注意事項、完了条件。前へ・次への移動もここにあります。第4回で作ったStepのフィールドが、そのまま並ぶ場所です。
- 右: AI補助欄です。現在の課題とステップの文脈、ヒント、そして質問への補助応答。ここはあくまで脇役の位置づけです。
左を見れば今どこにいるか分かり、中央を見れば次に何をすればいいか分かり、右で足りない観点を補える。第1回から書いてきた「観点をそろえる」を、レイアウトの形で表現したつもりです。人によって最初に見る場所が違っても、この画面なら同じ情報が同じ場所に並んでいる、という状態を目指しました。
チャットを中央に置かなかった
意図的にやめたのが、チャットを画面の中心に据えることでした。会話を主役にすると、また現在地が流れて見えにくくなります。第3回で書いた問題を、レイアウトで繰り返したくなかったのです。
中央には、課題の構造そのもの――いま踏むべきステップと、その判断材料――を置きたかった。だから、AI補助を一番右に、しかも幅を絞って配置しました。それが補助だと、画面の構成でも伝えたかったからです。困ったときに開く場所であって、そこから会話を始める場所ではない、という位置づけにしています。右にあって、幅が狭い。それだけで「主役ではない」というメッセージになると考えました。
3カラムは1280px以上にした
3カラムを常に出すわけにはいきませんでした。ここで一つ、実際に作ってみて分かった問題があります。このアプリ自体が、左側に固定のサイドバー（240px）を持っているのです。その分、本文に使える横幅はもともと狭くなります。
最初は、やや広い画面（1024px以上）で3カラムを出す設定にしていました。数字だけ見れば足りそうに思えたのです。ところが実際に確認してみると、アプリのサイドバーの分を差し引くと中央が200px程度しか取れず、肝心の確認手順や証跡欄が窮屈になってしまいました。中央が主役なのに、一番狭い。設計の意図と、実際の見え方が逆になっていたのです。
そこで、3カラムを有効にする条件を、より広い1280px以上（Tailwind CSSのxl）へ引き上げました。グリッドはおおまかにこういう指定です。
xl:grid xl:grid-cols-[236px_minmax(0,1fr)_304px]左を236px、右を304pxで固定し、中央は残り全部（minmax(0,1fr)）を使う形です。こうすると、1440px幅では中央がおよそ572px、1280px幅でもおよそ460px確保でき、確認手順や証跡欄がゆったり収まります。実際に広い画面で見直して、ようやく「中央が主役」の見え方になりました。数字の見積もりだけで決めず、実際に置いてみて直した、という地味な一歩でした。
狭い画面では1カラムに切り替える
1280pxに満たない画面――タブレットやスマートフォン――では、3カラムをやめて縦積みの1カラムにしています。左のステップ一覧を折りたたみボタンにまとめ、中央、その下にAI補助、という順に並べ替えます。折りたたみボタンには「現在 何番目／全体」を表示して、畳んでいても現在地が分かるようにしました。
横に3つ並べたまま縮めると、どの列も読みにくくなります。狭いときは潔く縦に積む、という判断です。各列に横幅の最小値をリセットする指定（min-w-0）を付け、長い文章や証跡欄がはみ出さないようにもしました。長い単語や値で横スクロールが出るのを防ぐためです。
長いヒントで画面が埋まらないように
もう一つ手を入れたのが、左右のペインの追従です。ステップ数が多い課題（後の回で書く15ステップの課題など）だと、左のステップ一覧が長くなります。右のAI補助も、ヒントが長いと縦に伸びます。
そのまま置くと、中央を下へ読み進めたときに、左の現在地表示や右の補助が視界から消えてしまいます。それでは「一画面で全体・現在地・作業を見る」という狙いが崩れます。そこで左右のペインは、広い画面では画面上部に貼り付き、内部だけをスクロールするようにしました。中央を読み進めても、現在地と補助が視界から消えない、という狙いです。
まだ実測は手動確認が残っている
正直に書いておくと、この幅ごとの見え方は、ブラウザで自動的にピクセルを測るところまではできていません。DOMの構造や、描画・操作中にエラーが出ないことは自動テストで確認していますが、実際の横スクロール有無などは手動での目視確認を残しています。CSSと幅の計算のうえでは崩れる要因を潰したつもりですが、実測ではない、という点は正直な弱みです。ここは今後の宿題として残っています。
次回からは、この共通UIの上に載せた3つの課題を、一つずつ具体的に見ていきます。まずは最初の基準実装になった、Webサイト接続障害の切り分けです。