1 pixel|サイバーエージェント公式クリエイターズブログ

サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。


Theme:

みなさん、こんにちは。サイバーエージェントでフロントエンド・サーバーサイドを実装したり、オフィスを作ってみたりしている@herablogです。今回は、Amebaアプリでアメブロの記事をネイティブ化したプロジェクトをご紹介したいと思います。多くの方がご存知のようにアメブロは2005年にPCブラウザ向けサービスとして提供され、インターネット上に個人やグループの記録を残す、まさしく THE Web といったサービスです。この記事では、10年以上のデータが蓄積されたWebサービスをどのようにしてネイティブアプリとして組み込んだかご紹介します。

 

 

コンセプト

ネイティブ化するにあたって、大事にしたことは以下の点です。

  • 表示がはやい
  • 記事を読むことに特化している

モバイルでの利用増加により、「表示がはやい」ということはますます重要かつ当たり前になっています。Webアプリでも、最適化をすることによって速度の高速化は可能ですが、今回のプロジェクトでは、実データ以外のUIパーツを事前に埋め込めるというネイティブアプリの利点を活かして、高速化にチャレンジしました。

 

また、Webの世界では、非常にオープンな環境であるがゆえにカスタマイズが容易で沢山のパターンのデザインがあったり、多種多様なSDKが混在し、そのすべてをコントロールすることが難しいといったことがあります。特に、PCからの仕様を継承したサービスでは膨大なパターンになりがちです。そこで、今回のプロジェクトでは記事を読むことに特化するように気をつけて設計しました。他のネイティブアプリと同様に、自由度はやや少ないんだけど、重要な機能にフォーカスされているといったモバイル時代に合った方向を目指しました。

 

とにかくはやい

今回のプロダクトでは、見た目がシンプルで記事が読みやすい・スクロールでのページングが滑らかといった特徴がありますが、何よりも一番のユーザーメリットとしてあげられるのが、表示のはやさだと思っています。表示がはやければ、途中で離脱せず、読みたい記事を最後まで読めるようになります。最近話題のAMPInstant Articleでも表示速度の改善を大きな目的としています。現状のWebページが他社に比べ劇的に遅いというわけではありませんが、一度ネイティブ版の表示を体験していただければその違いがわかると思います。

 

こちらが今回のプロジェクトの紹介ムービーです。記事の表示や記事一覧表示、記事の絞り込みなどの操作が素早くできます。

 

 

設計

今回のプロジェクトの最終的な設計は以下のようになりました。

API(記事・広告データ) 
  -> NativeApp(フェッチ、UIコントロール)
    -> ReaderView (WebView, 記事表示)

ネイティブアプリは、APIからのデータ取得と、UIパーツの表示コントロールをします。必要なデータが揃った段階でReaderView(実体はWebView)にデータを渡します。ネイティブアプリとReaderView間はオフラインですので、コスト低くデータを転送できます。(ReaderViewで使うファイル郡( html js css )は事前にネイティブアプリ内に内包しています。)

 

ReaderViewは、ネイティブアプリから受け取った情報をもとに、ブログ記事を表示します。ネイティブからデータを受け取るために、以下の様なメソッドを公開しています。

 

(例)

reader.render({
  title: 'Blog Post',
  text: 'Hi'
}); // render the contents
reader.clear(); // clear the view

初期段階ではWebViewを使わない選択肢も検討しましたが、「ブログ」という財産を活かすため、上記のような設計にしました。それは、アメブロのデータが基本HTMLをベースとしており、WebViewを使わないとブログ記事の表現がしきれない要素があったためです。

 

Web実装

ネイティブアプリに組み込まれるWeb実装(ReaderView内)として、特徴的なトピックスを記載します。

Viewに徹する

ReaderView内の実装では、とにかくViewに徹するようにし、データのフェッチや表示タイミングのコントロール、トランジションはネイティブアプリに任せることにしました。そうすることにより、ネイティブアプリとの役割を明確に分けるようにしています。

React, Flux

