こんにちは。
AWAでプロダクトマネージャー兼インタラクティブアニメーターをやっている冨樫(@kokiiiviii)です。

今回はAWAのインタラクションについて書いていこうと思います。


AWAインタラクションの軸


いきなりですが、実はこのテーマは以前個人ブログで綴ったことがあります。
AWAインタラクションの主軸は『ギャップレス』


はい、そうなんです。
AWAのインタラクションを創るうえで一つのテーマとして置いていたのは

ギャップレス

です。

個人ブログの内容とかぶりますが、ざっくりまとめます。


◆ 現実世界の動きとアニメーションの間にギャップを作らない


現実世界では「後ろの模様の動きが遅いから、あれは遠くにあるものだ」なんて意識して理解してる人はいないと思います。
脳が無意識に理解している部分です。

ということは、アプリ内の動きを現実で目にしている動きに近づけるだけで、ページの構造を直感的に理解してもらうことができます。

パララックスやシャドウはまさにここに直結していて、これを正確に使うことは直感的なUIにするための最も簡単な方法と言ってもいいかもしれません。

AWAでもパララックス、シャドウを正確にアニメーションさせることに気をつけました。

またスクロールするにつれて背景にブラーをかける処理(Lively Blurと呼んでいます)も
近くにあるものに視点を合わせると、他の部分はボヤけるという現実世界の現象に合わせて、
プレイリストを見やすくするとともに視点の移り変わりをスムーズにしています。


◆ ユーザーの連続的な動作とアニメーションの間にギャップを作らない


"継続性"を保つことはアプリの使いやすさに直結する大きなポイントの一つだと思っています。

ユーザーが連続的な動作をするときには、無意識に思考の連鎖が起きています。

この思考の連鎖をなるべく保つようにすることで、スムーズに使えるアプリになっていきます。

これをただ切り替わるアニメーションにしてしまうと、
ユーザーの連続的な動作の間に、今までの行動とそれに関わる要素を脳が再構築する時間がわずかに生まれ、直感的でスムーズな操作がしづらくなってしまいます。

AWAではなるべく継続性を保てるようなトランジションになるように気をつけています。


◆ ユーザーの操作とアニメーションの間にギャップを作らない


ジェスチャーのスピードに合わせてアニメーションのスピードを変えるようにしています。

実はiOSの標準のアニメーションにも連動性は低く条件付きですが、
ジェスチャーの速さによってアニメーション速度を変える処理がわずかに入っています。

しかしながら、この連動性が低いとジェスチャーとアニメーションにギャップが生まれ、ユーザーの脳はそのギャップに気が向いてしまい、それまでの行動を忘れてしまいやすくなります。"継続性"を失うポイントとなります。

このギャップを無くすために、AWAのカスタムトランジションのほぼすべてにジェスチャーのスピードを考慮するための仕組みを入れました。


インタラクション専用アプリの開発


ではどのようにこのインタラクションを開発していったかというと、

AWAではストア版アプリとは別に、インタラクション専用のアプリを並行で作成し、確認が取れたものをストア版に徐々にマージしていくような形をとっていました。

その専用アプリがこの


AWA-IxD です。


例えば、HOME画面での横スクロール時に、
通常のデザインのまま実装すると左のようにノッペリとした画面になりますが、そこにパララックスエフェクトを加えることで奥行きを持たせ、より"背景"であることを直感的に理解する手助けをします。

左(または上):パララックスなし    右(または下):パララックスあり

この「パララックスエフェクトを加える」という部分をストア版のアプリよりも先行して実装し、確認するためのアプリがAWA-IxDです。


また、AWA-IxDは完全にインタラクションに特化させているため、サービスのシステム上の制約がほとんどない(一番良い)状態のインタラクションをまとめることが可能です。

そのためストア版にマージする際に、より洗練させたものも、取り入れるのが困難だったものも多数あります。


■ OSに最適化したトランジション

左(または上):AWA-IxD    右(または下):AWA (ストア版)

実はiOS版のプレイリストのトランジションはリリース直前までAndroid版のようにサムネイルを起点に広がって出てくるようなアニメーションでした。

しかし、iOSではエッジスワイプ(画面左端からスワイプ)すると前の画面にバックできるというのが、標準的な動作となっています。

もちろんこのアニメーションでもエッジスワイプすれば前画面に戻れるようにインタラクティブなトランジションにしていましたが、
より直感的にエッジスワイプで戻れることを伝えるため、リリース直前に現在ストア版に出ているようなiOSに最適化したアニメーションに変わりました。


■ 慣性を利用した下部コンテンツへのアテンション


AWAのHOME5画面(TRENDING / DISCOVERY / GENRE / MOOD / RADIO)
それぞれ下にスクロールすることができます。
iPhone6などの画面サイズであれば、下部コンテンツがチラ見しているためすぐに気付けますが、iPhone5のような画面サイズだとチラ見していないため、場合によっては気付けません。

また、この画面での主役はコンテンツであり、タイトル部分は一度わかってしまえばそこまで重要な要素ではありません。

そこでAWA-IxDではこの5画面それぞれで少しでも触れると、触れたときの指の速さを計測し、その慣性のようにコンテンツのトップが画面の一番上に自動的にFIXするようなインタラクションを加えていました。

しかし、このインタラクションの実装には複雑な制御と意図しない動作をさせる可能性などのデメリットの側面があったため、ストア版へのマージは控えました。


■ タイトルラベルのナビゲーションバーへのFIX


これは前述の連続的な動作の中にギャップを作らないための一つの方法です。

AWAではスクロールするともともと画面上に出ていなかったナビゲーションバーがフェードインしてくるマテリアルデザインに近い画面が多数存在します。

ただし、ナビゲーションバーには基本的にタイトルは文字のみで表示するため、突然フェードインしてくると何を表しているページかここだけでは理解しにくい側面があります。

そこで、元から画面上に出ていたタイトルラベルを継続利用して、ナビゲーションバーに自然にFIXさせることによって、その画面の意味を無意識的に伝えられるようにしていました。

例えばプロフィール画面の場合は、プロフィール画像の上にあるユーザー名のラベルがそのままナビゲーションバーのタイトルへと移るため、ナビゲーションのタイトルはユーザー名であり、この画面はユーザーのページであることが直観的に理解できます。

しかし、各画面に存在するナビゲーションバーに統一性を持たせることと、UIの階層構造を複雑にしないために、このインタラクションの実装は控えました。


Meaningful Animations


AWA-IxDには今後導入予定の新機能も入っているため、
ここでは一部のインタラクションしか取り上げられませんでしたが、

AWAのすべてのアニメーションにおいて意識していることは

Meaningful Animations
意味のあるアニメーション

にすることです。

Google Material DesignのガイドラインにはMeaningful Transitionsというものがありますが、AWAではトランジションだけでなく、すべてのアニメーションに対して意味のあるものになるようにしています。

インタラクションはその意味がそぐわないとユーザーの混乱を招く真逆の効果を与えてしまうものです。

