Frontrend Conference The Finalに参加

Frontend

Frontrend Conference - A conference for front-end developer（2015年2月21日開催）に参加してきたので自分用メモ

[Keynote] Pragmatic Front-end Developer: From Artisan to Expert

斉藤さんによるエモい話。フロントエンドは無くならないどころか、これからより一層面白くなってくると思う。

資料（ドラフト）

リンク

JavaScript
CSS
  • idiomatic.css, css guidelines, sass guideline
html
  • code guide by mark otto
tools
  • editorconfig, jscs, csscomb
styleguide
style generator
Tips

[JavaScript] Reactive Programming in JavaScript

あほむさんによるRFP入門。いままで見たFRP入門の中で一番分かりやすかった。
いろいろ触ってみよう。Bacon.js押しだったけど、このタイミングだとReact.js使うかな

資料

リンク

[JavaScript] Introduction to React

外村さんのReact話。
一つ前の記事を受けて、いろいろさわる際の参考にする

資料

リンク

[CSS] Web Components/Polymer, Styling Shadow DOM

谷さんによるWeb Compornents話。おさらいから設計的な。
この辺りが普通に使えるようになるとフロントエンド本気で面白くなる。

リンク

専用セレクタ

  • :host()
  • :host-context()
  • ::shadow
  • ::contents
  • /deep combinator（>>>）

設計のヒント

Tweet

ライトニングトーク

Tweet

[JavaScript] Introduction to ServiceWorker

1000chさんにによるServiceWorker話。
実際に使えるのはずいぶん先だろうけど、5〜10年後のウェブがどうなるのかって視点で見てた。
ここまで考えてウェブを作るべきなのか？という話もあると思うけど。

資料

リンク

キーワード

  • offline first

  • navigator.onLine

    • on.online, on,offline
  • FileSystem API
    • ブラウザ実装されていない
  • Web Storage API
  • indexedDB API
  • Application Cache
  • Service Worker
    • 高機能なローカルプロキシ
    • リクエスト検知
    • リクエスト改ざん
    • on.fetch
    • Fetch API
    • Cache API
    • background Sync API
      • Sync Event
      • Sync Manager
    • Web Push API
      • サービスワーカーをプッシュサーバに登録してプッシュを受け取る
      • push manager

[CSS] Inline layout

づどさんのInline Layoutの話。面白そうだったけど聞けず。
しっかり理解って意味でためになる資料。Tweetで保管しつつ

資料

[JavaScript] JavaScriptテストの疑問、お答えします。

kyo_agoさんのTestエモ話

資料

リンク

test

  • ユニットテスト
    • mocha
    • jasmine
    • （QUnit）
  • SinonJS
  • Promiseパターンのテストどうする？
  • faketimer系を使わなくなった
  • powerAssert
  • E2E
    • Protractor
    • testeam
  • test runnner
    • karma
    • testem
  • Isomorphicだとテスト楽
  • Phantomは結構レガシー

Tweet

[CSS] Styling Atom (Editor)

atom使ってないし、ちょっと色々話が飛んでてどう聞けば良いのだろう…って感じだった。
プレゼンにエディタ使ってるのが印象的
SUIT CSSの事を知ることができたのはよかったかな

リンク

Tweet

検索連動広告戦略セッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその４。
なんだかんだで重要なペイドサーチセッションが今年のSMX Advanceのラストセッション。４人のパネリストによって発表されたとの事。分野が違ってこっちに踏み込む勇気はないけど、面白そうな業界だよね。

Up Close @ SMX Advanced: Amazing Paid Search Tactics

Heather Cooan @ Clix Marketing

ペイドサーチ分析用のGoogle Analyticsティップス。
PPCマーケティングが完全独立スキルだとよくわかる。単純な運用だけじゃやってけない、って話なんだろうなー。

  • カスタムデータソースでコストデータを読み込み、流入経路毎のROIを計る
  • フィルタを活用した検索パートナーのパフォーマンス測定ビュー
  • 便利な指標紹介
    • ページバリュー
    • アシストコンバージョンバリュー

Steve Hammer @ RankHammer

