2010年4月6日火曜日

ページ内スクロールバー

最近、ページ内の特定の領域をスクロールできるようにしているウェブページをあまり見かけなくなりました。



フレームが非推奨になって以降徐々に減り続け、新規登録やブログを編集するときの「テキストボックス」としての使い方意外ではめっきり減っています。一部の使いにくいサイトにだけ残っているのが現状です。減った理由は、フレームが非推奨になったことがメインですが、マウスホイールでスクロールしたときに思うように動かせず、カクカクっと動いて使いにくいからだと思います。アクセシビリティやウェブ標準的には前者が理由で、ユーザビリティ的には後者です。

しかし、有名所のサイトでもページ内スクロールバーを採用しているところがあります。

例を挙げると、「Apple」と「Google」です。

Apple(各メニューやApple Store)


Google(通常の検索結果に入るリアルタイム検索窓)

これらのスクロールバーはマウスホイールを回してもページ内がスクロールされることはなく、マウスカーソルの位置を気にすることなくページ全体をスクロールすることができます。

どうしてもページ内にスクロール領域を設けたいときは、これらを参考に、マウスホイールでスクロールできないように実装すると使いやすくなると思います。

2010年3月26日金曜日

ボタンの三点リーダー



 クライアントアプリケーションのボタンラベルやメニューには三点リーダー「...」がついているものがあります。「さらに作業があります」という場合に使われているイメージですが、今回しっかりと調べてみることにしました。

ソシオメディアのUIデザインパターンにはこのように書かれていました。
メニュー項目につく「…」は、正確には「Ellipsis Character(省略記号)」と呼ばれる。メニュー項目に「…」を付けるのは、項目選択後にダイアログウィンドウなどを表示してユーザーからアクショ ンの引数を得る場合である(例えば、「開く…」を選択すると、対象ファイルを選択するダイアログが開く)。単に確認ダイアログを表示して「OK」か「キャ ンセル」かを問う場合や、メッセージダイアログを表示するだけの場合は、「…」は不要。ただしこの差は曖昧に理解されていることが多い。

 一度読んだだけでは私はよくわかりませんでした。自分で実際にいろんなソフトを触ってた気づいたのは、ボタンラベルに書かれていることを実行するためには、他に指定しなければならない情報があるという場合に[...]がつけられているということでした。

UIデザインパターンでは「開く…」の例が挙げられていましたが、 ああ、確かに「開く」には「ファイルパス」が必要だな、とやっと理解しました。

でもこのルールが適用できない例があります。


テキストボックスと共に使われている「参照」ボタンです。英語では「Browse」ですね。(参照ボタンのアクセスキーが「B」なのは英語ではBrowseだからです。 )場合によっては「...」しかない場合もありますね。

参照やブラウズは「参考にする、見る、閲覧する」という意味であって、「参照すること自体」には他に指定しなければならない情報は特にないはずです。ボタンラベルが「アップロードファイルを指定する...」となっているのであれば納得できます。

では、 「ボタンラベルに書かれていることを実行するためには、他に指定しなければならない情報がある」というルールが間違えているのかもしれません。他のルールを模索してみると、どうやら「ボタンラベルが動詞であり、なおかつ別のダイアログが開く」ということが関係してそうです。

しかし、その場合でも適用できないものがあります。

それは、メニューの「設定」です。英語版では「Options」です。)「Settings」の場合もありますが、ほとんど「Options」です。)Optionは他動詞でもあるみたいですが(辞書で調べて初めて知りました)が「s」がついているくらいなので「名詞」として使われています。日本語版では「設定」は動詞なので、上記ルールが適用できますが、元来の「Options」は名詞ですので、上記ルールでは説明がつきません。

UIデザインパターンでも、
「動詞 → 名詞」の順序で行うアクション
と書かれていて、さらにメニューの「開く…」を例に挙げていますが、その後のダイアログでは最終的にまた「開く」ボタンがあるのが一般的ですので、矛盾した説明がされていたり、さらに、
単に確認ダイアログを表示して「OK」か「キャンセル」かを問う場合や、メッセージダイアログを表示するだけの場合は、「…」は不要。ただしこの差は曖昧に理解されていることが多い。
 と、ボタンやメニューの三点リーダーの使用ルールは曖昧なようで、現状は明確な使い分けはされていないようです。

単に確認ダイアログを表示して「OK」か「キャンセル」かを問う場合や、メッセージダイアログを表示するだけの場合は、「…」は不要。ただしこの差は曖昧に理解されていることが多い。

単に確認ダイアログを表示して「OK」か「キャンセル」かを問う場合や、メッセージダイアログを表示するだけの場合は、「…」は不要。ただしこの差は曖昧に理解されていることが多い。

ですが、「ボタンラベルが動詞であり、なおかつ別のダイアログが開く」というルールはあながち間違えてないと思いますので、基本はこの考え方でいいと思います。また、例外的に「設定...」(「Options...」)があるように、ボタンやメニューひとつひとつについて慣例を調べるのが正しいやりかたなんだと思います。


