今回は、4月12日にリリースしたスマートフォン版ブログデザインの紹介も兼ねて、
開発時に特に気にかけたところを、お話しさせていただきたいと思います。

スマートフォン版ブログデザイン

スマートフォン向けページは、より最適なUIを目指し改善・改修が頻繁に行われます。
そういった事を考慮して一般的にはデザインの自由度を低く設定しがちですが、
それぞれのデザインの個性が最大限伝わる事を優先に開発を進めました。
一番左がおなじみの緑のデザインです。（デザイン設定をする前はみなさんこのデザインとなります。）
右の5つが今回リリースされた、スマートフォン版ブログデザインの一部です。
背景やヘッダーに写真を使用したもの、真っ黒なもの、かわいいイラストのものなど、
バラエティに富んだブログデザインが出来上がり、開発側の立場である私もテンションがあがりました。

ブログデザインとスタイルシートについて

ブログデザインの仕組みは簡単です。枠組みとなるスタイルシートと個別のデザインを決めるためのスタイルシートの2つで構成されています。

左側が、枠組みだけ指定したスタイルシートを適用したものです。
デザイン要素の指定がないので、色の指定もなくずいぶんシンプルです。

右側が、それにブログデザインの指定を記述したスタイルシートを追加したものになります。
ブログデザインのコーディングはテンプレートとなるスタイルシートを元に作成していきます。
コーディングの運用を極力減らすために、デザインで指定されているカラーコードなどを上から順に記述していくだけで済むような作りにしました。

このようなつくりすることによりデザイナーの方でも簡単にコーディングをできるようになり、効率よく量産できるようになりました。

■デザインテンプレート

■スタイルシート

■頻繁に行われる改修に対応させる
先ほどもお話したようにスマートフォンのブログはUIの改修が頻繁に行われます。
今後新しい要素が追加されたときにも対応させられるように、
リンク色や背景色などの汎用的に使用するスタイルにそれぞれクラス名を用意しました。


既存のデザインのスタイルシートを修正を加える事なく、
用意したクラス名を指定すればデザインに対応できる作りにし、UIの改修もスムーズに行えるようにしました。

管理ページについて

管理ページの設計は、以下の2点を特に意識して進めることにしました。

①デザインを楽しく選べること。
②スマートフォンならではの見せ方。

既存のスマートフォンのブログ管理ページは、いかにも管理ページらしい固めなイメージでした。しかし、ブログデザインに関してはただデザインを選び適用するのではなく、見た目も楽しいと思えるような作りにしたいと考えていました。

また、スマートフォンでは画像の見せ方ひとつでもフィーチャーフォンと比べて、いろいろな見せ方ができます。横スクロールで見せたり、ポップアップで見せたりなど見せ方についてスタッフ間で議論を重ねました。

試行錯誤の結果、トップページと一覧ページではシンプルにデザインのサムネイルを表示するだけにとどめ、イメージ画像を左右にスライドすることで選べるページも作成しました。

スライドページを作成することにより、直感的にイメージをつかむ事ができるようになったのと、「選んでいる感」が得られるようになったかと思います。

ブログデザイン100本同時リリース

今回のスマートフォン版ブログデザインのリリースでは、100本を同時にリリースするという目標がありましたが、実際のリリース時には、目標を上回る106本を用意する事ができました。


その中からスタッフに人気のデザインをご紹介します。

<女性スタッフに人気のデザイン>
■マカロンカラーシリーズ



シンプルですがかわいい配色で人気です。

■ドングリサーカス



かわいい犬のイラストが楽しそうなデザインです。

■にわとり



こちらもイラストとカラーがかわいいデザインです。

＜男性スタッフに人気のデザイン＞
■輪派絵師団デザイン



虎のイラストが印象的な渋いデザインです。

■カモフラージュグリーン



カモフラージュ柄は男性の定番デザインですね。

■SKID



自転車好きの方におすすめです。

みなさんも是非、好みのデザインを探してみてください。

おわりに

4月12日のリリースから2週間で、約30万人のユーザーの方にスマートフォン版ブログデザインを適用していただいております。
今後も新しいブログデザインをリリースしていきますので、今後ともAmebaブログを宜しくお願い致します。

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

スマートフォン版Amebaブログ
http://s.ameblo.jp/
スマートフォン版Amebaブログデザイン
http://sblog.ameba.jp/ucs/skinTop.form

スマートフォン版ピグカジノ・スロットゲーム (http://casino.pigg.ameba.jp/) の開発を担当させて頂きました。
今回は使用したツール・ライブラリ・参考サイトに的を絞ってご紹介していこうと思います。

ツール

texturepacker

• TexturePacker – Sprite sheet maker, image packer and optimizer | TexturePacker | Sprite sheet creation and image optimization

言わずと知れた有名ソフトです。
iPhone開発などで良く耳にするソフトですが、ブラウザ開発でも相当な威力を発揮します。

画像読み込みによる負荷軽減の為、バラバラの画像を最終的に一枚の大きな画像にまとめるのですが、それを全自動で簡単にやってくるソフトです。
さらに、位置・サイズ情報を記述したCSSの書き出しまで自動で行ってくれます。

また、ピグカジノ・スロットゲームはもともとFlashのゲームですので、既にあるFlashの資産をうまく活用したいという思いがありました。

TexturePackerはswfファイルをドラッグ&ドロップするだけで、Flashアニメーションをスプライトシートに変換してくれます。もちろん位置・サイズ情報の書き出しも同時に行います。

SWFSheet

• SWFSheet – create sprite sheets from SWFs | BIT-101

今のところ、TexturePackerはflash IDEのrootで展開されるアニメーションにしか対応していません。
入れ子になったアニメーションのスプライトシート化はこちらを使用しました。
TexturePackerのupdateで対応される事を望みます。最新版はこちらから。

WebStorm

• The best JavaScript IDE with HTML Editor for Web development :: JetBrains WebStorm

javascriptエディターはこちらを使用しました。
コード補完・解析機能が優秀で、これにより相当な数のバグを回避し、開発負荷を抑えスピードを出す事が出来たと思っています。
ブレークポイントをエディタ上で設定することも可能で、ブラウザが検出しないエラーを発見する事もありました。

Google Chrome

実機での確認までは主にChromeで動作確認しつつ開発を行いました。
Safariの方がよりモバイル端末の挙動に近いのですが、デバッグ関係の使い勝手の良さからChromeを使っています。
ただこまめに実機で確認しないと想定外の挙動をしている事が多々あるので、注意しなければいけません。

iOSシミュレータ

Xcodeに入っているiOSシミュレータを使う為、xcodeをインストールします。

• Xcode 4 - Apple Developer

単体で使用したい場合の注意点があります。
Xcode4.3からシミュレーターの場所に変更があったようで、


にあります。Xcode.appを右クリックし、「パッケージの内容を表示」を選択した中にあります。spotlightの検索で出てこなくなったので注意して下さい。

■デバッグ機能をONにする
iOSシミュレーターでこれが出来るとかなりdebugの幅が広がります。

• iOSシミュレータ内MobileSafariのWebインスペクタを有効にする方法 | ひとりぶろぐ

cssアニメーション作成サイト

css3からcssの記述によりアニメーションをつける事が可能になりました。
最初から用意されているアニメーションの種類は


です。しかしこれだけではメリハリに欠けるので自分で作成する事ができるのですが、その際に便利なサイトがコチラです。

• cubic-bezier.com

css3の仕様では4つしかコントロールポイントが使えないので詳細な動きは作れないのが残念ですが…。

この際、Flashでの動きが参考になります。

• easing_demo

実際にこういったグラフを参考に、Flashと同様の動きを作成しました。

ただ一点問題があります。
Safari(モバイル用含む)では値を0から1の範囲に収めないと表示がおかしくなります。
上記で挙げたサイトでは警告が出ますね。

この制限が無ければバウンドする動きなどが簡単に付けられるので、早く一般的に使えるようになってほしいですね。

Chromeでは問題なかったので、気付かずに酷い目に会いました。
お気をつけを…。

Charles、Fiddler

プロキシソフトです。
CharlesはMac用、FiddlerはWindows用のソフトです。

• Fiddler Web Debugger - A free web debugging tool

• Charles Web Debugging Proxy • HTTP Monitor / HTTP Proxy / HTTPS & SSL Proxy / Reverse Proxy

デバッグに威力を発揮します。
サーバーにファイルをアップロードせずとも動作確認が可能になります。

こちらのサイトを読んで頂くと、どんなソフトか分かって頂けると思います。

• フロントエンドの開発効率が3倍に…！？デバッギングプロキシCharlesの使い方 :: 5509

• 実はFiddlerがすごすぎたので、機能まとめ紹介 : blog.loadlimit - digital matter -

どちらも出来る事はほぼ同じですが、個人的にFiddlerの方が使いやすく、高機能だと感じました。しかも無料というのが素晴らしいです。

ImageOptim

画像軽量化ツールです。

• ImageOptim — make websites and apps load faster (Mac app)

Fireworks、Photoshop等などの画像操作ソフト

多少画質は落ちますが、png32ではなくpng8などのフォーマットで書き出し直すだけで劇的に軽くなったりします。
ただpng8ではalphaが50%のような半透明は使用できません。100%か0%かです。
半透明も使用可能です。(2012/05/10 10:50訂正)

ライブラリ

AutoReloader-js

html、css、jsファイルを監視し、更新があったら自動でリロードしてくれるライブラリです。

• ファイル保存時にブラウザを自動的にリロードする JavaScript ライブラリを書きました | Tanablog

CodeKitなどにも同様の機能がありますが、こちらはjsでのみ動作しているので、スマートフォン上でも動作します。
手元でファイルを更新すると自動でスマートフォン端末のページがリロードされるのはなかなか面白いです。
常にajaxでファイルを監視しているので、通信が発生するのだけ注意が必要です。

LimeJS

• LimeJS HTML5 Game Framework

スロットゲームにはこのライブラリを使用しました。

レンダリングをcanvasとDOMから選べるのがポイントです。
canvasはスマートフォンで使用するにはまだまだ動作が重いです。
DOMが使えるライブラリということで使用を決めました。

Flash・Action Scriptでの制作に慣れた方でしたら、かなり取っ付き易いライブラリです。
html、cssの記述が必要ありません。jsのみで完結できます。

ただ、まだまだ開発途上の為にバグも多く、苦労することも多々あります。
Androidへの対応もステータスは「Soon」です。

沢山のdiv要素が作成され、動的に要素をバリバリ書き換える為、そのコストが大きいと感じました。
ですので、html、cssで事前にきっちりとレイアウトしてアニメーションを外部CSSで記述し、要素の変更を最小限に抑えた場合と比べてしまうと、どうしてもパフォーマンスが出せない、というのが現時点での見解です。

PC向けの作成であればパフォーマンスは全く問題無いと思います。

Closure Library

• Closure Tools — Google Developers

LimeJSはClosure Libraryを元にして作成されています。

jsでの開発はコードがぐちゃぐちゃになりがちな気がするのですが、Closure Libraryはそれを改善するライブラリだと感じました。
書き方を強制されるので、それにより整合性が保たれます。(それでも自由に書けはしてしまいますが。)

そのぶん冗長な記述が必要になるので、サクッと書くのには全く向いていません。
そういった点でjavascriptらしくないライブラリです。

また、最終的に一つのファイルに圧縮して使うのが前提なので、それまでは大量のファイルを読み込むなどの欠点もあります。

しかし多人数での開発には向いているのではないでしょうか。

CofeeScriptのClosure Libraryモードがあるようで、ネックである冗長な記述が解決されていて非常に興味があります。

• CoffeeScript/Google Closure Demo

参考サイト

スマートフォンのブラウザ向けに作成するにあたり、動きのパフォーマンスが出ているサイトを探しました。
下記の2つのサイトはネイティブアプリのように滑らかに動作し、かなり参考にさせて頂きました。

• Windows Phone Demo

• SUBARU オフィシャルスマートフォンサイト

2つともアニメーションにはcss3の-webkit-transitionを使用し、細かな座標移動はtranslate3dを使用しています。

• animationプロパティ

もかなりのパフォーマンスを出す事が出来るようです。

まとめ

いかがでしたでしょうか。
ピグカジノの他にも、サイバーエージェントではたくさんのスマートフォン向けゲーム・アプリが現在鋭意製作中です！

今後も新たなノウハウを共有して行きたいと思っております。
ご期待ください！

FlashはFlash2から始めて、かれこれ10数年、Flashで仕事をしています。Flashは、バナーからリッチアプリケーションと幅広い用途で使われ、アメーバピグもその一つです。

いろいろな案件を対応してきた中で、私自身はデベロッパーで、デザインをもらって作業することが常なのですが、いつも悩ませるのが、素材管理です。各デザイナー、使うツールが様々で、Photoshop、Illustrator、Fireworksといろんなソフトがあります。


Flashに直接インポートする機能があるので、そのまま使ってもいいのですが、修正が発生した場合に、問題が生じます。


素材をインポート後は、通常は、自分の作りやすいように名前を変え、ムービークリップに入れたりと、まとめた状態になっています。そうした状態で、再度インポートを使うと、また０からになるので、インポートするのが非常に手間です。

そこで、私が考えた方法は、Fireworksにまとめてしまう方法です。FireworksはPhotoshop、Illustratorのファイルを読み込めますし、スライスの書き出しも簡単で、グラフィックが苦手な私でも簡単に使えます。使うパーツごとにレイヤーに分けて管理して、使いたい画像だけを書き出して使います。毎回、更新部分だけFireworksの編集作業が発生しますが、Flashよりは管理しやすいです。


修正が発生した場合も、Fireworksでグラフィック管理をして更新した部分だけを書き出して、Flashに画像の更新をかけます。画像の更新は、元のパスが有効であれば、簡単に実行できるので、Flashで画像を読み込む場合は、元画像を残しておくのがおすすめです。


この手順は更新するのはこれで十分なのですが、新規Flashで作成する場合は、画像素材の表示位置の調整は必要になってきますし、さらに、ライブラリ内の項目名も名前にも気をつけます。

ここを怠ると、せっかく外部に画像を保存しておいても、どの画像なのかわかりにくいので、管理する癖をつけた方がいいでしょう。

私は、この部分を解決する問題として、Fireworksの拡張機能を考えました。拡張機能は、標準では足りない部分をJavaScriptを使って追加できる機能で、今回は、Fireworksで自動にレイヤーごとに書き出して、Flashに読み込んで再配置を行うバッチスクリプトを書き出す機能を作りました。

アメーバピグの開発では、グラフィックを素材はswcでまとめて、それをFlash Builder内からインポートして使うようになっているので、画像をそれぞれクラス化するのですが、パッケージの指定もFireworks上のレイヤーで指定できるようにして、Flash側での設定を不要にしました。

Fireworksで拡張機能を実行すると、画像ファイルとFlashで読み込むためのjsflが書き出され、jsflをFlashで実行すると、画像を読み込んで、一つ一つクラス名を設定して、Fireworksと同じ座標に並べて再現してくれます。



Fireworksを扱うデザイナーの場合は、最初からレイヤーの構造もある程度、デベロッパーと合わせるように依頼できればクラス名の設定だけで、ここまで持ってくるのは簡単で、スピードアップは確実なので、みなさんも拡張機能を作って楽をしましょう。

これまでにAmebaアプリ、萌えガチャ、girlspicなどの
プロデュースやディレクションに携わってまいりました。

今回は去年の秋に大きくリニューアルをしたAmebaアプリについて書きたいと思います。

はじめに

AmebaアプリはiOS,Androidあわせて現在400万ダウンロードを超える、
当社スマートフォンサービスの中でもメインタイトルとなるアプリの一つです。
iOSは2010年1月、Androidは2010年12月にそれぞれver1.0をリリースしました。
当時の状況を振り返ると、各企業が本格的にスマートフォン対応を始めつつあった、
手探りのフェーズだったなと思います。




Amebaアプリでは当初、ブランドカラーを抑えiOSアプリらしい基本的な作りをしていました。




Androidにおいては、利用ユーザーがiOSの３割にも満たないという時期でした。
iOSと異なり明確なガイドラインが存在しなかった中、デバイスの特徴や一般的な操作方法を
捉えた構成づくりに試行錯誤した記憶があります。


(※Androidは端末ごとに標準フォントが異なります。Amebaでは同等のUIが提供できるようにAndroidで採用されていたモトヤフォントを埋め込みました。OS4.0より正式フォントとなっています。)


その後も着実にスマートフォンの市場は拡大し、
OSバージョンや端末スペックも多様化していきました。
アメーバアプリもダウンロード数が急激に伸びるとともに潜在的なバグが多く発覚したりなど、
改修に四苦八苦した時期がありました。（ご迷惑をおかけしましたm(. .)m）

そのような中2011年10月に向け初夏より開発をスタートし、
iOS,Androidの同時リニューアル対応するに至りました。

リニューアルについて

リニューアルに関しての取り組みや所感を幾つかにまとめたいと思います。

1.リニューアル版の機能と画面の要件について　
＜要件＞
ーiOS,Androidユーザーに向け同等の機能を提供すること
ー他デバイスから移ってきた方にも不足がない機能を提供すること
（ブラウザを利用しなくてもアメーバのメイン機能が利用できること）
ースマートフォンの利用シーンに即した機能を提供すること

上記を前提条件として、画面の構成と機能を決めました。
Androidでは新しく「Amebaなう」の閲覧、投稿を加え、
iOS,Android両者に
　・コメントや読者申請のノーティフィケーション
　・撮影した写真の加工
　・オフラインでも絵文字を利用したブログの下書き　等
スマートフォンならではの機能をつけ加えました。

＜デザイン＞
機能のラインナップを整理したうえ、デザインにおいては
スマートフォンらしい直感的なUIにアメーバらしさをプラスした
バランスの良いインターフェースを模索しました。





2.テストについて
＜影響度を考える＞
アプリのテストでは、リリース済みのバージョンで多く利用されていた
端末やOSを分析し重点的に実施しました。





＜金曜の夜＞
ブログ投稿機能については様々なパターンでテストを行いました。
特に通信環境の悪い時間帯で実施し、
妥当なタイミングでのタイムアウト処理を盛り込みました。
（渋谷という場所がら金曜日の夜は回線がかなり細くなるので、格好の時間帯です。
また山手線内などより使われそうで、不安定な条件のもと実施したりもしました。）




上記をはじめ、「投稿ができない、失敗する」という最もクリティカルな問題に対し、
外的要因も考慮に入れたできる限りの対応を行いました。



3.反省点
リニューアルを通してたくさんの反省と学びがありました。

＜スマートフォン上でサービスがどのように使われているか＞
・web viewでの横画面対応を行わなかった
（端末でピグをはじめ様々な操作に利用していた背景を掴みきれなかった）
・マイページで一部機能を除外したためにたくさんの問い合わせをいただいてしまった

などリニューアル初期にたくさんの方にご不便をかけてしまいました。
利用パターンを捉えきれなかったことが大きな反省点です。

＜ユーザー環境の変化を知る＞
開発中にiOS5のβ版がリリースされ、文字入力のインターフェースに
大幅な変更が入ることが分かりました。
そのため主要画面であるブログ投稿ページへ対応をいれるなど、
直前にプロジェクト内を慌ただしくさせてしまった場面がありました。

環境は足を止めず刻々と進化していくことを肌で感じました。
流れを常にキャッチアップし、必要であれば対応を検討する。
この意識は開発の大詰めであっても持っておくべきであり、
プロダクトの最終的な品質を大きく左右するものであることを痛感しました。

4.運用、改修について（アプリの質を保つための体制づくり）



ー最新OSや、新端末への動作保証
ー要望にあわせた機能追加や修正

これらをはじめ、守りと攻めの運用をスピーディに行うことが
Amebaアプリの品質を守る鍵です。

プロジェクト内では
　・重要な部分にエラーログを埋め込む
（特定の端末による不具合を洗い出すため、主要部分は端末名まで確認できる形にした）
　・トレンドの調査を頻繁に行う（端末名やOSの利用ボリューム）
　・ユーザーのお問い合わせ対応を行う専属メンバーを配置し、重大な内容はその場で開発メンバーと連携する　
　・様々な観点で週に１度、アプリの定期テストを行う

などをはじめ、ソースコードのレベルからプロジェクト体制まで運用・改善に適した形を整えてきました。

最後に

寄せていただく不具合のレポートや要望から、私たちは多くのことを学び、反省し、
時には励まされ、スピーディな改修へと反映することができました。

ユーザーの皆さんが届けてくれる声こそが品質向上に直結しています。

現在ではiOS,Android共に一定の評価をいただけていますが、
日々変化していく環境をしっかりと見据えてよりいっそう快適に使ってもらえるよう
引き続き機能改善に取り組んで行きたいと思います。


これからもAmebaアプリをよろしくお願いします。

HR戦略室は、主に広報・人事案件を扱っている部署になります。

今回は、コーポレートサイトのマルチデバイス化を踏まえつつ、半年程前にリリースしました(だいぶ前ですが…)スマフォ版コーポレートサイトについて、ご紹介したいと思います。

コーポレートサイトのマルチデバイス化

弊社のコーポレートサイトでは、国内版PCサイト・フィーチャーフォンサイト・そして今回ご紹介するスマートフォンサイトはMobableTypeを使って、海外版PCサイトはWordPressを使ってを制作、運用しています。

【コーポレートサイト一覧】


マルチデバイス対応を進めていく中で、特に意識している事は「情報管理」と「デバイス特化」のバランスです。ここでの「情報管理」とは、共通の情報をより一つに集中させ、各デバイスの情報の一元管理・同時リリースを行う考えで、「デバイス特化」とは、各デバイスに合わせたコンテンツ・デザインを提供する考えです。

一見、両立できそうなイメージはありますが、PCとスマートフォンで情報の優先度が違ってくるので、デバイスごとに見せ方や情報の順序を変える必要があります。「情報管理」に寄せすぎると更新が簡単になる一方で、デバイスごとの実装面で制約が生まれます。逆に「デバイス特化」に寄せすぎても各デバイスで実装の自由度が上がる分、更新は複雑になってしまいます。

以上を踏まえて、できるだけ共通できるページについては「情報管理」を行い、ページによって「デバイス特化」を行う事を前提にページをデザインしています。その他に【コンテンツの優先度】や【閲覧者の利用環境】を考えた上で、総合的にサイトデザインを行っています。
客観的な印象として、他社のコーポレートサイトに比べてやや「デバイス特化」にやや比重を置いたサイト構築を行っていると感じています。

スマートフォンサイトについて

昨年9月にリリースしたスマートフォンサイトについて、ご紹介します。コンセプトとしては、PCサイトと同じユーザーエクスペリエンスをスマートフォンでも実現する事でした。
企業の中でデバイスによって異なるトンマナを入れ込むと企業ブランディング上、良くない事ですので、PCサイトのトンマナに合わせてベタでシンプルなデザインになるように心がけました。

【サイトTOP / 採用情報 / サービス情報】


また、スマートフォンサイトでは、2点「リアルタイム」と「ポータブル」というキーワードを意識してデザインを進めました。「リアルタイム」という点では、Twitterなどソーシャルサービスの露出を増やし、「ポータブル」という点では、外出先での閲覧を意識しました。

加えて、TOPページなどの主要インデックスページだけでなく、3階層下のコンテンツページまで網羅的にスマートフォン対応をしています。

サイトTOP

【サイトTOP】


まず、スマートフォンサイトTOPについてですが、コンテンツ内容は、特別誘導枠・プレスリリース枠・CyberAgent_PR Twitter枠・サービス枠・公式ソーシャルアカウント枠で構成されています。
特に、Twitter枠・サービス枠・公式ソーシャルアカウント枠については、PCサイトTOPと比較してソーシャルコンテンツを中心にして、「リアルタイム」な情報を得る事ができる様に設計しています。

採用情報

【キャリア採用情報】


採用情報については、新卒採用とキャリア採用を分けて表示をしています。特にキャリア採用は3月にリニューアルを行い、求人情報以外に社員インタビュー、事業部紹介などのコンテンツを追加しました。完全に蛇足ですが、キャリア採用の求人情報ページは夏までに全面リニューアル予定で進んでいますので、しばらくお待ちください。（大変、見にくいページがあるんです…）

サービス情報

【Amebaサービス一覧】


こちらは、CyberAgentから提供しているスマートフォンサービスを網羅的に紹介したページになります。当時はアプリでのサービス提供が主だった為、アプリに合わせたUIになっています。現在は、ブラウザでのサービス提供が主流になってきているので、近日リニューアル予定になっています。
また、更新面ではExcelから更新を行える様になっていて、デベロッパーがいなくても、随時更新できるフローを採用しています。

こちらのページについては、同プロジェクトのデベロッパー 久保の技術的な解説と合わせて、ご紹介します。

アクセス

【東京本社アクセス】


スマートフォンサイトでは、アクセスをグローバルナビに入れ込み、他デバイスよりアクセシビリティを高く設計しました。googleMAPを使って現在地からの経路を見る事ができます。

IR情報

【IR情報TOP】


IR情報については、個人投資家のみなさま向けのページで決算情報の資料などをPDFで閲覧する事ができるページになります。IRニュースや最新株価情報や決算発表の資料など、PCと連動し、ほぼタイムラグのない状態で「リアルタイム」でアップデートされる仕組みを採用しています。

まとめ

冒頭でも触れましたが、マルチデバイス化が進むに連れて、「情報管理」と「デバイス特化」の前者を意識しがちですが、しっかりと後者を考えた上で前者の取り組みを進めていきたいと考えています。

先にも言った通り、「情報管理」は、実質の運用効率にも関わってくるサイト設計の際の非常に重要な要素ですが、「デバイス特化」を意識したUI設計・情報設計をしない限り、ただのスマートフォンで見ることのできるサイトになってしまいます。つまり、閲覧する人（ユーザー）にとっては、見やすいサイト・使いやすいサイトとは言うことはできないのです。これが他社に比べて、「デバイス特化」に比重を置く理由になります。

今回のスマートフォンサイトでは、「リアルタイム」と「ポータブル」というデバイスの特性を考えて、各情報に優先度をつけ、デザインしてきましたが、半年経って改めて考えた時に「情報の拡散」という点に課題を感じています。
PCサイトでは、コンテンツの一部につけている"Twitterでつぶやく"ボタンや、"Facebookのいいね"ボタンなど リアルタイムに情報を拡散していく仕組みを、PCサイトだけでなく、親和性の高いスマートフォンサイトでも積極的に、今後対応していく予定です。

4月からコーポレートサイト全体のリニューアルも考えていますので、「情報管理」と「デバイス特化」のバランスに加えて「情報の拡散」というポイントをしっかり押えて、デザインを進めていけたらと思います。

最後までありがとうございました。

スマートフォン版ピグはネイティブアプリとWebアプリがあります。
WebアプリはそのほとんどがHTML5やCSS3を多用していてブラウザで動作します。

JavaScriptやHTML5 APIなどについては、原が以前このブログで書いた
「HTML5 Web Applicationのつくりかた」という記事が詳しいので、
この記事ではスマホ版ピグのCSSについてマイページを例にご紹介します。

とても長い記事になってしまいましたが、最後までご覧頂けると嬉しいです。

スクリーンショットで見るCSSプロパティやセレクタ

2012年4月現在、SPピグ内のレイアウトはどのページも大体同じなので、マイページとフォーム要素を抜粋して使っているプロパティやセレクタの中から主要なものをざっと並べてみました。

HTML5やCSS3で追加されたものをあちこちで使っています。
PCサイトを作るとき "IEが対応してないから" と使うのを避けてしまいがちなセレクタも
スマートフォン相手だとあまり気にしなくていいので多用しています。

<img> の zoom:0.5 はRetina Display対策です。
devicePixelRatioが１より大きい機種で見た時ぼやけないように、倍のサイズで作った画像を縮小して表示します。（背景画像はbackground-sizeを使っています）

図には載せませんでしたが、きせかえやショップにあるカルーセルの横移動と、ガチャのアイテムを表示するときの演出はCSS3のアニメーションです。（この記事では触れていません）

CSSで描くグラデーション

ヘッダーとフッターのグラデーションはliner-gradientで描いています。
SPピグでは使っていませんが、円形グラデーションはradial-gradientで作ることができます。

gradientは画像モジュールなので、背景に指定する時はbackground-colorではなくbackground-imageになります。

linear-gradientは先頭(top)がグラデーション開始位置で、色と位置を指定する組み合わせをコンマでつなぐ書き方をします。
将来的にはこの１行だけで良くなると思うのですが、gradientに限らずCSS3のプロパティを使うときはベンダープレフィックスが必要です。
-webkit, -moz, -o, -ms にプレフィックス無しを加えて5種類。毎度書くのは面倒なので
Compassを使ってその手間を省いています。

横幅を超える長さの文字列を省略する

ピグでは主に長いニックネームを設定している人が対象になるのですが、
マイページのタイトルはサーバーの処理で、
ピグとも、つぶやき、グッピグ帳、おでかけなどではCSSで省略されます。

CSSでの省略は、横幅が定まっているブロック要素に
以下の３つのスタイルを指定することで実現できます。

spanやa要素などに使う場合はdisplay:blockが必要です。（inline-blockは×）

Data属性を使った背景の切り替え

マイページの背景は設定で変更出来ます。
また、PC版と同じように時間によって窓の外の景色が変わります。

次のソースはお部屋の背景を指定している部分を抜粋したものです。
背景の種類と時間帯をdata属性で指定しています。

今のところ設定できる背景は６種類。時間帯がそれぞれ３種類なので、
上記のCSSを合計１８パターン書く必要があります。
これを手書きするのは骨が折れるので、Sassの@forと@eachで作っています。

data属性だとIDやクラスで使えない値でもそのまま使えるのが嬉しいところです。
（セレクタはかなり冗長になってしまいますが……）

フォーム要素のカスタマイズ

SPピグではデフォルトUIのまま使っているフォーム要素はありません。
最初に全てのスタイルをリセットした上でピグらしいデザインにスタイリングしています。

appearanceはブラウザが提供する標準UIの外観を操作出来るプロパティです。
フォーム要素にappearance:noneを指定するとdivのようにまっさらな状態になりますが
border、background、テキストに関するスタイルなどはリセットされません。

一見ただの画像に見えるマイページの背景選択やショップにあるカルーセルの●はラジオボタンで作られています。
選択時はCSS3で追加された状態疑似クラスの:checkedを使ってスタイルを変えています。

フレキシブルボックスが便利すぎてヤバい

ブラウザの実装具合がまだ揃ってないフレキシブルボックスレイアウトモジュール。
スマートフォン版ピグのブラウザは対象がWebkitなので遠慮なく多用しています。

使い方はとても簡単。
要素をdisplay:boxにするだけです。

フレキシブルボックスの例１：フッター

フッターは右寄せで３つのアイコンが並んでいるだけのものですが、
このデザインになる前は等間隔にアイコンが並んでいました。

フッターのHTMLはリリース当時から変わっていません。
以下は簡略化したソースです。メニューではよくあるコードだと思います。

<ul>にdisplay:boxを指定しています。
display:boxで検索をすると段組レイアウトを作るサンプルが上位にヒットしますが、
floatを使っていたものにはほとんど使えると思います。

<li> に指定してあるbox-flexは伸縮比率を指定するプロパティです。
比率の指定なので中に入るテキストや画像の大きさによって微妙にサイズが変わるんですが、
中身の大きさを統一すれば要素が増減しても自動で等間隔になります。

改修後の右寄せレイアウトは、box-packとbox-flexの値を変えただけです。

フレキシブルボックスの例２：左にサムネイルがあるレイアウト

こういうレイアウトってスマホだとよく目ににするんじゃないかと思います。
SPピグではピグのサムネイルが出るものと、内容を表したアイコンが出るものがあります。
設定ページなどにはテキストの画像だけを使ったリストメニューもあります。

上の画像をよくみると…コンテンツの少ないものが縦方向にセンタリングされていますよね。
テーブルセル以外の要素で縦中央に配置したい時に使える方法って、

• marginやpaddingで調整
• display:table-cell; vertical-align:middle
• height:100px; position:absolute; top:50%; margin-top:-50px
• 全部画像にする

これくらいでしょうか。
横方向のセンタリングに比べると格段に面倒くさいです。
でもCSS3の box-align なら簡単に揃え位置を変更する事ができます。

以下はサムネイルを表示するレイアウトの図解です。

次のソースは図解部分のHTMLとCSSを簡略化したものです。
テキストのカラーリングは画像とリンクしています。

ピグのサムネイルを表示しているときのサムネイルとコンテンツの親要素は<a>で、それぞれプロフィールとお部屋にリンクしています。
リンクが２つ並べたいときは<div class="listgroup">を親にしてフレキシブルボックスの対象を<a>タグにしています。

リンク先が１つしかないお知らせやショップ、サムネイルを持たない設定ページのメニューなどでは<li>直下に<a class="listgroup">があります。
box-alignを設定しているので、名前だけを表示する時などはサムネイルの高さに合わせてコンテンツがセンタリングされます。

listgroupクラス に display-box と box-align:center が設定されています。
box-align:centerはdisplay:boxの対象となる要素の縦揃え位置を指定するプロパティです。

box-alignの対象がインライン要素だと特有の隙間が出来て若干上にズレるので、
問題なければdisplay:blockにしておく方がいいです。

点線は最初倍のサイズの画像を border-image で表示していたのですが、Androidでの表示が汚かったため縮小なしの画像にしてbackground-imageに変えました。
ですがそう変更してもAndroidでは表示位置によって太さが変わって見える事があります。

フレキシブルボックスの仕様が変わりすぎてヤバい…

目が滑る長さのソースとともにフレキシブルボックスを熱く語ってみたのですが……、
W3Cのドラフト上では display:box から display:flexbox に変更されていたりします。

• display:box →　display:flexbox
• box-align →　flex-align
• box-flex →　flex()
• box-pack → flex-pack

現時点でflexboxの方に対応しているブラウザはないですが、
前に書いたソースで使ったプロパティはもうドラフトにありません……。

なので、ここに書いたソースはブラウザの対応が始まったら陳腐化すると思います。
それがいつなのかはさっぱり分からないですが……フレキシブルボックスを使った覚えがある人は頭の隅に入れておいた方がいいでしょう。

とはいえ、不便だったことが便利になっていくのは喜ばしいことですよね。
仕様変更やブラウザの実装差に振り回されるのは大変ですが、
これからも変化を追い続けて行こうと思います。

みなさんも、 「iPhoneのゲームアプリ、1ヶ月でつくって☆」なんて言われること、よくありますよね！？

もしなくても、ツールを使ってデザイナーもデベロッパーも効率よくプロジェクトを進められたらいいですよね。

今回はiOSのライブラリ「cocos2d」を使ってアプリを作成する場合に役立つツールを、 「COINPLAZA」の制作事例をもとに、紹介いたします。

「cocos2d」とは？

「cocos2d」とは、iOS（iPhone／iPod touch／iPad）やMac OS X向けのゲームなどで、グラフィカルなアプリ開発をするためのライブラリです。

構文がActionScriptsに近く、Flashを触っている人でしたら比較的容易に使えます。

cocos2dに関しては「PiggをiPhoneアプリで動かすまで」をお読みください。

以上、簡単ですが私達が活用してるツールを紹介させていただきました。

資料

・cocos2d

・コインプラザ

私がこのチームに配属されよく聞かれるのが、「ブログで何をデザインするの？」っという事です。おそらくブログという完成されたサービスの中で、何か新しくデザインする事があるのか？っと言う質問だと思うのですが、完成されたサービスだからこそ時流に合ったサービスを提供できているか、日々クオリティーに目を光らせていると言う訳です。

具体的には、ブログエディタをはじめとするプラットフォームの改修やSNSとの連携、スキンの量産などありますが、今回は改修について触れたいと思います。

改修と言っても大規模なものから小規模なものまであります。大規模なものは現在作業中なので小規模な改修について書きたいと思います。

ヒートマップ

小さな気遣いが、時に大きく利便性を高める事があります。これは大変難しいことです。その気遣いに気がつく為のツールとして、ヒートマップがあります。

ヒートマップとは、Webサイト内でユーザーが注目をしている部分を色分けし、視覚的に行動をとらえる事の出来るツールです。レイアウトデザインやインターフェイスが効果的に使われていつかなどを検証する為に用いられます。多くの場合はサーモグラフィーの用に注目が集まった部分が熱を帯びた色で表示されます。

Amebaサービス内のページでもまだまだ研究段階ですが、改修やリニューアルの参考資料の一つとして使用されています。

実験的に用いた例

「百聞は一見に如かず」と言う事で実際の画面をお見せしたいと思います。



ヒートマップを見る限り、コンバージョンボタンや見出しに注目が集中していることがよくわかります。因に、マウスの軌道の83～7%は視線の動きと同じといわれています。

今回の参考ページではブログサービス内の、ある機能の手順を解りやすく説明する事が目的です。実際にユーザーの行動をチェックしてみましょう。



懸念された点は上記画面内の【A】の部分になります。「機能の入り口部分が、いまいち認識されていないのでは？」と言う声があがり改修することにしました。確かに見出し以下のフローが無視されているに見えます。

早速改修へ…

改修はそれぞれの画面キャプチャを均等に配置し、マウスの軌道が集中する中央に“機能のアイコン”を配置しました。


※画面は改修前後の土日に測定したものの比較です。

すると…
中央にマウスの軌道が集中しています。アイコンに注目しながら緩やかにスクロールしている様子がうかがえます。
右下の画面キャプチャ内の“適用ボタン”にまで視線をおくる余裕も感じられます。
少なくとも以前よりは目に留まるようになったと言って良いのではないでしょうか？

今回はクリックテールを使ってみました。

数あるヒートマップツールの中でも今回は“ClickTail”の使用例を上げてみました。ClickTailでは、クリックされてた部分だけでなくマウスカーソルの起動を録画し、指定の日にちや期間事の測定データを閲覧する事ができます。ヒートマップの他にも…


などのツールでも測定可能です。

今後のUI改善

このように私たちは、毎日たくさんの人が訪れ、愛用され続けてきたアメーバブログをより楽しく使っていただけるよう、日々小さな所から改善を模索し続けています。

今回はランディングページでの事例でしたが、プラットフォームUIについても改修を行っていますので近々お見せできれば良いなと思っておりますのでご期待ください。

因に、普段の私はブログスキンの生産も担当しています。是非お気に入りのデザインを探して、お楽しみいただきたいと思います。最後まで読んでいただき、ありがとうございました。

http://ameblo.jp/

今回は、アメーバピグのアイテム制作におけるレギュレーションについてお話させて頂きます。
スピード感が大事だと言われて久しいwebサービス制作で、リリースから現在1000万にのぼるピグユーザーの皆様の期待に応えるべく、アイテムやエリアを制作するイラストレーター・デザイナーは総勢50名を超える人数となっております。

リリース当初は予想だにしなかった大所帯となったピグチームですが、ユーザー様からご覧になるピグのイラストレーションはあくまで「同じ人が描いたもの」に見えるよう配慮しなければなりません。均一なテイストのイラストレーションを提供する為に、チーム内での取り決めをいくつかご紹介したいと思います。

テイスト、世界観の分析

まず初めに行ったのは、ピグのイラストレーションの成り立ちを分析するところからでした。
ピグのテイストは当時の立ち上げメンバーが、直感的にカワイイ、皆に愛されるイラストの見せ方をいくつかの試作を経て完成しました。このプリミティブなかわいらしさや魅力を常にキープするためにはイラストの特徴を捉え、傾向を共有することが運用チームの我々としてまずやるべき仕事でした。

キャラクターと空間の傾きの違い




上の図は、ピグの立っている世界の傾き、いわゆるクォーター・ビューと呼ばれるものの角度、その床面の傾きとピグの各パーツの傾きを示した図です。この図からわかるように、ピグ自体の向きは、床面の視点と完全に異なる角度の視点で描かれた事がわかります。
具体的には、

・ピグのほうが空間よりも正面を向き、視点もやや見下ろした印象。
・空間に関しては傾きが均一（アイソメトリック図法）なのに対し、
　キャラクターは爪先～肩～顔と、傾きが変化している

等の点が挙げられます。
また、下の図では、前向きと後ろ向きの状態での体の向きに差があることもわかります。



これらの差分はピグが

①着せ替えサービスとして購入したアイテムをより見栄え良くするため
②コミュニケーションツールとして表情を認識し易くするため

等の配慮により導き出された結果だと伺えます。結果、この魅力を担保しながら運用する為には

・きっちりと明言化したガイドライン制作は現実的でなく、
　ある程度の振れ幅は容認しつつ制作する必要がある。
・ニュアンスを説明するための事例集によって管理することが適切である。

ということも明確になってきました。

運用時に様々なシチュエーションの家具や着せ替えアイテムと組み合わせる上で、このギャップをふまえて自然に見せる工夫が必要となります。下の図は、カチューシャ部分を同じパーツで使い回さず前後のパースを描き分けることを指示しています。



下のアイテムでは、トナカイの角の角度、前後での耳の見え方などに違いがあると思います。

ピグの体系に合わせる

ピグのアイテム制作時には、参考資料として沢山の写真画像が必要となる事が一般的ですが、その際リテイクになるケースで多いのが、家具アイテムのディフォルメ感の違いです。


上の図は、カジノエリアのリリース時に制作されたオープンカーのリテイクプロセスです。リリースされたデザインは一番右。最初に描かれたのは左となります、左の２台もイラストレーションとしては見応えがあり、造形的なクオリティーも高いのですが、ピグの世界観の中ではどうしてもシリアスな印象になってしまいます。

また、下の図のはカリブエリアの家具ですが、資料写真の印象に引っ張られて実際の人間のような８頭身の比率になってしまい、テーブルの天板の高さがピグの目の辺りまで高くなってしまっています。

右のようにピグの比率に合わせることで、自然と家具にもかわいらしさが吹き込まれます。

最後に個人的な意見ですが、日本人はルネサンス絵画に代表される「まるで写真のよう」な密度のある写実的なイラストや絵画を好む、優れているとする傾向があり、実制作においても仕事量・密度で説得力を持たせて完成度を上げる描画スタイルの方が多いと感じます。
そのスタイル自体に問題がある訳では決してないのですが、アメーバピグに関しては当てはまりません。また、いわゆるヘタウマのような自由度の高いスタイルも、50人を超えるイラストレーターでシェアし運用するのは非常に困難です。どちらかといえばロゴのデザインに必要な造形力、適切な密度と時間をかけて選びこんだ少ないラインで情報を整理することが適切なのでは、と感じています。

今後の予定としては、違うシリーズのアイテムを重ね着出来るインナーやアウターのシルエットの規格を検討中です。

最後まで読んで頂き、ありがとうございました。
まだまだ改修する点は山積みではありますが、
日本一洗練されたアバターサービスにするべく頑張ります！