2013年11月30日土曜日

動画番組 Android Design in Action: Our Favorite Design Details の概要

2013 年 11 月 26 日に公開された動画番組 "Android Design in Action: Our Favorite Design Details" では、Google 社員が それぞれお気に入りの Android アプリについて、その中でも特に優れた UI/UX デザインの表現手法の細部について紹介しています。 この番組には、 Android Design ガイドラインを執筆・提供している Android Design チームの社員も出演しています。

この動画番組の概要を日本語で作成しましたので、こちらに掲載いたします。 皆さまの Android アプリの UI/UX デザインをご検討いただく際のヒントとしてご活用いただけましたら幸いです。

この番組の出演者は下記のとおりです (出演順):
  • Roman Nurik - Developer Advocate, Android - New York
  • Rachel Garb - Interaction Designer, Android Design - Mountain View
  • Marco Paglia - Interaction Designer, Android Design - Mountain View
  • Nick Butcher - Developer Advocate, Android - London
  • Richard Fulcher - Interaction Designer, Android Design - Mountain View
  • Mike Denny - Developer Advocate, Android - Mountain View
  • Adam Koch - Developer Advocate, Android - New York


Foursquare の検索結果の階層表現 [再生時刻 01:14] - Roman Nurik

  • Foursquare (Google Play リンク) というアプリは、すでにご利用いただいている人も多いかと思います。
  • ここでは "Pizza" のような言葉を検索するときの優れた UI/UX 表現について紹介します。
  • 検索フィールドにフォーカスをあてます。文字を何も入力しなくても、検索フィールドの下に主な遷移先や検索機能のリストが表示される点は便利です。
  • "pizza" と入力してみます。すぐに、その言葉に関連する人気の検索ワードのリスト ("pizza hut", "pizza place" など) が表示されるのもいいですね。ここでは "pizza" を選んでみます。
  • 画面が検索結果の表示に遷移します。遷移の直後に、地図がなめらかに拡大していき、左右の 2 ペーンに分かれた表示になります。
  • 検索結果の表示が秀逸です。ここには、非常に多くの情報がコンパクトに表示されています。たとえば、 Amici's East Coast Pizzeria の項目の中を見ると、そこには "$" サイン (価格帯)、そこに行ったことがある私の友人の画像などが表示されています。とくに友人の画像は、「そこが重要な場所 (良い検索結果) かもしれない」というシグナルを表現しています。レストランの点数 (レーティング) も表示されています。
  • スクロールすると、情報の階層構造がとても見やすく表現されていることがわかります。それぞれのレストランの種類、誰がそこに行ったことがあるか、などが一目でわかります。Typography (文字フォント、色、サイズ、太さの選択) も見やすく、Roboto Light などのフォントが上手に使われています。このリストの中では、ピザの種類について繰り返されている情報は冗長ですので、ユーザーの認識の邪魔をしないように他の文字よりも薄い灰色で表示されています。
  • リストをスクロール操作するということは、ユーザーが まだ良い場所を見つけていない可能性があるという文脈に着目し、このアプリではスクロール操作を始めると そのリストの最下部に新たなバーが出現し、ユーザーに代替提案をします ("Or try..." と表示されているバー)。 この例では、food, dinner, italian, lunch, restaurant, というような選択肢が提案されています。 このような、ユーザーの文脈に応じた動的な表現は、検索をする体験をさらに優れたものにしています。
  • 他にも、右側の地図をタッチすると、左側のリストの対応する項目が (画面外であれば そこまで滑らかにスクロールして) ハイライトされる、というような優れた表現がこのアプリでは用いられています。
  • 私は、このアプリの検索のときのユーザー体験、とくに情報の階層的な表示の方法、文脈に応じた動的な表現が洗練されていると思います。


airbnb の基本に忠実な仕上がり [再生時刻 05:05] - Rachel Garb

  • こんにちは、Android Design チームの Rachel です。 airbnb (エアビーアンビー) というアプリ (Google Play リンク) のお気に入りの点について紹介します。
  • 何よりもまず、ログインや登録の必要がない点は便利です。アプリを起動するとすぐに、ログインも登録もせずにコンテンツを見ることができます。
  • コンテンツは、たいへん美しい内容です。高品質な写真が大きく表示されています。Typography (文字フォント、サイズ、太さの選択) も洗練されており、重要な情報 (価格) も 見やすく配置されています (写真の下端が薄暗いグラデーション表示となっており、そこに白い太字で価格を表示)。
  • それぞれの宿泊施設の詳細画面に遷移します。画面遷移時のアニメーション (transition; 左右方向の画面のスライドのアニメーションおよびロード中であることを示す控えめなアニメーション表示) は少しの間の待ち時間を良い体験にしています。 前の画面と同様に高品質な写真、洗練された Typography が用いられています。
  • 詳細画面では、左右方向のスワイプ操作により、すべての詳細な情報を すぐに確認することができます。 その画面での重要な機能 ("Book It" と "Contact Host") も判りやすく、大きく表示されています。
  • その宿泊施設について他の人と話したいときに用いることのできる「共有」機能も、Action Bar から すぐに利用できるようになっています。
  • これらの高品質な写真、美しい文字フォント、アニメーション表現 (transition)、スワイプ操作、共有機能は、「宿泊施設を選ぶ」という単調になりがちな作業を 楽しいものにしてくれています。


