よりぶろ

アプリのUIとかについて書いてく予定

モバイルアプリのデザインカンプにおけるレイヤー構造とリソースのネーミング

UI

がおおむね自分の中で固まってきたので晒してみる。

 

皆さん、デザインデータ作る時ってちゃんとレイヤーの階層とかネーミング、意識されてますか？

僕は入社時はそれはもうひどいもので、師匠に「吉竹さんのPSDデータ汚い…」と割と真顔で言われるほどでした。

このままでは嫌われてしまう！と焦った僕はそこから意識改革をし…というのは嘘。ぶっちゃけ半年〜1年近く放置してました。当時はデザイナーの数が少なくて自分の企画は自分が担当になること多かったから。。

ただ、もうここ1年近くはデザイナーの数も増えて、自分の出した企画を別の人が担当したり、その逆があったりは割と日常になってきました。そうなるとやっぱりレイヤーが整理されてないとお互いイラっとすることもあるんですよねー。

あとは他にも色んなタイミングが重なったりして、最近ようやく自分の中でも納得のできる整理ができてきたんじゃないかと思っています。

 

少しでも「自分のデータ汚いなー」と感じている方の参考になれば幸いです。

そしてあわよくばもっと良いやり方を知りたい…！

 

んで、だいたい今はこんな感じで作っています。使用ツールはPhotoshopです。

f:id:ryo_pan:20131005014656p:plain

言わずもがなですけど、業務のデータじゃないですよ。

たぶん分かる人はこれ見ただけで分かると思うので、以下は捕捉です。

 

・第一階層はシンプルに

たぶん人によってここ結構変わると思うんですけど、僕の場合は多くて4つくらいのフォルダに分かれます。

NavigationBar / Main / TabBar / BG

こんな感じですね。BGは1枚しかレイヤーが無くても癖でフォルダにしてます。

 

・並び順はZパターン

NavigationBarを見るとわかるのですが、レイヤーの並び順は、カンプ状の配置で言うと左にあるものが一番上にきます。

 

・画像リソースの命名規則

これも個人差あると思いますが、僕は画像リソースとして書き出すレイヤーは以下のような名前をつけています。

リソースの属性_配置場所_リソース名_状態

 

リソースの属性というのは、そのリソースがどういうものとして扱われるかの区分ですね。

btn…ボタン

pic…インタラクションがない、ただの画像。

ico…picに相当する中でも、アイコンとして扱われるもの。

bgi…背景画像。

この4つを使い分けています。

配置場所は、そのリソースが関連付けられている画面 or UIコンポーネントの名前です。

例えば、NavigationBarのような共用UIの場合は、nav とつけちゃいます。

その画面その画面でしか使われない場合は、該当の画面名称を付けます。図中で言うところの detail ですね。この画面は詳細画面なので、そのような名称としました。

リソース名は、そのままの意味で、名詞を当てはめます。お気に入りボタンだったら fav とか。英語辞書を開きつつ頑張って名前を考えます。

最後に状態ですが、これはタップ可能な画像リソースにつけます。

通常状態なら default、押下状態なら pressed という具合です。昔は pressed じゃなくて highlighted だったのですが、タイプするのが面倒になったので変えました。人によっては hit とか使われるそうです。

 

時にはこの命名規則から外れる場合もあります。例えば上図の中だと

btn_nav_fav_inactive_default@2x.png

ですね。これは、お気に入りに登録してない時とされてる時、それぞれのリソースが必要になるため、

非活性状態…inactive

活性状態…active

を挟んでいます。トグルスイッチとかになると on / off になります。

 

ちなみにですが、なんでここまで細かくリソース名を記載しているかと言うと、Slicy を使ってるからなんですね。

否が応でも整理しないといけないので、自然と「ちゃんとやらなくちゃ！」という気持ちになるのでオススメです。

この命名規則の並び順のメリットとして、大量の画像リソースの中から比較的見つけやすそう、があります。検証したわけではないので、あくまでも見つけやすそう、です。

何かを探す時に

ボタンで→あの画面の→アレなんだけど→見つけたー

という感じで探せます。1つ目と2つ目は反対でもいいかな。

個人的には、属性が最初に分かったほうがフィルタリングしやすいと感じているのですが、どうですかね。

 

あとはそんなに大したことはしてないので、最後にひとつ。

・企画時のデザインカンプにもこのルールを適用する

企画提案のデザインがそのまま受注後も使われることってそうそうないのですが、それでもやはり、自分以外のデザイナーの手に渡る可能性を考えると、この頃からしっかり整理しといたほうが、あとあとお互いの時間が取られなくて済むと思います。さすがに pressed のリソースをわざわざ作ったりはしませんが、、

習慣化してくると、時間も掛からずにサクッとできますよ。

 

余談として、よく「---------------------------------」という空レイヤーで要素を区切るのは割とメジャーな手法っぽいです。

僕は最初に書いた通り第一階層で分けてるのであんま必要性ないかなーと思って使ってないのですが、やったほうが便利なのかなぁ。

 

 

まあぶっちゃけ僕も100%このやり方ができてるわけではないので、あんまり偉そうなことは言えないんですけどね。。

もし「もっといいやり方あるよ！」とか「実装側としてはこうして欲しい！」とかありましたらご教授頂けますと幸いです。