1 pixel｜サイバーエージェント公式クリエイターズブログ -22ページ目

ガールフレンド(仮)におけるわくわくさせる運用デザイン

はじめまして。「ガールフレンド(仮)」のUIデザインを担当している西戸(@satomi0403)です。
「ガールフレンド(仮)」とは、ユーザーが主人公となり、様々な女の子と出会っていく学園恋愛カードゲームです。ちなみに「(仮)」も含めて正式タイトルです(笑)。
今回はその「ガールフレンド(仮)」における、運用デザインについてお話をさせていただきたいと思います。

ちなみに運用とは

ガールフレンドは2012年11月にリリースされました。

晴れてリリースされたサービスですが、ユーザーをいかに楽しませられるか、いかに飽きずに続けてもらえるか、常に改善と新しさが求められます。それに対して、ゲームをよりよくしていく為に行う事を運用と呼びます。

運用デザインの主なものは下記の点です。

・既存ゲームの改善と機能追加
・新カード(ガチャ)の追加
・イベントの開発と運用

今回はその中から「新カード(ガチャ)の追加」を、デザインの視点からいかにユーザーをわくわくさせるような魅せ方ができるかを私なりにご説明させていただきます。

カード追加やイベントをもりあげるロゴ

ガールフレンドでは登場人物の女の子が色々なテーマに沿って登場します。
クリスマス、お正月、節分、チアリーダー、ネココス、バレンタイン等等。
そのテーマに沿った世界観をロゴ等で表現します。

毎回違ったテーマとキャッチフレーズに、きちんとロゴを付けてあげる事で、新鮮さと、特別感、そして楽しさをユーザーに感じてもらえるようにします。

ただし、ガールフレンドの世界観から逸脱しないように制作するのがポイントです。

ロゴだけ見てもカードの世界観が伝わってわくわくできるような工夫をしています。

一瞬で伝えるバナーの制作

ゲームの情報を伝える上で欠かせないゲーム内バナー

バナーは「情報の看板」の役割を果たしています。そのため、バナーの制作で大事なことは、小さい枠の中でユーザーが一瞬さっと見ただけですぐそれが何なのか頭に入るよう、伝えたい事の優先順位づけをしっかりと大げさにすることです。「伝えたい事」は２通りに分けられると考えています。

①イベントの世界観を優先して伝える
②ユーザーにとってオトク情報を優先して出す

※この二つをどう出し分けるかというと、
上記で作ったようなロゴがある時、(ガチャ追加時、イベント)は①の世界観を前面に押し出すようにしています。特別感を感じてもらう為、オトク情報が一緒にあったとしても、世界観を優先します。

逆に、そういったものがなければオトク情報をとにかくめいっぱい出してあげます。
またこの２パターンを分ける事で、多く並ぶバナーの差別化をはかります。

パターン1　イベントの世界観を伝える
例）にゃんこのお願いキューピッド

①世界観→にゃんこのお願いキューピッド
②オトク情報→追加SR4倍
③オマケ情報→期間限定

パターン2　ユーザーにとってオトク情報を優先して出す場合
例）2012年大感謝キューピッド

①オトク情報→元気炭酸12個
②世界観→2012年大感謝キューピッド
③オマケ情報→10連限定

一番大事な「元気炭酸12個」を目立たせるため、他の情報は小さな文字だったり、イラストのみで表示しています。
強弱をつけずにたくさん情報を載せすぎると、大事な事が一瞬で頭に入ってこないのでNGです。

表現の方法は様々です。

例えばこのように、わくからはみ出したように見せたり、
gifアニで「レア鬼出現」のところを点滅させました。その理由として、要素が多くてごちゃごちゃして静止にすると情報の優先度がわかりづらいということと、また、世界観を大事にした上で大事な情報として目立たせるためです。

全部伝えるわかりやすいランディングページ

バナーという看板から入って来たら、メニューを見せてあげる場所がこちらランディングページ、通称「LP」です。
ここですべての情報を提供しますが、情報を羅列するだけではありません。デザインの見せ方のポイントが３つあります。

①上に大事な情報を持ってくる
②要点で区切る
③文字は少なく、目立たせたい情報は大きく表示

例）にゃんこのお願いキューピッド

①ヘッダー
世界観を全面に出し、ページのタイトルを表します。女の子達はみんな、バラバラの状態で描かれているので、距離感や角度等気をつけて、同じ空間にいるようにみせたり、配置を施します。

②ボタン
ファーストビューに一番大事なボタンを配置します。これはとても重要なことで、ユーザーを迷わせないようにするためと、煩わしさをなくすためです。

③報酬
メインでもらえるものを一番大きく配置します

④一覧
もらえるものを一覧で見せます。

⑤もらえるおまけ
オマケのオトク情報を記載します。文字をたくさん書くより、絵やメインとなる文字を端的において、わかりやすくする工夫をしています。

この他にも、キューピッドのページ自体にも、上部にLPを凝縮したヘッダーをおいたり、アイコンをイベント用に変更して、変化を感じてもらう工夫をしています。

最後にまとめ

長くなりましたが、以上がガールフレンド(仮)における運用デザインの一部です。
この他にもイベントの開催や、常にユーザーがより楽しく使いやすいゲームになるべく、日々UIの改善や、機能追加を行っております。

最後までお読みいただき、ありがとうございました。

ガールフレンド(仮)はこちらから⇒http://vcard.ameba.jp/

ゲーム企画の作り方（基礎編）

こんにちわ、
モテキロワイヤルのプロジェクト責任者をしています
堀江（@yu_horie）と申します。

絶賛リリース中のソーシャルゲーム
「モテキロワイヤル」（遊んでみてね！）ですが、
制作が決まった経緯が他の内製ゲームと少し違います。

モックプランコンテスト

モックプランコンテストは2012年の3～4月にかけて行われた、
社内のエンジニア・クリエイター向けのコンペです。
特徴としてはスマートフォン向けの新事業やサービスのアイデアを言葉ではなく、
モックで（実際に作って）提出するという点です。

当時、アメーバピグのデベロッパーとして従事していた私は、
JavaScriptでの開発経験は皆無でしたが、良い機会だと思い、
技術書を片手に、現在の「モテキロワイヤル」のコア部分を形成している、
モテるパズルゲームを制作し提出しました。

独特な世界観と、今までのブラウザゲームでは見たことがなかった
「よく動く」パズルゲームは評価され、
結果、応募総数123案の中から優勝することができました。

携帯が鳴り止まないくらい祝福されたのは良い思い出です。

はじめてのゲームづくり

その後、受賞作品の事業化が決まり、
「プロジェクトマネージャー」という立ち位置でプロジェクトがスタートして、
「モック」をベースに具体的な企画に落としこむフェーズに入りました。
開発当初はゲームの基礎的な企画脳ができていなかったため、苦労しました。
ゲームの基本的な考え方を教わってからはかなりスムーズに企画を考えられるようになった気がします。

「GETする」→　「育てる」→　「使う」→「GETする」etc
の方程式はあらゆるソーシャルゲームに適用できます。

２つの内製ゲームを比較してみました。

「天空のクリスタリア」はいわゆる「カードバトルゲーム」と言われるゲームシステムで、
ピグライフはいわゆる「箱庭系ゲーム」と言われるゲームシステムです。
（と、僕は認識してますが企画者の方的に全然違ったらごめんなさい！）

一見、違う２つのゲームシステムですが、
先ほどの方程式に当てはめると基本的なサイクルは同じ（シンプルであることが重要！）であることがわかります。
では、なぜ違うゲームに感じるのでしょうか？

それは2つのゲームが重要視しているポイントが全然違うからです。
天空のクリスタリアなどに代表されるカードバトルは「使う」ことが楽しくなるよう
設計されているのに対して、箱庭系ゲームは「育てる」ことに重きが置かれています。
（と、思ってますが。企画者の意図と違ったらごめんなさい。）

ので、ゲームを企画する際にはまずは「何が楽しいゲームなのか」を
最初に絞り込むとこの企画の「注力ポイント」が必然的にできて
「どの機能が必要か」が、見えてくるので企画を進めるのが楽になります。