AdWordsスクリプトを使った自動化について。
大事なのは急いだり、ステップを飛ばしたりしない事。きちんとひとつずつ効果を検証しながら進める事が大事。

  • 自動化の３つの利点
    • 計算
    • 外部連携（エクスポート、インポート）
    • パラメーター（テキストなどの自動変更）
  • 基本フレームワーク
    • Find
    • Fix
    • Scale
    • Success
  • その他サンプル多数

Jennifer Slegg

AdWordsのライティング、キーワード選定について。

  • 文法は重要。スペルミスで全く効果がなくなることも
  • サイトリンクは重要だけど遣り過ぎないように。マックスは25文字だが12文字程度におさめるように。
  • 競合の多いビッグワードの観察も大事。どんな事をやっているか、自分のキャンペーンに活かせないか考えよう。
  • 最後にちょっと驚きの手法で、たまには除外ワードで出稿する事も大事、とのこと。思い込みで役立つキーワードを捨ててるかもよ？

Larry Kim @ WordStream

最後はLarry Kimによる、クオリティスコアの話。
クオリティスコアが重要視されるようになって、従来の戦略が使えなくなったという話。

  • これまでCTRが少なめでもそれなりのビッグワードで出稿していた方が効果があった
  • ただし、その方法だとクオリティスコアの減少が著しい
  • また低いクオリティスコアのアカウントへのBidの価格上昇も大きく、かなりのコスト増
  • クオリティスコアの上昇（下降）でインプレッションに9%程度の影響が
  • 表示順位は3位あたりが一番コストパフォーマンスがいいらしい
  • CTRが低くてもCTAが高いと意味が無いのでLPの見直し大事
  • 下1/3のキーワードを削除してまるっと見直そう

ローカルSEOセッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその３。
Search Engine Landを見ている限り、いま一番熱いSEOの話題であるローカルSEOのセッション。スライドは無しでフリートーク形式で行われて、会場は満員だったらしい。さもありなん。

Up Close @ SMX Advanced: Local Super Therapy Session

得意分野ではないのと中途半端にピックアップできないので、主な話題だけリストアップ。気になる人は原文を読みましょう。

  • Google My Business
  • Local SEOにはインタラクションが大事
  • サイテーションの考え方を変えよう
    • サイテーションはリンクのような物でGoogleの性能アップでNAPの統一などは重要ではなくなった
  • レビューはランキング要素と考えないように
  • コールトラッキングはしないこと
    • 電話番号はブランドの一部
    • 番号が分散するなどもってのほかというパネリストの全会一致
    • 単一の番号であれば問題は無いがトラッキング業者を変えるorやめるのができなくなるリスク

構造化データに関する特別セッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその２。 今年のSMXでもっとも注目を浴びた構造化データのセッションではディズニーとBestBuy、Define Mediaグループが発表。
直接参加されて日本語でレポートしている方も多いのでそちら見る方が早いかも。

Up Close @ SMX: Enhancing Results With Structured Data & Markup

マーシャル・シモンズ@Define Mediaグループ

まずは構造化データの前にMega-SERPs図鑑を紹介。これはいいまとめ。
Mega-SERP: A Visual Guide to Google

次はSERPsにオーサー情報が載るファクターの紹介だけれども、オーサー情報消されてしまったので、なんとも。とはいえサイトやドメインオーソリティを計るには重要な尺度のはずなので紹介。

サイトレベル
  • サイトのオーソリティ
  • 高品質なコンテンツ
  • ドメイン年齢
  • クエリーバリエーションの多さ
著者レベル
  • 評判
  • コンテンツの品質
  • サイトに協力してくれている人たち（ゲストブログもOK!）
  • クエリーバリーションの多さ

最後に各スキーマの流入への影響度

  • オーサーシップ
    • ゆっくり、散在した表示、CTRへの影響は少ない
  • TVレビュー
    • インデックスは早い、表示までは時間がかかる（季節変動）、流入への影響は中くらい
  • 商品レビュー
    • インデックスも表示も早い、流入への影響も良い
  • レシピ
    • インデックスも表示も早いが、流入への影響は小さい
  • アーティクル
  • ビデオ
    • インデックスは早く、表示はさらに早い。インパクトも非常に大きい