一つ一つの要素の役割、それらを全体で見た時の役割、サービスの特性、
そのときのユーザーのアクションの意図を考えてアニメーションを付けていくことが
直感的でスムーズな使用を手助けするインタラクションに繋がります。


AWAではこれらのチェックをチーム全員で行い、納得するまで毎晩のように議論を重ねることで一貫性のあるMeaningfulなインタラクションになるように開発を続けています。

これからさらに改善を重ねていきますが、
インタラクションにおいては、なんとなく気持ちいいだけのアニメーションではなく、ユーザーの操作を手助けする意味のあるアニメーションになるように、まだまだ磨き上げていきたいと思います。


Thank you for your time.


AmebaアプリiOSエンジニアの木藤紘介です。
10月29、30日にサンフランシスコで行われたSwift Summitというカンファレンスに参加してきました。
今回はそのレポートを書かせていただきます。

Swift Summitの概要

Swift Summitはその名の通りSwift言語に関するカンファレンスです。
カンファレンスと聞くと堅い感じをイメージしてしまうかもしれませんが、実際に行ってみるとゆったりとした大きな勉強会のような雰囲気でした。

会場では積極的にコミュニケーションを取ろうとするエンジニアが多く、自分が知りたいことをどんどんいろんな人に聞く姿勢が印象的でした。



登壇者はSwiftに関する本を出版している方や、有名なライブラリの開発者、ブログが有名な方といったSwiftに精通している方々です。
1人20分から30分ほどの時間があり、初歩的な内容からコアな内容まで様々な発表がありました。
その中でも印象に残っているものをいくつかピックアップして紹介します。  

What I Learned From 55* Swift Standard Library Protocols



Swiftの標準ライブラリを参考にすると、protocolはこうあるべきであるというご自身の考えを発表されていました。
Swiftの標準ライブラリではprotocolは大きく分けて Can do タイプ, Is a タイプ, Can be タイプ の3種類あり、それぞれ -able, -Type, -Convertible を末尾につけた名前になっているようです。
また、Operations, Alternate views, Identity, Conversationはprotocolに含めるべきであるとおっしゃっていました。
適切なprotocolを書くためには世界中の様々なライブラリ、プロジェクトがどのようにprotocolを使っているかをたくさん読むことが大事だと強調されていました。

WWDC2015でもあったように、Swiftはprotocol-orientedな言語なので、protocolを題材にした発表は個人的にも興味深く、参考になりました。  

Speaker Deck

Simple asynchronous Swift code with ReactiveCocoa 4



日本のSwiftの勉強会でもよく耳にするReactiveの話でした。
if let文をネストしてcompletionHandlerを返して... という今まで面倒でかっこ悪かったコードがReactiveCocoaを使えばfunctionalに書けるよという話から始まり、ReactiveCocoaは難しいけど、シンプルで便利であるということをコードを交えて発表されていました。

AmebaアプリではReactive関連のライブラリを使っていないので自分が普段触れることはありませんが、このようなライブラリの使い方や中身の実装を知ってトレンドを抑えることも大切だなと再確認しました。  

Speaker Deck

Simpler Tables with Values, Enums and Protocols



発表者が開発したStaticというUITableViewに関するライブラリの紹介がメインの発表でした。
StaticはUITableViewにおけるMVVMの実現を目的に作られています。
UITableViewと言えば、UITableViewDelegateとUITableViewDataSourceのコードでViewControllerが太ってしまいがちですが、MVVMで実装することでこの問題を解消できます。

Amebaアプリでは弊社の@nghialvが開発したHakubaというUITableViewに関するライブラリを使っていますが、このライブラリも同じようにMVVMパターンを使ってUITableViewを実装することができます。
単純でシンプルなUITableViewCellがメインとなるUITableViewを実装するならStaticでもいいですが、カスタムなUITableViewCellがメインとなるUITableViewを実装するならHakubaの方が優れていると感じました。  

How to Build a More Compelling Watch App


Swift云々ということよりも、どのようなwatchアプリがよりユーザーに使われるのかということについての発表でした。
内容はwatchアプリ制作の基礎的な内容がメインでしたが、watchアプリのキーとなるのはアニメーション、音声入力を含む入力、デバイス間コミュニケーション、アクセシビリティだとして、コード付きでで説明されていたので、とても分かりやすかったです。

ちょうど最近watchOS 2を触ってみたり簡単なアプリを作ってみたりしていたので、内容がとても頭に入ってきていい勉強になりました。

スライド

Bring your apps to the big screen

これもSwiftの話というよりは、tvOSの初歩的な内容の紹介でした。
tvOSは触ったことがなく、何も知らない状態でこの発表を聞きましたが、意外と簡単に開発できそうだなという印象でした。
発表者も、UIKitを知っていればtvOSの開発は簡単に始められるとおっしゃっていました。

Apple WatchやApple TV (tvOS)などの新しいデバイスに対応するかどうかはプロジェクト次第ですが、それに関わらずエンジニアとして新しい技術に挑戦しておいて損はないと思うので、新しい技術にもっと挑戦していこうと思いました。  

Speaker Deck

Swift Summitを終えて

アメリカに行ったことすらなく、海外カンファレンスに参加するのも初めてで行く前はとても不安でしたが、実際に行ってみると様々な国のiOSエンジニアの考えや技術に触れることができ、とても学びが多いイベントとなりました。

Swiftに関する新しい学びがあったのはもちろんですが、一番感じたのは、日本も世界で戦える技術力を持っているということです。

今までは海外のエンジニア、特にシリコンバレーのエンジニアは自分とは比べものにならないくらいすごいエンジニアなのだと勝手に思っていました。
しかし、実際に会場のエンジニアの発表を聞いたり話したりしてみると、自分たちと同じ問題に頭を悩ませ、自分たちと同じ疑問を持っていました。

もちろん技術力が高いエンジニアばかりでしたが、日本にも技術力が高いエンジニアはたくさんいるので、日本でも世界と戦えるプロダクトは必ず作ることができると確信しました。

そして自分もそんなプロダクトを作り上げられるエンジニアになるために、日々励んでいきたいと思います。
こんにちは。
アメーバ統括本部でウェブアナリストをしている枝川です。

アメブロにGoogle タグマネージャを実装をしてみて、特に気に入った機能や設定をGoogle Analyticsとの連携に絞って紹介させていただきます。

Google タグマネージャとは?

Google AnalyticsやGoogle AdWordsなど、さまざまなツールのタグを一元管理することができます。
サイト上の管理画面から簡単に変更を加える事もできるので、HTMLやJavaScriptなどのコード修正とリリース作業が軽減されます。
より詳しく知りたい方は、「Google タグマネージャ ヘルプセンター」をご確認ください。

お気に入り機能紹介

1.変数でトラッキングIDを管理する
変数にGoogle AnalyticsのトラッキングIDを保存します。
仮にトラッキングIDを変更することになっても、この変数のみを変更するだけで済むのがメリットです。
全ファイルからGoogle AnalyticsのトラッキングIDを検索・置換、大量のファイルのレビューが必要なくなり、作業工数の大幅削減につながります。




