[Web標準の日々レポート]デザインパターンによるユーザーインターフェース革命（上野学氏・篠原稔和氏）

いまさら感たっぷりですが、Web標準の日々のレポートをお届けします。
自分用のまとめという意味も多分にあるので、何となく参考にしていただければ。

初日最初はソシオメディアのお二人のセッションでした。
部屋に入ると、机の上にモールが数本置いてあります。このモールをいじりながらセミナーを受けるのが海外の（一部の）セミナーでのトレンドだそうで。実は結構意味がある・・・らしいです。

「われわれの周りに存在するものはすべてデザインされている」 – Clement Mok
- 岡山の桃太郎弁当の写真（完璧にデザインされている）
「Quality without a Name（無名の質）」 – Christopher Alexander
- 言葉では言い表せない質。
- デザイナーは言葉に表せないものをデザインする。
- そのため、言葉で説明すること、ノウハウを伝えることは難しい
- 「階段は上れるだけじゃだめだ。すわれること、おしゃべりができること。」
- 「（アーケードなどの）柱は支えるだけでなく、寄りかかれなければならない」そういう余裕が必要
「テストはデザインの代わりにならない」 – Alan Cooper
- テストによって改善はできるがゼロから作り上げることはできない。
- UIデザインは芸術ではない。しかし同じように創造性が重要。
  - エレベーターのボタンのデザイン実例集（謎のNON STOPボタン）
「作業に対するニーズというものがユーザーごとに異なっているとしても、ユーザー集団は多くの一般的な心理属性を共有している」 – Jef Raskin
- ある程度多くの人が使いやすいと思うインターフェースデザインは共通している。
ロジカルデザインプロセス
- ユーザーセンタードデザイン
  - ユーザー観察（ペルソナ）
    - 社内ネットワークには「小田のコンピューター」というものがある（何年も前から活躍しているペルソナ）。
  - ユースケース、アクティビティ
  - ストラクチャマップ、ワイヤーフレーム
  - プロトタイプ
  - テスト
- 抽象―具象ギャップ
- デザイナー―プログラマーギャップ
  - プログラムのデザインとユーザーからみるデザインとはかなりギャップがある
タスクドリブンなデザインメソッド
- シナリオから「アクション：レスポンス」を分析し、ユースケースを構造化して、タスクと機能の対応リストをつくる
- タスクの優先度をもとに、対応する機能を
オブジェクトドリブンなデザインメソッド
- ユーザーの関心対象であるコアオブジェクトと画面との関係をクラス図で表す。
オブジェクト同士の静的な構造と操作フローとしての動的な展開→デザインパターン
デザインパターン（これが革命だと思っている）
- ものを生成するのに利用できる、形態、型、またはモデル。デザインのデザイン
- デザイナーのためのインターフェース（プログラムで言うAPIとか）
- A Pattern Language – Christopher Alexander
  - ある問題の文脈におけるソリューション。何回も使える。
- Design Patterns – Gang of four
  - 再利用可能な解法。デジャブを経験することがよくある。その時にどのように解いたかを覚えておけば、解法になる。
- デザイニング・インターフェース – Jenifer Tidwell
  - デザインのベストプラクティス。
  - ボキャブラリーとしての価値が高い
- SUI Design Patterns（ソシオメディアHP）
  - 現在公開されているものでまだ1/100くらい
  - 抽象レベルごとに体系化
  - 目的別に逆引き可能
  - キーワードで検索可能
  - フラットな構造を活かした相互リンク
- SUIデザインレイヤー
  - ポスチャー（概要、外観、基本コンセプトのようなもの）
    - モードレスインタラクション
      - 自然なモードの切り替え
    - モーダルインタラクション
      - まず動作を選ぶ
    - マルチウィンドウ
    - シングルウィンドウ
  - フィーチャー
    - リトリーバー（検索）
    - マニピュレーター
    - ビューワー（閲覧）
    - エディター（編集）
    - コンフィギュレーター
    - ベーシックDBマニピュレーター
  - トランジション
    - R-M-E（検索ー一覧ー詳細）
    - RM-E（検索一覧ー詳細）
    - ハブ型クエリーの組み立て
    - ドリルダウンのバリエーション
  - ストラクチャ
    - ２ペイン
    - ３ペイン
    - 自由帳
    - エンティティ・スクリーンストラクチャ
  - レイアウト
    - 右寄せ左寄せ
    - エッジのロックオン
  - ビヘイビア
    - オブジェクトのマルチ表現
    - 名詞→動詞
    - シングルクリック実行
    - PLD（検索・一覧・詳細）
- デザインパターンの今後
  - 今後（効率化のためには）デザインをパターンとしてとらえる必要がある
  - オンラインリファレンス
  - ソースコンポーネント
  - ウェブサービス
    - ページのテキスト版を作るというパターンがあったとする。
    - そういうASP(API)があれば、すぐに利用できる）
  - パターン間インテグレーション
    - パターン同士の相互接続

Q&A

Q:提案した内容がクライアントによって否定される場合はあるか、その割合は？

A:ほとんどすべて。提案が100%通るということはまずない。
それぞれクライアントによって事情が異なるし、それらを考慮して妥協点を探る。

考えてみれば当たり前のことだけど、きちんとできているところは少ないということかな。たとえば２カラムにするか３カラムにするか、プルダウンにするかラジオボタンにするかなど、無意識のうちに経験から判断していると思うけど、意識してデザインをパターン化、ストック、分類して引き出しを増やすことで、より適切なデザインの選択や効率化ができる、ということだろうと思います。

正直公開された資料を見返してみても、理解できていないところが多いです。UIとかIAとか、面白いんだけどいまいち雲をつかむような話なので、時間をかけてじっくり理解していくしかないのかな。

// 結局モールにどういう意味があったのかは分かりませんでした。。。

Q&A

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル