こんにちは！
スマートフォンプラットフォームDivという部署でデザインを担当しているおばたです。
モック作りを進めていって、デザインの方向性がなんとなく見えてきたら
その後の開発は、デザインデータの管理・運用で作業効率がずいぶんと違ってきます。
今回は、スマートフォン向けAmebaのデザインデータの管理・運用方法について書いてみます。
データの管理は、忙しいとついつい後回しにしてしまいがちです。
しかし、放っておくと気づけばカオスになっていることもしばしば・・・
ちょこちょこ整理するようにすると、すてきな感じになります。
SVNなんて呼ばれているツールで、ファイルのバージョン管理ができるものです。
チーム内のデベロッパーも同じものを使っています。
こんなことができちゃいます
・バックアップ作成
共有フォルダに日付をつけてpsdを保存していかなくてもよくなります
先祖返りとかもうこわくない！
・ファイルの競合がわかります
他のデザイナーと作業が競合したら、それを知ることができます
・デベロッパーとの共有もスムーズ
htmlファイルと同じ管理方法にすればデベロッパーも喜びます（たぶん）
基本的に、ファイルを編集したらコミットする。
編集内容をメモする。というルールの元運用します。
グラフィックデータはバイナリデータなので変更点を比較できないため
何をしたかを書いておく必要があります。
メモを残しておかないと、他の人との共有やチェックの際に困ることになります。
こんなかんじ
こんなかんじ
コンポーネントファイル一つを最新にしておき、ここを参照します。
以前のプロジェクトでは、こういった管理方法ではなかったため、
・すでに存在しているパーツを新しく作っていた
・同一のアイコンで古いものと新しいものが混在していた
など全体で統一感を取るのにも苦労していました。。
このファイルを作っておけば、引き継ぎなんかも楽々です！
既にあるものはコンポーネントファイルからドラッグして使うようにします。
★シンボルについて
共通化するパーツはシンボル化しておきます。
オリジナルの情報を保持したままリサイズ可能
角丸が保持されたままサイズを変更できます！
※シンボルを解除した時に、角丸が崩れる場合があるので
ファイル名にメモしておくと便利です
複数配置したインスタンスは一括修正が可能
背景色を変更します
他のライブラリへも適用！
更新があった場合は、それをローカルへインストールするだけで全画面に適用されるので
らくらくですね！
デザイン上で使用するサイズを考慮した上で作り始めます。
例）30px
30の倍数で大・中・小 といった具合。
キー入力の範囲でしか、登録ができません。それ以上になると、元データからコピペで配置することになってしまいます。
メリット
・font 更新すればデザイン修正が反映される
・デバイスごとの各画像を書き出さなくてよい
デメリット
・css fontを使用できない古いデバイスで使用できない。
・細かいデザインを指定できない(グラデつけられないとか)
まだまだ細かいところは色々あるのですが、今回はこの辺まで。
デザイナーで、バージョン管理ツールをご存知でない方や、データ管理でお悩みの方に
少しでも興味をもっていただけたら嬉しいです！
最後までお読みいただき、ありがとうございました！
スマートフォンプラットフォームDivという部署でデザインを担当しているおばたです。
モック作りを進めていって、デザインの方向性がなんとなく見えてきたら
その後の開発は、デザインデータの管理・運用で作業効率がずいぶんと違ってきます。
今回は、スマートフォン向けAmebaのデザインデータの管理・運用方法について書いてみます。
はじめに
Fireworks CS5.1を使い、Subversion（SVN）で管理しています。データの管理は、忙しいとついつい後回しにしてしまいがちです。
しかし、放っておくと気づけばカオスになっていることもしばしば・・・
ちょこちょこ整理するようにすると、すてきな感じになります。
Subversionについて
Subversionって！？SVNなんて呼ばれているツールで、ファイルのバージョン管理ができるものです。
チーム内のデベロッパーも同じものを使っています。
こんなことができちゃいます
・バックアップ作成
共有フォルダに日付をつけてpsdを保存していかなくてもよくなります
先祖返りとかもうこわくない！
・ファイルの競合がわかります
他のデザイナーと作業が競合したら、それを知ることができます
・デベロッパーとの共有もスムーズ
htmlファイルと同じ管理方法にすればデベロッパーも喜びます（たぶん）
基本的に、ファイルを編集したらコミットする。
編集内容をメモする。というルールの元運用します。
グラフィックデータはバイナリデータなので変更点を比較できないため
何をしたかを書いておく必要があります。
メモを残しておかないと、他の人との共有やチェックの際に困ることになります。
こんなかんじ
historyからバックアップを取り出せます。
Fireworks＋コンポーネントについて
パーツを一つのpngファイルにまとめます。こんなかんじ
コンポーネントファイル一つを最新にしておき、ここを参照します。
以前のプロジェクトでは、こういった管理方法ではなかったため、
・すでに存在しているパーツを新しく作っていた
・同一のアイコンで古いものと新しいものが混在していた
など全体で統一感を取るのにも苦労していました。。
このファイルを作っておけば、引き継ぎなんかも楽々です！
既にあるものはコンポーネントファイルからドラッグして使うようにします。
★シンボルについて
共通化するパーツはシンボル化しておきます。
オリジナルの情報を保持したままリサイズ可能
角丸が保持されたままサイズを変更できます！
※シンボルを解除した時に、角丸が崩れる場合があるので
ファイル名にメモしておくと便利です
複数配置したインスタンスは一括修正が可能
背景色を変更します
他のライブラリへも適用！
シンボル使用時についての注意点
・拡大縮小するシンボルを作成するときは基準点を左寄せ(X0Y0)にしておきます。
そうしないとシンボル自体がブレやすくなります。
・外部ファイルのパスを変更するとリンク切れになるので、シンボル名は最初に決めておきます。
今回あとからディレクトリ名を変更してしまい、各画面のリンク切れのシンボルをコピペしてしまい、別シンボル扱いとなり後から修正するのが手間でした。。
リッチシンボルの扱い
テキスト編集可能なシンボルは、見出しなどに便利です。
メリット
デザインを統一しつつ各画面で必要な設定を作成できます
デメリット
テキスト編集可能なシンボルはテキストの一括置換で修正できません
★iconのfont化
今回、使用アイコンはfont化しました。
フォントファイルもSVNで管理します。
・拡大縮小するシンボルを作成するときは基準点を左寄せ(X0Y0)にしておきます。
そうしないとシンボル自体がブレやすくなります。
・外部ファイルのパスを変更するとリンク切れになるので、シンボル名は最初に決めておきます。
今回あとからディレクトリ名を変更してしまい、各画面のリンク切れのシンボルをコピペしてしまい、別シンボル扱いとなり後から修正するのが手間でした。。
リッチシンボルの扱い
テキスト編集可能なシンボルは、見出しなどに便利です。
メリット
デザインを統一しつつ各画面で必要な設定を作成できます
デメリット
テキスト編集可能なシンボルはテキストの一括置換で修正できません
★iconのfont化
今回、使用アイコンはfont化しました。
フォントファイルもSVNで管理します。
更新があった場合は、それをローカルへインストールするだけで全画面に適用されるので
らくらくですね！
デザイン上で使用するサイズを考慮した上で作り始めます。
例）30px
30の倍数で大・中・小 といった具合。
キー入力の範囲でしか、登録ができません。それ以上になると、元データからコピペで配置することになってしまいます。
メリット
・font 更新すればデザイン修正が反映される
・デバイスごとの各画像を書き出さなくてよい
デメリット
・css fontを使用できない古いデバイスで使用できない。
・細かいデザインを指定できない(グラデつけられないとか)
まだまだ細かいところは色々あるのですが、今回はこの辺まで。
デザイナーで、バージョン管理ツールをご存知でない方や、データ管理でお悩みの方に
少しでも興味をもっていただけたら嬉しいです！
最後までお読みいただき、ありがとうございました！