GREE Creators’ Meetup ! に行ってきた #gree_creators_meetup

GREE Creators’ Meetup ! #gree_creators_meetup : ATND

デザイナーではないんだけど今関わっているプロダクトでLWF使っていたり、個人的にUIの話とか興味あったのでご飯を食べに行ってきました。 雑なメモを取ったのでそのまま雑に公開しておきます。

Flashが今後カスタムプラットフォームに注力していく話とか、チームでデザインに取り組むなど良い話が聞けて満足でした。

「ドットの匠」　渋谷員子（しぶや　かずこ） 株式会社スクウェア・エニックス

  • 色数が多くても書きづらいので敢えて32色程度に絞っている
  • ドットは表現が貧弱なので、ディティールよりもシルエットでキャラであることを伝えようとしている

「アプリ開発で活躍するFlashの新しいカタチ」

ネイティブアプリのアニメーションをFlashで制作する　～LWFを使ってみよう～　グリー株式会社　梶川 政雄

Flashクリエイターがネイティブアプリ開発に放り込まれてみた。〜消滅都市の場合〜　グリー株式会社　野口 隼

  • LWFでNativeに作る場合のフローについて

    • Flashはモックが簡単に作れる
    • エンジニアとかディレクターにも早い段階でイメージが伝わる

  • エフェクトはAfterEffectsを使って作っている

    • Flashだけでは対応出来ない場合に使用

  • 自動化スクリプト作った

FlashアニメーターがSpineさわってみた　グリー株式会社　二宮 大輔

  • spineとは

    • ボーンアニメーションに特化してるアニメーションツール

  • Flashより不便なところ

    • パーツ個別のループが出来ない
    • ASが無いので不便

  • メッシュが便利

  • ボーンのimport/exportが可能

    • ボーンさえあれば動き自体はそのまま流用可能
    • 色違いのモンスターとか作るときは描いてもらえればすぐ作れる

  • アニメーションを作るときに連番の画像を使用するのではなく、画像とjson、アトラス化の情報からアニメーションを生成する

    • 単純に軽くなる
    • iPhone 4以降の端末で30キャラ60fpsくらいは出ている

「変数と定数で考えるデザイン」グリー株式会社 村越 悟

  • 世の中のトレンド

    • 端末の大型化により片手持ちが少なくなってくる
    • 指的にタップ出来る有効範囲が下部に寄ってくる

  • デザインにおける変数と定数

    • 変数
      • 市場
      • 技術
      • UX/UI
    • 定数
      • 人間の能力(指の本数とか)
      • 遊び
        • 敵がいてスコアがあって、みたいな
  • 変数のウェイトが非常に高い
    • 先入観ではいけない

  • デザインの現場で必要となってくるもの

    • 観察力
    • 対話力
    • 理解力

  • チーム内ではユーザテストを重要視している

    • ユーザの観察
    • テスト結果についての(チーム内での)対話
    • 課題に関する理解
    • やりかた
      • 一般ユーザ(ゲームプロダクトに関わってない社員など)の操作を撮影する

    • テスト実施後にヒアリング

      • 行動の意図を聞く
      • なぜそう思ったか etc...

    • ユーザテスト後、各画面のフローを壁に張り出して、挙がった課題などの付箋を貼っていく

      • 課題の共有、可視化が出来る

    • ユーザテストの目的

      • チームに対して刺激を与えられる

  • プロトタイピング、ツールとかで画面を見ながら議論したりする

    • 複数人で集まって何かやることが大事
    • 参加協調型のデザインプロセス

大事なこと

f:id:takashabe:20141029234050j:plain

社内でGitHub勉強会開いた

git github

以前からGitHub Tシャツ着てギッハブギッハブ言い続けていたところ、弊社だと初のGitHub案件が回ってきたのでついでに勉強会を開くなどしました。

