「オブジェクト指向 UI デザイン」の設計手順を整理

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 WEB+DB PRESS plus

書籍『オブジェクト指向 UI デザイン』を参考に、設計段階で必要となる作業と成果物を整理したもの。

題材

以下のタスクを例にして「商品管理アプリケーション」の画面デザインを考える。

ある仕入れの仕入れ ID と日付と合計金額を確認する

商品「カーボンペン C2-W」の商品 ID と過去の購入を確認する

ある仕入れで購入した全商品の商品名、単価、個数を確認する

商品名を変更できる

1. model: オブジェクトの抽出

(1) 要件や業務から「名詞」を抽出する

要件文・業務記述・ユーザーストーリー・既存画面・帳票などから、UI が扱う対象を表す「名詞」を抽出する。

「名詞」とは、文の中で次の役割を持つ語である。

• 主語
• 目的語
• 補語
• 名詞化できる述語

ある『仕入れ』の『仕入れ ID』と『日付』と『合計金額』を確認する

『商品「カーボンペン C2-W」』の『商品 ID』と『過去の購入』を確認する

ある『仕入れ』で『購入した全商品』の『商品名』、『単価』、『個数』を確認する

『商品名』を『変更』できる

(2) 「名詞」同士の関連を抽出する

『仕入れ』は、『仕入れ ID』を持つ

『仕入れ』は、『日付』を持つ

『仕入れ』は、『合計金額』を持つ

『商品』は、『商品 ID』を持つ

『商品』は、『過去の購入』を持つ

『仕入れ』は、『購入した全商品』を持つ

『購入した全商品』は、『商品名』を持つ

『購入した全商品』は、『単価』を持つ

『購入した全商品』は、『個数』を持つ

『商品名』は『変更』できる

flowchart LR
  a[仕入れ]
  b[仕入れID]
  c[日付]
  d[合計金額]
  e[商品「カーボンペン C2-W」]
  f[商品 ID]
  g[過去の購入]
  h[購入した全商品]
  i[商品名]
  j[単価]
  k[個数]
  l[変更]

  a --- b
  a --- c
  a --- d
  e --- f
  e --- g
  a --- h --- i --- l
  h --- j
  h --- k

(3) 「名詞」を汎化し、粒度を揃える

それぞれの名詞から共通項を見つけ、複数の名詞を何か別の 1 つの名詞にできないか検討する。

flowchart LR
  a[仕入れ]
  b[仕入れID]
  c[日付]
  d[合計金額]
  e[商品]
  f[商品 ID]
  g[（過去の）仕入れ明細]
  h[仕入れ明細]
  i[商品名]
  j[単価]
  k[個数]
  l[変更]

  a --- b
  a --- c
  a --- d
  e --- f
  e --- g
  a --- h --- i --- l
  h --- j
  h --- k

• 購入した全商品 を 仕入れ明細 と汎化
• 過去の購入 を (過去の)仕入れ明細 と汎化

(4) 「名詞」同士の関係を全体で整理する

「名詞」同士をさらにつなげて、アプリケーション全体を通じた関係性を整理する。

flowchart LR
  a[仕入れ]
  b[仕入れID]
  c[日付]
  d[合計金額]
  e[商品]
  f[商品 ID]
  h[仕入れ明細]
  i[商品名]
  j[単価]
  k[個数]
  l[変更]

  a --- b
  a --- c
  a --- d
  e --- f
  a --- h --- e --- i --- l
  h --- j
  h --- k

(5) 作成したグラフより「メインオブジェクト」になるものを特定する

「メインオブジェクト」となる条件。

• この関心領域において、主要なオブジェクトである
  • UI 上で主対象として扱いたいオブジェクトのこと
• コレクション・ビュー / シングル・ビューを持ちうる
• 関係を表す線が多い
  • ユーザーの関心事のハブになっている、ことを意
  • ただし、プロパティの集合であるだけの場合もあるので注意