一番最初のモックでの実装は、

element.innerHTML = html;

というように、与えられたhtmlを表示するといった極めてシンプルなものでした。

しかしながら、最終的には React Flux での実装に変更しました。ネイティブエンジニアが修正する可能性もおおいにあるためScript中心でviewを構築する React は相性が良いと判断しました。(弊社内では Flux 設計のネイティブアプリも存在し始めているようです)

SVG

ネイティブアプリ内に内包されているWebViewを利用しているので、ある程度ユーザー環境を固定することができます。今回のプロジェクトでは、iOS 8以上、Android OS 4.1以上を対象にしているので、未対応のブラウザを気にすることなくSVGを使うことができます。ReaderViewでは、Web FontやCSS Spriteではなく、SVGをSprite化( symbol )してアイコンを表示しています。

 

なお、今回のタイミングでデザイナーさんと協力してSketch一括管理、Sketchから SVG SVG Sprites Font(TTF, WOFF, EOT) png などに書き出せるようにしており、好きなフォーマットで利用できるようになりました。

 


Sketchで管理された、シンボル一覧

 

tap hightlightをオリジナル実装

できるだけ、WebViewであることを感じさせないために、タップした時のフィードバックをデフォルトのものから変更しました。デフォルトのままだと、"ブラウザ感"が出てしまい、どうしてもネイティブアプリの世界観からずれてしまうためです。具体的には以下のパターンに分けて実装されています。

 

ボタンパターン

通常のブラウザのようにオーバーレイでのフィードバックではなく、ボタン自体の大きさを変えています。こうして、ボタンのデザインを損なうことなくフィードバックを表現しています。

 

 

背景変化パターン

ナビゲーションなど、大きめなスクエアボタンはタップ時に背景色を変更しています。

 

 

テキストリンクパターン

テキストリンクでは、通常のブラウザと同じ表現方法ですが、色をやや薄めにしてデザインに馴染ませています。

 

 

Podで管理

これは非常に余談的ですが、どのバージョンのReader Viewを使っているかネイティブアプリから管理しやすいように CocoaPods (iOS用のライブラリ依存管理ツール)を利用しました。今回のプロジェクトではReaderViewのリリース毎にバージョニング・設定ファイル( AmebloReader.podspec )を更新し、ネイティブアプリのビルド時に指定したバージョンにアップデートしてもらいました(ちなみにAndroidはシェルで管理してました)。

Pod::Spec.new do |s|
s.name         = "AmebloReader"
s.version      = "0.2.3"
s.summary      = "HTML, CSS and JavaScript for Ameba app blog reader"
s.homepage     = "https://ghe/ameba-app/ameba-app-blogreader-webview"
s.license      = { :type => "Custom",
 :text => "Copyright (C) CyberAgent, Inc. All Rights Reserved." }
s.platform     = :ios
s.ios.deployment_target = "8.0"
s.source       = { :git => "git@ghe:ameba-app/ameba-app-blogreader-webview.git",
  :branch => 'master',
  :tag => "#{s.version}" }
s.ios.resource_bundle = { "AmebloReader" => ["dist/blog_ios.html"] }
end

 

デザインスプリント

記事を読むことに特化しているプロダクトにするために、開発メンバー(デザイナー・エンジニア)のスキル・知識を総動員しました。それらを引き出す手法として、今回のプロジェクトでは、デザインスプリントを採用してみました。

 

デザインスプリントはGoogle社が提唱する開発手法で素早いPDCAを可能にしてくれるものです。 この手法のいいところは、意見の強い誰かが言ったこと(利害関係に左右されていたら最悪です)を実装するのではなく、重要な決定にみんなの意見が入り、当事者意識が芽生えるところです。 ものづくりの過程では、開発者自身がいかに自分のものとして考えられるかということが重要です。 そう考えられれば、細かいところも丁寧に気をつけて実装しますし、自ら改良のための提案も進んでしたくなるものです。

 

実際には、デザインスプリントの手法を少しアレンジして実施しました。それでは、その開発フローをのぞいてみましょう。

 