2.ルックアップ テーブルで条件によって値を変える
条件によって値を出し分けした変数を作ることができます。
サブドメインによって、トラッキングIDを変える。ということも可能になります。
これはかなりお気に入りです。

■{{Page Hostname}}によって、トラッキングIDを出し分けするサンプル
種類:ルックアップ テーブル
変数:{{Page Hostname}}
入力1:ameblo.jp
出力1:UA-11111111-1
入力2:s.ameblo.jp
出力2:UA-22222222-2
入力3:official.ameba.jp
出力3:UA-33333333-3



3.JavaScriptが管理画面で使えちゃう
カスタム JavaScriptは、JavaScriptで取得できる値を変数に保存することができます。
ユーザーエージェント情報を変数に保存して、ページビューのセカンダリディメンションとして計測することもできます。

■ユーザーエージェントを取得するサンプルコード
function() {
  var ua = navigator.userAgent;
  return ua;
}
※functionを使って、returnで値を返す必要があります。




4.とりあえずdataLayerに
Google タグマネージャの管理画面だけでは取得できないデータは、グローバル変数のdataLayerという名前の配列にpushします。
ページの特定位置までスクロールしたときに、イベントを発火させたいときなどはdataLayerに必要な情報を送らなければなりません。

Google Analyticsのイベント以外にも、カスタムディメンションなどにページやユーザーに関する属性情報を付与したい場合も、dataLayerへ値を送って管理画面で設定することも可能です。

■イベントを取得するサンプルコード
dataLayer.push({
  'event': 'analyticsEvent',
  'eventCategory': analyticsCategory,
  'eventAction': analyticsAction,
  'eventLabel': analyticsLabel
});




5.sampleRateもできる
Google Analyticsだけでは、該当ファイルのトラッキング コードにsampleRateをセットしなければいけませんでしたが、Google タグマネージャなら管理画面の設定だけでできます。

頻繁にsampleRateの値を変えることは望ましくないと思いますが、PV数の大幅な増減があっても、迅速に対応することができます。

■トラッキング対象ユーザーの割合を80%に設定
タグ>その他の設定>設定するフィールド
フィールド名:sampleRate
値:80



6.デバッグが強力
Google タグマネージャの変更を本番に公開する前に、プレビュー(動作確認)は必須です。
初めにプレビューボタンを押し、変更内容を反映するために更新のテキストを押すと本番公開する前に、ブラウザ上で動作確認をすることができます。



デバッグ画面一番左のSummaryで、Pageviewやgtm.click(クリック)の適用状況が確認できます。
Tagsは、ページビューやイベントが計測できているかが確認できます。計測できている場合は、「Tags Fired On This Event:」に管理画面のタグで作成した内容が配置されています。
逆に計測ができていないタグは、「Tags Not Fired On This Event:」に配置されます。
計測できてないタグをクリックして詳細をみると、どこが条件と合致せずに計測できていないかが分かります。
赤いバツになっているところが計測の条件に合致しなかったところです。

Variableで、変数にどのような値が入っているか、Data Layerで、dataLayerの中に何が入っているかが確認できます。

これらを駆使して、どこの設定が間違っていて計測できていないかをデバッグすることができます。
確認して、問題がないようであれば公開しましょう。



7.Google タグマネージャの拡張機能も使える
Google Chromeをお使いの方なら、Tag AssistantGTM Sonarという拡張機能がオススメです。
Tag Assistantは、どんなタグが実装されているかがわかり、簡単なコーディングミスを検知してくれたりします。
GTM Sonarは、gtm.linkClick(a要素のクリック)をデバッグしたいときに使えます。
Link Click Listenerにチェックを入れて、Switch Onにすると、a要素をクリックしてもページ遷移がしなくなり、リンククリックのイベントをデバッグできるようになります。


最後に注意点

イベントをたくさん計測しようとすると、タグ・トリガー・変数それぞれが乱雑になりがちです。しっかり整理するためにも、うまくフォルダを活用しましょう。

Google タグマネージャの導入を検討している方に、少しでもお役に立てたのであれば幸いです。

素敵なGoogle タグマネージャライフを。
はじめまして。2015年度新卒入社の森下(@morishitter)です。
今は755のフルリニューアルに向けて、Webフロントエンドの開発を担当しています。

その傍らでOSS活動も行っており、本エントリーで紹介するPostCSSは、GitHub上で僕がメンバーの1人でもあるプロジェクトです。

PostCSSとは

postcss_logo

PostCSSはNode.js製のCSSのパーサーで、そのAST(パース結果のJSオブジェクト)を操作するための便利なAPIを提供しています。PostCSS自体が提供する機能はたったこれだけで、非常に小さいライブラリです。

ASTを操作し、CSSを変換する処理はプラグインが担っていて、開発者はPostCSSのプラグインを書くことで独自のCSSの変換処理を行うことができます。

このようなプラグイン等を含めたエコシステムのことをPostCSSと呼ぶことが多い気がします。

有名なPostCSS製ツールの紹介

実際のサービス開発の現場では、効率のより開発を行うためにPostCSSのプラグインを組み合わせて使うことになります。
そこで、有名なPostCSSのプラグインをいくつか紹介したいと思います。

Autoprefixer

Autoprefixerは、各ブラウザで先行実装されていたり、独自の拡張のプロパティーに付けられる識別子である、ベンダープレフィックスを自動で付与してくれるツールです。
Autoprefixerは各ブラウザのCSSのプロパティー等の対応状況をまとめている「Can I Use」というサイトのデータを参照しています。

開発しているサービスで対応したいブラウザのバージョンをAutoprefixerで指定することで、適したベンダープレフィックスを付与でき、非常に便利なツールです。(余談ですが、PostCSSは元々はAutoprefixerを作るために作られました。)

input:

.selector {
  display: flex;
}


yield:

.selector {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flex;
  display: flex;
}


cssnext

cssnextは、現在策定段階でブラウザが未実装のCSSの記法を、今のブラウザが解釈できるようにトランスパイルするツールです。
cssnextを使うことで、
  • Custom properties & var()
  • Custom selectors
  • Custom media queries
  • media queries ranges
  • color()
等のCSSの新しい機能を先取りすることができます。

実際にブラウザで使えるようになるよりも先に新しいシンタックスに触れられるのはとても良いことだと思います。

cssnextはいくつかのPostCSSのプラグインをまとめたもの(Autoprefixerもcssnextに含まれている)であり、中には標準の仕様通りに実装されていないものも含まれます。

なので、cssnextを使うときも他のSassやStylus等のCSSプリプロセッサーを使うときと同様に、コンパイル後のCSSがどうなっているのかを気にして使うべきだと僕は思っています。

root {
  --mainColor: #6ea222;
}

@custom-media --mobile(width <= 640px);
@custom-selector :--heading h1, h2, h3, h5, h6;

.post-article :--heading {
  color: color( var(--mainColor) balackness(+20%) );
}
@media (--mobile) {
  .post-article :--heading {
    margin-top: 0;
  }
}


stylelint

「まだCSSLint使ってるの!?」

stylelintはモダンなCSSのLintツールです。
Custom propertiesやcalc()等のCSSの記法にも対応しているので、cssnext使っているのならstylelintを使った方がいいと思います。