flowchart LR
  a[[仕入れ]]
  b[仕入れID]
  c[日付]
  d[合計金額]
  e[[商品]]
  f[商品 ID]
  h[[仕入れ明細]]
  i[商品名]
  j[単価]
  k[個数]
  l[変更]

  a --- b
  a --- c
  a --- d
  e --- f
  a --- h --- e --- i --- l
  h --- j
  h --- k

(6) メインオブジェクト同士の多重性を特定する

classDiagram
  class 仕入れ{}

  class 仕入れ明細{}

  class 商品{}

  仕入れ --> 仕入れ明細 : 1 to 1..*
  商品 --> 仕入れ明細 : 1 to 0..*

(7) メインオブジェクトに付随する情報を「プロパティ」とする

• 単独で操作対象にならない「名詞」は「プロパティ」となる
• メインオブジェクトはプロパティにはならない

classDiagram
  class 仕入れ{
    仕入れID
    日付
    合計金額
  }

  class 仕入れ明細{
    単価
    個数
  }

  class 商品{
    商品ID
    商品名
  }

  仕入れ --> 仕入れ明細 : 1 to 1..*
  商品 --> 仕入れ明細 : 1 to 0..*

(8) メインオブジェクトに付随するタスクを「アクション」とする

オブジェクトに対して実行されるタスクのうち、表示するだけでは完結しない操作を「アクション」として定義する。

classDiagram
  class 仕入れ{
    仕入れID
    日付
    合計金額
  }

  class 仕入れ明細{
    単価
    個数
  }

  class 商品{
    商品ID
    商品名

    商品名を変更する()
  }

  仕入れ --> 仕入れ明細 : 1 to 1..*
  商品 --> 仕入れ明細 : 1 to 0..*

2. interaction: ビューとナビゲーション（ビュー同士の呼び出し関係）の検討

(1) メインオブジェクトに「コレクションビュー」を与える

flowchart
  a[コレクション：仕入れ]
  b[コレクション：仕入れ明細]
  c[コレクション：商品]

(2) メインオブジェクトに「シングルビュー」を与える

flowchart
  a[コレクション：仕入れ]
  b[コレクション：仕入れ明細]
  c[コレクション：商品]
  d[シングル：仕入れ]
  e[シングル：仕入れ明細]
  f[シングル：商品]

  a --> d
  b --> e
  c --> f

(3) 「コレクションビュー」と「シングルビュー」のナビゲーション（ビュー同士の呼び出し関係）を整理する

呼び出し関係とは参照元から参照先へ矢印を結ぶこと。

この情報はビュー同士の関係を意識したもので、いわゆる画面遷移図にはあたらない。実際の画面では、「あるシングルビュー」内に「呼び出し関係のあるコレクションビュー」を含めて、1 つの画面として構成することも充分にありえる。

flowchart
  a[コレクション：仕入れ]
  b[コレクション：仕入れ明細<br>（仕入れ別 / 商品別）]
  c[コレクション：商品]
  d[シングル：仕入れ]
  e[シングル：仕入れ明細]
  f[シングル：商品]

  a --> d
  d --> b
  b --> e
  e --> d
  e --> f
  c --> f
  f --> b

コレクション：仕入れ明細 は、参照元別に（画面遷移元別に）表示される条件が異なってくる。

(4) メインオブジェクトの中からルートナビゲーション項目を選定する

ルートナビゲーション項目選定の目安は、全体から考えて特に重要なオブジェクトを選ぶこと。ユーザーがアプリケーションを使う際に、思考の起点になりそうなオブジェクトを選定する。

仕入れ

商品

3. presentation: layout pattern の適用

(1) ルートナビゲーション項目の配置パターンを検討する

配置パターン。

• スマートフォン UI
  • 画面下部
  • 画面左で開閉式
• デスクトップ UI
  • 画面上部
  • 画面左

(2) ビューの配置パターンを検討する

コレクションビューとシングルビューの関係を画面上で表すために、「画面をどのように区切るか」もしくは「別々の画面で管理するか」を検討する。

