Flashエンジニアnao ozawaです。最近あんまりゴリゴリとFlashでコーディングしていません。なんでかなぁ！まるで働いていないみたいじゃないですか。一応ちゃんと仕事してるんですよ？
まぁ、そんな感じの毎日なので、実はここ数日、作業のかたわら、スマートフォン向けページのレイアウト方法を色々考えております。

・ブラウザの画面回転するのめんどくさくね？

　みなさんご存知のように、iPhoneを筆頭に最近のスマートフォンは、携帯を横に向けると、合わせてくるりと画面が横レイアウトに変わります。斯(か)く言う私も初めてソレに遭遇したときには驚きを隠せず、暫くは日がな一日iPhoneをくりくりと縦にしたり横にしたりして過ごしていたものです。それはそれは楽しかった。
が、しかし、最近スマートフォン向けのページを作る側にまわってみて、はじめて気がついたのです。

画面の幅が変わるのって、めんどくせぇ

もう喜んでる場合じゃない。あり得ないほどめんどくさかったのです。

　そう思ったきっかけはクリッカブルマップ。懐かしい響きですね。Flashが全盛を極めてからは、みんなすっかり利用されなくなってきていますが、残念ながらiPhoneではFlashは動きません。そのため、どうしてもクリッカブルマップを使いたかったんですが、ここで問題になったのが、画面の回転なのです。
　クリッカブルマップは画像上の絶対座標によってクリックエリアを決定しています。手持ちのiPhone4では画面が回転した時も横幅の拡大は「表示」の拡大という扱いになっているため座標はズレないのですが、実はXPERIA(Android1.6)では、横表示になった時に画面の再描画が行われるため、画像が縮小されます。
　じゃぁ、初めから画像の表示サイズをピクセルで指定しておくとか、機種ごとにテンプレートを用意すればいいんじゃない？という意見もあろうかと思います。自分でもそう思います。ですが、それも面倒じゃnそこは、エンジニアの端くれとして、スマートにコードを書いて解決したいと決意した次第なのです。
　そこでDOMの登場です。前置きが長くなりましたが、やっと本題です。

Q. DOMってなによ？
A. Document Object Modelの略で、簡単にいえばJavaScriptからHTMLタグとかCSSのパラメータとかを書き換えられるHTML5時代のスタンダード・ウェポン。iPhoneでも使えるよ！ジオン公国のツィマッド社が開発した陸戦用モビルスーツとは親戚関係。

・座標は比率から求めよう

　画面サイズも違えば縦と横での変化もあるページを、ひとつのコードで処理する。手っ取り早くコレを実現するには、画面幅に対して画像は80％のサイズ、というように、画面の横幅に対する比率を基準にしてしまえばOKです。
残りの数値は、全て画面が描画される都度に計算しましょう。なお、タグの属性の指定には「setAttribute」を使います。

[イメージタグ]
<img src="img/map.gif" border="1" usemap="#map_test" name="map_test" id="map_img" />
＊サイズの指定はしない

[JavaScript]
// mapという新しいオブジェクトにID名「map_img」(imgタグで設定したID)を割り当て
var map = document.getElementById("map_img");
// mapというオブジェクトのwidth(横幅)にwindow.innerWidth(画面の横幅)の80%(* 0.8)を指定
map.setAttribute("width",window.innerWidth * 0.8);

これで、画像の横サイズは、画面の横幅が100ピクセルの時は80ピクセルに。640ピクセルなら512ピクセルになるわけです。

で、あとはクリッカブルマップの<area>タグで、クリックエリアを指定するcoords属性の座標を地味に計算。
例えば100x100pxの画像の(x=20,y=10)の場所に座標がある場合は、(x=100*0.2,y=100*0.1)と表せます。
キモは画像のサイズを1としてゼロ座標からポイントまでの長さを小数点で表すこと。この例では、aポイントは画像の横幅に対して1:0.2の位置、縦幅に対して1:0.1の位置となるという事ですね。

var ax = document.images["map_test"].width * 0.2;
var ay = document.images["map_test"].height * 0.1;

こんな感じ。見たまんまですね。比率は、Photoshop等で頑張って測りましょう。

こうしてax,ay〜dx,dyまで4点の座標を求めたら、createAttributeでタグに直接記述されていない(予め書かないでおいた)coords属性を作成し、適用します。

var map_area = document.getElementById("AreaID");
var set_coords = document.createAttribute("coords");
set_coords.nodeValue = ax + "," + ay + "," + bx + "," + by + "," + cx + "," + cy + "," + dx + "," + dy;
map_area.setAttributeNode(set_coords);