課題決定

このプロジェクトにとって何が大事か、欠かせないものは何か、やってはいけないことは何かを決定します。参加者は思いついたことをそれぞれポストイットに書き出します。ここでは必ず紙に書き出すようにします。発言を求めてしまうと、意見の強い人に左右されてしまったり、いまいち自信がないと発表を控えてしまったりするからです。

投票

その後、それぞれよいと思ったアイデアの紙にシールを貼って投票します。この際に大事なことは、誰が言ったかではなく内容そのものについて評価することです。

 

よいと思ったアイディアには +1 シールを貼っていきます。こうすることで、プロジェクトにとって大事なこと・けしてやらないことなどがメンバー間で共有されます。

評価

投票の多かったものを中心に議論し、今回のテーマについて方向性を絞り込んでおきます。気になるところ・疑問に思うところは、この際に議論し、ある程度みなが納得している状態にします。

遷移図を描く

上記で決まった方向性をもとに、実際に遷移図に落としていきます。この際には、デザイナーだけでなく、エンジニアも一緒に考える方がよいでしょう。各プラットフォーム(OS)の作法に詳しいのは大抵の場合エンジニアですし、最終的に実装するのはエンジニアであることが多いからです。ここである程度一緒に決めておくとあとでデザイナーの元へ確認に行く頻度がかなり減ります。

 

実際に使った遷移図。遷移図は前後の流れも含めて描きます。デザイナーだけでなく、エンジニアも描くのでクオリティはマチマチです。

 

遷移図の評価

遷移図も、コンセプトと同様に議論し評価していきます。エンジニアのみなさん、「これは実装厳しいな...」と思ったらこの段階で遠慮せずに言っておきましょう(あとで徹夜にならないように...)。

実装 (プロトタイプ)

遷移図の評価ができ、案が決まったら実装してみます。実装者は、最初の段階から議論に参加しているのである程度納得した状態で実装できます。腑に落ちた状態かどうかで、実装スピード・クオリティは劇的に変わると思います(わたしはそうです)。

レビュー

実際に作ってみたもののレビューをします。ここでは、必要に応じて開発者だけでなく、ユーザーさんを呼んでのテストも有効です(今回のプロダクトでも数回行い、我々の想像以上に視野が集中しているという発見がありました)。ここで出た改善点を次回のデザインスプリントにいかしていきます。

上記のフローを隔週ベースで一周りするように進めました。実装の段階では、集中して進めるため、開発合宿を行ったりもしました。

 

開発合宿の様子。みんな集中してます。

 

XCodeとAndroid Studio両方を同時に開いているところがこのプロジェクトっぽいところです。

 

お昼は、弁当を注文してみんなで食べます。へいへい(運営担当)の弁当注文スキルもあがりました。

 

広告

広告というと「じゃま...」と感じている方もいるかと思いますが、いち開発者・いちユーザーとして、私自身も「なければないほどよい」と思っています。しかしながら、サービスを継続して提供していくためには広告による収益が大事であることも事実です。また、広告主、メディア、ユーザー全員にとって良かったと思える広告もあるでしょう。そこで、今回のプロジェクトではできるかぎり記事を読む邪魔をせず、効果を上げる以下の様な仕組みを検討しました。

inview率を上げる

通常、広告はSDKでコンテンツの読み込みの後に取得するため、表示が遅れてしまうことがあります。これはデータは読み込まれているのに、ユーザーに届いておらず無駄になっている状態で、誰にとっても喜ばしいことではありません。そこで、今回は記事データと同じタイミングでサーバで広告データを事前取得し、遅れず表示するようにしています。特に記事上部の広告は100%近い inview率 を保証でき価値の高い枠にできます。こうすることで、きちんと広告がユーザーの目に届き、価値があると感じたら押されることになります。

 

広告データは記事と一緒に取得しているので素早く表示され、ガタッと表示領域が伸びたりしない。

 

記事の邪魔をできるかぎりしない

