Integrating UX into Agile Development

UX matters の Integrating UX into Agile Development から、Agile について気になったところをピックアップ(記事が長いので)。引用して訳した訳ではないので注意。

Success Factors for Agile UX

  • Agile プロセスには継続的なフィードバックが必要になるので、UX アーキテクト / デザイナーは独立したデザイングループではなく、プロジェクトチームのメンバーでなければならない

Adapting User Research to an Agile Approach

  • 毎日の終わりに、簡単なフィードバックをする。全員でどの問題を修正すべきか優先順を付け、合意を得る

One Agile Process

  • UX アーキテクトは次のようなフォーマットで書かれたユーザストーリーを推敲する: As a [role], I want to [action based on a feature], so [user goal].
  • 開発チームはスプリントの計画の前に半日から1日かけて各ストーリーを見積もる。開発者はしばしば、この時点で新しいストーリを追加する
  • スプリントの計画時は、開発チームはそのスプリントで実施するストーリーを選択し、タスクに落とし込む
  • スプリントの間、UX アーキテクトはチームに対して UX デザインの課題についてアドバイスし、成果物のユーザビリティと質を検証する
  • UX アーキテクトはチームがスプリント n のストーリーを実装している間に、スプリント n+1 のストーリーに取り組む

Team Dynamics

  • 開発者はユーザリサーチについても積極的に関わるべきで、ユーザリサーチの結果を待つのではなく、直接ユーザと話す必要がある。

関係ないけど

この UX matter のページ、Cmd + C (コピー)するとツールチップのような小さなウィンドウが出てうっとおしい。日刊スポーツのサイトで文字を選択した時も変なのが出るが、こういう OS デフォルトのショートカットなどに対してそのサイト独自の動作を割り当てるのはいい UX なのかね。

Advertisements
Integrating UX into Agile Development

Apple doesn’t have separate web design for smartphone browser

The following article analyse Apple website and try to know what Apple thinks about web site design for PC and mobile.

According to the article, the author find out that

  • Apple sets “viewport” width as 1024px, which is rendered as if 1024px width
    in mobile browser (mobile safari).
  • Basically each page has large image at top of the page. And 3 – 4 images lined
    up in 4 columns under the large image.
  • When you double tap a small image, mobile safari zooms the contents and it
    fits the screen size. At this point, you can easily read the text with the image.

It can be considered that apple.com is optimized both PC and mobile web browser with one design. With mobile browser, you can see the page contents at a glance, and then you can access information that you want with double tap. The author says that this design seems mobile web design that Apple upholds.

Apple doesn’t have separate web design for smartphone browser

サインアップとログインをシンプルにするテクニック

Smashing Magazine の記事から箇条書きで。

Innovative Techniques To Simplify Sign-Ups and Log-Ins

サインアップをシンプルにする

  • ユーザ名はサインアップ後に登録させる
    (ユニークなユーザ名を決める際、確認やエラー後の修正が必要になるので時間がかかるため、後で行わせた方が登録時の離脱が少ない)
  • パスワードの入力を1回にする
    (ユーザにパスワードの間違いがないか確認させるには、2回入力させるより、パスワードのマスクを外すオプションを提供する方が良い)
  • 郵便番号から住所を自動入力
  • 国のフィールドをオートコンプリート
  • 支払い者の住所を配送先住所と同じにする機能
  • ニュースレターのオプションはデフォルトでチェックしない。さらにニュースレターのサンプルを見られるようにする
  • Spam 避けには、CAPTCHA の代わりに JavaScript で隠したテキストフィールドを使う
    (JavaScriptで生成した隠しテキストフィールドを必須項目にする。または CSS で見えなくしたテキストフィールドの値がブランクになっているかどうかをチェックする)

ログインをシンプルにする

  • Email アドレスでもログインできるようにする
  • 現在のページを離れずにログインできるようにする
    (ドロップダウンやモーダルウィンドウでフォームを表示)
  • ログインフォームを表示した際は、最初のフィールドにフォーカスを移す
  • パスワードのマスクを外せるようにする
  • パスワードを忘れた人用のリンクにクエスチョンマークのアイコンを付ける
  • Submit ボタンをテキストフィールドと同じ幅にする
  • Twitter、Facebook や OpenID でもログインできるようにする
