UI adalah neraka: kalkulator empat fungsi

Aku punya sesuatu untuk itu sejarah kalkulator; mereka merupakan salah satu perangkat elektronik portabel yang paling awal, mereka mendorong batas-batas teknologi tampilan, dan merupakan perangkat komputasi digital pertama yang menjangkau jutaan rumah.

Saat ini, jika Anda meminta insinyur perangkat lunak yang menghargai diri sendiri untuk mengimplementasikan kalkulator yang dioperasikan dengan tombol yang sederhana namun kompatibel dengan versi sebelumnya, mereka mungkin akan memutar mata dan mengatakan bahwa mereka dapat menyelesaikannya dalam satu istirahat makan siang. Mereka akan gagal. Saya tahu karena beberapa waktu lalu, saya membangun kalkulator desain saya sendiri — dan itu merupakan perjalanan yang menyenangkan.

Mari kita mulai dengan dasar-dasarnya: kalkulator paling sederhana memiliki sepuluh tombol digit, satu titik desimal, empat operator aritmatika (+, -, ×, ), tombol hasil (“=”), dan tombol “C” untuk mengatur ulang keadaan. Ini mengeksekusi aritmatika dua operan secara berurutan, tanpa memperhatikan prioritas — misalnya:

Kita dapat dengan mudah membayangkan penerapan perilaku ini dengan tiga variabel: register input, akumulator, dan pemilih operator. Masuknya setiap digit baru menggeser isi register masukan satu tempat desimal ke kanan. Memilih operator akan memuat nilai ini ke akumulator dan memberi ruang bagi operan kedua untuk diketik. Terakhir, pengguna menekan “=”; pada saat itu, hasilnya dihitung dan nilainya dimasukkan kembali ke dalam register input, sehingga tersedia untuk operasi berikutnya:

Tapi kemudian… apa yang terjadi jika pengguna menekan ⑨ tepat setelah tanda sama dengan? Hasilnya mungkin bukan “159”. Kita memerlukan kasus khusus: jika sebuah digit atau titik desimal ditekan segera setelah beberapa input non-numerik, register input harus dihapus. Kita dapat memperbaikinya dengan tanda “input reset” tambahan:

Keuntungan tambahan dari skema yang direvisi ini adalah kita dapat menyimpan operan yang dimasukkan sebelumnya di layar lebih lama pada langkah 4, sehingga kesalahan entri data lebih mudah dikenali.

Selesai dan dibersihkan, kan?

Ya… tapi bagaimana jika pengguna memasukkan ② + ③ × ⑤ =? Dalam skema yang disebutkan di atas, kita akhirnya membuang penambahan pertama dan hanya mengeksekusi ③ × ⑤ =. Untuk mengatasi masalah ini, kita memerlukan kasus khusus lainnya: jika suatu operasi telah dipilih, kita harus menekan “=” secara implisit sebelum menjadwalkan operasi lainnya.

Dan bagaimana jika pengguna memasukkan ② × ÷ ③? Mungkin yang mereka maksud bukan 2 × 2 3! Penjelasan paling logis adalah bahwa mereka mempermainkan operator dan mencoba memperbaiki kesalahan mereka. Jadi, kita memerlukan kasus khusus lainnya: “=” implisit tersebut harus terpicu hanya jika beberapa masukan numerik terjadi di antaranya — yaitu, ketika DalamR bendera belum disetel.

Namun apakah penjelasan yang sama berlaku untuk ② × – ③? Apakah itu upaya pengurangan, atau pengguna mencoba mengalikan dengan angka negatif? Tebakan Anda sama bagusnya dengan tebakan saya, tetapi kemampuan untuk memasukkan angka negatif akan menyenangkan! Beberapa kalkulator mengatasi ambiguitas tersebut dengan memiliki tombol tanda khusus; banyak yang tidak, malah mendukung notasi sufiks unary dengan huruf khusus tepat sebelum “=”:

Operator unary adalah peretasan yang cerdas, tetapi hal ini menyebabkan lebih banyak kebingungan UX. Pertama, ini mengubah tanda seluruh ekspresi, bukan operan kedua; untuk penambahan atau pengurangan, ini menghasilkan hasil yang agak berlawanan dengan intuisi:

Beberapa pengguna mungkin mengira cara kerjanya berbeda: 10 + -2 = 8.

Masalahnya tidak berakhir di situ; berdasarkan aturan yang kita miliki sejauh ini, ② – × ② = diperlakukan sebagai koreksi operator, bukan perubahan tanda — sehingga menghasilkan 4, bukan -4. Apakah itu yang diinginkan pengguna? Ada peluang lima puluh lima puluh.

Pertimbangkan juga apa yang terjadi jika pengguna memasukkan ② +, melihat operan terakhir (“2”) masih ditampilkan di layar, dan menekan “=”:

Orang yang berakal sehat akan berasumsi bahwa mereka menambahkan 2 dan 2. Namun bukan itu yang terjadi di sini. Apakah kita membuat segalanya menjadi lebih baik atau lebih buruk?…

Jika Anda pernah bermain-main dengan kalkulator lama, Anda mungkin memperhatikan “fitur” yang memungkinkan Anda mengulang operasi terakhir selamanya dengan menekan “=” berulang kali:

Mekanismenya lucu tetapi tidak berguna, kecuali untuk eksponensial manual. Namun ada lebih dari itu: ini sebenarnya adalah efek samping dari fitur “K-constant” yang kurang dikenal yang mempertahankan salah satu operan dan operator yang dimasukkan sebelumnya, dan memungkinkan Anda memvariasikan operan lainnya. Hal ini dimaksudkan untuk menghitung bunga atau biaya tambahan, misalnya:

Di baris pertama, kami menentukan biaya tambahan konstan (“10”) dan memilih operasi (“+”). Sejak saat itu, kita bisa terus memasukkan operan kedua dan menekan “go”. Bagus, ya? Namun ini berarti algoritma awal kita salah lagi: akumulator dan pemilih operator tidak dapat dihapus setelah “=”.

Dalam skema ini, operan kedua digunakan sebagai elemen konstan saat melakukan pembagian, penjumlahan, dan pengurangan; tetapi karena alasan historis, perkalian dilakukan dengan aturan yang berbeda:

Dan ini… memiliki konsekuensi yang cukup lucu jika Anda hanya menekan tombol “=” dan mengharapkan UX yang konsisten:

Oh, dan hei – ingat notasi “akhiran unary” untuk perubahan tanda? Di banyak kalkulator, terdapat kasus khusus lain untuk operator pembagian (tetapi tidak untuk perkalian). Hasilnya adalah permata kegunaan keseluruhan ini:

Operator pembagian unary memberi Anda timbal balik. Ini juga memungkinkan Anda membalik urutan pembagian normal, seperti:

Ingatlah bahwa antarmuka pengguna ini, dengan segala keunikan dan keunikannya, adalah hasil dari evolusi produk dan riset pasar selama beberapa dekade. Beberapa kalkulator awal dari tahun 1960an dan 1970an memiliki skema masukan yang lebih membingungkan. Lihat apakah Anda dapat memahami salah satu permata dalam koleksi saya — Sharp EL-8: