はじめに
本記事はSAP Advent Calendar 2019の11日目にあたります。
記事の作成理由とその対象
「こんな意味のわからないUX（いわゆる画面）のレビューがなんで通っているんだ！！！」
SAPUI5を用いたFioriのアドオンアプリを開発する中で、このように叫んだことのある方は非常に多いと思います。
少しでもこの叫びを減らすために、SAPUI5を用いたアドオンアプリのUXデザインにおけるアンチパターンと対策について言及します。
アンチパターンリスト
よく見かける気がする4パターンをアンチパターンとして取り上げます。
ひたすら要素が羅列されたパターン
- 起こっていること：数多くの要素が脈絡なく１つのUXエリアに並べられている
- このパターンの嫌なところ：ユーザが目的の要素をみつけにくい
-
よく見かけるアプリの種類：項目の多い伝票入出力アプリ、出力項目の多いBIツールなど
たくさん入力項目が並んでいた場合、どこを探せば入力したい項目があるのかわかりません。
抽象度が揃わない要素が隣り合っているパターン
- 起こっていること：レベル感の違う要素が1つのUXエリアに並列に配置されている
- このパターンの嫌なところ：ユーザが目的の要素をみつけにくい
-
よく見かけるアプリの種類：特になし
抽象度がそろっていない場合、入力したい項目を直感的に探しづらくなります。
順序関係が適切ではないパターン
- 起こっていること：適切な位置に適切な要素が配置されていない
- このパターンの嫌なところ：アプリごとに操作性が変わってしまう
-
よく見かけるアプリ：あらゆるアプリ
どのボタンをクリックすれば作業が終了するのかなどがわからなくなります。
ユーザに冗長な操作を求めるパターン
- 起こっていること：ユーザに操作を求めなくても判断可能な要素をユーザに判断させている
- このパターンの嫌なところ：ユーザの業務時間を奪う
-
よく見かけるアプリ：アプリ間遷移もしくはアプリ内遷移を伴うアプリ
トグルボタンを選択したのち、Runボタンをクリックするような設計になっています。Runボタンは冗長です。
各アンチパターンへの対策
それぞれ次のように扱います。
ひたすら要素が羅列されたパターン
アプリ内で扱う要素をUX設計時に構造化します。構造化された各要素をそのネストの浅い順にsap.uxap.ObjectPageSectionクラス、sap.uxap.ObjectPageSubSectionクラスやsap.m.Titleクラスなどに割り当てます。
構造化されて見やすくなりました。
抽象度が揃わない要素が隣り合っているパターン
対策は“ひたすら要素が羅列されたパターン”と同じです。
順序関係が適切ではない
各要素を配置する前にFiori Design Guidelinesにおける各クラスのDon't UseとUsageを必ず確認します。現状はFiori Design Guidelineの記述が曖昧でSAPの作成したFioriアプリの実装にブレがあるところもまだ少しあるので、曖昧さを発見したらFioriのデザイン関連の問い合わせ窓口に報告してプロジェクト内の共通方針を決めます。
ページ全体に関わる内容や集約した内容はヘッダエリア、編集したりする内容はコンテンツエリア、ページ全体に関わる動作のトリガー（ボタン）はフッターエリアにおきます。これら3つの関係を間違えると容易にとてもあつかいにくいアプリを作ってしまいます。
また、あるユーザが特定の条件を満たせば使えるようになるボタンはdisable、そのユーザが使う機会を持たないボタンはinvisibleにします。ユーザのロールによっては使用できるからと全てのボタンを常にvisibleかつenableにすると、関係のないユーザに誤解を与えてしまいます。
ExecuteボタンもしくはSuspendボタンを押せば作業が終了しそうだとわかります。
ユーザに冗長な操作を求めるパターン
ユーザの操作をエッジ、それぞれの操作後の状態をノードおよびアプリの最終的な各状態をルート（ルートノード）としてそれぞれ有向グラフにまとめます。まとめたグラフのルートから順にエッジをたどって“その時点でアプリの状態は十分に決定可能か”を判断します。この判断を繰りかえし、十分に決定可能なノードが発見できたら、それ以降のエッジは冗長な操作として取り除きます。最後に、取り除いた部分のデザインを少し修正します。
操作の冗長さはなくなりました。
この対策例のボタン配置はものすごくダサいので、参考にしないでください。
さいごに
これらのパターンを悪いと断定するのに用いた計算などは、後日LT会などで共有します。
（共有した資料のリンクは本記事からも参照可能にする予定です）