サインアップとログインをシンプルにするテクニック

Get Feedback or Fail

zurb.com のブログ記事 Get Feedback or Failの概要。

製品やサービスに対するフィードバックに対する 5 つの W について。

What: 効果的なフィードバック

  • Targeted: 質問に対する回答であること。「これについてどう思いますか?」といった質問に対しては、価値のあるフィードバックは返ってこないので、具体的な内容にする
  • Actionable: 次のステップを明確にするようなものであること
  • Valuable: Targeted かつ Actionalble であっても、価値のないフィードバックがある。例えば「ここの 5 px はもう少し暗くした方がいい」とか「Powerpoint 形式で Export できるといい」など。質問の的を絞って、こういった価値のないフィードバックを避ける

Why: 成功するプロダクト

カスタマーのためのプロダクトなのに、彼らのフィードバックなしでどうして成功できるだろうか。製品を作る事に時間、情熱やリソースを注いでも、カスタマーに正しい製品を提供できているかどうかを検証しないのは問題である。カスタマーこそが製品を作る、または壊す人々である

Who: カスタマー、クライアントそして (あなたの)チーム

  • Customer: カスタマーがあなたのプロダクトを使い、対価を払う。積極的に彼らのフィードバックを求めること。カスタマーのニーズを満たすプロダクトが成功する
  • Client: クライアントをあなたのカスタマーとして、エンドユーザをクライアントのカスタマーとして考える。定期的なフィードバックを通してクライアントを興奮させ、あなたのデザインに投資させ、彼らの意思決定を助けること
  • Your Team: 今あなたがどんな作業をしているかを常に共有し、質問を欠かさないこと。デザイナーだけでなく、エンジニア、プロダクトマネージャやマーケッターなどの意見に耳を傾け、様々な視点からのフィードバックを得る

Where & When: 今ここで!

製品サイクルのどの時点でも、カスタマーのフィードバックがその製品の方向性を決める手助けとなる。フィードバックの価値を学び、できるだけ早い時点で頻繁に行うこと。

A Personal Note

フィードバック得るのは最初はキツい出来事だった。ZURB で働き始めた頃、批判は才能や自分の仕事に対する攻撃のように思え、自身のエゴに大きな打撃を与えた。しかし 2, 3 年後、フィードバックなしでは仕事ができないようになった。フィードバックなしのデザインは、誰もあたなの決定に投資しないし、その仕事の価値を理解しない。飛躍を遂げるためには、フィードバックを受け入れ、それに対応し、効果的に製品を洗練させていくこと。

Get Feedback or Fail

大規模なjQueryアプリケーションを作る

Building Large-Scale jQuery Applicationsの超訳的な要約。

1. 依存関係の管理

必要なスクリプトの分だけ script タグを書く方法もあるが、依存関係の解決に script loader にはさらに便利な機能が用意されている (例えば、ブラウザがサポートする機能に応じた読み込むスクリプトを読み込む、など)。

現在、最も有力な script loader は RequireJS (by James Burke) と LabJS (by Kyle Simpson) で、それぞれに優れた点がある (RequireJSは構造化されたモジュールをサポートする、一方、より軽量なものを好むなら JabJS が良い)。この 2 つについてのもう少し詳しく知りたいなら、
この 記事が参考になるが、時間を節約したい人のために、次にいくつかのオプションを紹介する。

  • RequireJS – コードをモジュール化したいなら、これを使う事をおすすめする。RequireJS はコードを結合したり minify (圧縮)するツールも提供している
  • LabJS – 任意の順番でスクリプトをロードしたり、RequireJS より軽量なものを好むなら、これがベスト (LabJS で条件付きの読み込みを行う YepNope JSも要チェック)。
  • StealJS – JavaScriptMVC の一部だがこれだけを使うことも可能。コードの結合、圧縮、クリーニングができる
  • JSL Script Loader – 遅延ロード、指定順にロード、重複ロードの防止、キャッシングをサポート
  • Bootstrap – 軽量なことを最優先するならこれ

2. MVC と大規模jQueryアプリケーションの構造

