Bagaimana cara membuat pengguna membaca pesan kesalahan?


177

Jika Anda memprogram untuk audiens nonteknis, Anda mendapati diri Anda pada risiko tinggi bahwa pengguna tidak akan membaca pesan kesalahan yang dengan hati-hati Anda sebutkan dan mencerahkan, tetapi cukup klik tombol pertama yang tersedia dengan sedikit rasa frustrasi.

Jadi, saya bertanya-tanya praktik apa yang dapat Anda rekomendasikan untuk membantu pengguna benar-benar membaca pesan kesalahan Anda, alih-alih hanya mengesampingkannya. Gagasan yang bisa saya pikirkan akan jatuh di sepanjang garis:

  • Pemformatan tentu saja membantu; mungkin pesan singkat dan sederhana, dengan tombol "pelajari lebih lanjut" yang mengarah ke pesan kesalahan yang lebih panjang dan lebih terperinci
  • Minta semua pesan kesalahan tertaut ke beberapa bagian panduan pengguna (agak sulit untuk dicapai)
  • Hanya saja, jangan mengeluarkan pesan kesalahan, cukup menolak untuk melakukan tugas (cara yang agak "Apple" menangani input pengguna)

Sunting: audiens yang ada dalam pikiran saya adalah basis pengguna yang agak luas yang tidak terlalu sering menggunakan perangkat lunak dan tidak tertawan (yaitu, tidak ada perangkat lunak internal atau komunitas sempit). Bentuk yang lebih umum dari pertanyaan ini ditanyakan pada slashdot , jadi Anda mungkin ingin memeriksa beberapa jawaban di sana.


12
komunitas wiki ....
jldupont

3
Audiens apa yang Anda targetkan pada perangkat lunak Anda? Misalnya. beberapa perusahaan, atau pengguna internet? Apakah ada hubungan yang dapat Anda jalin dengan pengguna?
Janusz Skonieczny

@ WoYek: Itu akan (dalam kasus saya) basis pengguna yang agak besar, tetapi dengan waktu penggunaan yang terbatas (yaitu itu bukan perangkat lunak yang sering Anda gunakan, ini lebih merupakan "penggunaan sesekali" dengan basis pengguna yang besar).
F'x

@ MikeJ Mungkin orang yang sama memposting pertanyaan di beberapa situs?
7wp

7
Saya berada di lab komputer di perguruan tinggi. Seseorang duduk di sebelah saya dan mencoba masuk. Muncul pesan kesalahan: "Kata sandi salah. Pastikan Anda tidak mengaktifkan caps lock." Dia menolaknya tanpa membaca dan mencoba lagi. Beberapa kali. Ketika dia meminta bantuan saya, saya hanya menyuruhnya membaca pesan itu.
TRiG

Jawaban:


70

Itu adalah pertanyaan bagus yang layak diberi +1 dari saya. Pertanyaannya meskipun sederhana, mencakup banyak aspek sifat pengguna akhir. Itu bermuara pada sejumlah faktor di sini yang akan menguntungkan Anda dan perangkat lunak itu sendiri, dan tentu saja untuk pengguna akhir.

  • Jangan letakkan pesan kesalahan di bilah status - mereka tidak akan pernah membacanya meskipun telah dihancurkan dengan warna dll ... mereka akan selalu merindukannya! Tidak peduli seberapa keras Anda akan mencoba ... Pada satu tahap selama pengujian UI Win 95 sebelum diluncurkan, MS melakukan percobaan untuk membaca UI ( ed - harus dicatat bahwa pesan secara eksplisit dinyatakan dalam konteks 'Lihat di bawah kursi' ), dengan selembar uang $ 100 yang ditempelkan di bawah kursi tempat para subjek duduk ... tidak ada yang melihat pesan di status bar!
  • Buat pesan singkat, jangan gunakan kata-kata menakutkan seperti 'Peringatan: sistem mengalami masalah', pengguna akhir akan menekan tombol panik dan akan bereaksi berlebihan ...
  • Tidak peduli seberapa keras Anda mencoba, jangan gunakan warna untuk mengidentifikasi pesan ... secara psikologis, itu mirip dengan mengibarkan bendera merah ke banteng!
  • Gunakan kata-kata yang terdengar netral untuk menyampaikan reaksi minimal dan bagaimana melanjutkan!
  • Mungkin lebih baik untuk menampilkan kotak dialog yang mencantumkan pesan kesalahan netral dan menyertakan kotak centang yang menunjukkan 'Apakah Anda ingin melihat lebih banyak dari pesan kesalahan ini di masa mendatang?', Hal terakhir yang diinginkan pengguna akhir, adalah dapat berfungsi di tengah perangkat lunak yang akan dibombardir dengan pesan popup, mereka akan frustrasi dan akan dimatikan oleh aplikasi! Jika kotak centang dicentang, catat ke file ...
  • Terus beri tahu pengguna akhir tentang pesan kesalahan apa yang akan ada ... yang menyiratkan ... pelatihan dan dokumentasi ... sekarang ini adalah hal yang sulit untuk dibeberkan ... Anda tidak ingin mereka berpikir bahwa akan ada menjadi 'masalah' atau 'gangguan' dan apa yang harus dilakukan jika itu terjadi ... mereka tidak boleh tahu bahwa akan ada kemungkinan kesalahan, memang rumit.
  • Selalu, selalu, jangan takut untuk meminta umpan balik ketika kejadian lancar - seperti 'Ketika nomor kesalahan 1304 itu muncul, bagaimana reaksi Anda? Apa interpretasi Anda '- bonus dengan itu, pengguna akhir mungkin dapat memberi Anda penjelasan yang lebih koheren alih-alih' Kesalahan 1304, objek basis data hilang! ', Sebaliknya mereka mungkin bisa mengatakan' Saya mengklik ini jadi jadi, kemudian seseorang menarik kabel jaringan mesin secara tidak sengaja ', ini akan memberi petunjuk kepada Anda karena harus menghadapinya dan dapat memodifikasi kesalahan dengan mengatakan' Ups, Sambungan jaringan terputus '... Anda mendapatkan maksud.
  • Last but not least, jika Anda ingin menargetkan audiens internasional, pertimbangkan internasionalisasi pesan kesalahan - maka itu sebabnya tetap netral, karena itu akan lebih mudah untuk diterjemahkan, menghindari sinonim, kata-kata slang, dll yang akan membuat terjemahannya tidak berarti - misalnya, Fiat Ford, perusahaan mobil itu menjual merek mereka Fiat Ford Pinto, tetapi menyadari tidak ada penjualan yang terjadi di Amerika Selatan, ternyata, Pinto adalah bahasa gaul di sana untuk 'penis kecil' dan karenanya tidak ada penjualan ...
  • ( ed ) Dokumentasikan daftar pesan kesalahan yang diharapkan di bagian terpisah dari dokumentasi berjudul 'Pesan Kesalahan' atau 'Tindakan Korektif' atau serupa, yang mencantumkan nomor kesalahan dalam urutan yang benar dengan satu atau dua pernyataan tentang cara melanjutkan. ..
  • ( ed ) Terima kasih kepada Victor Hurdugaci untuk masukannya, jaga pesan tetap sopan, jangan membuat pengguna akhir merasa bodoh. Ini bertentangan dengan jawaban oleh Jack Marchetti jika basis pengguna adalah internasional ...

