デブサミ2012 1日目 (2012/02/16)のまとめ その2 #devsumi
【16-A-4】Effective Smartphone UX at GREE
Effective Smartphone UX at GREE
View more presentations from Kenichi Yonekawa
- UX 聞いたこともない人 →10人ぐらい
- UXで飯をと食っている人→2人
GREEでの事例
iPhone のスライド機能
ユーザーがスライドをする時には縦ではなく、実際には、指を斜めにスライドさせる
iPhoneのデフォルト機能はこれができる
- メッセージの受信
例
受診しましたのメッセージ
その場ですぐに見たいとは限らない。
ユーザーがWebを見てるなどどういう状態にあるかを把握しないとUIとしては正しくても
ユーザには不便に感じてしまうことがある
スマートフォン(iPhoneとAndroid)にフォーカスした話
-
- 指からタッチパネルまでの距離をいかに縮めるかかがユーザーが思ったとおりに動いてくれるかという指標になる
-
- タッチパネルに触ったときに即座にフィードバック
- 自分の操作にアプリが反応していると認識してくれる
- 例 iPhone電話で番号のハイライト
- 応答を早くすることでユーザー体験をよくする
- 歩いていてスマフォを使うことが多い
- 携帯よりも誤操作が多い。
- 間違ってなにかをしたときにもすぐに戻せること
- ユーザーが自分が間違ったしまったという感情を持たせずに使わせることができる
Speed × Quality
- (開発)スピードを重視しているので、HTML
- 常に最新のコンテンツを提供するために
- onClick delay
- Javascriptの仕様で300msまたされる
- もっさりした動きになってしまう
-
- onTocuStart & onTouchEnd
- Offline対策
- GREEのアプリをフライトモードで試してみたら、ひどかった・・・
-
- ページを読み込みませでした。
- 通信を確認してサイドアクセスしてください
-
- 表示してた情報がみえなくなる
-
- ネットワークエラー
- 通信状態のよい場所で再度お試しください
- →状態を保ったまま、再度操作できる
- ネットワークエラー
-
- Pathだと
- オフラインにしても写真をとれて送信できる(再接続したら送る)
- Pathだと
- ユーザがなにをしたいのかを考えて設計する必要がある
- GREEはユーザ体験を重要視している
- ソーシャルゲーム
- 主流は時間を使ってなにかアクションしたら、何かができる
- 時間が経過したら、何かができるようになる
-
- もう一度立ち上げてもらう必要がある。
- 遊びたいたいうモチベーションを阻害しないようにするためにUXが大切になる
-
- ソーシャルネットワークサービスはコミュニケーンのインフラ
- なにか1つの機能で障壁を作ってしまうとコミュニケーション全体の障壁になってしまう
###ここで、ミスでスライドが最初に戻った。
###こういうのがあると「ユーザー体験悪い」
###という自分を犠牲にした表現なのかもしれない。
クロスプラットフォーム対応
-
- Androidはアプリごとの連携をするので、ヘッダーにアプリ名がないとユーザーがが何を使ってて何をしたいか分からなくなる
- Evernoteの人曰く Cross Platform は神話
- 最善は各プラットフォームに適切なUXを提供することだ
- かと言ってすべてをつくることはできないので
- それをサポートするために、ベースとなるものをCross Platform で作る
- 文脈に反るユーザー体験を作ってしまうと
- 次にそのアプリを立ち上げるというモチベーションを下げてしまう
- そうすると使ってもらえなくなってしまう
Effective UX
- 即座にフィードバックを返す
- 間違えてもやり直せる
- ユーザーの文脈を壊さない
【16-E-5】デザインの最前線田川 欣哉 氏
Dsign Enginieering Firm の紹介
- http://www.takram.com/
- 他社と違って、変わっているところ
- 中で働いてる人の大半がエンジニアリングをバックグランドに持っている
- 工学系、現場で働いていた人
- ロボット
- 空間系
- デザインとエンジニアリングと結びついている
- UXを飛び越えた根っこの部分で、もっと
- Design and Engineering
- 先端的な製品はこの2つが結びついてる
- プロトタイプ
- ソフトウェアをアジャイルに作っていくこと
- →それよりも広い範囲で考えてる
- プランナー企画デザイナー、エンジニアがものづくりしていく
- 入り方を上流に持っていく
- コンセプトと具現化された製品があまり剥離しないように開発している
- そのためにデザインエンジニアがリードしていく
最近の事例 MUJI NOTEBOOK
- 無印良品 文房具が売上の大きい部分を占めている
- iPadがでたときにこういう製品に置き換えら得ていくのではないかという危機感
- コラボ
- はらけんや
- takura
- PDFで赤ペン入れ
- 独自の手描き入力
- OSS
- 予測変換 mozk
- 手書き認識
- ノートパッド、スケッチは数多くある
- 無印が出すプロダクト
- シンプルな世界観、装飾を省いて余白のあるデザイン
- 紙で見せても伝わらなかった
- アイディア自体への理解度が低くて、いいか悪かいの評価ができないのではないか？
- 液晶タブレットを使って、FLASHでプロトタイプを作成した
- アイディアが理解できると、判断でき、よければ共感して、次のアイディアが出てくる
- バージョンアップを重ねても目に見える機能を増やさないか
- 機能は簡単に増やせる
- デザインは定量的に増やしたり、減らしたりできない
- バージョンアップを繰り返していくと、機能だけが増えていき
- デザインと合わなくなっていくのがこういうソフトだとよくある。
- 機能を増やしていくと同時にどうやったら、機能を減らしていけるか、機能を統合して1つにするなど
最近の事例 TYOTA NS4
- 2画面で連動して動作する
- タッチパネルも自社で作成
- 次世代
- ARで全面ディスプレー
- 車全部がディスプレーになったらどうなるかというコンセプト
- 今よりも何が安全になるかというプロジェクト
- NTT docomo UI
- サービスのUIの設計、GCのデザイン設計
- 操作しなりを考えて、操作方法をプロトタイプで作成して議論
- 機能を羅列していってもユーザーがどういう印象として受け取るかわからない
- 仮説だけで実装が進んでいってしまう
- 不要なものが残ったままになったり
- 抽象的なものからだんだん舞台な方向にもっていくのは難しくなっている
- 抽象的な設計が出来る人と、ユーザーから見た見栄え、舞台になるかを考える人が最初から
- 取り組めるといい。
最近の事例 携帯のプロトタイプ
- これ専用のハードを1台組み立ててた
- 操作は携帯から、操作情報をPCに送って、PCからの情報を画面に表宇するなど
- 自動販売機でも同じサイズのものも作る
- デザインをしていく上でプロトタイプをたくさんつくる
- demo is more infomative than 100 skethes
- 具体的なものと抽象的なものを比較して進めていくのが有効
- プロジェクトのどの段階から始められるかがポイント
- 画面繊維でユーザーの認知を助けるアニメーションは何かを考える
- 実機でフィードバック
- 製品の中に1つ強いコンストラストを持つ
- 製品それぞれで考えていく必要がある
- 例
- 見た目は非常に機械っぽいがロボットは走りだした途端に生き物っぽい動きをする
- 生物と機械の対比を表現
-
- 他の製品にないコンストラストが生まれてくる
チームワークがどうやったらうまくいくか
- ものづくり側がプロトタイプを進めていく
- 周辺でカスタマーの人にどうやって伝えていくのかどう使って欲しいかを
- 同時に走らせると、実際に製品になったときに印象がいい。
- ソフトウェアとハードウェアの接点のところで面白いことが起きていくのではないだろうか
- Q.工学部出身ということでしたがのでデザインの知識は最初なかったと思います。どうやって身につけていったのか？
ハードウェア → ハードウェアの設計 →ソフトウェアという順になるのですか？
- A.いろんな入り方の人がいるので得意な分野の人を集めてチームとして機能するようになる。
- ひとりの人がすべてを網羅することを理想としている
- Q. ハードウェアはプロトタイプを作るのに時間がかかるがなにかいいアイディアがないか
- A. そこが腕の見せ所
- 何を見せるかによって因数分解できるものがある サイズ、重さなど
- 処理はこういったものに対しては、サイズを無視して性能を出してみてるとか
- 4つバラバラに作ってみてもらう
- バラバラでもイメージは伝わる
【16-C-6】kintoneの表と裏〜大規模JavaScript開発と非構造データベース若原 祥正 氏 / 生駒 浩隆 氏
デブサミ2012 kintoneの表と裏 - 表編
View more presentations from yo_waka
- サイボウズで作成しているkintoneというアプリ
- Kintoneの表 クライアントサイド
泥臭い話
- 7万行
- Javasriptでほぼ全てのDOMを描画
- D&Dをやるとイベント発火数がやばい
- イベントをうまく管理しないと破綻する
- kintoneでは クラス間通信
- 実装はMAP
- addEventListnerと変わらない
- DOM構造的に親子間映画なくてもイベントを介してやり取りできる
- クラスの役割が明確になる
- DOMイベントの違って、たくさん貼って重くならない
- メモリリーク
- アプリ内でフォームレイアウトした画面
- 画面遷移せずに描画(DOMの再描画)
- イベントリスナ、thisオブジェクトへの参照がのこっていた
- ユーザーがフォームをヘビーな作り方している
- フォームの繰り返しができる
- 繰り返し行が50行
- HTMLエディタ内で使用されているiFrameのロードが遅かった
- 対応
- 重いループ処理の非同期化
- Deferredパターン
- 成功時の処理、エラー処理を直列に書くことができる
- DeferredのトリガをsetTimeoutで囲んでチェイン
- コードが複雑になりにくい
- 処理がすべて終わったか分かる
- 表示速度≒体感速度
- 重かった処理をピンポイントで非同期化
- 裏側で激しくが動いていても、ユーザーは気づかなかった
- 大規模UIに必要な要素≒
- クラスベースなイベント設計
- メモリ管理の徹底
- 非同期化
- JavaScriptのコンパイル
- Clousure Compilerを採用
- コンパイラの最適化を選べる
- 最大最適化
- 300kbから90kb
- 今までに比べると爆速か
今日の話は、痛い目の実体験
- javascriptの設計をちゃんと考える必要がある
- コード量が増えてもコンパイラで圧縮すると早くなる
スキーマレスなDB
- NoSQL
- mongoDB
- CouchDB
- 独自のデータストア
- CyDE2
- kintoneが使ってるのはMySQL
- NoSQLは整列、集計、JOINに制限があるので、厳しい
- データの一貫性、安全性を重視
- 一番の理由はもともとMySQLが多いので、上からお達しがきた
- 案2
- カラムがあくさんあるテーブルを作っておけばOK？
-
- 性能的には厳しかった
- MySQLだとオーバーヘッドが大きかった
- 案3:kintoneのやり方
-
- 2種類のテーブル
- データテーブル
- スキーマレスなデータを保存するテーブル
- インデスクステーブル
- 悪いことろ
- カラム単位の更新、スキーマレスなデータをそのままいれてるので一括更新ができない
- インデックステーブルが巨大になる
- クエリが複雑になる
よしおか ひろたか 氏 / ショウジ ユウコ 氏 / 16コミュニティ参加
元祖ドラ娘を初めて見た。
Devsumi2012 JGGUG LT
View more presentations from bikisuke
-
- これからJGGUGに参加する人たちが準備するべき３つのこと
- ねこアイコン
- おっさん対策
- これからJGGUGに参加する人たちが準備するべき３つのこと
ここで時間切れだったので、続きはこのスライドで。
Togetterのリンクとその経緯
Developers Summit 2012 Togetterまとめを作ってみた(＆経緯について書いてみた) #devsumi - Shinya’s Daily Report
一歩を踏み出せなかった人、泣く泣く仕事で参加できなかった人、
そんな「仲間」に登壇者の「熱い想い」「言葉」を届けられたらいいな。
