10/25/2012

[&] Android App Designs Vol.4

デザイナーがコードから読み解く、
Androidアプリのデザインの幅を広げるコツとTips
http://www.ladybeetle-design.com/androidappdesigns/




----------------
第4回 レイアウト編

@tommmmy
小さなチップスではありますが、デザイナーの方に広めたいとおもっている事柄を
協力して頂いて、勉強会を開催できているのはありがたいことです!

GMO稲守さん : Zuck「(HTML5は)早すぎたんだ腐ってやがる」(ナウシカの巨神兵)

@tommmmy
最終回ですね〜
ドキドキですね〜
4回これで、今日最終回ですが、総集編として 11/8 木曜日に GDG Tokyo 主催で、
現在募集が始まってしまいました!

まず、今日、今までで一番多いような気がするんですが、
アンケートをきいてみました。圧倒的にエンジニア/開発者の方が多いです。
デザイナーさんも来てくれているのがうれしいです。
この勉強会3回やってこれました。

がんばって作ったデザインが
実装後に残念な結果にならないために
最終的にレイアウトの話をしますが、
デザイナーがわかっていると、思った通りの実装になるとうれしいです。

前回カスタムUIの話をしました。
スライダーがカスタムデザインにすると、つまみのデザインに注意
しなければいけないという話をしましたが、
あんざいゆきさんが解析してくれました。

レイアウト編
1. よくつかうレイアウト
2. 単位と空白
3. PSやWFでデザイン案を作るときの3ヶ条

●デザイナー向けレイアウト入門
デザイナーはどうやって実装されているかなかなか分からないと思うので。。。

1.よくつかうレイアウト
wrap_content インライン要素っぽい
fill_parent/match_parent ブロック要素っぽい
常に指定していかなければいけません。
android:layout_width="fill_parent"
android:layout_height="wrap_content"

一番簡単なのをみてみます。
pulse アンドロイドアプリのページ。
テキストビューが4つ並んでいて、ImageVIew が並んで、
上から順番に並べていくだけという書き方をしています。
このTextView 一個一個に対して設定しなければいけないので、面倒です。
これをまとめて
LinearLayout というタグで囲んであげます。
中身が横並びなのか、縦並びなのかを教えてあげれます。
単純なものだと良いのですが、タイムライン的なものだとややこしくなります。

横に並べというものを一番大きなものを横に並べます。
さらに中にある部品を縦に並べてあげて、その中をまた横に並べます。
ややこしいことではないのですが、
後でソースコードを見るとややこしくなっています。

LinearLayout の難点
構造が複雑で、階層が深い
数が多いと、重い原因となる
今ある要素以外の領域を示すことができて
android:layout_weight="1"

残りの領域全部を埋めることができます。
縦も同じなので、上下に部品があって、間を広くとるときは、
layout_width="fill_parent"
layout_height="0dp"  とします。
Androidいろんな画面サイズがありますが、中央をいっぱいいっぱい使えるようになります。

[ cancel ] [ OK ]
layout_weight="1" 両方1にすると、同じ幅になります。
layout_wight を 1:2 にすると、
ボタンが 1:2 のサイズ、その割合で、表示してもらえます。

LinerLayout の得意なこと
等分割や割合を指定した分割が得意
使わないスペースを最大限にのばすことが得意

●RelativeLayout

基本どんなレイアウトでも、どっちでも組めるのですが、
表示が重くなったりするので、最大のパフォーマンスはどれなのかを
考えながら実装していかなければいけません。
Twitter のタイムラインのような場合、
Relative は「相対」という意味があるので、
まずは「親」となるものを決めます。
それに対して、自分がどこにあるのかというのを設定してあげます。
何が便利かというと、構造が簡単になります。
これを頭に入れておいて.....

ぼく親だよー  android:id="@+id/Oya"
ぼく親の右どなりAだよー android:layouttoRightOf="@it/Oya"
ぼくAの右どなりのBだよー android:layout_toRightOf="@id/A"
ぼくAの下でAと左端が同じなCだよー

いろいろありますが、構造がなんとなくわかれば、
調べて使うことができます。

RelativeLayout の得意なこと。
LinearLayoutだと階層が深くなってしまうところを、
軽々と1階層で表現できる!
パフォーマンスとやりやすさを考えながら、トライ&エラーで。

●FrameLayout
重ねるときに使おう
Facebookアプリで、一回タップすると、下にコメントなどが出ますよね?
下の方がグラデーションで暗くなっていますよね?
写真が白っぽかったりすると、白背景に白い文字だと見にくくなります。
なので、少し暗くなって見やすくなっています。
最近、こういうのが増えてきています。
Google+アプリ、文字の背景の透明が少し暗くなるようになっています。

写真の背景に黒いグラデーションを入れて白い文字を
見やすくしています。
一番下に ImageView があります。fill_Parent にすると画面いっぱいに広がってくれます。
真ん中のグラデーションは Shape でやります。
startColor #8000
endColor #0000
これで綺麗に実装できます。

他にも pulse の写真画面。
あと、よく使うレイアウトで、
スクロールも必須ですよね?
スクロールもすごく簡単です。
最初は Java を触らないとスクロールできないと思っていました。
ScrollView の中に要素をいれます。
要素はひとつだけです。

複数使いたい場合は、一度リニアレイアウトを入れます。 
リニアレイアウトの中には何個も入れられます。

pulse は全体がスクロールしますが、各要素も横スクロールします。
スクロールに horizontalScrollview を入れると、横スクロールしてもらえます。
これをデザインするときに考えるというと....
知らなくてもいいですが、デザインする時にプラスになることも多いと思います。

後半は単位の話からはじめていきます!

