続・ヤフー

仕事

インターフェイスを作っていくうえで、「速さ=正しさ」というmalaさんの言葉があるが、それを実現するための方法を具体的に表現してくれている文章を発見。
http://developer.yahoo.net/blog/archives/2008/01/the_7_habits_fo.html
サイト作成というものを考える上で、少し物の考え方の変わるとてもいい文章だと思ったので、やっぱり訳してみた。
色々なことに対応できるDBのスキーマ設計、様々な機能、見栄えの豪華な画像というのも大事だし、要望があればその機能を追加したサイトを作ってしまいたくなるけれども、最も重要なユーザビリティとのトレードオフとなることを常に意識しないといけないんだな。

        • -

1.LOFNO(=Look out for number one) No.1を目指せ。
No.1を目指せ。それはあなたのユーザをそうするということである。ユーザを導く標となれ。ユーザ体験を支配するという重要な任務を担うわけなのだから、言い訳して妥協することは許されないし、言い訳すること自体が許されない。多くの人は自分が担当していない部分に非難の矛先を向ける。仮に表示の遅い広告やフレームワークがあなたのサイトのスピードを遅くしているとしても、あなた個人の力でユーザパフォーマンスを最善化できるチャンスはある。全ての画像は最適化されているか？あなたがいいと思っているページの要素を、本当にユーザが使うかを測定したか？YSlow(=サイトのパフォーマンス評価を行うFirefoxのアドオン)は実行したか？あなたのサイトの最重要プライオリティーがパフォーマンスであることを他のメンバーに適切に伝え、導いてきたか？できないことではなく、できることを探し出せ。ありとあらゆる手を尽くすのだ。



2.Harvest the low hanging fruit とりやすい実を採れ。
あなたのサイトに最大限の効果をもたらす最適化の方法を見つけろ。もし、サイト内にたくさんのページが存在するならば、各ページに優先順位をつけろ。まずはトラフィックに負荷がかかった状態でサイトを見てみろ。その状態こそが多くのユーザがページを見ている時の状態なのだから。あなたのビジネスに重要で不可欠のページを特定しろ。パフォーマンス最適化のためのリストを作成し、どの方法が最もパフォーマンスを改善させるかという観点から、順位付けをしろ。また、同じリスト内で、どの程度の労力が必要かという観点から順位付けをしろ。たった一つの画像を取り除くことが、バックエンドの処理を丸々作り変えるのと同等のユーザ体感速度の改善につながることもあることを忘れるな。 Rules for High Performance Web Sites を実行しろ。これらのルールは、デザインや機能を妥協することなくサイトの速度を上げることができる、簡単に採ることのできる実であると、ヤフーの調査で判明しているのである。



3.Balance features with speed 機能と速度のバランスをとれ。
優れたパフォーマンスを目指すというのはチームの垣根を越えた規律である。私たちの優れたパフォーマンス調査によれば、ページがロードされるためのユーザ待ち時間の内の８０％〜９０％はフロント側の処理で占められている。これによってサイトに含まれる各要素(デザイン、機能など)が、ユーザに各コンポーネント(画像、javascript,cssなど)をダウンロードさせ、大きな待ち時間を作っている塊となっていることを明確にした。
Think Yin and Yang, a constant flux of alternating forces.(上手く訳せない。)
デザイナーは視覚的に人を惹きつける要素を付け加える。プロダクトマネージャーは機能的にすぐれた要素を付け加える。エンジニアは柔軟なフレームワークを付け加える。これら全てがユーザがページロードのための待ち時間を生み出すことと同じことなのである。画像を取り除き、余計な機能を省き、コンポーネントは圧縮しろ。これら全てがユーザを待たせる時間を減らすこととなるのである。よりよいレスポンスはサイトからの離脱を減少させ、ユーザビリティの向上につながるのである。それによってページビューが向上する。それによって、あなたもハッピーで、ユーザのストレスも減るんだよ。



4.Start early and make performance part of the process パフォーマンスをプロセスに入れて、早めに対応しろ。
あなたのサイトにパフォーマンスの問題があることが判明するのが、サービス開始直前というようなことがあってはいけない。その時には既に手遅れだ。デザイン作成や要求定義の時点でのパフォーマンスの視点をサイト作成過程に組み込め。開発サイクルの早い段階からパフォーマンスを過程の一部に組み込むのだ。大きなマイルストーンが来るたびにパフォーマンス試験を行え。全ての要素にはそれと関連するパフォーマンスコストが発生する。テスト方法を発展させ、コストを測定しろ。もしあなたのサイトが認証を行っているのならば、最も重要なユーザ層を想定し、その人たちがこれなら使うと思えるテスト目標を設定しろ。もし想定する最も重要なユーザ層がダイヤルアップ、ブロードバンドと様々な回線速度でアクセスしてくることが予想されるのならば、それぞれの回線速度でテストを行わなければならない。



5.Quantify and track results 測定し、結果を追跡しろ。
向き合え、私たちはみな良い仕事を評価されたいと思っている。ユーザ体験を向上させるためにできることはいくらでもある。それらの最適化の結果を測定することで、その努力はより報われるだろう。ツールの一覧表を持つのだ。実際にユーザが使ったときの感覚のパフォーマンスを測定しろ。あなたの組織が使うテストの方法やツールの差異を把握しろ。最適化を実行したのに、改善が見られない場合、それは測定方法が間違っているかもしれない。たくさんのツールが存在し、違ったツールを使えば、違った結果を示すことがある。様々なツールを比較するのだ。各ツールにはそれぞれ特徴があるが、それらを組み合わせることで、あなたのサイトがどのように振舞っているかを完璧に表すことができる。



6. Set targets 目標を定めろ。
結果を計る方法を確立したのならば、目標を定め、それをクリアしろ。目標設定にはあなたの競争相手のサイトを参考にすればいい。さらに言えば、ユーザが自分のサイトに来る前に辿ってくるページのパフォーマンスも参考にしたほうがいい。ロード時間が全く同じの二つのページがあった時、ユーザの感覚として、直前に表示されていたページのパフォーマンスに大きく左右されるという調査結果が出ている。目標を高く持ち、自分のため、自分のチームのため、何よりユーザのために



7. Ask questions and challenge answers 疑問をもって、答えを探せ。
どんなに賢い人でも、頭ごなしの決めつけを行っていたり、間違った説明を繰り返し行っいたりする。あなたの取ることのできる最善の手段は、多くの疑問をもって、自分で答えを探そうとすることである。そして、時間があるならば検証してみるのだ。間違った疑問というものは存在しないが、間違った答えというものは存在するのである。上手くまとまっているようにみえる説明、徹底的に調べたように見える調査結果に疑問を持て。その情報はどこから来たんだ？そのデータはいつのものだ？そのデータを得るためにはどのような手段が使われたのだ？他にはどんな代替手段があって、それらはなぜ使われなかったのだ？どのような前提がなされているのだ？時間があるのならば、なぜ実際に試してみない？結論を急がずに疑問を持つのだ。



8. (Bonus) Run YSlow おまけ YSlowを実行しろ。
YSlowはあなたのサイトがなぜ遅いかを教えてくれる。今すぐダウンロードして、参照した全てのサイトで実行してみよう！

          • -

検索はやっぱりgoogleの結果のほうが好きだけど、頑張れヤフー！！
僕も頑張る。