ここではおすすめの MVC ソリューションを紹介するが、もし JS のデザインパターンについて
詳しく知りたいなら、このページで提供しているフリーの本をどうぞ。

なぜ JavaScriptMVC をすすめるか

JavaScriptMVC は大規模な jQuery アプリケーションを作るにあたり最も包括的なフレームワークで、たくさんの好意的な評価を受けている。JMVC は統合された開発ツールと再利用可能な MVC アーキテクチャの2 つに分けて考える事ができる。

MVC アーキテクチャについては、次のような特徴がある:

  • Model – Ajax リクエストやデータサービスのパッケージ
  • Controller – jQuery ウィジェットのジェネレータ
  • View – クライアントサイドテンプレート

開発ツールとしての側面は次のとおり:

  • 依存関係の管理、プロダクションビルド
  • ユニットテストおよび機能テストの自動化
  • ドキュメント

小さなアプリケーションを作る場合は、(一部で言われるように)オーバースペックだが、大規模アプリケーションを作る際には充分過ぎる程のメリットがある。

以下にその他のソリューションなども紹介する。

  • JavaScriptMVC – 大規模なアプリケーションを作るための all-in-one パッケージ。テスト、依存関係の管理、ビルドツールおよびクライアントサイドテンプレートなどを含む。Grooveshark がこれを使って書き換えられた。(Video Preview, Demos & Download)
  • Backbone – 任意のコンポーネントを自分で選んで使いたいなら、これは優れた DIY MVC ソリューションになる。(Demos & Download)
  • SproutCore – デスクトップアプリケーションのようなリッチなアプリケーションを作るなら。小さいアプリケーションには向かないと思われる。Apple などが使用。(Video Preview, Demos & Download)
  • Knockout JS – MVVC アーキテクチャ。(Demos & Download)
  • Eyeballs JS – サーバサイドに Ruby を使っていたり、Ruby に慣れている人は試してみる価値あり
  • Sammy JS – Route ベースのアプリケーションを手軽に作るために、MVC の C (コントローラ)部分を提供する軽量な jQuery プラグイン。単一ページのJS アプリケーションを作る場合、検討の価値あり
  • Choco – Sammy と JS-Model をベースにしており、ジェネレータをサポートし、拡張性も高い。もう少し洗練される必要があるかも。(Video Preview)

大規模 jQuery アプリケーションを作る際のパターンに関する、その他の情報源

3. テンプレート

個人的には jQuery-tmpl と Mustache が最も便利だったが、場合によってはオーバースペックになるので、個々のニーズに合うように他のオプションも上げておく。

4. モジュール間通信

以下にいくつかの異なる pub/sub の実装を上げる。

5. ビルドプロセスとスクリプトの結合

大規模なアプリケーションにとっては、最終リリースとなるコードを生成する際にいくつかのタスクを処理する事が重要だ。基本的には、JavaScript 界隈でよく使われている Ant を使用するのがおすすめ。Ant を JavaScript のプロジェクトのビルドツールとして使う場合は、このチュートリアルが役に立つだろう。

また、JavaScript アプリケーションのビルドツールとしては次のようなものもある。

6. スクリプトの最小化 (Minification)

プロダクション環境では、ロード時間を短くするために、スクリプトの Minification (最小化)が重要となる。最小化はスクリプトの結合プロセスの一部として行われる事が理想的である。

7. テスト

QUnit による JavaScript/jQuery コードのテスト

以下に QUnit を使ったテストの良いチュートリアルをあげる。テストツールは他にも JSUnitFireUnit などがあるが、QUnit はこれらの中で最も幅広く使われており、個人的にはこれを使っている。

JavaScriptMVC の FuncUnit を使ったユニットテスト

FuncUnit は QUnit の Add-on で、ブラウザや Selenium と組み合わせて使う。また、EnvJS 内で基本的な QUnit のテストを自動化することができる。

jQuery のためのテスト駆動開発

以下に、jQuery のためのテスト駆動開発に関するすばらしいチュートリアルがある。

jQuery のテストでブラウザの起動、テストの実行、結果レポートを自動化