------------------------------------------
●コネタ:山本さん

XMLは書けないデザイナーです
FWでデザインして、切り出して、エンジニアの人に使ってもらうしかできないのですが、
あちこちで聞く話、問題なんじゃないかという話をします。

エンジニアの人に聞く話ですが、
PhotoShop を使っていると思うのですが、
パースを切り出してお渡ししているのですが、
多くのデザイナーは PhotoShop PSD のデータのまま渡しています。
「はい、これで私の仕事は終わり」とか。
その後、エンジニアの人は、レイヤーを切り替えて、自分でスライスをして、
ファイル名をつけて、作業をしています。

エンジニアの人にパーツを切り出して渡す時に、一緒にわたした書類です。
パーツ名の一覧を書いてCSSも書いて渡しました。
#書きすぎて、半分くらいしかいらないんだよ!と言われてしまいました。

Q : 結構時間かかりますよね?
A : 一日じゃ終わらないです。

添付しないとどういうことになるかというと....
パーツというフォルダの中身をお見せしていますが、
Native と HTML が混在していたアプリです。
相当の数の画像パーツが入っています。
それとは別に Native 用のパーツ、Android用、iPhone用、
さらに画面サイズ用のパーツがあり、
切り出したパーツがボコボコあります。
PhotoShop PSDファイルごと渡されたとしても、大量の画像が送られてきた時に、
わけがわからなくなりますね。

毎回スゲーありがとう!と感謝してくれます。
どうすれば良いかというと、PhotoShop PSDだけの人は、突っ返すべきだと思います!
どこの画面をどこに実装するのかわかんない!と言うべきだと思います。
画像ファイル一覧、どの画面でどこで使うのか、一覧を書くべきだと思います!

------------------------------------------
●コネタ:@adamrocker
実践!Android Design

今日はログが書けないくらいのスピードで話します!

Android Design のページにいろいろ載ってます。
http://developer.android.com/design/index.html

設計指針 Get Started
様式 Style
パターン Patterns
準備されているもの Download

気になるところから読んでみてください。
Pattenrns のところをいくつか読んでみました。
デザインテクニックとは関係無しで、エンジニアもある程度理解できます。



実際は.... というと ActionBar Pattern を使え!
と声を大にして言いたい!
絶対使ってください。
いろんな端末がありますよね。
ActionBar は端末に応じて、自動でいい感じにしてくれます。

ActionBar にタブをおさめてくれるとか、
タブレットの時とか、小さい端末でもうまく動いてくれます。
ActionBar にいろいろ入れて、調整してもらえるので、
自由に使える領域にもなります。

ActionBar の機能は Android OS 3.0 からなので、つかえないかな?!と思ったときは
ActionBarSherlock を使えば Android OS 2.X からサポートしているので使えます。
http://actionbarsherlock.com/



Drawer (スライドメニュー)が流行です。
どんなものかというと、
facebook アプリ youtube アプリなど画面遷移することなく、横に移るものです。

simple-side-drawer というのをつくりました。
さらっと使えるので、よろしく。
https://github.com/adamrocker/simple-side-drawer

コードを2行足してもらうだけでOKです。
taggleDrawer で閉じたり開いたりもできます。
コードメンテナンスの必要があるので、誰か手伝って欲しいです!



simple-side-drawer の特徴は...
●2行で組み込めます。
●他のライブラリとの親和性もあります。
●なによりも、軽量ライブラリです、6.4kbyte 画像1枚分にも及びません。

これがどうなっているかというと......
実は Android の一番上に
decar の上にレイアウトが載るのが一般的です。
decar の上に FrameLayout を載せて、
元々あるものを載せています。



概念的にはこうです。
300行ぐらいなので、メンテナンスしやすいので、だれか手伝ってください!
(僕はもう作りたくないです。)

あと、Android Bazaar でも話してきたんで、よろしく。
http://goo.gl/igbpB

■まとめ
●Android Design を読んでくださいね。
●ActionBar を使いましょう〜
●simple-side-drawer をよろしく!

---------------------------------------
2.単位と余白

後半戦20分ほど、がんばります。
まずはちょっと地味な話、単位の話です。
Android アプリで使う単位の話です。
dp と sp です。
Density-independent Pixels, Scale-independent Pixels
なぜ説明をさけてきたかというと、わかりにくくて、説明しづらいからです。
エンジニアの人も理解していると思うのですが、
言語化して説明するのは難しいのです。

dp について。
考えないといけないのは Andorid は画像サイズとか、解像度の違いです。

GDD Phone Galaxy S2
320px x 480px 480px x 800px
160 dpi 240 dpi
1 1.5
320dp 320dp

画像解像度、画面密度も違います。
同じ数値で扱えれば便利ですよね?

160dpi 240dpi 320 dpi
mdpi hdpi xhdpi
1 1.5 2
1dp 1dp 1dp
1px 1.5px 2px

mdpi の端末は少ないので、hdpi と xhdpi を考えればいいです。
小さく作ったものを大きくするのは面倒なので、
大きく作ったものを、小さくするのが楽なので、
xhdpi 用につくるのが便利な方法です。

●sp について。
主にテキストに使います。
4.0 からフォントサイズを setting で変えられるようになっています。
フォントスケールということです。

Small 1.7
Normal 2.0
Large 2.3
Extra Large 2.6

xhdpi を中心としてデザインを作っていきましょう。
pulse アプリをキャプチャして確かめてみました。
比べてみた時にかなり同じだったので、推測はあたっていると思います。



重要なのは dp/sp を意識すること。

dp と sp
Density-independent Pixels, Scale-independent Pixels

Photoshop には sp/sp は無いので、
結局はピクセルで扱うことになりますが、
デザイナーもそこを考えてみようというものです。