Sunting: Ucapan terima kasih khusus kepada gnibbler yang menyebutkan poin penting lainnya juga!

  • Izinkan pengguna akhir untuk dapat memilih / menyalin pesan kesalahan sehingga mereka bisa jika mereka mau, untuk mengirim email ke tim dukungan bantuan atau tim pengembangan.

Sunting # 2: Badaku! Ups, terima kasih kepada DanM yang menyebutkan tentang mobil itu, nama saya campur aduk, itu Ford Pinto ... yang buruk ...

Sunting # 3: Telah disorot oleh ed untuk menunjukkan tambahan atau tambahan dan dikreditkan ke orang lain untuk masukan mereka ...

Sunting # 4: Menanggapi komentar Ken - inilah pendapat saya ... Tidak, bukan, gunakan warna Windows standar netral ... jangan gunakan warna mencolok! Tetap berpegang pada warna abu-abu normal dengan teks hitam, yang merupakan pedoman GUI standar normal dalam spesifikasi Microsoft..lihat Panduan UX ( ed ).

Jika Anda bersikeras pada warna mencolok, setidaknya, pertimbangkan potensi pengguna buta warna yaitu aksesibilitas yang merupakan faktor penting bagi mereka yang memiliki cacat, pesan kesalahan pembesaran ramah layar, buta warna, mereka yang menderita albino, mereka mungkin sensitif terhadap warna mencolok, dan juga epilepsi ... yang mungkin menderita warna tertentu yang dapat memicu kejang ...


1
Menarik tentang bilah status. Saya berpendapat bahwa orang - orang memperhatikan potongan-potongan berwarna cerah di bagian atas halaman web yang menunjukkan, misalnya, "Anda baru saja mendapatkan lencana Jawaban Baik." Ini tidak setara dengan bilah status, tetapi ini memberi tahu saya bahwa posisi dan warna latar belakang pesan kesalahan adalah faktor yang signifikan. Oh, dan catatan ejaan kecil: itu Fiat Punto. Pinto adalah produk Ford yang terkenal karena tangki bensin yang dipasang di belakangnya yang kadang meledak. Saya akan menghindari kedua nama :)
devuxer

@DanM: Astaga! kamu benar! Itu ford ... apa yang saya pikirkan ketika saya menulis jawabannya ... ya itu defo Ford Ford !!! Terimakasih atas peringatannya!!!
t0mm13b

@ommie, jangan lupa tentang Nova (seperti di Chevy Nova). Ini diterjemahkan menjadi "No Go" atau "
Do

2
@ DanM: dikoreksi itu - hei itu yang menarik .... aduh! Kedengarannya seperti mobil kayu dengan roda kayu yang masuk .... :)
t0mm13b

Terima kasih atas jawaban yang sangat bagus!
F'x

16

Tunjukkan pada mereka pesannya. Karena ketekunan dan semua, tetapi catat setiap kesalahan ke file. Pengguna tidak dapat mengingat apa yang mereka lakukan atau apa pesan kesalahannya hanya beberapa detik setelah acara, itu seperti akun saksi mata pelaku perpatrator.