ジェイ・メイヤー@BestBuy.com

すべての店舗は公開するべき素晴らしいデータを持っている、という戦略で構造化データに取り組む

かなり早いタイミングでRDFaに取り組み始める。初期に重視したのは以下

  • キーワード以上の価値を持ったデータを提供
  • きれいでイカしたURL
  • 文法はRDFa
  • 以下のようなオントロジーに対応
    • GoodRelations
    • FOAF
    • GEO

早いタイミングで対応した事が功を奏して、現在はmicrodataで情報を提供し、SERPsにも順調に表示されている

ジェフ・プレストン@Disney

話した内容はSchema.orgからOpen Graph、Twitter Cardまで幅広く。まずは、構造化データは万能薬ではないという忠告から。

Twitterカードの活用例として、新作映画に個別のURLを用意してツイート時とリツイート時で別イメージを出すように（？）するなどの工夫を。

最後にナレッジグラフに触れて、どのようなデータが影響するのかを解説。Wikipedia、Freebase、Schema.org。というかここまでの調査はナレッジグラフに情報が出まくるコンテンツを持っているディズニーならではかと。

記事での解説は少なめだったけれど、スライドのサンプルは充実しているので必見です。

QAセッション

  • マーシャルからジェイへの質問で、そこまでSERPsを拡張しているとGoogleのアップデートがされておらず間違ったデータを提供する事は怖くないか？
    • 確かに、Googleがクロールに戻ってこなくなったら心配する
    • BestBuyではストックデータがあるかどうかのフラグを管理していて、あとはGoogleを信頼している
  • データへのアクセスを制御したりだしたくないなどはないのか？
    • 全員がそれはないという答え、データをアクセシブルにすることはいい事だと言う認識
  • （SERPsの充実で）サイトにユーザーがこなくなる事を心配したりしないのか？
    • 実際に発生しはじめているとジェイ
    • ディズニーのジェフは、彼の居るようなエンターテインメント業界での影響は少ないが、スポーツなどでは影響が大きいとのこと。

ランキングファクターセッション@SMX Advance 2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモ。
大枠はずれていないけれど細かいトレンドのキャッチアップとしては非常に充実した内容。幾つかあるレポートの中でも一番長い（充実してる）です。

Up Close @SMX Advanced: The Periodic Table Of SEO Elements

ランキングファクターセッションでは、例年通りSearchmetrixによる調査の発表の他、２人からUXの重要性が発表された。

マーカス・トバー@Seachmetrix inc.によるランキングファクターの関連度調査

  • サイトスピードは重要で、特にモバイルではUXに直結するので大切にしよう
  • ブランドは１位２位には有効だがそれ以下の争いでは無意味。まずはネット以外でブランドを確立する事が大事。
  • 少なすぎる多すぎる内部リンクは不利（平均は180くらいだが数千のサイト調査の結果なので一概に言わない方がいい）。
  • どんなにスピードや内部リンクを最適にしても、コンテンツが貧弱ならどうにもならない。
  • コンテンツについては長めの文章が有利な模様
  • G+やFacebookのシェア数も影響度が大きいが、昨年よりは低下
  • バックリンク、量に関しても引き続き重要。
  • スマートフォンの場合はテキスト量少ない方が有利
  • さらに、バックリンクの数が影響するのは5〜6位まで
  • PCとモバイルの両方で20位以内に入るのは64%程度
  • サイト滞在時間はややポジティブな影響
  • 直帰率とランキングに影響は無い
  • CTRは非常に影響力が大きい

最近のSEOはユーザーエクスペリエンスだ！