「どこにソーシャル性をもたせるか？」も度々議論にあがりがちですが、
この「注力ポイント」にソーシャル性を組み込むのがセオリーだったりします。
クリスタリアで言うと「ユーザー間のカードバトル」
ピグライフで言うと「お手伝い」だったりです。

このような企画の紆余曲折があって、企画が仕上がり、
高い技術を持つデベロッパーの手によって
パズルは更にブラッシュアップされ、リリースに至りました。
それまで「自分のサービス」を持ちたい。
と考えていた私の夢が叶った瞬間でした。

「こんなのを作ってみたい」と密かに思っている
開発者は沢山いると思います。
サイバーエージェントはそんな夢を持っている開発者にとってはいい環境だと思います。
僕自身、社内で出した成果を今度は対世間で出さなければいけないので、
今奮闘している最中です。

モテキロワイヤルをよろしくお願いします。
http://mt.amebaspgame.com/

StyleDoccoによるCSSスタイルガイドの導入

はじめまして、アメーバ事業本部 teens事業部の谷です。業務ではフロントエンドデベロッパーとして、主にHTML/CSSの設計・実装をおこなっています。

今回は、以前斉藤が書いた「モバイル時代におけるCSSの設計と実装」という記事で触れられていたコンポーネントリストもといスタイルガイドについてのお話です。
スタイルガイドの事例と、スタイルガイドを生成するツール StyleDocco の紹介をします。

スタイルガイドとは

先の記事より引用すると、ページ上の部品（コンポーネント、モジュール）を集めたリスト、ページのことです。どれがコンポーネントで、どれがモジュールと呼ぶか、というのは人によって若干定義は異なるかとおもいますが、ここではひとまずページ上の部品ということで進めます。

スタイルガイドもしくはデザインパターンと呼ばれるページはいくつかのサイトで公開されています。下記はその例です。

このように部品を並べ、それぞれの仕様や使い方、あわせてコードスニペットをまとめておくことで、実装者自身はもちろん他の開発者やデザイナーに共有できる便利なドキュメントになります。

スタイルガイド運用の問題

スタイルガイドを作ること自体は決して難しいわけではなく、ひとつのページ内にサイト/アプリ内で使われるスタイルをまとめていくだけです。難しいのは、その後に修正・改善を重ねてデザインやスタイルや変わったときに、そのスタイルガイドの方も更新していくことです。
更新されないドキュメントは、ドキュメントそのものが無いのと同様、またはそれ以上に混乱を招き、逆効果となってしまうかもしれません。運用ルールを徹底して、デザインやスタイルが編集されればスタイルガイド側のHTMLとCSSも更新するというのは限界があります。

このスタイルガイドを作る作業を簡略化するためのツールとして今回紹介したいのがStyleDoccoです。

スタイルガイドジェネレータ StyleDocco

StyleDocco

StyleDoccoはNode.jsで実装されているスタイルガイドジェネータです。

StyleDoccoはCSS内に書かれたコメントをパースし、その内容をスタイルガイドページとしてHTMLにしてくれます。
つまり、CSSファイルを更新・修正する度にスタイルガイド側のHTML/CSSを手作業で修正するという必要はありません。
CSSファイルを更新した後にコマンドを実行するだけでスタイルガイドも更新されます。

実際にどのようなページを作ってくれるのかは、StyleDoccoのサイトにあるexampleをみてみましょう。

スタイルの説明、そのサンプルデザインのプレビュー、HTMLスニペット、CSSスニペットがグループ化され整理されています。
こうしたスタイルガイドをコマンドラインで簡単に生成することができます。
以下StyleDoccoの導入手順と使い方を説明します。

StyleDoccoのインストール

StyleDoccoはnpmからインストールします。


npm install -fg styledocco

※必要に応じてsudoで実行してください。


sudo npm install -fg styledocco

Node.jsおよびnpmをインストールしていない人は、Node.jsのサイトからダウンロードできるインストーラーを実行すれば簡単にインストールできます。その後、CygwinやTerminalといったコマンドラインツールで上記を実行します。

ドキュメントのコメントをCSSに書く

スタイルガイド上に反映される説明文は、CSSファイル内のコメント部分に記述します。次はその例です。


/*
# ボタン

サイト共通のボタンスタイル。

## デフォルトのボタン

`.btn`クラスを付与する。

```<div class="section">
  <a href="#" class="btn">Default</a>
</div>
```

## 主要なボタン

`.btn`クラスと併せて、`.btn-primary`を付与する。

```<div class="section">
  <a href="#" class="btn btn-primary">Primary</a>
</div>
```
*/

説明文はCSSのコメント記法 /* */ で囲みます。そして本文は通常のコメントのように文章をかけば良いのですが、例のような# や`（バックティック）などを使うことで、それらをHTMLの要素化してくれます。# の場合にはh1、## はh2というような形式です。
このような記述形式をMarkdownと呼びますが、もし使ったことがない場合には、こちらなどで構文を確認してください。

Markdown

スタイルガイドの構成上、最低限 # と `（バックティック）は覚えておきましょう。サンプルデザインのプレビュー部分を構成するHTMLは、`（バックティック）3つで囲むことで反映されます。

また # ひとつの場合は h1要素に置き換えられるのですが、スタイルガイド上ではこのh1の単位でセクションエリアが分割されます。

このあたりは実際に試されてから試行錯誤してみてください。

プロジェクトディレクトリで実行する

コメントが書けたら、コマンドラインツール上で対象のプロジェクトのディレクトリへ移動します。（以下のプロジェクトディレクトリへのパスは例です）


cd ~/Dropbox/Project/1pixel/

この移動先の1pixelディレクトリに下記のような構成でファイルが用意されているとします。


1pixel/
 + css/
   + style.css
   + common/
     + normalize.css
     + button.css
 + blog/
 + index.html

ここで確認してもらいたいのはCSSディレクトリとそれ以下のCSSファイルです。中にはcommonという名前でプロジェクト共通のCSSがあり、またそれらを@importで統合するstyle.cssがある、というような例です。各HTMLページではstyle.cssを読み込む想定です。

style.css:


@import “common/normalize.css”;
@import “common/button.css”;

body {
 …
}

では、コマンドラインツール上でこの1pixelディレクトリにいる状態から、下記のようなコマンドを実行します。


styledocco -n "My Project" css

そうすると下記のようにdocsディレクトリが生成されます。


1pixel/
 + css/
   + style.css
   + common/
     + button.css
     + normalize.css
 + docs/
      + common-button.html // common/button.cssのガイド
      + common-normalize.html // common/button.cssのガイド
      + index.html // スタイルガイドのトップページ
      + style.html // style.cssのガイド
 + index.html

生成した後は docs/index.html にアクセスすればスタイルガイドが確認できるかと思います。
この例のように、@importを使って分割している場合にはそれぞれのドキュメントページを生成し、スタイルガイドにも階層ナビゲーションが用意されます。

CSSプリプロセッサへの対応

StyleDoccoはSassやLESSといったCSSプリプロセッサにも対応しています。

CSSプリプロセッサは、.scss,.lessといった各プリプロセッサの対応拡張子のファイルをCSSにコンパイル（変換）するプロセスが必要です。

StyleDoccoでスタイルガイドを作るためにも、そうしたプリプロセスが必要かというとそうではありません。StyleDoccoはコンパイル前のプリプロセッサファイルをパースし、内部的にCSSへとコンパイルしてデザインプレビューに反映してくれます。

例えば下記のような場合でもその構成の通りのスタイルガイドを生成してくれます。


1pixel/
 + css/
   + style.scss
   + base/
     + _codes.scss
     + _forms.scss
     + _images.scss
   + generic/
     + _clearfix.scss
     + _helper.scss
     + _mixins.scss
     + _normalize.scss
   + objects/
     + _buttons.scss
     + _columns.scss
     + _grids.scss
 + index.html

CSSプリプロセッサによる運用の場合、上記のようにファイルを分割し、それぞれを必要に応じて読み込んで使う、というようなケースもありますが、その場合でもそれぞれでスタイルガイドを生成してくれます。