cssnano

cssnanoはCSSのminifyツールです。
いくつかのPostCSSのプラグインで構成されています。

CSSOはメンテナンスが完全に止まっているので、CSSOを使っているのならcssnanoに乗り換えてみても良いかもしれません。

ここで紹介したPostCSS製ツールは、有名でかつ開発が活発なものです。

どれも比較的新しいツールなので導入するのを躊躇うかもしれませんが、もしバグを見つけたとしてもissueを立てれば直してくれるでしょう。

また、PostCSSとその周辺ツールについて疑問があれば(英語ですが)Gitterで質問すればすぐに返答がもらえます。
日本語では僕にリプライして頂けると答えられるものは答えます。

ここで紹介した以外のPostCSSのプラグイン、ツールはPostCSS.partsというサイトで確認することができます。

現在登録されているものだけで約100個のプラグインが作られており、エコシステムとして順調に成長しているように思います。

最後に

最後に、実際に今755のリニューアルで使用しているPostCSSのプラグインの一覧です。
  • cssnext
  • stylelint
  • postcss-reporter
  • postcss-flexbugs-fixes
  • postcss-style-guide
CSSプリプロセッサーとしてcssnextを採用していて、そのコードのLinterにstylelintを使っています。
postcss-reporterはstylelintの出力を読みやすくするために使います。
flexboxのバグを解消するためにpostcss-flexbugs-fixesを使っています。
また、postcss-style-guideはスタイルガイドジェネレーターです。
スタイルガイド駆動な開発をしています。

PostCSSを使うと、自分が必要な機能だけをプラグインを読みこむことで使うことができます。Sassを使っているけど「@extendや@mixinは管理できないから使っていない」、「@importと変数定義だけできれば…」と思っている人はPostCSSを使っても良いと思います。

