Bao nhiêu thông tin về một lỗi nên được hiển thị cho người dùng?


38

Các ứng dụng luôn có thể ném lỗi. Nếu xảy ra lỗi như vậy, người dùng nên được thông báo, vì những gì anh ta yêu cầu ứng dụng thực hiện đã không thành công.

Tuy nhiên, người dùng nên cung cấp bao nhiêu thông tin? Tôi nghĩ rằng hầu hết chúng ta đều đồng ý không hiển thị dấu vết ngăn xếp (Có nên theo dõi ngăn xếp trong thông báo lỗi cho người dùng không? ), Nhưng tôi không thể tìm thấy câu hỏi về phần còn lại của nội dung lỗi hoặc nội dung hiển thị cho người sử dụng.

Ví dụ: một ngôn ngữ hỗ trợ các ngoại lệ (.net, java) có loại ngoại lệ để chia sẻ, trong đó xảy ra ngoại lệ và một thông báo có phần rõ ràng đi kèm với ngoại lệ. Điều này cũng nên được ẩn khỏi người dùng? Hay chúng ta nên thể hiện điều này? Hay chúng ta nên hiển thị một thông điệp chung chung? hoặc chúng ta nên hiển thị một trong số một số tin nhắn dựa trên ngoại lệ cơ bản là gì?

Câu trả lời:


34

Những gì cần hiển thị cho người dùng. Điều này cũng nên được ẩn khỏi người dùng?

Bạn cho người dùng thấy những gì có thể hành động cho họ.

Ví dụ: nếu bạn có lỗi xảy ra do một số ngoại lệ con trỏ null và nhiều lỗi hơn lỗi người dùng, bạn không muốn giải thích đầy đủ vì họ không thể làm gì khác.

Hay chúng ta nên thể hiện điều này? Hay chúng ta nên hiển thị một thông điệp chung chung?

Hiển thị ngoại lệ vì nội dung thông báo lỗi chính là vô nghĩa đối với hầu hết người dùng . Có lẽ nếu cơ sở người dùng mục tiêu của bạn là nhà phát triển, bạn có thể hiển thị thông tin là lỗi đầy đủ mọi lúc (có thể bạn có một ứng dụng nội bộ để kiểm tra tự động). Nhưng nhìn chung người dùng không thể làm bất cứ điều gì khác biệt ngay cả với kiến ​​thức đó.

chúng ta có nên hiển thị một trong số một số tin nhắn dựa trên ngoại lệ cơ bản là gì không?

Chiến lược tốt nhất là làm như sau:

  • Giải thích lỗi thành văn bản có ý nghĩa đối với người dùng.
    • Một phần của điều này là "những gì người dùng có thể làm khác nhau?"
    • Nếu họ không thể làm gì khác, hãy nói điều gì đó như "một lỗi không mong muốn đã xảy ra."
  • Thêm một mô tả lỗi chi tiết "tùy chọn"
  • Cho phép người dùng gửi báo cáo lỗi (hoặc thực hiện việc này tự động, tùy thuộc vào cơ sở người dùng)

Thí dụ

nhập mô tả hình ảnh ở đây

  1. Nó hiển thị "đây là những gì đã xảy ra" (lỗi không mong muốn)
  2. Cho người dùng biết phải làm gì (mở lại Mail, thậm chí bao gồm một phím tắt để làm điều này)
  3. Cũng có "xem chi tiết" nếu ai đó tò mò muốn xem lỗi kỹ thuật đầy đủ
  4. Cung cấp thông báo một báo cáo lỗi được nộp (xem bên dưới)

Lưu ý rằng trong một số trường hợp, bạn có thể muốn báo cáo lỗi thành thủ công so với tự động.


20
Tôi không đồng ý. Không có gì khá khó chịu như một ứng dụng in "lỗi đã xảy ra." vào màn hình và sau đó thoát ra. Bất cứ khi nào điều đó xảy ra, tôi luôn tự hỏi tại sao nhà phát triển lại lười biếng đến mức in một thông điệp không chính xác như vậy. Giải thích điều gì đó cho người dùng để họ có thể hiểu những gì đã sai trong một nghĩa chung, ngay cả khi họ không thể làm gì về điều đó. Trường hợp tốt nhất, họ có thể Google thông báo lỗi và có thể tìm ra giải pháp mà người khác đã mô tả, điều này gần như không thể nếu mọi lỗi khác nhau in cùng một thông báo chung.
Jon Bentley

