it-swarm.asia

Mengapa orang menggunakan "masukkan nama proyek untuk mengonfirmasi"?

Jika Anda adalah pengguna GitHub lama, Anda mungkin telah melihat sesuatu seperti ini:

Ini terjadi setiap kali Anda melakukan hal yang berpotensi merusak ke repositori, seperti mengalihkan status publik/privat atau mengarsipkan/menghapusnya.

Prompt muncul dalam modal setelah mengklik tombol tindakan, jadi ini adalah tindakan ekstra untuk mencegah tindakan tidak disengaja.

Tetapi sejauh yang saya ketahui, ini tidak efektif dalam "menetapkan penghalang lain" atau terlalu rumit sebagai "konfirmasi tambahan". Seseorang dapat dengan mudah menyalin nama repositori dari URL atau tepat di atas kotak input (teks tebal di atas), tetapi ini masih lebih kompleks daripada hanya mengklik tombol tambahan.

Menurut saya, modal ekstra dengan warna merah terang button yang tidak menanggapi tindakan keyboard (seperti tombol Enter) akan cukup. Seseorang harus memindahkan mouse mereka ke tombol merah terang untuk mengkliknya untuk lapisan ekstra hati-hati. Ini kurang rumit dan ketidakmampuan untuk cukup menekan tombol Enter sederhana dan efektif.

Adakah yang bisa menjelaskan bagaimana ini "masukkan nama proyek" adalah desain UI yang baik?

48
iBug

Ini tidak selalu tentang "desain UI yang baik", tetapi lebih banyak tentang mengambil semua tindakan untuk mencegah penghapusan tidak disengaja dan memastikan bahwa pengguna sepenuhnya menyadari apa yang mereka hapus .

Entri blog ini menangkapnya dengan cukup baik:

Alih-alih memberi pengguna tombol konfirmasi yang bisa mereka tekan secara keliru, beri mereka bidang teks dan minta mereka mengetikkan kata "hapus" untuk mengonfirmasi. Ketika pengguna mengetik "hapus" di bidang teks, tidak ada keraguan bahwa mereka ingin menghapus. Tidak ada penekanan yang tidak disengaja dari tombol hapus. Tidak ada penyesalan ketika pengguna menghapus, karena bidang teks konfirmasi membuat mereka yakin tentang apa yang akan mereka lakukan sebelum mereka melakukannya.
Cara Memastikan Pengguna Tidak Menghapus Secara Tidak Disengaja - Gerakan UX

Tentu, menekan tombol lebih mudah, tetapi itu selalu meninggalkan peluang bahwa Anda salah membaca nama dan menghapus item yang salah.
Ketika Anda harus mengetikkan nama (atau bahkan menyalinnya), Anda dapat yakin 99% bahwa pengguna tidak akan melakukan itu secara salah. Mereka akan menyadarinya paling lambat ketika menyoroti nama untuk copy-paste.

Selain itu, ini biasanya hanya digunakan untuk operasi penghapusan yang sangat kritis. Ini sangat jarang terjadi, jadi argumen tentang membuatnya lebih mudah atau kurang menyebalkan tidak benar-benar berlaku.


Berikut beberapa pertanyaan terkait:

168
Big_Chair

Hanya untuk memperjelas "UI" desain UI tidak berarti memberikan pengguna apa yang mereka inginkan. Ini sering berarti membantu pengguna untuk menjadi versi yang lebih baik dari diri mereka sendiri.

Selain apa yang telah disebutkan, pola ini (dan beberapa yang seperti itu) memungkinkan UI untuk mengurangi kecepatan. Secara umum muscle memory -> speed -> mistakes -> sad path.

Bayangkan Anda melakukan pekerjaan di bidang kesehatan. Jika pengguna membangun terlalu banyak "aliran" dalam tugas-tugas umum, mereka berpotensi membuat kesalahan sederhana yang membunuh seseorang. Sementara kontra intuitif, sering kali baik untuk menarik pengguna keluar dari aliran mereka dengan memerlukan interaksi (lebih dari dialog konfirmasi sederhana yang selalu muncul di tempat yang sama dan dapat ditambahkan ke memori otot).

Mengetik teks hanyalah salah satu contohnya. Saya juga pernah melihat:

  1. menambahkan batas waktu ke tombol sebelum tersedia.
  2. Mengacak penempatan tombol kelanjutan proses.
  3. Menambahkan kunci (mis. Jalankan proses sebagai administrator dengan kata sandi)

Semua pola ini dimaksudkan untuk cukup mengganggu pengguna sehingga mereka berhenti untuk menilai proses mental sebelum melanjutkan.

51
Bryce Howitson

Ini untuk memastikan bahwa:

  1. Anda memahami bahaya dari apa yang Anda lakukan.
  2. Yang terpenting, bahwa Anda benar-benar menghapus repo yang tepat.