コマンドとオプション

コマンドは、プロジェクト名の定義、任意でオプションを指定、最後に対象となるCSSファイルがあるディレクトリを指定して実行します。


styledocco -n [プロジェクト名] [任意のオプション] [CSSのディレクトリ]

-nの部分は、–nameでも構いません。プロジェクト名をここで定義するのは必須となります。またここで定義された名前はスタイルガイドの左上のエリアに反映されます。日本語でも大丈夫です。また名前はダブルコーテーションで囲みましょう。

その他のオプションには下記が用意されています。


--out, -o
-o styleguide

スタイルガイドを生成するディレクトリを指定できます。未指定の場合は、デフォルトの docs となります。これはコマンドを実行したディレクトリから見て相対的な場所に生成されます。


--preprocessor
--preprocessor "scss --load-path=deps/"

CSSプリプロセッサを利用しており、そのプリプロセッサの任意のコマンドを実行したい場合に使うオプションです。

すでに説明した通り、CSSプリプロセッサを対象とした場合には、StyleDoccoでスタイルガイドに反映させるためのコンパイルをしてくれるのですが、その場合に任意のコマンドを別途実行させたい場合に使うようです。個人的にはこれを使ったことはありません。


--include
--include preview.css --include preview.js

スタイルガイド上のサンプルのプレビュー部分に対して任意のCSSやJSを読みこませることができます。プレビュー部分にはスタイルガイドにするCSSがそのまま適用されますが、任意でプレビュー用のCSSを適用させることができます。
例えば、プレビュー上の背景を変えたいとか、レイアウトを制御したいような場合には使えるかもしれません。またJSファイルを読みこませることもできます。これはプレビュー上、何かしらのインタラクションの表現が必要である場合などに使えます。たとえばクリックしたときに任意のクラスを適用し、要素を変化させたい、といったこともできます。なお–includeを複数記述する形で、複数のファイルを読みこませることもできます。

これはあくまでもプレビューエリア内のカスタマイズとなるので、スタイルガイド本体のスタイルに影響するものではありません。


--verbose

コマンドを実行した時にログが表示されるようになります。デフォルトではオフ（false）になっているので何も表示されませんが、このオプションを指定すると、各CSSファイルがどのHTMLに反映されたかを確認することができます。
基本的にこれも使うことはないとおもいますが、うまく実行されているかわからない場合には指定してみるといいかもしれません。

以上のオプションをフルで使う場合には次のようなコマンドになります。


styledocco -n "My Project" -o styleguide --preprocessor "scss --load-path=deps/" --include custom/preview.css --include custom/preview.js --verbose css

その他の小技

スタイルガイドのトップページ

コマンドを実行すると、各CSSファイルのHTMLページだけでなく、スタイルガイドのトップページも生成されます。このトップページは、対象のディレクトリ、ここまでの例でいえば css ディレクトリの直下に README.md というファイルを置き、その中にMarkdown形式で記述すれば、それがHTMLとなって反映されます。そのスタイルガイドを運用する上での説明などを書いておくと良いでしょう。

コメントをドキュメントに反映させない

ドキュメントに反映させる文章はコメントで記述するのはすでに説明した通りです。しかし中にはコード上残しておきたいが、スタイルガイド上は除きたいものがあるかもしれません。例えばコピーライト表記といったものです。
その場合にはコメントに先頭に半角スペースを空けることで、ドキュメントには反映されなくなります。


/* これは反映される */
 /* ←先頭に半角スペースを空けているので、これは反映されない */

擬似クラスのプレビュー

リンクやボタンなどのデザインでは、それらのマウスオーバー（:hover）、アクティブ（:active）などの擬似クラスの表現をスタイルとして用意することもあるでしょう。それらもプレビューとして表現したい場合には、プレビューのHTMLのclassに、:hover、:active というのをつければ反映されます。


```
<div class="section">
  <a href="#" class="btn btn-primary">Primary</a>
  <a href="#" class="btn btn-primary :hover">Primary hover</a>
  <a href="#" class="btn btn-primary :active">Primary active</a>
</div>
```

StyleDoccoの惜しいところ

StyleDoccoは今のところ、スタイルガイド本体のデザインを変更するためのオプションなどはありません。例えば、納品データとしてスタイルガイドを用意したい場合には、それらしい体裁にしたかったり、余分な要素を排除してシンプルにしたい、ということがありません。
そのレベルで対応したい場合には、StyleDoccoが影響をうけた、KSSというスタイルガイドジェネレータであればテンプレート機能でデザインのカスタマイズが可能です。同様に、KSS派生のnode.js版 kss-nodeでも同じようにカスタマイズ可能です。これらの使い方については今回説明はしませんが、興味があればStyleDoccoと比較して試してみると良いでしょう。

またStyleDocco自身には、ファイルの更新を監視して自動実行する、といった仕組みはありません。
CSSファイルを更新したら、自動的にStyleDoccoのコマンドを実行する、ということをおこないたい場合には、grunt.jsを使うと良いかもしれません。

grunt.jsはnode.jsで実装されているビルドツールです。grunt.jsについての詳しい話は今回割愛しますが、grunt.jsを使うのであれば、grunt-styleguideというgruntタスクがあるので、それを使えば自動化が容易です。こちらも興味があれば試してみてください。
※ただし、grunt-styleguideたまに上手くスタイルガイドページの生成時に一部が反映されなかったり、タスクを動かすgrunt.js本体のバージョンに左右されて動かないようなケースもあるので、そのあたりは注意してください。

スタイルガイドで気づくモジュール設計の重要さ

きれいにスタイルガイドをつくるためには、それぞれモジュール単位でスタイルをつくる必要があります。StyleDoccoでも必要に応じてプレビューデザインをHTMLスニペットで作るわけなので、そうした設計が必須となります。
順番としては逆になってしまいますが、こうしたツールを通じてでもスタイルガイドを強く意識することで、CSSの設計をより深く考えられるようになります。

CSS開発を効率化するドキュメントとして、それだけではなくCSSの設計力を身につけるためのツールとしてもおすすめします。

最後までお読みいただきありがとうございました。

Fireworksを使った大規模ウェブサイトのデザイン設計

こんにちは。アメーバ事業本部デザイナーのパジェロです。
現在、スマートフォン版Amebaのデザインを担当しています。

今回は、大規模なウェブサイトのデザインファイルをAdobe Fireworksで制作・管理する方法を、実際に現場で使用しているファイルを元にお話したいと思います。

スマートフォン版Amebaとは

スマートフォン版Amebaとは、Amebaがスマートフォン向けに展開しているサービスの中心となるプラットフォームサイトです。

Amebaにはたくさんのゲームやコミュニティサービスがあり、プラットフォームサイトはそのハブになっています。
それぞれに一覧や特集ページが用意されている上に、掲示板などプラットフォームサイト独自のコンテンツも持っているため、全体として非常に大規模なウェブサイトになっており、そのページ数は優に200を超えます。
この膨大な数のページのデザインを作成していく際に、1ページ1ファイルで管理していくのは効率が悪い、というかほとんど不可能に近いです。
そこで、Amebaのデザインチームでは、Fireworksを使ってサイトデザインを効率良く作成・管理しています。

Fireworksの長所

Amebaで使用しているのはAdobe Fireworks CS5.1です。
Webデザインの現場ではPhotoshopを使っている人も多いと思いますが、AmebaではFireworksを採用しています。
Fireworksは、大規模サイトのデザイン制作に非常に向いているからです。

Fireworksを使うメリットは大きく2点あります。
1点目は、リッチシンボルの活用によるデザインパーツの一元化が可能であること。
そして2点目が、ページ機能とステート機能によって複数のページを1ファイルで管理できることです。

この2点のメリットについて、実際のデザインファイルを例に説明していきたいと思います。

デザインパーツを一元化する

Amebaは膨大なページ数を有するサイトですが、全体を通してデザインのテイストは統一されていなければなりません。
そこで自然と、同一・類似デザインのパーツを何度も使うことになります。
この時に便利なのがシンボルです。
よく使うデザインパーツをシンボル化しておけば同一パーツの管理・デザイン変更が楽になります。
例えばAmebaで頻繁に使っているこのボタン。