Google Play ニューススタンドの Action Bar 表現 [再生時刻 06:13] - Marco Paglia

  • こんにちは、Android Design チームの Marco です。 リリースされたばかりの Google Play ニューススタンド (Google Play リンク) というアプリについて紹介します。
  • これが Google Play ニューススタンド アプリです。 他の典型的な Google Play アプリと同様に、 Navigation Drawer を採用しており、アプリ内の主要な各セクションへの遷移を提供しています。
  • 各画面を最初に訪れたときに、その画面の概要 (目的) をお伝えするためのカードが表示されます。 たとえば、 "Get started with My News" というカードでは My News 画面の目的を紹介。 "Welcome to Google Play Newsstand" というカードでは、Google Play ニューススタンド アプリの目的を紹介しています。 これらのカードは、用が済んだら そのままカードの下にある "Got it" ボタンをタップすると表示されなくなります。
  • アニメーションをさまざまな場面で活用しています。すべての表現は滑らかです。
  • 各ニュースソース (媒体) および話題を選択する画面に行ってみましょう。 The Verge, New York Times といったニュース媒体に加えて、主な話題がリスト表示されています。 それぞれの話題には、違った色が割り当てられていることにご注目ください。 ここでは、"Google Play" という話題は水色、 ”Google" という話題は赤紫、"Architecture" という話題は紫で表示されています。
  • 試しに "Architecture" という話題を開いてみます。 すると、 Action Bar の色がその話題の色 (紫) に変化します。 ここで、画面の左端をスワイプして、 Navigation Drawer を引き出してみましょう。 Action Bar の色が少しづつ変化し、Navigation Drawer が引き出された状態では ニューススタンド アプリそのものの色 (青) に変化します。 このような色の滑らかな変化により、「特定の話題」という文脈と、「アプリそのもの」という文脈の間を行き来していることをユーザーに伝えています。
  • "The Verge" というニュースソース (媒体) を見てみましょう。 私たちは、いくつかのニュースソースについて、とくに感情的に豊かな表現をしたいと考えました。 背景の写真画像が、 Kent Burns effects に似た感じでアニメーションしています。 この画面をゆっくり指でスクロールすると、The Verge のロゴ画像は画面左上 (Action Bar の App Icon の位置) にスライドし、ニュースソースの名前 ("The Verge") が透過アクションバーの中に現れます。
  • 記事本文の画面を見てみましょう。 New York Times の記事を見ると、文字フォントは通常のフォントではなく、 New York Times のフォントが用いられています。 このような方法で、それぞれのニュースソース (媒体) の特色を表現しようとしています。 また、無料で読める範囲に制限をつける方法の一つとして、1 日に読むことのできる記事数の上限が画面下部に表示されています。 画面をゆっくり下にスクロールしていくと、この数字 (この例では "11") が滑らかにアニメーションしながら "10" に変化していきます。 途中でスクロールをやめれば、数字は "11" に戻ります。
  • "Stingray" という自動車の記事を見てみましょう。 記事を開くと、しばらくして Action Bar は (画面上部に wipe out して) 表示されなくなり、画面全体が記事表示になります。 下にスクロールしていくと Action Bar は表示されないままです。 一方、上に (記事の始めの方向に) スクロールすると、Action Bar が再度画面に現れます。 そして記事上端に達すると、記事冒頭の写真を尊重し、 Action Bar は半透明になります。
  • 上記のような、このアプリで用いられている表現の細部は、他のアプリよりも 際立って洗練された体験を提供するためにデザインされています。 このアプリを ぜひ研究していただき、皆さまが優れた体験を提供されるときの参考にしてくださることを願っています。


Chrome のタブ管理のジェスチャー操作 [再生時刻 10:59] - Nick Butcher

  • Chrome ブラウザ (Google Play リンク) の、とくにジェスチャー操作のデザインについて紹介したいと思います。
  • タブのアイコンに触れると、"Open tabs" という案内が薄く表示されます。 タップすると、タブを管理する画面に滑らかにアニメーションしながら切り替わります。 もう一度同じ場所をタップすると、通常どおりの画面に再びアニメーションしながら戻ります。
  • このジェスチャー操作で特筆すべき点は、ユーザーが「自分がこのアプリをコントロールしている」と感じることができるようにアニメーション表現に細心の注意が払われている点です。 たとえば、タブ管理画面に移ってから指をそのまま下にドラッグすると、各タブが斜め上から見ているように変形し、指を上に戻すとまたもとに戻ります。 ユーザーのタッチ/ドラッグ操作に対するこういった滑らかな画面変化により、ユーザーは自分の操作の意味をすぐに理解することができます。
  • もう一点重要なのは、タブの表現が contextual (文脈に応じた表現) になっている点です。 たとえば、タブ管理画面の下に表示されているタブを拡大表示してから再度 指をドラッグすると、タブの順序が保存されたまま滑らかにアニメーション表示していることがわかります。 このことにより、タブの順序の中で自分が何を操作しているのかをユーザーはすぐに理解することができます。
  • 画面を左右にスワイプすることで、タブどうしの間を滑らかに行き来することも可能です。 このことで、タブどうしの空間的な位置関係をユーザーに判りやすく伝えています。
  • これらの表現は、タブを管理するという単純な作業を、より楽しく豊かな体験にしています。 タブ管理画面で、特定のタブを閉じるには、そのタブを右にドラッグして画面の外に押し出す (swipe away する) こともできます。
  • Chrome で用いられているジェスチャー操作のような UI/UX 表現 (ドラッグ操作、スワイプ操作と滑らかなアニメーションを組み合わせた表現) は、ユーザーに機械的にコマンドを呼び出すことを要求する操作に比較して、より豊かなユーザー体験を提供します。 皆さまのアプリの UI/UX 表現をご検討いただく中で、これらも是非参考にしていただけましたらと思います。


Libra の時間スケール表現 [再生時刻 13:27] - Rich Fulcher

  • こんにちは、Android Design チームの Rich Fulcher です。 私自身がここ数年使っている、Libra というアプリ (Google Play リンク) をご紹介したいと思います。 これは、体重を管理するためのアプリです。 このアプリは、Notification (通知) を使って、体重を入力することを求めたり、というような便利なリマインダー機能を備えています。
  • 今日特にお話したいのは、 Libra が、ユーザーの入力したデータを視覚化 (visualize) しているその手法です。 とくに、異なった時間スケールでの表現の間を行き来する手法について紹介したいと思います。
  • 標準的な画面では、 Libra はユーザーが入力した体重データを、数週間の間について表示しています。 オレンジの小さい丸が、それぞれの日に入力されたデータを示しています。 そこから、灰色の縦の直線が、数日間の平均値のトレンド線 (赤色) まで伸びています。 そして、最近のトレンドからの予測線が右に向かって薄い灰色で表示されています。
  • Libra でとくに優れているのは、画面に表示する時間スケールを変化させたいときの そのスムーズな表現方法です。 二本の指でピンチイン・ピンチアウト操作を行うことで、時間スケールを広げたり狭めたりすることができ、 その操作に伴って細部のデータの表示の方法がリアルタイムに変化しています。
  • たとえば、ピンチイン操作により長い時間スケールの情報を表示すると、オレンジの小さい丸 (一日ごとのデータの表示) は画面から消えます。 しかし灰色の縦の直線の表示は残っていますので、平均値との差分についての概要はひきつづき画面で確認することができます。 そして、さらにピンチイン操作により時間スケールを長くしていくと、その灰色の縦の直線の表示も消え、赤いトレンド線のみが表示されます。
  • また、画面上をタップすると、その日付を中心とする一段階詳しい (=時間スケールの短い) 表示に滑らかにジャンプすることができます。 また、タップ操作後、画面には、同様のショートカット操作を提供する薄いボタンも表示されます。
  • このアプリは、私が一日のほんの短い間 (30秒未満) を過ごす小さなアプリですが、アプリを見るときのユーザーの目的に良く応えてくれています。 特定の日の情報を見る、長い時間スケールの情報を俯瞰する、といった操作がじつに滑らかに行えます。


Timely の徹底した洗練 [再生時刻 16:18] - Mike Denny

  • Bitspin の素晴らしい人たちにより開発された Timely というアプリ (Google Play リンク) について紹介します。
  • このアプリは、これまでも Android チームの動画で何度か紹介しています。 Android Design の考え方が実に美しく表現されているアプリです。 Android 端末はユーザーを Enchant (喜ばせる) すべきである、という考え方が随所に見られます。
  • Timely は、アラーム付き時計、タイマー、ストップウォッチの機能を提供するアプリです。 私自身、目覚まし時計として利用しています。 これらの機能はごく普通の (特別なことはない) 機能なのですが、このアプリは 他のアプリに比較して 洗練の度合い、細部のこだわりが抜きん出ています。 アニメーション、色の活用、タイポグラフィーについて、「さらに 1% 良くする」という努力が このアプリの体験を特別なものにしています。
  • これが Timely の画面です。 私が画面をタッチすると、水紋のようなアニメーションが広がります。 ぱっと見には、よくある Android アプリには見えません。 塗りつぶされた Action Bar もありませんし、明るい灰色や黒を基調とするテーマがあるわけではありません。 鮮やかな色が採用されており、 Live Wallpaper っぽいアニメーションが背景の中で動いています。 これらは触ってみると、実に Android アプリらしい振る舞いをします。
  • 画面を左右にスワイプすると、滑らかにグラデーション表現された色の変化が左右にスクロールします。 また、画面上のすべての要素は「タッチ可能 (touchable)」です。 タッチすると何らかの反応をすることで、ユーザーが画面に触ることを歓迎しています。 ユーザーは、「ここを操作しなさい」とわざわざ説明してもらう必要はありません。
  • タイマー画面で「再生」ボタンをタッチすると、滑らかにカウントダウンが始まります。 また、タイマー画面を触って指を上下に動かすと、チルト表現 (斜め上から見た表現) がアニメーションし、それには何か意味がありそうです。 画面左下のボタンをタップすると、タイマーとストップウォッチ画面がぐるっと回転して切り替わります。 このことで、チルト表現の場面で指を動かし続けると、タイマーとストップウォッチを上下のドラッグ操作のジェスチャーで切り替えることができることがわかります。
  • もう少し複雑な操作をユーザーに伝える必要があるときには、「優しく控えめに」説明されます。たとえば、ここではアラームの時刻を設定するために、画面を左端からスワイプしてください、という操作がアニメーションで説明されています。
  • それに従って画面を左端からスワイプすると、アラーム時刻の設定画面になります。この画面でも、多くの部分がドラッグ操作に反応します。また、時刻の上下には「+ 5 min」「- 5 min」という案内が(優しく控えめに)表示され、その部分をタップすることでも時刻を調整することができます。 そして画面上部の "Done" をタップするとセット完了です。 素晴らしい表現ですね。 セット後、アラーム時刻部分をタップすると再び時刻設定画面に戻ります。
  • このような "Extra 1% of effort" (追加の 1% の努力) により、ユーザーを喜ばせ、感動させることにこのアプリは成功しています。


Etsy のレイアウト表現、blur 表現 [再生時刻 20:26] - Adam Koch

  • Etsy というアプリ (Google Play リンク) は、手作りのグッズが販売されている電子市場です。
  • いま Google Play からこのアプリをダウンロードした直後です。 起動してみましょう。
  • 起動するとすぐに、コンテンツが表示されます。チュートリアル、ログイン画面、登録画面などによりユーザーが邪魔をされることなく、すぐに "Trending" (流行) のグッズのリストが表示された画面が表示されます。これは素晴らしいと思います。私の同僚の Nick Butcher も、この初回起動時のユーザー体験を気に入ることでしょう。
  • 下の方にスクロールしていくと、画面のレイアウトが、 Stacked Gridview とも呼べるレイアウトになっていることがわかります。 これは、ありがちな平板な (すべてのアイテムが同じ大きさの) Gridview レイアウトに比較して、変化があってよいと思います。各アイテムの画像は、必ずしも正方形である必要はありません。たとえば、このセーター商品の画像は縦長になっています。 また、この方式の画面レイアウトは、さまざまな画面サイズにもうまく対応できます。 たとえば、スマートフォンの portrait モード (縦画面) では、アイテムは縦に一列で表示され、画面サイズが大きくなるとマルチカラム表示になります。
  • 若干気づきにくいかもしれませんが、スクロールしているときの各アイテムの place holder 表示 (写真画像がロードされる前の表示) として、その後ロードされるアイテムの写真に合わせた 淡い色の矩形が表示されています。 たとえば、写真画像が緑と茶の多い画像の場合は、その写真がロードされる前には それを淡い色で示唆する矩形が表示されています。 これも、素敵なことだと思います。
  • タッチに対するフィードバックは、控えめに ほんの少しだけ色が暗くなるという表現が用いられています。 これは Android 4.4 KitKat のガイドラインにも適合した考え方です。
  • Navigation Drawer を開くと、コンテンツ本体は (次第に滑らかに) blur (ぼかし) 状態になります。 これは素晴らしいアイディアです。 このことで、自分がアプリの中にいる感覚を失わずに、注意を Navigation Drawer に向けることができます。 Navigation Drawer を閉じると、コンテンツ本体は (再び滑らかに) シャープな表示に戻ります。
  • 何かのアイテムを「お気に入り」しようとすると (アイテム右上のハート記号をタップ)、そこで はじめてサインイン (またはユーザー登録) が求められます。 この場面でも、"Not Now" (後で) という選択肢が表示されています。 Sign in に進むと、ログインまたは登録のダイアログ (ログイン、登録はタブ/スワイプで切り替え可) が表示されます。 この画面でも、 Etsy はコンテンツを背後に blur (ぼかし) 状態で表示しています。 これも美しくて判りやすいですね。
  • アイテムの詳細画面に行ってみましょう。 写真が大きく表示され、コンテンツを強調するために、システム標準の UI としては Action Bar のみが表示されています。
  • 詳細画面を上スクロール (scroll down) して内容をさらに見ていくと、画面の下端に 追加の画像のリストが出てきます。 これらは、この特定の販売者が提供している他のアイテムのリストです。 亀のグッズがお好きであれば、このリストを眺めて楽しむことができます。


2013年11月9日土曜日

動画番組 Things Every Android Game Developer Should Know の概要

ゲーム開発者の方々を対象に 2013 年 3 月 29 日に公開された動画番組 "Things Every Android Game Developer Should Know 2.0" にて、 Google+ Sign-in 機能、品質を高めていただく上での留意事項、および In-app Billing Version 3 についての解説が、Mountain View オフィスの Wolff Dobson, Dan Galpin, Bruno Oliveira によって提供されております。 この番組は 2012 年 6 月 29 日の Google I/O 2012 での Dan Galpin, Ian Ni-Lewis による講演 "Ten Things Game Developers Should Know" の続編です。

この番組が 2013 年 3 月に公開されたあと、 Google は Google Play Game Services を提供開始しました。 このため、一部の内容については最新の状況と若干異なっているのですが、大部分は 2013 年 11 月現在においても有効かつ重要な内容です。 そこで 以下に、この動画番組 "Things Every Android Game Developer Should Know 2.0" の内容と、2012 年の "Ten Things Game Developers Should Know" の内容の一部を 日本語でお伝えしたいと思います。

(ここ数年間の Android 端末のグラフィックス性能の向上に伴い、 Google Play における Android ゲーム作品の品質の向上、およびビジネスチャンスの拡大には目覚ましいものがあります。 日本においても、 Google 東京オフィスから「みんなのゲーム人気投票 どっちのゲームが好き?」キャンペーンも含め、さまざまな支援を行っております。 今後も Android プラットフォーム上で優れたゲーム作品を ご提供いただくために、この番組を お役立ていただけましたら幸いです。)



導入部 [再生時刻 00:05]

  • これまでゲーム開発者の人たちから、「Google Play 上で目立つためにはどうすればいいのか?」「悪いユーザーレビューを消したい」「レビューで星を 5 つ得るにはどうすればいいのか?」「Google Play に feature 掲載してほしい」「ユーザーの人にお金を払ってもらうにはどうすればいいのか?」といった お問い合わせをたくさんいただいています。 残念ながら ゲームを提供して成功することは、コマンドを一つ実行すれば達成できるほど簡単なことではありません。
  • これらのお問い合わせの中で時折、すべての中心的な存在として重要な「ユーザー」のことを忘れてしまいそうになります。 ユーザーは素晴らしい存在です。
  • そこで私たちは、最も重要な存在である ユーザーにフォーカスしたいと思います。 ユーザーを Happy にすることができ、より多くのユーザーにゲームを遊んでもらうことができれば、 Google Play においても成功する見込みが高いと言えます。
  • こういった背景から、新規ユーザーの獲得、優れた ユーザー体験の提供、および課金上の注意点について 今日はご紹介したいと思います。


Google を用いた Sign in 体験


Google+ とゲーム開発者の関係 [再生時刻 01:29]
  • ゲームにおいてユーザーを増やしていく方法の一つは、ソーシャル機能を追加することです。
  • 最近行われた あるユーザー調査では、多くのユーザーの人が Google によるサインイン (Sign-in) について (他のサインイン手法に比較して) 信頼してくださっていることが判りました。
  • 昨年 (2012 年)、Google は Google+ Sign-in という API を提供開始しました。 この機能を用いると、様々なプラットフォーム (アプリ、Web) において、ユーザーはGoogle+ のアイデンティティを用いて開発者が提供するサービスやアプリにサインインすることができるようになります。
  • Google+ は、(2013 年 3 月現在) 5 億人の人にご利用いただいており、 月間アクティブユーザー数は 1 億 3500 万人にのぼります。 約半数以上のユーザーが、モバイル端末から Google+ を利用しています。 ユーザー 1 人あたり平均で 1 日 12 分間、ストリームコンテンツをご覧いただいています。
  • 現在 Google は、数多くの Google サービスの Google+ との統合を通じて、より優れたユーザー体験を提供できるように努めています。 Google+ は、多くの Google サービスのユーザー体験を横断的に 良くしていくための背骨のようなものだと言うことができます。
  • 開発者から見ると Google+ は、
    • Android アプリのインストールを増やすための手段
    • 上手にターゲティングしながらのソーシャル共有を通じてユーザー層の成長を促す手段
    • ユーザーそれぞれにパーソナライズされた体験を提供し、ソーシャルグラフを通じたユーザーどうしの関係構築を助ける手段
    • ユーザーに信頼していただいている主体によるログイン認証を提供する手段
    として捉えることができます。