本エントリーで少しでもPostCSSに興味を持って頂けると幸いです。
こんにちは。タクスタでフロントエンジニアをしている今井(@imakei_)です。
現在リニューアルしている"宅スタ"、あたらめ"takusuta"でweb開発を行っております。
(リニューアル詳細はこちら)
今回はtakusuta(https://takusuta.com)で用いてるJavaScriptライブラリーRiot(http://riotjs.com/)をテーマに書きたいと思います。

Riotとは

A React-like user interface micro-library

と公式サイトにもあるように、React(https://facebook.github.io/react/)のようなUIライブラリーです。ビューに特化しているライブラリーで、Reactのほか、Polymer(https://www.polymer-project.org/1.0/)やVue.js(http://vuejs.org/)といったものと比較されることが多いです。
その特徴はなんといってもそのサイズで、わずか12.5KBと超軽量です。Polymerの138KB、Reactの119KBと比べるとその軽さが際立ちます。
(各ライブラリーのサイズはRiot公式サイトより引用)

軽量だからできることが少ないと思われるかもしれませんが、Server-Side Renderingまでこなすパワフルなライブラリーとなっています。

今回はRiotの超入門としていくつかの構文や文法の紹介をしたいと思います。


超入門

Riotでは独自タグを用いてコンポーネントベースで開発していきます。
ではさっそくいつもの。

hello-world.tag
<hello-world>
  <h1>Hello, World!</h1>
</hello-world>

ReactがJavaScriptの中にHTMLを書くようなものだったのに対して
RiotではHTMLの中にJavaScriptを書くようなイメージですね。

マウントは以下のようになります。

index.html
<body>
  <hello-world></hello-world>

  <script src="riot+compiler.min.js"></script>
  <script src="todo.js" type="riot/tag"></script>
  <script>riot.mount('hello-world')</script>
</body>



簡単ですね。HTML,CSSを触ったことある人であればすんなり理解できると思います。

上記ではブラウザ上でコンパイルするサンプルになっていますが、
事前にコンパイルすることもできるので興味がある人は詳しく調べてみてください。


引数

上記のコードを少し変更して見ます。

hello-world.tag
<hello-world>
  <h1>Hello, { opts.user }!</h1>
</hello-world>
index.html
<hello-world user="Abema"></hello-world>



Riotではカスタムタグの属性として引数を渡すことができ、
optsという変数でそれらにアクセスしています。
また、{ }で変数を簡単に出力できます。


スタイリング

hello-world.tag
<hello-world>
  <h1>Hello, { opts.user }!</h1>
  <style>
    h1 {
        color: red;
        border-bottom: 1px solid #E0E0E0;
    }
  </style>
</hello-world>


上記のようにカスタムタグ内にstyleタグで記入できます。


イベントハンドラ、繰り返し

では、簡単なアプリケーションを作ってみたいと思います。
テキストを入力するとリストになる、簡単なTODOリストを作りたいと思います。

todo.tag
<todo>
  <form onsubmit={ add }>
    <input type="text">
    <input type="submit" value="追加">
  </form>

  <ul>
    <li each={ item, i in list }>
      { item }
    </li>
  </ul>

  <style>
    /* 略 */
  </style>

  <script>
    this.list = [];

    add(e) {
      var input = e.target[0];
      this.list.push(input.value);
      input.value = '';
    }
  </script>
</todo>



scriptタグの中でLogicを書くことができます。

ここではTODOのアイテムを管理するlistと、それに値を追加するadd関数を用意しました。

イベントハンドラでDOMイベントが起きた際に呼ばれる関数を簡単に設定できます。  
onsubmitに先ほど用意したadd関数を設定しています。

繰り返しはeach属性で行います。each属性を持った要素は配列の要素の数だけ繰り返されます。上記のプログラムの場合、listの要素数だけ繰り返され、listが要素が変更されると
自動的に新しい要素が追加/削除されます。

今回のTODOリストのソースコードは下記においておきますので参考にお使いください。
https://github.com/imakei/riot-todo-smaple

タクスタでのRiot


takusutaでは専属のweb開発部隊がいません。それでも流入経路の確保やSEOなどの観点からweb開発は外せませんでした。その中で見つけたのがRiotで、軽量ライブラリーであることに加えてサーバサイドレンダリングが可能でSEOに強く、そしてなんといっても学習コストが非常に低かったため、すぐに採用しました。Riot未経験だった自分もすんなり開発に入ることができ、非常に速度の速い開発ができていると思います。

また、現在爆速でリニューアルしているtakusutaのwebサイトは、近日公開予定ですのでよろしくお願いします。


終わりに

最後少し早足になってしまいましたが、HTML/CSSとほんの少しのJavaScriptだけ  
簡単なアプリケーションを作ることができました。
これを機会にエンジニアの皆さんにはもちろん、デザイナーさんにも
Riotに関して少しでも興味を持っていただけたら幸いです。

---

takusuta - 見逃せないスクープから恋愛相談までLIVE中継
iOS App
Android App
PC(https://takusuta.com)

---

タクスタ
今井(@imakei_)
こんにちは。
アメーバ統括本部にて、キュレーションメディアのクリエイティブディレクターをしていた見上です。
(異動して現在はスタートアップ見てます)

いまから一年半ほど前に、キュレーション事業部の立ち上げが決定し、Spotlightをはじめとする多くのキュレーション・バイラルメディアや、プラットフォームであるみんなの編集局の開発がスタートしました。
現在は、by.SGAMYMIRUYOなどのメディアも運営しています。

いまや、どのSNSにも流れてくるキュレーションメディアの情報ですが、その多くが現れては消えていく中、
日本最大級の規模に成長したSpotlightを例に、キュレーションメディアの開発についてお話ししたいと思います。


キュレーションやバイラルとは?

なにがどう違うの?と思う方も多いと思うので簡単に言うと、

キュレーションメディア・・・さまざまな場所に散らばった情報を整理(編集)し新たな価値を付加してユーザーに提供するメディア。
バイラルメディア・・・はTwitterやFacebookなど、SNSの拡散力を利用し、話題性のあるコンテンツを短期間で爆発的にリーチさせるメディア。

こんな感じで、Spotlgihtはこれらを兼ね備えたメディアとして存在します。
どちらかというとバイラルメディア感が強いかなと。

Spotlgihtとは

さて、Spotlightのサービスコンセプトは、
「最新のトレンドからエンタメ・社会問題に至るまでの幅広いジャンルで、人々の心を動かすコンテンツを発掘するWebメディア。」
育児、グルメ、ライフハックなどのお役立ち情報や、ちょっとムフフな記事まで、あらゆるジャンルの情報にあふれています。


インターフェイスにおいては、これらを実現しコンテンツの魅力を活かすため、余計な装飾を極力省く“引き算のデザイン”を意識しています。
どんなジャンルが入っても読みやすいよう堅めのスタイルをベースに、色使いなどの遊びを加え、万人に受け入れられるデザインを目指しました。

キーカラーは、オールジャンルを受け止めターゲットを狭めることのない広がりをイメージし、濃いめの黄色を採用。
ロゴについては、メディアが大きく成長することを見越して、シンプルさを追求し、黄金比を用いたアイコンを制作しました。


誰が書いても読みやすく

記事詳細はユーザー離脱させることなく、コンテンツを最後まで見せるため、フォントの強弱や各パーツの余白感の調整に時間をかけています。
多くのライターが様々な記事を書くことを想定し、どんな記事に仕上がっても読みやすくなるよう、かなり練りました。


記事タイトルは印象強く伝わるよう大きめのフォントサイズに。
記事を構成する要素として、
・見出し
・画像タイトル
・出典
・リンク
・本文
・コメント
…など、多くのパーツが混在していますが、
テキストのサイズやウェイト、カラーで強弱をつけたり、パーツ間のマージンをたっぷりとるなどして、ユーザーがテンポよく読めるよう何度も組み合わせを検討し、最終的には数十パターンの組み合わせからいまのものに至りました。

また、バイラルメディアのキモであるSNSシェアボタンは優先度を高くし、記事を拡散するという概念を強調。
ページの上下に設置されています。


SNSアカウントのフォロワーを増やすことも重要視しており、運用の中では、フォロー導線も繰り返し検討されています。
(↑こちらのいいね訴求はどのメディアにも踏襲され、もはや業界スタンダードに…)

ブランド強化のタイミング

そして、リリースから数ヶ月がたち、ずいぶん規模も大きくなったところで、数あるバイラルメディアの中でも抜きん出た存在となるべく、その一手としてリニューアルの話が浮上します。
オーダーは、
「更に幅広いジャンルを網羅し、男性にも女性にも受けるメジャー感。」
要するに、全部。

もともとは男性寄りのイメージでしたが、ここで女性にも受け入れやすい柔らかさを取り入れました。
当初はプロデューサがきっちり作ったワイヤーを渡されたのですが、どうも納得がいかず・・・
デザイナー陣で検討した結果、Spotlightのブランド向上と認知に振り切る方針にシフトし、ワイヤーなしで進めることに。
担当デザイナーのディスプレイ前に、プロデューサーもデザイナーも集まって都度話し合いながら進めました。


Before
黄色と黒のコントラストがしっかり。フォントにも力強さがあり、男性的な印象。


After
全体的に黒の量を削減。フォントは游ゴシックを用いて中性的な印象に。
画像を大きく使い、多様なコンテンツがあるにぎやかさを演出。


更に、記事の詳細面ではサイドに回遊枠を設置した2カラムから記事のみの1カラムにし、記事に集中させる作りに変更。 これにより、読了率の向上につながりました。(ページ長いのでイメージは割愛。是非記事をご覧ください)

さいごに

Amebaのキュレーションメディアでは、多くの編集メンバーが日々大量の記事の運用をし、そのひとつひとつの記事をより多くのユーザーに届けるべく、開発メンバーもテストを重ねて地道な運用を続けています。
SNS上で流れてきたバイラルメディアを何気なく見ている方がほとんどだと思いますが、Spotlightに出会った時は、どうぞ、たくさんの記事を回遊してください笑。

この記事が気に入ったらSpotlightに是非いいねを
こんにちは!
アメーバブログでデザインを担当している、中 隆理(ナカ タカミチ)と申します。
先日、1pixelでpixateの紹介や操作方法を説明させていただきました。

今回は、「Ameba古着屋を作ろう!」という名目で行ったハンズオン社内勉強会での内容から、pixate制作で悩みそうなところを抜き出して紹介します。
なので、Ameba古着屋をダウンロードして実際に見ていただくか、pixateで制作したサンプルがあるので、pixateアプリのQRリーダーから読み取っていただくと、内容が把握しやすいと思います!

今回の内容

1. スクロールさせる
2. スクロールとアニメーションを組み合わせる
3. コンディション(if文)を使う

pixateの制作で、クセがあり、つまづくポイントになりそうという理由でこれら3つについて解説します!

制作の基本

pixateは、どんなインタラクションによって、どんなアニメーションが起こるのかを設定して制作していきます。

例えば、画像Aをタップしたら、画像Bを拡大させたいときには、

① 画像Aに「TAP」というインタラクションを設定
② 画像Bに「scale」というアニメーションを設定
③「scale」の条件設定で画像Aをタップしたらどれだけ拡大するかを設定

このように制作していきます。 

ちなみにインタラクション/アニメーションは以下を設定できます。

インタラクション
Drag, Tap, Double Tap, Long Press, Rotate, Pinch, Scroll

アニメーション 
Move, Scale, Rotate, Fade, Color, Image, Reorder(レイヤーの上下入れ替えができる)

1. スクロールさせる

pixateのインタラクションは、基本的にはインタラクションをさせたいレイヤーに設定すれば良いのですが、スクロールは違います。
Ameba古着屋のトップページの縦スクロールを用いて紹介します。

① 画像を表示したい領域を四角形で作る

・赤い四角形を「area_scroll_01」という名前で配置
(わかりやすいように赤くしているだけなので、プロパティの「Appearance」から色なしを選択)
・端末全体に表示したいので、四角形のサイズは画面と同じ

② スクロールさせたい画像を配置

・画像アセットページから画像をドラッグ&ドロップ
・四角形レイヤーと左上のポジションを合わせる

③ 四角形レイヤーを親としてグループ化

・レイヤー部分で、画像レイヤーを親となる四角形レイヤーにドラッグ&ドロップ


④ 親の四角形にインタラクションの「scroll」を設定

・インタラクションのパネルからドラッグ&ドロップ
・さらに今回はスクロールするたびに画面にフィットしてほしいので、アニメーション設定から「paging」を選択

これで完成です。
Ameba古着屋には他に3つのページがあるので、それぞれ同じようにスクロールを設定してあげましょう!

・レイヤー構造はこのようになっているはず

ちなみに、
親レイヤーよりも子レイヤーが、縦に長い時は、縦にスクロールし、横に長い時は、横にスクロールします。
ただし縦も横も親レイヤーより大きくなるとぐにょぐにょ動いてしまいます。
 
Ameba古着屋の横にスクロールするとページが切り替わる部分も上記と同様に制作できます。

① 各ページを準備し、ページ順に横に並べる



② area_flickという四角形レイヤーを画面と同じサイズで作る

・四角形レーヤーは赤い部分

③ 四角形レイヤーを親、各ページを子としてグループにする



④area_flickに「scroll」を設定


2. スクロールとアニメーションを組み合わせる

画面右上のインジケーターを、選択しているページと連動させます。
制作する上で、この様に考えるとわかりやすいかもしれません。

① インジケータの画像を配置する
・白い4つの点が並んだ画像と赤い選択しているページを示す画像の2枚を配置

② 赤い点のレイヤーにアニメーションの「move」を設定
 

③「move」のアニメーション条件設定を行う

・Based On部分では、どのレイヤーのどのインタラクションに対応させるかを指定
・area_flickは4つのページをまとめている「scroll」が設定されている親レイヤーのこと

Animatesの部分は3つ選択肢があり、私はこのように解釈しています。最初のうちはどれを選べばいいのか迷うと思います。
 

・Move toの部分の272という数字は、インジケーターのふたつ目の白い丸のx軸方向の位置を意味している
・ 赤い点の画像はx座標が258で配置されており、1ページ目→2ページ目にスクロールされる間に258→272へとx座標の変化を指定している

・条件設定下部の「+target」をクリックすると条件が追加できる
・ area_flickのスクロール量は今回はページにフィットするので、0,320,640,960の時しかなく、以下のようになる
※今回の画面は320×568で制作
0=1ページ目
320=2ページ目
640=3ページ目
960=4ページ目

 

3-1. コンディション(if文)を使う 

次は選択したページのタイトルを表示させます。こちらも先ほどと同じように、area_flickのスクロール量が0,320,640,960のときにタイトルそれぞれの不透明度を0or100に変更しています。

①4つのタイトルを配置し、それぞれにアニメーションから「fade(不透明度を変更できる)」を設定
 

②トップページ以外の3つ画像を不透明度0(opacity=0)にする



③「fade」の条件設定を行う

まずは最初に表示している画像に条件を設定していきます。if文を記入するので「With duration to final value」を選択します。 



・if文はルールがしっかりしているので、意外と難しくない
・書き方は固定で、
(数値を測りたいレイヤーの名前).(測定する値) 不等号 (指定する数値) 
ここでは「area_flick.contentX == 0」と記入する
・ contentX とは x軸方向のスクロール量のことで、「area_flickのx軸方向のスクロール量が0のとき」を指している 

・条件を更に追加し、スクロール量が0ではない時は不透明度が0になるように指定 

 
if文で測定できる値の種類


・測定できる値はこのようにたくさんあり、この中から適切なものを選択する 

if文で使える不等号の種類

・詳しくはpixateのユーザーガイドに書いてある

3-2. コンディション(if文)を使い、タブを表現

下側にスクロールするときだけ、タブが下に移動するようにif文を記入します。基本的には、アニメーションから「move」を選択して、スクロールの開始や終了を起点として移動させているだけなので、割愛します。

このように記入します。

意味は以下になります。

 

・velocityYはy軸方向の向きを測る事ができる

このようにしてタブの動きは表現できます。このようなスクロールに連動させる動きはよく使うことがあると思います。だいたいこんな感じの式なので、定番の式なんだ!くらいに思っておいてください!

最後に

今回は作り方を僕の方で勝手に決めていましたが、同じ見た目でもいろいろやり方があるので、どうしたらそう表現できるかを考えてみてください。

そして、とっつきにくい部分しか紹介していないので、全部が難しいわけではないです。やってみたら案外すぐ理解できる人も多いと思いますし、僕は結構楽しくて時間を忘れてやってしまいました。

最後まで読んでいただき、ありがとうございます!
こんにちは!
アメーバブログでデザインを担当している、中 隆理(ナカ タカミチ)と申します。

私は、pixateの紹介や操作方法、理解が難しいと感じた部分の説明などを2度に分けて行いたいと思います。
 今回は、制作開始までに必要な準備とツールの使い方を、作業を円滑に進めるためのポイントなどを含め説明させていただきます。

「pixate」とは

簡単に言うと、

「細かい動きまで作り込める、ネイティブアプリ向けプロトタイピングツール」

です。
そして、pixateを使用するメリットとして

「アプリなどの操作に対応するアクション(パーツの動きや形、色の変化など)を、ある程度簡単に実際の端末で再現できる」

この点にあると思います。

以前、所属していたモックテックという部署で、pixateでできることを探りながらデザインモックを制作したので、これを見れば多少はできることがイメージできると思います。

また、以下のことも知っておいたほうが良いと思います。
・制作したアニメーションをコードに変換できない
・使いづらい部分がなかなかある(UI説明の部分で記入します)
・pngしか使用できない

「pixate」を始める準備

必要な準備
pixateのPCアプリをダウンロード
(最近のアップデートでブラウザ上での制作ができなくなった)

wifi
(画面を端末で確認するにはおなじwifiにつなぐ必要がある)
※OS10.9以下だと端末接続がうまくいかないことがあるかも?
※android端末なら設定を行うとUSBで同期可能だそうです。

Xcode
(PC上でシュミレーションできる)
  
広い画面
(pixateの制作画面が拡大縮小できないので)

Retinaサイズの画像
(名前をわかりやすくつけると、pixate上で探す際に便利)

新規作成

ファイル選択画面と端末サイズ選択画面


1 ,左側の画面が出てくるので、「create a new prototype」をクリック。または、⌘+Nでも良いです。

2 , 名前を決めます。

3 ,右側の画面が出てくるので、 画面サイズを選択します。

また、保存したデータは「◯◯◯◯.pixate」という拡張子のファイルになります。 ダブルクリックで開けます。

 

制作部分のUI説明

全体の見た目


主にこの画面で制作を行います。

真ん中の部分をキャンバスと言い、画像などを置いていきます。
白い部分が表示エリアになり、端末で見える部分になります。

全体の見た目(画像配置時)


ちなみに実際に画像を配置した時はこのように上下左右にパーツが広がっていると思います。 この場合は横フリックでの遷移を表現したいので、画像を横に並べてあります。

画像配置は、表示エリア(真ん中の白い部分)に画像を動かして、遷移やアクションなどの連続性を表現するイメージ です。

なので、構造を意識した画像配置が大事です!

 
レイヤー 


赤と青のレイヤーを用意し、グレーのレイヤーを親としてグループ化してあります。


解説
・キャンバスに置いた画像などのレイヤーが並びます。

・グループは子にしたいレイヤーを親にしたいレイヤーにドラック&ドロップします。

右上の+ボタンで四角形が作れます。そして四角形をものすごくよく使います。

・レイヤーが動かしにくく、勝手にグループになったりします。下から上に動かすと割とマシです。

レイヤー横のボタンはキャンバス上での表示/非表示を切り替えます。なので、端末では上にあるレイヤーが見えています。


プロパティ


解説
・Positionは表示エリアの左上を座標の(0,0)としています。グループの場合は親レイヤーの左上が(0,0)になります。
 
・pixateのキャンパスは拡大できないので、画像の位置をあわせるときはプロパティで合わせたほうが早くて正確だと思います。 

・opacity(不透明度)を0にすると端末でも表示されなくなります。 

・Appearanceにある「色をつけない」をものすごくよく使います。四角形と組み合わせて空の領域を作れます。 

四角形の色は斜線アイコンで消す。




アクション

解説
・パーツの整列などが行えます。レイヤーを選択し、行いたいアクションを選択し、右向きの三角ボタンを押すと実行されます。

・タブの遷移やスクロールなど定番のテンプレートも作れるのですが、pixateを理解していないと変更しづらかったり、自分の作りたい構造と違う形になっていることも多いので、慣れてきたら見てみてください。

インタラクション / アニメーション 


2つはタブで切り替えられます。

インタラクションの解説
レイヤーに持たせたい要素をドラッグ&ドロップすると、そのレイヤーがそのパネルの機能を持ちます。
例えばTapをドラッグ&ドロップしたレイヤーはタップできるようになります。

・プロパティに選択しているレイヤーが持っているインタラクションが表示されます。

・スクロールは少し特殊で悩む人が多いと思うので、第2回で説明します。

アニメーションの解説
・どんな変化をさせたいかをレイヤーにドラッグ&ドロップします。
プロパティパネルの下のANIMATIONSという部分にドラッグ&ドロップしてもよいです。

アニメーション条件設定


UIの右下部分に、選択したレイヤーに付いているアニメーションが表示されます。
・条件の指定をして、どんなインタラクションがされたらどんなアニメーションを起こすのかを設定してきます。

ここで大事なことは

どのレイヤーがどんな動きをしたら、どのレイヤーがどのようにに変化するのかを分解して考える

ということです。
どんな良いアニメーションもシンプルな動きの組み合わせでしかないはずです。

そして、重要になってくるのがアニメーションさせる際の条件の設定になります。

条件の設定がpixateの1つの壁だと思っていて、その部分の理解が深まると、できることの幅がグッと広がると思います。

アニメーションの条件の付け方については、次回紹介したいと思います。

制作の流れとしては、

1 , 画像を配置し、配置の構造とレイヤーの上下関係や親子関係を整理する

2 , 何をしたら、どう動くのかを考え、レイヤーにインタラクションやアニメーションをつけて、条件を設定していく

これをモジュール単位などで繰り返し行なっていきます。 

アセット部分のUI説明

アセットページ


赤い丸が付いている部分のタブをクリックするか、画像を直接pixate上にドラック&ドロップした場合にこの画面になります。 

画像の追加はASSETSの+ボタンからでも可能です。

そしてアセット画面では、画像パーツをキャンバスに配置することができます。画像をpixateに追加するだけでは、キャンバス上には置かれていません。

リストになっている画像をドラック&ドロップして配置しましょう。

ヒント!
・あまり正確に配置できないと思うので、プロパティで数字を打ちましょう。
・アセットリストは名前順に並ぶので、ヘッダーやフッターなど構造ごとにわかり易い名前にしましょう。

今回はここまで

今回はpixateの表面的な部分や考え方を紹介しました。文字で説明すると、ちょっと複雑に感じるのですが、触りながら読むとすぐ分かると思います。

次回は実際にモック制作を行う際に、おそらくつまづくであろう部分の解説と私がよく使う技など、実践的な内容を紹介しようと思っております。

また、「pixate」以外にも「principle」や「flinto」などの細かいアクションが設定できるツールも登場していますので、興味のある方は是非触ってみてください。

最後まで読んでいただきありがとうございます!
こんにちは、始めまして!2014年度新卒入社の安田と申します。
現在は株式会社GOODROIDにて、主にカジュアルゲームのデザイナーをしております。

casual_title

昨今、AppStoreのランキングの上位を見ても、リッチなゲームに負けないくらい、カジュアルゲームの姿が見受けられます。
いざダウンロードしてみると、ちょっと笑えるものからドンずべりしているもの開発者の正気を疑うものまで…

casual_chichineko

『ちちねこぐらし』 開発者の正気を疑う例

今回はそのカジュアルゲーム開発の特徴を、CyberAgentグループでも特に異色な、GOODROIDの開発スタイルになぞってご紹介したいと思います。

短期間・少人数で作る!!

・基本的にプランナー・デザイナー・エンジニアの3人
 案件の規模にもよりますが、考えうる最小限の人数で開発しています。

・GOODROIDでは一人のデザイナーが2つの案件を並行して担当
 複数の企画で頭がこんがらがることも多々あります。

・理想の開発期間は、めざせ1.5ヶ月
 こちらも規模によりますが、サッと作ってサッと出すことが求められます。

casual_everyjump

『まいにちJump』は1.5ヶ月で完成しました。ちなみに昨日リリース、みんな遊んでね!

目に見える部分、すべて俺が作る!

普通の現場では、イラストレーター・デザイナー・アニメーター、といったようにそれぞれ分業されていますが、カジュアルゲームのデザイナーの理想は、その全てを一人ですることです。そんなカジュアルゲームの開発の流れをご紹介します。

①プランナーといっしょに、企画の世界観やテイストを決定する。
 時には自分が描いたキャラ発進で企画がスタートすることも。

casual_azarashi_rough

『ウチのあざらしちゃん』 キャラクターのラフと完成案。可愛くなってよかったね!


②アプリの拡散性や広告収益を考えつつ、世界観に合わせたUIを制作する
 ユーザーのSNSでの拡散が最重要!もやしはそれで、ノンプロモでも日本や台湾でバイラルしました。広告はバナー広告、インタースティシャル広告、動画広告などが主なものになります。

③エディタ(弊社ではcocosStudio)を使いUI・アニメーションを組み立てる
 アプリの完成図を頭の中で想像しながら、エンジニアが組み込むことも考えて素材を制作していきます。このゲームを作るにはどういう素材・動きが必要かを考えながら作ります。
 それが完成したら、下記のようなエンジニアに向けたデザインの仕様書をつくります。

casual_design_method

『まいにちJump』デザイン仕様書 こうしてエンジニアを手玉にとります。


④開発が終盤に差し掛かるとアイコンやストア画像、プロモーション用の画像や動画を制作。
 ストア周りの画像は直接DL数につながる超重要なところ。リッチなゲームと違い、ターゲットに一目でカジュアルゲームだと分かるようシンプルにつくる必要があります。

casual_jump_store

『まいにちJump』ストア画像 1枚目を見て、すぐにどんなゲームか想像できることが重要


☆なんなら自分でモックもつくるでー
 デザイナーでもプログラミングを少しかじれば、実機でメインゲーム部分が遊べるモックを素早く制作し、開発を円滑に進めることができます。

casual_coding

デザイナーが作ったモックのコードを参考にエンジニアに制作してもらう稀有な例。
でしゃばりすぎには注意しましょう

カジュアルゲーム開発には、こんなイイところが!!

人によって合う合わないが激しく分かれそうな、カジュアルゲーム開発。
『ゲームを作る』こと自体に興味があるひとは、非常に向いていると思います。

カジュアルゲーム開発のメリット
・このアプリ、全部俺が作ったで!!って言える。
・逆に言えば、クリエイティブは全て自分の責任!
・ゲーム制作に必要な全てのスキルが満遍なくつく。
・短いスパンで様々なテイストを制作できる
 ちなみに私が入社後1年半で関わった新規案件は6本!
・マーケティングにも関われる
 普段あまりデザイナーが関われない、お金の流れがわかる。
・この部分がヒットした、この部分がダメだった、など、SNSやレビュー欄からユーザーの生の声が返ってくる。

デメリットもあるよ
・一つの技術を集中して高めたいひとには向かない。
・基本的にシンプルなゲームループになったり、ユルい系・シュール系のデザインになってくる。
こんなもんを作ってて俺は大丈夫なのか…と人生の不安と戦いながら生きていかねばならないことも。

casual_faied


最後に!!

さてさて、これだけつらつら書いてきて、

『でもウチの部署、規模が大きいからエフェクトしか作る余裕ないょ・・』
『やってみたいけど、アニメーションとか作ったことないから無理だょ・・』

そんな人は、お家で自分で作ればいいじゃないですか。幸いネットに情報はゴロゴロ転がっています。そしてまったく自分がやってこなかった技術に関わってみるのは、クリエイターにとって良い影響になります。

私のように休日に趣味でひとり寂しくゲームをつくりましょう…

楽しく勉強でき、どれだけ自分に力がついたか試せるし、逆にそれが実務に活かされている部分もかなりあります。

個人的には、デザイナーが、ただデザインだけをする時代はとっくに終わったと思っています。
世の中には個人でカジュアルゲームを作って大ヒット、億万長者になる人もいます。

casual_final


そんな夢を見てあなたもカジュアルゲームを作ってみませんか??


GOODROIDデザイナー
安田 将(@sho_yasu)
こんにちは!アメーバ統括本部でデザイナーをしている石塚千裕(@pekep)と申します。
8月にリニューアルした「ラジ生?」のデザインを担当しました。

今回は新しい「ラジ生?」が生まれるまでの経緯やデザインのこだわりなどまとめさせていただきました。

ラジ生について


「ラジ生?」は誰でも気軽に本格的なラジオ放送ができるネットラジオ配信アプリです。

実は2015年5月にリリースしていましたが、再度デザインの見直しをすることになり、私は6月にサービスにジョインし、7月末にリニューアルデザイン版をオープンしました。


「デザインは振り切りたい」

プロデューサーからのデザイン要望として強く言われていたのが「ラジオ感をしっかり出す」ということでした。クリエイティブディレクターからも振り切ったデザインを作って、とにかくパターン出しをしようと伺っていたので、元のラジ生の世界観は壊す勢いでリニューアル案を考えました。

パターン出しの際、デザインも最終ゴールが決まっていなく、とにかく幅広い案を見たいとのことで、フラットからリッチなもの、ポップ、シンプル、おもちゃ、レトロ、近未来、ゆるい、などなど…とにかく数多くの案を出し続けました。

1番最初にユーザが訪れるホーム画面、そしてラジオ配信を行う放送画面、この2軸をしっかりと決め、他画面への展開を行っていきました。




デザイン案の作り方

まずは手書きでラフスケッチを描き大枠のイメージを固め、細かいディティールまで調整ができるPhotoshopでイメージを起こしていきました。ここでPhotoshopを使った理由としては、「とにかく沢山の案を出す」という、早さ勝負なところがあったので使い慣れているツールを選びました。

メインデザインFIX後は、デザインツールをSketchに切り替えて作業を行いました。
複数の解像度の書き出しが簡単にできることと、ページごとに管理でき、Illustratorのようなカンバス機能があるため、各画面ごとにデザインを俯瞰して見れるからです。


Sketchの使い方はアプリエンジニアさんにも展開し、マージンやフォント、カラー指定、画像の書き出しなどデザイナー側からの指定を待つ時間を軽減させ、スピード感高く作業を進めることができたと思います。

モックアップ確認はProttを使用しました。また別途動きが必要な部分はFlashでアニメーションイメージを作成しています。



より具体的に動きのイメージを伝えることで、実装に入る前に出来ることと出来ないことがはっきりと分かってきます。また問題点なども上がりやすく、デザインの大幅な戻りも防ぐことができました。


「リアル」にこだわったサービスの世界観



ホーム画面
アプリの第一印象を決める大事な画面です。ここでは視聴数の多い人気の番組が20件表示されます。
幅広く自分好みの番組を見つけられるよう、あえて細かい番組情報などは載せず、まずは放送を聴いてもらうということを重点に置いています。
画面下にラジオチューナーのようなデザインを置き、アナログで探しているような楽しさを残していて、この針の動きと同じようにリストも横にスライドするインタラクションにしています。


放送画面
一番悩んだ画面です。コンセプトにあるように誰でもラジオパーソナリティになれる、そして「声」のみ配信できる、ということを伝えるためマイクをメインに置く形で振りきりました。
放送者がラジオ放送に集中できるようにコメントはマーキーで流れるようにして一覧は別画面で展開するようにしています。
背景もラジオブースにいるようなリッチなデザインに仕上げ、実際のラジオ収録を意識した、とにかく「リアル」にこだわった画面となります。
また、声のログをとっている感を出すため、声音に反応するビジュアライザーも入れ、自分の声がしっかりと反映されていることが分かるようにしています。


最後に

サービスデザインにおいて、ロジカルに考えることももちろんですが、ルールやロジックにこだわりすぎて案が固まってしまうことは避けたいので、まずは自由に発想、創造することを心がけています。
ユーザと一緒にサービスを楽しみ、同じ目線に立って、設計することを念頭においてデザインしています。

まだまだラジ生はまだまだ改善途中で、これからもよりよいサービスに成長すべく開発陣一同、頑張っています。
沢山の人に、ラジ生?を知っていただけると嬉しいです。

そして、プロデューサーと毎週公式ラジオを放送しておりますので、良かったらぜひ聴いてみてくださいね。

【公式】ラジ生?の中の人のラジオ「ラジトーク」
※スマートフォンからご覧ください。


最後までご覧いただき、本当にありがとうございました!