このボタンも、背景をシンボル化しています。
この画面内のボタンの背景と枠線の色を変更してみます。

1つのシンボルをいじるだけで、

そのファイル内のすべてのボタンに変更が反映されます。

このシンボルに応用性を持たせたものがリッチシンボルです。
リッチシンボルとは、簡単に言うと、色やテキストなどの設定をいじれるようにしたシンボルのことです。
デザインパーツをリッチシンボルにしておくと、複数の類似パーツを単一シンボルで管理することができるようになります。
再びさっきのボタンを例に見てみましょう。
Amebaでは同一デザインのボタンにカラーバリエーションがあり、用途に応じて使い分けています。

デザインファイル内ではこれを1つのリッチシンボルにまとめて管理しています。
選択ツールでボタンのシンボルを選択すると、シンボルプロパティウィンドウに変更できるプロパティ（設定）が表示されます。

今回の場合は、プロパティ「type」を変更することで、ボタンの色を変えることができます。

このように、普通だったらカラーバリエーションの数だけシンボルを作らなければならないところを、リッチシンボル化することによって、たったひとつのシンボルで管理することができます。

複数ページを1ファイルで管理する

複数のページや条件分岐を1ファイルにまとめることができる機能がページとステートです。
【ゲーム】のページのデザインファイルを例に実際に見ていきましょう。

game.pngを開きます。

ページウィンドウを見ると、01～08の8つのページに分かれています。

これらは、それぞれが独立したページのデザインです。
このファイル内だと、ページ03【game_top_normal】が【ゲーム】のトップページです。
そして、このページの中の「恋愛」ボタンをタップして遷移した先のページのデザインが、ページ07【game_category_list_renai】に入っています。

このようにページ機能を使うことで、関係する複数のページを1ファイルにまとめることができます。

ファイル内の各ページはステートを活用することで、更に細かい場合分けが可能です。
ページ04【game_top_app】を見てみましょう。

ステートウィンドウを見ると、このページには【default】と【popup】の2つのステートが設けられていることがわかります。
ここでは【default】で通常時、【popup】でポップアップ広告表示時の状態を見ることができます。

このように、ステート機能を使うことで、より細かい場合分けを管理することができます。

※注意点
ページとステートを多用するとファイルが複雑化します。
混乱を防ぐために、「ページは遷移」「ステートは条件分岐」など、ルールを設けて使うことをおすすめします。

ページ、ステート機能の応用例

ページ、ステートは、場面に応じて工夫することで更に便利に使うことができます。
最後に、Amebaのデザインチームで実際に使っているステート機能の応用例をご紹介します。

■ A/Bテスト

A/Bテストとは、1つのページを、デザインや内容が微妙に異なる「Aパターン」と「Bパターン」に分け、どちらのUIがよりユーザーに使いやすいかをテストする手法です。
それでは数ヶ月前のgame.pngを開いてみましょう。

今の【ゲーム】のページと全然違いますね…。
Amebaは日々改修の連続で、UIもどんどん変化しています。
この頃は特に怒涛の改修ラッシュで忙しかった…。

さて、このページはステートで【01_ranking】と【02_vs】に分かれています。
この2つを見比べてみると、上段の一部コンテンツだけ
別々のものが入っていることがわかります。

この2つを同時に公開し、ユーザーの反応が良かった方を採用する、
の繰り返しでUIの改善を進めていきます。
ステートを利用することで、A/Bテスト用のデザインを効率良く整理することができます。

最後に

このように、大規模なウェブサイトのデザイン制作においてFireworksはすごいパフォーマンスを発揮します。
スマートフォン版Amebaでは、これからもツールのポテンシャルを活かして、スピード感のあるUI改善を進めていきたいと思います。

最後までお読みいただきありがとうございました。

Cubaseで作るピグサウンドの作り方

こんにちは。
アメーバ事業本部でサウンドを担当しています倉科です。

以前もこちらのブログで書かせていただきましたが、今回はピグのサウンドの作り方をCubaseを使い紹介させていただきます。音色の選び方から各トラックの処理をCubaseの内蔵音源と付属プラグインで行いたいと思います。

ユーザーの再生環境に最適な音を考える

まず音質ですが、PCのほうが128kbpsのmp3（それ以下の音質のサービスも有）、スマートフォンのアプリは128kbpsのcaf及びoggになります。どちらもサンプリングレート44100、16bitのwavを変換したものになります。

音楽の作り手としていい音を届けたいという気持ちはもちろんですが、ユーザーの再生環境を考え、それに適した音作りをすることが何よりも大切なことです。
ユーザーの多くの再生環境である安価なPCのスピーカーでは特定の周波数以下の低音は全く聞こえません。高音だけが強調されないよう全体のバランスを見て、PCのスピーカーとヘッドフォンやイヤホンで聞こえ方が大きく異なることがないよう意識しながら楽曲を制作していきます。

音色と各トラックの処理

音色選びの際に注意していることですが、ピグの2次元でかわいい世界観を再現するために、生っぽい音や過剰な演出の音は避けシンプルで加工しやすい音を選ぶようにしています。Cubaseの内蔵音源HALION Sonic SEは音色が豊富で使い勝手も良いのでピグのサウンドを作るときにとても重宝しています。

【ドラムの処理】
まずドラムですが、ソフト音源の場合各パートのバランスはしっかりしているのでキック、スネア、ハイハットなど個別の音の処理より全体的な音のバランスに注意します。

ドラムにはVintageCompressorをよく使います。VintageCompressorを用いることで全体の音のバランスを揃え、滑らかな音に仕上がります。

ハイハットやシンバルの高音が強いと安価なスピーカーの場合主張しすぎるので高音が強い場合EQでカットします。裏でこっそり鳴らしているくらいがバランスよく聞こえると思います。

【ベースの処理】
次にベースですが、極端に低音が強い音色や歪みが強いものより、C2～C3くらいの高さで違和感無く使える音色を選びます。このくらいの音高で使える音色であれば PCやスマートフォンのスピーカーでも無理なブーストをしなくても聞こえるようになるかと思います。
ドラムと音が被る場合、被る音域をEQでカットすると音の抜けも良くなります。PCピグの場合モノラルの場合が多いのでEQので音の被りを防ぎます。

【メロディー】
リズム系以外のメロディーの部分ですが各楽器によって処理は異なります。CompressorやEQは各楽器ごとに調整しますが、音圧を上げすぎたりEQでブーストし過ぎると原音を損なうのでほどよくバランスを取ることが大事です。また、あまりリアルすぎる音だとピグの世界観に合わないこともあるのでHALION Sonic SEの原音っぽさを残すこともあります。主旋律の楽器はEQで各楽器の音を調整して音が前面に来るようにCompressorを軽くかけるのが良いかと思います。
ストリングスやパッド系の楽器は音を潰して奥から聞こえるようにすると上手く聞こえるようになります。
全体の音圧はマスタートラックのほうで行うので各トラックでは相対的に音を捉えるように心がけています。

主旋律にReverbのPlateをかけると音がなじみ良い響きが得られることがあります。音を重ねたときに違和感を感じたりまとまりがほしい時にこのようなReverbを使います。マスタートラックのReverbと組み合わせることでDTMにも豊かな響きを与えることができます。

マスタートラックの処理

マスタートラックの処理ですがこちらの5つです。Reverb以外の要素はほぼ使い、曲によって中身を変更していきます。

StereoEnhancerはステレオの広がりを調整するものです。モノラルするときにもこちらを使います。
マスタートラックのReverbですがこちらではホールやスタジオなど曲全体の響きを調整します。ノイズが発生したり音が籠もらないように注意します。

マスタートラックにMaximizerを使うことで全体の音圧を上げます。音質の良し悪しで音の聞こえ方が全然違うのでクリップしない範囲で持ち上げます。