Berikan cara yang baik untuk memungkinkan mereka mengirim email atau mengunggah log kepada Anda sehingga Anda dapat membantu mereka mendamaikan masalah. Jika itu adalah aplikasi web: lebih baik lagi, Anda dapat menerima informasi tentang situasi di depan siapa pun yang melaporkan masalah.


2
+1 besar untuk ini. Perhatikan bahwa bagian pengembang dapat berisi jejak tumpukan lengkap dan detail lainnya. Anda bahkan dapat mengambil tangkapan layar aplikasi (terutama untuk aplikasi WinForms internal) jika diinginkan.
TrueWill

Saya agak enggan untuk mempertimbangkan "tangkap tangkapan layar aplikasi" saran yang bagus: lagipula, itu kedengarannya seperti kebocoran serius data pribadi (bahkan jika aplikasi Anda tidak pernah dirancang untuk menangani NS <nogrep> informasi kelas A di tempat pertama. ) ...
F'x

Saya pikir itu lebih dari keputusan bisnis / kebijakan yang harus ditangani oleh pengguna domain daripada aspek teknis memberikan dukungan yang lebih baik dengan memiliki dukungan diagnostik kecelakaan "kotak hitam". Saya berharap bahwa aplikasi LOB internal memiliki keprihatinan / tujuan yang berbeda dari hubungan dukungan klien eksternal dengan informasi sensitif.
MikeJ

11

Jawaban singkat: Anda tidak bisa.

Jawaban yang lebih singkat: Jadikan mereka terlihat, relevan, dan kontekstual (sorot apa yang mereka buat kacau). Tapi tetap saja, Anda kalah dalam pertempuran. Orang tidak membaca di layar komputer, mereka memindai, dan mereka telah dilatih untuk mengklik tombol sampai kotak dialog hilang.


Kebiasaan mengklik dialog itu adalah masalah nyata dengan dialog instalasi IE ActiveX yang lama.
Alex Jasmin

10

Kami menempatkan grafik mudah diingat sederhana di kotak kesalahan: bukan ikon, bitmap yang cukup besar, dan tidak seperti ikon pesan Windows standar. Tidak ada yang bisa mengingat kata-kata dari kotak pesan (kebanyakan bahkan tidak akan membacanya jika kotak memiliki tombol "OK" yang dapat mereka tekan), tetapi kebanyakan orang TIDAK ingat gambar yang mereka lihat. Jadi orang-orang pendukung kami dapat bertanya kepada pelanggan "apakah Anda melihat pria peminum kopi?" atau "apakah Anda melihat meja kosong?". Setidaknya dengan begitu kita tahu kira-kira apa yang salah.


1
Masalah saya dengan ide itu adalah ia merusak keseragaman UI yang orang harapkan. Lebih jauh, bagaimana mereka bisa tahu bahwa "meja kosong" adalah masalah yang lebih mengancam daripada "peminum kopi"?
F'x

Kami membuat sistem tujuan tunggal (pusat kendali darurat), jadi kami hanya memperhatikan diri sendiri dengan keseragaman UI dalam sistem itu. Toh tidak ada hierarki ancaman yang tersirat di sini. Tujuannya hanya agar mudah diingat. Kedua grafik tersebut sebenarnya mewakili situasi tidak aktif yang sama (operator menjauh dari meja, operator mungkin sedang istirahat) sehingga mereka akan bermakna ... tetapi itu bukan tujuan sebenarnya. Kami hanya ingin mereka menjadi berkesan. Mungkin saya tidak perlu menyebutkan mouse yang menari :-).
Bob Moore

10

Tergantung pada basis pengguna Anda, menulis pesan kesalahan lucu / kasar / pribadi dapat bekerja dengan baik.

Sebagai contoh, saya menulis sebuah aplikasi yang memungkinkan orang-orang SDM kami untuk melacak tanggal perekrutan / pemecatan karyawan dengan lebih baik. [kami adalah perusahaan kecil, sangat santai].

Ketika mereka memasukkan tanggal yang salah saya akan menulis:

Hei bodoh, pelajari cara memasukkan tanggal!

EDIT: Tentu saja pesan yang lebih bermanfaat adalah untuk mengatakan: "Silakan masukkan tanggal sebagai mm / hh / tttt" atau mungkin dalam kode untuk mencoba dan mencari tahu apa yang mereka masukkan dan jika mereka memasukkan "blahblah" untuk menunjukkan kesalahan. Namun, ini adalah aplikasi yang sangat kecil untuk orang SDM yang saya kenal secara pribadi. Karenanya sekali lagi orang-orang, baca baris pertama posting ini: Tergantung pada basis pengguna Anda ...

Baru-baru ini saya mengerjakan proyek Institut Seni, jadi pesan-pesan kesalahannya ditujukan kepada audiens, seperti:

Kebanyakan karya seni sebelum periode Barok tidak ditandatangani. Namun, kami berada di luar periode Barok sekarang, sehingga semua bidang harus diselesaikan.

Pada dasarnya persiapkan untuk audiens Anda jika memungkinkan, dan hindari membosankan karena semua kesalahan umum yang tidak wajar seperti: "silakan masukkan email" atau "silakan masukkan email yang valid".


Mengingatkan saya pada "tip" dalam kata MS - Menjalankan dengan gunting bisa berbahaya
MikeJ