これで座標の指定は完璧。 座標指定のスクリプトをhoge()など好きな名前の関数にして、

window.onload = function(){
	hoge();
}

とすれば、ページを読み込んだ時に実行され、無事クリッカブルマップが動くようになります。

・回転した場合の処理

iPhoneには「onorientationchange」という魔法の呪文でブラウザの回転イベントを取れるのですが、Androidでは未対応なので、ここは素直に「onresize」(画面サイズが変化した場合のイベント)を使います。

window.onresize = function(){
	hoge();
}

これでOK。 本当は「回転しないように」出来れば素晴らしいのですが、今のところ、そんな神コードは思いつかない(無くはないけど面倒)ので、まぁ今日のところは、このへんで勘弁してやろう。iPhoneめ参ったか。フヒッ。

13:49 追記
書きなぐった記事を読みながら揚げパン食ってたら思いついた。回転しない(ように見える)のは、結構簡単にできるかも？上手くできたら後日投稿します。

・まとめ

今回はクリッカブルマップでしたが、この考え方で、ブラウザの横幅が変化してもレイアウトを維持できるコンテンツが作成可能です。
使い方は色々あるので、ぜひ皆さんもDOMってみてください。

つーかiPhoneでFlash動くようになんないかなぁ！ジョブス爆発しろ！
この秋出ると噂の新型MacBookAirも、きっとまた買っちゃうんだからね！

では、また。

日時: 11:54 | パーマリンク | コメント (1) | トラックバック (0)

yamaokaです。

以前「エラスティック・レイアウトのご紹介」というエントリを書きましたが、 実際にエラスティック・レイアウトを実装しようとするとなかなか大変です。 画像のサイズを動的に変えるにはどうしたらいいのだろう？　というところでどうしても考えこまざるをえなくなります。

しかし実は、ほとんどの最新のブラウザにはズーム機能がついています。 もしあなたがFirefox 3を使っているなら、 ツールバーの「表示」から「ズーム」を選択してみてください。 「拡大」「縮小」「リセット」「文字サイズだけ変更」というメニューがあると思います。

Firefox 3でズーム機能を使う posted by (C)フォト蔵

従来のブラウザのズーム機能は文字サイズだけを変更するものでした。 そのためレイアウトが崩れてしまう可能性があったので、 解決策として登場したのがエラスティック・レイアウトです。

しかし、Firefox 3のズーム機能は文字サイズだけではなく ページの表示そのものを拡大・縮小することができます（ぜひ試してみてください）。 Firefox 3のページ全体をズームできる機能は、 もともとOperaやIE7に実装されていた機能をFirefoxが3になって取り入れたものです。 IE7の場合だと、ステータスバーの右端にズームする倍率を切り替えるためのスイッチがあります。

IE7でズーム機能を使う posted by (C)フォト蔵

残念ながら現在最新版のSafari（Mac版、Windows版とも）とGoogle Chromeでは同様のズーム機能が実装されていませんが（拡大・縮小できるのは文字サイズのみ）、 WebKitの開発版では既に実装されているようなので、そのうち使えるようになりそうです。

だんだん標準的に使えるようになっていくブラウザのズーム機能。 ひょっとしたら、エラスティック・レイアウトを無理して実装する意味がなくなりつつあるのかもしれません。 ただ、現状のブラウザのズーム機能に問題がないわけではありません。 ブラウザごとに異なる挙動をすることや、そもそもアクセスしづらい機能であることなどです。 もっとズーム機能が使いやすいものになってくれるといいですね。

日時: 16:41 | パーマリンク | コメント (4) | トラックバック (0)

yamaokaです。

最近タブをメタファーにしたナビゲーションをよく見るようになりました。タブには大抵、内容を示すキャプションが付けられています。さて、どこからどこまでがリンクでしょうか。どの部分をクリックすればそのタブを選択できるでしょうか。

例えば、キャプションの文字だけにリンクが貼られている場合。利用者はタブの中のさらに狭い範囲、文字の部分を狙ってクリックしなくてはなりません。

実はマウスの操作というのは難しいのです。狭い範囲を狙って指定することにはあまり向いていません。目的到達のために狭い範囲のクリックを強制するのはどう考えてもよいインターフェースではありません。

そこで大抵のタブ型インターフェースではタブの枠の中全体をリンクとして扱えるようになっています。

アンカー要素のdisplay属性をblockにして、必要な高さと幅を与えることでリンクの範囲を四角形に広げることができますね。大きさを固定値で指定してもかまいませんが、そうするとキャプションの文字の大きさによってははみ出てしまうかもしれません。padding属性を使えば大丈夫です。

