懸念
気になるのは、「ユーザが明示的にカンマを削除/入力した時の挙動」と、
- 1234 -> 1,234 -> 1234(ユーザがカンマ削除) -> ????
- 123 -> 123,(ユーザがカンマ入力) -> 123,4 -> ????
「ユーザが明示的に数字を削除した時の挙動」と、
- 1234 -> 1,234 -> 1,34(ユーザが2を削除。入力ミスした為、修正しようとしている) -> ????
「ユーザが明示的に数字/カンマ以外の文字を入力した時の挙動」と、
「ユーザがIME変換機能を使って数値入力する事がサポートされているのか(IME変換前の段階で勝手に補完されるのは好ましくない。IMEの単語登録された辞書から入力する人もいる)」と
「マウスを使ったクリップボードからの貼り付けが有効なのか(キーボード入力されないので、keyupは無効)」です。
入出力を一カ所に統合するデメリット
入力と出力を一つのテキストボックスで行うと、
- ユーザの意図しない入力が発生するので直感的ではない
- ユーザがどんな入力をしてもいいように、様々なパターンを考慮しなればならない
という問題があります。
大体、勝手にガンマが挿入されると、入力ミスした時にカンマ分もカーソルを戻さなくてはならず、入力の手間だけ考えると面倒くさいです。
質問者さんが求める実装はあくまで見た目が美しいという景観重視の発想で、ユーザビリティは考慮されていないように思います。
私としては、「ユーザが好む方法で入力出来ること」「ユーザの入力を阻害しないこと」が大前提なので、入力と出力は別々の場所にあるべきと考えます。
直観的
追記を読みましたが、直観的ではないと思いました。
ここでいう「直観的ではない」は
- キーボードで 1 を入力 → 1 が出力される
- キーボードで [←] を入力 → カーソルが1つ左に移動する
というようなPC操作の一般常識的な動作を逸脱していないこと、です。
その手の逸脱した動作は作り手にとっては「使いやすい」と思っても、世間一般の人には学習コストが高すぎるのです。
1.数字を入力/削除すると、数字を3桁ずつカンマ区切りできる。
「なぜ勝手にカンマが挿入されるんだ?入力してないカンマが勝手に入るなんてけしからん。大体、カンマ区切りの数字なんて見づらいだろうが!」
(カンマ区切りの数字が見やすいかどうかははっきりいって主観です。ならば、一般常識的な動作におさめた方が批判は少ないでしょう。「1234と入力して、1234が出力されるなんてけしからん!」と怒る人はいません。)
金額の入力欄なので、入力文字は半角の数字のみとなります。
「"ひゃくまん" と入力して、"1000000" にIME変換しようとしたのに出来んぞ。どういうことだ?」
2.カーソルを矢印キーで移動した場合、カンマの部分は自動的に飛ばされます。
「なぜカーソルが2つ分移動するんだ?矢印キーは一回しか入力してないのに!」
3.数字の貼り付けは見落としていたのですが、動作を確認したところ、カーソルが外れた段階でカンマが挿入されました。
「なぜクリップボードからの貼り付けだけ挙動が違うんだ?他にも穴があるんじゃないのか?」
ようするに、作者が(個人的に)既存UIに不満を持って解消した独自UIは、既存UIに慣れ切った一般人には使いにくいという事です。
新しいUIを提案するということは、そのUIの学習コストの支払いを利用者に強要する事に他なりません。
Selection API
技術的観点あと、気になったのはアニメGIFでは右端から入力/削除しかしなかった事ですね。
カーソルを数字の真ん中に持っていって削除or数字挿入して、カーソル位置が保持されるようなら、カーソル制御も行っています。
window.getSelection 等を使って、カーソル位置を記憶し、置換処理後に適切なカーソル位置を計算して移動しているのでしょう。
そこまでいくと、範囲選択に対応しているかが興味深いですが、
- 12,345→1と2の間にカーソルを移動し、Shiftを押しながら、[→] キーで4と5の間まで移動→1を入力→????
- 12,345→1と2の間にカーソルを移動し、Shiftを押しながら、[→] キーで4と5の間まで移動→[Delete] を入力→????
- 12,345→1と2の間にカーソルを移動し、Shiftを押しながら、[→] キーで4と5の間まで移動→[Backspace] を入力→????
Re: zilch さん
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/08/30 01:00
2018/08/30 01:27
2018/08/30 02:32