7
pelajari cara memasukkan tanggal !! - Tentu tapi beri saya petunjuk. Saya tidak perlu menebak format yang tepat.
Alex Jasmin

4
+1 untuk pesan Baroque, saya selalu terhibur oleh kreativitas semacam ini :)
medopal

2
Tidak yakin saya sangat menyukai pesan semacam itu ... Lagi pula, mengapa saya harus belajar cara memasukkan tanggal?
F'x

1
Alih-alih mengharuskan pengguna untuk mengetahui format tanggal, luangkan beberapa menit ekstra dan ajarkan perangkat lunak Anda cara menguraikan tanggal dalam berbagai format. Komputer itu cerdas - biarkan itu membantu pengguna alih-alih menampar pergelangan tangan mereka.
Bryan Oakley

10

Peringatan / munculan mengganggu, itu sebabnya semua orang menekan tombol pertama yang mereka lihat.

Buat tidak terlalu mengganggu . Contoh: jika pengguna memasukkan tanggal yang salah, atau memasukkan teks di mana angka diharapkan, maka JANGAN popup pesan, cukup sorot bidang dan tulis pesan di suatu tempat di sekitarnya.

Buat kotak pesan khusus . Jangan pernah menggunakan kotak pesan default sistem, misalnya kotak pesan Windows XP mengganggu dirinya sendiri. Buat kotak pesan berwarna baru, dengan warna latar berbeda dari standar sistem.

Sangat Penting: jangan ngotot . Beberapa kotak pesan menggunakan dialog Modal dan bersikeras membuat Anda membacanya, ini sangat menjengkelkan. Jika Anda dapat membuat kotak pesan muncul sebagai pesan peringatan, akan lebih baik, misalnya, pesan Stack Overflow yang muncul tepat di bagian atas halaman, memberi informasi tetapi tidak mengganggu.

PEMBARUAN
Jadikan pesan itu bermakna dan bermanfaat . Misalnya, jangan menulis sesuatu seperti, "Tidak ada Papan Ketik yang ditemukan, tekan F1 untuk melanjutkan."


1
1 dan 3 bagus. 2 dipertanyakan, karena alasan aksesibilitas. Kontrol standar sistem dapat ditangani secara khusus. Varian Anda tidak bisa.
Phil Miller

1
@Novelocrat, kemungkinannya bagus bahwa jika sisa aplikasi Anda dapat diakses, dialog kesalahan khusus Anda juga akan demikian. Dan jika sisa aplikasi Anda sudah memiliki masalah aksesibilitas, satu lagi dialog dengan masalah tidak masalah.
Mike Daniels

@Novelocrat, saya terutama berbicara tentang aplikasi web, daripada kotak peringatan JavaScript default, Anda dapat membuat kotak bergaya baru, dan memberikannya properti yang sama. Tetapi ide yang sama bisa berlaku untuk aplikasi Desktop jika tujuannya adalah untuk memaksa membaca pesan
medopal

Sama dengan Novelocrat, saya tidak terlalu suka bagian "tidak pernah menggunakan sistem UI" dari jawabannya. Orang ingin merasakan di wilayah yang dikenal.
F'x

Dan juga, aksesibilitas selalu lebih baik untuk sistem UI.
F'x

8

Desain UI terbaik adalah tempat Anda hampir tidak pernah menampilkan pesan kesalahan. Perangkat lunak harus beradaptasi dengan pengguna. Dengan desain semacam itu, pesan kesalahan akan menjadi novel dan akan menarik perhatian pengguna. Jika Anda membumbui pengguna dengan dialog tidak masuk akal seperti itu, Anda secara eksplisit melatih mereka untuk mengabaikan pesan Anda.


6

Menurut pendapat dan pengalaman saya, itu adalah pengguna yang kuat, yang tidak membaca pesan kesalahan. Audiens nonteknis yang saya kenal membaca setiap pesan di layar dengan sangat hati-hati dan masalah pada titik ini kebanyakan adalah: Mereka tidak memahaminya.

Poin ini mungkin menjadi penyebab pengalaman Anda, karena pada titik tertentu mereka akan berhenti membacanya, karena "mereka tidak memahaminya", jadi tugas Anda mudah:

Buat pesan kesalahan semudah mungkin dimengerti dan simpan bagian teknis di bawah tenda.

Misalnya saya mentransfer pesan seperti ini:

ORA-00237: operasi snapshot dianulir: file kontrol yang baru dibuat Penyebab: Upaya untuk memanggil cfileMakeAndUseSnapshot dengan file kontrol yang terpasang saat ini yang baru dibuat dengan CREATE CONTROLFILE. Tindakan: Pasang file kontrol saat ini dan coba lagi operasi.

untuk sesuatu seperti:

Langkah ini tidak dapat diproses karena masalah sesaat dengan database. Silakan hubungi (admin Anda | helpdesk | siapa pun yang dapat menghubungi pengembang atau admin untuk menyelesaikan masalah). Maaf untuk ketidaknyamanannya.