.nav a {
  display: block;
  padding: 5px 10px;
}

マウスのポインタがタブの上に乗ったときにタブの色に変化をつけてあげると、よりリンクであることを強調することができるかもしれません。

.nav a:hover {
  background-color: #DEE;
}

ほとんどのサイトで同様のテクニックが使われていて、利用する側としては当たり前のように使っているインターフェースはいろいろとあります。

しかしそういうインターフォースでも、「なぜそうなっているのか？」と考えてみると面白いと思います。

日時: 18:41 | パーマリンク | コメント (0) | トラックバック (1)

五十川です。

携帯サイトの見栄えをシミュレートするウェブアプリ作りました。と言っても、実際に作ったのはかれこれ半年以上前で、手直ししてから公開しようと思ってたら、結局「guid=ON」を付け足したくらいであとは放置だったので、さすがにいい加減晒そうと。

任意のヘッダでリクエストして、レスポンスの絵文字とか変換してサイトの見栄えを確認するというものですが、これはそもそもExt JSをいじってた頃に、Ext JSでこういうの作ればいい感じになるんじゃね？ということで、丁度2.0がリリースされた頃にデモ用に作ったものなのでした（なので、かれこれ半年以上前）

実機テストの代用になるわけでは、もちろんありませんが、絵文字も含めたマルチキャリアでの見栄えを手軽に確認したいときなどに、わりと便利に使えてたりします。

スクリーンショット

機種ごとのプリセットのヘッダグループをYAMLファイルに書いておいて、以下のようにプルダウンメニューから選択して切り替えます。この画面で直接ヘッダの値を書き換えたり、任意のヘッダを追加したりもできます。

レスポンスのヘッダとボディ（HTMLソース）を確認できますが、HTMLソースは以下のようにタグなどを色分けして、行番号を付けて表示します。

アクセス履歴を保存してドメイン別に表示します。ページタイトル、URL、アクセス日時で並べ替えができ、それぞれダブルクリックで、そのページに再度アクセスできます。

その他の機能

• QRコード表示します。
• Basic認証をエミュレートします（開発環境には必須かな）
• iモードの「UTN」と「guid=ON」をエミュレートします。リクエストヘッダのUser-Agentに個体識別情報が含まれる場合は、UTN属性のある要素からのリクエストでは個体識別情報を含むUser-Agentを、それ以外は個体識別情報を除去したUser-Agentを送信します。同様に、リクエストURLのクエリーストリングに「guid=ON」が含まれる場合、X-Dcmguidヘッダが設定されてれば送信します。
• iモード以外ではCookieの送受信をエミュレートします。

サーバサイドのプログラムは諸般の事情でPHP4スクリプトです（PHP5でも動作確認してます）。PHP4でのHTMLスクレイピングには限度があるので、そのあたりの処理は限定的になってます。

試してみようと思ったかたは

以下アーカイブをどうぞ。

mobile-simulator-1.0.tar.gz

Google Codeに移動しました（2008-07-10）

しかしこいつは、各機能を実現するのにさまざまなオープンソースソフトウェアを利用させていただく他力本願なつくりなので、アーカイブの中身だけでは動きません。以下利用させていただいているソフトウェアの一覧です。それぞれ必要な段取りは、アーカイブのREADMEをご覧ください。

Ext JS 2.x

2.0と2.1で確認してます。それ以前のバージョンでは動きません。

MobilePictogramConverter 絵文字変換ライブラリ

絵文字の変換表示にはこちらを利用させていただいてます。

QRcode Perl CGI & PHP scripts ver. 0.50

QRコードの表示にはこちらを利用させていただいてます。

PEAR HTTP_Client

仮想HTTPクライアントのコアはこちら。

PEAR Text_Highlighter

レスポンスボディの強調表示に。

spyc 0.3

YAMLのパースはこちら。

Jsphon - JSON in PHP

JSONのエンコード/デコードはこちら。

SILK ICONS

アイコン画像に利用させていただいています。

日時: 03:41 | パーマリンク | コメント (9) | トラックバック (0)

miyakeです。Webアプリケーションにおけるユーザーインタフェースの代表格と言えばフォーム。今日はそんなフォームのUIを作るに当たって、普段自分が心掛けていることをつらつらとご紹介します。

■チェックボックスやラジオボタンはfieldset,label要素でくくる

チェックボックスやラジオボタンには一般的にその内容を表すテキスト（ラベル）が付けられますが、input要素だけでマークアップした場合、チェックボックス（ラジオボタン）の部分しかクリックすることができません。

