斉藤祐也の海外WEBテク定点観測＜Issue.14: 2014/05/01-2014/05/31＞
今月の定点観測はURLバーの改善、Object.observe()、アクセシビリティに足りないことなどを紹介します。
原題: 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
原題: Data-binding Revolutions with Object.observe()
JavaScriptでMVCを、というムーブメントが発生し、実際のプロダクトでも利用されるシーンが増えてきています。そんな中で生まれたデータ・バインディングと呼ばれるような機能へのニーズの高まりは必然ともいえるでしょう。そんなニーズに答えるObject.observe()という機能がChrome 36ベータ版にて利用できるようになりました。このAddy Osmani氏によるHTML5 Rocksの記事では、そのObject.observe()の使いどころから、現状の多くのMVCライブラリでの解決との比較など非常に詳細にわたる解説をしています。
原題: Asking why is not always the best strategy
﹃なぜ﹄を繰り返すことは本質的な問題にたどり着く方法だと言えると思います。しかし、HubSpotのプロダクト・デザイナであるDaniel Ritzenthaler氏は、闇雲に﹃なぜ﹄を繰り返すことは生産的ではないとしています。
記事では、より生産的な﹃なぜ﹄を問うには3つのレイヤーを意識するべきだとしています。
1つ目は利便性レイヤー。ここはある機能を使って実際に何を行おうとしているのかを問うレイヤーです。
2つ目はユーザビリティレイヤー。ここはある機能を使うとどんな結果を得ることができるのかを問うレイヤーとなります。3つ目は結果の望ましさのレイヤー。ここでは、目的を達した後、何が変化するのかを問うレイヤーです。
Daniel Ritzenthaler氏はプロダクトに対してこの3つのレイヤーを念頭においた﹃なぜ﹄はしっかりと時間を取って考え、答えるべきであり、その時間は決して無駄にならないと記事を結んでいます。
原題: Accessibility: The Missing Ingredient
WAI-ARIAが広くブラウザでサポートされている現在においても、アクセシビリティが必要要件とされるケースは決して多いとは言えないのではないでしょうか?
このA List Apartの記事で、IBMのフロントエンド・デベロッパであるAndrew Hoffman氏はアクセシビリティに足りていない材料は、実装の順番に対する認識であるとし、さらにコード例を通じてWAI-ARIAのroles、states、そしてpropertiesに関する簡単な実装を紹介しています。
原題: Do it once. Do it right.
Webのプロダクトの多くがアジャイルを採用し、短いサイクルのイテレーションで新しい機能をリリースすることは今では珍しくはありません。
Virbのプロダクト・マネージャを務めるRyan Clark氏はそのイテレーションにひそんでいるほころびを3つ指摘しています。
●イテレーションを言い訳にしない / 次のサイクルがすぐ来るからと言って、問題を先送りにしていいわけではない。
●イテレーションの破綻 / ただリリースするだけではなく、きちんと振り返り、フィードバックを次のサイクルに反映すること。
●中長期計画なきイテレーション / 闇雲に機能をリリースするのではなく、最中的な、あるいは中間のゴールを持って開発をすること。
記事のタイトルにある通り、﹃1回で正しく﹄できることはそうするべきです。
注目ニュースピックアップ
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回で正しく﹄できることはそうするべきです。