2
Dan kemudian admin / helpdesk / etc mendengar tentang pesan tersebut, dan bertanya "Apa yang harus saya lakukan?". Pesan kedua Anda bersifat umum sampai tidak berguna. Adapun yang pertama, tidak pernah menggunakan perangkat lunak Oracle (menebak berdasarkan awalan), saya masih bisa berhipotesis pada apa yang seharusnya saya lakukan.
Phil Miller

Yah, helpdesk dapat menginformasikan pengembang untuk memperbaiki masalah. Apakah akan membantu klien atau helpdesk untuk menulis pesan teknis dalam kesalahan? Semua pengguna ingin tahu pada saat ini adalah: Apa yang terjadi dan di mana saya bisa mendapatkan bantuan, jika itu bukan kesalahan yang dibuatnya (input salah atau sesuatu). Dan jangan salah, itu tentu saja pesan di lapisan presentasi. Di log server, ada pesan kesalahan khusus, yang akan membantu Anda memperbaikinya.
bl4ckb0l7

1
@Novelocrat, tepatnya. Anda sering dapat menemukan personil dukungan teknis berteriak, "Tapi saya adalah administrator sistem, dan saya tidak punya f * @ # & tahu apa masalahnya!" Anda sebaiknya menambahkan opsi "tunjukkan padaku technobabble" untuk kesalahan Anda.
Mike Daniels

helpdesk tidak dapat memberikan banyak bantuan ketika itu merupakan aplikasi komersial dan kesalahan tidak mengandung informasi yang berguna.
Mike Daniels

5

Tunjukkan kepada pengguna bahwa pesan kesalahan memiliki arti , dan itu adalah cara untuk memberikan bantuan kepada mereka dan mereka akan membacanya. Jika itu hanya pesan jargon-bable atau generik, mereka akan belajar untuk mengabaikannya dengan cepat.

Saya telah belajar bahwa ini adalah praktik yang sangat baik untuk memasukkan dialog kesalahan dengan tindakan default untuk mengirim (misalnya melalui email) info diagnostik terperinci, jika Anda dengan cepat menanggapi email-email itu dengan informasi atau solusi yang berharga, mereka akan memujamu.

Ini juga merupakan alat belajar yang hebat. Dalam versi yang akan datang Anda dapat memecahkan masalah yang diketahui atau setidaknya memberikan info penyelesaian masalah di tempat. Sampai saat itu pengguna akan belajar bahwa pesan ini disebabkan oleh X dan masalahnya dapat diselesaikan oleh Y - semua karena seseorang memang menjelaskannya kepada mereka.

Tentu saja ini tidak akan bekerja pada aplikasi skala besar, tetapi bekerja dengan sangat baik dalam aplikasi perusahaan dengan beberapa ratus pengguna, dan dengan lincah, rilis rilis awal sering, lingkungan.

EDIT:

Karena Anda memiliki basis pengguna yang luas, saya sarankan untuk menyediakan perangkat lunak yang melakukan apa yang diharapkan / dilakukan oleh pengguna, misalnya. jangan tampilkan pesan eroror kepada mereka jika nomor telepon tidak diformat dengan baik, format ulang jika untuk mereka.

Saya pribadi menyukai perangkat lunak yang tidak membuat saya berpikir , dan ketika sesekali tidak ada yang dapat Anda (pengembang) lakukan untuk menginterpretasikan niat saya, memberikan pesan yang ditulis dengan sangat baik (dan ditinjau oleh pengguna sebenarnya).

Sudah menjadi rahasia umum bahwa orang tidak membaca dokumentasi (apakah Anda membaca instruksi back-to-back lakukan ketika Anda terhubung ke alat rumah tangga?), Mereka mencoba cara untuk mendapatkan hasil dengan cepat, ketika gagal Anda harus menarik perhatian mereka (mis. nonaktifkan tombol default untuk sementara waktu) dengan info yang bermakna dan bermanfaat . Mereka tidak peduli dengan kegagalan perangkat lunak Anda, mereka ingin mendapatkan hasil, sekarang.



2

Untuk memulai, tulis pesan kesalahan yang benar-benar dapat dimengerti pengguna. "Kesalahan: 1023" bukan contoh yang baik. Saya pikir cara yang lebih baik adalah mencatat kesalahan, daripada menunjukkannya kepada pengguna dengan beberapa kode "mewah". Atau jika logging tidak memungkinkan, berikan pengguna cara yang tepat untuk mengirim detail kesalahan ke departemen dukungan.

Juga, singkat dan cukup jelas. Jangan sertakan beberapa detail teknis. Jangan perlihatkan kepada mereka informasi yang tidak dapat mereka gunakan. Jika mungkin berikan solusi untuk kesalahan tersebut. Jika tidak memberikan rute default, itu harus diambil.

Jika aplikasi Anda adalah aplikasi web, merancang halaman kesalahan khusus adalah ide yang bagus. Mereka kurang menekankan pengguna, misalnya SO. Anda bisa mendapatkan beberapa ide bagaimana merancang halaman kesalahan yang bagus di sini: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/


2

Satu hal yang ingin saya tambahkan.

Gunakan kata kerja untuk tombol tindakan Anda untuk menutup pesan kesalahan Anda daripada tanda seru, misalnya jangan gunakan "Oke!" "Tutup" dll.


1
Beberapa platform tidak membiarkan Anda melakukan ini. Hampir ada alasan bagus untuk pembatasan itu juga.
Phil Miller

