<?xml version="1.0" encoding="utf-8" ?>
<feed version="0.3"
	xml:lang="ja"
	xmlns="http://purl.org/atom/ns#"
	xmlns:dc="http://purl.org/dc/elements/1.1/">
	<title>へたれwebディレクターの覚え書き</title>
	<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/" />
	<modified>2008-05-26T16:43:16+00:00</modified>
	<tagline><![CDATA[マーケティングの視点から、IAとUIについて考えます]]></tagline>
	<generator url="http://serenebach.net/">Serene Bach</generator>
	<entry>
		<title>タブインターフェースを使うための条件</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=207" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=207</id>
		<issued>2008-05-22T00:59:23+09:00</issued>
		<modified>2008-05-21T15:59:23Z</modified>
		<summary>メニューの表示にタブデザインを採用するサイトが増えています。が、個人的には、ただ見栄えがいいからとの理由でタブデザイン（タブインタ...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; UI / design</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[メニューの表示にタブデザインを採用するサイトが増えています。<br />
<br />
が、個人的には、ただ見栄えがいいからとの理由でタブデザイン（タブインターフェース）を採用するのは反対です。<br />
<br />
ちょっと前に『<a href="http://www.studio-no9.com/sb/sb.cgi?eid=192">タブインターフェースと“世界観”</a>』というタイトルで、タブインターフェースを使うのに適した条件を、自分なりに考えて書いてみました。<br />
が今読んでみると、内容がアバウトで我ながら意味不明な点もあります。<br />
そこで今回は、もう少し具体的に条件を考えてみます。<br />
<br />
これが正解というわけではなく、あくまで自分のための覚書きです。ご意見などあればいただけるとうれしいです。<br />
<br />
<h3>タブインターフェースを使うための条件</h3><br />
<ol><li>タブの中にある情報が一つ、もしくは複数なら並列関係である</li><li>ページの遷移が発生しない</li><li>複数タブの情報を同時に見る必要がない</li><li>タブがデフォルトのままでもコンテンツの価値を失わない</li><li>コンテンツの内容をタブのタイトルだけで伝えることができる</li></ol><br />
以下、それぞれの説明です。<br />
<br />
<h4>1・タブの中にある情報が一つであること、または複数なら並列関係であること</h4><br />
<h5>1-1・タブの中にある情報が一つ</h5><br />
タブは、一つのデータを複数の条件で出し分ける目的に向いています。<br />
<br />
例として、wikiのようなサービスが挙げられます。<br />
Wikiでは、1ページ毎に、それぞれのページに対応した「閲覧」「wiki文法での編集」「リッチテキストでの編集」「ページ管理」といったメニューが存在します。それぞれのメニューに主従関係はありません。<br />
このようなコンテンツの場合、タブインターフェースによる切り替えは理にかなっているといえます。<br />
<a href="http://www.studio-no9.com/sb/img/img71_file.png" rel="lightbox" alt="画面1・wikipediaのタブインターフェース" title="画面1・wikipediaのタブインターフェース"><img src="http://www.studio-no9.com/sb/img/img71_file.png" class="thumb" alt="画面1・wikipediaのタブインターフェース（クリックで拡大）" title="画面1・wikipediaのタブインターフェース（クリックで拡大）" width="360" height="252" /></a><br />
<a href="http://www.studio-no9.com/sb/img/img70_richtext2.png" rel="lightbox" alt="画面2・wiki『Confluence』の編集画面" title="画面2・wiki『Confluence』の編集画面"><img src="http://www.studio-no9.com/sb/img/img70_richtext2.png" class="thumb" alt="画面2・wiki『Confluence』の編集画面（クリックで拡大）" title="画面2・wiki『Confluence』の編集画面（クリックで拡大）" width="360" height="195" /></a><br />
<br />
<h5>1-2・タブの中にある情報が複数の場合は、すべてが並列関係</h5><br />
タブは、上下関係のない同じ種類の情報が大量にあったとき、それをある一定のルールに基づいてグループ分けして表示する目的に向いています。<br />
<br />
ニュースサイトは（通常）、1ページに1つの記事が掲載されています。それぞれに上下関係はありません。このような状態を「並列関係」と規定します。<br />
<br />
Amazon.co.jpにはかなり大量の情報がありますが、商品情報は（基本的に）「1ページ＝1商品」です。このような場合に、タブによるグループ分け表示は適しています。<br />
<a href="http://www.studio-no9.com/sb/img/img72_file.png" rel="lightbox" alt="画面3・amazon.co.jpのタブ" title="画面3・amazon.co.jpのタブ"><img src="http://www.studio-no9.com/sb/img/img72_file.png" class="thumb" alt="画面3・amazon.co.jpのタブ（クリックで拡大）" title="画面3・amazon.co.jpのタブ（クリックで拡大）" width="360" height="63" /></a><br />
タブは並列関係にある同じ種類の情報を、あるルールにのっとって分割するから意味があります。情報に階層関係、主従関係があると、デフォルトのタブを開いている状態のときに他のタブをクリックしたらどのような結果になるかをユーザーが想像しづらくなってしまいます。<br />
<br />
Amazonの場合、並列関係にある商品のみにタブが使われています。もし同じ種類に属さない、商品以外の「欲しい物リスト」や「カートを見る」がタブに含まれたら、とたんに難しいインターフェースになってしまうでしょう。<br />
<br />
<h4>2・ページの遷移が発生しないこと</h4><br />
タブインターフェースを採用するなら、タブをクリックしたときにページ遷移をさせないほうがいいと思います。<br />
ユーザーが、「タブをクリックしたらページ遷移が発生する」と想像しづらいからです。<br />
ページ遷移が発生するかどうかわからないということは、タブを切り替えたときに「切り替えた前の状態が保存されているかどうか」の予想がユーザーにはつかない、ということです。<br />
<br />
タブインターフェースを採用しつつページ遷移が発生する例として、Yahoo!メールとYahoo!カレンダーで起こる問題を考えてみます。<br />
<a href="http://www.studio-no9.com/sb/img/img73_yahoomail.png" rel="lightbox" alt="画面4・yahoo!メールとカレンダーはタブで切り替えるようなUIを採用している" title="画面4・yahoo!メールとカレンダーはタブで切り替えるようなUIを採用している"><img src="http://www.studio-no9.com/sb/img/img73_yahoomail.png" class="thumb" alt="画面4・yahoo!メールとカレンダーはタブで切り替えるようなUIを採用している（クリックで拡大）" title="画面4・yahoo!メールとカレンダーはタブで切り替えるようなUIを採用している（クリックで拡大）" width="360" height="144" /></a><br />
会議参加依頼のメールが届いて、その予定をYahoo!カレンダーに登録しようするときのフローを考えてみましょう。<br />
<br />
<ol><li>会議参加依頼のメールが届く。参加を決める。</li><li>予定を登録しようと、タブ「カレンダー」をクリック。自分のカレンダーが表示される。</li><li>カレンダーに予定日時を入力。</li><li>続いて場所も入力…しようと思ったときにメールに書かれていたはずの場所を確認していないことに気づく。</li><li>場所を確認しようと、メールのタブをクリックして、該当メールに戻る…つもりがメールサービスのトップページへ遷移してしまった。</li><li>慌ててカレンダーのタブをクリックしたら、カレンダーサービスのトップ画面が表示。カレンダーに入力途中だったデータは消えた。最初から入力しなければ。</li><li>凹む。</li></ol><br />
ページの遷移が発生することをユーザーが想像しづらいタブインターフェースでは、情報のリセットが行われると想像するのが難しく、「元のタブに戻れば以前の状態が保存されている」ように錯覚しがちです。<br />
<br />
これがもしタブインターフェースでなかったらどうでしょう。<br />
もしボタンメニューだったなら、ユーザーは「メニューをクリックすると単にページ遷移が起きる、だから入力途中のデータはなくなる」と想像がついたはずです。<br />
<br />
<h4>3・複数タブの情報を同時に見る必要がないこと</h4><br />
上記「ページの遷移が発生しない」の例でもわかるとおり、カレンダーとメールは同時に表示しつつ利用することがあります。このような場合は、タブインターフェースを採用するべきではありません。<br />
<br />
タブは小さなスペースで多くの情報を表示するのに適していますが、それらの情報を比較しながら閲覧することに向いていません（というか同時に表示されないので比較すらできません）。<br />
<br />
<h4>4・タブがデフォルトのままでもサービスが価値を失わないもの</h4><br />
タブは、クリック率の低いインターフェースです。<br />
<br />
ですから、「タブをクリックしてくれないとユーザーに楽しさが伝わらない」「クリックしなければサービスの目的が満たせない」ような場面で採用するべきではありません。<br />
<br />
ヤフーのトップページにあるニュースコンテンツは優れた例だと思います。<br />
<a href="http://www.studio-no9.com/sb/img/img74_file.png" rel="lightbox" alt="画面5・Yahoo!トップのニュースコンテンツは優れたUIだと思われる" title="画面5・Yahoo!トップのニュースコンテンツは優れたUIだと思われる"><img src="http://www.studio-no9.com/sb/img/img74_file.png" class="thumb" alt="画面5・Yahoo!トップのニュースコンテンツは優れたUIだと思われる（クリックで拡大）" title="画面5・Yahoo!トップのニュースコンテンツは優れたUIだと思われる（クリックで拡大）" width="360" height="297" /></a><br />
「トピックス」という名前で注目の記事が表示されています。一般のユーザーは、トピックスの記事を目にすれば十分です。<br />
もし他の記事を見たくなったり、他の記事を見る必要が生じた場合には、きっとタブをクリックしてくれるでしょう。<br />
もともとニュースを見ることが目的なら、きっと「一覧」をクリックしてくれるはずです。<br />
<br />
仮にユーザーがタブをクリックしてくれなくても、トップページの価値が下がることはありません。<br />
<br />
<h4>5・コンテンツの内容をタブのタイトルだけで伝えることができる</h5><br />
ユーザーは「そのタブをクリックすることが自分にメリットがある」と感じなければクリックしてくれません。<br />
ユーザーにそう感じてもらうにはまず、デフォルトのタグタイトルとタブ内に表示された情報を見て「自分は他のタグをクリックするべきか？」を判断してもらう必要があります。<br />
<br />
上述のニュースの場合、ニューストピックスが表示されている状態で、「エンタメ」とのタブタイトルが目に入りました。そのときユーザーは、「エンタメ」をクリックするとどのようなコンテンツが表示されるのか容易に想像することができます。<br />
<br />
逆にいうと、クリックして画面遷移しないと中身が想像できないコンテンツにはタブインターフェースは向いていません。<br />
<br />
Amebaもタブメニューを採用しています。この「トップ」画面で、「ルーム」というタブ名からそこになにがあるか想像できるでしょうか？<br />
<a href="http://www.studio-no9.com/sb/img/img75_ameblo.png" rel="lightbox" alt="画面6・amebaのトップページにあるタブはタイトルから内容を想像できない" title="画面6・amebaのトップページにあるタブはタイトルから内容を想像できない"><img src="http://www.studio-no9.com/sb/img/img75_ameblo.png" class="thumb" alt="画面6・amebaのトップページにあるタブはタイトルから内容を想像できない（クリックで拡大）" title="画面6・amebaのトップページにあるタブはタイトルから内容を想像できない（クリックで拡大）" width="360" height="114" /></a><br />
タブ名「ブログネタ」も中身が想像できません。きっとブログを書くためネタがあるのかなと思いクリックすると、いきなり謎の生物が表示されます。<br />
<br />
しかもamebaではタブを階層化させてしまっています。階層化された奥に「クチコミ番付」というコンテンツが存在するとは想像もできません。<br />
「各コンテンツが並列関係にない」「各コンテンツが同じ種類の情報で構成されていない」ため、タブの中身を想像しづらくさせてしまっています。もし「ルーム」や「クチコミ番付」がキラーコンテンツだったらどうするのでしょう。（幸い、キラーではありませんが…）<br />
<br />
余談ですがAmabaのトップページ、初めて「リクエスチョン」をクリックするといきなりタブメニューが消えてしまうのもインターフェースをさらに難しくしています。<br />
<br />
<h3>最後に：ではいったい、タブメニューとボタンメニューではなにが違うの？</h3><br />
前述したYahoo!メールとYahoo!カレンダーは、見かけはタブメニューですがajaxを使っているわけではありません。実際の動きはボタンメニューのそれです。<br />
しかしたとえ仕組みは同じでも、ビジュアルがタブかそうでないかで、ユーザーがうける印象は大きく異なるのではないでしょうか。タブメニューとボタンメニューの違いは、仕組みの違いだけで判断されるべきではないと思います。<br />
<br />
ビジュアルの違いでユーザーが受ける印象はどう変わるのか？の例として、「なぜチェックボックスとラジオボタンは別のグラフィカルデザインが用意されているのか」を考えて見ます。<br />
<br />
チェックボックスは複数項目が選択可能です。一方、ラジオボタンは一つだけ選択させるときに使います。<br />
<br />
ではチェックボックスのプロパティになにかフラグが増えて、それがONなら複数選択できない、という仕組みがブラウザに用意されたらどうでしょう？<br />
ラジオボタンは無用になるでしょうか？<br />
<br />
しかしそれではユーザーが、「今、自分は複数の項目を選んでいいの？ それとも一つだけ選べるの？」というのを、画面を見ただけでは判断できなくなってしまいます。<br />
ユーザーは、自分にどのような行動が許されているのかを、画面からの情報で判断するからです。<br />
<br />
<br />
タブでメニューの表現はもちろんできます。しかし状況を考えずに使ってしまうと<strong>タブメニューであるからこそユーザーが感じることのできる「ここにある情報は並列で、同じ種類のものだ」という意味づけを失ってしまいます</strong>。<br />
<br />
ユーザーの理解を助ける役割を果たしている「暗黙のルール」を、安易にweb製作者が破壊するべきではないと思うのです。<br />
<br />
<h3>追記</h3><br />
今回のエントリーを書くにあたり、以下のページを参考にさせていただきました。<br />
<ul><li>Jakob Nielsen博士のAlertbox『<a href="http://www.usability.gr.jp/alertbox/20070917_tabs.html" target="_blank">タブの正しい使い方</a>』</li><li>ソシオメディア　UIデザインパターン『<a href="http://www.sociomedia.co.jp/104" target="_blank">タブの並列切替</a>』</li><li>Apple Human Interface Guidelines　『<a href="http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_19_section_7.html#//apple_ref/doc/uid/TP30000359-TPXREF227" target="_blank">View Controls</a>』</li></ul><br />
タブインターフェースを採用することが決まったら、次に検討するのは「見やすく」や「高速に」などかと思います。それらについては参考ページに詳しいのでそちらをお読みいただくのがいいかと思います。]]></content>
	</entry>
	<entry>
		<title>XAMMP再インストールでMySQLが起動しなくなったら</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=206" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=206</id>
		<issued>2008-05-19T00:27:32+09:00</issued>
		<modified>2008-05-18T15:27:32Z</modified>
		<summary>自分が何度も引っかかるので、覚え書きを残しておきます。なお、以下の記述はWindows XP professionalでのものです。XAMPPを何度かインストール（アッ...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; PG</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[自分が何度も引っかかるので、覚え書きを残しておきます。<br />
なお、以下の記述はWindows XP professionalでのものです。<br />
<br />
<br />
XAMPPを何度かインストール（アップデート含む）をしていると、MySQLが起動しなくなるときがあります。<br />
古いバージョンのMySQLがサービスとして残っており、それが新しいバージョンとconflictを起こしていることが多いです。<br />
<br />
その場合、古いMySQLのサービスを止めてしまえば正常に動作するようになります。<br />
<br />
<br />
<ol><li>コントロールパネルの「管理ツール」を選択</li><li>その中の「サービス」を起動</li><li>「Mysql」をダブルクリック</li><li>表示されるダイアログボックス内の「実行ファイルのパス」がXAMPPをインストールした場所と違うことを確認（同じなら正常に上書きインストールができているので原因が別のところにある可能性が）</li></ol><br />
<a href="http://www.studio-no9.com/sb/img/img64_mysql.png" rel="lightbox" alt="画面1・Windows XPのサービス管理画面" title="画面1・Windows XPのサービス管理画面"><img src="http://www.studio-no9.com/sb/img/img64_mysql.png" class="thumb" alt="画面1・Windows XPのサービス管理画面（クリックで拡大）" title="画面1・Windows XPのサービス管理画面（クリックで拡大）" width="480" height="304" /></a><br />
<ol start=5><li>コマンドプロンプトを起動</li><li>現在XAMMPがインストールされているディレクトリに移動し、その中の「mysql\bin」に移動</li><li>mysqld-nt --removeを実行</li></ol><br />
<img src="http://www.studio-no9.com/sb/img/img65_mysql2.png" class="pict" alt="画面2・コマンドプロンプトでコマンドを実行" title="画面2・コマンドプロンプトでコマンドを実行" width="421" height="180" /><br />
<ol start=9><li>XAMPPコントロールパネルからMySQLを起動</li></ol><br />
<img src="http://www.studio-no9.com/sb/img/img66_mysql3.png" class="pict" alt="画面3・XAMPPコントロールパネルからMySQLを起動" title="画面3・XAMPPコントロールパネルからMySQLを起動" width="445" height="354" /><br />
これで無事に起動に成功しました。<br />
<br />
<br />
ネット上では「mysqld-max-nt --removeを実行」と書かれている情報があったのですが、mysqld-max-ntといファイルが見つからなかったので、とりあえず「mysqld-nt --remove」を実行したらうまくいったので、もうこれでいいことにしてしまいます。<br />
<br />
<br />
以上、自分用メモでした。]]></content>
	</entry>
	<entry>
		<title>地域情報サービスの検索フォーム比較</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=205" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=205</id>
		<issued>2008-05-13T23:27:30+09:00</issued>
		<modified>2008-05-13T14:27:30Z</modified>
		<summary>『Yahoo!地域情報』と『Googleマップ』の検索フォームには、それぞれ検索例が掲載されており、初めて利用するユーザーが使い方に迷わないように...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; UI / design</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[『<a href="http://local.yahoo.co.jp/" target="_blank">Yahoo!地域情報</a>』と『<a href="http://maps.google.co.jp/" target="_blank">Googleマップ</a>』の検索フォームには、それぞれ検索例が掲載されており、初めて利用するユーザーが使い方に迷わないようになっているようです。<br />
<br />
しかし実際に利用してみると、かなり差があるように思われます。<br />
<br />
後学のため、どこに差があるのか、を文章化してみます。<br />
<br />
<br />
<br />
『<a href="http://local.yahoo.co.jp/" target="_blank">Yahoo!地域情報</a>』は画面右上に検索フォームがあります。<br />
最近のサービスによくあるように、「まず例に挙げられているキーワードを入力して試してみてね」と例文がフォーム内に表示されています。一見、親切そうなUIです。<br />
（画像はクリックすると拡大します）<br />
<a href="http://www.studio-no9.com/sb/img/img59_file.png" rel="lightbox" alt="画像1・Yahoo!地域情報" title="画像1・Yahoo!地域情報"><img src="http://www.studio-no9.com/sb/img/img59_file.png" class="thumb" alt="画像1・Yahoo!地域情報" title="画像1・Yahoo!地域情報" width="480" height="343" /></a><br />
<br />
<br />
初めて使うので、まずは例文のとおりに「東京ミッドタウン、渋谷駅」と入力しました。そして二つ目のフォームにカーソルを移動。<br />
すると、なぜか一つ目のフォームが、フォームでなくなりました。もうキーワードを修正できなくなってしまったのでしょうか。<br />
<a href="http://www.studio-no9.com/sb/img/img60_file.png" rel="lightbox" alt="画像2・Yahoo!地域情報（検索条件を入力中）" title="画像2・Yahoo!地域情報（検索条件を入力中）"><img src="http://www.studio-no9.com/sb/img/img60_file.png" class="thumb" alt="画像2・Yahoo!地域情報（検索条件を入力中）" title="画像2・Yahoo!地域情報（検索条件を入力中）" width="480" height="140" /></a><br />
実は入力不可になったと思われた一つ目のフォームは、キーワード上でクリックするとフォームが復活します。だからといってわざわざフォームを消す理由が分かりません。<br />
仮に理由があったとしても、ユーザーに「入力できなくなった」と勘違いさせる以上の理由があるとは思えません。<br />
<br />
混乱しつつ二つ目のフォームにも、例に挙げられているとおり「ホテル、郵便局」と入力して検索ボタンをクリック。<br />
<br />
すると、見事に1件もヒットしません。<br />
<a href="http://www.studio-no9.com/sb/img/img61_file.png" rel="lightbox" alt="画像3・Yahoo!地域情報の検索結果" title="画像3・Yahoo!地域情報の検索結果"><img src="http://www.studio-no9.com/sb/img/img61_file.png" class="thumb" alt="画像3・Yahoo!地域情報の検索結果" title="画像3・Yahoo!地域情報の検索結果" width="480" height="384" /></a><br />
実は例にあった「東京ミッドタウン、渋谷駅」というのは、「東京ミッドタウンか渋谷駅の、どちらかを入力してね」という意味だったのです。わかりづらいです。<br />
<br />
<br />
一方、同種のサービスである『<a href="http://maps.google.co.jp/" target="_blank">Googleマップ</a>』をあげてみますが、キーワードごとにかぎカッコでくくられており、どのように入力すればいいのか一目瞭然です。<br />
<a href="http://www.studio-no9.com/sb/img/img62_file.png" rel="lightbox" alt="画像4・Googleマップの地図検索" title="画像4・Googleマップの地図検索"><img src="http://www.studio-no9.com/sb/img/img62_file.png" class="thumb" alt="画像4・Googleマップの地図検索" title="画像4・Googleマップの地図検索" width="480" height="192" /></a><br />
例文が常時表示されているので、「一つ目のフォームに入力するのは場所？キーワード？時間？そのほか？」と悩むこともありません。<br />
<a href="http://www.studio-no9.com/sb/img/img63_file.png" rel="lightbox" alt="画像4・Googleマップのサービス検索" title="画像4・Googleマップのサービス検索"><img src="http://www.studio-no9.com/sb/img/img63_file.png" class="thumb" alt="画像4・Googleマップのサービス検索" title="画像4・Googleマップのサービス検索" width="480" height="160" /></a><br />
そもそもYahoo!地域情報の場合、フォームにカーソルをあてると例文が読めなくなる、という仕様も使いづらい一因です。<br />
例文は初めてサービスを使ってみる人にこそ必要なものですが、そのようなユーザーがじっくりと例文を読んでから入力という行動を始めるとは思えないからです。<br />
<br />
<br />
親切のつもりでつけた機能が、実は逆に使い勝手を悪くするというのはよくあるパターンです。<br />
サイトを設計するときは、どのような熟練度のユーザーがどのように利用するかをイメージしながらUI構築をしないといけないのだと思いました。]]></content>
	</entry>
	<entry>
		<title>『ケータイ白書』は掲載内容にもう一工夫欲しい</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=204" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=204</id>
		<issued>2008-05-13T00:46:37+09:00</issued>
		<modified>2008-05-12T15:46:37Z</modified>
		<summary>職業柄「ケータイ白書」は毎年、資料として購入しています。役だってはいるのですが、情報の載せ方にもう一工夫あれば、資料としてもっと使...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; マーケティング</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[職業柄「ケータイ白書」は毎年、資料として購入しています。<br />
<br />
役だってはいるのですが、情報の載せ方にもう一工夫あれば、資料としてもっと使い勝手が良くなるように思います。<br />
<br />
<h3>年代別よりも職業別の集計を掲載して欲しい</h3><br />
ケータイ白書を見ていて「年代別の集計にどれだけ意味があるのだろうか？」と思うことがあります。<br />
<br />
「ケータイを持つようになった」「パケット定額にした」「有料サービスを利用するようになった」「メールの利用が増えた」など、ケータイの使い方に変化があるのは、職業の変化（所得の変化、生活環境の変化）のほうが大きいと思います。<br />
<br />
学生なら、「アルバイトをするようになったから支払い能力が上がった、だから有料サービスを利用しよう」、「友だちが一気に増えたからSNSを始めよう」などですね。<br />
<br />
そうなるとケータイ白書の「10代・20代・30代」というくくりは、マーケティングの資料として使うのにはあまりに大ざっぱであることがわかります。<br />
<br />
もっと細かく年代を刻むか、もしくは「小学生・中学生・大学生」などのように職業ごとに集計してくれたら…と思います。<br />
<br />
<h3>前年度比の数字も掲載して欲しい</h3><br />
もう一点の不満は、前年度との比較が掲載されていないので「この数字は伸びてるの？」というのが分からない点です。<br />
<br />
ケータイはおよそ2年に一度の頻度で買い換えられているそうです。つまり数年で大きく数字が変わります。<br />
「今年どうだったか」の数字もいることはいりますが、来年再来年にどうなるか？を予測することのほうが実は重要だったりします。<br />
<br />
予測をたてるためにも、前年度比くらいは載せて欲しいです。<br />
<br />
<h3>まとめ</h3><br />
もしかしてもっと詳しい情報が知りたければ、ケータイ白書で使われているデータがさらに詳細に記載されている『<a href="http://direct.ips.co.jp/book/ihtml/kwp2008/default.cfm" target="_blank">ケータイ利用動向調査報告書</a>』を購入してくれ、ということなのでしょうか。<br />
10万円は個人には厳しいですが…。<br />
<br />
<iframe src="http://rcm-jp.amazon.co.jp/e/cm?t=hetarewebdire-22&o=9&p=8&l=as1&asins=484432490X&fc1=000000&IS2=1&lt1=_blank&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>]]></content>
	</entry>
	<entry>
		<title>鍋ぶたの取っ手の形が変わっただけで余計な気苦労から解放された</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=203" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=203</id>
		<issued>2008-05-13T00:35:57+09:00</issued>
		<modified>2008-05-12T15:35:57Z</modified>
		<summary>webと関係ないのですが、便利だと思ったのでエントリー。無印良品で鍋とフタを購入しました。フタの取っ手の形に一工夫あり。直方体（に近い...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>使い勝手 &gt; 使いやすい</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[webと関係ないのですが、便利だと思ったのでエントリー。<br />
<br />
<br />
無印良品で鍋とフタを購入しました。<br />
<br />
フタの取っ手の形に一工夫あり。直方体（に近い形）なのです。<img src="http://www.studio-no9.com/sb/img/img57_nabe.jpg" class="pict" alt="画像1・MUJIで購入した鍋とふた" title="画像1・MUJIで購入した鍋とふた" width="480" height="360" /><br />
<br />
これだと、フタを裏返しにして置いたときに、取っ手が丸なのと違って、転がらないのです。<br />
<img src="http://www.studio-no9.com/sb/img/img58_nabe2.jpg" class="pict" alt="画像2・取っ手が直方に近い形状のため、フタが転がらない" title="画像2・取っ手が直方に近い形状のため、フタが転がらない" width="480" height="360" /><br />
<br />
これまでは熱くなっている鍋のふたを一時的に置くときに、転がらないかと慎重になっていたのですが、今は余計な気苦労をしなくて済むようになりました。<br />
<br />
当たり前のようになっていたけど実は必要のない気苦労だった、というのは探せばwebの世界でもありそうですね。]]></content>
	</entry>
	<entry>
		<title>テキストリンクとsubmitボタンの使い分けルール</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=202" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=202</id>
		<issued>2008-05-11T23:11:18+09:00</issued>
		<modified>2008-05-11T14:11:18Z</modified>
		<summary>htmlにはページ遷移とユーザーからのフォーム入力内容受け取りの機能があり、それぞれテキストリンクはページ遷移submitボタンはフォーム入力内...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; UI / design</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[htmlにはページ遷移とユーザーからのフォーム入力内容受け取りの機能があり、それぞれ<br />
<ul><li>テキストリンクはページ遷移</li><li>submitボタンはフォーム入力内容の反映</li></ul>と役割を担っています。<br />
<br />
しかし最近ではajaxの一般化もあり、このルールにあてはまらないUIのサービスが増えてきました。<br />
<br />
一度、ルールを整理してみようと思います。<br />
<br />
<h3>テキストリンクとsubmitボタン、どちらを選ぶべきか</h3><br />
テキストリンクとsubmitボタンでどちらを選ぶべきか？を表にしました。<br />
<img src="http://www.studio-no9.com/sb/img/img56_file.png" class="pict" alt="表1" title="表1" width="452" height="86" /><br />
<br />
以下、それぞれの内容です。<br />
<br />
<h4>1・「遷移」か「実行」か</h4><br />
<a href="http://www.studio-no9.com/sb/img/img53_file.png" rel="lightbox" alt="図1・Flickrの画像プロパティ編集画面" title="図1・Flickrの画像プロパティ編集画面"><img src="http://www.studio-no9.com/sb/img/img53_file.png" class="thumb" alt="図1・Flickrの画像プロパティ編集画面" title="図1・Flickrの画像プロパティ編集画面" width="360" height="240" /></a><br />
Flickrの画像プロパティ編集画面です。ここでは画像が撮影された時刻を編集しています。<br />
<br />
編集完了ボタンを見ていただきたいのですが、編集して保存する場合は【SAVE】というsubmitボタン。これは一般的なUIです。<br />
しかしキャンセルがsubmitボタンではなく“click here if you are not sure of the date.”とのテキストリンクになっています。<br />
<br />
考えてみるとこのUIは理にかなっています。<br />
Flickrのこの場面の場合のキャンセルとは、「編集を反映しないで編集画面を終える」のではなく厳密には「編集を反映しないで画像表示画面（前ページ）へ遷移する」です。<br />
ページ遷移ですから、テキストリンクでいいのです。<br />
<br />
ちなみに画像表示画面で直接タイトルを編集する場合は、キャンセルはsubmitボタンです。キャンセルしてもページ遷移が発生しないからこのようにしているのだと思います。<br />
<a href="http://www.studio-no9.com/sb/img/img54_file.png" rel="lightbox" alt="図2・ajaxによるタイトル編集画面" title="図2・ajaxによるタイトル編集画面"><img src="http://www.studio-no9.com/sb/img/img54_file.png" class="thumb" alt="図2・ajaxによるタイトル編集画面" title="図2・ajaxによるタイトル編集画面" width="360" height="240" /></a><br />
<br />
<h4>2・選択された内容は一時的反映か、記憶されるか</h4><br />
サービスの動作を設定し反映する場合、その設定に2種類あります。<br />
「その設定が一時的なもの」か「その反映が記憶される」かです。<br />
<br />
Yahoo! Japanの検索条件の設定は、検索条件を「動画」にしても、次にこのページに訪れるときはデフォルトの「ウェブ」に設定が戻ります。<br />
<br />
本来、「設定の反映」はsubmitボタンのほうがいいと思われがちですが、このように設定が保存されないものは、テキストリンクのほうが一時的であることが伝わりやいと思います。<a href="http://www.studio-no9.com/sb/img/img55_file.png" rel="lightbox" alt="図3・Yahoo! Japanの検索条件設定はテキストリンク" title="図3・Yahoo! Japanの検索条件設定はテキストリンク"><img src="http://www.studio-no9.com/sb/img/img55_file.png" class="thumb" alt="図3・Yahoo! Japanの検索条件設定はテキストリンク" title="図3・Yahoo! Japanの検索条件設定はテキストリンク" width="360" height="87" /></a><br />
<br />
<h4>3・SVOCの“O（動作の対象）”はthisか</h4><br />
Flickrの一覧にある「削除」は<br />
「この画像を削除」<br />
を表しています。この場合、テキストリンクでも違和感がありません。<br />
<br />
逆に検索ボタンなどは対象語がない、という状況は考えられません。<br />
このような場合は、submitボタンを選択しましょう。<br />
<br />
<h4>それをクリックしたら、まわりの内容も反映されるか</h4><br />
submitボタンは本来、フォーム入力に利用されるものです。<br />
フォームでのsubmitボタンは、それ単独で利用されることはほとんどありません。ユーザーは「submitボタンを押すと、そのまわりにある入力フォームの内容が反映されるんだな」とのイメージをすでに持っています。<br />
<br />
一方テキストリンクは、ページ遷移で使われます。ページが遷移するだけですから、そのページないでなにか入力されていても関係なく「ただページが移動するんだな」と理解します。<br />
<br />
ですので、ページ内の入力項目が反映されるボタンにテキストリンクを使うべきではありません。<br />
<br />
<h3>まとめ</h3><br />
長々と書きましたが、これが絶対に正解というわけではないと思います。<br />
ご意見などあればいただけるとうれしいです。]]></content>
	</entry>
	<entry>
		<title>プルダウンメニューの利用に適した条件とは</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=197" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=197</id>
		<issued>2008-03-19T03:25:22+09:00</issued>
		<modified>2008-03-18T18:25:22Z</modified>
		<summary>ユーザーからの入力を求めるときのインターフェースはいくつかありますが、中でもプルダウンメニュー（ボタンダウンメニューとも呼ばれる）...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; UI / design</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[ユーザーからの入力を求めるときのインターフェースはいくつかありますが、中でもプルダウンメニュー（ボタンダウンメニューとも呼ばれる）は使い勝手がよく、<br />
<ul><li>限られたスペースでも設置できる</li><li>こちらが想定した内容に限定した入力をさせることができる</li></ul><br />
というメリットが魅力的で、ついつい多用しがちです。<br />
<br />
ここではあらためて、プルダウンメニューはどのような条件で使われるべきなのかを考えてみます。<br />
<br />
<br />
<h3>プルダウンを使うのに適した条件とは　</h3><br />
次の条件に当てはまる場合、プルダウンが適していると思われます。<br />
<ul><li>必ずしも入力必須でないもの(選択肢を選ばなくてもなんとかなる)</li><li>もし入力必須なら、どの選択肢を選べばいいのかすぐにわかるもの</li><li>選択肢から複数を選ぶ必要がないもの</li><li>直接入力するより選んだほうが早く入力できるもの</li></ul><br />
<br />
<h4>選択肢を選ばなくても動作可能なもの</h4><br />
たとえば「さらに詳細に絞り込む」ときなどがこれにあたります。<br />
<a href="http://www.amazon.co.jp/" target="_blank">amazon.co.jp</a>の場合、プルダウンが条件絞り込みに使われています。が、プルダウンがデフォルトのままでも、目的のページにたどり着くことができます。<br />
<a href="http://www.studio-no9.com/sb/img/img41_file.png" rel="lightbox" alt="図1・amazonのプルダウンはデフォルトのままでも利用できる" title="図1・amazonのプルダウンはデフォルトのままでも利用できる"><img src="http://www.studio-no9.com/sb/img/thm41_file.png" class="thumb" alt="図1・amazonのプルダウンはデフォルトのままでも利用できる" title="図1・amazonのプルダウンはデフォルトのままでも利用できる" width="120" height="70" /></a><br />
<br />
<a href="http://www.google.co.jp/advanced_search?hl=ja" target="_blank">googleの検索オプション</a>はさらに徹底しています。複数のプルダウンがありますが、すべてデフォルト設定のままで問題なく検索機能を利用できます。<br />
<a href="http://www.studio-no9.com/sb/img/img42_file.png" rel="lightbox" alt="図2・googleは検索オプションを細かく指定できるが、指定しなくても問題なく使えるようになっている" title="図2・googleは検索オプションを細かく指定できるが、指定しなくても問題なく使えるようになっている"><img src="http://www.studio-no9.com/sb/img/thm42_file.png" class="thumb" alt="図2・googleは検索オプションを細かく指定できるが、指定しなくても問題なく使えるようになっている" title="図2・googleは検索オプションを細かく指定できるが、指定しなくても問題なく使えるようになっている" width="120" height="77" /></a><br />
<br />
<a href="http://b.search.blogs.yahoo.co.jp/SEARCH/index.html?p=%B8%A4&pt=a" target="_blank">Yahoo!ブログの検索機能</a>は、検索条件に「ブログ」「記事」「画像」を選べます。「絞り込み」というよりは「選択」であり、一見、プルダウンに適していないように思えます。<br />
しかし検索結果を複合表示する「全体」を用意することで、デフォルトのままでも問題ないようにしています。<br />
<a href="http://www.studio-no9.com/sb/img/img43_file.png" rel="lightbox" alt="Yahoo!ブログの全体検索結果画面" title="Yahoo!ブログの全体検索結果画面"><img src="http://www.studio-no9.com/sb/img/thm43_file.png" class="thumb" alt="Yahoo!ブログの全体検索結果画面" title="Yahoo!ブログの全体検索結果画面" width="50" height="120" /></a><br />
<br />
<h4>（選択が必須の場合は特に）どの選択肢を選べばいいのかすぐにわかるもの</h4><br />
プルダウンは、選択肢をじっくり読むことに適していません。<br />
「設問を見た時点でユーザーは答えを思いついており、あとは選ぶだけ」という状況で使われるべきです。<br />
選択肢の文をじっくり読まないと選べないんのなら、別のインターフェースを検討するべきです。<br />
<br />
<h5>自分が選択するべき項目以外は確認しなくてもいいもの</h5><br />
「あなたの住んでいる国は？」という設問が合った場合、答えはすぐに「日本」と浮かびます。<br />
ユーザーがするべきことは「日本」を探すだけです。日本以外にどんな選択肢があるのかを読んで確認する必要はありません。シーランド公国があってもなくてもユーザーには関係のないことです。<br />
<br />
<em>プルダウンは、すべての選択肢を読まなければ選べないような設問に使うべきではありません</em>。「すべての選択肢を」「よく読まないと」判断できないのなら、別のやり方を検討するべきです。<br />
<br />
<h5>選択肢は少ないほうがいい</h5><br />
たとえ簡単な質問でも、選択肢が多いとどれを選べばいいのか混乱することがあります。<br />
<a href="http://www.studio-no9.com/sb/img/img51_file.png" rel="lightbox" alt="図4・選択肢が多すぎると逆に複雑化する" title="図4・選択肢が多すぎると逆に複雑化する"><img src="http://www.studio-no9.com/sb/img/thm51_file.png" class="thumb" alt="図4・選択肢が多すぎると逆に複雑化する" title="図4・選択肢が多すぎると逆に複雑化する" width="66" height="120" /></a><br />
<br />
<h4>複数選択したくならない</h4><br />
ホテルの予約をしたいとき、「ツインだとうれしいけど、ないのならダブルでもいいや」という状況はあり得ます。画面のようなフォームだと、そのニーズに応えることができません。<br />
<a href="http://www.studio-no9.com/sb/img/img44_roomchoice.png" rel="lightbox" alt="図5・部屋選択の悪い例" title="図5・部屋選択の悪い例"><img src="http://www.studio-no9.com/sb/img/thm44_roomchoice.png" class="thumb" alt="図5・部屋選択の悪い例" title="図5・部屋選択の悪い例" width="120" height="34" /></a><br />
<br />
プルダウンメニューを使うときは、ユーザーが複数選択したくなるかどうかを前もって検討するべきです。<br />
<br />
<h4>直接入力するより早い</h4><br />
たとえば「生まれた年を選択してください」とプルダウンから選ばせるなら、もしかしたら直接入力してもらったほうがユーザーにとっても楽かもしれません。<br />
本当にプルダウンが便利なのかは、設問ごとに検討されるべきです。<br />
<br />
<br />
<h3>アクションコマンドとしてのプルダウンを考える</h3><br />
プルダウンから選択すると、直後になにか動作が起きるUIのページを見かけます。<br />
ユーザビリティー系の本には、動的なプルダウンは推奨しないと書かれていることが多いです。<br />
本当にそうなのか、そうならばどのような理由からなのか、を考えてみます。<br />
<br />
<h4>ページ遷移</h4><br />
プルダウンを選択したとたんにページが遷移するインターフェースを見かけることがあります。リンクショートカットに使われていることが多いようです。<br />
<br />
しかしショートカットを用意したくなるような「頻繁に使われるリンク」「重要なリンク」なら、もっと別なやりかたでフィーチャーするべきです。<br />
<br />
また、プルダウンのボタンをクリックするまでどんなリンク先があるかわからないわけですから、あまりいいUIとは言えません。<br />
<br />
<em>明確な理由やメリットがないのに、一般に定着しているUIルールから逸脱するのは避けるべき</em>だと思います。<br />
<br />
ただ、<a href="http://www.checkpad.jp/" target="_blank">check*pad</a>のような例外もあります。<br />
<a href="http://www.studio-no9.com/sb/img/img45_checkpad.png" rel="lightbox" alt="図6・check*padではプルダウンショートカットを採用している" title="図6・check*padではプルダウンショートカットを採用している"><img src="http://www.studio-no9.com/sb/img/thm45_checkpad.png" class="thumb" alt="図6・check*padではプルダウンショートカットを採用している" title="図6・check*padではプルダウンショートカットを採用している" width="74" height="120" /></a><br />
<br />
ここで表示されているページは、すべてユーザーが入力したモノです。つまりユーザーはプルダウンボタンをクリックする前からどんな選択肢があるのかを知っています。<br />
<br />
このサービスは「とことんシンプル」がサービスの大きな魅力になっています。クリック数を少なくすることは、このサービスを選んでいるユーザーの希望に適います。<br />
<br />
しかしcheck*padはあくまで特殊な例であり、普通のサービスでは、このようなUIは選ぶべきではないでしょう。<br />
<br />
<h4>選択された項目がすぐに反映</h4><br />
webサービスでは特殊ですが、オフィスソフトなどでは当たり前の用に使われているインターフェースです。<br />
ワープロソフトなどでは、フォントを選択した直後にそれが画面上で反映されます。<br />
<a href="http://www.studio-no9.com/sb/img/img46_file.png" rel="lightbox" alt="図7・選択直後にフォントの設定がかわる" title="図7・選択直後にフォントの設定がかわる"><img src="http://www.studio-no9.com/sb/img/thm46_file.png" class="thumb" alt="図7・選択直後にフォントの設定がかわる" title="図7・選択直後にフォントの設定がかわる" width="120" height="94" /></a><br />
<br />
クリック数を減らす以外にも、プルダウンで表示されている内容と、実際に表示されているものとの不一致を避けるという意味で、実は優れたインターフェースかと思われます。<br />
<br />
<a href="http://gw.tv/fw/" target="_blank">fashionwalker.com</a>では、ソート条件にプルダウンが使われており、条件を変更した直後に画面上で反映されます。プルダウンで表示されている条件と実際の表示とがずれることを避けています。<br />
<a href="http://www.studio-no9.com/sb/img/img47_fashionwalker.png" rel="lightbox" alt="図8・fashionwalkerのソート条件" title="図8・fashionwalkerのソート条件"><img src="http://www.studio-no9.com/sb/img/thm47_fashionwalker.png" class="thumb" alt="図8・fashionwalkerのソート条件" title="図8・fashionwalkerのソート条件" width="120" height="69" /></a><br />
<br />
しかし条件と表示件数を続けざまに変更すると、画面の表示内容がついてこれないようです。<br />
<em>動的なプルダウンを使うのなら、正常に動作することは必須条件</em>だと思われます。そうでないと、ユーザーを混乱させることになります。<br />
<br />
また、<a href="http://shopping.yahoo.co.jp/category/1518/" target="_blank">Yahoo!ショッピングのように、ソート条件を並べて表示</a>しても問題ないわけですから、本当にプルダウンにしなければならないのか？をよく検討したほうがいいでしょう。<br />
<a href="http://www.studio-no9.com/sb/img/img48_file.png" rel="lightbox" alt="図9・Yahoo!ショッピングのソート条件" title="図9・Yahoo!ショッピングのソート条件"><img src="http://www.studio-no9.com/sb/img/thm48_file.png" class="thumb" alt="図9・Yahoo!ショッピングのソート条件" title="図9・Yahoo!ショッピングのソート条件" width="119" height="18" /></a><br />
<br />
<h4>プルダウンを動的な絞り込みに使う</h4><br />
<a href="http://gourmet.yahoo.co.jp/restaurant/" target="_blank">Yahoo!グルメ</a>では、まず都道府県を選ぶとさらに詳細なエリアの選択プルダウンが動作する仕組みになっています。<br />
<a href="http://www.studio-no9.com/sb/img/img49_gourmet.png" rel="lightbox" alt="図10・Yahoo!グルメでは都道府県を選ぶと、さらにその内訳エリアを選択できるようになる" title="図10・Yahoo!グルメでは都道府県を選ぶと、さらにその内訳エリアを選択できるようになる"><img src="http://www.studio-no9.com/sb/img/thm49_gourmet.png" class="thumb" alt="図10・Yahoo!グルメでは都道府県を選ぶと、さらにその内訳エリアを選択できるようになる" title="図10・Yahoo!グルメでは都道府県を選ぶと、さらにその内訳エリアを選択できるようになる" width="60" height="120" /></a><br />
<br />
OPTGROUPを使って項目を階層化し一つのプルダウンにまとめるやりかたもありますが、リストが長くなるだけで使い勝手があまり改善されないからか、それほど一般的ではないようです。<br />
<br />
Yahoo!グルメのプルダウンは絞り込み目的です。選択は必須ではないですし、都道府県だけで絞り込みをやめることもできます。<br />
渋谷の店を検索したい場合、プルダウンで「東京」「渋谷」から階層を辿ることもできますし、検索窓に直接入力「渋谷」と入力することもできます。<br />
<br />
また、どうしても「渋谷」で検索したい場合、そのユーザーは渋谷が「東京都」であることを知っているので、わき道にそれるということはありません。<br />
<br />
「選択肢を選ばなくてもいい」「どの選択肢を選ぶべきかすぐにわかる」との条件を満たしていますし、階層化するよりもいいのなら、採用してもよさそうです。<br />
<br />
一方で<a href="http://blogs.yahoo.co.jp/" target="_blank">Yahoo!ブログ</a>のカテゴリ選択に使われているプルダウンは悪い例です。<br />
ディズニーランドに行った日記を書いてカテゴリを「テーマパーク」にしたいとき、「テーマパーク」がどの親カテゴリに存在するのかわからない可能性があります。直接「テーマパーク」を入力するフローは存在しません。<br />
<a href="http://www.studio-no9.com/sb/img/img50_file.png" rel="lightbox" alt="図11・Yahoo!ブログのカテゴリ設定" title="図11・Yahoo!ブログのカテゴリ設定"><img src="http://www.studio-no9.com/sb/img/thm50_file.png" class="thumb" alt="図11・Yahoo!ブログのカテゴリ設定" title="図11・Yahoo!ブログのカテゴリ設定" width="120" height="53" /></a><br />
<br />
そもそも「テーマパーク」というカテゴリが存在するのかも前もってわからないので、「どの選択肢を選べばいいのかすぐにわかる」というルールにも反しています。<br />
<br />
カテゴリを入力させたいのなら別のUIを検討するか、タグのような「アバウトなカテゴリ」にしたほうがいいかもしれません。<br />
<br />
<br />
<h3>最後に</h3><br />
今回はプルダウンに限った話でしたが、フォームに違和感がある場合、他にも検討するべき要素はたくさんあります。<br />
<br />
1年前のエントリー「<a href="http://www.studio-no9.com/sb/sb.cgi?search=%E4%BC%9A%E5%93%A1%E7%99%BB%E9%8C%B2%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A03%E3%81%A4%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%81%A85W1H&Submit=FIND" target="_blank">会員登録フォーム3つのポイントと5W1H</a>」は未だに有効だと思いますので、そちらもお読みいただけるとうれしいです。]]></content>
	</entry>
	<entry>
		<title>ケータイがコミュニティーツールであることを意識した機能</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=198" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=198</id>
		<issued>2008-03-08T01:45:30+09:00</issued>
		<modified>2008-03-07T16:45:30Z</modified>
		<summary>ちょっと前に、「初心者にとって、友だちから教えてもらったケータイのアドレスを登録するまでの手段が難しすぎる」といった内容のエントリ...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>使い勝手 &gt; 使いやすい</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[ちょっと前に、「初心者にとって、友だちから教えてもらったケータイのアドレスを登録するまでの手段が難しすぎる」といった内容のエントリーを書きました（『<a href="http://www.studio-no9.com/sb/sb.cgi?eid=159" target="_blank">データを登録してもらうための工夫</a>』）。<br />
<br />
「ケータイへのアドレス登録は、まだ使い方を把握しきれていないケータイ購入直後に行なうことが考えられのに、メーカーはユーザーレベルを想定せずに機能を設計しているのでは」という内容でした。<br />
<br />
この件について、「最新の機種同士なら、ケータイ同士をくっつけるだけで自分のアドレスを相手に伝えることができる、IC転送という機能がある」と教えてもらいました。<br />
これはすばらしい進化だと思います。<br />
<br />
<br />
<strong>「作ったモノを楽しく使ってもらうには？」というのは、モノヅクリをする人なら絶対に考えなければいけない</strong>ことだと思います。<br />
<br />
ケータイでいえば、ビジネスツールであり、ガジェットであり、コミュニティツールでもあります。<br />
そしてそれぞれの役割ごとに、利用してもらうための要件があります。<br />
<br />
コミュニティツールとして楽しめるのは、コミュニケーションをとる相手あってのことです。ケータイでいうと<br />
<ul><li>電話をする相手が存在する⇒相手に電話をするための手段を入手している</li><li>メールをする相手が存在する⇒相手にメールするための手段を入手している</li></ul><br />
が絶対に必要です。<br />
同じコミュニティツールであるmixiなどと、このあたりは変わりません。<br />
<br />
つまり<em>コミュニケーションツールとしてのケータイの楽しさを知るには、すでにケータイに複数の連絡先の情報が設定されていないといけない</em>のです。<br />
イコール、<em>連絡先登録ができない人は楽しさに気づけない</em>、ということになります。<br />
（もちろん実際はほかにも楽しめる方法はあるのですが、今は措きます）<br />
<br />
<br />
相手のメールアドレスを登録したくなったとき、これまでならどんな手段があったかというと、<br />
<ul><li>相手からメールが来たら、それを登録（相手にメアドをどうにか伝える必要あり）</li><li>赤外線通信（赤外線受信モードのやり方がわからないと使えない）</li><li>手入力（それが簡単にできるのなら苦労しない）</li></ul><br />
です。どれもケータイ初心者にとって敷居が高すぎです。<br />
<br />
しかしIC転送だと、受取る側はなにもしないくていいのです。<br />
「メールアドレスを交換する二人ともが使い方を知っていないと苦労する」だったのが、「どちらかが使い方を知っていれば簡単にアドレス交換できる」になりました。これは大きな改善だと思います。<br />
<br />
<br />
<br />
みんながみんなコミュニケーションツールとしてのケータイの楽しさを知る必要はないとは思うのですが、とはいえ私はプランナーですので、どんな場面でも「みんなに使ってもらうためにはなにが必要なんだろう？」というのは考えていたいな、と思います。]]></content>
	</entry>
	<entry>
		<title>もうちょっと頑張れAmazonおまかせリンク</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=196" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=196</id>
		<issued>2008-03-06T02:10:35+09:00</issued>
		<modified>2008-03-05T17:10:35Z</modified>
		<summary>雑談エントリーです。このサイトでは右カラムにAmazon.co.jpのアフィリエイトブログパーツ「Amazonおまかせリンク」を設置しています。Amazonおまか...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>日常生活</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[雑談エントリーです。<br />
<br />
<br />
このサイトでは右カラムにAmazon.co.jpのアフィリエイトブログパーツ「Amazonおまかせリンク」を設置しています。<br />
<br />
<blockquote>Amazonおまかせリンク(R)は、あなたのWebサイトの内容に沿った商品を自動的に表示する便利なリンク方法です。</blockquote><br />
というスグレモノ、のはずなのですが、実際には浄水器とかゲームとかばかりが紹介されているんですよね。<br />
<br />
そして今はこれが。<br />
<img src="http://www.studio-no9.com/sb/img/img40_amazon.png" class="pict" alt="図1・ドアラ著「ドアラのひみつ　かくさしゃかいにまけないよ」" title="図1・ドアラ著「ドアラのひみつ　かくさしゃかいにまけないよ」" width="282" height="276" /><br />
絶対違う…。]]></content>
	</entry>
	<entry>
		<title>サイトのリニューアルは「これからはこう使ってほしい」との提案があるべき</title>
		<link rel="alternate" type="text/html" href="http://www.studio-no9.com/sb/sb.cgi?eid=195" />
		<id>http://www.studio-no9.com/sb/sb.cgi?eid=195</id>
		<issued>2008-03-06T01:55:52+09:00</issued>
		<modified>2008-03-05T16:55:52Z</modified>
		<summary>サイトをリニューアルするとき、今あるコンテンツの扱いをどうするか検討すると思います。アクセス数をチェックして「このコンテンツは人気...</summary>
		<author>
			<name>takeyoshi TOMODA</name>
		</author>
		<dc:subject>Web &gt; idea/plan</dc:subject>
		<content mode="escaped" type="text/html" xml:lang="ja"><![CDATA[サイトをリニューアルするとき、今あるコンテンツの扱いをどうするか検討すると思います。<br />
アクセス数をチェックして「このコンテンツは人気があるからもっとフューチャーしよう」「このコンテンツは使われていないから位置を下げよう」といったやり方が一般的です。<br />
<br />
しかし、必ずしも今のユーザーの利用動向に合わせたリニューアルが、イコール正しいリニューアルというわけではないと思います。<br />
<br />
私は、<strong>サイトのリニューアルは、「今こう使われているから」を考慮しつつも、「これからはこう使ってほしい」との提案があるべき</strong>だと思います。（そしてその提案は、トップページを見たら伝わる、というのが望ましいです）<br />
<br />
機能が使われていないのは、「そのコンテンツが必要とされていないから」ではないかもしれません。<br />
ユーザーに魅力を伝えきれていないからかもしれませんし、そもそもユーザーの興味をひいていないから、ひょっとしてユーザーが気づいてすらいないから、かもしれないからです。<br />
<br />
サービスを提供する目的は「使ってくれると絶対に便利」「使ってくれたら絶対に楽しい」のはずであり、それには必ず使われ方の理想形があるはずです。<br />
<br />
<br />
また、それらを明確にしよう、という視点で考えると、ペルソナやシナリオを作る意味もぐっと高まるように思います。<br />
<br />
<br />
私たちがインターネットを通じて提供しているのは、単純にサービスではなくライフスタイルなのだ、というのを忘れないようにしたいです。]]></content>
	</entry>
</feed>