3
@JonBentley Bạn đang xem nó như một nhà phát triển, người muốn hiểu thứ này. Người dùng trung bình sẽ đơn giản trở nên lo lắng rằng họ nên hiểu nó, điều mà họ không cần phải làm.
deworde

12
@deworde Ngược lại, tôi đang xem nó như một người dùng . Là người dùng, tôi không muốn hiểu về thuật ngữ kỹ thuật, nhưng tôi muốn có đủ thông tin mà tôi không cảm thấy như người viết phần mềm là không đủ năng lực ("đã xảy ra lỗi" mang lại ấn tượng rằng nhà phát triển đã không ' Tôi không biết họ đang làm gì) và để tôi có thể tìm kiếm câu trả lời. Nếu mỗi một sự cố đều nói rằng "một lỗi đã xảy ra" thì một tìm kiếm Google sẽ không giúp tôi. Một thông điệp duy nhất cho mỗi tình huống có nhiều khả năng đưa tôi đến một diễn đàn nơi người khác có cùng vấn đề và có thể giải quyết nó.
Jon Bentley

3
@JonBentley một vài điểm để xem xét. Đầu tiên, điểm chính của câu trả lời này là bạn cung cấp cho người dùng thông tin hành động. Nếu đó là một lỗi họ có thể sửa chữa cần phải cho họ biết thông tin để giải quyết. Điều này rơi vào You show the user what is actionable for them. Nếu bạn biết nguyên nhân của vấn đề, thì bạn sẽ hiển thị cho người dùng trong phần mô tả. Nhưng nói chung nếu bạn biết lý do của một lỗi, bạn sẽ biết giải quyết vấn đề để thông báo cho người dùng một cách thích hợp.
enderland

2
Thứ hai, bạn đánh giá quá cao khả năng trung bình của người dùng để tự giải quyết vấn đề. Phần lớn dân số áp đảo là điều mà hầu hết các nhà phát triển / lập trình viên / người dùng Stack Exchange sẽ gọi là máy tính không biết chữ. Hầu hết những người này khá thẳng thắn không được trang bị để chẩn đoán, khắc phục sự cố và giải quyết vấn đề. Chi tiết thực sự có thể làm cho mọi thứ tồi tệ hơn bởi vì mọi người có thể hiểu sai những điều sẽ hoàn toàn có ý nghĩa với các nhà phát triển. Các lập trình viên và những người am hiểu công nghệ hầu như không phải là nhân khẩu học mục tiêu cho hầu hết các ứng dụng, gây thất vọng cho tất cả mọi người ở đây ... :)
enderland

12

Nó phụ thuộc vào người dùng là ai và họ có thể làm gì với thông tin.

Nói chung, cố gắng chỉ cho họ thấy thông tin hữu ích về những điều họ có thể tự giải quyết. Dấu vết ngăn xếp 40 dòng với lỗi biểu thức chính quy ở trên cùng không hữu ích lắm. Tốt hơn nhiều sẽ là một thông báo nói rằng Ngày phải được định dạng là "yyyy-mm-dd" . Bất cứ điều gì khác và người dùng có thể không biết cách phản hồi lỗi và sau đó họ có thể không muốn sử dụng ứng dụng của bạn, vì sợ nó sẽ gây ra nhiều lỗi khó hiểu và đáng sợ hơn (và vâng, người dùng không có kỹ thuật đôi khi sợ hãi bởi stack dấu vết). Và điều đó có thể xấu cho kinh doanh.

Đối với các ứng dụng nội bộ được sử dụng bởi các nhà phát triển khác, tôi sẽ thoải mái hơn một chút về việc hiển thị theo dõi ngăn xếp, ngoài ra còn có ích hơn , vì tôi biết người dùng có thể xử lý khi nhìn thấy dấu vết ngăn xếp và có thể sẽ biết phải làm gì về nó.

Đối với người dùng không có kỹ thuật, lần duy nhất tôi nghĩ sẽ ổn khi hiển thị cho họ dấu vết ngăn xếp trong tình huống lỗi nghiêm trọng khi bạn cần giải quyết vấn đề và họ được yêu cầu sao chép và dán dấu vết ngăn xếp và gửi nó Đối với bạn, mặc dù thực sự là một cách tốt hơn để làm là yêu cầu họ gửi tệp nhật ký, hoặc tốt hơn là yêu cầu ứng dụng gửi tệp nhật ký cho nhà phát triển, sau khi yêu cầu người dùng cho phép chia sẻ tệp.


