Kesalahan apa yang dilakukan pengguna Anda, dan bagaimana Anda dapat memperbarui aplikasi Anda untuk menanganinya? [Tutup]


12

Sebenarnya pertanyaan ini adalah tentang peringatan yang harus diambil untuk meningkatkan pengalaman pengguna yang berkualitas dan mengurangi panggilan dukungan yang dapat dihindari.


2
Pertimbangkan judul ini: "Kesalahan apa yang dilakukan pengguna Anda, dan bagaimana Anda dapat memperbarui aplikasi Anda untuk menanganinya?"
Peter Boughton

Jawaban:


25

Kurangnya validasi input yang tepat adalah salah satu hal yang cenderung mengarah cukup cepat kepada pengguna melakukan hal-hal "buruk" dengan aplikasi Anda, ketika itu harus benar-benar ditangani oleh programmer.

Saya telah melihat aplikasi lawas tempat pengguna dilatih untuk:

  • tidak memasukkan apostrof dalam nama
  • tidak memasukkan simbol apa pun selain a-z0-9,
  • pastikan tidak ada spasi sebelum atau setelah teks yang dimasukkan
  • periksa apakah alamat email yang diformat dengan benar dimasukkan ke dalam emailbidang, jika tidak, surat berikutnya kepada pengguna tersebut akan menggunakan apa pun yang ada di lapangan dan akan gagal
  • pastikan " http://" diletakkan di depan alamat web

dll

Semua masalah di atas adalah masalah yang harus ditangani oleh pengembang aplikasi. Saat validasi input Anda pada dasarnya "pastikan pengguna tahu format apa bidang ini harus dan percaya apa yang mereka masukkan benar", maka hal-hal tak terduga pasti akan menemukan jalan masuk ke aplikasi. Selain implikasi keamanan yang jelas, pengguna membuat kesalahan. Sebagai programmer, kita sering menghasilkan produk terbaik dengan membungkuk ke belakang untuk memastikan bahwa pengguna tidak dapat salah, tidak peduli seberapa keras mereka mencoba!


Ini sering diabaikan ... Saya tidak percaya kita masih mengalami masalah ini hari ini! @
mpeterson

2
+1 karena saya pernah melihatnya. TETAPI: "alamat email yang diformat dengan benar" terkenal sulit untuk memvalidasi fightforalostcause.net/misc/2006/compare-email-regex.php pastikan Anda tahu apa yang Anda lakukan. Jika Anda hanya berurusan dengan himpunan bagian dari email yang digunakan perusahaan Anda secara internal, itu akan baik-baik saja, jika tidak, ada lebih banyak kerumitan daripada yang diperkirakan kebanyakan. Kisah yang sama untuk http://titik validasi. Sebagai contoh, ASDFlakukan ini dengan cara yang naif, dan hasilnya adalah Anda tidak dapat meng-host paket pada domain yang digunakan https://.
Inaimathi

Itu tidak berhasil ... itu tidak menerima email dengan bang paths (ya saya tahu siapa yang peduli, tetapi masih, memvalidasi email ke RFC IS sulit.)
Spudd86

7

Saya pernah mendapat panggilan dukungan pelanggan karena aplikasi saya hilang begitu saja. Ternyata mereka membuka aplikasi lain di atasnya.

... Saya memutuskan untuk tidak memastikan hal itu tidak terjadi lagi, karena pengguna komputer buta huruf yang menyebabkan masalah, bukan aplikasi. Apa pun yang bisa saya lakukan untuk memperbaikinya akan menyebabkan pengalaman pengguna yang buruk bagi orang lain.


1
Silakan teruskan posting ini ke semua pengembang yang menerapkan fungsionalitas "tetap di atas" di aplikasi mereka. Bahkan jika CEO yang memintanya, kita harus memiliki hak untuk mengatakan "tidak".

7

Hampir setiap program yang saya tulis dipanggil secara ketat dari baris perintah. Saya juga menulis beberapa hal yang lebih bagus yang dimulai sebagai antarmuka CLI dan dengan cepat tumbuh menjadi sesuatu yang lebih seperti shell daripada apa pun.

Jadi, saya bisa berbicara hanya untuk apa yang saya tahu. Berikut adalah beberapa masalah umum dengan program-program baris perintah:

Terlalu banyak pilihan

Kecuali Anda menulis kompiler atau editor baris, cobalah untuk menjaga opsi terbatas pada satu layar penuh pada penyangga bingkai 80x25 ketika --helpatau /?dilewati. Tidak apa-apa untuk memiliki lebih banyak opsi dari itu, tetapi pilah ke dalam beberapa kategori. Contohnya

