質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.90%

入力値制限、入力値検証どちらにすべきか

解決済

回答 5

投稿

  • 評価
  • クリップ 3
  • VIEW 1,548

mikupedia

score 155

テキストボックスの入力テキストを数値に変換して使用する場合に
あらかじめテキストボックスに入力制限(数字以外入力不可)を設けるか、
全ての入力を許容して入力テキストを入力毎または任意タイミングで検証して
エラーにするかのパターンが考えられます。

これは好みの問題なのかもしれませんが
自分の中で判断基準が不透明であるためどちらを採用すべきなのか迷っています。

一般的にはどちらを採用すべきなのでしょうか?
両方採用すべきなのかもしれませんが、そこまで必要か疑問にも思えます。

もし、ガイドライン的なものがあれば教えていただけますでしょうか?

プログラミング言語は問いません。
(当方はWPFでアプリケーションの開発しております。)

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

checkベストアンサー

+2

入力値検証と入力値制限は目的が異なると思います。

  • 入力値検証はシステム(プログラム)を正常に動作させるために必須です。
    ※システムによっては入力制限を行うことで入力値検証を省略(入力値制限で代用)可能な場合もあると思います。
    が、この場合でも「入力値検証を省略(入力値制限で代用)する」ことはあくまで例外であることを認識したうえで、要件・予算・納期(開発期間)などの条件により省略の是非を判断すればいいでしょう。

  • 入力制限はユーザビリティ向上を目的としており、入力値検証で行っている制限のもとで利用者に使いやすいI/Fを提供するために実施すればいいです。
    ※ リストボックスからの選択、チェックボックスやラジオボタンで選択なども広い意味では入力制限にあたると思います。入力値検証を通る入力をユーザーに負担にならないように如何に入力させるかが入力制限(UI)の胆ですね。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

重くなっているPCや反応の悪いタッチパネルなど、ユーザーに「キー入力が通ったか」わからない状況というのがあります。
こういう状況で入力制限、つまりキー入力が弾かれることがあるとユーザーにとっては拒否されたのかまだ通っていないだけなのかわからず不安なUIになります。

もし入力制限にするのなら、拒否すると同時にバルーポップアップで制限の詳細を指摘する必要があります。

また、別の観点としてIMEの未変換文字列をどうしますか? 電話番号入力欄で数字のみしか受け付けないとしても、ユーザーの中には「でんわ」で変換して入力したい人もいます。それを邪魔しないように制限できるでしょうか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/01/26 19:30

    >ユーザーの中には「でんわ」で変換して入力したい人もいます。
    なるほど、これは頭にありませんでした。
    このようなパターンだと入力制限を設けてしまうとユーザに負担をかけてしまいますね。

    キャンセル

+1

いろんなパターンがあるのは好みの問題でなく想定ユーザーの層と数、セキュリティ等の問題と思います。
消費者向けなどの多くの人に使ってもらう事が重要であればより優しく。
ビジネス上の影響の大きいシステムだったら工数をかけて。
想定ユーザーが社内の数人だったら工数を少なく。
不正な入力を完全に防げる仕組みになるかどうか。
のあたりを考慮して、どのようなものにすべきかを検討すべきと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/01/26 19:28

    ご指摘の通り、ユーザ次第になってしまいますよね。
    社内アプリかエンドユーザー向けアプリによっても仕様で逃げられるときとそうでないときもありますし。
    理想と現実の線引きでいつも苦労します。

    キャンセル

0

どっちでもいいんじゃないでしょうか?
ただ年配の方は入力ができないとパニックになることがあるので、不適切な入力にはわかりやすいエラーメッセージを出すのがいいと思います。
そうであれば、検証の方が作りやすいかもしれません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

入力値の検証はプロセスとしては必要なものですから、省略できたとしても建前上は「空の検証プロセスがある」として欲しいところです。

その上で誤解を恐れずに断言します。
入力前に制限できるものは、全て制限すべきであると考えております。

そのためには、テキスト入力は極力避ける必要があります。
1.数字の入力にはテキストボックスを使うのではなく、数字入力専用のコントロールを使う。
2.選択肢が有限の物は、テキストボックスで入力させるのではなく選択させる。
などです。
これは入出力の水際作戦とか言われています。

特に、デスクトップアプリケーションで登録ボタンを押した後に検証エラーをだすのはとてもカッコ悪いと思います。
Webアプリケーションならば、ある程度は仕方がありませんがユーザー側に立った場合ガッカリしますよね?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/01/23 19:18 編集

    >「空の検証プロセスがある」として欲しいところ
    >入力前に制限できるものは、全て制限すべき
    制限、検証の両方が必要という考えですね。

    >テキストボックスで入力させるのではなく選択させる
    確かにある程度、入力パターンが決まっていればコンボボックスなりで選択させるほうが
    利用者側にとっては使いやすいですね。なるほど。

    >登録ボタンを押した後に検証エラーを出す
    確かにこれは、利用者にとって不親切ですし、無駄なオペレーションになりますね。
    WPFではMVVMパターンを意識したときに、View側のTextBox入力毎に変更通知を行えるので
    ViewModel側ではリアルタイムに検証を行うことができますね。
    なので、常に検証を行い、リアルタイムにエラー表示することができるのでこれについては問題なさそうですね。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.90%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る