Berapa banyak informasi tentang kesalahan yang harus ditampilkan kepada pengguna?


38

Aplikasi selalu dapat melempar kesalahan. Jika kesalahan seperti itu terjadi, pengguna harus diberitahu, karena apa yang dia minta agar aplikasi tidak berhasil.

Namun, berapa banyak informasi yang harus diberikan pengguna? Saya pikir sebagian besar dari kita sepakat untuk tidak menampilkan jejak stack ( Haruskah jejak stack berada di pesan kesalahan yang disajikan kepada pengguna? ), Tapi saya tidak dapat menemukan pertanyaan tentang sisa konten kesalahan atau apa yang harus ditampilkan kepada pengguna.

Misalnya, bahasa yang mendukung pengecualian (.net, java) memiliki tipe pengecualian untuk dibagikan, di mana pengecualian terjadi, dan pesan yang agak klarifikasi untuk disertakan bersama pengecualian. Haruskah ini juga disembunyikan dari pengguna? Atau haruskah kita menunjukkan ini? Atau haruskah kita menampilkan pesan umum? atau haruskah kita menunjukkan salah satu dari sejumlah pesan berdasarkan pada apa pengecualian yang mendasarinya?

Jawaban:


34

apa yang harus ditampilkan kepada pengguna. Haruskah ini juga disembunyikan dari pengguna?

Anda menunjukkan kepada pengguna apa yang dapat ditindaklanjuti untuk mereka.

Misalnya, jika Anda memiliki kesalahan yang disebabkan karena beberapa pengecualian penunjuk nol dan lebih banyak bug daripada kesalahan pengguna Anda tidak ingin penjelasan lengkap karena mereka tidak dapat melakukan sesuatu yang berbeda.

Atau haruskah kita menunjukkan ini? Atau haruskah kita menampilkan pesan umum?

Menampilkan pengecualian karena konten pesan kesalahan utama tidak berguna untuk sebagian besar pengguna . Mungkin jika basis pengguna target Anda adalah pengembang, Anda dapat menampilkan informasi sebagai kesalahan penuh sepanjang waktu (mungkin Anda memiliki aplikasi internal untuk pengujian otomatis). Tetapi umumnya pengguna tidak dapat melakukan sesuatu yang berbeda bahkan dengan pengetahuan itu.

haruskah kita menunjukkan salah satu dari sejumlah pesan berdasarkan pada apa pengecualian yang mendasarinya?

Strategi terbaik adalah melakukan hal berikut:

  • Menafsirkan kesalahan ke dalam teks yang bermakna bagi pengguna.
    • Bagian dari ini adalah "apa yang dapat dilakukan pengguna secara berbeda?"
    • Jika mereka tidak dapat melakukan sesuatu yang berbeda, katakan sesuatu seperti "kesalahan tak terduga telah terjadi."
  • Tambahkan deskripsi kesalahan terperinci "opsional"
  • Izinkan pengguna mengirimkan laporan kesalahan (atau melakukan ini secara otomatis, tergantung pada basis pengguna)

Contoh

masukkan deskripsi gambar di sini

  1. Ini menunjukkan "inilah yang terjadi" (kesalahan tak terduga)
  2. Memberitahu pengguna apa yang harus dilakukan (buka kembali Mail, bahkan sertakan jalan pintas untuk melakukan ini)
  3. Juga memiliki "lihat detail" jika seseorang ingin melihat kesalahan teknis penuh
  4. Memberikan pemberitahuan, laporan kesalahan salah diajukan (lihat di bawah)

Perhatikan bahwa dalam beberapa kasus Anda mungkin ingin membuat laporan kesalahan menjadi manual vs otomatis.


20
Saya tidak setuju. Tidak ada yang sangat mengganggu seperti aplikasi yang mencetak "kesalahan telah terjadi." ke layar dan kemudian keluar. Setiap kali itu terjadi, saya selalu bertanya-tanya mengapa pengembang sangat malas untuk mencetak pesan yang tidak informatif. Jelaskan sesuatu kepada pengguna sehingga mereka dapat memahami apa yang salah secara umum, bahkan jika tidak ada yang bisa mereka lakukan. Skenario terbaik, mereka dapat Google pesan kesalahan dan mungkin menemukan solusi yang telah dijelaskan orang lain, yang hampir mustahil jika setiap kesalahan yang berbeda mencetak pesan generik yang sama.
Jon Bentley