私としては、そこまで気にしている人はいないですし、三点リーダーをつけるとなるとお客さんや事業部が「これはついてないのはなぜですか?」と言い出しかねないので、はじめからつけなくてもいいじゃん!と考えたいのは本音です。

というワケにもいきませんので、やはり、ルールと例外は知っておくのがベターなんでしょうね。

とほほ... (T)

2010年3月13日土曜日

さまざまな業務システムのナビゲーションメニュー

業務システムはメニューが大量にあるにも関わらず、メニューのコンテンツが少なくなりがちです。前回とりあげたE-CUBEのメニューを例に挙げると、以下のようなメニューにわけられています。

  • 基本管理情報
    • SHOPマスタ
    • 特定商取引法
    • 配送設定
    • 支払方法設定
    • ポイント設定
    • メール設定
    • SEO管理
    • 会員規約設定
    • 郵便番号DB登録
    • サイト管理設定
    • 定休日管理
  • 商品管理
    • 商品マスタ
    • 商品登録
    • 商品登録CSV
    • 規格管理
    • カテゴリ管理
    • カテゴリ登録CSV
    • 商品並び替え
    • レビュー管理
    • トラックバック管理
  • 顧客管理
    • 顧客マスタ
  • 受注管理
    • 受注管理
    • 新規受注入力
    • ステータス管理
  • 売り上げ管理
    • 期間別集計
    • 商品別集計
    • 年代別集計
    • 職業別集計
    • 会員別集計
  • (以下略)

 これで半分くらいです。

その割りに コンテンツは多いものから少ないものまで様々です。


これらのメニューを画面の左側に一覧で表示したら大変なことになるので、コンパクトに見えるように工夫するのが普通です。EC-CUBEでは、上部にグローバルメニューがあり、左側にサブメニューがあります。グローバルメニューは適切なボタンや文字サイズが保たれていますし、サブメニューも縦に長くなりすぎてないのでうまく収まっていると思います。

業務システムに限らず、ナビゲーションメニューのUIパターンは7つぐらいあると思います。

  1. 上部に一覧表示
  2. 左側に一覧表示
  3. 上部グローバルメニュー×左サブメニュー
  4. 上部グローバルメニュー×プルダウンメニュー
  5. 上部グローバルメニュー×サブメニューヘのリンク用ページ
  6. 左メニューでアコーディオン
  7. メインメニュー用のページ×各ページ左メニュー
  8. コンボボックス(フォーム)

それぞれに関する詳細はいずれ書くとして、どれが優れていてどれが劣っているなんてことは一概に言えません。メニューやカテゴリの量によってどれがもっとも適切かどうか変わりますので、 個別に最適なレイアウトを考える必要があります。

参考になりそうなナビゲーションメニューのサイトを載せておきます。
Apple
Googleリーダー
asahi.com(朝日新聞)
価格.com
Sony Japan
Sony Ericsson

2010年3月11日木曜日

使いやすそうな業務システム「EC-CUBE」

ユーザビリティ的にもデザイン的にもよくできていると思える業務システムを見つけました。

EC-CUBE (デモサイト)
 




ナビゲーションメニューのレイアウトや、全体的なデザインテイスト、細かいパーツのデザインが良いと思います。

業務システムは、GoogleドキュメントやGMailをよく参考にさせてもらっています。さまざまな業務システムの調査をして、ベストプラクティスを考えたいと日々思っていますがなかなか動けません…。

リンク:
EC-CUBE (デモサイト)

2010年3月9日火曜日

リスト項目に対するアクションボタンの位置

会社で業務システムのUIデザインを担当することがありますが、リストから項目を選らんでアクションを起こす画面での「アクションボタン」の置き方について議論されることがあります。

  1. 項目毎にアクションボタンを設置するのか
  2. リストの上端と下端に設置するのか

1.項目毎にアクションボタンを設置する場合

操作回数は減りますが画面はごちゃごちゃします。
 


2.リストの上端と下端に設置する場合

一方「2.リストの上端と下端に設置する場合」は操作回数が増えてわかりにくくなりますが画面はすっきりします。


一度チェックボックスで選んでからアクションボタンを押すことになりますが、分からなかった場合、太字になっている件名をとりあえず押してみようという気にさえなれば、詳細画面にもアクションボタンがあります。


1と2のどちらにするかの判断は、操作回数やわかりやすさというよりも、「編集」や「削除」をどれくらいの頻度で行うか、システムを使う目的は何かが重要なのではないでしょうか。上に挙げた「 1.項目毎にアクションボタンを設置する場合」の例はブログの編集画面で、「2.リストの上端と下端に設置する場合」の例はメーラーです。「編集する」「見る」といったタスクの場合、どういった操作を行うことが多いのかを考えてどちらのパターンを選ぶのか判断するのが良いと思います。
 
Copyright 2009 Deguin. Powered by Blogger Blogger Templates create by Deluxe Templates. WP by Masterplan