5
Tôi sẽ không ổn với một ứng dụng gửi nhật ký ở bất cứ đâu mà không hỏi tôi. Thay vào đó, hộp thoại thông báo lỗi sẽ cung cấp tùy chọn báo cáo lỗi. Người dùng sẽ có thể xem lại bất kỳ và tất cả thông tin, bao gồm cả dấu vết ngăn xếp, trước khi gửi báo cáo.
piedar

1
@piedar: Đó là một điểm tốt.
Thất

4
@piedar: Có nút "Xem thêm chi tiết" trong hộp thoại lỗi hoặc liên kết đến tệp nhật ký ứng dụng có lẽ là một cách tốt để trình bày tất cả các thông tin chi tiết cho những người có quyền lực muốn biết thông tin đó. Ngay cả hộp kiểm "hiển thị chi tiết theo mặc định", nếu bạn muốn gặp rắc rối khi mã hóa nó. Nhưng không phải tất cả người dùng sẽ muốn thấy điều đó, và một số người dùng sẽ bị tắt bởi điều đó.
Thất

2
@Paddy: Bạn đã đúng, nhưng: 1) Đó là một ví dụ. : P 2) Có lẽ tôi đã sửa và dọn sạch mã như vậy, đó là lý do tại sao nó mới trong tâm trí của tôi ...
Thất