Saya sangat menyukai komentar Novelocrat. UI standar baik untuk pengguna (dan karenanya baik untuk Anda). Saya pikir tetap dengan label tombol standar mencapai sesuatu yang Anda tidak ingin kehilangan, bahkan untuk menarik perhatian (kecuali mungkin dalam kasus luar biasa).
F'x

Anda tidak perlu menggunakan peringatan JS () untuk menampilkan pesan kesalahan. Anda dapat membangun jendela dialog Anda sendiri. Juga tujuan menggunakan kata kerja dan bukan hanya tanda seru adalah karena jika Anda melihat 'Ok' sebagai tombol, Anda harus membaca isi kotak dialog. Masalahnya adalah beberapa pengguna tidak akan meluangkan waktu untuk melakukannya sehingga mereka hanya akan mengklik ok. Jika Anda menggunakan kata kerja untuk menggambarkan tindakan maka pengguna akan tahu apa yang terjadi tanpa membaca kotak dialog.
Mark

Tutup adalah kata kerja. Anda menggunakannya dalam kalimat Anda sendiri; "untuk menutup pesan kesalahan Anda"
Ricket

Tapi @Mark, pertanyaan ini adalah tentang membiarkan mereka membacanya: p
Bart van Heukelom

2

Satu tip bagus yang saya pelajari adalah Anda harus menulis kotak dialog seperti artikel surat kabar. Bukan dalam arti ukuran, tetapi dalam arti penting. Biarkan saya jelaskan.

Anda harus menulis hal-hal yang paling penting untuk dibaca, pertama, dan berikan informasi yang lebih rinci kedua.

Dengan kata lain, ini tidak baik:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Alih-alih, ubah urutan:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Dengan cara ini, pengguna dapat membaca sebanyak yang dia inginkan, atau mengganggu, dan masih memiliki ide tentang apa yang ditanyakan.



2

Kecuali Anda dapat memberikan pengguna beberapa solusi sederhana, jangan repot-repot menunjukkan kepada pengguna pesan kesalahan sama sekali. Tidak ada gunanya, karena 90% pengguna tidak akan peduli apa yang dikatakannya.

Di sisi lain Jika Anda BISA benar-benar menunjukkan kepada pengguna solusi yang bermanfaat, maka salah satu cara untuk memaksa mereka membacanya adalah membuat tombol OK menjadi diaktifkan setelah sekitar 10 detik. Semacam bagaimana Firefox melakukannya kapan pun Anda mencoba memasang plug-in baru.

Jika ini adalah kerusakan total yang tidak dapat Anda pulihkan dengan anggun, beri tahu pengguna dengan istilah yang sangat awam dengan mengatakan:

" Maaf kami mengacau, kami ingin mengirim beberapa informasi tentang kecelakaan ini, apakah Anda mengizinkan kami melakukannya? YA / TIDAK "

Selain itu, cobalah untuk tidak membuat pesan kesalahan Anda lebih lama dari kalimat. Ketika orang (termasuk saya) melihat seluruh paragraf berbicara tentang kesalahan, pikiran saya mati begitu saja.

Dengan begitu banyak media sosial dan informasi yang berlebihan, pikiran orang membeku ketika mereka melihat dinding teks.

EDIT:

Seseorang juga baru-baru ini menyarankan untuk menggunakan komik bersama dengan pesan apa pun yang ingin Anda tampilkan. Seperti sesuatu dari Dilbert yang mungkin dekat dengan jenis kesalahan yang mungkin Anda miliki.


1
Anda dapat mencari kartun Dilbert yang relevan di sini: bfmartin.ca/finder
SLaks

Sepuluh detik? Lihatlah jam dan hitung sepuluh detik. Ini adalah keabadian ketika Anda mencoba untuk menyelesaikan beberapa pekerjaan.
Mike Daniels

1
Mike, itu dimaksudkan sebagai contoh, tidak ditulis dalam batu. Pilih batas waktu apa pun yang Anda inginkan. Atau, apakah Anda pernah menginstal adon Firefox? Apakah hitung mundur itu benar-benar mengganggu Anda? Saya belum pernah mendengar terlalu banyak orang mengeluh tentang itu.
7wp

@Roberto - berbicara tentang hitungan mundur plugin Firefox ... yang TIDAK mengganggu saya. Saya hanya ingin klik install. Mengapa saya perlu hitungan mundur ketika saya mengklik instal sebuah plugin dan kemudian sekarang harus menunggu 10 detik untuk mengonfirmasi pemasangan.
Markus

1
@Ark justru karena alasan pertanyaan Stack Overflow ini diajukan. Terlalu banyak orang mengklik senang dan tidak repot-repot membaca pesan dan konsekuensinya dan akhirnya melakukan sesuatu yang tidak mereka maksudkan. Mark, Anda tahu dan mengerti apa yang Anda klik. Namun, setelah bekerja di dukungan teknis HP di masa lalu, ada orang di luar sana yang mengklik pada hal-hal hanya karena mereka bisa. Penundaan memaksa pengguna untuk berhenti dan melihat pesan, daripada mengatakan "ya, ya, apa pun yang saya akan klik OK, sudah pergi"
7wp

2