EQですが、スマートフォンやPCのスピーカーの場合を想定して聞こえない音域をカットし、目立ちすぎる音域を抑えつつ音のバランスを保ちます。高音を削りすぎると物足りなくなってしまう場合もあるので音を聞きながら調整が必要です。

Multi Band Compressorですが全体の帯域の中で特定の帯域にコンプをかけたい場合に使います。使い方が非常に難しいですがどこの帯域の音を圧縮してゲインを上げるか、元の音と聞き比べながら最終的な調整をします。

最後に

世界観を作るのはスコア（楽譜）も重要ですが音の志向や作り方、どういったミックスをするかが非常に大切だと思います。今後もみなさんに喜んでもらえるように音楽的な取り組みも継続していきますのでアプリやピグのイベントもチェックしてください！

もっと効率の良い方法やミックステクニックありましたらblogやTwitterで突っ込んでくださいね！

愛されるカードグラフィックの制作裏～入門編～

初めまして、天下統一クロニクル開発者の岸知秀といいます。

普段は開発の方向性を決めたり、ゲーム全体の品質向上などを主に行っています。

ご当地×美麗イラストに注力しているゲームなので、今日はカードイラストの制作にまつわる話を企画（プランナー、ディレクター）側目線で簡単にご紹介させて頂ければと思います。

製作の体制

このゲームは公開当時から700枚という驚異のイラスト枚数から開始しました。

そして毎月、100を超えるイラストを描いて、実装しています。

そのため、絵を描く人はチーム内外に100名以上いるのに加え、

それを補助・管理するメンバーが常に3名、兼業で4名が参加しています。

一口にいっても絵が描けるメンバーや、進行管理に特化したメンバー、

イラスト指示書の製作がうまいメンバーなど役割も多様です。

また、内部だけでなく「工画堂」様などのアートディレクションチームにも参加いただいています。

ソシャゲという単語で思い浮かぶ規模より、大分大きい規模かもしれません。

イラスト製作の流れ

絵師様が作業に入る前に内部で行うものとして主に次の２ラインが並行して走っています。

①絵師様を探す⇒連絡とって契約⇒③へ
②題材の選定⇒設定作成⇒キャラクターデザイン⇒③へ

題材の選定はこのゲームにおけるキモともいえる部分で、
「季節的にこんなカードが必要じゃないか」「バランス的にＸＸ県のＲカードを増やしていこう」など大体、３～５か月くらい先を見ながら運用しています。

公式ツイッターなどを通じてお客様からリクエストを集めて、それで増えたりもしています。
上記の二つがそろうと絵師様への発注となります。

③発注⇒構図作成⇒ラフ⇒着色⇒完成⇒④へ
イラストが完成してからも結構実装までには行程があります。
カードの枠をつけたり、プロフィール用のサムネを切りだしたり、
少しでも容量を小さくするために、一枚一枚劣化がないか確認しながら圧縮をかけたり、ですね。何気に大変です。これは内部のチームで行っています。

④レアリティによる調整⇒ゲーム素材化⇒実装
レアリティにの話は後述してあります。

以上、この流れが基本系となっていて、早いと2週間、長いと3か月くらいかかります。

まだ未実装のイラストなんですが、
制作中のラフとその発注に使った資料を、
このブログを読んでいる方だけに先にちらみせしちゃいます。

＊キャラクターデザイン：河原麻里奈

気を使っているポイントと苦労したポイント

天クロでは美麗というところで、品質にはもちろんとても力を入れいます。

それを前提として、「愛されるカード」「どの人でも絶対好きなカードがある」というコンセプトをチームの中で掲げています。

そもそも天クロは地元愛をテーマにしてるので、

どの題材にも日々それにかかわる人・好きな人がいます。
なので、どの題材のカードも、しっかり作ろうという、という感じです。

普通の開発現場や、開発セミナーでは、予算は極端に振り分けて

ノーマルは安く数をそろえ、高レアリティに予算を多く積む。のが定石とされています。

しかし、天クロではレアリティに応じて予算を変えるのをやっていません。

ぱっと言うといいことのようにも聞こえるし、実際いいことだと思って始めたのですが

そのために当初苦労した点もありました。

低レアリティ（ノーマル）と高レアリティ（Ｓレア）の品質差です。

どちらも力ある作家様に、力を入れて描いてもらっています。

そうするとノーマルが豪華になりすぎて、Ｓレアが欲しい欲求が湧きません。

これは当初、とても色々な人に指摘されました。

とはいえ、ノーマルもしっかりいいカードにしたい。欲しいって言われるカードにしたい。

というわけで色々と試行錯誤を繰り返しました。

ひとつのシンプルな回避方法としては、
「最終的にはカメラの距離と構図」を利用しました。

ノーマルほどキャラクターの顔を大きく（カメラに近く）静止した瞬間を題材

Ｓレアになるほど人物の顔を小さく、動いている瞬間をとらえ、濃淡の差を強くつける。

これを使い分けることで、
どちらも素敵で綺麗なイラストなのに、レアリティの差が現れるようにしています。

カード絵をこれから描く方はぜひ意識してみてください。

大分印象が変わると思います。

（しかしカード絵のレギュレーションはメーカーによって違うので、
　それに倣う必要はあると思います）

＊天クロで実装してあるカード
上段がノーマル。下段がＨレア・Ｓレアというトップレアリティ群。

「欲しい絵」を作る感覚を大切にしつつも、客観も忘れないデータ分析

「リーダーカードに設定されているカード」だったり、

バナーにキャラクターを使う時は、「どのキャラクターがクリックされるか」など様々な情報を集めています。

＊リーダーカード：ゲーム内における自分の顔（アバター）のようなもので、ゲーム的に強くなるなども利点はない。

それらを集めて、常に人気があるイラストの方向性などを分析し、チームに共有をしています。

こうした運用を重ねていくことで、愛されるカードイラストを作っています。

おかげさまで12/25時点で、
会員数、日々遊んでいるお客様の人数でNo.1になることができました！
これからもどんな方でも、必ず好きなカードがみつかるカードゲームとして
日々開発をがんばっていこうと思います。

さて、かなり長くなってしまったので今回は以上で終わりにしたいと思います。

最後までお読みいただきありがとうございました！

最後に天下統一クロニクルでのイラスト製作に

興味がわいた方がいらっしゃったらこちらまでご連絡ください。

tnk47_1pixel☆cyberagent.co.jp

☆→@

今年中に読んでおきたい！2012年人気の記事10本！

今年も残すところあとわずかですね。いかがお過ごしですか？
スマートフォン版Amebaのディベロッパーを担当している宇納(@TasukuUno)です。
このブログの編集委員なんかもやったりしています。

2011年8月にオープンした1 pixelですが、皆様のおかげでここまで更新を続けることができました。いつもありがとうございます！
本日は、今年2012年に公開された記事の中から、特に反響の大きかった記事をピックアップしてご紹介致します！

【デザイン】ピグアイテムのイラストレーションについて

長年アメーバピグのデザインを支えてきたデザイナー、青山の記事。
ピグの世界感はただ「かわいい」だけではなく、2Dながら空間を感じることができるような、きちんと計算された構図やデザインポリシーの上で成り立っています。多くのデザイナー・イラストレーターが在籍する弊社で、その世界観を壊さずに発展させていくことができているのは、この記事で紹介されているようなルールの上で制作を進めているからです。

http://ameblo.jp/ca-1pixel/entry-11191977597.html
（3月14日公開）

【開発】SPピグで見るCSS3活用事例

スマートフォン版アメーバピグで、HTML/CSS/JavaScriptなどのフロントエンド開発を担当する(*)森の記事。
スマートフォンの登場により、昔のブラウザでは使えなかった、HTML5やCSS3を多様したWebアプリケーションが作れる時代になりました。弊社では、多くのスマートフォンWebブラウザ向けサービスを展開していますが、こちらはその中でもかなり初期のプロジェクト。この記事では「フレキシブルボックスが便利すぎてやばい」件など、CSS3にフォーカスした活用事例をご紹介しています。

(*) 弊社ではディベロッパーと呼んでいます
http://ameblo.jp/ca-1pixel/entry-11215557737.html
（4月11日公開）

