本当にあったUIの指摘事項（運用担当者からの指摘編）

# 運用担当（Linux をよく触る人達）からの指摘

## 始めに
~~~
これは、私が実際に業務で体験した、UIへの指摘事項の話です。

私は数年間、社内ポータルの開発に携わってきました。
これまで学んできた UI のお作法に則って開発をしてきましたが、
まさか、そこに様々な指摘事項を貰うことになるとは
思いもよりませんでした。

今回はそのうち、運用担当の方、
特に Linux に習熟している方々から頂いたお便り（指摘）を紹介します。

※個人情報、および業務上の情報は伏せています
~~~

+ <font color="DarkGray">他の指摘事項（営業担当からの指摘など）には以下ページから移動できます。
  - [本当にあったUIの指摘事項（メインページ）](https://qiita.com/hantyou-k/items/2ed207a6ff38a2da58e5)

## サイドバー、邪魔
#### 最初の状態
最近の流行りを取り入れ、各ページへのリンクをサイドバーにまとめた。
また、レスポンシブを考慮し、
ウィンドウを小さくした場合はサイドバーを隠し、
右上にハンバーガーボタン（線が3つくらい並んでいるアレ）を設置し、
サイドバーと同じリンクを出すようにした。

※サイドバー：Webページの左側などに出てくるメニュー
※レスポンシブ：画面サイズによってページのレイアウトを変える技法
（例：スマホで見るとレイアウトが変わるページ）
※ハンバーガーボタン：下図のような線が並んだボタン。通常、押すとメニューが表示される
<img width="10%" border="5" alt="ハンバーガーボタン" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/568441/f02b2335-6783-d109-9d64-183ad89803eb.png">

#### 指摘
運用担当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 の場合）**
<img width="100%" border="5" alt="修正前" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/568441/96e5087e-d901-7314-908d-8d3f2e4006b0.png">

+ URL が長すぎて複数行に渡ってしまい、前後の会話が見辛くなる。
+ 更に、途中でリンクが切れてしまう。
  - 上図の下線部分（リンク）が3行目で切れている
  - なので、リンクをダブルクリックしてブラウザを開いても、正しくページが表示できない
+ ※例は kibana というデータ可視化ツールの検索 URL（そのまま）

#### 対応
URL に障害情報の hash キーだけを付与するように修正し、
短い URL を共有できるようにした。

具体的に書くと

+ 障害ごとに一意の hash キーを作り DB に登録
+ hash キーを QUERY STRING に付与
+ URL が叩かれたら、バックエンド側で hash キーを WHERE 句の条件にして DB から障害情報の検索を行う

**修正後のチャット貼りつけ例（短い URL にした場合）**
<img width="100%" border="5" alt="修正後" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/568441/fed81e82-48f5-7e3f-022b-c3e4e75ceca5.png">

+ 大体1行で収まるので、会話の妨げにならない
+ ※例は kibana の検索 URL（ハッシュ版）

#### 反響
Dさんより、URLがコンパクトになりチャットに貼りやすくなった、とのご意見を頂いた。
#### 教訓
障害など、複数人と共有する可能性がある検索結果については、
検索結果の詳細ページに直接飛べる URL を用意しておく。
URL は共有しやすいように短くするとよい。

+ 例：URL には短いキーだけを付与し、そのキーで DB を検索する など

~~~
※本記事に登場する人物やサービスは仮名です。
~~~