レイアウトを変更せずに小数値を入力します

プログラム/ Webサービスのインターフェースに小数値を入力する頻度はどのくらいですか？ 場合によっては、おそらく、そのようなフィールドの不適切な動作に直面したでしょう。 たとえば、私は定期的に絶対に愚かなフォームについて額を打ちました。 分数値を入力すると白熱が発生する理由と、それをどうするかを知りたいですか？ 猫へようこそ。



私の観察によると、それらの動作の次のアルゴリズムが最も頻繁に見つかります。

• クリックする場所を推測します。 このようなフィールドは、デスクトップアプリケーションで最もよく見られます。 このフィールドは、数字と小数点を除くすべての文字の入力を厳密にフィルタリングします。 すべてが論理的であるように思われます。 しかし、実験を行ってみましょう。目を閉じて、ボタンを1つ押すだけで、このような厳密なフィールドに小数点記号を入力しようとします。 うまくいきましたか？ ああ、事実ではありません！ 厳密なフィルタリングの問題は、ユーザーが次のことを行うことです。a）開発者が2つの標準小数点のどちらを使用したかわからない b）数字を入力するときに、現在のキーボードレイアウトを考慮する必要がない場合があります。 その結果、ケースの半分以上でセパレーターを入力しようとしても失敗します。 一度に1つの値を入力する必要がある場合、これはそれほど重要ではありませんが、小数を入力する必要がある場合は定期的に行う必要があります。このフォームの動作は疲れます。
• 精度は何よりも重要です。 このタイプはウェブの特徴です。 入力はまったくフィルタリングされず、フォームを保存しようとすると、次の3つのいずれかが発生します。エラーメッセージが表示されます。 入力フィールドがクリアされます（または前の値が返されます）。 何も起こりません（フォームはバックグラウンドでチェックされ、その送信はユーザーに見える理由でブロックされます）。 どうやら、一部の開発者は、ユーザーがフォームに入力する内容を常に知っていると単純に信じています。
• まあ、このようなもの...不器用なフォームの第三のタイプは、どこでも定期的に発生します。 彼らの行動を予測することはほとんど不可能です。 たとえば、ホームアカウンティングを実行するための一般的なシェアウェアプログラムの1つでは、間違った小数、除算を入力しようとすると（より正確には、現在のレイアウトにない区切り文字が付いたボタンをクリックすると）、数字の全体がトレースなしで消えます。 別の（これも無料ではありません）ユーティリティでは、通常、数字以外の文字とプログラムが予期する区切り文字を入力すると、システム例外が発生します。 最後に、1つの非常に大きなロシアのオンラインストアでは、無効な文字を入力すると小数点と小数部分に2つのゼロが挿入され、小数点を入力すると...が挿入されます。

一般に、XXI世紀の中庭ではインターフェイスが開発されており、小数値を入力するなどの些細なアクションは依然としてユーザーの頭痛の種です。 数年前、私は小さなプログラムを設計（および部分的にコーディング）する機会がありました。 当然、上記の動作を繰り返したくありませんでした。 いくつかの考えの結果、かなり単純なアルゴリズムが生まれました。



それでは、小数をどうするか？ まず、入力をフィルタリングする必要があります。 フォームの送信時に確認するのは良いことですが、スクリプトの横からキックした後ではなく、最初に値を入力できる方がユーザーにとってははるかに便利です。 このようなフィルターの私のバージョンは次のとおりです。

1. 0〜9の数字を入力できます。
2. 任意のレイアウトで可能な小数点区切り文字を含むボタンを押すと、キーボードから送信された文字を入力フィールドの正しい小数点区切り文字に置き換える必要があります。
3. 複数の小数点記号を入力する試みをブロックします。
4. 入力データのタイプに応じて、入力数の小数部分の文字数を制限します。

例1.ロシア語のレイアウトのユーザーは、キー[1] [2] [3] [b] [4] [5]を順番に押します。 入力フィールドの結果： 123.45

例2.英語レイアウトのユーザーがキー[1] [2] [3] [Shift +？] [4] [5]を順番に押します。 入力フィールドの結果： 123.45

このアルゴリズムの結果は、優れた（すごい）効果をもたらします。 ユーザーはレイアウトについて考える必要がなくなり、Shiftキーを押しながら、プログラマーが小数点またはコンマを使用したかどうかを推測します。 ライブユーザーの実験では、そのような「スマート」な入力フィールドで1〜2週間作業した後、通常のフィールドに戻ると、キーボードが壊れてプログラマーを殺すという欲求が生じることが示されました。



PS。 正直なところ、このアルゴリズムは非常に単純なので、このアプローチが1回または2回以上使用されたことは146％確信しています。 しかし、未知の理由で、それは広く分布しませんでした（あなたが私を信じないなら、最も近い入力フィールドを見つけて、その動作を確認してください-私が引用した「正しい」アルゴリズムではなく、3つの「不器用な」アルゴリズムのいずれかに適合することはほぼ確実です）。



PPS DelphiまたはLazarusで書く人のために、対応する言語でこのアルゴリズムを実装するCurrencyEditコンポーネントへのリンクを提供します： GitHub 。



PPPS それぞれのプログラムの作者に敬意を払って特定の例を挙げているわけではありません。 Habrの読者のいずれかが自分のコードで「誤った」アルゴリズムを見つけ、それらを「正しい」アルゴリズムに変更することに決めた場合、ユーザーからの感謝が保証されます。



PPPPS どういうわけか私は完全に主題ではありません：HTMLフォームでは、原則として、入力をフィルターできますか？