[&] Android App Designs (omnibus)
Android App Designs (omnibus)
デザイナーがコードから読み解く
Androidアプリのデザインの幅を広げるコツとTips
http://goo.gl/zZWMG
@tommmmy
4回やってきて、今回が5回目。最後の総集編です。
これまで4回やってきた、Android App Desings というイベントでした。
結構たくさんの人に来ていただけました。
参加者内訳は、開発者が6割強。残り4割弱がデザイナー。
デザイナーズハックとうデザイナー中心のコミュニティを細々とやっています。
7月に大阪から引っ越してきたばっかりで、まだなじめていません.....
サブタイトルが
「デザイナーがコードから読み解く、
Androidアプリのデザインの幅を広げるコツとTips」
がんばって作ったデザインが、実装後に残念な結果にならないために。
残念になる理由
B. エンジニアがでザインのことをわかっていない
A. デザイナーがAndroidデザインの基礎を理解していない
P.11
よくある話としては.....
P.12
余白が少ない。のが見て取れます。
元のデザインは綺麗につくっているのですが....
P14
白い線が入っているデザインなのに、入っていない。
影がなぜか無くなっている。
テキストにエンボスをかけているのに、無くなっている。
グレーの線の上にハイライトの線を入れているのに、無くなっている。
けっこう細かいところは、デザインしている人じゃないと、
なかなか気づかないと思うし、間違い探しと一緒。
こういうことって、結論からいうと、エンジニアが気をつけてさえくれれば、
残念なことにはならない
残念になる理由。
A. デザイナーがAndroidデザインの基礎を理解していない
むりやり押し付けてもダメだな〜と思って。
デザイナーにXMLコードを勉強して欲しい？
別にそういうことではない。
エンジニアにデザイナーを分かってほしいということでもなく....
コードからつかんだデザインのコツ。
デザイナーが知っておくと、エンジニアもデザイン実装がしやすくなる！
なかなか人が居ないとか、情報が少ないとか。
デザイナーにXMLを勉強してほしいとか、もありますが。
自分が実装しやすいように、デザイナーに仕込む。
自分が実装しやすいデザインレギュレーションを決めておいて共有すれば良い
どうやって簡単に？
たぶんデザイナーに [ dp ] とかいっても受け入れてくれないと思う
デザイナーさんの身近な言語に翻訳して伝えてみる。ピクセルとか。
裏テーマ
「デザイナーさんにわかりやすく興味をもってもらうために」
興味を持っていただくのを今日の裏テーマとして。
アジェンダ：
デザイナーさんにわかりやすく興味を持ってもらうための５つのポイント
効率的な進め方
Android App Designes アンケート結果の紹介
P.25
デザイナーさんにわかりやすく興味をもってもらうための５つのポイント
自然に責める
壁を突破するためのきっかけになるとうれしい
1. -----------------------------------------------------------------------------
640 px x 1066 px
720 px x 1280 px
作成するデザイン案のサイズ。
ガイドラインは dp なので、そこでわからなくなってしまう。
なので、あらかじめピクセルに直して考える。
xhdpi で作る
320 dpi といういちばん大きな画面密度で作る
1dp = 2px なので計算がかんたん。
320dp と 360 dp の 2種類あるのだが...
なぜ２つかというと、確認する端末によって、分ける
... といいんじゃないかと思う。
Android Design Preview デザイナーにとってうれしいツール。
パソコン画面をそのまま Android 端末に映すことができるツール。
http://code.google.com/p/android-ui-utils/downloads/list
320dp と 360dp これを 640px デザインしたものを表示させると、
Galaxy Nexus で見た時に、ちょっと大きめになってしまう。
逆に 720px でデザインしたものを表示させると、
320dp で見た時にちょっと小さく感じてしまう。
ぴったりに見せたい時は、デザイナーさんが持っている端末にそって
サイズを決めておけば良いと思います。
これでもしやってみて、いいこと悪いことあれば、教えてください！
2.-----------------------------------------------------------------------------
96 px と 4の倍数
各要素を決める数値です。
96px にすると、要素がぴったりあいます。
4の倍数は、ガイドラインで指定されています。主に余白です。
ピクセルに直すと、8の倍数です。
デザインしていくなかで8の倍数はけっこう大きいです。
細かいところは 4の倍数でいいんじゃないな〜と考えています。
いろいろ考えてみると、
P.43
xhdpi で 4の倍数をとると、hdpi でも整数になっています。
私の持論です。実装も綺麗になるので大丈夫です。
3.-----------------------------------------------------------------------------
伸縮幅・固定幅
横幅は原則2種類。
どこが伸縮／固定なのかをはっきりさせる
640px で作っていたら、720px のときにはどこが伸びるのか
余白はどちらの時にも固定値にする。
P.48
どっちかを作って、どこが伸びるのかを明示しておくと、
エンジニアさんに伝わりやすい。
P.50-52
これは何を意味しているかというと、
どこが伸びるか？どこが何ピクセルかを示したものです。
これはこれでデザイナーはちゃんと計算してデザインしています。
オレンジのところが、伸びるところ、または縮まるところです。
P.53
ボタンについては、1:2 の割合になっているので、
伸びたりしても、バランスが保たれます。
4.-----------------------------------------------------------------------------
9-patch
これは第１回、4-50分かけて、説明しました。
画像をのばすテクニックです。
画面サイズはデバイスによって違うので、
必ず伸縮を考えないといけません。
P.57
まず、画像を9分割して、四隅はのばさない。その他の部分を
伸びてもいいようにして、びよーんと伸びる設定にします。
世界で一番わかりやすい 9-patch の説明です！
P58〜
周りに1ピクセルつづ、余白をとります。
黒い点を打ちます。(P60) 切り取ると、（P62)
みよーんと伸びます（P63,64)
P72
このデザインに関しては、同じ。
グラデーションを扱った場合、9patch は注意が必要。
P73〜P93
結果が微妙に違う！
色味が近い場合、荒いグラデーションになってしまう場合があります。
角丸が終わるギリギリの場所で2箇所指定した場合.
もっこり感が微妙に違います！
光の具合を計算しているので、変なところが伸びていると「残念だ」と
思ってしまう。デザイナーもどこが伸びるのか指定してあげてください。
エンジニアも、伸びすぎて気になる場合は、デザイナーに確認してあげてください。
両者の心遣いが大切です。
ボタンで使う場合が多いと思います。
どこが伸びるかを指定しよう。
個人的には、グラデーションがある場合は、9patchはあまり使いたくありません。
してもらってうれしいこと。
デバイスで見るとどう伸びるのかを、一緒に体験する。
Draw9patch というツールが、デザイナーのPCで動くようにする。
慣れてきたら、Photoshop でも作るよ！
設定してあげたら、けっこういい 9patch が出来てくると思います！
Draw9patch のツールのコマンドを、ドックに入れてあげるといいです。
（Unix コマンドなので、開いたら、爆発してしまうんじゃないかと思う！）
Mac に Automater でパスを指定して開けるので。やりやすくなります。
やりはじめるとハマると思います。
5.-----------------------------------------------------------------------------
矩形 shape タグ。
CSS3 でグラデーションとか、角丸とかできるようになったのと
同じようなことができるので Web デザインをする人なら取っ付きやすいです。
コードで書ける矩形のことを知っておこう。
特にコードの書き方は知らなくてもいいと思います。
コードで書けることを知っていれば、それなりに綺麗なものが仕上がってきます。
P103
Rは角丸の半径。ボーダーも指定できます。
スタートカラーと、エンドカラー、センターカラーも指定できます。
デザイナー的には、センターカラーが変えられるのはあまりうれしくありません。
こういう光り方をしているボタンはあまり作りません。
P105
Photoshop でグラデーションを作っているところ、上70%くらいに
変化のポイントを打つことは良くありますが、真ん中にすることはあまりありません。
あ、残念だ... と思ってしまう。
グラデーションの場合、コードで可能なものか、9-patch になるのかを考えておこう。
まとめ-----------------------------------------------------------------------------
1. 640x1066, 720x1280 (px)
2. 96px, 4の倍数
3. 伸縮幅／固定幅
4. 9-patch
5. 矩形 shape
これまでまとめてきた上で、デザイナーに押さえてもらえると
ずいぶん楽になる５点です。
ぜひ広めてください！
詳しい資料を、別にまとめようと思います。
-----------------------------------------------------------------------------
後半
http://www.slideshare.net/toooommmmmmmmy/4androidtips-15080493/110
ちょっと実装とは関係ないんですが、
XMLの実装をめぐる、効率の良い進め方を再考してみたいと思います。
いままでやってきた中で紹介していきたいと思います。
アプリケーション作る時に、だいだいワイヤーフレームみたいなのを
作ると思います。エンジニアはフローチャートとかで仕様を決めておいて、
そこからデザインに入ったりすると思います。
P111
カンペを出すアプリです。
セミナーとかやっている時に、後ろからメッセージを送るアプリです。
ワイヤーベースのモックをまず作ります。
で、ここからデザイン、実装に入る時に.....
＃ここで寸劇....
エンジニアの人が「一週間でお願いね！」
デザイナー「オッケー」
初めてデザインする人とかは、実装できないデザインを出してくることがある....
こういう場合、
ワイヤーを決める
デザインをデザイナーにまかせる
なかなかできあがってこない
デザインが無いと実装できない....
P126
エンジニアが、デザインの待ち時間がもったいない。
モックを作ったりとはするとは思うのですが.....
なので、
同時進行！
ワイヤーさえ決めればあとは同時進行
いっかい、これをやって、気分が晴れ晴れしました！
＃再び寸劇
P128-
P131
エンジニア：いわゆる葬式UIが出来上がってきました。
いい意味で、デフォルトだけのもの。
P132
デザイナー
ワイヤーがきまっているので、そうそうずれていない。
ボタンの位置とか設定されているので、
画像を張り込むだけで良かったりするので。
すごい工数も少なく終わりました。
P.134
配置とか画像とか変えてもいいので。
ちなみに、これ、自分でデザインを作って、
ここから、XMLを実装したものなので、ちょっとしょぼいのですが、
結構気に入っています。
アナログ感をどうしても出したかった。
逆にひんそに見えるかもしれませんが。
デザイン実装した分、これも 9patch でやっていて。
アナログなアプリにしてみました。
アプリは公開していないので、ここだけで見られるものです。
同時進行のメリット；P136
デザインと実装を同時並行。
設計、ワイヤーの時間をとれる。
ちゃんと設計をしておけば、だいたい同じようなものが出来上がってくる。
XMLのスタイリングを最後にする。
ワイヤーさえかわらなければ、最高の効率！
すごく楽しくできました。
デザイン例：P138
shape を知った上でのデザイン
shape タグで出来ることを知っていれば、それに見合ったデザインができます。
それの例を紹介します。
「カンペ君」アプリをぱっと見ていただいて、綺麗でシュッとしているように見えます。
ほとんど shape タグで実装しています。
ボタンみたいのも、全部 shape です。
先ほどのグラデーションあったかと思うのですが、全機能使ってます。
P.143
遠隔の端末でも同じメッセージが表示されるというアプリの機能です。
押せるところと、押せないところがあります。
押せるところは、赤い○で囲んであるところ（P144）
押せるところは盛り上がって押せるように見えるように作ってあります。
押せないところは、すでにへこんでいるように見えるように作ってあります。
例えば、P146 エンジニアがどう実装するかは分かりません。
私が XML の shape を分かっていで、デザインしたら、こういう形にしました（P147)
P148 綺麗に見えると思いますが、shape で作っています。
グレーのグラデーションに角丸です。
P150 send ボタンも同じです。
画像にshadowを入れています。
9patch で画像を作るよりも楽です。
いちいち photoshop で作り直さなくても良いので、その方が楽です。
shape で作れる範囲で思いっきりやろうかと。
画像使えば綺麗になるというわけでも無いので。
もう一個。こだわっているところがあって。
一番上、P151
背景に若干ノイズ、テクスチャが載っています。
ちょっと柔らかさを出したりするために、ノイズが載せたいんです。
実装どうやるかといった時に、
ボタンなら、画像を切り出しせばいいのですが....
どうやったら実装できるんだろうと、考えました。
P152 実際に実装した画面です。
結構いい感じに、少し薄いですが、まあまあいい感じにノイズが載っています。
ただ、実装した結果どうなっているかというと、
じゃっかん、角丸からはみ出ているのがわかります（P153)
これ、何をしているかというと....
P154 この場合、上からノイズの画像の透明度を10%-15% にしたものを
グラデーションの上に載せると、ノイズがかかった綺麗な画像になります。
shape とビットマップをレイヤースタイルを使って重ねています。
ノイズをなんとか表現してみたい。P155
今日までに解が見つからなかったので、教えて欲しい！
角丸でくりぬく方法があれば、教えてください！
●綺麗にデザインするためには
デザイナーが数少ない表現方法でもしっていれば、
それなりに組み合わせて綺麗なデザインを作れる。
こういうの出来るよというのをエンジニアが示してあげれば、
デザイナーは綺麗なデザインをしてくるので、それを信じて実装してあげてほしい。
残念になるのは、両方が勉強不足、コミュニケーション不足。
コードを知らなくてもちゃんとする方法を教えてあげるといいと思います。
これから資料としてまとめていければいいな〜と思っています。
Q&A
Q: shape の話で、ボタンが盛り上がっているのと、へんこんでいるのの違いが
わからなかったのですが....
A. 押せるところは、上の方が薄い色になっています。
押せないところは、上のグラデーションの色の方が下よりも濃くなっています。
光の当たり具合ですが、上から光があたっている時、膨らんでいると、上の方が明るくなります。
へこんでいると、影になって、色が濃くなります。なので、こういう風にみえるように。
Q: デザイナーとデベロッパーの連携で聞きたい。
デザイナーが５枚くらいカンペを作って、テキストサイズをまとめてシートを作って、
18pix です。とか、カラーチャートを作って、ボタンのパーツの色を伝えたりしていました。
実際にやる時に、どう伝えているのか？教えてほしい。4px とか。
A: 実際は XML を書いてわたしています。仕事としては「脳内」です。
デザイナーからエンジニアに色の指定とか、テキストの指定をしているのか？
山本さん「どうやってデザインのパーツを全部切り出して、パワーポイントで、
全部の画面にぺたぺた貼付けて、パーツは何、カラーコードは何とか、
そんな感じで全てのパーツに、全部つけてお送りしています」
すごい丁寧だと思います。私だったら、自分でやっちゃうと思います。
やり方は色々あると思います。
変数化するよりもまとまっている方がいいですね。
Q: shape ボタンを作られるさい、
プレビューをうまくやる方法。
A:
Q; 色の指定というのは RGB というのは255 255 255と 16進数とどちらで指定するのが良いのでしょう？
A: 16進数の方が喜ぶと思います。
Q; Nexus 10 とかタブレットとか？xhdpi の範疇に収まるものなのか？
A: 足立さん：xhdpi の高解像度になります。xxhdpi が出てくるので戦々恐々としています。
--------------------------------------------------------------
Android App Designs アンケート
日々の見えない声
P161
デザイナーとして同感で、
こういうことがいっぱいあるので、自分でやるようにしました。
なんで相談しないのか、疑問でした。
もっとコミュニケーションとって欲しい。
足立さん：そんな時間が無いんですよね。1ピクセルくらいっか〜
ここは絶対譲れない部分と、実装が難しい部分を分かってもらうと。
ぜったい崩して欲しくない部分を明示しておくと、大丈夫かもしれない？
足立さん：素材を綺麗に切り出してもらえば大丈夫です。
みんな１ピクセルの問題はあるんですかね？
dp で 0.66 dp とかありですか？
足立さん：無し。書けるけど、そういうこまかいことよりも重要なことがある。
書けるけど................
1px のライン、72dpi のパソコンの解像度の 1px と android の 1dp ってちょっと
太くなってしまう。
0.66dp にしていたりします。1dp だとボーダーとかちょっとしゅっとしなくなるので.....
P166
エンジニアの「できない」は信じないほうが良いです。
でも「できる」って言うと仕事が増えるんです。
足立：アプリのクオリティをあげるのは重要で、期限があるときは、
どこを削るのかが重要。一番最初のローンチ時の立ち上がりが重要。
問題があるなら、全部に時間をかけるのは難しいので、
使い勝手や、使い心地など、大事なところが２、３個ピックアップして、
集中してやった方がいい。
勝負できるのはスピードも重要。最初のクオリティが非常に重要。
そこでコケてしまうと、後で取り返すがの大変。
大量に広告しなければ、いけなかったり。
と、個人的には思っています。
納期はまもらなければいけない。
予算が決まっているので。
足立；細かいところ修正するよりも、
たくさんの端末でちゃんと表示できるようにするほうが重要なのか、
プロダクトデザイナーがジャッジするべき。
P169
P170
足立：デザインを全部みた上に面倒を見るのは大変。
Webデザインよりも大変。人から言われて、まだプログラム書いてないのにXMLのこと言われても。
微調整くらいはデザイナーができると楽になる。
XML の押し付け合い...........
新しい機能がでたら、git にあげて、お知らせする
足立： デザイナーのための git というセミナーを...むちゃくちゃ助かってます。
ゆくゆく考えれば、id 設定もお願いできれば....
Webデザインがいいのは、ツールがいっぱいあって、デザイナーがいろいろできるのが良いところ。
ここはそういうツールが出てくるのを待つか、XMLをデザイナーが勉強するのか、
XMLコーダーみたいな人がでてくるのか、過渡期にあると思います。
ベースを作ってもらって、数値設定に口出しできるようになるだけでも
変わってきます。
公開したスライドには、全部の「声」が書かれています。良かったら見てください。
<< Home