オブジェクト指向UIデザイン
デザイン
人類の知能の発達要因
人類は、自身で作成した道具に作用され、その知能が発達してきた。
モードレスな(抽象度の高い)道具による相互作用
抽象度の高い道具(ナイフ:高、ピーラー:低)は、ユーザ次第(用途のアイディア・スキルの向上)で利便性が広がる。 モードレスな道具は、ユーザの変化で意味性を高めるという意味で、人と道具の相互発展をポジティブな方向に促す。 これが、モーダルなタスク指向デザインではなく、モードレスなオブジェクト指向デザインを行うことの意義。
一貫して作用する「原理」を備える
「万人に合わせたデザイン」ではなく、「万人が自ら合わせられるデザイン」が良いデザイン。 要求ごとに愚直に対応すると、典型的なタスク指向デザインになる。 「対象・行えるアクション・その結果」が見えれば、ユーザはその道具の役割と機能を自ら発見し、仕事を組み立てられる。
使いづらい事業者目当てのデザイン
ユーザ目当てではなく、事業者目当てで設計されたソフトウェアは使いにくくなる。 ユーザは自身の目当てを覆い隠され、ソフトウェアを使って何かをするのではなく、ソフトウェアによって何かをさせられている。
操作モデル
なぜオブジェクト指向なのか。在るがままに在るようにして作ると、それがオブジェクト指向になる。
オブジェクト指向UIとタスク指向UI
オブジェクト指向UI | タスク指向UI |
---|---|
名詞 → 動詞 | 動詞 → 名詞 |
オブジェクト(名詞)が手がかり | タスク(動詞)が手がかり |
モードレス | モーダル |
探索・創意工夫 | オブジェクトの選択不要・定型の入力手続き |
オブジェクト指向プログラミング | 手続き型プログラミング |
'hello'.toUpperCase(); |
strtoupper('hello'); |
オブジェクト指向UI
オブジェクト(ユーザの関心対象の構造的概念(メンタルモデル)であり操作対象)を手がかりに設計されたUIのこと。 「モードレス(モードがない)」に本質的な優位性がある。
オブジェクト指向とは
システムをデザインする際に主体(知覚する者)ではなく客体(知覚される物)をモデル化することに本質がある。 ソフトウェア世界の中に対象(オブジェクト)が存在し、そこへ何かしらのアプローチを起こす。 オブジェクトは自律的にそのアプローチへ反応し、自分自身を変化させたり、他のオブジェクトにアプローチを起こす。 このイメージが、抽象的なプログラミングと具象的なUIの間で一貫したパラダイムを作っている。
オブジェクト指向UIの原則
- オブジェクトを知覚でき直接的に働きかけられる
- オブジェクトは自身の性質と状態を体現する
- ユーザが状態を把握し、次の操作を判断する
- オブジェクト選択→アクション選択 の操作順序
- GUIの本当の特徴はこの操作構文にある
- すべてのオブジェクトがお互いに強調しながらUIを構成する
GUI
GUIは「グラフィック」に「オブジェクト指向UIの原則」を適用したものであるために、使いやすい。 コンピュータ内の情報を物のように感じさせ(メンタルモデルをコンピュータ内で模式的に再現し)、日常生活の作業と同じ感覚で扱える。 それらに対して自由に働きかけながら目的(タスク)を達成できるようにする。
優れたGUIに対してユーザが「マニュアルを読まなくても使える」と感じるのは、そもそも決まった手順がないため。 手順がなく、ユーザが好きな方法で目的に向かっていける。これがGUIの根本にあるモードレス性。
Sketchpad・Smalltalk
単なる計算機ではなく、人が試行錯誤しながら目的を達成していくためのクリエイティブな道具として、コンピュータを再定義した。 SmalltalkのUIが「モードレス」であることを重視していたのは、PCに求められる「誰でも使える」ことを実現するための根本的な条件だったから。 UIの表現が空間的なマッピングを利用したオブジェクト指向であることと、操作が非順序的でモードレスであることの間には、相互に強い必然性がある。
タスク指向UI
CLIのように動詞を起点として設計されたUIのこと。 「モーダル(モードがある)」であり、操作の自由度を奪い、余計な手続きを増やす。
タスク指向UIに陥る原因
ユーザのタスクをコンピュータが効率よく代行することがデザインの目的であると認識されているため。
問題点
全体像がはっきりしない
オブジェクトがタスクの中に閉じ込められ、タスクを開始しないと何があるのかわからない(アプリで扱う情報とその全体像がはっきりしない)。 これを「情報なき同意(その選択で目的が達成されるかわからないまま先へ進む状況)」と呼ぶ。
作業が中断される
モーダルダイアログは、ユーザの仕事を中断し特定の作業を強要するため、システムを使いにくくする。
混乱する
一つのスイッチがモードごとに異なる機能を持つと、ユーザは混乱し、モードエラーを引き起こす。
オブジェクト指向UIの設計
メインオブジェクトの一覧を早い段階で見せる。 一覧からオブジェクトを選択すると、情報の階層をドリルダウンして、選択したオブジェクトの詳細情報が表示される。 詳細情報のビューでは、オブジェクト単体に対するアクションが用意されている。 「オブジェクト選択→アクション選択」という操作構文をできるだけアプリ全体で踏襲する。 ビューは、「機能」を表す単位ではなく、「対象」を表すものになる。
基本ステップ
どのレイヤーから着手しても良い。各レイヤーを行きつ戻りつすることで、複雑な構造体に有効性を与えながらデザインする。 情報量が多く複雑なアプリほど、目に見える形にしてみて得られる気づきがある。
ユーザにはUIがシステムそのものであり、先にUIがデザインされるべき。 つまりプレゼンテーションが最優先であり、 その裏にある構造はプレゼンテーションとモデルの間の整合性をとるためのものに過ぎない。
ソフトウェアデザインのレイヤー
デザイナーのアブダクションライン
モデル|オブジェクトの抽出
ユーザのメンタルモデルや業務中にどのような概念が存在するかを調べ、ユーザの操作対象となるオブジェクトを提起する。 ユーザ自身が意識していない概念もうまく発見しなければいけない。 対象ドメインの範囲が広いか、範囲が漠然として場合は、アプリでサポートするドメインのスコープを決める。
オブジェクトの抽出ステップ
- タスクを書き出す
- 「名詞」を抽出する
- タスクの文言から名詞を探す
- ユーザの関心対象となる概念が何かを考える
- オブジェクトには「もの」的なものもあれば、「こと」的なものもある
- 一見同一な異なるオブジェクトを抽出するために、厳密に命名する
- 設置されている遊具 と 遊具の種類
- 仕入れ と 仕入れの明細
- 「名詞」とそれらの関係を整理する
- 「名詞」を汎化し、粒度を揃える
- 「名詞」の関係性をつなげ、オブジェクトを特定する
- 名詞同士をつなげ、ネットワーク状にする
- オブジェクトの特徴
- 数えられる名詞として表せる
- 同種の集合として管理され得る
- 共通のアクションを持っている
- 動詞的な概念や属性的な要素でもok
- 「メインオブジェクト」を特定する
- 主要なもの(メインオブジェクト)とそうでないもの(サブオブジェクト)に分ける
- 人の持つ優先度の判断能力に委ねる
- 関連を表す線の多さを目安にする
- メインオブジェクトの多重性を特定する
- 多重になるオブジェクトに「*」を付ける
- メインオブジェクトに付随するオブジェクトをプロパティとする
- タスクからアクションを見つける
- メインオブジェクトとアクションを結び付ける
- 「計算する」などはアクションではなくプロパティにする
インタラクション|ビューとナビゲーションの検討
モデルとプレゼンテーションをつなぐためのメカニズム。
ビュー
ユーザが画面上で実際に目にするひとまとまりの情報表示領域のこと。 ひとつのオブジェクトは複数のビューで扱われる。 同一オブジェクトが場面に応じて姿を変え、異なる場面や情報の詳細度で表象される。
ビュー表現には「コレクション」と「シングル」があり、基本的にはオブジェクトごとにそれぞれ用意する。 状況に応じて、どちらかのビューを省略することもある。
ビュー | 特徴 |
---|---|
コレクション | ひとつのビュー内に同種のオブジェクトを複数並べて表示する オブジェクトが持つ属性で重要なものだけ表示する |
シングル | ひとつのビューでオブジェクトひとつ分を表示する |
コントローラー
ユーザからの入力を受け取り、モデルを更新し、その結果をビューに反映する際の制御を行う。 ビューごとにコントローラーを設ける。 コレクションビューにおいては、表示する項目をDBから取り出す条件や、一覧における現在の選択状態が、コントローラーのプロパティとして保持される。 項目を新規に追加したり、既存の項目を削除したいりするアクションは、コントローラーが実行する。
ナビゲーション
オブジェクト間ナビゲーション
オブジェクト同士のつながりと多重性から参照可能性を導き出し、呼び出し関係を考える。
ルートナビゲーション
特に重要なメインオブジェクトを並べたもので、これがアプリの基本的な情報構造になる。 どれかを選択すると、そのオブジェクトのコレクションビューが表示される。
アイコンを一貫して利用することで、ユーザは情報構造全体の適切なメンタルモデルを持てる。 項目名に「〜システム」や「〜一覧」、「〜管理」などは冗長なので不要。
プレゼンテーション|レイアウトパターンの適用
一般化しているパターンを用いる。
ルートナビゲーション
スマホであれば下や開閉式、デスクトップであれば上や左に配置されることが多い。
ペイン
画面単位を変えることで、同一UIをデスクトップとモバイルに対応させられる。
1画面複数ペイン
ペイン間のインタラクションには方向性をもたせる。
- 左の操作が右に反映される
- 上の操作が下に反映される
1画面ペイン
スマホなどの表示面積が狭いデバイスに向いている。 1画面複数ペインよりも柔軟性が高い。
コレクションビュー
アプリの有効性を高める上で非常に重要な役割を果たし、アプリの性質をそのまま代弁する。
パターン | 特徴 |
---|---|
1項目1行の1次元リスト | 多くの項目を一覧させるのに適している |
1項目複数行の1次元リスト | リスト上である程度の情報を表示できる |
1項目複数行の1次元リスト(高さ可変) | SNSなどでよく用いられる |
サムネールのグリッド | イメージを強調するタイプ |
マッピング | カレンダーや地図など、2次元上にマッピングするタイプ |
アクション
一覧画面に追加・削除機能をもたせたり、新規追加・更新用の画面を共通化することは、定石のデザイン。
フィルタリング
タスクに準じた条件でオブジェクトを絞り込めるフィルタリング機能をコレクションビューに組み込む。
シングルビュー
アプリの機能性、ユーザのメンタルモデル、操作のコンテクストに合わせて変わる。
パターン | 特徴 |
---|---|
他コレクションの一部を表示する | 重要と思われるいくつかを先出しする |
他コレクションを強調する | すべてを表示するとコレクションが強調される |
他コレクションだけを表示する | フォルダとファイルのような表現になる |
アクション
オブジェクトに対して実行可能な一連のアクションボタンを一貫した表現で並べる。
Createアクションのパターン
パターン | 特徴 |
---|---|
ブランクパターン | 空のアイテムが作成される |
パラメータパターン | モーダルが現れて、必要なパラメータを入力 |
プレースホルダーパターン | 常に新規作成用のプレースホルダーを表示 |
セーブアズパターン | 既存のアイテムをコピーして別名保存 |
テンプレートパターン | テンプレートを選んで新規作成 |
マスターパターン | マスターから新規作成 |
ワンタイムモードパターン | 新規作成モードに入る |
ガッツパターン | デフォルトで作成 |
Deleteアクションのパターン
パターン | 特徴 |
---|---|
モーダルコンファームパターン | モーダルで確認を促される |
アンドゥアブルパターン | 「戻る」で取り消せる |
モードレスコンファームパターン | 確認がモードレスに表示 |
Updateアクションのパターン
パターン | 特徴 |
---|---|
モーダルエディットパターン | 参照と編集がモードで分かれ、「保存」ボタンがある |
モードレスエディットパターン | 常に編集可能で、自動保存 |
モードレスにする方法
アクションを分割する
モーダルなアクションを複数の「1ストローク即時実行」(モードレスなアクション)に分割する。
サブミットボタンをなくす
プロパティの個別変更でデータ不整合が生じる場合には、データバインド(自動で他のフィールドを変更して整合性を保つ)を利用する。 データバインドが使えない場合のみ、モーダルなサブミット式を採用する。
タスク
タスクは複雑なため、タスク優先でデザインすると複雑なアプリになる。 オブジェクトとアクションの組み合わせでタスクを遂行する。
タスクの特徴
- やり終えないとわからない(行動しながら考える)
- 粒度がさまざま(厳密に境界を定義できない)
- 増える
- 変わる
タスクの反映
反映先 | 補足 |
---|---|
コンテンツ | ヘルプやプロモーションなどで、代表的なタスクを限定的に説明する |
表示形式 | 特定のプロパティに関連したタスクでは、そのプロパティを強調表示する |
アクション | オブジェクトのアクションのバリエーションとして扱う |
初期値 | 良い初期値はユーザの作業効率を大きく引き上げる |
テンプレート | ユーザはテンプレートからタスクの作業文脈を得る |
フィルタリンググループ | フィルタでタスクを考慮し、場合によってはデフォルトで選択状態にする |