サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Google I/O
web-usability.jp
火曜日, 12 月 16th, 2008 | Author: sibsiv | (0) (0) (0) (1) Total: 1 最近の電子レンジにはボタンひとつで適切な温度に温めてくれる「あたためモード」が搭載されています。 昔は、パッケージに時間が書かれているようなもの以外を温める場合には、過去の経験からくる大体の勘などを頼りに時間を設定し、加減しながら温めなおすなど、物を適切な温度に温めるという作業にも手間がかかっていました。 しかし、あたためモードができたことにより、（どれくらいの頻度で使われているかは別として）物を温める作業の手間が減少したように思います。 では、昔の電子レンジに存在した手間は消えてなくなってしまったのでしょうか？ ラリー・テスラー氏は、手間＝複雑性について以下のような法則を提唱しています。 あらゆるプロセスには本来備わっている複雑性があり、「臨界点」以降はそ
都道府県の選択や、もっと複雑なところでは海外サイトの国名選択など、セレクトボックスから目的のものを探す際になかなか見つからずにイライラしてしまった経験はありませんか？ 都道府県選択であれば、北海道から沖縄までの地域順、国名選択であればアルファベット順など、ルールに従ってソートされていることがほとんどですので、そのルールさえ分かっていれば、ある程度簡単に探すことができます。また、optgroupタグを利用するなど、標準の仕組みでできる改善策もあります。 とはいえ、いくら分かりやすくなるような工夫をしても、セレクトボックス自体がそもそも一覧性が低いため、ユーザビリティの改善にも限度があります。 そんなとき、セレクトボックスを分かりやすいパネル表示に拡張してくれる、selectable.jsはいかがでしょうか？ このスクリプトを適用すると、通常のセレクトボックスの見た目が変わり、一覧性の高いパネ
金曜日, 10 月 12th, 2007 | Author: sibsiv | (0) (0) (0) (0) Total: 0 一昔前のウェブサイトでは、「リンク＝単純なページ遷移」「ボタン＝データに対するアクション」という分かりやすい区別が存在しましたが、近年ではjavascriptの利用などにより、リンクでフォーム機能を実現することが多くなりました。 これにより、昔のような制限に囚われずにサイト設計・表現を行なえるようになりました。 しかし、その一方で、利用者側の立場からすると、ボタンやリンクを見たときに、それがどのような動作を行なうものなのかを簡単には判断できなくなってしまいました。 設計の幅が広がったことはとても好ましいことですが、単純な見た目だけに囚われることなく、利用者の立場に立って考えなければユーザビリティは損なわれてしまいます。 設計をする上では、どちらを使ったほう
少し前に、棚橋さんのブログで、長谷川さんが紹介していたというsite-it!について書かれていたのを見て、自分でもsite-it!を作ってみましたのでご報告。 site-it!はウェブサイトの典型的なページを付箋のような小さな紙に印刷したもので、サイトの構成を検討する際などに使えるツールとなっています。 以前、画面遷移図について「画面遷移図の書き方」で、画面名だけ書いた箱ではイメージしづらいということを書きましたが、site-it!はまさにそ問題を解決するツールです。 上部に画面名を書き込んで並べれば画面遷移図・サイトマップになりますし、模造紙を下に敷いて、線をつなげても良いと思います。もちろん紙なので並べ替えや移動も簡単です。 また、紙ベースであるため、打ち合わせの場でクライアントを巻き込んで検討するのに便利ですし、典型的なページから選ぶというやり方をすることによって、おおまかなサイト構
ウェブサイトの構築においては、顧客のビジネス戦略を画面の集まりによって構成されたシステムに落とし込むことがミッションとなります。 そこで、戦略を画面に落とし込むまでのフローをユーザー中心設計やユーザビリティ活動を盛り込んで作成してみました。 （小さい画像ですみません。興味ある方個別に連絡ください。） 概要は以下の通り。 サイト戦略は顧客側で管理されていることが多く、画面設計を行う開発チームまで全ての情報が伝わることは稀である。 しかし、根拠のある画面設計を行うには、サイトの目的・想定ユーザー像などの情報が必要となる。 したがって、間を埋める資料としてサイトコンセプトを定義しておく。 サイトコンセプトには、サイト運営者の目的と利用者の目的、及び利用者の特性などの情報を記述しておく。 サイトコンセプトからユーザーセグメント及びペルソナの検討を行い、シナリオを記述する。 一方、一般的なガイドライ
携帯電話用サイトでのパスワード入力について、ビービットさんのコラムにこんな記事が掲載されていました。 パスワードを英文字も含めて設定してもらう場合には、テキストエリアには「INPUT type=”password”」ではなく「INPUT type=”text”」を使うことをお勧めします。 （中略） 弊社のユーザ行動観察調査の中では、入力中から「*****」という表記になることで、打ち間違いが容易に発生することがわかっています。 from 成果を上げる携帯サイトのフォーム設計＠beBitユーザビリティ実践メモ 確かに、携帯サイトを利用する際に、パスワードが****のようなアスタリスクで表示されてしまうと分かりづらいと感じていましたが、実際自分で携帯サイトを製作するにあたって、input type=”text”で実装してしまってよいのか悩んだ事もありました。 携帯なので、端末を共有したり、覗き
月曜日, 9 月 29th, 2008 | Author: sibsiv | (0) (0) (1) (0) Total: 1 今まで各画面のレイアウト・仕様を「画面仕様書」、画面間の関係を「サイトマップ」としてそれぞれ作成し、お客様への説明の際も主にこれらドキュメントを利用していました。 一つ一つの画面の中身を見るには１画面１枚のようなプリントアウトの仕方のほうが分かりやすいですが、いくらサイトマップを添えているとはいえ、画面仕様書では各画面間の遷移が直接的には表現されていないので、イメージがわきにくい場合があります。 そこで、画面仕様書の画面部分を使った画面遷移図を作ってみました。 （仕様書としての画面遷移図とサイトマップは同じものを指すことが多いですが、ここでは分かりやすいように、箱にIDだけ書いてあるものをサイトマップ、画面の詳細まで書いてあるものを画面遷移図と呼んでいます。）
個人的には最近は、ペーパープロトタイピングやAxure、OmniGraffleなどのプロトタイピングツールに興味を持っていますが、それらはあくまでプロトタイピング段階の話で、仕様書としておこす場合には、ExcelやVisioなどのファイルに記述することになると思います。 業務でExcelやVisioを用いて画面仕様書や画面遷移図（サイトマップ）を作成する中で感じた良い点・悪い点などをまとめてみます。(PowerPointは少ししか使ってないのでおまけ程度に載せてみました。) 画面設計、画面仕様書作成ツールを検討する際の参考にして頂ければと思います。 Excel [Good]新たにツールを購入する必要がない ほとんどの企業で導入されているため、画面仕様書作成のために新しくお金をかけてツールを購入する必要が無いのは大きな利点である。 [Good]共有する際にそのまま送ってもほとんど問題ない 大
SuperSliderは複数並んだラジオボタンを見た目だけスライダーバー風に変更する、PrototypeとScript.aculo.usをベースにしたスクリプトです。 ウェブ上のFAQの末尾などに「この情報は役にたちましたか？」のような形でフィードバック用のアンケートが用意されていることがあります。一般的にこのようなアンケートはラジオボタンによる段階評価で行うことが多いのですが、段階評価であれば、スライダーバーのような全体の高低の関係が視覚的に分かるUIのほうが理解しやすく、回答の間違いも減ると思います。 スライダーバーはJavaScriptなどを使えば実現できるのですが、既存の仕組みがラジオボタンだったり、JavaScriptを利用できない環境でも使える必要がある場合などもあります。 そのような場合には、実際の仕組み自体はラジオボタンで実装しておき、見た目だけSuperSliderを使っ
月曜日, 11 月 05th, 2007 | Author: sibsiv | (0) (0) (1) (0) Total: 1 最近は見かける回数が減ってきた気がしますが、フォームのリセットボタンは必要か？について考えてみたいと思います。 この話題は、だいぶ昔にJakob Nielsen氏のAlertboxでも取り上げられていますので、知っている人にとってはいまさらかもしれません。 まず、結論から言うと、「原則的に使わないほうが望ましい」です。 フォームにおけるリセットボタンは、ユーザーの入力を元に戻す手段を提供することを目的としています。 フォームにデフォルトの値が存在し、それが記憶しづらいもの、入力しづらいものであった場合には、ユーザーの処理をやり直すための貴重な手段となります。 しかし、一般的には以下の理由により、有効に活用されません。 多くのフォームのデフォルトが空白である
ユーザビリティの向上に役立つフィードバックとフィードフォワードという考え方について紹介します。 フィードバック、フィードフォワードという言葉はユーザビリティとは別の分野でも使われているので、なじみのある言葉だと思いますが、ここでは一般的な説明から離れ、少しユーザビリティ寄りで定義したいと思います。 フィードバック･･･ユーザーの動作によって生じた結果を、後からユーザーに提示すること。問題を解決するための情報を与えること。 フィードフォワード･･･ユーザーの動作によって生じるであろうことを、事前にあらかじめユーザーに提示すること。問題が発生しないように情報を与えること。 フィードバックとフィードフォワードの例として面白いのがカーナビです。 カーナビは基本として、「○○メートル先の交差点を右方向です。」「この先○○kmの渋滞です。」などのように、これから起こることを事前に運転手に伝えて、通り過
Masked Input Pluginは、jQueryベースのフォーマット入力サポートプラグインです。 入力フォームで郵便番号や電話番号を入力させる場合、ハイフンなどの区切り文字ごとにインプット要素を分けるかどうか、分けない場合区切り文字を入力させるかどうかで悩むと思います。 区切り文字ごとにインプット要素を分けた場合、 フォーマットと異なる形式で入力されることによる入力エラーなどは減りますが、タブやマウスクリックでインプット要素間を行き来する手間などが問題になります。 逆に、区切り文字も含めてひとつのインプット要素に入力させる場合には、フォーマットどおりに入力する手間が問題になります。 インプット要素間の行き来を自動的に行ってくれるものとして、以前「入力後に自動でフォーカスを移動してくれるスクリプト: Autotab」を紹介しましたが、Masked Input Pluginはひとつのイン
木曜日, 11 月 20th, 2008 | Author: sibsiv | (0) (0) (0) (0) Total: 0 SNSやブログで力作の日記を書いて、いざ投稿しようと思ったら間違って×ボタンを押して閉じてしまったり、リンクをクリックして別ページに遷移してしまって、せっかく書いた内容がパーになってしまったというような経験は無いでしょうか？ 昔「フォームにリセットボタンは必要か」でも書きましたが、自分の行った作業が無駄になってしまうと多かれ少なかれフラストレーションが溜まります。毎日更新していた日記でも、「もう一度書き直す元気が無いし、また明日書こう」といって一旦間を空けてしまうと、それからずっと書かなくなってしまったりするかもしれません。 ウェブサイトをサービスとして提供する場合、そのような「利用を止められてしまうきっかけ」は出来るだけ少ないに越したことはありません。 そ
システム開発者の立場からフォーム設計を行なうと、いかにエラーメッセージを出すかということについて、考えてしまいがちです。 もちろん、システムにとって都合の悪い入力を適切に排除することは、セキュリティの面でも必要不可欠です。 しかし、ユーザビリティの観点から考えると、いかに違和感無くスムーズに作業を行なえるかが大切ですので、いかにエラーを出さないようにするかを考えていく必要があります。 以下にユーザビリティを向上させるためのポイントを示します。 注意書きや例によりあいまいさを無くす 入力方法が複数考えられるような場合には、例を示すことによって、スムーズな入力を促すことができます。 例えば、電話番号なら、 「03-1111-1111」 「0311111111」 のように、ハイフンありの場合と無しの場合が考えられます。 どちらかに統一しなければならないのであれば、例を示すべきです。
入力エリアを用意しユーザーに入力してもらう場合、入力チェックが必須になるので、大抵の場合にはエラーメッセージが必要です。 エラーメッセージはメッセージの文言も重要ですが、表示する位置もよく考える必要があります。 以下はYahoo!の例ですが、一般的にエラーの対象となったエリアとエラーメッセージの表示位置が近いほうが、ユーザにとってより分かりやすく、修正しやすいです。 しかし、ブログのコメントのように、ページの先頭に情報がたくさんあり、下のほうにフォームがあるような画面では注意が必要です。 ユーザーが入力したデータをサーバーに送信し、サーバー側でチェックを行ってエラーを返すような仕組みの場合には、送信ボタンを押してからエラーメッセージが表示されるまでに、画面のリロードが発生します。 画面のリロードを行うと、基本的にはページの一番上が表示されるので、ページが長い場合には、表示される最初の画面に
フォーム入力の際、必須入力の項目が未入力であった場合には「○○を入力してください」などのメッセージを出し、入力するまで先に進めないようにすることが一般的です。 これをセレクトボックスに当てはめると、セレクトボックスは必ず１つの選択肢を選択してしまうので、「何も選択していない」ことを表す選択肢を選択している場合にはメッセージを出すということになります。 この、何も選択していないことを表す選択肢の文言はサイトによってばらばらで、空白だったり、「未選択」「選択してください」というような文言が使われます。 例えば、利用者アンケートの場合には以下のような選択肢になります。 ・選択してください←デフォルトで選択されている項目 ・使いやすい ・どちらでもない ・使いにくい ここで、「ユーザーは作業中のエラーを嫌う」ということを思い出し、デフォルトで何か一つ有効な選択肢を選択しておくようにしたら良いのでは
複数個の選択肢の中から順不同で複数を選択させる場合の入力方式としては、チェックボックスを利用する事が多いと思います。チェックボックスは一覧性があり、全体を把握できる点では分かりやすいですが、表示領域を広く取ってしまうため、使いづらい場合もあります。 今回紹介するSelectMultipleは、LIVEPIPE UIというライブラリの中の1つの機能なのですが、セレクトボックスで複数選択を可能にする入力インターフェースを提供しています。 初期状態では、通常のセレクトボックスとなんら変わりないのですが、横の"Select Multiple"をクリックすると、複数選択用のメニューが表示されます。 ここで、例えば上記のような３つを選ぶと、セレクトボックスの選択肢として、３つがセットになった選択肢が表示されるという仕組みです。 この方法であれば、省スペースで複数選択を実現できるので、インターフェースの
一般的にラジオボタンやチェックボックスは、それを選択することが何を意味するのかを表す文字列（ラベル）と共に用いられます。 そして、ラジオボタンやチェックボックスはサイズが小さくクリックしづらいため、WindowsなどOSレベルでは、ラベルをクリックした時もラジオボタンやチェックボックスをクリックしたのと同様の動作が起こるようになっています。 この仕組みはユーザビリティという意味でもアクセシビリティという意味でも有効なので、積極的に利用すると良いです。 これと同じことをWebでやろうとした場合には、labelタグを利用し、for属性に対象のidを正しく記述する必要があります。 <input type="checkbox" value="1" name="cb1" id="cb1" /> <label for="cb1">チェックボックス1のラベル</label><br /> <input
ラジオボタン（<input type="radio">）は複数の選択肢の中から1つを選択するための入力コントロールです。したがって、必ず1つ選択されている状態が正しく、RFCでもそのように定義されています。 At all times, exactly one of the radio buttons in a set is checked. If none of the <INPUT> elements of a set of radio buttons specifies `CHECKED’, then the user agent must check the first radio button of the set initially. 集合中のラジオ・ボタンは、いつも丁度1つがチェックされます。ラジオ・ボタンの集合の input 要素のどれも checked が指定されていなけ
ボタンのラベル付けについては、以前「ボタンのラベル付け～名詞？動詞？編～」や「ボタンのラベル付け～UPDATEボタン編～」でも考えたのですが、要するに大切なのはページ内の見出し、一覧、ボタンなど様々な要素を文脈を意識して適切に配置できるかということなのだと思います。 例えば、以下のような画面があった時に、「新規登録する」ボタンが「何」を新規登録するのかが分かるかということがまず大切です。 この例では、ページが「ユーザー一覧」となっていることから、「ユーザー」を新規登録するということが暗黙的に理解されますが、業務システムなど一ページに大量の情報がある場合には、ボタンの影響範囲が分からなくなったり、どれに対応しているのか分からなくなりがちです。そのような場合には、ページの中でどこからドコまでが一つの文章であるのかを視覚的に表現してあげる必要があります。（具体的には、線で囲む、色を分ける、物理的
JQuery Cycle Pluginは、複数の画像を切り替えて1つの領域に表示したい場合に、画像の切り替えエフェクトを表示するためのJQueryプラグインです。 最近では、Ajaxなどでページ遷移なく表示内容を切り替えるようなケースが多くなり、適切な切り替えエフェクトを表示しないと、変わったことに気づいてもらえなかったりするという問題も発生してしまいます。 複数から1つを選んで表示する方法としては、"<前へ 次へ>"のような形式のものもあれば、サムネイルから1つを選ぶ場合、スライドショーのように一定時間ごとに切り替える場合などもあると思いますが、JQuery Cycle Pluginはデモがとても充実していて、色々な場合の実装例を見ることができます。（デモ見ているだけでも楽しいです・・・） エフェクトの出来も良いので、機会があれば使ってみたいです。 ■リンク 公式サイト こちら デモ
■よくある（？）例 システム開発を行っているとこんなことがよく起こらないでしょうか？ 方法が複数ありどちらを選べばよいか判断できない 開発メンバーの中で実現方法に対して意見が割れる 良く検討して作ったものをユーザーや顧客に「使いづらい」と言われる 細かいグラフィックデザインの指摘や修正ばかりで全体を見てもらえない などなど このような事が起こる原因の一つに、「多くの場合、自分も顧客もユーザーではない」ということが挙げられます。 頭では「ユーザーが使いやすいように」とか「ユーザーにとって便利なように」と分かってはいても、いざ考えるときには、「ユーザー」が「自分」に置き換わってしまっていませんか？ しかし、それは仕方ないことなのです。なぜなら、いくら頑張ったところで（悲しいですけど）結局自分はユーザーではないからです。 ではどうすればよいかと言うと「ユーザーに登場してもらう」のが
jQuery TextAreaResizerはjQueryのプラグインとして提供されているスクリプトです。jQuery TextAreaResizerを使うと、ユーザーが自由にテキストエリアのサイズを変えられるようになります。規約の「テキストエリアのサイズは可変にしておく」で書いたように、テキストエリアが小さくて使いづらいというような点を解決し、ユーザビリティを高めるのに効果的です。 動作サンプルを見る限り、textareaだけでなく、iframeのサイズを変更できるようになるみたいですが、iframeのほうは処理が重くて高速に動かした場合にあまりきちんとは動きませんでした。でもtextareaのほうは大丈夫みたいですね。リサイズ中は微妙に白くなるなどのエフェクトもあり、分かりやすいと思います。 ■リンク 公式サイト こちら デモ あり ダウンロード 記事の中に記載 (ページ下段
月曜日, 12 月 10th, 2007 | Author: sibsiv | (4) (0) (0) (0) Total: 4 先日、昼食後にオフィスのカフェでWEB+DB press vol40を読んだのですが、ユーザビリティに関する特集があることに、いまさらながら気づきました。 丁度、先週社内でユーザビリティの勉強会を開いたのですが、 （読んでないのに）そのとき書いた資料と大分かぶっててちょっとびっくりすると共に、 認識が大体同じだということが分かり、ほっとしたのでした。 資料を書く前に気づいてたらもう少しすっきり書けたんですけどね。 ということで、私が書いたスライド資料も公開しようと思います。 (クリックで画像を拡大) > ユーザビリティとユーザー中心設計(PDF) スライド資料に関しては、煮るなり焼くなりご自由にどうぞ。 ppt形式もありますので、連絡頂ければ配布いた
製品のシリアルナンバーや、郵便番号など、あらかじめ決まっている桁数の文字を連続で入力する場合に便利な「Autotab: jQuery auto-tabbing and filter plugin」の紹介です。 ユーザーに連続した数字や記号を入力させる場合には、ルールに基づいて固まりに分けて入力させると入力がスムーズになります。 そのような、データを固まりに分けてユーザーの記憶や理解を助ける手法のことをチャンキング（chunking）と言います。 入力する際にも「CDケースの裏に書いてあるシリアルナンバーをサイトの入力フォームに書き移す」などの際に短期記憶を使うので、この手法が有効です。 しかし、入力エリアを分けた場合のデメリットとしては、全て入力するための手間が増えるということが挙げられます。 通常の場合には、文字を入力した後に次に入力したい領域をクリックし、また文字を入力するというよ
最近あまり時間が取れないこともあり、便利なJavaScriptの紹介記事が多くなってしまっているので、自分なりの見解を書いておこうと思います。 JavaScirptを使って視覚的に効果のある演出を行ったり、ユーザビリティを向上させるということに対しては、どちらかと言うと肯定的な考えを持っています。 一方、ブラウザ依存があることや、Webの操作に慣れていない人・ハンディを持つ方などには敷居が高くなるということも、充分に理解しなければいけないと思っています。 便利だから何でも使うというのではなく、何かしらのポリシーを持った上で効果的に使わないと意味が無いものになってしまいます。 最終的な判断基準としては、 そのシステムの対象ユーザーとして想定されるペルソナはどんな人か？ この機能が使えない（または代替手段を使わざるを得ない）場合に、どれくらいのロスが発生するか？ というようなことを考える必
画面全体を使って何かの作業を行うようなアプリケーションの場合、常に表示されるメニューを用意しておくと、その分使える領域が小さくなってしまい、不便なことがあります。 そうでなくても、例えば、メイン領域に項目が多い表を表示したい場合などには、メニュー部分が無ければもっと広く使えるのに･･･思うことが無いでしょうか？ そのような場合に、このSexy Sliding Javascript side bar menuを使うと、メニューを表示したり非表示にしたりエフェクト付きで切り替えることができます。 表示・非表示を切り替えるだけであれば、他の方法でもいくらでもできますが、このスクリプトの良い点は、隠れたり、表示されたりという動きがきちんと表現されているところと、ラベル部分がツマミのようになっていて、「引っ張り出せる」ことをアフォードしている点です。 いつでも使えるものではないと思いますが、「画面を
Proto.IPSはテキスト入力欄(input=text)に選択肢を追加することができるJavaScriptウィジェットです。 単純に入力よりは選択のほうが楽ですし、どのようなものを書けばよいのかイメージが付くので、うまく使えばユーザビリティの向上につながると思います。 テキスト入力欄に選択肢をつけるという視点でも便利ですが、今までラジオボタンで入力させていたものをテキスト入力で代用することも考えられます。 よくある以下のような選択肢の場合、サッカー、バレー、バスケットボール以外にしたければ、ラジオボタンで「その他」を選び、右のテキスト入力欄に入力するということを行います。 このような場合に、システムで厳密に管理する必要がなく、「その他」が割合的に多くなりそうなものであれば、Proto.IPSのような仕組みを使って代用すると、シンプルに実現することが可能です。 (2008/5/26追記)
先月発売したばかりの、「Webサイト設計のためのペルソナ手法の教科書」という書籍を読んでみました。この本はもともとSteve Mulder氏が書いたものを奥泉直子氏が翻訳したものです。洋書を翻訳したものは読みづらいという先入観があったのですが、この本はとても読みやすかったです。 「Webサイト設計のための」と書かれている通り、ペルソナ作成や分析の元となるデータがアクセス解析だったりという部分はありますが、手法としてはWeb以外にも適用できる部分が大きいと思います。 ペルソナについては少し勉強したことがあるけど実際使ったことが無い人や、作ってみたけどこのペルソナで正しいのかという疑問を持っている人にお勧めです。 以下メモ。
次のページ
このページを最初にブックマークしてみませんか？
『ウェブユーザビリティ.JP』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
