memo.xight.org

日々のメモ

カテゴリ : ユーザビリティ

1ページ目 / 全1ページ

やってはいけない10のユーザインタフェース

Summary

 1. ID,ニックネームを考えさせてはいけない.半角英字開始限定は論外.
 2. パスワードに英数混在や5文字以上を強制すると問い合わせ激増,アクティブ会員率減.
 3. チェックボックスで項目選び,別のボタンで操作を決定するUIはわかりにくい.
 4. フォントサイズはブラウザ設定で可変できないとだめ.
 5. アイコンは理解されない 使う場合は添え書きを.
 6. ブラウザにてリンクを新しいウィンドゥで開くのはNG.
 7. 1つの画面に多数の機能を並べてはいけない.
 8. AJAXやFlashで可能になったからといってドラッグ&ドロップは使うな.
 9. ダブルクリックされるとまずいボタンはダブルクリック禁止にせよ.
10. 「かんたんモード」を設定しても使わない.

Reference

キャズムを超えろ! - 団塊〜シニア層向けのWeb設計 やっちゃいけない10のUI
http://d.hatena.ne.jp/wa-ren/20061117/p1

虫眼鏡のアイコンは「検索」か「拡大」か

Summary

説明が必要なアイコンは用いない
処理を開始するスイッチをアイコンに頼らない
制限コントロールの選択肢に否定文を使わない
肯定ボタンのラベルにあいまいな文言を用いない
ナビゲーションをアクションのように見せない
紛らわしいアイコンやラベルは再考する

説明が必要なアイコンは用いない

ユーザによって違う意味に理解される可能性もある.
虫眼鏡のアイコンが「検索」を意味するか「拡大」を意味するか.

処理を開始するスイッチをアイコンに頼らない

Wordなどの「標準」ツールバー.
アイコンから処理の予測が必要.

プロパティを変更する場合の良い例は,Wordの「書式設定」ツールバー(太字,斜体,下線,囲み線など).
得られる結果をグラフィックで表現すればよいため,具体化しやすくアイコンの効果を得られやすい.

制限コントロールの選択肢に否定文を使わない

肯定文と否定文の混ざった選択肢を用いると理解が難しくなる.
否定文に二重否定を用いるとさらに理解が難しくなる.

悪い例はInternet Explorer のオプションダイアログ.
□ スクリプト エラーごとに通知を表示する
□ スクリプトのデバッグを使用しない
□ スケジュールに従ってオフライン項目の同期をとる
□ スムーズ スクロールを使用する

例外は,選択肢として「いずれも選択しない」行為を能動的に行なう場合.
○ 会社員
○ 自営業
○ 主婦
○ 学生
● 該当無し

肯定ボタンのラベルにあいまいな文言を用いない

悪い例は「OK」ボタン,「次へ」ボタン.
動作内容をユーザが推測する必要がある.

動作内容を記述することで回避可能.
「入力内容を送信する」,「配送先の入力へ進む」など.

ナビゲーションをアクションのように見せない

画面遷移のためのナビゲーションと,
動作確定のためのアクションのリンクを区別する.

ナビゲーションであれば「ダウンロード画面へ進む」.
アクションであれば「ダウンロードを開始する」.

紛らわしいアイコンやラベルは再考する

アイコンやラベルは限られた表示領域の中で視覚的に表現する.
制作者の意図が確実にユーザに伝わるかは確認が困難.
第三者による検証が必要となる.

Reference

@IT - 虫眼鏡のアイコンは『検索』か『拡大』か?
http://www.atmarkit.co.jp/fwcr/rensai/usabilitytips03/01.html

AJAX Interface Design - フォームとラベルの配置など,インタフェースデザインについての考察

Reference

LukeW: AJAX Interface Design
http://www.lukew.com/resources/articles/ajax_design.asp

LukeW: Web Application Form Design
http://www.lukew.com/resources/articles/web_forms.html

Functioning Form - Web Application Form Design Expanded
http://www.lukew.com/ff/entry.asp?155

via

オレンジニュース - 2006-08-16
http://secure.ddo.jp/~kaku/tdiary/20060816.html#p13

onsubmit で submit ボタンを disable にしてユーザビリティを良くする

function disableSubmit(form) {
  var elements = form.elements;
  for (var i = 0; i < elements.length; i++) {
    if (elements[i].type == 'submit') {
      elements[i].disabled = true;
    }
  }
}


<form method="get" onsubmit="disableSubmit(this)">
  <input type="text" name="q">
  <input type="submit" value="search">
</form>


ボタンのvalueが渡らなくなる罠がある.
そのような作り方はしていないので,とりあえず保留.

Reference

naoyaのはてなダイアリー - onsubmit で submit ボタンを disable にしてユーザビリティを良くする
http://d.hatena.ne.jp/naoya/20050803/1123053496
naoyaのはてなダイアリー - submit ボタン disable 技の罠
http://d.hatena.ne.jp/naoya/20050804/1123152230

OKボタンの位置はどこが適切か

Reference

OKボタンの位置はどこが適切?
http://www.phenomena.co.jp/phenomena/uid_lab/ok_btn/
OKボタンの位置はどこが適切? - 結果
http://www.phenomena.co.jp/phenomena/uid_lab/ok_btn/test_result_lr.html

via

cl.pocari.org - OK ボタンの位置はどこが適切?
http://cl.pocari.org/2005-12-25-2.html
OKボタンはキャンセルから大きく離して右下に - ただのにっき (2006-01-31)
http://sho.tdiary.net/20060131.html#p01