Jika seorang pengguna memiliki banyak repo dengan nama yang panjang, mudah untuk membuatnya tercampur. Mengetik namanya adalah cara yang baik untuk memastikan Anda tidak mengabaikan yang salah, yang akan sangat buruk.

15
frodo2975

Saya memetakan ulang tombol keyboard yang tidak digunakan (melalui AutoHotKey) untuk penggunaan berselang-seling sebagai klik kiri mouse untuk mengurangi ketegangan akibat terlalu banyak menggunakan pergelangan mouse saya, dan kadang-kadang (jarang) menekan tombol itu di tempat yang salah ketika melakukan banyak tugas. Saya juga sesekali menabrak mouse itu sendiri dan tanpa sengaja mengklik tombol pada dialog.

Walaupun "jangan buat saya berpikir" adalah aturan yang sangat baik, masuk akal untuk membantu pengguna fokus pada apa yang sebenarnya akan dilakukan dengan mengeksekusi perintah destruktif. Saya bahkan akan mempertimbangkan untuk meminta pengguna mengetik kalimat lengkap dari formulir, "Silakan hapus repositori iBug/example-repositori, termasuk wiki, masalah, dan komentar" kata demi kata untuk memperjelas maksud pengguna untuk diri sendiri = dalam situasi itu, karena pengguna hanya akan melakukannya sekali pada repositori itu.

Siapa pun yang benar-benar menulis kode harus mengetik baris teks yang lengkap, jelas, dan dieja dengan benar dengan sangat sering, sehingga satu baris lagi untuk mengonfirmasi tindakan paling merusak yang dapat Anda lakukan pada suatu proyek bukan tidak masuk akal.

9
user117529

Menurut pendapat saya, modal tambahan dengan tombol merah terang yang tidak merespons tindakan keyboard (seperti tombol Enter) akan cukup. Seseorang harus memindahkan mouse mereka ke tombol merah terang untuk mengkliknya untuk lapisan ekstra kehati-hatian. Ini kurang rumit dan ketidakmampuan untuk cukup menekan tombol Enter sederhana dan efektif.

(penekanan ditambahkan)

Apakah Anda tentu bahwa mereka harus "memindahkan mouse mereka"? Setiap saat? Bahkan jika mereka menggunakan perangkat dengan resolusi berbeda, di mana mungkin hal-hal tidak sesuai seperti yang diharapkan? Atau jika mereka diperbesar? Bagaimana dengan input sentuh? Bagaimana dengan orang yang tidak menggunakan mouse (karena perbedaan kemampuan/dll)? Sekarang Anda harus memastikan keyboard merespons dengan cara yang tidak merusak aksesibilitas, tetapi tidak memungkinkan penghapusan yang tidak disengaja.

Sementara ada argumen yang menentang tanpa pandang bulu mengikuti praktik terbaik cukup karena mereka menjadi praktik terbaik (versus mengembangkan pemahaman mengapa mereka ada di tempat) atau setidaknya " apa yang dilakukan orang lain ", terutama ketika mereka tidak selalu benar-benar hebat, saya ingin menunjukkan bahwa biasanya mereka telah menjadi praktik terbaik karena ada masalah tak terduga yang akan muncul , dan mencoba melawan mereka hanya karena Anda tidak mengerti maksud mereka biasanya adalah ide yang buruk. Ketika melihat sesuatu yang merupakan praktik terbaik yang tersebar luas/diadopsi secara luas, mulailah dari anggapan bahwa praktik itu bermakna dan signifikan dan kemungkinan memiliki alasan kuat yang kuat yang telah berkembang dari waktu ke waktu (dan kemungkinan di antara lebih banyak orang daripada hanya satu, dan tentunya telah Ulasan oleh lebih dari satu orang) daripada Anda sendiri mungkin telah dikhususkan untuk masalah yang sama (dan hanya dengan perspektif Anda sendiri membimbing Anda). Belum lagi masalah konsistensi global.

@ jawaban BigChair bersama @ jawaban Bryce Howitson keduanya Gali mengapa ini adalah praktik terbaik untuk tindakan yang tidak dapat dipulihkan secara umum. Dalam desain UI, penting untuk menciptakan gesekan untuk tindakan kritis yang tidak dapat dipulihkan, dan keduanya membahas topik dengan cukup baik untuk konteks ini.

Jika memungkinkan , saya akan menyarankan untuk mengambil jalur yang berbeda dalam hal apa pun yang memungkinkan untuk diterapkan:

Hindari membiarkan tindakan tidak dapat dipulihkan sejak awal