マリアン・スウィーニー@PortentによるUXがSEOに与える影響

  • 検索者は年々なまけものになっている
  • UX観点からの重要なポイント4つ
    • 選択（ユーザーはあなたを選ぶか？）
    • エンゲージメント
      • ファーストビュー
      • 分かりやすいか（Proto-Typicality：よくあるデザインで斬新すぎないように）
      • 複雑すぎる見た目になっていないか
      • ナビ：検索を使うようになっているので、最低限で分かりやすくすること
      • ユーザーは必ずページ中央をまず見るので、そこに最も重要なコンテンツを配置する事
    • コンテンツ
      • あり物のコンテンツを活かす
      • 古くて不要なコンテンツは消すべし
      • コンテンツのオーナーにコミットメントさせろ
    • リンク
      • キーワードリサーチは陳腐かしたがそれでも重要
      • Google Trendなどを使ってクエリーの向こうにいる人間を想像する事
  • 90%のユーザーはスクロールしない（Google Analyticsで調べられる）
    • あなたのコンテンツはスクロールする価値があるのか？

マシュー・ブラウン@MozによるSEOを成功させる要因

  • 単純なSERPsはもうほとんど存在しない
  • ランキングへのハミングバードの影響は強く、相関性も複雑になった

  • SEO担当者は計れるもので考えて、計れない物は無視してしまいがち

  • 重要じゃなくなったもの

    • タイトルタグとメタタグ中のキーワード
    • キーワードの言い替え(“hotels in Paris,” “Paris hotels,” “top Paris hotels” etc.)
    • やり過ぎなスニペットを意識したマークアップ
    • 単純な順位ではなく、検索結果面に一緒に表示されるユニバーサルサーチを確認しよう

  • これから重要（になりそう）

    • エンティティ（ナレッジグラフ）最適化
    • ローカル情報（モバイル検索の成熟でさらに重要に）
    • ナレッジグラフはどんどんローカルに

  • エンティティとリレーションシップを最適化しよう

  • SEOはこれからどんどんサイトに独自化していくのでSEOの重要性は上がっていくと思う

QAセッションでのダニーサリバンのお言葉

  • ソーシャルでの関連度をあげろ、ランキングをあげるためではなく、（コンテンツの評価などを）評価するために

Volocity.jsを使ってアニメーションのパフォーマンスを比較してみた

CSS vs. JS Animation: Which is Faster?
CSS AnimationよりもJavascriptを使った方がパフォーマンスが出るよ、というこの記事を見たので実際に試してみた。

結論

アニメーションさせる時は、Velocity.jsを使いましょう

デモ

DEMO1 - 画面下からスクロールインしてくるモーダルウィンドウ

DEMO2 - 120個の丸が一度に動く、シンプルなアニメーション

[source code @ GitHub]

機能比較

ライブラリ 特徴 メリット
jQuery(animate()) 標準で組み込まれているアニメーションライブラリ ライブラリの読み込み不要
Velocity.js 標準のanimate()と同じ文法で使える拡張ライブラリ スピード最適化された実装
Transit CSS Animationを制御するためのライブラリ 3d-transformも使用可能

結果

Windows7とMac Book AirのChromeでテスト。

ライブラリ DEMO1 DEMO2
jQuery(animate()) △ 動きに引っかかりが発生 × 動きがずれる
Velocity.js ◎ なめらか ◎ なめらか
Transit ○ なめらかだが一瞬ひっかかる ○ 動きのステップが大きい

結果はValocity.jsが圧倒。特にDEMO2でのスムーズさは他を圧倒。
requestAnimationFrameを使用していて、ちゃんとフレーム毎に再描画されるのでスムーズさが違います。
GPUが使えないスマートフォンで見ると、さらに違いが顕著。

解説

Velocity.jsがスムーズな一番の理由はrequestAnimationFrameを使っている事。これはブラウザが画面の再描画のタイミングで呼ばれるフックになっていてきちんとフレーム毎に再描画されるようになり、そのおかげでスピード以上に自然な動きに見えるようになります。その他にも効率化のために色々やっているので、使わない手はありません。既存のanimate()との互換性もあり、呼び出しをvelocity()と書き換えるだけで問題なく動作するようです。

個人的にびっくりしたのはCSSアニメーションがそこまで早くないという事。ブラウザがネイティブで最適化できるんだから一番早いはず！というのは思い込みだったようです。とはいえ、3d-transformをアニメーションさせるにはCSSアニメーション必須なので、使い分けですね。