foo --help

foo --help option_name

Tidak ada opsi panjang

Jauh lebih mudah diingat foo --attach_to [argument] --volatile --verbosedaripada diingat foo -a [arg] -v +V. Ini tidak selalu mungkin, tetapi dalam kebanyakan kasus, memang demikian.

Tidak ada validasi input

Hampir setiap platform memiliki banyak pustaka yang dicoba, diuji, dan benar dalam hal mem-parsing dan memvalidasi argumen. Hampir setiap platform memiliki lexer yang telah dicoba, diuji, dan benar yang memvalidasi input dari CLI. Gunakan satu, yang lain atau keduanya. Jika program Anda segfault atau membaginya dengan nol karena sesuatu yang disediakan pengguna, itu hanya memalukan.

Anda mungkin tidak memerlukan sesuatu yang rumit seperti lexer, mungkin Anda bisa hanya tokenize string jika Anda mengharapkan barang-barang dalam urutan tertentu dengan hal-hal tertentu di tempat-tempat tertentu.

Saya benar-benar mendapat laporan bug di mana bilangan bulat diharapkan dan seseorang mengetikkan f*** my lifetanda kutip. Saya tidak menulis program itu, saya tidak beruntung mewarisinya.

Tidak ada kenop 'verbocity'

Izinkan pengguna berpengalaman untuk dengan mudah menemukan cara mengeluarkan lebih banyak suara dari program Anda daripada yang ditoleransi kebanyakan orang, tetapi default untuk mencetak hal-hal yang serius dan penting saja. Saya tidak dapat memberi tahu Anda berapa kali saya harus menjalankan stracehanya untuk menyadari bahwa ada sesuatu yang gagal karena beroperasi pada aliran file NULL.

Anda juga dapat membungkus pernyataan sehingga mematikannya melalui NDEBUG atau cara lain masih menghasilkan sesuatu yang dicetak atau dicatat untuk ditemukan oleh pengguna.

Berbicara tentang file log, cobalah untuk memastikan apa pun yang Anda tempatkan di dalamnya masuk akal (setidaknya sedikit) kepada orang lain selain Anda. Jika awal setiap entri adalah tanggal UNIX zaman, Anda akan menambah frustrasi pada seseorang yang benar-benar ingin membantu Anda mereproduksi bug.

Tidak ada 'bug buddy' dalam mode debug

Banyak program menawarkan semacam tombol 'debug' yang menawarkan obrolan tambahan tentang apa yang sedang terjadi dengan program ini, tetapi sangat sedikit yang menawarkan hal-hal berikut:

  • Cara untuk secara otomatis mengirim laporan melalui HTTP / HTTPS dan mendapatkan semacam nomor referensi layanan
  • Cara untuk membuang informasi berguna ke file yang dapat dikirim sebagai lampiran permintaan dukungan

Atau, mungkin Anda suka mendengar orang membaca berikut ini melalui telepon:

Dikatakan kondisi yang tidak terduga pada nol eff oh empat nol oh .... OK aku baca itu kembali padamu ...

File konfigurasi yang terlalu rumit

Jangan membenarkan perlunya mengurai konfigurasi sebagai alasan untuk mendapatkan buzz tentang banyak gula sintaksis. Cobalah untuk menggunakan format yang orang benar-benar tahu, bahkan jika itu berarti pekerjaan tambahan saat parsing. Saya mencoba menggunakan format gaya INI sedapat mungkin. Anda akan kagum dengan apa yang dapat Anda lakukan dengan kamus kunci-> nilai sederhana.

Tidak ada file konfigurasi

Jangan membuat orang menulis skrip shell atau file batch hanya untuk menggunakan program Anda, kecuali jika itu dimaksudkan sebagai alat untuk salah satu tugas. Beri saya cara untuk menunjuk pada file yang berisi opsi biasa saya dan berikan hanya beberapa argumen tambahan.

Tidak ada tanda-tanda 'lantai basah'

Jika beberapa fitur dapat membuat pengguna bermasalah (mungkin ada di sana untuk pengguna mahir), tandai dengan jelas seperti itu. Selain itu, jika seseorang yang gemuk memasukkan atau lupa sesuatu, minta Anda memprogram untuk mencetak tautan yang sangat ramah ke dokumentasi online. Anda mungkin berurusan dengan seseorang yang menggunakan program Anda melalui KVM dan tidak dapat memotong dan menempel.

Bila memungkinkan, (ini bertepatan dengan validasi input) gunakan apporach Google:

Apakah maksud Anda foo --bar FILENME, Anda hanya mengetik foo --bar