ガイドラインに書かれているものも全て単位が dp です。
タブレットは 960dp 1280dp とか。
その中で、
メトリクスグリッド 余白の取り方の例も dp で書いてあります。
さらにサンプルも dp、テキストも sp という単位で書かれています。

デザイナーがドキュメントを読むときに、dp, sp あっても、
どうやって作ったらいいか分からない。
自分は今 xhdpi と考えて、今何ピクセルなのかを考えて作っていけばよいです。

実施は.....
PHONEサイズの場合、横幅が 320sp か 360 dp に。
縦幅は端末によって違いますが、
320dp



xhdpi で作って、Photoshop を開いて、横幅何ピクセルにすればいいの?
1dp = 2px なので、360dp なら 720px
ガチガチに合わせるのではなく、多少高さが変わっても合うものを作るのが
ポイントです。
横幅もおなじコードで表現した方が良いです。

実際にガイドラインでダウンロードできるステンシルは、
360px なので、高解像度になっていません。
単純に 2倍に拡大してから使わないといけません。

実際に作ってみました。
xhdpi 用なので、横幅を720px にしています。
ここで考えていかなければいけないのは dp をどう基準につくっていかなければいけないか?
360dp の横幅
タブビューは 48dp の幅にします。
なんで 48dp に決まっているのですか?
端末で見た時に、7mm から 8mm になるので、指で押しやすい幅。
押すボタンとかは 48 dp を守りましょう。となっています。
さっきの計算式でいくと、720px の横幅、96px でデザインすると
綺麗にあがってきます。



余白、細かいですが、すごく重要なので聞いて欲しいです。
この写真の上側 12 dp 下側、内側の余白が 12 dp
画像と文字の間も 12dp
これもまた、それぞれを 2倍していくと、何ピクセルで作るのかが
決まってきます。簡単ですよね?



次は文字のサイズです。
ガイドラインにもありましたが、4種類のサイズを推奨しています。
タブのところは 12sp など。
結構 dp sp で考えていないので、フォントのサイズは結構目分量でした。
端末で見て、目分量のことが多かったです。
ガイドラインのように綺麗に作っていかないといけません。

余白、マージンの値を入れてみました。
実際に実装してみました。
左側が Photoshop でピクセル換算して作ったデザインです。
右側が Galaxy Nexus で実装したものです。
Photoshop のものと見比べて、全然違いは無いですよね?
あえていうと、タイトルの上下に隙間が入っている分がちょっと違うくらい。

ちなみに、HTC Desire 解像度 320dp 横の端末。
ただ単純に文字群の幅が違うだけで、余白は綺麗に実装されています。
デザイナーは Photoshop ぐらい余白やフォントも考えて実装して、
sp, dp で仕様書を書くと、デザインしたものが綺麗に仕上がっています!

基本的なことがわかれば、同じ配置にして色を変えたりもできますし、
枠を入れたりして、可愛い感じにすることもできます。
全然簡単です。
枠を入れたところについて言うと、
隙間は 8dp で入れています。全然綺麗です。

ということでまとめ。

●Photoshop や Fireworks でデザインを作るときの3ヶ乗

1. サイズは(ほぼ)2種類
320dp と 360 dp の横幅があり、大きいもので作った方が良く、
両方のサイズがあることを考えながらルクレバ、両方にあいます。

2. xhdip の余白は 4nお倍数の dp だとベスト!
hdpi になっても整数になる。
1.5:2 なわけです。何をするにも。
1.5:2 = hdpi の余白 : xhdpi の余白
比の勉強になり、3/4 になります。
4の倍数になれば、いかなる時にも割り切れます。
デザインガイドも、みごとに4の倍数になっています。
4の倍数で考えておけば、どこでも綺麗になります。

3. 作ったあとは、実機で確認(要ものさし)
何mm になるのかを実際にチェック

dropbox に入れて実機で見る他に、
Android Design Preview というツールを使います。
http://code.google.com/p/android-ui-utils/
パソコン場面を USBでつないだ Android 端末の画面にそのまま送ることができます。
実際に触って大きさを確認することができます(動きませんけど)
Photoshop 上で、360dp 用に作った素材は 320dp 端末の時には Photoshop の表示を75% にすれば良いです。
その後は物差しで計って、48dp だと 9mm 前後なので、チェックします。

デザイナーにも広めたいと思ってはじめた勉強会です。
結構な人に共有できたのかな〜と思います。
デザイナーがこういう気持ちでデザインしているのかがわかれば、
エンジニアがデザイナーに伝える時に分かりやすさが通じれば満足です。

Android Layout Cookbook を読みました。
何の知識も無くて読むとハードルが高いですが、勉強会を聞いてからだと、
分かりやすく入ってきます。ICSの本はデザイナーが読んでもわからないです。

11/8(木)に総集編をやります!
http://goo.gl/iLBpo

10/24/2012

[&] Webapp Workflow & Yeoman



Chrome Tech Talk
--------------------
ウェブアプリケーション開発のワークフローと Yeoman
( Webapp Workflow & Yeoman )(講演者:Paul Irish)

発表スライド
https://dl.dropbox.com/u/39519/talks/tok-workflow/index.html#1

Web App を楽しく構築することに関して話していきます。
Yeomen についての話をします。

最初に質問いたします。
JSHint または JSLint を使っていますか?
テスト用、デプロイ用に自動化をしていますか?
Yeoman, Codekit などを使っていますか?

今現在のトレンドとして登場していきているのは、
ブラウザの互換性など細かいことに集中するよりは、
ツールを整備することで対応するものです。

