Permintaan, konfirmasi, dan peringatan JavaScript dianggap "kuno" [ditutup]


21

Akhir-akhir ini saya telah mengembangkan sistem manajemen berbasis web untuk gym. Aplikasi mereka sebelumnya dikembangkan dalam Visual Basic. Untuk aplikasi baru, semua skrip front-end menggunakan jQuery, server menjalankan PHP & MySQL ... Anda tahu, stack khas el-cheapo berbasis linux.

Ngomong-ngomong, saya bertanya-tanya mengapa dialog pesan, konfirmasi, dan peringatan JavaScript sangat jarang digunakan saat ini. Ada banyak plugin jQuery untuk modal windows dan pesan peringatan yang mencoba meniru sesuatu yang sudah ditawarkan bahasa dan setiap browser dipaksa untuk mendukung dengan benar.

Menggunakan solusi buatan tangan atau berbasis plugin boleh digunakan untuk formulir kompleks dan kebutuhan khusus, tetapi jika Anda hanya perlu meminta satu nilai atau mengonfirmasi penghapusan catatan, mengapa Anda menambahkan overhead seperti itu ke aplikasi web Anda? Selain itu, iOS dan Android menawarkan dialog pesan yang disesuaikan dengan baik ketika Anda menggunakan prompt, konfirmasi dan peringatan.


7
"El murahan?" Sangat? Bukankah itu sedikit merendahkan?
asthasr

1
Saya bingung; pertama Anda mengatakan aplikasi dikembangkan dalam Visual Basic, lalu Anda mengatakan server menjalankan PHP. Hah?
jhocking

@jhocking: sepertinya dia mengatakan sistem lama adalah aplikasi desktop yang ditulis dalam VB, dan yang baru (yang dia tulis) ditulis dengan tumpukan LAMP.
Jordan

Kedengarannya seperti aplikasi mereka sebelumnya ditulis dalam vb, saat ini dia membuat web front end untuk itu.
GrandmasterB

Jawaban:


56

1. UX: kotak pesan sebagian besar jahat

Kotak peringatan buruk dalam semua kasus dari sudut pandang UX. Di aplikasi desktop. Dalam aplikasi web sebagai peringatan atau pesan JavaScript inline. Dimana mana.

Anda dapat membaca Tentang Wajah 3 oleh Alan Cooper¹ jika Anda ingin tahu mengapa; ini menjelaskan dengan sangat baik bagaimana ini mengganggu alur kerja dan mengganggu pengguna, dan bagaimana hampir setiap kotak peringatan yang ada dalam perangkat lunak saat ini sangat salah . Pada halaman 542, "Dialog yang menyerukan" Serigala! "" Menjelaskan bahwa kotak peringatan diberhentikan secara rutin, sehingga model mereka benar-benar rusak. Pada halaman 543 buku ini tercantum tiga prinsip desain utama:

  • Jangan, jangan tanya.
  • Jadikan semua tindakan reversibel.
  • Berikan umpan balik modeless untuk membantu pengguna menghindari kesalahan.

Kemudian, penulis memberi tahu kami cara mengganti kotak peringatan dengan pendekatan desain yang benar.

Pesan yang cepat sedikit berbeda. Dan masih, mereka merusak pengalaman pengguna aplikasi Anda. Jika Anda ingin pengguna memasukkan sesuatu, pertimbangkan untuk menggunakan kotak teks atau textarea, dekorasinya dengan JavaScript saat dibutuhkan. Jangan malas, berikan antarmuka yang kaya di era aplikasi yang mendukung RIA dan AJAX ; dalam semua kasus, jika JavaScript dinonaktifkan, prompt Anda tidak akan ditampilkan.

Di halaman web, baik kotak peringatan maupun konfirmasi sebagian besar menyebalkan. Beberapa contoh:

  1. Beberapa forum memungkinkan Anda membuat daftar dengan meminta item daftar tanpa batas. Ini berarti bahwa saat membuat daftar, Anda tidak dapat menggunakan halaman itu sendiri, termasuk salin-tempel. Anda juga memiliki satu bidang kecil. Bagaimana dengan teks panjang? Bagaimana dengan huruf tebal dan miring?

  2. "Jika Anda melanjutkan, foto akan dihapus secara definitif dari profil Anda. Apakah Anda yakin?" . Tentu saja saya yakin! Apakah saya akan mengklik "Hapus foto dari profil saya" jika tidak? Mengapa aplikasi web Anda seandainya saya begitu bodoh? Sebenarnya, aplikasi Google sebagai GMail menunjukkan pendekatan yang benar. Anda dapat menghapus, menghapus, menghancurkan apa pun yang Anda inginkan, dan ketika Anda melakukannya, aplikasi menampilkan tautan kecil "Undo".

  3. "Apakah kamu ingin mengambil survei terbesar kami?" . Sebenarnya saya ada di sana untuk mengunjungi situs web Anda, tetapi karena Anda mengganggu saya dengan pesan-pesan Anda yang menyebalkan, saya lebih suka pergi ke tempat lain.

  4. "Klik kanan dinonaktifkan di situs web ini untuk melindungi foto yang dilindungi hak cipta" . Ya, sebenarnya saya mengklik kanan untuk mengubah bahasa pemeriksa ejaan sebelum mengirim komentar saya. Tentu, saya akan mengirimnya tanpa memeriksa ejaannya.

