Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Smartphone ui:ux」 de na creative seminar vol.1 レポート

1,688 views

Published on

  • Login to see the comments

Smartphone ui:ux」 de na creative seminar vol.1 レポート

  1. 1. 「Smartphone UI/UX」 DeNA Creative Seminar vol.11 レポート (2012-3-21) 2012-5-15 ソネットエンタテインメント 荒井康友 NAVER まとめ http://matome.naver.jp/odai/2133273154983690401
  2. 2. 目次2  スマートフォンソーシャルゲームUIのコツ  企画・開発・運用の効率化やその他テクニック  CSS3/JavaScript で作るスマートフォンUIと落とし穴  UI、Android 対応のテクニック  Smartphone フロントエンドの最適化と最前線  レスポンス速度向上テクニック
  3. 3. 3 スマートフォンソーシャルゲームUIのコツ 登壇者:古窪智美氏 DeNA デザイン系部署 前職:ドワンゴ/ニコニコ事業部
  4. 4. User Interface の大前提4  ソーシャルゲームの User Interface をよくする目的 ⇒ユーザに使いやすいと感じてもらう為  ユーザが使いやすいとどうなるの? ⇒楽しくゲームができる
  5. 5. UI 先行で進めてはいけない5  この技術を「使いたい」先行はダメ  3Dグラフィック  HTML5、CSS3  JavaScript  アニメーション ⇒やろうと思えば(凝った物を作ろうと思えば)いくらでも出来る 「世に無いすごいものを生み出す」目的ならOK
  6. 6. UI の到達ラインを明確にしておく6  「あたりまえ品質」  最低限の操作性  ゲームの制作目的によってレベルが変化する  「+α ライン」  ハイレベルな UI
  7. 7. UI/UX が失敗した原因(経験談)7  仕様が決まらずとりあえず制作しはじめて迷走し変更が 入る ⇒ デザインルールの破綻  ハイレベルを求めすぎて、不可能・可能を確認せずに 実装しようとする  サーバサイドの制作と、フロントサイドの制作の連携不 足  1ページ毎、1機能毎しか見ていない  スマホ UI/UX ノウハウのあるメンバーがプロジェクトに いない
  8. 8. 最短工数で使いやすい UI/UX を制作するには8  1日でも早くモックでひと通りの操作感やゲームを試せ る環境を用意  実際に触ってみないと  機能追加・修正は、はじめから大幅に見込んでおく  ブレないものを作るか、ブレても構わない UI 設計
  9. 9. モバゲーブラウザーソーシャルゲームのスマホUIにおける主軸9  「高速化」  表示速度  体感速度  「操作感」  指操作を意識したUI  「ゲームの世界観」
  10. 10. 展開用デザインをルール化する10  見出し H1~H4  リンク表現  テキスト左寄せ  領域リンク  ボタンデザイン  メインボタン  サブボタン  ページング  メニュー  タブ  ボックスレイアウト
  11. 11. 展開用デザインルール制作のメリット11  画像、コードの軽量化  複数のメンバーでコーディングを行っても統一される  要素の追加・変更があった場合でも、企画・エンジニア誰で も作業可能  運用フェーズになってもルールが引き継がれるため、操 作性が統一される
  12. 12. スマホソーシャルゲームならではのUIの落とし穴12  同じような機能、似たようなページで操作・配置が違う  連続した操作なのにタップ領域の位置が違う  ページから Flash に遷移するときに起こりがち  遷移ページが多い  完了テキストのみ差し変わるページをまるごと読み込むなど  リンクがありすぎて次に押すべきボタンが分からない  行きたい場所へのリンクが無い  一括したいのに一回づつ選択させられる  一画面に詰め込みすぎてタップしづらい  世界観を重視しすぎてリンクだとわかりづらい  ガラケーから移行したユーザへの配慮をしていない  ネガティブボタン(キャンセル・戻る)、5キー(決定・進む)
  13. 13. 画像 + CSS13  ALL CSS  さっぱりしすぎており、世界観にそぐわないことも  ALL 画像  重い  文字差し替え工数がかかる  画像 + CSS  border-image で枠のみ画像で世界観をキープ  文字差し替え工数がかからない
  14. 14. 連続した遷移のタップ位置は揃える14 同じ位置
  15. 15. 15 CSS3/JavaScript で作るスマートフォンUIと落とし穴 登壇者:西畑一馬氏 株式会社まぼろし フロントエンドエンジニア
  16. 16. はじめに16  ユーザはアプリで経験値を高めている ⇒アプリのようなウェブサイトがよい?  Apple の Human Interface Guidelines 参照  リンクの高さは 44 ピクセル以上  Android は端末によって処理に違いがある ⇒バグ取りが大変
  17. 17. スワイプギャラリー17 CSS3 -webkit-transform:translate3d(100px,0,0); GPU で高速に動作
  18. 18. スワイプギャラリー Android の落とし穴18  GPU に切り替わらない端末も多い  touchmove イベントをロストする端末もある
  19. 19. Android 対応19  e.preventdefault() $("ul").on("touchstart",function(e){ if(/Android/.test(navigator.userAgent)){ e.preventDefault(); } }):  touchmove 無視  フリック型
  20. 20. 固定配置20  ヘッダー、フッターを「ISCROLL」で固定
  21. 21. オーバーレイ (ポップアップ)21 Android ではレイヤー下の要素にフォーカスが当たって しまうことも ⇒透明板を挟んだり、フォーカスを透明にしたりして対策
  22. 22. 22 Smartphone フロントエンドの最適化と最前線 登壇者:城戸総史氏 DeNA フロントエンド担当
  23. 23. iPhone23  Display : 960×640  CPU : 800MHz  Memory : 512MB リッチな表現 × 限られた性能
  24. 24. パフォーマンス最適化(front end optimization)24 800ms 未満 ⇒人間が待たされないと感じる境界と考えている
  25. 25. 計測する25  Google Page Speed  実機計測  Date.now()  HTTP Archive  chrome の Network
  26. 26. TTI : Time to Interact26  「お、動いた」  「お、動かせる」
  27. 27. 最適化する27  リクエスト数を削る  画像  base64 encode でソースに埋め込む  スプライト化(1つの画像にまとめる)して数を減らす  JavaScript、CSS の Unify (1つにする)  ブロックを回避  SCRIPT は後続処理をブロックするので body の下部に置く  defer / async を活用  <script defer type="text/javascript" src="...  遅延させる
  28. 28. Smartphone の負荷部分28  HTML のパース処理を部分的に遅らせる  パーススキップ  画像取得 (empty cache)  画像を encode して CSS化し、CSS を遅延ロード  JavaScript ライブラリの評価
  29. 29. これから29  HTML5 + Flash

×