あと、Transitはアニメーションの終了をフックできません（多分 コメントいただきましたがjQueryアニメーションと同じ文法で書けると明記されていました）。リアクションとしての動きだけなら問題ないけれど、インタラクティブなアニメーションをさせる場合、実装ががやや面倒くさくなりますね。

CSS Animationを使用するタイミング

元記事にも有りますが、シンプルなアニメーションで管理をすべてcssファイルで一元管理できるならあり、とのこと。大量の要素を一度に動作させない限りパフォーマンスも悪くないので、使用する事自体は問題ないでしょう。個人的には飾り的な（なくてもいい）アニメーションはCSS、インタラクションに関連する必須なアニメーションはVelocity.jsを使うのがオススメです。

My recommendation is to use raw CSS transitions when you're exclusively developing for mobile and your animations consist solely of simple state changes. In such circumstances, transitions are a performant and native solution that allow you to retain all animation logic inside your stylesheets and avoid bloating your page with JavaScript libraries. However, if you're designing intricate UI flourishes or are developing an app with a stateful UI, always use an animation library so that your animations remain performant and your workflow remains manageable. One library in particular that does a fantastic job at managing CSS transitions is Transit.

結論ふたたび

コストはたったの8kだけなので、Velocity.jsを使いましょう。
互換性もあるので、不具合あってもすぐに戻せるし。

参考リンク

Velocity.js公式

CSS vs. JS Animation: Which is Faster?

Improving UI Animation Workflow with Velocity.js

compassミニマムスタートの始め方

既存プロジェクトの一部だけにcompassを取り入れてみる。

すでに公開中のサイトにcompassを導入する場合は、sassフォルダに現状のcssをぶち込んでしまえば良い訳ですが、それは一人で管理している場合。

複数人で作業している場合には、全員にcompassに乗り換えてもらわないと行けないので中々めんどうです。。単発のお仕事でキャンペーンページ作成や新機能の追加などの場合は、自分の担当部分だけでもcompassでやりたい！と思うのですが、準備やコミットが面倒くさい事この上ない、、、

ということで、既存のプロジェクトで自分の作業ファイルだけをcompass採用するためのプラクティスです。

メリット

  • 既存のフォルダを汚さない
  • 作業フローがどんな形でもコンフリクトが起きない
  • フォルダの整理などの事前準備が（ほとんど）不要

どうやるの？

  • compassフォルダを追加で作成
  • htmlのcssファイルへのパスを変更
  • compass w実行
  • 実作業
  • 最後にcommpass compile -e production
  • htmlの記述を戻して、納品！

フォルダ構成

作業フォルダ/
　└ css/
　└ img/
　└ compass/
　　└ sass/
　　└ img/
　　└ css/
　　└ config.rb

config.rbはこんな感じ

config.rbサンプル @ Gist

やってること

Gruntが書き出すcssを監視して、親ディレクトリ*1のcssフォルダに自動的に移動します。

既存のcssファイルに同じ名前の物が有ったら確認メッセージを表示するので、間違って上書きも発生しません。

注意

  • cssで使用している画像の移動は手作業で
  • commpass compile -e production実行時にcssに変更が無いと変換されないので、--forceオプションを付けるか、grunt cleanを実行してから

最後に

compass/*.cssをcss/に移動させているだけなんですが、そこがコントロールできるのがポイント。 納品やコミット作業のタイミングまでcompass一式を分離しておくので、共有フォルダで他の人と同時に作業していても問題無いですし、間違って関係ないcssを消してしまう事もありません。

また、最初に色々パスを書き換えて、、、的な準備が不要になるので気楽にcompass導入ができるのではないかと。自動化もされるので、なれないフォルダ構成にあたふたする必要もありません。

画像ファイルの移動ややhtmlのcssパスの書き換えは手作用になるのが難点ですが、ミニマムスタートということでこの形式。完全移行か不採用かっていう葛藤ではなく、とりあえず、コスト0でスタートすることは大事だと思うのです。

*1:config.rb中のcss_distination_dirで指定できます