運用担当（Linux をよく触る人達）からの指摘
始めに
これは、私が実際に業務で体験した、UIへの指摘事項の話です。
私は数年間、社内ポータルの開発に携わってきました。
これまで学んできた UI のお作法に則って開発をしてきましたが、
まさか、そこに様々な指摘事項を貰うことになるとは
思いもよりませんでした。
今回はそのうち、運用担当の方、
特に Linux に習熟している方々から頂いたお便り（指摘）を紹介します。
※個人情報、および業務上の情報は伏せています
- 他の指摘事項（営業担当からの指摘など）には以下ページから移動できます。
サイドバー、邪魔
最初の状態
最近の流行りを取り入れ、各ページへのリンクをサイドバーにまとめた。
また、レスポンシブを考慮し、
ウィンドウを小さくした場合はサイドバーを隠し、
右上にハンバーガーボタン（線が3つくらい並んでいるアレ）を設置し、
サイドバーと同じリンクを出すようにした。
※サイドバー：Webページの左側などに出てくるメニュー
※レスポンシブ：画面サイズによってページのレイアウトを変える技法
（例：スマホで見るとレイアウトが変わるページ）
※ハンバーガーボタン：下図のような線が並んだボタン。通常、押すとメニューが表示される
指摘
運用担当Aさんよりご指摘を頂いた。
サイドバーが横幅を占有しすぎていて見辛い、とのこと。
（リモートではラップトップPCなので余計見辛い）
ハンバーガーボタンについてはAさん以外の方からも指摘があり、
ボタンの存在に気付けなかった、とか
そもそもこのボタンって何なの？というご意見もあった。
対応
サイドバーの下に開閉ボタンを付け、サイドバーを収納できるようにした。
開閉ボタンには大きく日本語で メニューを閉じる と記載した。
（閉じているときは メニューを開ける）
なお、ハンバーガーボタンは分かりづらいという事で削除した。
また、特定のページしか見ない人は
そもそもサイドバーすら不要（リンク辿らない）、とのことなので、
サイドバーの開閉状態を Cookie に記憶させるようにした。
（一度閉じれば閉じたまま）
反響
Aさんより、サイドバーを開閉できることで横幅が広くなった、とご意見を頂いた。
Cookie での開閉状態の記憶も、
特定のページしか見ない人にとっては、
いちいち閉じる手間が減って助かっているようだ。
教訓
- サイドバーは開閉できるようにする
- メニューをハンバーガーボタンだけに格納しない
- ボタンの存在や用途に気付けない人もいる
- 使うならサイドバーなどと併用した方がよい
ボタン類は左側にまとめて
最初の状態
データベースの情報をリスト表示するUIを作成した。
1行ごとに、データの編集や削除ができるボタンを 行の右端 に設けた。
指摘
運用担当Bさんよりご指摘を頂いた。
文字列が長い場合、一行が長くなり、右端のボタンが一画面で収まらなくなる。
このため、いちいちスクロールしてボタンを押すのが面倒、とのこと。
また、削除ボタンについては
"誤って押したら怖い" とのご相談も頂いた。
（一応、確認画面は出すようにしているが、それでも心配らしい）
なお、上述のボタン配置については、
サイト内の全ページで統一した方が戸惑わなくてよいのでは、という意見も頂いた。
対応
操作ボタンを各行の左端にまとめて表示した。
削除ボタンについては、削除したい行を選択した上で、
画面左上に1個だけある削除ボタンを押す仕様に変更。
加えて、サイト内の全ページに同じレイアウトを適用した。
反響
Bさんから、ボタンを見つける手間（スクロール）が減った、とご意見を頂いた。
教訓
操作ボタンなどのよく使う or よく見る項目は
スクロール無しで見えたほうがいい。
また、ページのレイアウトはサイト全体で一貫性を持たせると、
利用者の戸惑いを無くせる。
※ただ、必ずしも全ページで統一する必要はないと思う。
例：同じレイアウトでは表現や操作が難しい場合
一覧を見ただけで内容を把握したい
最初の状態
障害対応の一覧ページがある。
このページでは、１つの障害に対してその進行状況などを記録でき、
詳細画面を開けば障害の情報が細かく出てくる。
ただ、一覧表示では障害の題名と発生日時だけを表示しており、
特に他の項目は出さないようにした（行が長くなるので）。
指摘
運用担当Cさんよりご指摘を頂いた。
題名と日時だけだと、似たような障害が多い場合に判別がつきづらい。
障害を一意に見分けるために必要な項目を
幾つか一覧に出して欲しい、とのこと。
対応
一覧に運用担当より依頼のあった項目も表示するようにした。
長文になる場合は途中まででカット、
または 非表示部分を展開する ボタンなどで展開できるようにした。
反響
Cさんより、一覧を見るだけで障害の判別が付くようになり、
作業がしやすくなった、とのご意見を頂いた。
教訓
一覧画面を作るときは、奇麗に表示することに考えが行き、
どうしてもデータ量を減らしたくなる。
しかし、あまり表示を抑制してしまうと
各行の内容を特定できなくなる、という悪影響もある。
そのページで作業を行う人に確認し、
その行を一意に判断可能な項目を出してあげることが大事。
詳細ページは短いURLで連携したい
最初の状態
前項で説明した障害対応の一覧ページについて、
運用担当Dさんより依頼を受けた。
障害対応の詳細画面の URL をチャットでメンバーに共有したい、という依頼。
※チャット：業務で利用している文章での会話ツール（Slack など）
ひとまず、障害の検索条件を URL の QUERY STRING に付け、コピペできるようにした。
指摘
Dさんよりご指摘を頂いた。
URLの共有はできるようになったが、
URLが長すぎてチャットが汚れる、とのこと。
確かに、検索条件をたくさん繋げているので長い。
また、チャットの仕様なのか
QUERY STRING が途中までしか認識されなくなり、
リンクとして機能しなくなる問題もあった。
修正前のチャット貼りつけ例（長い URL の場合）
- URL が長すぎて複数行に渡ってしまい、前後の会話が見辛くなる。
- 更に、途中でリンクが切れてしまう。
- 上図の下線部分（リンク）が3行目で切れている
- なので、リンクをダブルクリックしてブラウザを開いても、正しくページが表示できない
- ※例は kibana というデータ可視化ツールの検索 URL（そのまま）
対応
URL に障害情報の hash キーだけを付与するように修正し、
短い URL を共有できるようにした。
具体的に書くと
- 障害ごとに一意の hash キーを作り DB に登録
- hash キーを QUERY STRING に付与
- URL が叩かれたら、バックエンド側で hash キーを WHERE 句の条件にして DB から障害情報の検索を行う
修正後のチャット貼りつけ例（短い URL にした場合）
- 大体1行で収まるので、会話の妨げにならない
- ※例は kibana の検索 URL（ハッシュ版）
反響
Dさんより、URLがコンパクトになりチャットに貼りやすくなった、とのご意見を頂いた。
教訓
障害など、複数人と共有する可能性がある検索結果については、
検索結果の詳細ページに直接飛べる URL を用意しておく。
URL は共有しやすいように短くするとよい。
- 例：URL には短いキーだけを付与し、そのキーで DB を検索する など
※本記事に登場する人物やサービスは仮名です。