Android Usabilltiy Seminar 2010に行ってきた
場所：代々木ビジネスセンター二号館
13:20に開始
http://itpro.nikkeibp.co.jp/android/AUS2010/index.html
◆13:05〜13:55 使いやすさをデザインするということ
講師：山中俊治氏（慶應義塾大学大学院教授、LEADING EDGE DESIGN代表）
タッチパネル操作可能なスマートフォンは、幼い子どもでも扱えるユーザー・インタフェースを実現している点で画期的なデバイスです。
説明抜きに直感的に使えるユーザー・インタフェースは、どこがポイントで、どうやって実現できるのでしょうか。
本セッションでは、「Suica」対応自動改札機など多くの工業機器のデザインを手掛けた山中氏の講義を通じて、「使いやすさとは何か」「使い勝手（ユーザビリティ）検証の在り方」などを学びます。
●導入
マンガを書くのが趣味だった
マンガを抱えて日産に行ったらプロダクトデザイナーにしてもらえた
車やカメラ、時計などを手がけた
色や形だけではなくて機能や使い勝手 いわゆるファンクションの設計にも関わっている
つかいやすい、さわりたい、ほしい、わくわくする 人間の感じることにかかわれたらよいと思っている
●ユーザビリティ調査について
Suica自動改札機アンテナ面の最適化に関わった
直感だけではうまくいかないのでプロトタイプをなんこも作って最適なものを探り当てた
ユーザに説明をしないでSuicaをどうかざすかを探り当てた
ユーザの行動にフィットさせる形を探した
人間は傾きがあるものに対しては動作を止めてくれた
人間は光っているものに惹かれる
「触れてください」とかいておくとカードをかざしてくれる
インジゲーターは遠くに置かないと混同する
●ユーザビリティ調査のポイント
一期一会と考え、周到に準備する
二度と同じことはやれないことが多いので一発でやるつもりで進めたほうが良い
開発者同士が自分自身の経験で語るので意見や使い方が衝突する
被験者に負担をかけないように配慮する
何分も待たせないようにする
多重の記録装置と多数の観察者
被験者の表情なども観察する必要がある
分単位のタイムテーブルとマニュアルの整備
他の被験者の真似をされないようにひとりづつやらなければならないので時間がかかる
被験者への説明は全く同じにしなければならない（マニュアル化する）
使い方のヒントを与えないようにする
実際の使用環境に近くする
テストは企画の一環である
最終確認ではない
フレキシブルなプロトタイプを用意する
早めにテストする
少数の被験者をていねいに観察する
観察の直後にアイデアを出し合い、速やかに実装、再び調査を行う
→ 出来る限り早く実装し再度テストする できればその場で変更する
参加することに意義がある
企画者自身も他人の前で使ってみる
被験者の行動を関係者全員で観察する
被験者の体験・問題点を共有しなければならない
体験と問題点の共有が出発点
キーパーソンの参加（報告書を見るだけではダメ）
キーパーソンの思いつき、体験だけで語るのはダメで実際に被験者の問題点を見て、認識する必要がある
ケータイのフェリカの端末側、リーダライタも設計した
ケータイはモックでPCにつながっていてUIはFlashで設計した
結果としてはケータイ側でなにも反応を返さないほうが良かった
リーダライタ側が反応を返したほうがよい
ケータイ側でなにか表示させようとするとディレイが長くなる
ユーザビリティのテストは自分たちが思ったものと違う方向になることのほうが多い
●キッチンツール（OXO）のユーザビリティテスト
レイドル
アメリカでは太いグリップで手で握るが
東洋人はペンを持つように指を使って握る
トング
アメリカ人握るようにもつ
東洋人はピンセットのようにもつ
丁寧に観察して写真などで比べてみることが必要
大根おろし
各家庭に二個か三個あるが使い勝手が良いものがないのでユーザビリティテストを行った
刃にランダムさがないとうまくすれない
職人が作った昔ながらの大根おろしはきれいにすりおろせるが、機械で作った大根おろしは一定の方向に刃が向いていて轍のようなものができてすれなくなってしまう
殆どの人が取っ手を使わずに、大根おろしの本体を押さえていることがわかった
3000円近い大根おろしになったが売れている
●時間がないとき
被験者を減らす（内容を薄めるのは危険）
ひとりでも、ふたりでもその装置について知らない人に被験者になってもらう
クライアントに参加してもらう
クライアントに納得してもらう為にその場で見てもらう
説得に時間がかかる
早いうちにやる
プロトタイプマシンを用意する
後で膨大な手間とコストをかける
皮肉です
例えば新幹線の改札機 二枚切符を入れるというのは開発としては素晴らしいが、ユーザのメンタルモデルとしては二枚入れることを考えないので
駅に二、三人立っていて説明しなければならなくなった
改札機に赤い文字で二枚入れてくださいと説明しなければならない
●iPhoneは1歳4ヶ月の子どもでも動かせる
アイコンや記号、文字で説明しなければならない機能は子供では操作できない
何をやってもまずいこと（失敗）が起きないことが重要
警告（アラート）は子供は喜んで押してしまう
●QA
・どういう人が被験者に向いているか？
開発者や経験者、社内の経理の人は向かない
どうしても一人しか選べないのならば商品のメインターゲットに近い人を選ぶ
太っている人やお年寄りなども使えるか試してみたほうが良い
思ったことをはじから話してくれる人のほうが良い
・ユーザビリティテストで啓蒙をしないほうが良いのか？
啓蒙をしようと、しまいと商品が世に出て普及しまったら
ユーザが変化してしまうので結果的に啓蒙してしまう
もちろんテストの開始時に啓蒙・説明をしてはいけない
・アイフォンベイビーはタッチパネルネイティブだが我々はペンのネイティブ・・・？？？
わかった気にはなるが、半年経つと感覚が変わってしまう
キッチンツールなどベーシックなものは一年、二年経っても変わらない
◆14:00〜14:50 Flash PlatformによるAndroidアプリ開発のこれから
講師：Flashデベロッパー／テクニカルライター 池田 泰延氏
Android OSは2.2以降Flashに対応するようになり、表現力が向上することが期待されています。
本セッションでは、先日開催されたアドビシステムズ主催の「Adobe MAX 2010」の報告を交え、
「Adobe AIR 2.5を用いたアプリ開発」「スマートフォンでのFlash Player 10.1とHTML5」などを解説します。
●ADOBE MAX 2010レポート
・次世代Flash PlayerはGPUが熱い
3D API
Flash Playerの新しい3DのAPI
0％CPU（GPUで処理）
DirectX9,OpenGL1.3,OpenGL ES2,ソフトウエアレンダリング
現状のポリゴンはFPS30で1000〜3000程度だが、およそ百倍のポリゴンが表示可能
大量の陰影や炎などの表示が可能になった
StageVideo
GPUを利用したビデオ再生
現状はデコードまではできるがエンコードはCPUで演算していた
動画の上に画像を合成してもスムーズに表示ができる
●Adobe AIR 2.5を用いたアプリ開発
・マルチ環境 Mac、Windwos、Linux、TV、モバイル
いままではデスクトップアプリケーションだったが
タッチスクリーン式のアプリやタブレット向けの開発も行えるようになった
・Air for Androidで開発されたアプリケーション
宇宙船着陸アプリ
傾きセンサーや加速度センサーを利用したアプリ
・オーサリング環境
AIR SDK
コマンドラインだがフリー
Flash Professional CSS(Extension for Adobe AIR 2.5)
タイムラインアプリケーションに特化している
時間の流れに沿って柔軟に作れる Photoshop/Illustraterとの連携に優れている
端末に直接転送できる、apk作成もできる
Flash Builder Burrito
Flexフレームワーク
Eclipse向け
RIA向け
端末に直接転送できる、apk作成もできる
いろんな端末でのエミュレーションができる（Android SDKのエミュレータではない）
UIの作成が簡単で、ネイティブアプリのUIより綺麗
・Flex SDK Hero
コマンドラインだけどUIはFlash
・各ブラウザのHTML5対応状況
http://www.html5test.com
●HTML5とFlashの機能比較
ブログに載せています
Flashは1社独占だがその分開発スピード、機能追加が早い
モバイルでHTML5のCanvasとFlashで比較してみた
・3DはHTML5だと重いが、Flashだとサクサク動く
・線のレンダリングはHTMLだとちょっと重いが、Flashだとサクサク動く
Android版のFlashはGPUで処理しているのでHTML5よりも速い
スクリプトは比較していないがあまり変わらないと思う
●QA
・Flash10.1は標準搭載か？
標準搭載かどうかはわからないがMarketからダウンロード出来る
・Android端末は乱立しているがパフォーマンスの違いを吸収できるか？
パフォーマンスに影響は当然出る
機種間の差は古い端末を基本に考えて開発すれば良い
・Androidは画面幅が乱立しているが解像度の違いの吸収はできるのか？
Flex FrameworkのHeroは画面サイズに合わせてフィットする
Flashの仕組みで画面幅のパターンを3パターン〜4パターンそんざいする
固定幅、縦横比固定で画面幅にフィットさせる、縦横比を保ったままフィットさせる
固定幅で作成して、余白の情報を取得して自力で動的に表示することもできる
◆15:10〜16:00 ユーザビリティと満足度向上の勘所 デザイン・イン型UI開発と３Dの活用
講師：エイチアイ インタフェース技術部門デザイン課 工藤重人氏
本セッションでは、モバイル端末向けユーザー・インタフェース（UI）デザイン開発の経験を踏まえ、ユーザビリティと満足度の向上方法などを解説します。
さらに、Androidアプリで注目を集める3次元（3D）グラフィックスのUIへの適用についても、各種アプリケーションにおける実現方法を紹介します。
●デザイン・インとは
上流工程・開発のはじめの段階でエンドユーザを意識した開発をすすめる
製品化直前ではなく、利用者視点でUIを改善するために仕様決定前にユーザビリティテストを行ったほうが良い
●具体的なユーザビリティテスト
利用者の声を反映できるだけでなく、デザインに一貫性が増す
カラオケのリモコンのテスト
・60代の女性の場合はメモを取り出して直接番号を入力し始めたりする
→ 番号入力を分かりやすい位置に変更した
・目が不自由な方
ヘルパーさんが同行して曲を予約している
→ 音声読み上げ機能を追加した
ユーザビリティテストをナレッジ化して次の機会にも活かす
●満足度向上の為のエスノグラフィー
利用者の観察
入力・ユーザの行動ログを蓄積して利用することができる
ログを4つに分類した
・ユーザの行動ログ
・行動ログを解析・表示向けに最適化したもの
・表示向けログから時間帯別の推薦IDを記載したもの
・推論結果に対する修正履歴
デモアプリ
ユーザが過去に利用したサイトから未来に表示するサイト・機能を予測する
未来の予測を編集することができる
開発途中 ３Dライブラリの会社なので３Dバリバリ使っています
独自の学習／推論アルゴリズムを利用している
Xperia、Desireで動きます
●自社開発のコンポーネントの紹介
３Dを描画させる機能
３Dと２Dを混在させるコンポーネント
３DのListView
3Dトランジション
裸眼立体視が容易になる（昔のiアプリと互換性がある）
CとJNIを利用しているのでJavaからOpenGL ESを呼び出すよりも2倍から3倍速い
IS03向けのフィットネスアプリで使われている？？？
●開発効率と長期的ユーザビリティ
開発効率化のポイント
早期にターゲットを見極め、以下にユーザの求める声を取りいれるか
要素技術に着目し、パフォーマンス・クオリティ面を早期に解決する
長期的ユーザビリティのポイント
コンテキストを取得し、利用する
評価ポイントをサイクル化させ、次なる課題をナレッジ化する
●二極化と飽和
●QA
・二次元ディスプレイで３D UIだと2Dより情報量が減ってしまうが利点はあるのか？
ジレンマがある
ボタンを押したときのフィードバックに３Dを利用するのもよい
トランジションとかで徐々に試している
◆16:05〜16:45 「アメーバピグ」に見るデザイナーと開発者の協業
講師：サイバーエージェント 新規開発局 システムディベロップメントグループ 切通伸人氏
サイバーエージェント 新規開発局 フロントクリエイティブグループ 馬場絵美氏
パソコン版で約500万人のユーザーを集めているサイバーエージェントのコミュニティサービス「アメーバピグ」が、
11月1日にAndroid端末向けアプリ「アメーバピグfor Androidβ版」をリリースしました。同アプリはAndroid 2.2に対応、
10月に発表されたばかりのAdobe AIR for Androidを活用しています。本セッションでは、同ソフトの開発プロセスを紹介、
アメーバピグfor Androidβ版におけるデザイナーとソフトウエア開発者の協業、スマートフォンならではのユーザビリティを実現するためのアプローチなどを学びます。
●pigg for Androidβ
pigg自体は５０名で開発
11/1にアプリ版はリリース
5人（ディレクター２名、開発者２名、デザイナー１名）
業務外でひっそりと開発
１ヶ月半で開発、業務時間外で開発
●ワークフロー
・デザインチーム確認
・プロジェクトチーム確認
・アートディレクター確認
・プロデューサー確認
・社長確認
１ヶ月半で開発するにはどうすれば良いのか考えた
デザイン確定後、変更や修正が多発する
デベロッパーの業務が巻き戻る
→ Mockを作って実機で確認する
重要なキーパーソンに聞いてまわった
→ 明確なゴールをディレクターが決めてブレを起こさないようにした
デザインチェックを通常行うが今回のメンバにはデザインチェックをする人がいなかった
普段はワークフローどおり五名それぞれの承認が必要だったが
改革を行い５０名のユーザレビューを行ってもらった
５名もその５０名に混ざってユーザー目線の評価を行った
レビュー会実施して通常の確認系統を補完した
●そもそも、Androidで動くの？
Android2.2からFlash Player10.1が動く
デバイスはネクサスワンを入手しておこなった
ブラウザでさわるとアドレスバーが邪魔、IMEが邪魔でチャットが出来ない、ボタンが小さすぎて押せない
AIR for Androidで移植した
移植は簡単だったのでデザインに注力した
●デザインについて
機能を絞ってアイコンを減らした
主要機能のアイコン化した、メニューボタンを作成しその中にアイコンを移したり
アイコンを単純化した
●画面サイズ
ネクサスワンの解像度をもとに開発した
Androidアプリではミスタッチを防ぐために余白を十分にとった
ボタンを縦配置にしてしまうとミスタッチをしてしまうので横配置にした
（指の腹で押すのか、先で押すのか人によって異なるため）
●開発環境
Flash Builder4
AIR SDK2.5
Android SDK
ネクサスワン
移植が簡単だった理由
・汎用性のある設計
フレームワークが疎結合になっていたので
ほとんどView層の変更だけですんだ
・元々スペックの低いPCでも動作するように開発していた
パフォーマンスチューニングせずに済んだ
●問題
ギャラクシーSだとマーケットにアップしたが検索ヒットしない
５方向ナビゲーションが付いていないのが原因だった
●これから
基本的な機能しか追加していないので機能追加します
GPSなどを使用したいAndroid独自の機能
海外版のPicoも
●課題
今後増えてくる画面サイズへの対応
PC版とのソース管理
PC版のFlashを動的に読み込んだりしているのでAndroid側で落ちてしまうことがある
●QA
・ユーザ５０名でのレビューはどのように行なったのか？
社内の人間でリテラシーの低い人間を集めて３回から４回に繰り返して行なった
・デザイナー、開発者、ディレクターは近くで開発していたのか？
階が別々で離れている
やりとりをスムーズにする秘訣は作ってしまった方が速い
開発者が試しにリサイズしてみて実際に見せたりしてデザイナーとコミュニケーションをとっていた
