検索条件と検索結果が同じ画面

投票結果総投票数：43
クリア	26票	60.47%
クリアしない	17票	39.53%
投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。

投稿者

投稿内容

Beatle: ぬし; 会議室デビュー日: 2003/06/09; 投稿数: 394

投稿日時: 2004-09-06 12:00

引用:
おかしいことは、全く別である筈です。しかし、システムの作りを知らないユーザに対してエラーメッセージを出さないということは、ユーザにとって判断に必要な情報を十分に提供していないということになると思います。

確かにそうなんですが、日付の指定間違い（この場合、有り得ない日）というのは、
「システム作り」に起因するところなんでしょうか？（親切ではあると思いますが）
「当月度内のみ有効」「未来日付は入力してはいけない」等の個別システム条件が
ある場合には必須だと思いますが．．．

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2004-09-06 12:04

unibon です。こんにちわ。

「１．」と「２．」のどっちもアリだと思います。具体的な事例を今すぐには思いつかないのですが、たぶん巷には両方が混在しているでしょう。たとえば水道の蛇口は、下げ吐水がなくなって上げ吐水に統一されるようですが、ソフトウェアのユーザーインターフェースは一長一短があるので、統一というのは蛇口に比べれば難しいような気がします。
それよりも、妥協になりますが、画面をみたらどちらの方式かが分かるようになっているかどうかのほうが重要だと思います。たとえばラジオボタンとチェックボックスは形が違うので、どんな挙動をするかが分かりますよね。そんな感じです。

おばけ: ぬし; 会議室デビュー日: 2002/11/14; 投稿数: 609; お住まい・勤務地: 東京都江東区

投稿日時: 2004-09-06 12:14

引用:
確かにそうなんですが、日付の指定間違い（この場合、有り得ない日）というのは、「システム作り」に起因するところなんでしょうか？

あり得ない日を入力した場合どう処理するか(エラーとして返すか、丸めて処理を
続行するか、など)も、システムの作りによって変わりませんか？

例えば、2月31日と入力したら勝手に2月28日に丸められてしまい、その「丸め」
という処理のことをシステム側がユーザに通知しなかった場合、ユーザはいったい
いつの日付で処理が行われたか分かりませんよね？

まあ、ユーザの想定とシステムの挙動にどれだけのギャップがあるか、というのが
重要で、そのギャップを埋める為に(エラー)メッセージで通知するわけです。
このトピックって、「そもそも要件によって変わる」という答え方(答えになって
いないかもしれませんが・・・)もあるかと思います。

良太: 会議室デビュー日: 2004/04/09; 投稿数: 14

投稿日時: 2004-09-06 13:24

引用:
Beatleさんの書き込み (2004-09-06 10:38) より: クリアに入れましたが．．．「クリアしない」という場合、正しい検索条件を指定しても、抽出件数が０件でも前の結果が残っているってことですか？

もちろん正しい検索条件を指定して、抽出件数が０件の場合は検索結果をクリアし、エラーメッセージも出力しません。ちなみに2月31と入力した場合、Validationチェックでエラーとなります。問題はValidationチェックでエラーとなった場合、元々の検索結果をクリアするか、しないかの問題です。こんなシステムがどこかにあれば、説得力があると思いますが、普通は検索条件と検索結果の画面は分かれていますね。

おばけ: ぬし; 会議室デビュー日: 2002/11/14; 投稿数: 609; お住まい・勤務地: 東京都江東区

投稿日時: 2004-09-06 13:36

私、一度クリアに入れたんですが、やっぱりクリアしないの方が良いかも

というのも、例えば「2月31日」という入力はバリデーションエラーになると
して、その際には「2月31日」という入力データは残したまま、「日付が存在
しない」というエラーメッセージを出力する、というのが私にとっては最も
妥当な実装に思えるからです。(勿論、要件によって変わりますけれど)

ユーザが入力したままのデータを示し、そのデータがエラーであることを示し、
修正を促す。これが良いのでは？

未記入: 大ベテラン; 会議室デビュー日: 2003/11/24; 投稿数: 121