広告の表示が遅く、事前に高さが確保されていない場合、誤ってタップしてしまうことがあります。しかしそれは本質的なタップではありません。それを防ぐため、事前に広告を取得・予め高さを決めて表示するようにしています。また、バナー表示を避け、できる限り記事のデザインと合わせることで記事から"浮いて目立つ"ことのないようにしています。

効果を上げて、枠の数を減らす

広告は数が多いほど効果が出やすい傾向にあるため、ついつい数を増やしてしまいがちです。しかしそれは、本来記事を読みに来ているにもかかわらず、広告だらけで読みにくい・不快だといった本末転倒なことになる可能性もあります。今回のプロジェクトでは上記のような対応をすることで、それぞれの枠の効果を上げることにより、広告の枠を増やし過ぎず、記事とのバランスをとれるように心がけました。

 

KPIs

最後に、このプロジェクトにおけるKPIについて触れて終わりにします。このプロジェクトでは、表示速度の改善・滑らかなページングによる PPU (Pageview Per User) の向上、表示内容最適化による 広告効果(CPM: Cost Per Mille) の向上を主要KPIとして設定しました。

それぞれ

PPU -> 約130%向上
アップ

CPM -> 約120~130%向上
アップ


というようにいまのところよい効果が出ています。

以上、アメブロのネイティブ化についてご紹介しました。iOS, Androidとも、Amebaアプリでご覧になれますので、ぜひ軽快になったブログ表示を体験してみてください。

 

iOSアプリ

 

Androidアプリ

Get it on Google Play

 

いいね!した人  |  リブログ(0)
最近の画像つき記事  もっと見る >>

Theme:
アメーバピグでフロントエンジニアをしております松永と申します。

今回は12月8日に開催となりました『UXなまトーク Vol.3』について

レポートさせて頂きます。

盛り上がったパネルディスカッション 写真左から、小川卓さん / ヤフー株式会社 瀧知惠美さん / 株式会社サイバーエージェント 水野 寛さん / 株式会社アイ・エム・ジェイ 佐藤哲さん
『UXなまトーク』はUXについて現場のなまの声をトークするというイベントです。第3回となる今回は【定量と定性の交差点】というテーマです。


どのような考えがあり、実際に現場で起きたことをどのように解決したかなどをそれぞれの立場からトークしていただきました。

当日はいろいろな職種の方がたくさん集まって、熱気で会場が包まれていました。

それでは、各登壇者の”なまトーク”をご紹介いたします。

『ネットアンケートから定性的データを引き出し質的分析をする取り組みについて 無意識インサイト調査®と行動文脈リサーチの実践例』

株式会社アイ・エム・ジェイ 佐藤哲さん


定量と定性の融合と定量側と定性側の協調について発表していただきました。

実際に案件で発生したものをフィクション化しストーリーテリング的に発表されていたので、臨場感溢れる発表でした。
・・・・・
・・・・・・・・・・・・・・

人間の脳は95%が潜在意識といわれており、意思決定はそれらに影響される。

そのため、本質ニーズを得るための手法として略画法や状況設定、擬人化法を使いアンケート設問を設計していくと効果的である。

そのようなアンケート設問の自由回答から得た情報にこそ、人の心に関する文脈が入っている。

ワークショップ形式で文脈を読み取りながら質的分析をすることで、情報の深掘りが可能になる。

・・・・・・・・・・・・・・・・・・・

定量調査で事実確認し、定性調査で情報を深掘っていくことで、定量と定性、お互いが補完し合い、良い相乗効果を生んでいる実例でした。

私自身、担当サービスのアンケートとも向き合うことがあり、その際に本質的なニーズはなかなか得にくいという体験をしていたので、大変参考になりました。


『ピグのユーザ体験を 定量/定性で捉える方法』

株式会社サイバーエージェント 水野 寛さん





現在ピグ事業部全体のUX改善に努め、私も共に仕事をしている弊社、水野の発表です。

・・・・・・・・・・・・・・・・・・・