テスト用のフレームワークを使えば、いろいろなプラットフォーム上の様々なブラウザ上で、
たくさんのマニュアルテストを行わなくても良くなる。John Resig は、WebDriver (Java)、
Watir (Ruby) および JSTestDriver を勧めている。また同様のツールでは、Selenium RC人気がある。

Envjs と BumbleBee を使った JavaScript のテストとデバッグ

Envjs はブラウザを便利なスクリプト環境にするJavaScript で実装されたツール。そして Envjs で使うテストツールキットが Bumble で、今年リリースされた。

jQuery でユーザインターフェイステストを自動化

UITest は jQuery プロジェクトの UI テストを自動化するのにおすすめ。オフィシャルページや、jQuery Bay Area Conference のスライドにいいサンプルがある。他に、Selenium と Coded UI を使った UI テストについてのディスカッションがここにある。

その他の情報

大規模なjQueryアプリケーションを作る

API プロバイダが犯しがちな 10 の間違い

10 Common Mistakes Made by API Providers – ReadWriteCloudの要訳というか超訳。

1. いつも全部が正しく動作していると仮定する

データベースのエラーやバックエンドの処理遅延などによって API の出力がおかしくならないように、ユーザに提供する前に依存性を確認して、APIがどう動くかを確認すること。開発者(APIのユーザ)は stack traceなどではなく、正規のレスポンスフォーマットでエラーコードなどが返ってくることを期待している。

2. お粗末なコミュニティ管理

開発者を引きつけるには、コミュニケーションを取って彼らの役に立つこと。開発者をパートナーと考えて対応する。

3. API ビジネスプロセスの規模を予測しない

規模が小さいうちは、ガバナンスの必要性は少ないが、API のトランザクションの規模が大きくなると、ファイナンスや法務にとっても重要な問題になってくる。

4. API をウェブサイトと同じドメインに置く

ウェブサイトと API それぞれのスケーラビリティを別個に扱えるように、別のドメインにする(twitter.com と api.twitter.com のように)。

5. 実際の環境でテストしない

もし、ウェブサイトがその API を使っていないなら、API を使ったサンプルアプリケーションをいくつか作ってみること。そうすることによって、API で取得できるデータの内容(組み合わせ)が適切かどうかを知る事ができる。API を使ってあなたのウェブサイトを再現できないとしたら、その API は修正する必要がある。

6. 悪質な挙動を想定しない

意図的なもの (頻繁なリクエスト、渡される JSON や XML データによる攻撃、SQL インジェクションなどのテクニック)や、スケーラビリティに関係するものを考慮して設計する。

7. ブラックボックステストをしない

アップデート時にはウェブサーバの設定変更等も行う事があるので、ユニットテストだけではなく end-to-end のブラックボックステストも行うこと。

8. API をコアビジネスと認識しない

成功したメディア、オンラインショップ、ウェブ関係の会社は、しばしばそのトラッフィックの 50% 以上が API 経由になっている。従って API を製品の 1 つとして扱うこと。

9. API について役員レベルのマネジメントを行わない

他の新規プロジェクト、ビジネスや技術と同じように (API についても) 理解と明文化されたゴールや評価基準などを持ち、各部署レベルの目標に落とし込んでいく必要がある。

10. エラーを tunneling する

よくあるのが、エラーなのにレスポンスコード 200 OK で返したり、すべてのリクエストを GET, POST で処理したり (PUT, DELETE を使わない)、ユーザに content-type を指定させない、など。

API プロバイダが犯しがちな 10 の間違い

Usability vs depopulated atmosphere

I read an interesting posts about a storategy of creating online service/community.

She wrote about not adding functions consciously even though it seems basic function at the beginning of the site. There is a qoute from another post by kensuu who provides (actually his company provides) Nanapi. Nanapi is website where people post lifehack technique. And it is said the reason why Nanapi didn’t provide search function at the beginning.

In early stage of a site, number of users, number of contents/posts are small. If users search the site, there is relatively higher possibility that he can not found the information that he want. Then he must feel that the site is not popular. If there is atmosphere of under populated, people leave and will not visit again.

There seems to be a strategy that creating initial version of your service less usable for some points consciously to avoid making depopulated atmosphere.

Usability vs depopulated atmosphere