ゲームでの Google+ サインイン UI [再生時刻 03:10]
  • この機能をゲームで用いた時に どのように見えるか考えてみましょう。
  • ここで紹介するサンプルゲーム Nostalgic Racer において、 ゲームのタイトル画面に Google+ ログインのボタンが配置されています。 このボタンの表示は、あなたが提供している UI にあわせて行って頂くことができます。
  • このボタンをタップすると、 Google により提供されている承認ダイアログが表示されます。 ここには 2 つのものが含まれています。
  • 前半部分は、ユーザーの基本的なプロフィール情報やソーシャルグラフ情報に、アプリ (ゲーム) がアクセスしようとしていることについての説明です。 このダイアログでは、アプリが見ることができるソーシャルグラフはどの部分なのか (アプリに自分のソーシャルグラフの中の誰を見せるか) を、ゲームを遊んでいるユーザーは選ぶことができます。
  • 後半部分では、ユーザーがそのゲームを遊んでいることについて、ソーシャルグラフの中の誰に共有してもよいか (または共有しないか) をユーザーは選ぶことができます。
  • このダイアログの表示を編集・承認すると、ゲーム画面に戻ります。 この例では、私は Bruno Oliveira としてこのゲームにログインしている状態であることがわかります。
  • すでに Google+ アカウントをお持ちのユーザーの多くにとっては、これは とても簡単な操作となります。