Kesimpulan: dari sudut pandang pengalaman pengguna, sebagian besar aplikasi menggunakan kotak pesan secara salah.

Tapi tunggu! Banyak situs web berkualitas rendah menggantikan kotak peringatan yang mengganggu dengan mengganggu pesan JQuery dengan latar belakang semi-transparan yang mencakup semua halaman. Jadi kekurangannya tetap ada.

Nah, ada alasan lain untuk tidak menggunakan kotak pesan di aplikasi web:

2. Desain: kotak peringatan memiliki desain sendiri

Anda tidak dapat merancang kotak peringatan sama sekali. Anda tidak dapat mengubah warna, ukuran, dan fontnya. Ini membuatnya semakin menjengkelkan bagi pengguna: Anda bekerja dengan aplikasi web, dan alur kerja Anda dipecah oleh pesan yang tampaknya datang entah dari mana dan bahkan tidak cocok dengan aspek visual dari aplikasi tersebut. Tidak termasuk bahasa tombol juga cocok dengan bahasa OS / browser, bukan bahasa aplikasi web.

Untuk desainer, pesan JavaScript jauh lebih kuat daripada kotak peringatan.

Mereka juga jauh lebih luas. Anda dapat menambahkan huruf tebal dan miring, Anda dapat memilih tombol Anda sendiri (bagaimana dengan: "Kami meminta maaf tetapi kata sandi yang Anda masukkan tidak valid. [Atur ulang kata sandi saya] [Coba yang lain] [Batal]"?) ².

3. JavaScript: aliran aplikasi berhenti

Saat menampilkan kotak peringatan, JavaScript berhenti dijalankan hingga pengguna mengklik. Di situs web, mungkin baik-baik saja. Dengan aplikasi web, seringkali menjadi masalah.

4. Sandbox: jangan memaksa pengguna untuk mem-boot ulang komputernya

Ingat situs web jelek yang menunjukkan jumlah kotak pesan yang tak terbatas ? Satu-satunya cara bagi pengguna tanpa latar belakang teknis yang cukup untuk dapat terus bekerja sebenarnya adalah dengan me-reboot komputer mereka. Ini membawa kita ke masalah: kotak peringatan berada di luar cakupan situs web atau aplikasi web. Anda tidak berwenang untuk mencegah pengguna mengakses tab lain dari browser³.

Masalah yang sama memaksa browser untuk menyelesaikannya dengan berbagai cara. Firefox, misalnya, mengizinkan akses ke tab lain saat menampilkan peringatan di tab Anda. Chrome, di sisi lain, memungkinkan Anda untuk memeriksa bahwa Anda tidak ingin lagi mendapatkan kotak peringatan dari halaman, tetapi masih memblokir akses ke tab lain.

Tangkapan layar memperlihatkan kotak peringatan dengan kotak centang "Cegah halaman ini membuat dialog tambahan"

Meskipun pendekatan Firefox benar-benar valid, pendekatan Chrome dapat dikritik (karena masih memblokir setiap tab), dan menyebabkan masalah: bagaimana jika pengguna sangat terganggu oleh beberapa kotak pesan yang dikeluarkan oleh aplikasi Anda dan memeriksa kasusnya, lalu, Anda mencoba menunjukkan sesuatu yang sangat penting? Benar, pengguna tidak akan pernah melihatnya.

Faktanya tetap sama, sebagian besar pengguna akan terganggu oleh kotak peringatan, sehingga mereka masih tidak terlalu ramah pengguna, dan mungkin sangat memblokir pengguna tanpa latar belakang teknis yang cukup. Inline, pesan JavaScript dapat memblokir halaman, tetapi bukan browser itu sendiri. Karena model aplikasi web adalah semacam sandboxing, di mana Anda tidak dapat misalnya mengakses keyboard pengguna atau me-reboot komputer atau membaca file dari hard disk atau layar penuh atau menggunakan dua monitor, kotak peringatan dengan efek pemblokirannya rusak parah. model sandboxing .

Last but not least, bagaimana jika pengguna berada di tab lain ketika aplikasi Anda memutuskan untuk menampilkan kotak peringatan? Bagaimana jika pengguna melakukan sesuatu yang penting, dan tidak ingin berinteraksi dengan aplikasi Anda saat ini?