今年で7年目を迎えるピグには外部環境の変化にあわせた変化が求められ、利用者の本質的ニーズに応えるべく、分析とUXD推進のタスクフォースチームが結成される。

定量と定性それぞれの限界を理解したうえで使い分けている。

事業目線で既存から棚卸しをして作成したコンセプトダイアグラムと、ユーザー体験から仮説を発見し、固定概念を超えるために作成したカスタマージャーニーマップ。
・・・・・・・・・・・・・・・・・・・


私自身、発表の中にあったUXD推進室に参加しており、水野とは日々仕事をしております。
現在ピグ事業部は1人1人がUXに向き合い、常にユーザー中心にモノづくりをしていくという姿勢が浸透しています。

定量・定性の違いという視点から、具体的にピグで行われているUXアプローチを詳しく紹介いただきました。


『チームビルディングから始めよう!~UXデザイナーの定量×定性への取り組み方~』

ヤフー株式会社 瀧知惠美さん






UXデザインの考え方を自身のプロジェクトで活用しようとした際、問題が発生することがあります。
そうした問題の解決方法、1人でも実行できるUXデザインの方法、UXデザイナーの定量への意識、定量と定性のアプローチ方法を発表していただきました。

これからUXデザインを活用しようという場面においてもとても参考になる内容でした。

UXデザインを活用しようとするときに、UXデザインの進め方は不確定要素が多かったり時間がかかるので、プロジェクトメンバーの理解を得ることに苦労をするという話は色々なところで耳にします。
発表の中にあった具体的な反対意見に対する解決方法の紹介などは、とても参考になりました。
・・・・・・・・・・・・・・・・・・・
UXデザイナーはメンバーの気持ちも汲み取ってファシリテートしていく。
なぜならば、メンバーもある意味”ユーザー”と捉えられるので、メンバーに対しても”ユーザー”視点で望む。

・・・・・・・・・・・・・・・・・・・
常にそういった視点を意識していくことで色々と円滑に進められることも多いと思いました。
・・・・・・・・・・・・・・・・・・・
定量だけでは解決方法が絞れず、定性だけではどこが重要かわからない。それぞれを補間し合い、実際に瀧さんの現場では、UXアナリストとUXストラテジストがコラボレーションをして進めている。
・・・・・・・・・・・・・・・・・・・

実際の現場のお話も聞けて大変興味深いお話でした。


『ユーザーを理解できない「アクセス解析指標」や「KPI」からの脱却! ユーザーエクスペリエンスに基づいた指標設計と改善の考え方』

小川卓さん



・・・・・・・・・・・・・・・・・・・
様々な指標があるが数字としてそれらを達成することが重要なのではなく、大切なことはユーザーの想いや行動が変わることである。

コンセプトダイアグラムを作り、ユーザーの行動や態度変容を可視化する。
これまでのような、直帰率や数だけを断片的に追っていては見えない行動の流れが見えてくる。
作成の際には、企業目線は絶対に持ち込まない、作って終わりではなく計測することが重要である。

・・・・・・・・・・・・・・・・・・・

実際に開催してきたワークショップの様子、その時作成された最終アウトプットなども紹介していただきました。
実際に多くの企業が実践し、それによって沢山の気づきを得ている事実を知り、こういった視点や手法がとても重要であることを再認識しました。

コンセプトダイアグラムの具体的な作成例や、コンセプトダイアグラム作成後に施策まで落としこむ流れなど、他にも非常に勉強になることばかりでした。

様々な指標を分析していくと、数字のみにフォーカスしてしまうことがあると思います。
常にユーザーの気持ちを理解しながら分析し、ユーザーにとって正しい順番で正しい情報を提供していくことの重要性を学ばせていただきました。


おわりに

今回もたくさんの方にご来場いただき、UXに対する関心が高まっていることを感じました。
実際に現場で活躍されている登壇者の方々によるトークとパネルディスカッションはすぐにでも実践できることも多く、とても参考になりました。