Dari pengalaman saya: Anda tidak mendapatkan pengguna (terutama yang non-teknis) untuk membaca pesan kesalahan. Tidak peduli seberapa jelas dan dapat dimengerti, tebal, merah, dan mem-flash pesan, yang Anda tampilkan, sebagian besar pengguna hanya akan mengklik sesuatu yang tidak biasa mereka gunakan, bahkan jika itu "Apakah Anda benar-benar ingin menghapus semuanya?". Saya telah melihat pengguna mengklik "window close" -icon alih-alih "OK" atau "membatalkan" meskipun mereka bahkan tidak tahu opsi mana yang mereka pilih dengan melakukannya ...

Jika Anda benar-benar perlu memaksa pengguna untuk membaca apa yang Anda tampilkan, saya akan menyarankan JavaScript-Countdown sampai sebuah tombol dapat diklik. Dengan begitu pengguna diharapkan akan menggunakan waktu tunggu untuk benar-benar membaca apa yang seharusnya. Berhati-hatilah: sebagian besar pengguna akan lebih jengkel karenanya :)

Saya juga lebih suka ide Anda tentang "baca lebih lanjut" -tautan, meskipun saya ragu itu akan membuat pengguna lebih tertarik yang hanya ingin menyingkirkan pesan dengan segala cara ...

Sebagai catatan: ada pengguna yang DO membaca pesan kesalahan tetapi sangat takut mereka tidak akan melakukan apa-apa dengannya. Saya pernah memiliki panggilan dukungan di mana pelanggan akan membacakan pesan kesalahan kepada saya, bertanya kepada saya, apa yang harus dia lakukan. "Yah, apa pilihanmu?", Tanyaku. "Jendela itu hanya memiliki tombol 'OK'.", Jawabnya. ... mmh, susah :)


11
"JavaScript-Countdown" ini adalah hal paling menjengkelkan yang bisa Anda lakukan. Pengguna akan benci untuk "harus menunggu jam untuk menghitung mundur" dan nyaris tidak fokus pada teks kesalahan daripada kemarahannya.
bl4ckb0l7

2

Saya sering menampilkan kesalahan dengan warna merah (ketika desain memungkinkannya).

Merah berarti "waspada", dll. Jadi lebih sering dibaca.


3
dan bagaimana dengan orang yang buta warna?
Natrium

1
Sebagai seseorang yang buta warna, saya bahkan tidak yakin seperti apa warna "merah" itu.
MikeJ

Merah tidak secara universal diartikan sebagai peringatan. Beberapa budaya mengartikannya sebagai kebahagiaan, misalnya. Waspadai siapa pengguna potensial Anda saat memilih warna.
Bryan Oakley

1
@ MikeJ: jelas, Tyzak harus membuatnya berkedip, sebagai gantinya. Itu akan jauh lebih bermanfaat. Ada perbedaan dalam nilai (kecerahan) antara bidang yang orang lain katakan adalah 'merah' dan yang mereka katakan jelas, bukan?
Phil Miller

hm, saya tidak berpikir tentang buta warna, itu poin yang bagus. ya warnanya ditafsirkan secara universal (Cina, India). Itu tergantung pada audiens, kan.
Tyzak

1

Nah, untuk menjawab pertanyaan Anda secara langsung: Jangan programer Anda menulis pesan kesalahan Anda. Jika Anda mengikuti saran ini, Anda akan menghemat, secara kumulatif, ribuan jam kecemasan pengguna dan produktivitas dan jutaan dolar dalam biaya dukungan teknis.

Namun, tujuan sebenarnya adalah mendesain aplikasi Anda sehingga pengguna tidak dapat membuat kesalahan. Jangan biarkan mereka mengambil tindakan yang mengarah pada kesalahan pijat dan meminta mereka untuk membuat cadangan. Sebagai contoh sederhana, dalam formulir web yang mengharuskan semua bidangnya diisi, alih-alih memunculkan pesan kesalahan saat pengguna mengklik tombol Kirim, jangan aktifkan tombol Kirim sampai semua bidang berisi konten yang valid. Ini berarti lebih banyak pekerjaan di sisi belakang, tetapi menghasilkan pengalaman pengguna yang lebih baik.

Tentu saja, itu adalah dunia yang ideal. Terkadang, kesalahan program tidak dapat dihindari. Ketika hal itu terjadi, Anda perlu memberikan informasi yang jelas, lengkap, dan bermanfaat, dan yang paling penting, jangan memaparkan sistem kepada pengguna dan jangan salahkan pengguna atas tindakan mereka.

Pesan kesalahan yang baik harus berisi:

  1. Apa masalahnya dan mengapa itu terjadi.
  2. Bagaimana mengatasi masalah tersebut.

Salah satu hal terburuk yang dapat Anda lakukan adalah hanya mengirimkan pesan kesalahan sistem kepada pengguna. Misalnya, ketika program Java Anda melempar pengecualian, jangan hanya meneruskan programmer-ese ke UI dan memaparkannya kepada pengguna. Tangkap, dan pesan yang jelas dibuat oleh pengembang bantuan pengguna Anda yang dapat Anda presentasikan kepada pengguna Anda.

