Ada beberapa faktor yang perlu dipertimbangkan. Untuk mengilustrasikan poin-poin itu, saya akan menggunakan contoh bidang di mana pengguna harus memasukkan persentase dalam konteks kuota yang ditentukan untuk tugas tertentu dalam hal berapa banyak ruang disk yang bisa digunakan tugas tersebut. 0% berarti tugas tidak akan bisa menulis apa pun ke disk; 100% berarti tugas bisa mengisi semua ruang disk. Nilai-nilai di antaranya berarti apa yang dimaksud.
Sebagai pengembang, Anda mungkin mempertimbangkan bahwa nilai yang dapat diterima adalah [0, 1, 2, 3, ⋯ 99, 100], dan yang lainnya konyol. Mari kita lihat mengapa pengguna masih bisa memasukkan nilai-nilai "konyol" itu.
Salah ketik
%^
Pengguna memasukkan nilai 56, tetapi secara keliru ditekan Shiftsaat memasukkannya (misalnya karena pada keyboard Prancis, Anda harus menekan Shiftuntuk memasukkan angka, dan pengguna terus-menerus beralih antara keyboard Prancis dan QWERTY).
Dengan cara yang sama, Anda bisa mendapatkan nomor, dengan sesuatu setelah atau sebelum itu, atau di antaranya:
56q
Di sini, pengguna mungkin memasukkan digit, diikuti oleh tab untuk pindah ke bidang berikutnya. Alih-alih menekan ⇆ , pengguna menekan tombol tetangga.
Kesalahpahaman dan salah tafsir
Input kosong mungkin yang paling biasa. Pengguna membayangkan bahwa bidang itu opsional, atau tidak tahu apa yang harus dimasukkan dalam bidang ini.
56.5
Pengguna berpikir bahwa nilai floating point dapat diterima. Entah pengguna salah, dan aplikasi harus dengan sopan menjelaskan mengapa hanya nilai integer yang diterima, atau persyaratan awal yang salah, dan masuk akal untuk membiarkan pengguna memasukkan nilai floating point.
none
Pengguna salah mengerti bahwa ketika diminta untuk ruang tugas yang bisa diambil, aplikasi mengharapkan nomor. Ini bisa menunjukkan antarmuka pengguna yang buruk. Misalnya, menanyakan kepada pengguna "Berapa banyak ruang disk yang harus diambil oleh tugas?" Mengundang masukan semacam ini, sementara bidang dengan tanda persen berikut akan menerima lebih sedikit dari masukan semacam itu, karena "tidak ada%" tidak menghasilkan banyak akal.
150
Pengguna salah mengerti apa artinya persentase dalam kasus ini. Mungkin pengguna ingin memberi tahu bahwa tugas tersebut dapat mengambil 150% dari ruang yang saat ini digunakan, jadi jika pada disk 2 TB, 100 GB digunakan, tugas tersebut dapat menggunakan 150 GB. Sekali lagi, antarmuka pengguna yang lebih baik bisa membantu. Misalnya, alih-alih memiliki bidang masukan kosong dengan tanda persen ditambahkan padanya, orang dapat memilikinya:
[____] % of disk space (2 TB)
Ketika pengguna mulai mengetik, itu akan mengubah teks dengan cepat menjadi ini:
[5___] % of disk space (102.4 GB of 2 TB)
Representasi
Angka besar atau angka dengan floating point dapat direpresentasikan secara berbeda. Misalnya, sejumlah 1234,56 dapat ditulis seperti itu: 1,234.56
. Bergantung pada budaya, representasi teks dari nomor yang sama akan berbeda. Di Prancis, jumlah yang sama akan ditulis seperti ini: 1 234,56
. Lihat, koma di mana Anda tidak akan mengharapkan satu, dan spasi.
Selalu mengharapkan format tertentu menggunakan lokal tertentu akan membuat Anda cepat atau lambat, karena pengguna dari berbagai negara akan memiliki kebiasaan berbeda dalam menulis angka, tanggal dan waktu, dll.
Manusia vs. komputer
Twenty-four
Manusia biasa tidak berpikir dengan cara yang sama seperti komputer. "Dua puluh empat" adalah angka aktual, terlepas dari apa yang PC katakan kepada Anda.
Meskipun (1) kebanyakan sistem tidak menangani semua jenis input ini dan (2) hampir setiap pengguna tidak akan membayangkan memasukkan nomor yang ditulis dalam huruf penuh, itu tidak berarti bahwa input seperti itu konyol. Dalam Tentang Wajah 3 , Alan Cooper menunjukkan bahwa tidak menangani input tersebut merupakan indikasi ketidakmampuan komputer untuk beradaptasi dengan manusia, dan idealnya, antarmuka harus dapat menangani input tersebut dengan benar.
Satu-satunya hal yang harus saya tambahkan ke buku Alan Cooper adalah bahwa dalam banyak kasus, angka ditulis dalam digit karena kesalahan . Fakta bahwa komputer mengharapkan penggunanya melakukan kesalahan (dan tidak akan mentolerir pengguna yang menulis dengan benar) sangat menjengkelkan.
Unicode
5𝟨
Unicode menyimpan kejutannya sendiri: karakter yang bisa terlihat sama tidak sama. Tidak meyakinkan? Salin-tempel "5𝟨" === "56"
ke alat pengembang browser Anda, dan tekan Enter.
Alasan bahwa string tersebut tidak sama adalah bahwa karakter Unicode 𝟨
tidak sama dengan karakter 6
. Ini akan menciptakan situasi di mana pelanggan yang marah akan menelepon, memberi tahu bahwa aplikasi Anda tidak berfungsi, memberikan tangkapan layar dari input yang terlihat sah, dan aplikasi Anda mengklaim bahwa input tersebut tidak valid.
Mengapa ada orang yang memasukkan karakter Unicode yang mirip digit, Anda akan bertanya? Sementara saya tidak akan mengharapkan pengguna memasukkan satu secara tidak sengaja, copy-paste dari sumber yang berbeda dapat menyebabkan itu, dan saya punya kasus di mana pengguna benar-benar melakukan copy-paste dari string yang berisi karakter Unicode yang tidak akan muncul di layar.
Kesimpulan
Itu adalah kasus yang Anda dapatkan untuk bidang input angka dasar. Saya akan membiarkan Anda membayangkan apa yang bisa Anda tangani untuk formulir yang lebih kompleks, seperti kencan, atau alamat.
Jawaban saya terfokus pada apa yang Anda sebut input "konyol". Pengujian bukan tentang memeriksa jalur bahagia; ini juga tentang memeriksa bahwa aplikasi Anda tidak rusak ketika pengguna jahat dengan sengaja memasukkan hal-hal aneh, mencoba untuk memecahkannya. Ini berarti bahwa ketika Anda meminta persentase, Anda juga harus menguji apa yang terjadi ketika pengguna merespons dengan string yang berisi 1.000.000 karakter, atau angka negatif, atau tabel bobby .