label要素を用いることで、ラベルの部分をクリックしてフォームを操作することが可能になります。これは是非設定しておきましょう。

ラベルをクリックできると思って期待を裏切られると、かなりのストレスになりかねません。

また、そのチェックボックスやラジオボタンのグループをfieldset要素で囲んでおくことをお勧めします。マークアップ的な理由というよりも、後からCSSでデザインをに手を入れる時に、CSSだけで対応できる範囲が広くなることのメリットが大きいです。

実際のHTMLは以下のようになります（紙面の都合上適宜改行していますが、実際は一行で書く方が安全です）。

<fieldset>
 <input type="radio" id="fav1" name="favorite" value="1" />
 <label for="fav1">犬好き</label>
 &nbsp;&nbsp;
 <input type="radio" id="fav2" name="favorite" value="2" />
 <label for="fav2">猫好き</label>
</fieldset>

以下、長いので続きを読むでどうぞ。

続きを読む "フォームのユーザビリティを改善する10のTips" »

日時: 12:53 | パーマリンク | コメント (7) | トラックバック (2)

Sashaです。気がついたら自分の生活の一部だった。そんなサービスが人に小さな幸せを生み出します。そんなサービスを作ることが出来たらいいですよね。

でも、人っていっても、色々いますよね。私たちは、だれの生活を思い浮かべたらいいのでしょう。

UIという文脈の中で、ペルソナ（personas）という言葉の意味を聞いたことがありますか？ペルソナは、マーケティング、デザイン、製品開発など幅広い分野で、顧客中心思考を実現するためのひとつのキーワードとして論じられています。

UIに関していえば、樽本徹也氏が「ユーザビリティエンジニアリング」という本の中でこの言葉について説明されていますので、ご紹介させていただきます。

ペルソナとは、UI設計の中で設計チームの意思決定のよりどころとなる「ユーザ像」をさします。「だれのためのサービスか」、を明らかにすること。当たり前のようなことですが、日々、バグやクレームや締め切りに追われる開発者たちにとっては、本当に忘れやすいポイントだということを、私もよく実感します。

ペルソナは、実在する人物でも、私たちが勝手に作り上げる人物でもなく、「発見するもの」です。樽本氏はペルソナを構成する以下のような手順を紹介しています。

1. 数十名規模でインタビューを実施する
2. 同じようなニーズや目的を持っているユーザーを、グループ化する
3. グループごとに、ライフスタイル、ITリテラシー、サービス利用の目的などを踏まえてユーザ像（ペルソナ）を定義する
4. このペルソナを持った人物に、"もっともらしい"個人情報をつけてあげる（キャラクター誕生！）

例えば、

右脳優子さん(35歳)
主婦。最近ちょっといいデジカメを買った。決してプロレベルの写真ではないけれど、自分の写真の中の一人息子の笑顔をたくさんの人に見せたくてフォト蔵を利用。ネットサーフィンや情報収集のためにPCには毎日短時間ずつ触れている。

左脳秀蔵さん(29歳)
IT企業に勤めるプログラマ。ネットには四六時中つながっていて、職業的興味から暇さえあれば新しいサービスを試している。最近フォト蔵のAPIをつかって何か面白いことが出来ないか模索中。

その他数名・・・。

5. ペルソナに優先順位をつける！！

私たちは、優先順位の「最高値」をつけられたペルソナ、つまり、プライマリペルソナを、セカンダリペルソナより、「えこひいき」しなければならないんですよね。もちろん、セカンダリペルソナを排除しなければならない、ということではありません。限られた時間でより多くの人々の生活にとって「なくてはならない」サービスを作るには、『より多くのニーズ』を満たすよりも、『より多くの人のニーズ』を満たして「お得意さん」になってもらう必要があります。でも『より多くの人のニーズ』が実際に『多すぎるニーズ』であると、事業は方向性を見失ってしまうものです。ですから、『より多くの人を代表する、一人の人のニーズ』に意識を集中させる必要があるのです。サービスの方向性で重要なのは、「どのキャラクターからの要望」なのかを議論すること。多様化するユーザーニーズにいきあたりばったりに対応しようと思っても、相反する要望が出たときに行き詰ってしまいますが、ペルソナを使えば迅速な意思決定が可能になるかと思います。

ちなみに、「右脳優子さん」と「左脳秀蔵さん」を紹介するにあたり、私は手順の1番目の「インタビュー」を実際に行ったわけではありません。この点でこの二人のキャラクターは「勝手に作り上げられた人物」であると突っ込まれるかも知れませんが、この二人のキャラクターは実際にフォト蔵ユーザーの中に存在するペルソナですし、そもそもここで話しているサービスにしてもこの記事を書くための一例ですので、大目に見てください。