【デザイン】データ管理で作業効率がUPするデザインワーク

今年は、スマートフォン版Amebaが全面リニューアルした記念すべき年でもありました。こちらは、そのプラットフォーム（通称デカグラフ）で手腕を振るうデザイナー、おばたの記事。
大人数でも効率よくデザインワークを進めるために、データの管理方法1つを取ってみても、細かく気を配っています。UIをコンポーネント化してFireworksで管理するとどういったメリットがあるのか、またアイコンをCSS3から対応したWebフォントを使って実装するなど、スマートフォン開発ならではの工夫も書かれています。

http://ameblo.jp/ca-1pixel/entry-11281463120.html
（6月20日公開）

【開発】JavaScriptのテスト手法

先ほどの記事と同じく、スマートフォン版Amebaで、Node.jsとフロント側のJavaScriptを担当するディベロッパー、川口の記事。
最近でこそJavaScriptはサーバーサイドでも使われていますが、元々はブラウザで動くスクリプト言語です。HTMLとの関連もあるため「ボタンがクリックされたら正しくポップアップが表示されるか」といったテストコードを書くといったことはなかなか難しい。ですが、近年はそういったテストを可能にしてくれるテストフレームワークが出ています。この記事ではそのひとつ「Jasmine」を例に、利用方法をご紹介しています。

http://ameblo.jp/ca-1pixel/entry-11279972790.html
（6月27日公開）

【開発】knockout.jsでさくさくWebアプリ開発

スマートフォン版アメーバピグのディベロッパー、吉川の記事。
フロントエンドのJavaScriptでは、業界的に見てもいくつか課題がありますが、その1つにDOM操作の問題があります。時にはCSSでも共用するidやclassを利用してDOMを取得し、それに対してイベントを紐づけたりとしていくうちに、Viewとロジックが切り離せなくなる・・・そういった苦い経験をお持ちの方は少なくないはず。この記事では、それを解決するフレームワークの1つ、「knockout.js」について初歩からご紹介しています。

http://ameblo.jp/ca-1pixel/entry-11298459074.html
（7月25日公開）

【デザイン】Illustratorによるイラスト制作の基本操作

今年も多くの新卒エンジニア・新卒デザイナーが弊社に入社しました。こちらはその新米デザイナーの1人、マチダが執筆した記事。
当時はまだ彼女の担当サービスは未発表でした。ところが、研修で制作したイラストを例に執筆してみたところ、はてなブックマーク数で他の先輩社員を一気に突き放すという大偉業をやり遂げ、社内でもちょっとした話題になりました。内容は、Illustratorでイラストを描いたことがない方でも興味を持っていただけるような基本的なチュートリアルになっています。

http://ameblo.jp/ca-1pixel/entry-11327275121.html
（8月15日公開）

【開発】リッチスマートフォンWebアプリのメモリ管理

PCで提供している「ピグライフ」をスマートフォンでも楽しめる「どこでもピグライフ」の開発を担当しているmaginemuの記事。
このブログは一応クリエイターズブログなので、基本的にはエンジニアは記事を執筆しないのですが、実は彼はサーバーサイドもこなすエンジニア。フロントエンドの分野ということで特別に書いてもらいました。スマートフォンはHTML5/CSS3/JavaScriptが使えると言っても、やはりモバイル端末。メモリを消費しすぎると、ブラウザがクラッシュすることも。この記事では、ブラウザのWeb Inspectorを極限まで活用した、メモリ管理の方法をご紹介しています。

http://ameblo.jp/ca-1pixel/entry-11333270027.html
（8月22日公開）

【デザイン】女子中高生向けの「かわいい」キャラクター制作

こちらも今年入社したばかり、女子中高生向けのコミュニティサービスCandyを担当するデザイナー、松本の記事。
突然ですが「かわいいデザイン」とは何でしょうか？受ける印象・感じ方は人それぞれです。私たちは女子中高生ではないので、女子中高生がどんなものに「かわいい」と感じるかはわかりません。この記事では、彼女が持ち前の行動力を活かし、「女子中高生がかわいいと思うキャラクター」を追求したプロセスと、それを実際にサービスに登場させた事例が書かれています。

http://ameblo.jp/ca-1pixel/entry-11375074847.html
（10月10日公開）

【開発】モバイル時代におけるCSSの設計と実装

フロントエンド開発の分野で社内外、国内外問わず活躍している斉藤の記事。
JavaScriptの設計の話題は頻繁に議論に上がりますが、CSSの設計についての記事を目にしたことのある方はそう多くないかと思います。近年では、CSSこそDRY(Do not Repeat Yourself)やオブジェクト指向の考え方を取り入れ、メンテナンス性、柔軟性を実現することが不可欠と考えられています。この記事では、それを踏まえた上で、実際にCSSをコンポーネント化する具体例をご紹介しています。

http://ameblo.jp/ca-1pixel/entry-11413319214.html
（12月5日公開）

【デザイン】280万回押されるボタンのデザインとは

新卒入社ながら「きいてよ！ミルチョ」のデザイナーとして最前線で活躍している山幡の記事。
この記事は、なぜか公開直後の社内での盛り上がりが凄まじかったのですが、それも彼の人柄の賜物でしょうか。ある日、彼は社長との会議中「このボタンはコアな機能だから、もっと目立たせた方がいい」と言われ、試行錯誤するも上手くいかず頭を抱えます。その試行錯誤の日々と、ある先輩デザイナーから言われた一言で問題が解決した経験談について語っています。

http://ameblo.jp/ca-1pixel/entry-11424360340.html
（12月12日公開）

まとめ

いかがでしたでしょうか。
他にもご紹介したい記事は山ほどあったのですが、特に皆様からの反響の大きかった記事や、ページビュー数の高い記事を10本厳選させて頂きました。

イラストやUIデザインを題材にした記事もあれば、JavaScriptをはじめとした、フロントエンド開発の技術寄りな記事も多く読んで頂いているようで、大変嬉しく思います。

来年も、少しでも興味を持っていただける記事をお届けできるように、クリエイター一同努力していきますので、今後とも1 pixelをお願い致します！

クリエイター向け新卒採用「Artboard」で選考特典！

最近めっきり炬燵が恋しい寒さになりましたね。

皆様、お久しぶりです。アメーバ事業本部経営本部局の小林です。

今日はサイバーエージェントのクリティブコースの
採用特設サイトについてお知らせさせていただきます。

2014年度卒業生向け「Artboard」で書類選考スキップ特典

12月に入り就職活動も本格的にスタートしましたね。サイバーエージェントでも12月よりクリエイティブコースを希望の皆さんに向けてユニークな採用をスタートさせました。

その名も「Artboard」

クリエイティブコースを目指す皆さんに、よりクリエイティブに自身の良さをアピールしてもらおうと今年、初めてこのような特設サイトを開設しました。

なんと、このArtboardに自信の作品(イラストや写真、WEBサイト)を登録して「いいね！」を沢山もらうと……
上位30名に「2014年度新卒採用における書類選考をパスできる特別選考パス」が授与される特典があるんです。

「Artboard」に投稿できるのは一人10作品。
自信のあるジャンルに絞るのでも良し、幅広いテイストの作品で勝負するのも良し。

個人ではなく、作品ごとに「イイネ！」をもらえるので沢山投稿するとそれだけあなたの作品が見られる機会が増えます。

自分の力作、自信作を思いっきりアピールしてください。

「まずは自分の作品をアピールしたい」
「作品から伝えたいものがある」
「何も言わず私の作品を見て」

スタートはなんでもOKです。
沢山投稿してください！

募集期間が2013年1月14日（月）までなので、早めにUPするとそれだけ見てもらう期間も増えるので早めの投稿がおススメです。

■Artboard■

http://artboard.cyberagent.co.jp

【募集期間】

2012年12月10日（月）から2013年1月14日（月）23時59分まで

(※詳しくはArtboardをご確認ください)

皆さんの作品、お待ちしています！

280万回押されるボタンのデザインとは