Tawarkan jalan keluar dari instruksi yang merusak

Tujuannya adalah untuk memberi tahu pengguna mengapa itu tidak berhasil dan minta mereka mencoba beberapa kali lagi, sambil memastikan bahwa Anda tidak melakukan apa pun yang berpotensi merusak kecuali tampaknya pengguna benar-benar ingin Anda melakukannya. Biarkan sakelar yang mematikan 'mengomel', misalnya -Yatau /Ytetapi memungkinkan jalan keluar bagi seseorang yang memiliki 'jari gemuk'.

Saya mungkin lupa beberapa petunjuk. Saya sering berurusan dengan ini karena sangat, sangat sulit untuk membuat antarmuka 'tingkat rendah' ​​untuk sesuatu yang cukup intuitif bagi kebanyakan orang untuk menghindari membuat kesalahan.


3

"Apakah Anda yakin ingin menghapus file / catatan ini? Ya / Tidak". Klik ya dan kemudian mendapat panggilan bahwa "keliru" mengklik tombol hapus merah dan perlu data itu kembali :)


7
Mengapa "mengutip". Apakah Anda menyarankan mereka mengklik ya, supaya mereka bisa menelepon Anda?
Peter Boughton

1
Mudah dipecahkan dengan menggunakan "penghapusan lunak" yang dapat dibatalkan.
Robert Harvey

1
ya mereka bisa dibatalkan, tetapi mengapa menghapusnya? Itulah mengapa saya menaruh peringatan itu di sana, meminta mereka untuk mengonfirmasi dua kali bahwa mereka ingin menghapusnya :)
Quamis

2
@ Quamis: Kotak dialog menjadi sangat menjengkelkan bagi banyak pengguna sehingga mereka cukup mengklik OK, Ya, apa pun, hanya untuk melewati kotak dialog. Itu sebabnya banyak sistem baru menggunakan penghapusan lunak tanpa konfirmasi, dan memberi pengguna cara untuk membatalkan. Sebagian besar sistem email sekarang bekerja dengan cara ini, misalnya.
Robert Harvey

1
@ Robert Harvey - Saya mengerti, dan ya itulah alasan spesifik penghapusan yang sulit harus dilaksanakan. Contoh khusus ini dapat diselesaikan dengan melacak kebijakan penyimpanan, tetapi mungkin ada kasus di mana orang menekan "Hapus" dengan benar mengharapkan konsekuensi dari operasi itu menjadi penghapusan yang benar. Saya menyukai rute hapus lunak sendiri, tetapi poin saya adalah kadang-kadang itu bukan opsi.
Inaimathi

3

Saya tidak merasa mendapatkan contoh perbaikan / perbaiki sama pentingnya dengan menyadari hal ini:

  • Pengguna tidak membaca manual Anda, atau menonton tutorial Anda. Mereka mempelajari perangkat lunak Anda melalui eksplorasi.

Jika melalui eksplorasi itu mereka merusak sesuatu, sebagai programmer, adalah tugas Anda untuk memperingatkan mereka tentang bahaya atau mencegahnya terjadi sejak awal. Saya tidak ingat di mana saya melihatnya sekarang, tetapi di benak saya, saya selalu berusaha untuk " membuat melakukan hal yang benar dengan mudah " bagi pengguna perangkat lunak saya.

Jika Anda bersikeras pada contoh:

  • Pengguna dapat memasukkan nama huruf kecil yang memecahkan kode integrasi / diperbaiki dengan melakukan validasi input
  • Pengguna dapat mengklik tombol yang salah setelah melakukan tindakan / diperbaiki dengan hanya menunjukkan tombol yang benar.
  • Pengguna dapat melakukan X secara tidak sengaja / diperbaiki dengan memperingatkan mereka bahwa mereka akan melakukan X.

Lihat kemana ini? :)


2
Peringatan harus disediakan hanya untuk operasi yang paling merusak, dan Anda harus menghindari salah satu dari itu, membatalkan JAUH BANYAK JAUH lebih baik, orang sekarang telah dilatih untuk mengklik 'OK' tanpa membaca kotak, itu memori otot sekarang, hindari mereka untuk operasi apa pun yang dapat dilakukan oleh pengguna secara teratur untuk menghindari efek ini.
Spudd86

3

Ini yang saya dengar minggu ini. Seorang pengguna meminta fitur "kirimi saya pemberitahuan ketika suatu peristiwa terjadi". Cukup sederhana dan pengembang terus maju dan mengimplementasikannya. Tentu, pertanyaan pertama seharusnya adalah "apa yang coba diatasi dengan pemberitahuan ini?". Saya tidak akan membahasnya. Beberapa hari kemudian pengguna berhenti oleh pengembang dan bertanya "Saya mendapat pemberitahuan ini. Apa yang harus saya lakukan dengannya?".