フォト蔵の場合、右脳優子さんは左脳秀蔵さんより多くのユーザーを代表しています。ですので、右脳優子さんのニーズは左脳秀蔵さんのニーズより比重を置かれるべきです。より多くのユーザーを代表するペルソナを作れば、「より多くの人を幸せにする」というとても複雑な事業目標も、「まずは右脳優子さん一人を幸せにしよう」というシンプルなものに整理され、方向性がブレにくくなると思います。

まずは、右脳優子さんの生活を思い浮かべてみる。どうやったら、ひとつのサービスがこの人の生活の一部になれるのでしょうか。どうやったら、この人を「ちょっと幸せ」にできるのでしょうか。

『まずは、一人の人を幸せにしよう』

それをいつも考えていようと思います。

日時: 01:37 | パーマリンク | コメント (3) | トラックバック (2)

はじめまして。今月から入社した5日目の新人のyukiです。yukiですが女性ではありません。残念です。

ウノウでは毎日新鮮な気分で仕事させてもらっています。毎日違う机や椅子、ボールというのもすごいですね。朝もゆっくりなのでシャワーを浴びて、洗濯物を干してから出かけたりしてます。

さて今回は初めてラボを書くことになりました。諸先輩方のためになる記事、さすがです。そこで自分はちょっと方向性を独自にとってみようと思います。

Yahoo! DEVELOPER NETWORK(英語)　より、Yahoo! UI Library(YUI) のお話です。結構有名どころだと思いますが。

最近ではリッチなインターフェースのサイトも多くなってきました。通信速度やコンテンツ内容はすばらしくても、「使ってもらえる」サイトでなくてはユーザーの不満がたまります。去ることはなくても、より使いやすいサイトが出てくればそちらに流れるかもしれません。

Movable Typeなどを使って手軽に製作できるようになりましたが、あまりに使わているためにどうしても差別化が必須になる場面があります。そういうときに、ちょっと手軽に追加できるライブラリを知っておくといいかもしれません。幸い設置方法やサンプルなどもしっかりあり、初心者向けに作られてる感じです。

この他にも、ブラウザの違いを吸収して同じ大きさで表示してくれるFonts.cssや<ol>タグなどの表示誤差をリセットしてくれる Reset.cssなんかもあります。自分の手ですべてを調整しようとすると大変ですが、いったんYUIに調整してもらってから自分で修正したりすれば、大分作業がラクになります。

※Yahoo! UI Library ライセンス情報

日時: 16:31 | パーマリンク | コメント (0) | トラックバック (0)

デジタルな世界で生きている同業者の皆さん、ペーパーレスの世界に過信しすぎてはいませんか？

今日は、紙を使ってプロトタイプを作ることの意義と、方法を紹介します。

紙プロトタイプは、ユーザビリティ・テストのれっきとしたメソッドであることをご存知でしたか？筆者は、前職ではよく紙と、ペンと、はさみとのりを使ったプロトタイプを作成していました。ウノウに入ってからは大体wikiやPhotoshopだけを使ってモックを作るようになり、フォト蔵チームでも大きなUIの変更の際は大体、
(1) WikiやBTSで仕様を簡単にまとめる
(2) PhotoshopやPowerPointでモック（四角がいっぱい並んでいる）
(3) HTMLでモック(大体の動作を体感)
というステップを踏んでいます。

でも、最近になって作業効率とかユーザビリティテストとか考えるようになったら、なんだかものすごく紙が懐かしくなってきたんですね。ちょうどA List Apartでも紙プロトタイプが紹介されたので、この際、紙資源がもったいないとか、アナログだとか字が汚いだとか言う批判を恐れずに、社内外にこのメソッドの布教活動をしてみようという気になりました。

紙プロトタイプの導入は、上記の(1)から(3)までのステップを一段階増やすもので、まずは(1)と(2)の間に入ることになります。一段階増やしていながら、ユーザー想いなプロダクトを作る上で最終的に効率を高める結果にあると、私は思います。

紙プロトタイプは何に使える？

紙プロトタイプは、人とコンピュータのインタラクティビティを生み出すプロダクトであれば、サイトであろうと、ソフトであろうとハードであろうと、何にでも応用できます。

必要なもの