3
@ JonBentley Anda melihatnya sebagai pengembang, yang ingin memahami hal ini. Rata-rata pengguna hanya akan khawatir bahwa mereka harus memahaminya, dan mereka tidak perlu melakukannya.
deworde

12
@deworde Sebaliknya, saya menganggapnya sebagai pengguna . Sebagai pengguna, saya tidak ingin memahaminya dalam istilah teknis, tetapi saya menginginkan informasi yang cukup sehingga saya merasa orang yang menulis perangkat lunak tidak kompeten ("kesalahan telah terjadi" memberi kesan bahwa pengembang tidak Saya tidak tahu apa yang mereka lakukan), sehingga saya dapat mencari jawaban. Jika setiap kerusakan mengatakan "kesalahan telah terjadi" maka pencarian Google tidak akan membantu saya. Pesan unik untuk setiap situasi jauh lebih mungkin untuk membawa saya ke forum di mana orang lain memiliki masalah yang sama, dan mungkin menyelesaikannya.
Jon Bentley

3
@ JonBentley beberapa poin untuk dipertimbangkan. Pertama, poin utama dari jawaban ini adalah Anda memberikan informasi yang dapat ditindaklanjuti oleh pengguna. Jika itu adalah kesalahan mereka dapat memperbaikinya perlu memberi tahu mereka informasi untuk menyelesaikannya. Ini termasuk dalam You show the user what is actionable for them. Jika Anda tahu penyebab masalahnya, maka Anda menunjukkannya kepada pengguna dalam deskripsi. Tetapi umumnya jika Anda tahu alasan kesalahan Anda akan tahu resolusi masalah untuk menginformasikan pengguna dengan tepat.
enderland

2
Kedua, Anda terlalu melebih-lebihkan kemampuan pengguna rata-rata untuk menyelesaikan sendiri masalah. Mayoritas populasi adalah apa yang oleh sebagian besar pengembang / programmer / Stack Exchange disebut komputer buta huruf. Sebagian besar dari orang-orang ini terus terang tidak diperlengkapi untuk mendiagnosis, memecahkan masalah, dan menyelesaikan masalah. Detail sebenarnya dapat membuat segalanya menjadi lebih buruk karena orang dapat salah menafsirkan hal-hal yang masuk akal bagi pengembang. Pemrogram dan orang yang paham teknologi hampir secara universal bukan target demografis untuk sebagian besar aplikasi, sangat mengecewakan semua orang di sini ... :)
enderland

12

Itu tergantung pada siapa pengguna, dan apa yang dapat mereka lakukan dengan informasi tersebut.

Umumnya, coba perlihatkan kepada mereka hanya informasi yang berguna tentang hal-hal yang dapat mereka selesaikan sendiri. Jejak tumpukan 40 baris dengan kesalahan ekspresi reguler di bagian atas tidak terlalu berguna. Jauh lebih baik pesan yang mengatakan Date harus diformat sebagai "yyyy-mm-dd" . Ada hal lain, dan pengguna mungkin tidak tahu bagaimana menanggapi kesalahan, dan kemudian mereka mungkin tidak ingin menggunakan aplikasi Anda, karena takut itu akan menyebabkan lebih banyak kesalahan samar dan menakutkan (dan ya, pengguna non-teknis kadang-kadang takut dengan tumpukan jejak). Dan itu mungkin buruk untuk bisnis.

Untuk aplikasi internal yang digunakan oleh pengembang lain, saya sedikit lebih santai tentang menampilkan jejak tumpukan, selain sesuatu yang lebih berguna , karena saya tahu pengguna dapat menangani melihat jejak tumpukan dan mungkin akan tahu apa yang harus dilakukan tentang itu.