配置パターン例。

• メインオブジェクトが単一
  • (1) コレクションビューとシングルビューを、別々の画面で管理する
  • (2) コレクションビューとシングルビューを、同一画面でペインを分けて配置する
• メインオブジェクトが複数
  • (3) ルートナビゲーションを配置し、コレクションビューとシングルビューを、別々の画面で管理する
  • (4) ルートナビゲーションを配置し、コレクションビューとシングルビューを、同一画面でペインを分けて配置する

(1) または (3) のパターンは、スマートフォンなど画面面積が少ない場合に向いています。また画面面積が多いデスクトップでも、メインオブジェクト同士が参照し合ってナビゲーションがループする場合には有効です。

(2) や (4) のパターンは、オブジェクトを横断した呼び出しがない場合に使用するとよいでしょう。

デスクトップの広い画面面積を複数のペインに区切る「シングルウィンドウ」式のレイアウトよりも、スマートフォンの狭い画面の中で一度に 1 つのコレクションビューまたはシングルビューだけを見せて次々と画面遷移する方式の方が、オブジェクトの呼び出し関係を作る上では柔軟性が高いのです。

(3) コレクションビューの表示形式を検討する

コレクションの性質に合わせて表示形式を検討する。以下は書籍で紹介されている表示形式パターン。

• 1 項目 1 行の 1 次元リスト
• 1 項目複数行の 1 次元リスト
• 1 項目複数行の 1 次元リスト (高さ可変)
• サムネイルのグリッド
• マッピング

(4) コレクションのフィルタリング・パターンを検討する

UI をオブジェクト指向にするためには、オブジェクトのコレクションビューをできるだけ早い段階で表示します。しかしあるオブジェクトの全項目を一度に表示すると、数が多すぎて目的の項目が見つけづらくなる場合があります。

その場合には、フィルタリング機能をコレクションビューに組み込むことで、タスクに準じた条件ですぐに表示を絞り込めるようになります。

オブジェクトの性質やユーザーのタスクに応じて、適切なフィルタリング・パターンを検討する。以下は、書籍で紹介されているフィルタリング・パターン。

• キーワード検索
• グループ
• AND 条件
• クエリビルダー
• ソート

(5) シングルビューの表示形式を検討する

シングルビューには通常、あるオブジェクトについての詳細情報が表示されます。しかし、詳細情報の捉え方は、アプリケーションの機能性、ユーザーのメンタルモデル、操作のコンテキストなどによって変わります。

例えば、箱そのもののサイズではなく、箱の中身を詳細と捉えたり、音楽アルバムそのものの情報ではなく、収録曲を詳細と捉えたりします。こういった詳細の場合には、「開いて中のものを見ているよう」なイメージになります。

詳細情報を適切に表現するには、あるオブジェクトに関連するさまざまな情報を必要に応じた粒度で集め、シングルビューの性質や用途に合わせて表示形式を決定していきます。

音楽アルバム と 収録曲 の関係は、まさに 音楽アルバム というシングルビューの詳細が 収録曲 というコレクションビューとなっている関係にあたります。

こういった場合に採用できるパターンとして、書籍で紹介されているもの。

• 他のオブジェクトのコレクションの一部を表示する
• 他のオブジェクトのコレクションを強調する
• 他のオブジェクトのコレクションだけ表示する

(6) アクションの表示形式を検討する

基本は、アクションを実行するためのボタン、もしくはそれに準じたコントロールを、アクションの対象となるオブジェクトの近くに配置することです。

以下は書籍で紹介されている CRUD ごとのパターン。

• Create
  • Blank Pattern
  • Parameter Pattern
  • Placeholder Pattern
  • Save As Pattern
  • Template Pattern
  • Master Pattern
  • One-Time Mode Pattern
  • Guts Pattern
• Delete
  • Modal Confirm Pattern
  • Undoable Pattern
  • Modeless Confirm Pattern
• Update
  • Modal Edit Pattern
  • Modeless Edit Pattern