必要なものは、紙とペンのほかに『はさみ』。あと、付けたり貼ったりが繰り返すことのできるタイプの『のり』があれば完璧です。『はさみ』と『のり』が、ただ単に紙にメモ程度にモックを書くことと、プロトタイピングの大きな、大きな違いです。なぜなら、この二つによって、例えばdiv id="login"の中身だけ、上からペタッと変えることができるじゃないですか！

紙プロトタイプの効果

紙プロトタイプの効果は、例えば次のようなものがあげられます。

意義1: プロダクトがまだ図面段階、骨組み段階にあるときに、ユーザーからのフィードバックをいち早く開発に取り入れる、早い段階で軌道修正が可能。

意義2: ニコニコ笑顔で修正できる。エンジニアマインドな開発者が言う「ここ修正して」の一言はPhotoShopを使って丹念にモックを作ったデザイナーの心を激しく傷つけます。紙だったら、いつでもやさしい人でいられます。

意義3: メモが書き込みやすい。チーム内、社内、あるいは実際のユーザーさんに見てもらって得たフィードバックを、ダイレクトに書き込むことができます。Photoshopだったら、Textレイヤーを作って、配置して、フォント設定して、あぁめんどくさい。

意義4: 簡単にインタラクティビティをデモれる。ラボブログ当番な私は今日中にこの記事を仕上げなければならず、自分で今からこれを説明するための紙プロトタイプを作ることができないので、手抜きします。さっきのA List Apartの例をご覧ください。

真ん中の方にいくつかある写真をごらんいただくと、紙プロトタイプで作られた簡単なサイト画面で、セレクトボックスのインタラクティビティ、ログインフォームのインタラクティビティが間単に表現されていることがお分かりいただけると思います。

紙プロトタイプとユーザビリティテスト

もうお気づきかもしれませんが、上であげたような紙プロトタイプの意義は、ユーザビりティテストと深い関係にあります。もちろん、ユーザビリティテストとは、チーム内、社内、あるいは実際のユーザーさんを用いてのどの場合も含まれます。紙プロトタイプがもたらすユーザビリティテストの可能性とは、どんなものがあるでしょう。

(1) 問題を見つけ、解決法に関するアイデアを誘発する。
(2) ユーザーさんがクリックするところをペンでマークできる。
(3) ユーザーさんに、「そこをクリックしたら何が見えることを期待するか」を描いてもらったりもできる。
(4) ネットワークや、PCなど、環境の準備がまったく不要で、カフェでコーヒーを飲みながら、「ねえ、ちょっとこれ見てくれる？」という感じで簡単にユーザビリティテストを開始できる。

もちろん、読み込みのスピード、スクローリングを紙でデモるには相当な工作能力を要するなど、限界もありますが、上手に使えば、ユーザーにとっても、開発にとってもハッピーなメソッドです。

それになにより、紙を使って工作、楽しいですよね？

日時: 17:06 | パーマリンク | コメント (3) | トラックバック (1)

Sashaです。

明けましておめでとうございます！2007年も皆様にとって素敵な一年になるよう、心からお祈り申し上げます。今年もウノウラボをよろしくお願いいたします。

さて、今日は「選択」の話をしたいと思います。

この記事にたどり着いた皆さんは、例えばブックマークから、またはRSSリーダーから、Googleから、誰かのブログから、紹介してくれた誰かのメールから、あるいはウノウのサイトから、どういうわけかここへやってきました。どなたかの紹介でダイレクトにここへやってきた人もいるかもしれないし、様々な他の情報を切り捨て、数あるリンクの中からこのページへのリンクを選択した人もいるかもしれません。その選択は、いったいどのように行われたのでしょうか？ダイレクトにここへやってきた人は、「選択なんかしてない」とおっしゃるかもしれません。ですが情報がこのようにあふれかえっている世の中で、意識的であろうと無意識的であろうと、人は「選択」せずに情報を見つけ出すことができるでしょうか？

心理学では、「選択肢があるときとない時の人の満足度」の違いについて繰り返し研究がなされてきました（Sashaは心理学畑出身です）。同じ結果に行き着いたとしても数ある選択肢の中から選んだ時の満足度は、他に選択肢がなかった時の満足度と比べてはるかに高い傾向にあるのです。でも、選択肢が多ければ多いほど人の満足度は高まるのでしょうか？

今まで運がよければ2つ、3つあればラッキーだった選択肢（＝情報量）は、情報化社会によってこの10年ほどの間に200にも2000にも増えたことでしょう。ところが、ある一定の数を超えると、人はとたんに「選択」という自由行動を完全に放棄してしまいます。「選択する」という行動をやめない強い『自由意思』を持った人手さえ、選択の作業を自動化したり、単純化したりする業を付け始めます。