今回のテーマでもあった定量と定性についても、それぞれ良い部分も限界もあり、それらをお互い補間しあって、目的であるUXの向上を図っていくことがとても重要であると感じました。

サービスを使ってくれる人の体験を最高のものにするという最も当たり前に目指すべき目標を達成できるように今回の学びを活かしていきたいと思います。

今回ご参加頂けなかった方も、是非次回の「UXなまトーク」へご参加ください!



サイバーエージェントでは定量と定性に真摯に向き合いサービス創りができるクリエイターを募集しております。
⇒サイバーエージェント採用サイト
いいね!した人  |  リブログ(0)

Theme:
みなさん、こんにちは!
CyberSSにてデザインを担当している佐藤宜也(ヨシナリ)と申します。
日々の業務として、インターネット広告メディアを創っているのですが、その上で最重要としている「One to Oneマーケティング」と、それを実現する為のデザイン思考に関して今回は書きたいと思います。

One to Oneマーケティングとは?

"One to Oneマーケティング"とは、いわゆるビッグデータを活用して、ユーザーの年齢や性別はもちろん、趣味趣向や購買・行動履歴や現在地。もっといくと交友関係や生活パターンまで!!そんな1人ひとりの個人に合わせて展開していくマーケティング手法のことです。

今までの広く漠然とした訴求ではなく、個人レベルに合わせてその個人にベストなタイミングで具体的な内容の訴求を行なうことができるので、今まで以上にユーザーの心をグググググッッとつかむことができます。

例えば、「冬用セーターを探している20代の独身男性」に対して、その需要をしっかりキャッチアップした「20代独身男性に人気の冬用セーター」を提案できるわけです。
このコミュニケーションがしっかりと合致すれば、「欲しいと思っている人に欲しいものを紹介できる」ことになるので、結論、より高いレスポンスが期待できます。

01


このような、しっかり対面接客している実店舗で行っているようなコミュニケーションが、今ではインターネット上でも加速的に拡がっています。
そしてこの仕組みを利用して、より効果的な広告クリエイティブを創っていくということは、広告業界のクリエイターとして目指すべき「コミュニケーションデザインの最たるもの」と僕は考えています。

広告から個告へ。10万人のユーザーに対して10万通りのデザイン

02


上記のイメージで示すような"思想"が、One to Oneマーケティングの目指すところです。
ひとつのクリエイティブで10万人の心を捉えようとするのではなく、10万人それぞれに響く言葉とビジュアルで心を捉えよう!ということです。
とはいえ、この言葉どおり10万通りのデザインを普通に創るとしたら、まぁ普通に考えて無理です 笑
ですが、その理想的な状態に少しでも近づくために、僕らは以下のような手法でデザインをしています。

検索キーワードを読み取る

僕らが運用しているサイトへの集客の軸はリスティング広告(検索連動型広告)です。
リスティング広告についてはここでは割愛させていただきますが、「検索キーワードによってurlを設定できる」という機能というか仕組みがあるので、キーワードに対してそれぞれ個別のページを用意できます。
つまり、検索キーワードに対してそれぞれ個別のデザイン設計をすることが可能なので、その検索ユーザー需要に対して、よりベストエフォーなページを用意することができるのです。

例えば、先ほどの「セーター」と検索したユーザーがいたとします。そのユーザーに対しては、当然「セーター」の商品が満載のサイトを見せてあげることが望ましいです。
さらに具体的に「”赤い”セーター」と検索するユーザーがいたとします。
そのユーザーに対しても、先ほどと同じ「セーター」のページを用意することは間違ってはいませんが、「赤いセーター」があるページを見せることができた方が、コミュニケーションはより高次元で成立するはずです。

1枚絵のキービジュアルを要素分解

それでは、上記のようなコミュニケーションを効率的に成立させるためにはどうすればよいのか。
その一つの手法がキービジュアルの要素分解です。

