1. 「Smartphone UI/UX」 DeNA Creative Seminar vol.1
1
レポート （2012-3-21）
2012-5-15
ソネットエンタテインメント 荒井康友
NAVER まとめ
http://matome.naver.jp/odai/2133273154983690401

2. 目次
2
 スマートフォンソーシャルゲームUIのコツ
 企画・開発・運用の効率化やその他テクニック
 CSS3/JavaScript で作るスマートフォンUIと落とし穴
 UI、Android 対応のテクニック
 Smartphone フロントエンドの最適化と最前線
 レスポンス速度向上テクニック

3. 3 スマートフォンソーシャルゲームUIのコツ
登壇者：古窪智美氏
DeNA デザイン系部署
前職：ドワンゴ/ニコニコ事業部

4. User Interface の大前提
4
 ソーシャルゲームの User Interface をよくする目的
⇒ユーザに使いやすいと感じてもらう為
 ユーザが使いやすいとどうなるの？
⇒楽しくゲームができる

5. UI 先行で進めてはいけない
5
 この技術を「使いたい」先行はダメ
 3Dグラフィック
 HTML5、CSS3
 JavaScript
 アニメーション
⇒やろうと思えば（凝った物を作ろうと思えば）いくらでも出来る
「世に無いすごいものを生み出す」目的ならOK

6. UI の到達ラインを明確にしておく
6
 「あたりまえ品質」
 最低限の操作性
 ゲームの制作目的によってレベルが変化する
 「＋α ライン」
 ハイレベルな UI

7. UI/UX が失敗した原因（経験談）
7
 仕様が決まらずとりあえず制作しはじめて迷走し変更が
入る ⇒ デザインルールの破綻
 ハイレベルを求めすぎて、不可能・可能を確認せずに
実装しようとする
 サーバサイドの制作と、フロントサイドの制作の連携不
足
 １ページ毎、１機能毎しか見ていない
 スマホ UI/UX ノウハウのあるメンバーがプロジェクトに
いない

8. 最短工数で使いやすい UI/UX を制作するには
8
 １日でも早くモックでひと通りの操作感やゲームを試せ
る環境を用意
 実際に触ってみないと
 機能追加・修正は、はじめから大幅に見込んでおく
 ブレないものを作るか、ブレても構わない UI 設計

9. モバゲーブラウザーソーシャルゲームのスマホUIにおける主軸
9
 「高速化」
 表示速度
 体感速度
 「操作感」
 指操作を意識したUI
 「ゲームの世界観」

10. 展開用デザインをルール化する
10
 見出し H1～H4
 リンク表現
 テキスト左寄せ
 領域リンク
 ボタンデザイン
 メインボタン
 サブボタン
 ページング
 メニュー
 タブ
 ボックスレイアウト

11. 展開用デザインルール制作のメリット
11
 画像、コードの軽量化
 複数のメンバーでコーディングを行っても統一される
 要素の追加・変更があった場合でも、企画・エンジニア誰で
も作業可能
 運用フェーズになってもルールが引き継がれるため、操
作性が統一される

12. スマホソーシャルゲームならではのUIの落とし穴
12
 同じような機能、似たようなページで操作・配置が違う
 連続した操作なのにタップ領域の位置が違う
 ページから Flash に遷移するときに起こりがち
 遷移ページが多い
 完了テキストのみ差し変わるページをまるごと読み込むなど
 リンクがありすぎて次に押すべきボタンが分からない
 行きたい場所へのリンクが無い
 一括したいのに一回づつ選択させられる
 一画面に詰め込みすぎてタップしづらい
 世界観を重視しすぎてリンクだとわかりづらい
 ガラケーから移行したユーザへの配慮をしていない
 ネガティブボタン（キャンセル・戻る）、５キー（決定・進む）

13. 画像 ＋ CSS
13
 ALL CSS
 さっぱりしすぎており、世界観にそぐわないことも
 ALL 画像
 重い
 文字差し替え工数がかかる
 画像 ＋ CSS
 border-image で枠のみ画像で世界観をキープ
 文字差し替え工数がかからない

14. 連続した遷移のタップ位置は揃える
14
同じ位置

15. 15 CSS3/JavaScript で作るスマートフォンUIと落とし穴
登壇者：西畑一馬氏
株式会社まぼろし
フロントエンドエンジニア

16. はじめに
16
 ユーザはアプリで経験値を高めている
⇒アプリのようなウェブサイトがよい？
 Apple の Human Interface Guidelines 参照
 リンクの高さは 44 ピクセル以上
 Android は端末によって処理に違いがある
⇒バグ取りが大変

17. スワイプギャラリー
17
CSS3
-webkit-transform:translate3d(100px,0,0);
GPU で高速に動作

18. スワイプギャラリー Android の落とし穴
18
 GPU に切り替わらない端末も多い
 touchmove イベントをロストする端末もある

19. Android 対応
19
 e.preventdefault()
$("ul").on("touchstart",function(e){
if(/Android/.test(navigator.userAgent)){
e.preventDefault();
}
}):
 touchmove 無視
 フリック型

20. 固定配置
20
 ヘッダー、フッターを「ISCROLL」で固定

21. オーバーレイ （ポップアップ）
21
Android ではレイヤー下の要素にフォーカスが当たって
しまうことも
⇒透明板を挟んだり、フォーカスを透明にしたりして対策

22. 22 Smartphone フロントエンドの最適化と最前線
登壇者：城戸総史氏
DeNA フロントエンド担当

23. iPhone
23
 Display : 960×640
 CPU : 800MHz
 Memory : 512MB
リッチな表現 × 限られた性能

24. パフォーマンス最適化（front end optimization）
24
800ms 未満
⇒人間が待たされないと感じる境界と考えている

25. 計測する
25
 Google Page Speed
 実機計測
 Date.now()
 HTTP Archive
 chrome の Network

26. TTI : Time to Interact
26
 「お、動いた」
 「お、動かせる」

27. 最適化する
27
 リクエスト数を削る
 画像
 base64 encode でソースに埋め込む
 スプライト化（１つの画像にまとめる）して数を減らす
 JavaScript、CSS の Unify （１つにする）
 ブロックを回避
 SCRIPT は後続処理をブロックするので body の下部に置く
 defer / async を活用
 <script defer type="text/javascript" src="...
 遅延させる

28. Smartphone の負荷部分
28
 HTML のパース処理を部分的に遅らせる
 パーススキップ
 画像取得 (empty cache)
 画像を encode して CSS化し、CSS を遅延ロード
 JavaScript ライブラリの評価

29. これから
29
 HTML5 + Flash