それでは、選択肢が膨大になった時、人はその数をどのように絞り込む傾向にあるでしょう。あなたは、何を使って自分に与えられた無数の選択肢を絞り込んでいるでしょう。考えられる意識的・無意識的な要素は次のようなものが挙げられます。

1) 見た目：　選択肢が多くなればなるほど、人は「見かけ」のインパクトを大事にする傾向にあります。視覚的情報は、人の主観的な部分にダイレクトに訴え、深く読んだり調べたりしなくても「好き」「嫌い」で簡単に選択肢を大幅に減らすことができるからです。

2) 自分との関係：　選択肢と自分との関係は近ければ近いほど、自分にとってのその選択肢の意味が具体化しやすくなり、それゆえ深く読んだり調べたりしなくても「近い」「遠い」というコンセプトで選択肢を大幅に減らすことができます。例えば、無数のRSSフィードから自分の興味にあった記事を探し出して選択的に記事を読む時にも、人は無意識的に自分とその記事の内容の距離とを計っているはずです。

Web2.0で繰り返し問われたものとして、上記のような選択肢のフィルタリングをいかにプログラム側がやってあげるか、という挑戦がありました。でもこれって、何もプログラムに限った挑戦ではありません。UIにだって、企画にだって、同じ挑戦があります。

UIでは、ユーザーの欲しいであろう選択肢をレイアウトとして優位に見せることで、ユーザーの意思決定を簡単にしてあげたり、画像や、動画や、色やタイポグラフィーの助けを借りることで、見た目のインパクトを用いて選択肢を絞ってあげ、ユーザーと選択肢の関係をビジュアル化しやすくしてあげる、ということが可能です。

企画では、見た目に魅力的な商品企画を提案し、演出するテクが有効であることは誰でも納得できるはずです（みんな一度くらいはそういう商品企画の良いカモになったことでしょう）。魅力的な商品企画によってユーザーは意外と、不毛な調査や学習の必要性から救われたりするのだと思います。そして、企画にユーザーのシナリオ・パターンが含まれていることも重要です。だれが、どこで、誰に対して、どういうことをするために、何を用いるから、その選択肢を選択するはずなのか、というシナリオを、企画担当の人はむしろプログラマより柔軟に考えられたりするでしょう。そういったシナリオは、ユーザが自分と選択肢との関係を具体化するために非常に役に立つはずです。

ずいぶんと抽象的な話になってしまいましたが、わたしは結構こういうの、好きなんです。そのうち気が向いたら具体的な例をあげたいと思います。ユーザの選択の自由を尊重して、プログラマさんとも企画担当さんとも、仲良く開発を行って行きたいと思います（なんて、すごい強引な締め方・・・）。

日時: 21:55 | パーマリンク | コメント (2) | トラックバック (0)

こんばんわ、Sashaです。フォト蔵のUI改善への要望が高まっているのをうけて、最近、ユーザビリティについてみんなで考えています。

基本の基本が気になる私は、「ユーザビリティって何だろう」というところから考えるべく、『ユーザビリティのguru』と呼ばれるJakob Nielsenの「ユーザビリティ」の定義を復習しました。以下はそのまとめです。

ユーザビリティって何だろう？

ユーザビリティは、UIがどのくらい使いやすいものであるのかを示す質的属性です。「ユーザビリティ」という言葉は、モノをデザインする過程で「使いやすさ」を改善するための方法でもあります。

ユーザビリティは、次の5つの品質によって表すことができます。
「学習しやすさ」
初めてそのデザインに触れるユーザーが、どれだけ容易に基本的なタスクを発見し、遂行できるだろう？
「効率のよさ」
ひとたびそのデザインを学習したユーザーが、どれだけ素早くタスクを実行できるだろう？
「記憶への残りやすさ」
ユーザーがそのデザインにしばらくぶりに戻ってきた時、どれだけ容易に感覚を取り戻すことができるだろう？
「誤りの起こりにくさ」
ユーザーはどのくらいエラーを犯すだろう？そのエラーはどの程度深刻だろうか？どのくらい容易にエラーから復帰することができるだろう？
「満足度」
そのデザインを使うことが、どれだけ快適だろうか？

Nielsenがあげている他の「質的属性」で興味深いのが、デザインの機能性を示す、「ユーティリティ」。「このデザインは、ユーザーが必要としていることを反映しているか」、という質問です。つまり、どんなに「簡単な○○」であっても、その「○○」をあなたが必要としていなかったら、意味はない、と言うことです。同様に、プログラムがあなたが必要な「○○」を実現できるように書かれているのに、UIが難しいゆえにユーザーが「○○」を遂行できなかったら、やっぱり意味はないですね。