これまで基本的にsvnでmasterブランチ1本運用みたいなアレだったんですが、さすがに2014年だし既存プロダクトもGitHubに移行していきましょう的な雰囲気が出たのはとても良かった。 おまけに書いておいた非エンジニアでのPR駆動についても、この話をしたところ前向きに話が進んでいるのでもうちょっと布教していきたいところ。

正直まだ運用経験乏しいので、基本的にはブランチ戦略コレで良いかなーと思っているんですが、リリース時がまだちょっとフワフワしていて、例えばdevelopをそのままreleaseにマージしてしまうのか、もしくはリリース前確認用のQAブランチを毎回挟んでそれをreleaseに回すべきか悩んでいたりしてます。

現在はリリース対象の粒度によってどちらも採用している感じですが、それもつらいのでCI導入に合わせて基本的なフロー確立出来ればなと試行錯誤している感じです。この辺はまた勉強会開いた時などに都度共有出来れば良いなァと思っています。

なおGitHub Tシャツはこちらで買えます。輸入で手数料が結構かかるので共同購入おすすめです。(一緒に買いましょう)

「インタフェースデザインの心理学」を読んだ

長い間積んでいたがようやく読んだので簡単な紹介など。

本書の構成

UIデザインを行う上での100の指針が掲載されており、主に心理学などの論文に基づく内容となっている。 引用元が心理学なのでデザインサンプルといったものではなく、人間の行動原理に関わる内容が多い。UIに関係なさそうな項もあったが基本的には論文紹介からUIへの適用例といった内容。

目次および序盤のサンプルPDFは以下から。

面白かったトピック

  • 003.人はパターン認識で物を識別する
    • 人間が物を認識するときは基本的な立体(幾何形態-ジオン)に基づくというもの
    • ジオンで構成した物体の方がより認識しやすい
  • 020.一度に覚えらえるのは4つだけ
    • タイトル通り、一度に処理出来る情報数は4つが限度
    • 例えばタブなどを4つ以下に抑えると認識しやすい
    • それ以上の情報を詰め込みたい場合はチャンクにして下位に情報を持たせる
  • 031.人はシステムを使うときメンタルモデルを作る
    • メンタルモデルはある物事に対してどう理解しているかというもの
      • ユーザの成熟度によって受け取り方が異なってくる
    • 過去の経験などからメンタルモデルは構成される
      • #objectdesignでも話されていたけど、例えば開発者とユーザのメンタルモデルは異なるため開発者がユーザ目線を持つのは困難であるということ。だからユーザ調査をしてメンタルモデルを理解しようとする
  • 054.「内的報酬」のほうが「外的報酬」よりもヤル気が出る
    • 内的報酬とは達成感や何かを習得したいなどのことで、外的報酬は金銭的な報酬
    • 外的報酬によるモチベーションは外的報酬が得られなくなった時点で途切れる
    • 内的報酬によるモチベーションの方が持続的
  • 092.人は自分の処理能力を超えた数の選択肢や情報を欲しがる
    • 「ジャムの法則」商品の選択肢を増やしたほうが立ち止まる顧客は増えたが購入率は下がるという話
    • 020.の4つのルールを適用してみる
  • 093.選択肢が多いほうが思いどおりになっていると感じる
    • 092.と通じるが、1つしか選択肢がないものと複数あるものでは後者が選ばれやすい
    • たとえ効率が悪いものであっても選択肢を複数用意するのは良い

所感

  • デザイン、心理学について学んだことが無かったため多くの学びがあった。本書は構成的にも雑学のような感じなので今後より体系だった本を読むと面白そう
  • メンタルモデルおよび概念モデルについてはUIだけでなく設計やコードにも適用すると良さそう
  • 092.にあるように積読が多すぎると選択肢が多すぎて読むのがつらい。積読を減らそう

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

ChatWorkで画像をスタンプっぽく使う

chatwork ネタ

普段コミュニケーションツールとしてChatWorkを使っているんだけど、同僚からライフハックを教えてもらったのでメモ。