Saya ingat komik Dilbert ini dan menyarankan kepada pengembang "menulis aplikasi untuk mencari tahu apa yang harus dilakukan pengguna dengan pemberitahuan itu".

Seperti kata mpeterson, pengguna sangat kompetitif dalam bidang keahlian mereka. Mereka hanya tidak berpikir seperti pengembang atau perancang perangkat lunak.


2

Saya tidak berpikir pengguna bodoh. Mereka tidak ingin menggunakan program Anda atau apa pun. Yang mereka inginkan adalah menyelesaikan pekerjaan mereka. Bantu mereka dan mencegah bahaya agar tidak terjadi pada mereka di sepanjang jalan.


1
Anda tidak mengerti pertanyaannya. Anda ulangi apa yang saya tulis dengan kata lain. Ini bukan jawaban untuk pertanyaan itu. Praktik apa yang dapat kita lakukan untuk mencegah bahaya?
Maniero

1
Saya mengerti pertanyaan dengan baik, terima kasih. Pertanyaannya mencakup sesuatu yang tidak benar: "pengguna itu bodoh".
LennyProgrammers

1
Tidak, belum. Ini salah paham Anda. Kutipan Anda tidak ada!
Maniero

1
Ok, orang tidak melakukan hal bodoh, dunia ini sempurna :-) Ini kesimpulan saya tentang pendapat ini.
Maniero

1
Tidak ada perasaan keras, oke? ;)
LennyProgrammers

1

Memiliki antarmuka pengguna yang baik dan memberikan pengalaman belajar yang memadai sangat membantu mencegah pengguna melakukan hal-hal buruk.

  • Antarmuka pengguna yang baik harus tanpa gesekan.

    Alih-alih memunculkan kotak dialog (operasi yang mahal, dan yang diabaikan pengguna setelah beberapa saat) untuk mengonfirmasi penghapusan, melakukan penghapusan, dan menawarkan cara untuk membatalkan.

  • Antarmuka pengguna yang baik harus dapat ditemukan.

    Meskipun pita di Microsoft Office mendapat banyak kritik karena memaksa pengguna Word yang lama untuk mengubah cara mereka, pita itu adalah contoh cemerlang tentang bagaimana Anda dapat membuat antarmuka dapat ditemukan (yaitu mudah ditemukan).

  • Antarmuka pengguna yang baik, seperti kode yang baik, harus jelas.

    Tidak ada yang membaca manual. Satu-satunya manual yang pernah saya baca untuk pengguna saya adalah presentasi PowerPoint yang berisi langkah-langkah langkah-langkah dari perangkat lunak. Saya telah melihat ini dilakukan dengan alat video seperti Camtasia, tetapi PowerPoint lebih baik karena Anda dapat dengan mudah membalik ke depan dan ke depan melalui langkah-langkah.


-1

Pengguna tidak melakukan kesalahan. Kesalahannya terletak pada programmer yang gagal membuat antarmuka yang dapat digunakan.

Begitu juga tes kegunaan dengan setiap rilis!


2
Kembali ketika saya tinggal dengan orang tua saya, ayah saya bertanya mengapa dia terputus dari internet setiap kali dia memeriksa emailnya (ya, ini kembali di Zaman Batu ketika kita melakukan panggilan - saya hanya setua itu ). Saya memintanya untuk menunjukkan - coba tebak apa yang saya lihat? Ketika dialog Kirim & Terima Outlook Express muncul, opsi untuk memutuskan sambungan setelah mengirim dan menerima dicentang. Saya pikir itu semua pada pengguna ...
JohnL

3
Tidak benar-benar John .. Jika programmer pandangan berpikir ini melalui mereka tidak akan menempatkan kotak centang itu di sana atau memberikan label yang lebih bermakna. Ayahmu bukan orang idiot: fitur ini tidak dipikirkan atau sudah melalui tes kegunaan. Perangkat lunak tidak ada di sini untuk membuat kita merasa bodoh! :)
Arcturus

1
-1: Pengguna memang melakukan kesalahan, bahkan jika mereka dapat dihindari dengan hal-hal seperti pelabelan yang lebih baik. Intinya, pertanyaan ini menanyakan masalah spesifik yang memiliki solusi spesifik. Hanya mengatakan "mengujinya" hanyalah jawaban yang buruk.
Maks.
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.