Saya cukup beruntung, pada pekerjaan terakhir saya, untuk bekerja dengan tim programmer yang tidak akan berpikir untuk menulis pesan kesalahan mereka sendiri. Setiap kali mereka menemukan diri mereka dalam situasi di mana seseorang diperlukan dan program tidak dapat dirancang untuk menghindarinya (seringkali karena sumber daya yang terbatas), mereka selalu mendatangi saya, menjelaskan apa yang mereka butuhkan, dan biarkan saya membuat pesan kesalahan yang jelas dan mengikuti gaya perusahaan. Jika itu adalah pola pikir default setiap programmer, dunia komputasi akan menjadi tempat yang jauh, jauh lebih baik.


1

Lebih sedikit kesalahan

Jika aplikasi melempar muntah pada Anda secara teratur, Anda menjadi kebal terhadapnya, dan kesalahan menjadi muzak latar menjengkelkan. Jika kesalahan adalah peristiwa langka, itu akan mendapat lebih banyak perhatian.

Cepat apa pun yang bukan masalah besar, buang semua peringatan itu, temukan cara untuk memahami maksud pengguna, ambil keputusan jika memungkinkan. Saya memiliki beberapa aplikasi yang terus saya rampingkan dengan cara ini. Pengembang melihat setiap kesalahan sebagai hal yang penting, tetapi ini tidak benar dari sudut pandang pengguna. Cari respons umum pengguna terhadap masalah dan tangkap itu, sebarkan itu sebagai respons Anda .

Jika Anda perlu meningkatkan kesalahan: singkat, singkat, faktor teror rendah, tidak ada tanda seru. Paragraf gagal .

Tidak ada peluru perak, tetapi Anda perlu merekayasa sosial untuk membuat kesalahan penting.


1

Kami memberi tahu pengguna bahwa manajer mereka telah dihubungi (yang bohong). Itu bekerja sedikit terlalu baik dan harus dipindahkan.


1

Menambahkan tombol "Advanced" yang memungkinkan beberapa detail teknis lebih lanjut akan memberikan insentif untuk membacanya bagi bagian dari audiens target yang menganggap dirinya sebagai teknis


0

Saya menyarankan agar Anda memberikan umpan balik (menyatakan bahwa pengguna melakukan kesalahan) segera setelah kesalahan terjadi. (Misalnya, saat memasukkan nilai bidang tanggal, periksa nilainya dan, jika salah, buat bidang input berbeda secara visual).

Jika ada kesalahan pada halaman (saya lebih ke pengembangan web, maka saya menyebutnya sebagai "halaman", tetapi bisa juga disebut "formulir"), tampilkan "ringkasan kesalahan", menjelaskan bahwa ada adalah kesalahan dan daftar poin tentang apa yang sebenarnya terjadi kesalahan. Namun, jika ada lebih dari 5-6 kata per pesan, itu tidak akan dibaca / dipahami.


Dua paragraf Anda tampaknya saling bertentangan: berikan umpan balik segera, tetapi kumpulkan di akhir halaman?
F'x

@ FX, Idenya adalah Anda melakukan kedua hal itu - memperingatkan pengguna dengan segera, tetapi, karena dia mungkin masih mengabaikannya, kumpulkan semua kesalahan di akhir halaman.
naivists

0

Bagaimana dengan menyatakan tombol "Klik di sini untuk berbicara dengan teknisi pendukung yang akan membantu Anda dengan masalah ini."

Ada banyak situs web yang menyediakan opsi untuk berbicara dengan orang sungguhan.


Intinya adalah untuk membuat pengguna menangani kesalahan sendiri, setidaknya jika memungkinkan. Tombol seperti itu akan menjadi pernyataan kegagalan total dari niat.
Seether

0

Saya membaca kandidat untuk solusi paling mengerikan di slashdot:

Kami telah menemukan bahwa satu-satunya cara untuk membuat pengguna bertanggung jawab atas kesalahan adalah dengan memberi mereka penalti karena memaksa kesalahan itu hilang. Sebagai permulaan, jika memungkinkan, kesalahan tidak akan benar-benar menutup untuk mereka kecuali kita memasukkan kata sandi admin untuk membuatnya hilang, dan jika mereka reboot untuk menyingkirkannya (Task Manager dinonaktifkan pada semua PC klien) mesin tidak akan membuka aplikasi yang macet selama 15 menit. Tentu saja, ini semua tergantung pada jenis pengguna yang Anda hadapi, karena pengguna yang lebih mahir secara teknis tidak akan menerima sistem semacam ini, tetapi setelah mencoba secara harfiah TAHUN untuk membuat pengguna bertanggung jawab atas kerusakan dan memastikan departemen TI mengetahui mereka untuk memperbaiki masalah sebelum terlalu sulit untuk dikelola, ini adalah satu-satunya langkah yang berhasil. Sekarang,


0

"PERHATIAN! PERHATIAN! Jika Anda tidak membaca pesan kesalahan Anda AKAN MATI!"


0

Terlepas dari semua rekomendasi dalam jawaban yang diterima, pengguna saya terus mengklik tombol pertama yang bisa mereka temukan. Jadi sekarang saya tunjukkan ini:

Baca ini!

Pengguna harus membuat pilihan sebelum tombol OK muncul

Pilih opsi yang benar

Jika ia memilih opsi ke-3, ia dapat melanjutkan, jika tidak, aplikasi akan berhenti.

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.