みなさま、はじめまして！
デザイナーの山幡です。今年の4月に新卒で入社しました。
今は、CMでもおなじみ「きいてよ！ミルチョ」のUIデザインを担当しています。

今回はミルチョの中で最重要とも言えるボタン「きいてよ！ボタン」の制作エピソードをメインに、UIデザインについて考えていることやポイントなどをお話できたらと思います。

「UI」って何？

UIとはユーザーインターフェース（User Interface）の略です。
ユーザーが何か行動を起こす時に使えるボタンなどを提供してあげて、
その行動の結果をユーザーに見える形で表示してあげる。これが役割です。

といったかんじで説明すると何だか難しいかんじですが、
ミルチョの場合はもっと簡単に考えています。

ミルチョの住んでいる畑（？）と僕たちが今生活している世界。
この間に挟まってて、ミルチョの世界と僕たちの世界をつないでいるのがUIです。
間にあるものだから、きちんと操作できるのはもちろんのこと、ミルチョの独特な世界観も踏襲して、ユーザーが世界に入りこんでいけるようなデザインになるように心がけています。

きいてよ！ボタン

僕がミルチョチームに入って1番最初に苦戦した作業が、きいてよ！ボタンの作成でした。
きいてよ！ボタンは、押すとテキスト入力画面が立ち上がり、どーでもいいひとりごとを投稿すると、ミルチョや他のユーザーがきいてくれます。

ミルチョというコミュニティサービスを成立させるためには、
1番使われるべきボタンだと思います。

社長との会議で「コアな機能だから、もっと目立たせた方がいい。」という話があり、
本格的にデザインの改修に入りました。

改修前のきいてよ！ボタンはこんなかんじ↓

ルールを破る

とりあえず考えつくだけのボタンのパターンを用意しました。

しかし、どれもわざわざ変えて効果が見込めるほどの違いのあるボタンにはなりませんでした。

そんなダカイ策が見つからないでいる僕に、
先輩デザイナーのサトウさんが声をかけてくれました。

「こういうプラスチックみたいなボタンが、真ん中にどーんと置いてあったら押すよね。」

た、確かに…

でも、ミルチョのUIでは今までそんな処理やパースをかけたことはないし…。
いわばミルチョのUIの中ではルール違反のボタンです。
しかし、ミルチョの世界の中にたった１つだけルールを破ったボタンが置いてあれば、
ユーザーが一番気になるボタンにはなると思いました。
その「異物感」を不快なものでなく「良い意味での異物感」になるようにするのは
デザインの課題でした。

きいてよ！ボタンを作る

まずは、パースや処理でルールを破る分、
ボタンの形自体は、ユーザーのひとりごとをフワフワ浮かべている雲から引っ張ってくることにしました。ボタンの形は、イラストレーター上でパスで作ります。
（拡大縮小に影響を受けず、編集にとっても便利！）

ボタンの上面と側面でかける処理が異なるため、パーツを分けておきます。

作ったパスデータをフォトショップ上に持ってきて処理をかけます。
モチーフを参考にしながらたくさん処理をかけて、
目で見ながら濃さを調整したり効果的でない処理を削ったりしていくやり方が好きです。
（少々時間はかかりますが...）

ここでプラスチックっぽい質感に見せるポイントは、
エッジにかけた光沢処理とパッキリとしたハイライトです。
これがないと立体的ではありますが、質感はプラスチックっぽくありません。

そして、出来上がったボタンに最後のひと工夫、押したときの処理を加えてあげます。

この２枚をユーザーが画面をタップしたときに切り替えてあげることで、
ギュッと押した感（リアクション）が出て、ユーザー体験が向上します。

最後に

こうして完成したきいてよ！ボタンは、
30万人を越えるユーザーに、通算280万回押されているボタンになりました。
（※累計きいてよ数参照 2012年12月現在）

ゆる～いデザインのミルチョですが、
ユーザーにそのゆる～い体験を続けてもらえるように
今日紹介したきいてよ！ボタンをはじめとして日々様々な改良を続けています。

「ど～でもいいひとりごとでゆる～くつながる新感覚コミュニティきいてよ！ミルチョ」
これからもよろしくおねがいします！→ http://mirucho.me
（まだの人はこれを機に始めて、きいてよ！ボタンを押してみてください！）

最後まで読んでいただきありがとうございました！

モバイル時代におけるCSSの設計と実装

はじめまして、こんにちは。
ネット総合事業本部プラットフォームDivの斉藤です。

今回は私の所属している部署からは初の1pixelへの寄稿となるそうです。

CSS開発のアプローチ

ほぼ同時期にモダンウェブ開発に欠かすことが出来ないと言われるようになったJavaScriptと比べると、CSSにおける設計、という話題はなかなか出てきません。

単純なウェブサイトを作る際にはあまり気にしてこなかった部分ですが、ウェブアプリを制作している我々の仕事には欠かすことが出来なくなってきています。

ほかのプログラミング言語に比べると圧倒的に非力な言語だからこそ、ほかのプログラミング言語でも重要と考えられているDRY(Do not Repeat Yourself)や、メンテナンス性、そして柔軟性を考慮した設計がより重要だとも言えると思います。

今回はそれらの原則を実行するために必要なコンポーネントについて紹介していきたいと思います。

コンポーネント

コンポーネントイメージの図

オブジェクト指向CSS(OOCSS)、Scalable and Modular Architecture for CSS(SMACSS)という単語を聞いたことがあるという方も多いでしょう。
今回紹介するコンポーネントとは、CSSにおけるオブジェクトあるいはモジュールと同じものだと考えてください。
※CSSにおけるオブジェクト、モジュールについては、Scalable and Modular Architecture for CSS(SMACSS)という本もあります。こちらについては現在私の方で和訳をおこなっています。

90年代のウェブサイトと比べると現代のウェブサイトには非常に多くのパターンを見つけ出すことができるようになりました。
コンポーネントとはそれらのパターンと言い換えることが出来ると思います。

ウェブサイトに限らず、人間はパターンを好む生き物です。心理学、神経科学のジャーナリストであるジョナ・レーラー氏は著書『一流のプロは「感情脳」で決断する』でこのように述べています:

身の回りに見たことがあるパターンを見いだすと、我々の脳はドーパミンを発する。

ドーパミンは快楽と結びつきが強いと考えられているホルモンだということなので、人間はパターンを好むという意見の裏付けにもなっています。
コンポーネントアプローチはユーザにとっての『使いやすさ』を補強するだけではなく、我々開発者にとっても有益に働くことが多いWin-Winのアプローチです。

ヴィジュアルパターンを抽出し、抽象化することでコードの繰り返しを避けることが出来ます。このことがDRYの原則を守ることにつながり、結果的にコードの絶対量を減らすことが可能になります。

抽象化されたコードは拡張性に優れていることから、柔軟性も高くなり、結果的にモダンウェブ開発では欠かせないイテレーションを素早く回すための基礎として優れていると言うことが出来ます。

1)と2)であげた特性はメンテナンス性を高めるために必要な要素です。またこの後で紹介するコンポーネントアプローチを行うためのワークフローを活用することでより強固なメンテナンス性を得ることが出来ます。

ビジュアル言語とも言えるCSSに効率性を求めるのは非常に難しいとされてきましたし、そのCSSの基礎である記述性が失われたわけではないため簡単なことではありません。
どんなコンポーネントがウェブサイトにはあり、それらをどのようにコード化していくのかを見ていきましょう。

コンポーネントリストとコード化

コンポーネントの最もわかりやすい例はボタンだと思います。
試しにGoogleで「CSS ボタン」と検索してみてください。驚くほどに多くの情報があるはずです。ボタンには様々なバリエーションがあります:

サイズ
色
形
状態(:hoverや:focusなど)

などがバリエーションの糧となる好例でしょう。

小規模のウェブサイトにも状態を含めたボタンのバリエーションは20くらい、最低でも10はあるはずです。CSS3の登場により、それらのバリエーションをコードだけで実現できるようになった代わりに、すべてのバリエーションを個別のコンポーネントとしてコーディングしてしまうと無駄の多いコードを生み出すことになってしまいます。