Your shell
Yeomen
Testing
Style iteration
Devtools tricks
Rainbows!

●Your Shell
OS X のデフォルトのターミナル画面です。とても汚いです!
シェルをもっと魅力的なものにしましょう!
github.com/paulirish/dotfiles/../.bash_prompt
この方がカラーがあるのでみやすいし、
どのブランチに居るのかがわかります。

レポジトリで変更がある場合の表示とか、
リモートサーバーにログインすると、どのサーバーにログインしているか分かります。
このタブの方にもタイトルがついていて、どこにいるのかわかりやすいです。

dotfiles.github.com
のコミュニティで自分の好きなものを選んで使ってみてください。

Dotfiles: 好きなものとしては
ジャンプするための z
instant webserver 用の server
色づけする cat

git にコミットするごとに自分の写真を撮る機能とか!(笑
これを動画にしてみました!

Time lapse of my git commits from Aaron Forsander on Vimeo.


Deploy on push
git にプッシュするのは、ワークフロー上良いきっかけです。
ssh key をサーバーに展開すると、deploy.php という小さなスクリプトを
作ることができます。
サービスフックが加えられます。
したがって、その後は、プッシュをするごとに、なにかさせることができます。

そうやって、
開発者フローをさらに改善していくことができます。

●Yeoman の紹介
Webアプリを作る上で、より魅力ある形で、
楽しくそれをすることができる、フレームワークが Yeomen です。

Yeomen で利用可能にしているもおは、
Sass, Coffescript で、オーサリングすることができます。
AMD, ECMAScript のシンタックスもサポートしています。
Bootstrap, HTML5, Mocha nado.

Yeomen のデモ
% yeomen init
いくつかの質問に答えていきます。
Twitter Bootstrap を含めるか?
Requires JS, など。
依存関係をサポートしたファイルができます。

% yeomen server
実際に動いているところをみることができます。
% yeomen subl
% subl app

サイト用の CSSをオーサリングしているところです。
ファイルを変更すると、すぐに変更が反映されます。



もう少し複雑なものも

●Package management
パッケージ管理したいとうのが yeoman で解決したいことのひとつです
つまり JS を使えばできるわけですが、依存関係を解決できれば、
より高いレベルのパッケージができるわけです。

Yeomen でバックボーンパッケージを検索しています。
backbone.rpc というのを選びます。
これは、パッケージを見にいって、ソースの依存関係を見て、アプリの中に取り込みます。
ある一つの依存関係が期限切れになった場合、通知してくれるメリットがあります。
ご覧のように、古いバージョンをインストールしようとすると、新しいバージョンがあることを
知らせてくれます。

いちいち、いろんな全てのブログやツイートをトラッキングしなくても、
ツールの方で、新しいバージョンを知らせてくれます。

もうひとつ、Generators という機能があります。
特定のモデルやコントローラ、ビュー、
タブレットでプロジェクトを作ることができます。
ビルトインサポートが入っていて、非常に良く使われるJSライブラリが入っています。
新しいコントローラを加えたい場合は、
コマンドを入力すると、テストスクリプトも含めて必要なファイルを作ってくれます。
Unit テストをすぐにスタートすることができます。
Angular とYeomen が連携して機能します。

JavaScript を変更して保存すると、ページが更新されます。
新しい素晴らしいものを加えることが簡単にできます。
かなり短時間で、インタラクションが完成します。

Yeomen のまとめ。




安定性、テストをすることができ、アプリケーションを構築し、テストを繰り返すことができる。
ビルドスクリプトで何が走っているかみることができます。

Yeomen 0.9.4 が最新バージョンです。
http://yeoman.io/

●Testing
テストの話を細かくしていきます。
Testing your unit tests
ブラウザの中でテストを走らせます。
ブラウザの中でテストスイートしてテストを完了させることができます。
コマンドラインでフィードバックが帰ってきます。

興味深いこととしては、モバイルのテストの時に、必ずしもモバイルの端末が無い時もあります。
エミュレートされたモバイルブラウザ、シミュレーター上のブラウザでテストすることができます。
bunyip というツールを使って、ユニットテストもできます。
http://ryanseddon.github.com/bunyip/
ブラウザ完結するテストができ、各プラットフォームでどうなのかができます。

十分に楽しみながらテストするのが重要です
テスト中はコマンドラインに mocha-NyanCat が表示されます(笑

●Style Interation
CSS を統合するいくつかの例を紹介します。
Sass + LiveReload を使っている人??
Saas でやれば、オリジナルのソースに戻すこともできます。
エクスペリメンタルのサポートを ONにすると、
Chrome Developer Tools の中で変更することができ、すぐにフィードバックが得られます。
非常に便利で、ミックスすることもできます。

●JavaScript の IDEである WebStorm を紹介します。
HTMLを見て行く、選択したエレメントが、Chrome ブラウザ上で確認できます。
変更したところを、すぐにブラウザで見ることができます。

自分にとって便利なツールを選びましょう!
setup というコミュニティがあります。
http://setapp.me/

開発することだけではなく、良い環境を作るのも仕事。
同じことを繰り返していて、面倒ならば、だれかが便利な手法を使っているはず。
だれもしていなかったら、自分でやろう。

Styled Console Messages
console.log() は一般的なものですが、それに CSS を加えることができます。
スタイルによって、黒くすることもできますし、
コンソールログで表示することができます!!

[&] From High-DPI to multi-touch: cutting edge mobile web





Chrome Tech Talk
--------------------
モバイルアプリの最新動向 - High DPI とマルチタッチ
( From High-DPI to multi-touch: cutting edge mobile web )
(講演者:Boris Smus)

プレゼン資料
http://smustalks.appspot.com/japan-12/#1

みなさんこんにちは Boris といいます Mt.View で仕事をしています。

モバイルweb開発がいかに増えてきているか?
モバイルで使っているユーザーが増えてきています。
ごらんのように2014年くらいに、Mobileユーザーがデスクトップユーザーを
追い越すことが予想されています。
モバイルというのはどういうことでしょうか?
デスクトップではありませんね?
モバイルWEbのバリエーション
スクリーン密度
フォームファクター
インプットのタイプ
いろいろ問題になりますが、後で触れます。

●スクリーン密度、Density のバランスの話から。

初期のPCは、解像度が非常に低いものでした。
現在のPCでは増えています。
多くのピクセルを使って表現できます。
なので、固有のピクセルを指定してしまうと、画面上では小さくなってしまいます。
CSS pixelsで定義します。
Density には関係なく、利用できます。

拡大ができるものとしては、テキストや SVG, CSS は簡単に拡大できます。
ビットマップ画像に関してはできません。
ボタンとか Gradients など、UI部品に関してはイメージを使うのを避けるのが良いです。
とはいってもフォトギャラリーのように使わざるを得ない時もあります。
できるだけ効率よく、ハイクオリティーな画像でサービスをすることが必要です。

アプローチとしては二つの方法があります。
一つの画像を最適化します。
一連の画像のセットから、最適なものを選んで使う方法があります。

したがって、
クオリティの高いイメージを選ぶと大きさが大きくなってしまう。
2倍から4倍くらい大きくなってしまいます。
それに対して、WebP は 30% くらいさらに圧縮して小さくできます。
必ずしも全てのブラウザがサポートしているわけではないので、
うまく使えないときもあります。

したがって、そういったものに対するソリューションとして、
クオリティーを犠牲にして利用するのは、
1x quality 90, 2x 30%
ピクセルサイズではなく、画像のクオリティを下げて使う。

イメージのアーティファクトが出てしまう。
可能な限り、マニュアルでスケーリングした方が良い。
自動でするよりも。
複数のイメージのアプローチにする。マニュアルでスケーリングして
一番いいものを選ぶのが良い。
JavaScript で利用できます。
多くのスクリプトで利用できます。

しかし、loolahead のパーサーを使うとうまくいきません。
Server-side で対応する方法もあります。
唯一判別できるのはユーザーエージェントの文字列しかありません。
ですから、クライアント側で JavaScript を使わない方法としては、
Media Queries を使う方法です。
デフォルトでクオリティの低い画像がロードされるようになっています。
スクリーンとして高画質に対応できるものに対しては、高画質のものを使います。
スピードが遅い接続状態で、高画質のものをロードするのは困ります。
ですから、そういった場合に、ブラウザの image-set を使います。
ブラウザが最適化されていれば、ネットのスピードに対応します。
これはまだ Chrome と Safari でのみ現在利用可能です。

このように、スクリーンイメージでは、BackGround のイメージの話をしましたが、
コンテンツのイメージに関しては?
CSS4 の srcset はまだ実装されていません。
image-set で代用して試します。

まとめ。
適切な fallback で、image-set を使う。
クオリティが良く無いイメージでも我慢できるのであれば、圧縮画像を使う。

●From Factor variations
モバイル開発をする場合、こんな風景と相対さないといけません。(端末がいろんなものがある)
どう対応するのか?

例1
一つのバージョンを作って、それでえいやっと全部に対応してしまう。
サイズが小さすぎるとか、全然機能しないとかが生じる。

例2
別の方法としては、個別対応があります。
しかし非常に無数に数があるので、そんなんこともできません。

中庸:
二つの極端な例の間をとります。
いろんな異なるフォームファクターがあり、スマートフォン、タブレットサイズ。
しかしそれ以外で、プラットフォームの違いがありますが、
フォームファクターの違いの方がおおきいです。

一つのアプローチとしては、
レスポンシブデザインを使うということです。
CSSをロードし、ページの幅に依存して調整します。
あるいは、Developer Tools を利用して、ページを小さくしてためしてみることができます。

Media query Limitations
場合によってはメディアクエリでは十分ではありません。
あるフォームファクター特定の機能をロードする必要があります。
JavaScript でこれが実現できます。
任意のメディアクエリを評価することもできます、
あるいは変化に対して、注意深く問い合わせることもできます。

Multiple Version
別のアプローチとしては、タブレット用、スマホ用と切り分ける方法もあります。
タッチサポートを確認するために Modernizr.touch を使います。

スマートフォンとタブレットの特性を十分に分けておく必要があります。
いろいろな解像度があります。
縦横画面モードがあります。それを加えると複雑になります。
したがって650ピクセルでラインをひくと...........

ドキュメトの一番頭で、そのセマンティックを記述します。
github.com/borismus/devices.js
自動的にロードします。
自分が宣言したものを見て、その中でどれかを選びます。

サーバー側での対応;
deviceatlas.com
wurfl.souceforge.net
ユーザーエージェント文字列を使う例もあります。
デスクトップ上でこれらのエージェントを Chrome Developer TOols ではシミュレーションして使えます。

●Input variation
最後のセクションは、インプットのバリエーションです。
マウスとかキーボードとかが一般的な方法です。
これがスマートフォンになっても、キーボードがついているものがありますが、
タッチが登場して、大きく入力の方法が変わりました。

覚えておくべき大切なことは、
タッチはマウスとは全然違います。
そもそも、hover state は無いし、マルチタッチもないし、
入力そのものが精度が無く、荒いものです。





タップ、ダブルタップ、ジェスチャなど。

Touch events
タッチイベントの仕様
events: touchstart, touchmove, touchend , touchenter, touchleave
properties, touches, targetTouches など。

Chrome 上でタッチイベントをエミュレーションすることもできます。
lab.hakim.se/scroll-effects/mobiel.html
タッチそうさをべミュレーションするというところにチェックすると、
タッチデバイスと同じようにスクロールできます。

スクロールが邪魔なので、スクロールしたくない時もあります。
ほとんどのブラウザでは、touchmove しないようにしてます、
IEの時はちょっとやり方が違って CSS で対応しています。
ブラウザ固有のジェスチャなので、ものによっては上書きできないものもあります。
ピンチ、スーミングが出来ないものもあります。
そういったニーズが無い、適切な使い方を。

Touch performance
モバイルWEbでタッチはクリックにくらべて、遅れます。
マウスイベントに比べて、300ミリ秒の遅れがあります。

More on touch performance
同時に多くの指がある場合、そういう場合は
タッチのパフォーマンス問題にぶつかります。
したがって、入力と描写の描く作業を分ける必要があります。
アニメーションフレームをリクエストする方法があります。
何時レンダリングするのかをブラウザ側で決めます。
ここで問題があります。
だいたい、マウスもタッチも両方サポートしたい場合があります。
そうすると、両対応の必要があります。

ジェスチャーは実装しにくいものです。
ピンチズームの例としては....
あまりにも長過ぎます。

ポインタイベントを使うという方法です。
マイクロソフトからのアイデアです。
最近これが規格になっています。
大部分のブラウザでは使えませんが、ライブラリがあります。
github.com/borismus/pointer.js
すべてのマウスイベントがポインタイベントに変換されます。


many JS Gesture Library いろいろライブラリがあります。
リロース的にはポインタの上にジェスチャを実装したいのですが、
なかなかそうもいきません。

https://github.com/borismus
http://smustalks.appspot.com/japan-12/#1
@borismus


10/04/2012

[&] Android App Designs Vol.3

デザイナーがコードから読み解くAndroidアプリの
デザインと幅を広げるコツとTips #3
http://www.ladybeetle-design.com/androidappdesigns/
-------------------------------------------------------
カスタムUIみなさんはやりますか?

がんばって作ったデザインが実装後に残念な結果にならないために
ある時ふと考えて、XMLを勉強してみると、
おもいのほか HTML/CSSと似ていて分かった。
皆と共有しようと!と勉強会を始めました。




@tommmmy
今はBaiduでSimejiの開発のフロントエンドの一部を担当しております。

■1.カスタム UI について
カスタムUIとは。
●チェックボックス
●ラジオボタン
●スライダー
●シークバー
●スライドバー など
デフォルトで決まっている部品のデザインのカスタマイズをしていきます。
デフォルトで決まっていますし、OSによって違いますし、
OSのバージョンによっても違いますね。
そこを Android でどうやってカスタマイズしていくかというと...

カスタムUIって使う?
結構皆さん作ってますね?
カスタムUIは一長一短があります。
やればいいというものでもありません。

まず、iOSがどんなものかを見ていきます。
ON/OFFのトルグボタンです。
右と左で ON/OFFが切り替えられるよー
バージョンによって、丸かったり、四角かったりしますが、
コンセプト的にはほとんどかわりません。
これが Android だと???
黒い設定画面にボテっとしたボタンが並んでいます。
メーカーによって違います。

スライダーを見てみると、メーカーによって違います。
4.0以降になると、ちょっとシュッっとしてきました。
アプリの中に入れても奇麗に使えるようになりました。
チェックボックス くせ者ですよね〜
黒い背景であれば、黒のチェックボックスは「有り」かな〜
黒い背景にいきなり灰色のボタンが出てくると変えたくなりますよね。

■デザインをカスタマイズする理由
実は、変えたからオシャレで良くなったというような
単純な理由ではありません。普通のデザイン以上に注意深くする
ひつようがあります。いいところ悪いところがあります。

いつ使う?
●ユーザーに何かを決めてもらうとき。
●現在のステータスを何かしら提示したいとき
ユーザーが決めたいとき、自分がどういう位置にあるのか分かるもの
なので、奇をてらったデザインをしてしまうと、ユーザーに伝わりにくく
なる可能性もある。
簡単な気持ちでカスタムUIにしてはいけないな〜

■デメリット
●いつも見ているものと違うとビックリする(かもしれない)
●それが自分で操作できるものかがわからない(かもしれない)

迷わせてしまうのはいけません。
押したらチェックが入りそう?押したら選択されそう?
といのがわかるデザインにしなければいけません。
スライダーであれば、つかんで動かす。つかめそう?動かせそう?
というのが分かるデザインであることが絶対条件。

■メリット
●端末によるデザインの違いがなくなる
●アプリのデザインとして統一感がでる(ブランディング)

普段自分が使い慣れていないものに対してユーザーの気持ちを考えると
ひとくくりにメリットだけではない。そのへんも考える。
ふんわりしたデザインの中にグレーのボテっとしたデザインがあるのは
うれしく無い。でも全部の端末で合わせる必要は無い。
普通のユーザーは Android を一台しか持っていないので、

実はカスタムUIは製作者のエゴかもしれない!と思ったりする。
奇麗なものを使いたいという意思はあるのだが、
単に変えればいいというものでもないので、よく考えて。

■ちょっと物知りのクライアントさん

→カスタムUIにしてください!
←どういう感じにしたいですか?
→いや、クライアントさんがそうしたいって言っているんで、なんでもいいです....

クライアントさんも、アプリに関してはド素人だと思います。
アプリを触ってはいると思いますが、作りに関しては素人です。
ちゃんと話を聞いて、噛み砕いて理解する必要があります。

→Androidはメーカーによってデフォルトのデザインが違うから、そろえて欲しいそうです。
←なるほど、そのとおりですね。
←なぜそろえてほしいのですか?

いろいろ話を聞くと、聞き出すことができて、うまくいきました。
クライアントに聞くのが難しければ、こちらから説明してあげる。
UIって複雑なもので、いろいろな理由があることをクライアントに
教えていかないと、ものすごくイイアプリはできません!

クライアントさんにもちゃんとした理由を考えてほしい。

■使うのに適した場面その1
●設定がメインとなるアプリ
10/1 に新バージョンがリリースされて設定画面が奇麗になりました。
simeji は IMEなのでアプリとしては設定画面ばかりです。
中を見ていただくと、チェックボックスで設定をしたりというもの。
設定の項目ばっかりです。
いっぱいあるし.....
これがもしデフォルトのチェックボックスが並んだら....
と、考えると是非変えたいと思いました。
背景が黒ならデフォルトでも良いのですが、
simeji はふんわりとしたテクスチャを使っているので、
カスタムUIにしたいいと思いました。

■使うのに適した場面その2
●世界観をだしたい場合
magic hour
スライダーとか、ON/OFF のボックスも、なじむように奇麗にしています。
grid lens
設定画面がぶっ飛んでる!レイアウトを決める画面とか。
オプション画面が、もう設定画面すらない!ラジオボタンですらない!
世界観を出したい時にはとてもいいと思います。

■そもそもの段階で....
●本当にやるべきかどうかをしっかり考える(コンセプトも考えて)
●予算面
というのもあると思います。予算が無くて出来ない場合も....
確実に工数が増えるので、お金をかけてもカスタムUIにするかどうか。
そういう話をした上で、やると決まったら....

■気をつけることその1
ユーザーが「自分で決めれる」ということがわかるものにしないといけない。
ToDoアプリの例。設定画面。ON/OFF すごく書いてある。
テーマも白か黒か?パッと見て、なんだか良くわからない。

■気をつけることその2
ユーザーが「自分がどういう状態か」というのことが
わかるものにしないといけない。

キャンバスの向き「縦/横」
一瞬、どちらが ONなのか分からなくなってくるような失敗デザインです。
ちょっと工夫して、ちょっと色がつくとわかります。

■気をつけることその3
あくまで脇役なので、必要以上に華美になってはいけない
また、デフォルトと離れすぎるとびっくりする。

ワリカンアプリ The 割り勘 というアプリ
○で囲ってあるのが設定画面。ぱっと見てびっくりしてしまう。
黒板をモチーフとしてあるもの、押すものと分かるものはあるが、
ちょっとびっくりします。

■気をつけることその4
世界観が必要なら、確実にその方向が必要

ここまでが気をつけることと、前置きです!----------------------------

■2. 状態とデザインについて
●チェックボックス
ICSになってから、こういうブルーのデフォルトのチェックボックスがあります。
どういう状態が必要なのか確認していきます。

まず普通のチェックボックス。何もチェックされていない状態。
チェックをします。
押している時は、周りが青くなります。
チェックボックスの四角以外のところも色がかわります。
四角だけだと指で隠れて見えなくなるので、周りも色が変わります。
チェックがつきます。
再度指で押すと、微妙にチェックの色が変わって、
チェックがはずれます。

周りがボワっとなるのは参考になります。

フォーカスしている時、
タッチ端末を使っている時にはあまり見ることはありません。
キーボードをつないでいる時とか?
ディスエーブル。押せない状態の時、ちょっと薄くなっています。

チェックボックスカスタマイズで調べると、
ものすごいいろんな状態があります。

オフの時
オフ/押しているとき
オンの時
オン/押しているとき

simeji もいろいろ使っていて... 茶色いチェックマークが
入るようになっています。詳しくみると....
今周りがボワっとするようになっていて、
チェックボックスを押した時は、周りがボワッと黒くでるようになっています。
行の中を押した時は、周りがボワッとせずに、チェックが入ります。
チェックボックスではなく、行を押した時にボワッとなるのは変なので
止めています。

リソースの中の drawable (xml) 状態をカスタマイズするxmlを入れていきます。

selector という状態を変化させるタグを使います。
item
android:state_checked="true"
android:state_pressed="true"

チェックされているかどうか?
押されているかどうか?
フォーカスされているかどうか?
ディスエーブルの時もあります。

たくさん状態があって、資料を見るだけでも「うぇっ」ってなります。

前半終了。コネタに移ります!

-------------------------------------------------------------



@asamieee7
11月に Carry ていう iPhone アプリ出ます!
アプリのステッカーを持ってきました!
「渋谷アプリ」の Android をぜんぜん違うUIで出すんだ!
というタイムアウト東京さんのチームにまぜてもらいました。

本題

そのアプリの世界観を具体的に形にできるのは
お客さんじゃない あたしだ!

とにかくたくさん話を聞く
お客さんとたくさん話す
打ち合わせをめんどくさがらない

できればお客さんの熱い想いや、世界観をたくさん聞かないと、
それを聞かないとビジュアルに出来ないと思っています。

箇条書きでデザインはできません!
とにかくああでもない、こうでもないと。
クライアントの脳をできるだけ自分の脳に入れていく。
Photoshop やイラレを使うだけではありません。

だんだんお客さんから
ターゲット/目的
ビジュアルイメージが分かってきます。
思っていることを言えないということもあるので、
いっぱいいろいろ聞きます。

どうも、ターゲットとイメージが合っていない時もあります。
例;National Geographic のアプリを例に....
どうもやろうとしているアプリは全部あってないジャン!

いろいろとかみ合ってないかもしれない...
と、悩んでいる場合じゃないです!

それ、世界観違うかも! というのも大事なお仕事
勝手な解釈や見当違いはダメ。だまってろ!

違うといいっぱなしはダメ。
別な、こうしてみませんか?という提案を。
実装は大変だけども、世界観を合わせるのが大事です。

教えて、ちひろぴょん!

-------------------------------------------------------------


@adamrocker
Layout Performance 対決!

Android Training の中の Optimizing Layout Hierarchies の紹介
http://developer.android.com/training/improving-layouts/optimizing-layout.html

リニアレイアウトが使いやすい。
horizontal で横に並べて、vertical で区切って、スペーサーを入れて..
基本これでも奇麗にみれます。

Android のハイエラルキーツールで見ることができます。
赤とか黄色とかでていて、重そうなヤバイ感じがしますよね。

RelativeLayout でやってみます。
さっきと同じパーツですが、角を合わせていきます。
高さを合わせたり、横を合わせたり、親のレイアウトの右上にそろえるとか....
さっきと同じものができますが、シンプルな構造になります。

時間を計ってみました。
LinearLayout だと... Measuter 8.8ms , Draw 5ms
RelativeLayout は 2ms Draw 4ms

タイムライン描画だと、100個とか並びます。
だいたい、10%〜20% 速くなります。
プログラムは変えてなくても、レイアウト変えるだけで速くなります!

LinearLayout は使いやすいけどほどほどに
RelativeLayoutで代用できるときはコッチ
RLならレイアウトがスッキリしてみやすい
RL なら LLより 10%-20% ぐらい高速化できる。

-------------------------------------------------------------
2.状態とデザインについて
●スライダー

4.0以降のスライダーデフォルトのもの。
simeji もカスタム UIを使っています。
フリック判定幅のところで使っています。
ちょっとだけ変えました。
デザイナーは仕組みを知っているといいです。

ドーン
三つの部品が重なっています。
オンになっているエリア
オフになっているエリア
つまみ(通常時)
つまみ(押されたとき)
画像でもいいんですが、実はシェイブになっています。
中がグラデーションになっています。
stroke #59cf
startColor #50cf
endColor #0cf
透明度を変えただけですが、奇麗なパーツになてちます。
透明度を変えるのはけっこうアリなテクニックです。
corners で角丸をつけています。

つまみの真ん中の部分が操作している値になると思います。
カスタムUIで書いた時に、それができませんでした.....

つまみを作る時には注意が必要!
だんだん移動してくるのですが、
下のバーの、オフになっているエリアの色の部分が微妙な位置にきます。
半分に来ると、やっと中心になります。
なんか気持ち悪くないですか?
画像の端とバーの右端があうという変な仕様です。

つまみのデザイン
●透過をしたり、特別な形にするときは注意!
●バーの進み具合はつまみのセンターに従ってくれない!

回避方法.....
設定で、真ん中をずらす thumbOffset を使ってみる。
なんでここが切れるの!
なんでこうなるんだ!

つまみのデザイン
thumbOffset を使うと両端が切れてしまう。

ドロップシャドウを用意しておくと、画像のサイズが一回り小さくなってしまいます。
つまみの画像自体は、ピッタリぎりぎりで切れるようにしておきます。
そとに何かを表示するのではなく、押した時に黒くするとかで対処する。

■つまみのデザイン注意1
●できるだけギリギリでスライスする
●プレス時も外回りに影などをつけるのではなく、ぎりぎりまでつかい、色の変化などで対応

バーを shape で作る方法と、9-patch で作る方法があります。
繊細なデザインの時は、9-patch で作ります。細くなります。
スライダーはつまみがネックです!



■シークバー
くるくるまわるヤツ!
いろいろ見た事があると思います。
実はこれ、すごく簡単で、shape だけで出来ます。

shape
android:shape="ring"
android:innerRadius="7dp"
android:thickness="3dp"
android:useLevel="false"
gradient
android:endColor="#300"
android:startColor="#3300"
android:type="sweep"

shapeだけじゃなく、画像でも大丈夫です。
中を bitmap に書き換えることもできます。

かんたんシークバー
回転するものを作っておく

■スクロールバー
皆さん結構変えられますか?
simeji は勝手に変えています。

グレーの普通のスライダーです。
別にデフォルトでも問題無いですが、
微妙に色を変えます。スライダーも shape で作っています。
横向きのグラデーションで角丸をつけています。
意外と簡単なものであれば、コードで表現することが多いと思います。
デザイナーも分かっているといいです。

ちょっと余白が欲しいな... という時
スクロールバーが出ているのですが、上などに余白が欲しい時。
上と右に 2dp づつとっています。
スクロールバー、あんまり注目しなくてもいいかな〜と思います。

どうしてもやってみたかったのは、キャラを入れてみたかった!
ヒモみたいのがあらかじめあり、スライドするとキャラが登る!みたいな。
構造的に言えばそういうのも出来るかと思ったのですが....
9patch でのばすしか無いのかな〜
全体的にネコのキャラクタを入れてしまうと、細く伸びた猫になってしまうので、
やるならこれぐらいなのかな〜



■スクロールバーのカスタマイズについて
●基本的には 9-patch などで伸びる表現が必要
●どの程度余白をとるかを指示

ということで、今日はカスタムUI でした。

■まとめ
●やればいいというものではない
普通のデザインをする以上に神経を尖らせてデザインしなければいけない。
●ユーザーのアクションを妨げない
●とはいえ、デザイナーとして可能な範囲を考えたい
なにかしら世界観のあるデザインをしたい場合がいっぱいある。
やり方、仕組みをしっておくと、奇麗に実装してもらえる。

今日は時間ぴったりに終わりました!