ユーザーの瞬間的な印象を左右するキービジュアルは、ファーストビュー内の要素の中でも特に重要で、どんなに素晴らしいコンテンツがあるサイトだとしても、キービジュアルの印象が悪ければ、せっかく来訪してくれたユーザーはすぐに離脱してしまう可能性が高いです。
有名な3秒ルールの名が示す通り、ユーザーの心を掴むのは3秒(もしくはそれ以下)です。
従って、キービジュアルでユーザーコミュニケーションを成立させることは大前提となります。
サイトイメージに合うビジュアルを創ることはもちろんですが、さらにコミュニケーションを高めるために、構成要素を分解して設計します。

03


これら分解した要素ごとにパーツを用意するわけですが、そのパターンを検索キーワード分用意していきます。
例えば、パーツを3つにわけ、キーワード数を20として、その全てをユニークなものにした場合、その組み合わせは、
20x20x20=8000通りのKVを用意することができます。

大きなデザインの違いは正直無いです。
「パーツの一部が変わっただけのもので、成果に大きな違いがあるとは思えない」と感じる方も多いとは思いますが、それは制作側の目線で考えているからであって、ユーザー側はそのキービジュアルを見比べているわけではなく、それが唯一のビジュアルということになります。
結果、そのキーワードに合わせて変更した言葉やパーツが、ユーザーに対して有益な訴求として目に映り、ユーザーの興味をひくキービジュアルになるというわけです。

ビジュアルは言葉よりも早く大脳に届く

ビジュアルによる訴求は言葉よりも早く深く大脳にアプローチできるという脳科学の話もあり、ビジュアルの精度を上げることで、ユーザーへの訴求力はより高くなるはずです。
たとえ、意識的にユーザーに気づかれない小さなアイコンや何気なく目に映っている背景色だとしても、無意識化に影響しているはずで、その無意識な領域に直接訴求できるのは言葉よりもイメージであり、それがデザインの力です。

だからこそ、One to Oneマーケティングを成功させる為の最適なデザイン思考がこれからどんどん必要なってくると思います。
ダイレクトマーケティングが主流となることで、広告から個告へと概念が移っている広告業界。そこに身を置いている僕らクリエイターにとって、このような思考は身につけておくべき重要なデザインスキルであると感じています。

さいごに

僕たちは、このような概念のもと、ユーザーとのより高度なコミュニケーションの実現を目指して日々の業務を行っています。
それこそ地道なPDCAの繰り返しとなりますが、その精度を少しずつ少しずつ上げていくことで、ユーザーにとって本当に利用価値のあるサイトを作りあげていくことが最終的な目標です。


以上、最後まで読んでいただき、まことにありがとうございます!!!
いいね!した人  |  リブログ(0)

Theme:
こんにちは。
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.


いいね!した人  |  リブログ(0)

Theme:
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に関する新しい学びがあったのはもちろんですが、一番感じたのは、日本も世界で戦える技術力を持っているということです。

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

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

そして自分もそんなプロダクトを作り上げられるエンジニアになるために、日々励んでいきたいと思います。
いいね!した人  |  リブログ(0)

Theme:
こんにちは。
アメーバ統括本部でウェブアナリストをしている枝川です。

アメブロに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 タグマネージャライフを。
いいね!した人  |  リブログ(0)

Theme:
はじめまして。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に興味を持って頂けると幸いです。
いいね!した人  |  リブログ(0)

Theme:
こんにちは。タクスタでフロントエンジニアをしている今井(@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_)
いいね!した人  |  リブログ(0)

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

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

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


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

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

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

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

Spotlgihtとは

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


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

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


誰が書いても読みやすく

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


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

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


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

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

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

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


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


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


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

さいごに

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

この記事が気に入ったらSpotlightに是非いいねを
いいね!した人  |  リブログ(0)

Theme:
こんにちは!
アメーバブログでデザインを担当している、中 隆理(ナカ タカミチ)と申します。
先日、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軸方向の向きを測る事ができる

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

最後に

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

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

最後まで読んでいただき、ありがとうございます!
いいね!した人  |  リブログ(0)
ページトップへ戻る