では、そのユーザビリティって、どうして大事なんでしょう。

ユーザビリティはどうして大事なの？

ずばり、ユーザビリティはサイトから「去る」人々を食いためるために必要です。デザインは、使う人のやる気をくじいてはならないのです。やる気をくじくと、人々はどんどん逃げてしまいます。ウェブサイトには、人々のやる気をくじく要素がいっぱい詰まっています。

Jakob Nielsenは、「デザインにかける費用のおよそ10%の予算をユーザビリティに使うべきだ」と言っています。

ユーザビリティはどうやったら向上するだろう？

答えは、ユーザビリティテストです。Jakob Nielsenは、「デザインの重要なユーザビリティ上の課題を洗い出すには5人のユーザーに対するテストでおよそ大丈夫」、と言います。ユーザーを、個別にテストして、起こる問題を自力で解決してもらうことも重要です。

重要なのは、

• 『代表的なユーザー』に
• 『代表的なタスク』を遂行してもらい、
• ユーザーが何をして、どこでうまく言ったのか、どこで躓いたのかを『黙って観察』すること。

デザインを改善する過程の要所要所で小さなテストを繰り返して、テストの間に洗い出された問題点を修整する、というのが、効率のいいやり方のようですよ。

続きを読む "ユーザビリティって何だろう？（基本のまとめ）" »

日時: 20:32 | パーマリンク | コメント (0) | トラックバック (1)

こんにちは、sashaです。

フォト蔵 のような、使ってもらって何ぼのWeb Applicationは、ビジターをいかにユーザに替えることが出来るか、というのが鍵になるかと思います。どうしたら、ビジターがユーザになってくれるだろう、ということを考えていたら、こんなことを思いつきました。題して、「ビジターをユーザーに替える３ポイント」です。

ビジョンを与えるのが鍵。

ユーザーとしてログインしていないときにビジターが見ることの出来るページは、未登録ビジターにとってサービスの疑似体験が出来るものでなくてはなりません。もちろん、サービスはユーザーのためにあるべきなので、登録ユーザには、未登録ビジターとは差別化された特権を与えなければならず、それが、写真アップロード権限であったり、ＳＮＳサービスであったりするわけです。ただ、そういったユーザのみのサービスは使えなくとも、少なくとも、このサービスを使ったらこんな気分になるんだ！こんな楽しいことが出来るんだ！こんな便利なんだ！ということを実感してもらわなくてはならないのです。ユーザになったらどんな体験が出来るのか、そういうビジョンを持ったビジターは、サービスに対して一定の期待感を持って入会します。プロバイダは、その期待感を保障するために、日々開発に勤しむのです。

ショー・ウィンドウ方式のティーザーページ。

さて、ではどんな風にビジターは、ユーザーになったときの自分の体験をビジュアライズするでしょう。ビジターのビジョン形成を助けるのは、未ログインページのビジュアル・デザインであったり、サービスについて説明されたページのUIであったりするでしょう。ここでは、登録したときに自分が体験するサービスの情報をふんだんに見せる必要があると思います。仮に、勝手にショーウィンドウ方式と呼んでみることにします。ショーウィンドウには、商品がただ、ぽんと置かれているわけではありませんよね。スタイルのいいマネキンが、カラーコーディネイトもばっちりで、「ああ、あのジャケットを買ったら、こんな着こなし方をするといいんだな」というインスピレーションを与えてくれます。それと同じように、未ログイン時のホームページは、実際にそのサービスはどんなテイストで、どんな使い方が出来るのか、というインスピレーションを与えるものであるべきだと思います。豊富なスクリーンショットなんかも、きっと有効でしょうね。

ホームページは重要？

私は毎日のようにYouTubeのページを目にしますが、自分からYouTubeのホームページを尋ねていって、そこから各ページを閲覧して回るようなことはまずありません。他にも、RSSを購読しているいくつかのサイトでは、そのサイトの「1ページ」を毎日のように目にしますが、実際にサイトのホームページを見ることはほとんどありません。WebサービスがRSSやリンクやブログに依存しているとき、サイトのホームページは、将来のユーザーにとってそれほど重要ではなくなります。というより、未ログイン状態で見ることの出来る｢1ページ｣ごと全てが、未登録ビジターを登録ユーザーに替える上で重要な｢1ページ」になるのです。



----------------------
さて、フォト蔵は、こんなことも念頭において、これからも常に進化し続けますよー、っと☆

日時: 12:06 | パーマリンク | コメント (2) | トラックバック (0)