ChatWorkでは画像をuploadする機能があるが、そのまま利用すると画像周りには日時やフレームなどのメタ情報が一緒にポストされる。 ポストした内容は基本的に文字列で管理されていてEditから自由に編集出来るようになっているので、画像の表示タグ以外をすべて消せばスタンプっぽく使えてコミュニケーションが円滑になると思う。

画像のタグ

idはuploadした時点で自動的に採番される。

[preview id=<image_id> ht=<height_size>]

使用イメージ

f:id:takashabe:20140118161730p:plain

gitでパスワードをキャッシュしておく方法

git github

HTTPSでcloneしたリポジトリをpushする時などにパスワードを毎回要求されるのたるいので記憶しておきたい。 設定するたびにググるので備忘のためにメモる。以下の方法はMac専用。

$git credential-osxkeychain
$curl -s -O http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain
$git config --global credential.helper osxkeychain

credential-osxkeychainはgit本体のディレクトリ以下に移動される。homebrewで入れていたとしたら/usr/local/Cellar/git//binあたり

- 参考

IntelliJ IDEAで空行インデントを保持する

intellij idea

今話題のIntelliJ IDEAで空行に設定されたインデントを保持する設定のメモです。

設定方法

Settings > Editor > Other > Strip trailing spaces on Save を None に設定するだけ。

適用範囲

パラメータ名通り、保存時に空白を取り除くことを抑制します。Noneの他にもAll、Modified Linesがあり、それぞれファイル内全てと変更した箇所に対して空白を取り除きます。

ただしReformat Codeには適用されないので注意が必要。formatの設定で空白を残すような設定は無いような気がするけどpluginとかを使ってformatしてあげれば良い感じの挙動になるのかな…。この辺り知っている人いれば教えてほしい。

いつ使うの？

既存のコードベースが空行も含めてインデント使ってるような場合とか。ぶっちゃけIDEだけでやるならIDEのformatに任せたほうが良いと思う。IntelliJだとインデントレベル表示してくれるし。

JAWS DAYS 2013 DAY 2 に行ってきた #jawsdays

aws 勉強会

JAWS DAYS 2013 | 2013/3/15（金）～16日（土）東京ビッグサイトで開催！ 2日目に参戦してきたログです。

まとめやustはこちら


ここでは感想的な何かを書いておきます。

Opsの人多い

セッションはOps、Dev系にカテゴリ分けされており、Devが2セッションのみで他は全てOps系というOps色強い感じでした。
ただ実際にはOpsな人でもコード書いてたりしてOps≒Devといった感じの人が多かったように思います。Opsな人はDevのことを知る必要があるし、逆もまた然り。

Devのアーキテクチャの話

Devのセッションは以下の2つがあり、どちらもAWS上でシステムを作る場合の設計指針とかそんな感じでした。


それぞれ特性が異なるアプリケーションでしたが、キューを挟んでスケーラビリティを向上させるアプローチが共通していて興味深かったですね。
SQSは一貫性が保証されていないのでそこをどうするのって話。

  • TDではSQSを使わずにRDS上にキューを実装(コードは以下github)。懇親会でお話を伺ったらAWSに閉じないようトランザクションがあるRDBMSであれば使えるpluggableな形にする意図もあったとのこと。
  • ソシャゲの方ではそもそもRDBMSを使わない方針であったため、SQSを使用してアプリケーション側でキュー処理に楽観的ロックを実装して対応。
    • ちなみに僕はこのソシャゲの会社の中の人なんですが、設計指針とか詳細にあるので弊社社員にこそ見て貰いたい内容でした

まとめ

  • Devの人もインフラに興味持ちましょう
  • スケール出来る部分とそうでない部分の設計をやりましょう
  • AWSカルタかわいい

以上、小学生並みの感想でした。
とても充実した1日でした。運営、スピーカーのみなさまありがとうございました。