インタラクティブな投稿の共有 [再生時刻 04:15]
  • ユーザーである Bruno がゲームをとても楽しんでいて、今 自分がうまくプレイしている このコースについて 誰かと共有したくなったとします。
  • Google+ のインタラクティブ投稿の機能を用いて、ユーザーは特定の友人に対してインタラクティブなメッセージを共有することができます。 この画面の例では、ゲームを遊んでいる Bruno が、友人の Todd に対し、「Todd は私より速くない」というメッセージとともに、そのゲームについての画像と「Challenge (挑戦) する」というボタンを同時に共有しています。
  • この機能は 2 つの点において重要です。 一つは、この機能はユーザー自身のソーシャルグラフの中で用いられる機能であるため、共有される相手 (そのゲームを遊んでいるユーザーの友人) は そのゲームに興味を持つ可能性が高いということです。
  • もう一つは、この共有は特定の人に宛てて行われているため、 端末の Notification 機能が活用されるということです。 このため、共有された相手 (Todd) は、 Bruno が自分に対して何かを仕掛けているということを実際に端末上で見る (知る) 可能性が高まります。
  • Google+ のストリーム上では この画面の例のように見えます。 Bruno のストリームを見ている人に対しても、「Challenge (挑戦) する」ボタンが見えるようになっています。
  • Bruno 以外のユーザーがこの「Challenge (挑戦) する」ボタンをクリックしたときには、 Web 上であれば そのゲームの Google Play アプリ詳細画面に遷移します。 一方、端末上でこのボタンがクリックされた場合には、ユーザーはそこから直接 ゲームの中の (Bruno が指定した) 特定のステージの画面に行くことができます。 端末上にゲームがまだインストールされていない場合には、Google Play 上のそのゲームのインストール画面に遷移します。
  • この機能を、ゲームのインストール数を高めていくためにご利用いただくことができます。
  • この他にも、Google+ API には、Over-the-Air install, Analytics, +1 ボタンによる共有、 Web 上での Hangout API といったさまざまな機能があります。 是非、これらの機能を活用する方法について http://developers.google.com/+ にてご確認ください。
  • [参照] Google Play Game Services — Google Developers
  • [参照] Google+ Platform — Google Developers


  • 品質上の注意点


    App Quality Guideline の紹介 [再生時刻 05:46]
    • 2012 年の Game Developers Conference の後、 Google は App Quality Guideline を公表しました。
    • Core App Quality Guideline には、 ゲーム作品が陥りがちな多くの注意事項が含まれています。
    • これまで数年にわたって Google は、 Android 標準のナビゲーション (Back ボタン対応) にゲームが適切に対応することを推奨しています。
    • Back ボタンに適切に対応しないことは、 Google Play 上でのネガティブなユーザーのレビューにもつながります。
    • ボリュームボタンについては、対応はプラットフォームに任せ、ユーザーが標準のボリューム操作 UI を使えるようにしてください。
    • Menu ボタンにも注意が必要です。 Google Play の QA チームは、何もしない Menu ボタンが画面に表示されてしまっていることを問題視します。 これを表示しないようにするには、アプリの targetSdkVersion の値を最新 (2013年3月現在は 17, 2013年11月現在は 19) の値にするようにしてください。
    • targetSdkVersion の値を最新のものにしていただくことで、プラットフォームの互換機能を使わずに済みます。 これはゲームのパフォーマンス (動作速度) の観点からも望ましいことです。
    • [参照] Core App Quality Guidelines - Android Developers
    • ユーザーに対して、不要な Notification 通知を送らないようにしてください。
    • Notification 通知を送る場合には、ユーザーが それをオン・オフしたり、どのような通知を表示する・しないを精密に設定できるようにしてください。 こうすることで、ユーザーから より良いレビューが得られるだけではなく、ユーザーが端末上の Notification 通知を完全にブロックする対策をとる可能性を減らすことができます。
    • [参照] Core App Quality Guidelines - Android Developers
    • 不要なパーミッションは利用しないでください。
    • ゲームにおいては、秘匿性の高いユーザー情報が 必要になることは ほとんどありません。
    • 昨年の Google I/O 2012 において、ゲーム開発者が避けるべきパーミッションについてご紹介しましたので こちらもあわせてご確認ください。
      • 10. Change Wifi Settings
      • 9. Receive Boot Completed
      • 8. Query Running Tasks
      • 7. Obtain Fine Location
      • 6. Read System Log
      • 5. Directly Call Phone Numbers
      • 4. Read/Write Contacts/Calendar
      • 3. Read/Write Bookmarks
      • 2. Display System Level Alerts
      • 1. Send/Receive SMS
    • この中でもとくに、SMS を送信・受信するパーミッションは避けるようにしてください。
    • これらのパーミッションを使ってしまうと、 Google Play 上での feature 掲載が難しくなります。
    • Audio (音声) についても、昨年お話いたしました。
    • ロックスクリーンにおいて音声が不用意に鳴ってしまうことは問題です。
    • [参照] Making Android Games that Play Nice | Android Developers Blog
    • 時間のかかる処理は (UIスレッドではなく) バックグラウンド・スレッドで実行してください。
    • StrictMode を用いながら開発してください。 StrictMode でアプリを実行したときに、画面が赤く点滅しないようにしてください。 Google Play に feature 掲載されるときの品質検査においてこれは実際に行われています。
    • [参照] New Gingerbread API: StrictMode. Dec 12, 2010. Android Developers Blog
    • [参照] StrictMode | Android Developers
    • ゲームのグラフィックスが、タブレットを含む画面サイズで問題ない品質になるようにしてください。 もし あなたのゲームが すべての Nexus 端末 (Galaxy Nexus, Nexus 4, Nexus 7, Nexus 10) において問題なく動作し、文字サイズやタッチ領域の大きさにおいても問題ない場合には、他のデバイスにおいても問題ない可能性が高いと言えます。
    • 私たちは、Nexus 端末の他にも、人気機種だが問題が多い機種を用いてテストすることもあります。 画面上の文字が小さ過ぎたり、タッチ領域が小さすぎたりするのは問題です。
    • Google Play での feature 掲載において用いられる Feature Graphic (1024x500 px の画像) を、見やすいようにデザインしてください。
    • 携帯電話の画面サイズにまで縮小されても見やすいように、 あまり細かい文字を Feature Graphic の中に描き込まないことをおすすめします。
    • [2013年11月注] この番組の配信の後、 Google Play の UI は新しいものになり、それまでに比べると Feature Graphic の露出の機会は減りました。 とはいえ引き続き Google Play Games アプリや、一部の Google Play feature 掲載時において Feature Graphic は引き続き必要である旨、ご理解いただけますようにお願いします。
    • Core App Quality Guideline の大部分は、そのまま検証チームに渡すことのできるテスト・ケース文書として提供されています。 是非ご活用ください。

    ゲームコントローラーへの対応 [再生時刻 09:23]
    • Android 3.0 (Honeycomb) において HID デバイスへの標準的なサポートが追加されたこともあり、 これまで多くのゲームがコントローラーへのサポートを拡大していることは喜ばしいことです。
    • サンプルゲームである Nostalgic Racer にも、ゲームコントローラーのサポートが含まれています。
    • ただし、ゲームのプレイ画面中でコントローラーがサポートされていても、メニュー画面においてはサポートされていないかもしれません。 それは残念なことです。
    • ゲーム中も、メニュー画面でも、コントローラーで操作できるようなゲームを是非開発してください。
    • ほとんどのコントローラーは、次の対応により動作させることができます。
      • 上移動 : DPAD UP
      • 下移動 : DPAD DOWN
      • 左移動 : DPAD LEFT
      • 右移動 : DPAD RIGHT
      • 決定 (Action) : DPAD CENTER, Aボタン
    • 「決定(Action)」を、 DPAD CENTER と A ボタンの両方に対応づけることを推奨している点にご注意ください。 ほとんどのゲームコントローラーでは、 DPAD の上下左右方向への対応は適切に行われています。 一方で、 X, Y, A, B という 4 つのボタンがある一般的なコントローラーにおいては、「X ボタン, Y ボタン」が DPAD CENTER に、「A ボタン, B ボタン」が BACK BUTTON に対応づけられています。 とくに A ボタンについては (BACK ではなく) 肯定的な動作を期待するユーザーが多いため、 A ボタンはデフォルトのままの挙動ではなく、決定 (Action) の肯定的な動作を対応づけることをおすすめします。
    • 他に、一部のコントロラーには以下のボタンも装備されていますが、これらは常に存在するとは限らない点にご注意ください。
      • Start : メニュー画面では、ゲーム開始。ゲーム中は、ゲーム中断
      • Select/Menu : 追加オプション (メニュー)
      • Back : Android 本体の Back ボタンと同じ
      • B : メニュー画面では Back。 ゲーム中は任意
      • A : メニュー画面では決定。 ゲーム中は任意
      • X, Y, Thumb L, Thumb R, Button TL, Button TR : 任意
    • アナログスティックに対応する時は、同時に DPAD イベントにも適切に対応してください。
    • 下記は、一般的なアナログ入力の軸です。
      • X, Y 軸 : 左スティック
      • Z, RZ 軸 : 右スティック
      • Throttle : 背面右トリガー
      • Brake : 背面左トリガー


    In-app Billing


    In-app Billing Version 3 [再生時刻 11:24]
    • In-app Billing API は、重要な API です。
    • 以前のバージョンの API は、利用方法が複雑なため、苦手意識を感じる人も多くいました。 IN_APP_NOTIFY 通知による状態の管理が必要でした。 アプリが sleep 状態のときにも通知を受け取れるように、 BroadcastReceiver を実装する必要がありました。 そしてその処理をバックグラウンドで行うために、 Service を走らせる必要がありました。 また、端末ローカルにデータベースを構築することも必要でした。 これらの処理は、難読化する必要もありました。
    • 複雑さの一つの要因は、 BroadcastReceiver の処理 (Google Play から通知をうけとる処理) を堅牢に構築することがシンプルではなかったためだったと言うことができます。
    • V2 は非同期型の API であり、アプリ内の多くのコンポーネントが協調しながら動作する必要があります。 非同期型であることが、複雑になりやすい要因の一つでした。
    • In-app Billing Version 3 API は、同期型の API であり、アプリは結果を同期的に (呼び出した後すぐに) 得ることができます。 このことにより V2 に比較して、よりコードの記述がシンプルになります。
    • V2 では、トランザクションのリストア (RESTORE_TRANSACTIONS) は高価な (重い) 処理でした。 このため、リストア処理は頻繁にではなく、注意深く行う必要がありました。
    • V3 では、Google Play はクライアント側のキャッシュを維持します。 このため、リストア処理は 以前に比べると非常に高速で軽いものになっています。 リストア処理は、何度でも行うことができ、回数に制限はありません。
    • In-app Billing Version 3 は、 Android 2.2 およびそれ以降のすべての端末においてサポートされています。 これは、現在使われている Android 端末の大部分です。
    • V3 がサポートされているかどうかをコード内で確認するには、 IInAppBillingService.isBillingSupported() を呼び出します。
    • ユーザーがどのアイテムを「所有」しているかをアプリ内で確認するには、 IInAppBillingService.getPurchases() を呼び出してください。
    • この呼び出しは、クライアント側のキャッシュを利用するため、とても高速であり、結果は同期的に (すぐに) 得ることができます。
    • ユーザーがお金を払ったあと、ゲームがアイテムを付与する処理に失敗しないように 十分に注意する必要があります。
    • これが発生すると、ユーザーの苦情、ネガティブなレビュー評価につながります。
    • そういった状況を避けるためにも、V3 においては "unamanged item" の考え方は廃止され、すべてのアイテムが "managed item" となっています。
    • 購入フローを開始するには、IInAppBillingService.getBuyIntent() を呼び出したあと、 startIntentSenderForResult() を呼び出してください。
    • 購入の結果は、アプリの Activity.onActivityResult() に返ってきます。
    • この段階で、アプリは結果を RESPONSE_CODE, INAPP_PURCHASE_DATA, INAPP_SIGNATURE という 3 つのデータにより得ることができます。
    • 最も簡単なシナリオにおいては、上記で処理は完了です。 アプリが開始するときには getPurchases() でユーザーが所有しているアイテムを確認。 購入フローを開始するときには、 getBuyItent() で Intent を取得し、それを実行。 onActivityResult にて、結果を処理する、ということになります。

    consumePurchase の使い方 [再生時刻 17:40]
    • V3 では新しく、"consumption" (消費) という概念が導入されています。 ユーザーがアイテムを購入した直後は、ユーザーはそのアイテムを所有していますが、 "consume" 処理を行うと、ユーザーはそのアイテムを所有していない状態に戻ります。
    • コード上では、 IInAppBillingService.consumePurchase() を呼び出すことでこれを行うことができます。 アイテムが購入されたときの purchaseToken をここに渡すことで、この API を呼び出すことができます。
    • consumePurchase を呼び出すべきタイミングには、大きく分けて 2 通りのシナリオがあります。
    • 一つは、実際にユーザーがアイテムを「使った」ときに呼び出す方法。
    • もう一つは、ユーザーがアイテムを買った直後にすぐに呼び出す方法です。
    • 前者の方法では、同じアイテムをユーザーは複数回買うことはできません。後者の方法を用いることで、ユーザーは同じアイテムを何度でも買うことができます。
    • 後者の方法を用いる時は、アプリの起動時 (再起動時) に必ず getPurchases() によりユーザーが所有するアイテムを確認し、それに対しすぐに consumePurchase() を呼び出すように注意してください。 ユーザーの購入直後にアプリがクラッシュした場合には、次の起動時が consumePurchase() を呼び出す適切なタイミングになります。
    • まとめると、アプリ起動時(再起動時) には getPurchases() を呼び出してユーザーの所有アイテムを確認。 必要に応じてこのタイミングで consumePurchase() 処理も行ってください。
    • ユーザーが購入遷移にすすむときには、 getBuyIntent() を呼び出して Intent を取得し、それを実行。
    • onActivityResult() に購入の結果が返ってくるので、その結果を処理。 購入に成功していたら、すぐに consumePurchase() を呼び出し。
    • consumePurchase() 処理が成功したときには、必ずユーザーに購入されたアイテムが付与されるようにデータを更新。

    In-app Billing のセキュリティ上の注意点 [再生時刻 21:45]
    • 残念ながらインターネットには、あなたの有料アイテムを無料で入手しようとしている人たちが存在しています。
    • ここでは彼らを海賊 (Pirates) と呼ぶことにします。
    • 購入処理が実行されるたびに、あなた (開発者) は その購入が正当なものかどうかをチェックする必要があります。
    • 海賊はもちろん、あなたを騙してそれが正当だと思わせようとします。 あなた (開発者) は、その嘘を見抜く必要があります。
    • 海賊を 100% ストップする方法は残念ながらありませんが、彼らの攻撃を非常に困難にすることはできます。
    • あなた (開発者) が活用できる防御手段は、 developerPayload, Signature verification, Server-side validation の 3 種類です。
    • developerPayload を用いることで、すべての購入に、開発者は何らかのユニークな名前をつけることができます。 その情報の中に正当な購入者の情報を含めておき、それを後で再度チェックすることで、 Replay attack と呼ばれる攻撃を防ぐことができます。
    • Signature をチェックすることも重要です。 Google Play が あなたのアプリに購入情報を送信する際には、それは private key を用いて署名されています。 あなたの手元にある public key を用いてそれをチェックすることで、偽造された購入情報を防ぐことができます。
    • クライアント側の処理のみでは防御は十分とはいえません。 というのは、端末そのものが hack されてしまったり、端末に搭載されている Java API が改変されている危険性もあるためです。
    • このため、購入処理の中で、署名の確認、注文番号 (Order Number) の確認の処理はサーバー側で行うことを強くおすすめします。 これらのクライアント - サーバー間の通信処理は、安全な方法によって行うようにしてください。
    • これを整理すると、Signature verification, developerPayload, Server-side verification を組み合わせていただくことで、 MITM (Man-in-the-middle; 中間者) 攻撃、 Reply 攻撃、 プラットフォーム/フレームワーク改変のいずれの攻撃からも あなたのアプリを防御していただくことができます。
    • 難読化も忘れてはいけません。
    • 実際には、これらの手法をどのように組み合わせるかについては、アプリ/ゲーム作品ごとに適切な対応が異なります。 上記の手法を参考に、あなたのアプリを適切に防御してください。
    • [参照] Security and Design - In-app Billing - Android Developers
    • もう一つお知らせがあります。 In-app Billing Version 3 においては、アイテムの価格情報を (各ユーザーの地域・国にあわせて) 自動的に取得する API が追加されました。 IInAppBillingService.getSkuDetails() メソッドを用いて、ユーザーに合わせた適切な価格表示を行っていただけますようにお願いいたします。


    Google I/O 2012 講演 "Ten Things Game Developers Should Know" の抜粋


    2012 年 6 月 29 日、Google I/O 2012 での講演 "Ten Things Game Developers Should Know" において、 Dan Galpin と Ian Ni-Lewis は ゲーム開発の上での主な注意事項を紹介しています。 このうち、"Things Every Android Game Developer Should Know" 番組では詳しく触れられていない Back ボタンの扱い、および GPU 対応テストの話題について、下記に抜粋してお伝えいたします。

    3. Back ボタン対応について [再生時刻 09:42]
    • Android 端末には、 Back ボタン、 Home ボタン、 Recent Apps ボタン、 Lock ボタン、 Volume ボタン、が装備されています。
    • これらのボタンはほとんどのゲームにおいて、プラットフォームに処理を任せるほうがベターです。 たとえば Volume ボタンの入力は、アプリが自分で処理するのではなく、ユーザーがプラットフォーム標準のボリューム制御 UI を使えるようにすることが推奨されています。
    • Back ボタンの対応は、場合によっては複雑です。 というのは、ゲームでは、実際には Activity は 1 つだけしか利用していない場合が多いためです。
    • ここでは、サンプルゲームを用いて、 Back ボタン対応について考えてみましょう。
    • これは、シンプルなアーケードゲームの例です。
    • ゲームを開始し、メニューでステージを選択し、ゲーム画面でゲームを楽しんでいます。
    • この画面で Back ボタンを押したとします。
    • この例では、ステージ選択メニューに戻っています。 これは問題ありません。 ステージを途中まで進めた状態を保存すべきかそうでないかは、ゲーム内容によります。 Back ボタンにより、1 つ前の画面に戻るのは Android ユーザーの期待にも沿っています。
    • もうひとつの方法は、「中断メニュー」をダイアログ形式で表示することです。 これは、Android のナビゲーション方式とは完全に一致する方法ではないので「ベスト」プラクティスとは呼べませんが、十分にポピュラーな対応方法であり、これに反対する理由はありません。
    • ダイアログ形式のこの中断メニューが表示されているときに Back ボタンが押されたら、何が起きるべきでしょうか。
    • ステージ選択メニューに戻るべきでしょうか? それとも、ゲーム画面に戻るべきでしょうか?
    • 一般には、この画面は明らかに「ダイアログ」に見えるので、ダイアログのように振る舞うことが期待されます。 この場合は、おそらくダイアログが閉じられてゲーム画面に戻る、というのが期待される挙動でしょう。
    • この例から、ユーザーをできるだけ邪魔しない UI が望ましい、という原則を想起していただけましたら、と思います。
    • また、ダイアログを表示するのではなく、 (Back ボタンが押されたら) メニュー画面に戻り、そのメニュー画面から そのステージを再開 (中断した場面からの再開) できるようにするという方法もあります。 この方法は、Back ボタンに対して ダイアログを表示する方法に比較して、より Android 標準の画面ナビゲーション手法に沿っている点が優れています。
    • 最も良いのは、ユーザーは前の画面に Back ボタンでいつでも戻ることができ、同時に ゲームの進行を失わずに もともといた画面で続きを遊ぶことができる、という挙動です。
    • Back ボタンに対して、「ゲームを終了しますか?(Yes/No)」というダイアログを表示することはユーザー体験として良くありません。
    • ゲームの進行を失わないでユーザーに続きを楽しんでもらう方法は他にもたくさんあります。 このような「Yes/No」ダイアログは表示しないでください。
    • Back ボタン対応についてのまとめです。
    • ダイアログが表示されているときは、ダイアログを閉じてください。
    • メニュー表示 UI では、前の画面に戻ってください。
    • ゲーム中では、
      • 中断(ポーズ)、または
      • 下記のいずれか:
        • オプション選択ダイアログを表示
        • 前の画面に戻る
    • ゲームのタイトル画面の場合は、単にアプリを終了してください。 Y/N を聞く必要はありません
    • ユーザーが進行を失わないようにしてください。

    9. GPU 対応のテストについて [再生時刻 46:00]
    • テストについて少しお話したいと思います。
    • 現在 数多くの Android 端末が存在しており、テストの軸ごとに難易度が異なります。
    • 入力デバイスの軸、画面サイズの軸、OSバージョンの軸に対してテストを行うことは、実はそれほど難しくありません。
    • 一方、3D ゲームにおいて、グラフィックドライバー、GPU ハードウェアの軸に対してテストを行うことはシンプルではありません。 時折、ドライバーにはバグがあり、 GPU ハードウェアはそれぞれに特性が異なるためです。
    • 現在 Android 端末で用いられている主要な GPU には下記のものがあります:
      • Adreno
      • PowerVR
      • Tegra
      • Mali
      • Vivante
      • Broadcom
    • このうち、上の 4 種類 (Adreno, PowerVR, Tegra, Mali) は特に重要です。
    • 中でも、PowerVR の挙動は他の GPU と大きく異なります。 PowerVR では、material による sort により高速化が行えますが、 geometry, complexity による sort はほとんど効果がありません。 一方で、PowerVR 以外の GPU (Adreno, Tegra, Mali, ...) においては、 geometry, complexity による sort により大幅なチューニングが可能です。
    • また、テキスチャ圧縮フォーマットにもいくつかの種類があることに留意してください。 透過型ではないテキスチャについては、ETC1 を使うことができます。 透過型のテキスチャを用いるときは、何らかのメーカー固有のフォーマットを用いるか、または shader を記述する必要があります。
    • Google Play では、同じアプリの中で、利用されているテキスチャ圧縮フォーマットごとに、別々のバーションの APK (および別々の拡張ファイル) を提供していただくことができます。
    • 上記の留意事項は、3D ゲームにおいて特に重要です。 2D ゲームにおいては、これらは問題にならないかもしれません。