2
@NateKerkhofs "Và nếu anh ấy là nhà phát triển, anh ấy có thể sao chép lỗi" .. - ồ, nếu đó là sự thật :(
Blorgbeard

1

Tin nhắn cho người dùng nên được xử lý theo cách tương tự như tạo một ngoại lệ mới để ném - bạn cung cấp thông tin họ sẽ cần để quyết định phải làm gì.

Tất nhiên điều này sẽ phụ thuộc vào ứng dụng và cơ sở người dùng của bạn, nhưng đó phải là hiệu trưởng chính của bạn - mục đích của bạn là cung cấp thông tin cần thiết cho "người gọi" để xác định xem, nếu có bất cứ điều gì, họ có thể làm gì để thực hiện thành công hành động mong muốn . Nếu đó là một cái gì đó đơn giản như lỗi truy cập vào một tệp, bạn đưa ra đường dẫn tệp và thông báo mà bạn không thể truy cập được. Nếu đó là một ngoại lệ con trỏ null, chỉ cần đưa ra một thông báo lỗi chung.

Tất nhiên, sẽ có nhiều thông báo "không thể thực hiện hành động mong muốn" hơn những tin nhắn mà người dùng thực sự có thể sửa, nhưng đó chỉ là cuộc sống - hầu hết các trường hợp ngoại lệ là do chúng tôi đã nhầm lẫn, không phải vì người dùng thiết lập môi trường không chính xác


1

Đây là một chủ đề phổ biến:

Làm thế nào bạn có thể giúp người không biết chữ / máy tính không biết chữ đồng thời hiển thị thông tin mà người dùng cao cấp hơn như lập trình viên, nhà phát triển, người kiểm tra, v.v. có thể sử dụng.

Tôi nghĩ rằng câu trả lời là bạn làm cả hai!

Thứ tự là quan trọng mặc dù và tôi khuyên bạn nên có:

  • Chuyện gì đã xảy ra.
  • làm gì bây giờ
  • Chi tiết kỹ thuật

Chi tiết kỹ thuật là phần có thông tin cho các đơn đặt hàng nâng cao hoặc cho người dùng thường xuyên khi báo cáo sự cố


0

Những gì bạn muốn thể hiện phụ thuộc vào mức độ xấu hổ của bạn khi làm hỏng việc.

Vấn đề là để có được các chi tiết của sự thất bại để hỗ trợ kỹ thuật càng nhanh và trơn tru càng tốt. Điều đó có thể có nghĩa là bạn tự động gửi tệp nhật ký bao gồm cả dấu vết ngăn xếp của lỗi kết thúc trở về nhà hoặc bạn vui lòng yêu cầu người dùng nhấp vào nút sẽ bắt đầu chuyển. Có thể thông qua thẻ nhớ USB nếu không có kết nối internet.


0

Tôi thích lý do đằng sau câu trả lời được chấp nhận, nhưng tôi phải tôn trọng ít nhất là không đồng ý với cách giải thích của tôi về việc giới hạn thông tin ở mức "có thể hành động" . Tôi muốn biết một chút ít hơn một chút so với người dùng hơn là "lỗi không mong muốn" .

Và phải thừa nhận rằng tôi là một người am hiểu máy tính một chút và tôi có sự thiên vị đó, nhưng tôi không nghĩ rằng đây là một quan điểm đặc biệt thiên vị. Bởi vì tôi có thể cố gắng hết sức để loại bỏ sự thiên vị đó bằng cách áp dụng tư duy này vào các lĩnh vực mà tôi có ít chuyên môn, như hàng không.

Mặc dù tôi biết rất ít về hàng không, nói rằng chuyến bay của tôi bị hoãn hoặc hủy và điều duy nhất nhân viên nói với tôi là "Chúng tôi đã có một lỗi không mong muốn. Vui lòng đợi 3 giờ cho chuyến bay tiếp theo." Ít nhất bạn sẽ tìm cho tôi thêm một chút khách hàng bất mãn trong những trường hợp đó bởi vì, mặc dù điều đó không thực sự ảnh hưởng đến quá trình hành động của tôi, tôi chỉ muốn biết thêm một chút về lý do tại sao tôi là bất tiện theo cách này như một khách hàng trả tiền.

Nếu họ chỉ nói như: "Chúng tôi đang trải qua thời tiết hỗn loạn" hoặc "Chúng tôi đã có một trường hợp khẩn cấp y tế trong chuyến bay trước của chúng tôi", hoặc một sự cố thiết bị hoặc bất cứ điều gì, điều đó đủ để tôi thông cảm nhiều hơn "lỗi bất ngờ" và có thêm một chút nội dung ngồi xung quanh và chờ 3 giờ cho chuyến bay tiếp theo. Trên thực tế, tôi thậm chí có thể thích một số kỹ thuật công nghệ vượt qua "lỗi không mong muốn" như "Được rồi, những lời phát ra từ miệng bạn đang đi vào tai tôi nhưng không đến được bộ xử lý trung tâm. Nhưng giờ tôi đã hiểu vấn đề ở đó và tôi sẽ lấy một ít cà phê và ngồi ở đó! Hy vọng các bạn sẽ giải quyết vấn đề đó với điều đó! "

Và thường là về mặt xử lý ngoại lệ, tôi nghĩ bạn thường có đủ loại thông tin cơ bản về những gì đã xảy ra trên catchtrang web, ngay cả khi bạn muốn ẩn các chi tiết kỹ thuật của ngoại lệ, như:

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

Và điều đó thậm chí không hiển thị những gì có khả năng là thông tin kỹ thuật được đính kèm ngoại lệ, nhưng ít nhất nó cũng cho chúng ta biết nhiều hơn là "lỗi không mong muốn". Nó ít nhất cung cấp một "cái gì / ở đâu / khi nào" theo ngữ cảnh ngay cả khi nó không nói "tại sao / như thế nào". Tôi nghĩ rằng ít nhất mong muốn về mức độ thông tin cơ bản này không bị thiên vị máy tính của tôi thiên vị.

Phần còn lại có lẽ là rất cụ thể cho khách hàng và nhu cầu cụ thể của bạn. Nhưng sự hấp dẫn của tôi ít nhất là đối với một cái gì đó chỉ là một chút tuổi teen hơn là "lỗi không mong muốn".


Vâng, đó một quan điểm thiên vị. Người dùng trung bình không quan tâm đến lý do tại sao họ không thể làm những gì họ không thể làm. Họ chỉ quan tâm liệu và làm thế nào họ có thể khắc phục vấn đề của họ.
gnasher729

"Người dùng trung bình không quan tâm đến lý do tại sao họ không thể làm những gì họ không thể làm. Họ chỉ quan tâm liệu họ có thể khắc phục vấn đề của mình hay không." Nếu người dùng bình thường thậm chí không hiểu tập tin hoặc máy chủ là gì, có lẽ vậy, nhưng điều đó vẫn có thể liên kết với những gì "có thể hành động" sau đó, bởi vì họ có thể chạm vào vai bạn và nói, "Này , ứng dụng này cho biết họ không thể tìm thấy điều này đòi hỏi tập tin cấu hình", hoặc một cái gì đó để tác động này, nơi bạn có thể có thể sau đó tìm kiếm các vấn đề và nhanh chóng sửa chữa nó cho họ, ví dụ
Rồng Energy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.