斉藤祐也の海外WEBテク定点観測＜Issue.14: 2014/05/01-2014/05/31＞

今月の定点観測はURLバーの改善、Object.observe()、アクセシビリティに足りないことなどを紹介します。

注目ニュースピックアップ

URLバーの改善 – JakeArchibald.com

原題: Improving the URL bar

iOS SafariではURLの表示がドメイン名になっています。(URLを表示しているエリアをタップするとURL全体を表示します。)
Google Chrome Canaryの、しかもExperimental Flagのオプションを有効化することで同様の機能を利用できるようにしています。
この機能と記事の筆者であるJake Archibald氏の『一般的なユーザにとってURLはノイズです。プロトコル、オリジン、パスを混ぜ合わせたものです。このターミナルのコマンドのようなものをユーザにそのまま送り返すUIはよいUIであると言えない。URLは共有のしやすさを失わないように、セキュリティにフォーカスしていくべきだ。』という記事の最後に書いた意見は、下記の関連リンクで様々な意見を集めています。

関連リンク:

• URLy warning – Adactio
• On Chrome hiding URLs to protect users from phishing – remy sharp’s b:log
• URLs are already dead – NCZOnline
• Do we really need to hide the URL? – FT Labs

Object.observe()を使ってデータ・バインディング革命を – HTML5 Rocks

原題: Data-binding Revolutions with Object.observe()

JavaScriptでMVCを、というムーブメントが発生し、実際のプロダクトでも利用されるシーンが増えてきています。そんな中で生まれたデータ・バインディングと呼ばれるような機能へのニーズの高まりは必然ともいえるでしょう。そんなニーズに答えるObject.observe()という機能がChrome 36ベータ版にて利用できるようになりました。このAddy Osmani氏によるHTML5 Rocksの記事では、そのObject.observe()の使いどころから、現状の多くのMVCライブラリでの解決との比較など非常に詳細にわたる解説をしています。

『なぜ』と問うことが常に最適な戦略とは言えない – Inside Intercom

原題: Asking why is not always the best strategy

『なぜ』を繰り返すことは本質的な問題にたどり着く方法だと言えると思います。しかし、HubSpotのプロダクト・デザイナであるDaniel Ritzenthaler氏は、闇雲に『なぜ』を繰り返すことは生産的ではないとしています。
記事では、より生産的な『なぜ』を問うには3つのレイヤーを意識するべきだとしています。
1つ目は利便性レイヤー。ここはある機能を使って実際に何を行おうとしているのかを問うレイヤーです。
2つ目はユーザビリティレイヤー。ここはある機能を使うとどんな結果を得ることができるのかを問うレイヤーとなります。 3つ目は結果の望ましさのレイヤー。ここでは、目的を達した後、何が変化するのかを問うレイヤーです。
Daniel Ritzenthaler氏はプロダクトに対してこの3つのレイヤーを念頭においた『なぜ』はしっかりと時間を取って考え、答えるべきであり、その時間は決して無駄にならないと記事を結んでいます。

アクセシビリティにはなにが足りないのか? – A List Apart

原題: Accessibility: The Missing Ingredient

WAI-ARIAが広くブラウザでサポートされている現在においても、アクセシビリティが必要要件とされるケースは決して多いとは言えないのではないでしょうか?
このA List Apartの記事で、IBMのフロントエンド・デベロッパであるAndrew Hoffman氏はアクセシビリティに足りていない材料は、実装の順番に対する認識であるとし、さらにコード例を通じてWAI-ARIAのroles、states、そしてpropertiesに関する簡単な実装を紹介しています。

1回で正しく – Ryan Clark

原題: Do it once. Do it right.

Webのプロダクトの多くがアジャイルを採用し、短いサイクルのイテレーションで新しい機能をリリースすることは今では珍しくはありません。
Virbのプロダクト・マネージャを務めるRyan Clark氏はそのイテレーションにひそんでいるほころびを3つ指摘しています。

• イテレーションを言い訳にしない / 次のサイクルがすぐ来るからと言って、問題を先送りにしていいわけではない。
• イテレーションの破綻 / ただリリースするだけではなく、きちんと振り返り、フィードバックを次のサイクルに反映すること。
• 中長期計画なきイテレーション / 闇雲に機能をリリースするのではなく、最中的な、あるいは中間のゴールを持って開発をすること。

記事のタイトルにある通り、『1回で正しく』できることはそうするべきです。

海外トレンドコラム

デザインをレビューする時にJason Friedがする質問 – Jason Fried

原題: Questions I ask when reviewing a design

BasecampのJason Fried氏がデザインをレビューする際に質問する事柄。
リストアップされている質問は毎回全て聞くことはないし、順番には意味はありません。自分がデザイナだったらどう答えるか、あるいはデザインを評価する立場なら、聞くべき質問を忘れていないか、優れたチェックシートになるのではないかと。

ツールを使わなくても問題ない – Jonas Downey

原題: It’s OK not to use tools