Untuk pengguna non-teknis, satu-satunya waktu saya pikir itu tidak apa-apa untuk menunjukkan kepada mereka jejak stack adalah dalam situasi kesalahan kritis di mana Anda membutuhkannya untuk menyelesaikan masalah, dan mereka diminta untuk menyalin dan menempelkan jejak stack dan mengirimkannya bagi Anda, meskipun cara yang jauh lebih baik untuk melakukannya adalah dengan meminta mereka mengirim file log, atau lebih baik lagi, meminta aplikasi mengirim file log kepada pengembang, setelah meminta izin kepada pengguna untuk membagikan file tersebut.


5
Saya tidak akan setuju dengan aplikasi yang mengirim log di mana saja tanpa bertanya kepada saya. Sebagai gantinya, dialog pesan kesalahan harus menyediakan opsi untuk melaporkan kesalahan. Pengguna harus dapat meninjau setiap dan semua info, termasuk jejak tumpukan, sebelum mengirim laporan.
piedar

1
@ Piedar: Itu poin yang bagus.
FrustratedWithFormsDesigner

4
@piedar: Memiliki tombol "Lihat lebih detail" di dialog kesalahan, atau tautan ke file log aplikasi mungkin merupakan cara yang baik untuk menyajikan semua detail berdarah kepada pengguna yang menginginkan informasi itu. Bahkan kotak centang "tampilkan perincian secara default", jika Anda ingin kesulitan mengodekannya. Tetapi tidak semua pengguna ingin melihatnya, dan beberapa pengguna akan dimatikan oleh hal itu.
FrustratedWithFormsDesigner