¹ Tentang Wajah 3, Esensi Desain Interaksi , Alan Cooper, Robert Reimann dan David Cronin, ISBN 978-0-470-08411-3; Bab 25: Kesalahan, Peringatan, dan Konfirmasi.

² Ini hanyalah sebuah contoh. Tolong, jangan lakukan itu di aplikasi web Anda, karena itu benar-benar pilihan desain yang buruk.

³ Jika Anda ingin perbandingan dengan dunia aplikasi desktop, pesan JavaScript inline seperti kotak pesan aplikasi desktop. Kotak peringatan di browser, di sisi lain, seperti jendela yang muncul entah dari mana, ditetapkan sebagai yang teratas, pada latar belakang buram layar penuh yang menghalangi Anda mengakses aplikasi desktop lainnya. Aplikasi apa pun yang akan memutuskan untuk melakukannya sekali di komputer saya akan segera dihapus, dan selamanya.


1
Pertanyaannya tidak ada hubungannya dengan munculan tak terbatas atau spam, jadi mengapa Anda menyebutkannya di sini? Dan saya tidak berpikir itu hal buruk yang seharusnya muncul pop up JS. Ketika digunakan dengan benar (untuk mengingatkan pengguna pada sesuatu yang UTAMA) mereka memaksa pengguna untuk mengatasinya sebelum melakukan hal lain, yang kadang-kadang seperti yang Anda inginkan.
Graham

Ini tidak menjawab pertanyaan.
CaffGeek

1
"Saat menampilkan kotak peringatan, JavaScript berhenti dijalankan hingga pengguna mengklik" - ini berlaku untuk a confirm()dan prompt(); dengan alert(), perilaku tergantung pada browser (eksekusi dapat berlanjut bahkan ketika peringatan () ditampilkan - alasannya adalah "hanya ada satu jalan keluar").
Piskvor

1
@ Graham: Anda tepat untuk sembulan yang tak terbatas; Saya di luar topik pada titik ini. Saya mencoba memformulasikan ini dengan lebih baik. Sedangkan untuk mengingatkan sesuatu yang utama, lihat poin keempat dari jawaban saya: ya, Anda mungkin ingin menghentikan semuanya sebelum pengguna mengonfirmasi tindakan, tetapi itu tidak memungkinkan Anda untuk memblokir setiap tab browser, karena tab lain tidak milik aplikasi web Anda.
Arseni Mourzenko

1
@BornToCode: tidak ada alternatif. Segera setelah Anda menunjukkan foto di layar pengguna, tidak ada cara untuk melindungi mereka agar tidak disalin. Adapun pertanyaan kedua Anda, Anda harus lebih spesifik. Coba ux.se .
Arseni Mourzenko

3

Intinya: Kotak dialog prompt, konfirmasi, dan peringatan cocok dengan gaya browser Anda, bukan gaya situs Anda. Kebanyakan orang UI ingin semua kotak dialog mengalir dengan UI situs mereka. Mereka menggunakan modal windows untuk menyajikan pesan dan mengumpulkan data menggunakan font dan warna yang sama dengan UI situs, bukan abu-abu dan biru default MSIE atau FF.


2

Anda hanya menambahkan overhead jika Anda tidak memerlukan dialog mewah di tempat lain, yang mungkin Anda lakukan. Pada titik itu, tidak ada banyak perbedaan apakah fungsi tersebut dimasukkan sebagai bagian dari browser atau sebagai bagian dari kerangka kerja yang Anda gunakan, dan Anda juga dapat membuat semua popup Anda terlihat konsisten.

Meskipun Anda dapat melakukan banyak hal dengan javascript dan tanpa kerangka kerja, saya ingat bagaimana rasanya berkembang dalam javascript sebelum kerangka kerja tersedia, dan saya tidak ingin kembali ke sana.


1

Karena browser tidak menanganinya dengan baik . Seperti yang mungkin telah Anda perhatikan, mereka biasanya merupakan dialog modal dan tidak hanya mencegah pengguna memindahkan dan mengubah ukuran browser mereka, tetapi juga mencegah tab lain diakses, yang sangat mengganggu.

Untuk dialog seperti konfirmasi dan ubah, saya masih berpikir browser harus memberlakukan perilaku, dan untuk browser Firefox terbaru Anda dapat melihat mereka telah memperbaiki masalah yang saya sebutkan di atas. Mereka digunakan dalam peringatan halaman yang mencakup halaman ini.

Karena itu saya sarankan Anda mengganti perilaku waspada sehingga semua browser dapat menangani (setidaknya peringatan) dengan lebih elegan.

Beberapa alasan yang dirangkum:

  • Ini adalah API standar dan pengembang dapat mengetahui apa yang Anda coba lakukan.
  • Ini lebih ramah pengguna, dan terlihat lebih baik.
  • Dukungan platform, situs seluler mungkin memerlukan API asli.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.