Dengan itu, cara terbaik untuk bergerak maju adalah tidak memiliki tindakan pengguna menghasilkan keadaan perangkat lunak yang tidak dapat dipulihkan di tempat pertama. Ingat, apa yang diungkapkan oleh UI kepada orang yang menggunakan perangkat lunak tidak harus cocok dengan apa yang perangkat lunak lakukan dengan keadaannya secara internal, dalam semantik terkait 1: 1. Tidak masalah bagaimana sesuatu diwakili oleh orang yang menggunakannya untuk tidak cocok dengan implementasi teknis dari apa yang terjadi ketika mereka mengaktifkan tindakan terkait.

Jangan menghapus hal-hal dalam representasi perangkat lunak Anda berdasarkan pada input pengguna saja. Tandai mereka dihapus di representasi penyimpanan Anda dan berikan cara untuk mengambilnya (tempat sampah/etc). Jangan izinkan penciptaan situasi di mana seseorang yang menggunakan produk Anda dapat kembali ke sudut yang tidak dapat dihindarinya. Tidak hanya lebih baik UX untuk menghindari keharusan jenis konfirmasi ini di mana pun dimungkinkan untuk dilakukan, tetapi juga mengurangi persyaratan dukungan dan tingkat friksi terkait dalam masalah dukungan terkait (yang juga merupakan aspek UX). Ketika seseorang "menghapus" sesuatu, buat sangat jelas bahwa mereka juga akan dapat mengembalikan tindakan yang telah mereka ambil saat terlibat dalam aksi dan sesudahnya (sehingga jika mereka miliki secara tidak sengaja "menghapus" sesuatu tanpa membaca layar hingga dan termasuk mengambil tindakan, mereka sekarang dapat melihat ke mana harus membatalkannya).

9
taswyn

Saya sudah membuat apa yang saya sebut kesalahan tidak disengaja:

  • tanganku bergeser saat aku menekan tombol (ingin "Cancel", mendapat "OK"). Atau: iklan muncul dan menggeser halaman.
  • instruksi itu sangat membingungkan sehingga saya menekan tombol yang salah (tentu saja bukan yang kurang merusak)
  • Aku "oh tidak, tidak, tidak" dan dengan panik menekan tombol yang salah
  • Saya mungkin atau mungkin tidak Juan Pablo Davila

Inilah mengapa saya benar-benar lebih suka untuk memiliki dalam kasus seperti itu suatu proses yang membuat saya bertindak berbeda dari apa yang disarankan oleh memori otot.

5
WoJ

Apa yang Github coba lakukan di sini adalah menghindari kesalahan pengguna, tetapi secara khusus "tergelincir" sebagaimana Don Norman merujuk mereka dalam Desain hal-hal sehari-hari.

Slip terjadi ketika pengguna bermaksud melakukan satu tindakan, tetapi akhirnya melakukan tindakan lain (sering serupa). Misalnya, mengetik "i" dan bukannya "o" dianggap sebagai slip; secara tidak sengaja menaruh sabun tangan cair pada sikat gigi seseorang sebagai ganti pasta gigi juga merupakan kesalahan. Slip biasanya dibuat ketika pengguna menggunakan autopilot, dan ketika mereka tidak sepenuhnya mencurahkan sumber daya perhatian mereka untuk tugas yang sedang dikerjakan.

Saya menekankan bagian terakhir dari kutipan sebagai hal yang sangat relevan.

Artikel berikut dari nngroup membahas tentang cara mencegah slip

kesalahan tipe slip sering kali dibuat oleh pengguna ahli yang sangat akrab dengan proses yang ada; tidak seperti pengguna baru yang masih belajar cara menggunakan sistem

https://www.nngroup.com/articles/slips/

Mempertimbangkan tipe orang yang akan menggunakan Github, Anda akan menganggap mereka sangat tinggi pada sesuatu seperti GDS Digital Inclusion Scale yang akan menyiratkan bahwa mereka adalah pengguna ahli yang lebih mungkin membuat slip.

Lalu satukan keduanya dan berempati dengan pengguna Github yang sudah ratusan jam mengerjakan proyek, tetapi lelah, lupa proyek mana yang mereka tempati, dan tergelincir untuk menekan delete ketika mereka tidak bermaksud demikian. Bagaimana perasaan mereka?

Banyak pengguna Github memiliki repositori dalam jumlah besar dan pada halaman hapus tidak ada banyak hal yang harus dibedakan jika Anda tidak memperhatikan, mungkin Anda bermaksud menghapus repo "rancangan proyek juta pound", tetapi Anda berada di "Proyek juta pound".

Inilah yang mereka lakukan dan saya akan menganggapnya desain UI yang efektif untuk itu. Menempatkan kendala bermanfaat di jalan operasi yang tidak dapat dipulihkan adalah praktik yang baik.

3
dougajmcdonald