2
@ Paddy: Anda benar, tetapi: 1) Ini contohnya. : P 2) Mungkin saya sudah memperbaiki dan membersihkan kode seperti itu, yang mengapa itu segar di pikiran saya ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "Dan jika dia adalah pengembang, dia dapat mereplikasi bug" .. - oh, andai saja itu benar :(
Blorgbeard

1

Pesan untuk pengguna harus diperlakukan dengan cara yang sama seperti membuat pengecualian baru untuk dilempar - Anda memberikan informasi yang mereka butuhkan untuk memutuskan apa yang harus dilakukan.

Ini tentu saja akan tergantung pada aplikasi Anda dan basis pengguna, tetapi harus menjadi prinsip panduan Anda - maksud Anda adalah untuk memberikan informasi yang diperlukan untuk "penelepon" untuk menentukan apa, jika ada, yang dapat mereka lakukan untuk berhasil melakukan tindakan yang diinginkan . Jika itu sesuatu yang sederhana seperti kesalahan akses ke file, Anda memberikan path file dan pesan bahwa Anda tidak dapat mengaksesnya. Jika pengecualian null pointer, cukup berikan pesan kesalahan umum.

Tentu saja akan ada lebih banyak pesan "tidak dapat melakukan tindakan yang diinginkan" daripada akan ada pesan yang benar-benar dapat diperbaiki pengguna, tetapi itu hanya hidup - sebagian besar pengecualian adalah karena kami membuat kesalahan, bukan karena pengguna mengatur lingkungan salah.


1

Ini adalah tema umum:

Bagaimana Anda dapat membantu orang yang kurang informasi / komputer yang buta huruf pada saat yang sama dengan menunjukkan informasi yang dapat digunakan oleh pengguna yang lebih mahir seperti programmer, pengembang, penguji, dll.

Saya pikir jawabannya adalah Anda melakukan keduanya!

Urutan ini penting dan saya sarankan Anda memiliki:

  • Apa yang terjadi.
  • Apa yang harus dilakukan sekarang
  • Detail Teknis

Detail Teknis adalah bagian yang memiliki informasi untuk pesanan lanjutan atau untuk pengguna reguler saat melaporkan masalah


0

Apa yang ingin Anda perlihatkan tergantung pada seberapa malu Anda karena mengacau.

Intinya adalah untuk mendapatkan rincian kegagalan dukungan teknis secepat dan semulus mungkin. Itu mungkin berarti Anda mengirim file log termasuk jejak tumpukan kesalahan penghentian kembali ke rumah secara otomatis atau Anda meminta pengguna untuk mengklik tombol yang akan memulai transfer. Mungkin melalui USB stick jika tidak ada koneksi internet.


0

Saya suka alasan di balik jawaban yang diterima, tetapi saya harus dengan hormat tidak setuju setidaknya dengan interpretasi saya membatasi informasi untuk apa yang "dapat ditindaklanjuti" . Saya ingin tahu sedikit lebih dari itu sebagai pengguna daripada "kesalahan tak terduga" .

Dan memang saya sedikit mengerti komputer dan saya memiliki bias itu, tetapi saya tidak berpikir ini adalah pandangan yang sangat bias. Karena saya dapat mencoba yang terbaik untuk menghapus bias itu dengan menerapkan pola pikir ini ke domain yang saya tidak memiliki banyak keahlian, seperti penerbangan.

Sementara saya hanya tahu sedikit tentang penerbangan, katakanlah penerbangan saya ditunda atau dibatalkan dan satu-satunya yang staf katakan adalah, "Kami memiliki kesalahan tak terduga. Harap tunggu 3 jam untuk penerbangan berikutnya." Setidaknya Anda akan menemukan saya sedikit lebih banyak dari pelanggan yang tidak puas dalam kasus-kasus itu karena, meskipun itu tidak benar-benar memengaruhi tindakan saya, saya hanya ingin tahu sedikit lebih banyak tentang mengapa saya menjadi tidak nyaman dengan cara ini sebagai pelanggan yang membayar.

Jika mereka hanya berkata seperti, "Kami mengalami cuaca yang bergejolak," atau "Kami memiliki keadaan darurat medis dalam penerbangan kami sebelumnya," atau kerusakan peralatan atau apa pun, itu cukup bagi saya untuk bersimpati lebih dari "kesalahan tak terduga" dan menjadi sedikit lebih banyak konten duduk-duduk dan menunggu 3 jam untuk penerbangan berikutnya. Sebenarnya saya bahkan mungkin lebih suka beberapa masalah teknis yang melampaui kepala saya untuk "kesalahan tak terduga" seperti, "Baiklah, kata-kata yang keluar dari mulut Anda masuk ke telinga saya tetapi tidak mencapai prosesor pusat. Tapi saya mengerti sekarang bahwa ada semacam masalah di sana dan aku pergi mengambil kopi dan duduk di sana! Semoga kalian menyelesaikan masalah itu dengan halamajig itu! "

Dan seringkali dalam hal penanganan pengecualian, saya pikir Anda biasanya memiliki cukup informasi dasar semacam itu tentang apa yang terjadi di catchsitus, bahkan jika Anda ingin menyembunyikan detail yang lebih teknis dari pengecualian, seperti:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

Dan itu bahkan tidak menampilkan apa yang berpotensi menjadi informasi yang sangat teknis yang melekat pada pengecualian, tetapi setidaknya memberi tahu kita lebih dari sekadar "kesalahan tak terduga". Paling tidak memberikan "apa / di mana / kapan" kontekstual bahkan jika itu tidak mengatakan "mengapa / bagaimana". Saya pikir setidaknya keinginan untuk tingkat informasi dasar ini tidak terlalu bias oleh komputer saya.

Sisanya mungkin sangat spesifik untuk pelanggan Anda dan kebutuhan tertentu. Tetapi daya tarik saya setidaknya untuk sesuatu yang sedikit lebih dari "kesalahan tak terduga".


Yah, itu adalah pandangan yang bias. Rata-rata pengguna tidak peduli mengapa mereka tidak bisa melakukan apa yang tidak bisa mereka lakukan. Mereka hanya peduli apakah dan bagaimana mereka dapat memperbaiki masalah mereka.
gnasher729

"Rata-rata pengguna tidak peduli mengapa mereka tidak bisa melakukan apa yang tidak bisa mereka lakukan. Mereka hanya peduli apakah dan bagaimana mereka dapat memperbaiki masalah mereka." Jika rata-rata pengguna bahkan tidak mengerti seperti apa file atau server itu, mungkin begitu, tetapi itu mungkin masih terkait dengan apa yang "dapat ditindaklanjuti", karena mereka mungkin dapat menyentuh bahu Anda dan berkata, "Hei , aplikasi ini mengatakan tidak dapat menemukan file konfigurasi yang diperlukan ini ", atau sesuatu untuk efek ini, di mana Anda mungkin dapat kemudian mencari masalah dan dengan cepat memperbaikinya untuk mereka, misalnya
Dragon Energy
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.