典型的なボタン(:hover、:activeの状態を含む)のCSS例:

.login {
  padding: 10px 15px;
  background: #4479BA;
  color: #FFF;
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  border-radius: 4px;
  border: solid 1px #20538D;
  text-shadow: 0 –1px 0 rgba(0, 0, 0, 0.4);
  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -moz-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -webkit-transition-duration: 0.2s;
  -moz-transition-duration: 0.2s;
  transition-duration: 0.2s;
  -webkit-user-select:none;
  -moz-user-select:none;
  -ms-user-select:none;
  user-select:none;
}

.login:hover {
  background: #356094;
  border: solid 1px #2A4E77;
  text-decoration: none;
}

.login:active {
  -webkit-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  -moz-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  background: #2E5481;
  border: solid 1px #203E5F;
}

この例では、ログインボタンそのものと:hover、:activeの状態バリエーション、合計3つのバリエーションを作りました。
もし赤いボタンがあったら、または緑のボタンがあったら、例ではコンテンツに応じてサイズが変わるボタンとなっていますが、固定幅サイズのボタンがあったら、と考えると、コードには無駄な部分が多いと言わざるを得ません。私の経験から言うと、間違いなくそれらのバリエーションは開発のどこかのタイミングで発生します。

それではこのコーディングのどこに問題があるのか、抽象化の作業を順を追って見ていきながら説明していきましょう。
まずはクラス名.login。

HTML5の仕様書のクラスに関するセクションでも:

・・・著者はクラス属性をコンテンツに求める見た目を説明する値ではなく、コンテンツ自体の特性を説明する値を利用すること。

とあるように、セマンティックであることをベストプラクティスであるとしています。

クラス名.loginは確かにセマンティックであると言えますが、.logoutボタンがあったとして(ほぼ確実にあるはずですが)、それら2つの要素に共通するパターンはないでしょうか？ユーザもその直接的に関連する2つの要素に対して一定のパターンを期待するはずです。
しかし、コンテンツ派生のセマンティック性にこだわったクラス名を付けてしまうことで、その2つの要素には共通のコードを存在させることは重複したコードを記述することを意味してしまいます。
もちろん、CSSプリプロセッサのSassやStylusにあるextendという機能を使ってこの問題の回避を行うことは可能です。しかし同様にCSSが元々持っている機能でも回避することも出来ます。

単純に.buttonクラスに共有するコードを定義すればよく、バリエーションを2つ目のクラスで定義しすることでも問題を解決できます。

.button.login、.button.logoutのようにすることで、.loginと.logoutが持つ共通のコードは.buttonに担わせることが出来るわけです。
先ほどの.loginボタンから.bottonのベーススタイルを分離してみましょう。

.button {
  padding: 10px 15px;
  background: #808080; /* デフォルトカラーとしてグレーを定義 */
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  border-radius: 4px;
  text-shadow: 0 –1px 0 rgba(0, 0, 0, 0.4);
  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -moz-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -webkit-transition-duration: 0.2s;
  -moz-transition-duration: 0.2s;
  transition-duration: 0.2s;
  -webkit-user-select:none;
  -moz-user-select:none;
  -ms-user-select:none;
  user-select:none;
}

.button:hover {
  text-decoration: none;
}

.button:active {
  -webkit-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  -moz-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
}

今回ベースとなるコンポーネントは色の違いによって拡張されるという定義にしています。.loginボタンが青だとしたら、それに関連するスタイルのみを定義すればよいことになります。こうすることで.logoutボタンの拡張も簡単に行うこと出来ます。
DRYであり、拡張性も高く、メンテナンス性にも優れたアプローチだといえるでしょう。

3バリエーションのボタン例

ウェブサイトが変わってきたのであれば、ワークフローにも転換が必要

今回は例としてボタンというもっともわかりやすい例を取り上げましたが、ウェブサイト、あるいはウェブアプリケーションにはボタンのほかにも様々な再利用できる要素があります。
それら要素をコンポーネント化し、コード化するのにもっとも優れた方法がコンポーネントリストページを作成することです。

HTMLもバージョンが変わり、CSSも同じようにバージョンが変わりました。JavaScriptも初期のウェブに見られた単純なトリック的な要素を扱う言語から、アプリケーション言語として転換を果たしています。しかし、ウェブサイトを制作するフロントエンドのワークフローそのものは大きく変わっていないのが現状です。

ウェブサイトを支える技術に転換があったのであれば、それに即したワークフローが必要だと考えています。

その1つがコンポーネントリストページです。
コンポーネントリストページとは簡単に言うと、ウェブサイト、ウェブアプリに必要なコンポーネントを一枚のページにまとめてコーディングしたものです。

メールマガジン発行ツールを提供しているMailChimpの例(画像の例ではありますが)がその好例です。

スタイルガイドというように呼ばれることも多いですが、この記事ではコンポーネントリストページと呼ぶことにします。ガイドラインというとどうしても作る方も見る方も構えてしまいますが、リストページであれば、単なるリストとしてとらえて考えることが出来ると思うからです。(最終的にスタイルガイドとよばれるドキュメントになっていくのですが。)

デザイナからベクターデータが届いたら、まずそのデータ通りにページをコーディングするのではなく、コンポーネントリストページにコーディングをしていきます。
初期の段階ですべてのパターンや拡張性について考える必要はありません。文章を書くのと同じで、まずは考えていることを書き出してしまうことが大切なことであり、文章と同じく推敲を重ねることがパターンとしての抽象化を適切に行うもっとも効率的な手段です。

アーネスト・ヘミングウェイ氏が言うとおりに『第一草稿はどんなものでもいまいちである』なのです。

すべての要素を1ページに収めてコーディングを行うことにはいくつかの利点があります。

CSSの結合時に問題が起こらない。1ページにすべての要素があるわけですから当然ですが、ページごとにコーディングを行うことに比べて、クラス名の衝突などが起こらないため、仮にCSSファイルが分離されていても問題なく結合することが出来る。HTTPリクエスト数を減らすことはページロード速度の最適化にとって基本となっていますので、思っている以上に効率がよい方法です。

CSSのテストが可能なページを作れる。どんな熟練の開発者でもCSSのカスケードを完璧に制御することは出来ません。どんなプログラム言語でも、実装に伴うテストの手法が確立されているものですが、CSSではなかなか難しいのが現状です。コンポーネントリストページを作ることで、その『当たり前』をCSSに取り込むことが出来ます。

私自身このコンポーネントアプローチを数年実践して来ていますが、すべてのパターンを見いだすことは当然出来ませんし、今後それらのパターンを瞬時に見極められるとも思いません。

まずページとしてコード化する前に、コンポーネントリストというプロトタイプを作ることで、『ああ、またこのパターンがあるのか、でも面倒だからこのままでいいか』という部分を減らすことが出来ると思います。

ウェブサイトはもはやページの集合体ではなく、様々な機能を有するシステムとして捕らえるべき存在です。ウェブページがシステム全体を構成する1つの機能であるとしたら、そのウェブページを構成する要素はシステムを構成するために必要不可欠なパーツとなります。
パーツのみを上手にデザインできてもシステムとして正しく動作するかは保証されませんし、機能だけが単品で存在していてもシステム全体としてのフローの中に組み込まれなければ意味をなしません。

最後に、これからのフロントエンドデベロッパにはどんなパーツを作る方法を知っているか、というトリビア的な技能だけではなく、どんなパーツが手元にあり、それらをツールとしてどう活かしているかが求められると考えています。
上手に抽象化されたコンポーネント/パターンはどんな種類のウェブサイト、ウェブアプリケーションにも適応することが出来ます。ある要素を『どう作るか』よりも、より本質的な『何が問題となっているか』そして、『どう解決するか』にフォーカスをすることがよりよいサービスを作るために必要な質問ではないでしょうか？
そんな質問をし始めるのに必要なきっかけがこのコンポーネントアプローチという考え方だと思っています。ものすごく概念的な話に終始してしまいましたが、手元の作業に集中するだけではなく、全体を俯瞰して開発を考えるきっかけになれば幸いです。