投稿日時: 2004-09-06 13:58

「クリアする」に一票入れました。

引用:
入力値の検証(Validation)を行い、妥当でなければエラーメッセージを表示するのは必須ではないでしょうか？

エラーメッセージは必要と考えましたが、「入力値の検査」処理自体が
新しい作業(新規検索)に含まれると思います。よって、バリデーションを
かける前に既存の結果をクリアしておくべきかと。

※ Webシステムで, JavaScript でバリデーションかけていると、
HTMLで表示されている結果を消すのすごく面倒だけどね…。

「間違った検索条件」と「前回検索結果」が同一画面上に存在すると、
どうしても勘違いしてしまう人がでてきますからね。気を付けたいところです。

引用:
また顧客の要求仕様によっては　・極力ユーザに対してエラーメッセージの表示はしたくない！

そういえば、Windows XP のユーザーインターフェイスデザインガイドラインでも
そのあたりの指針が変更されていますね。従来、エラーダイアログを出してユーザーに
通知するとなっていたのが、ツールチップ(バルーン)を使うことが推奨されるように
なっています。

Windows 2000 以前と Windows XP でログオンに失敗してみると、デザインガイドラインの
変化を体感することができます。なるほど、XP ガイドラインのほうが良さそう。

でゅうく: 大ベテラン; 会議室デビュー日: 2003/11/30; 投稿数: 129

投稿日時: 2004-09-07 16:34

引用:

おばけさんの書き込み (2004-09-06 13:36) より:
私、一度クリアに入れたんですが、やっぱりクリアしないの方が良いかも

というのも、例えば「2月31日」という入力はバリデーションエラーになると
して、その際には「2月31日」という入力データは残したまま、「日付が存在
しない」というエラーメッセージを出力する、というのが私にとっては最も
妥当な実装に思えるからです。(勿論、要件によって変わりますけれど)

ユーザが入力したままのデータを示し、そのデータがエラーであることを示し、
修正を促す。これが良いのでは？

この投稿からおばけさんは検索条件と検索結果の両方をクリアすると捉えているように思いますが、大元の質問は検索結果についての挙動に関してではないでしょうか。
エラーの通知を行なう場合には、ユーザーの入力内容を返したほうが良いというよりも、返すのが必須に近い内容だと思います。

〔追記〕
クリアするに投票しました。

[ メッセージ編集済み編集者: でゅうく編集日時 2004-09-07 16:36 ]

Beatle: ぬし; 会議室デビュー日: 2003/06/09; 投稿数: 394

投稿日時: 2004-09-08 12:33

今回の件についてあまり気にしたこと無かったので、とりあえずこれまで構築した(と
いうか関係した）ものをちらっと見てみました。すると３パターンになっていました。

パターンＡ
検索条件入力画面は独立で、検索を実行すると検索条件と結果表示画面に遷移するもの。
結果表示画面では検索条件は表示のみで、条件を変える場合には検索条件画面に戻る
必要があるもの。（当然、エラーの場合には結果の画面に遷移しないので、クリアの
概念は無い）

パターンＢ
検索条件をどんどん変えれるもの（ＧＯＯＧＬＥのような感じ）。エラーチェックは
ほぼなし。検索できない、またはヒットしない場合には結果画面に表示なし。（また
は検索結果０件のような表示）

パターンＣ
検索条件と結果が同一画面にあるが、フレームが分かれているもの。
検索ボタンをクリックした際、チェック前に結果表示フレームのみ初期化。結果的
にＳＣＲＩＰＴ内でエラー表示した場合、クリアされているように見えますが、
この場合、ＳＣＲＩＰＴでのエラーもエラー用のhtmlに結果フレームを遷移させて
いるものもありました。

まぁ、ユーザーの要求とかもあるでしょうが、システム内での統一性という面もあるので
難しいところですね。

[ メッセージ編集済み編集者: Beatle 編集日時 2004-09-08 12:38 ]

«前のページへ 1|2|3 次のページへ»

検索条件と検索結果が同じ画面

スキルアップ／キャリアアップ（JOB@IT）