2連続でBasecampのブログ、Signal v.Noiseから紹介。こちらはJonas Downey氏による記事。
昨今フロントもサーバーもインフラも新しいツールがあふれています。それらツールの取捨選択、そしてもちろん利用することも開発者にとっては重要なタスクであると思いますが、それも時と場合を考えて。単純なHTMLとCSSのページを作るのに大仰なツールは必要なく、シンプルにできるものはシンプルに。適切なツールを適切に使いこなすことが大切です。

モバイルにおけるWebアプリケーション標準化の現状とロードマップ – W3C

原題: Standards for Web Applications on Mobile: current state and roadmap

このW3C作成のページでは、SVGやCanvasなどのグラフィックス、音声や動画などのマルチメディアなど13の標準についての現状とロードマップがまとまっています。仕様そのものの現状はもちろん、実装の状況、開発者向けのドキュメントの有無、テストの状態について一覧できる表があって便利です。

スタートアップにおけるデザインの役割 – Google Ventures

原題: Cheat sheet: Understanding the role of design in startups

記事のタイトルにはスタートアップにおける、とはありますが、Webに関するデザイン全般にも通じるデザインの役割について紹介しています。

A Complete Guide to Flexbox – CSS-Tricks

原題: A Complete Guide to Flexbox

CSSにおいての次世代レイアウト・プロパティともいえるFlexboxですが、弱点が1つだけあるとしたら、機能の全てを覚えきれないことではないでしょうか? このチートシートはそのFlexboxの機能をビジュアルとともに丁寧に解説してくれているので、これから覚えようという方はもちろん、いつもドキュメントを読み返している方もぜひ。

An Introduction to IndexedDB – Dev.Opera

原題: An Introduction to IndexedDB

まだまだブラウザの対応具合には難があるものの、IndexedDBの持つブラウザ側でデータベースを持てるという機能はかなり期待が高いものです。この記事でOperaのTiffany Brown氏は、そもそもIndexedDBとは何か、ブラウザの対応状況を解説し、おなじみTODOアプリを実装していく行程をコード例と共に紹介していきます。

パフォーマンス最適化 #perfmatters

Script-injected “async scripts” considered harmful – igvita.com

原題: Script-injected “async scripts” considered harmful

JavaScriptを非同期で読み込むことが、モダンブラウザにおいてもはやベストプラクティスとはいえない。
Ilya Grigorik氏はブラウザの内部動作を元にこの説について検証しています。

Docs on Performance Considerations – Modernizr

原題: Docs on Performance Considerations

プログレッシブ・エンハンスメントを行うのに便利なModernizrのパフォーマンスを鑑みた上で利用するにはどのようにするべきか。
Paul Irish氏によるアドバイス。

The Illusion of Motion – The Sea of Ideas

原題: The Illusion of Motion

レンダリング・パフォーマンスについて語る上でFPS(Frames Per Second)という単位は欠かすことができないものです。
この記事ではFPSとはなんなのか、そして人が動きを感知する錯覚とはどのように発生するのかについて詳しく解説しています。

Parallax Done Right – Dave Gamache

原題: Parallax Done Right

エフェクトの多い少ないはあるにしても毎日のようにパララックスを活用したWebサイトを見かけます。
皆さんもすでにお気づきのように大抵はパフォーマンスに難があり、時にはブラウザがクラッシュしてしまうこともあるほど。
この記事ではそのパララックスのパフォーマンスを向上させるいくつかのテクニックを紹介しています。

FrameViewerの使い方 – The Chromium Projects

原題: FrameViewer How-To

60FPSのゴールを達成するためには1フレームあたり16msの予算しかありません。
そのゴールを達成するのに必要なことはまず計測することです。
この記事ではGoogle Chrome(Canary推奨)が密かに提供しているFrameViewerという計測ツールの使い方について詳しく解説しています。

クローズアップ“ビデオ/スライド”

スライド/ビデオ

Breaking news at 1000ms – Patrick Hamann

原題: Breaking news at 1000ms

イギリスの新聞Guardianが次世代のWebサイトを作るにあたり実行したパフォーマンス最適化についてのスライド。
そもそもなぜパフォーマンスが大切なのか、よくあるパフォーマンスのボトルネックはどこにあるのかについてよくまとまっています。

Progressive Enhancement for JS Apps – Garann Means

原題: Progressive Enhancement for JS Apps

JavaScriptをメインとしたWebアプリにおけるプログレッシブ・エンハンスメントの仕方についてのスライド。
なぜプログレッシブ・エンハンスメントを行うべきなのかから、アプリケーションの状態の管理についてなど細かい部分についてのノウハウについて紹介されています。

Principles of Mobile Site Design: Delight Users and Drive Conversions

原題: Principles of Mobile Site Design: Delight Users and Drive Conversions

Googleがまとめたモバイルサイトデザインの原則。119時間にもおよぶユーザビリティテストの結果を5つのポイントに集約し、わかりやすく具体的なアドバイスをしています。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年7月2日にお届け予定です。★