Làm sao để người dùng đọc thông báo lỗi?

Nếu bạn lập trình cho đối tượng phi kỹ thuật, bạn sẽ có nguy cơ cao rằng người dùng sẽ không đọc các thông báo lỗi được diễn đạt cẩn thận và giác ngộ của bạn, mà chỉ cần nhấp vào nút đầu tiên có sẵn với một sự thất vọng.

Vì vậy, tôi tự hỏi những thực hành tốt nào bạn có thể đề xuất để giúp người dùng thực sự đọc thông báo lỗi của bạn, thay vì chỉ đơn giản là bỏ qua một bên. Những ý tưởng tôi có thể nghĩ ra sẽ rơi vào dòng:

• Định dạng của khóa học giúp đỡ; có thể là một tin nhắn đơn giản, ngắn, với nút "tìm hiểu thêm" dẫn đến thông báo lỗi dài hơn, chi tiết hơn
• Có tất cả các thông báo lỗi liên kết đến một số phần của hướng dẫn sử dụng (hơi khó đạt được)
• Chỉ không phát hành thông báo lỗi, chỉ cần từ chối thực hiện tác vụ (một cách hơi "Apple" để xử lý dữ liệu nhập của người dùng)

Chỉnh sửa: đối tượng tôi có trong tâm trí là một cơ sở người dùng khá rộng, không sử dụng phần mềm quá thường xuyên và không bị giam cầm (nghĩa là không có phần mềm nội bộ hoặc cộng đồng hẹp). Một dạng chung hơn của câu hỏi này đã được hỏi trên slashdot , vì vậy bạn có thể muốn kiểm tra ở đó để biết một số câu trả lời.

Đó là một câu hỏi xuất sắc xứng đáng với +1 từ tôi. Câu hỏi mặc dù đơn giản, bao gồm nhiều khía cạnh về bản chất của người dùng cuối. Nó tập trung vào một số yếu tố ở đây sẽ có lợi cho bạn và chính phần mềm, và tất nhiên cho người dùng cuối.

• Không đặt các thông báo lỗi trong thanh trạng thái - họ sẽ không bao giờ đọc chúng mặc dù nó có màu sắc nổi bật v.v .... họ sẽ luôn nhớ chúng! Cho dù bạn có cố gắng đến mức nào ... Ở một giai đoạn trong quá trình kiểm tra giao diện người dùng Win 95 trước khi được khởi chạy, MS đã thực hiện một thử nghiệm để đọc UI ( ed - cần lưu ý rằng thông báo được nêu rõ trong ngữ cảnh của 'Nhìn dưới ghế' ), với một tờ 100 đô la được dán vào mặt dưới của chiếc ghế mà các đối tượng đang ngồi ... không ai phát hiện ra thông điệp trên thanh trạng thái!
• Làm cho các tin nhắn ngắn, không sử dụng các từ đáng sợ như 'Thông báo: hệ thống gặp sự cố', người dùng cuối sẽ nhấn nút hoảng loạn và sẽ phản ứng quá mức ...
• Cho dù bạn cố gắng thế nào, đừng sử dụng màu sắc để xác định thông điệp ... về mặt tâm lý, nó giống như vẫy cờ đỏ cho con bò!
• Sử dụng các từ nghe trung tính để truyền đạt phản ứng tối thiểu và cách tiến hành!
• Có thể tốt hơn để hiển thị hộp thoại liệt kê thông báo lỗi trung tính và bao gồm hộp kiểm cho biết 'Bạn có muốn xem thêm các thông báo lỗi này trong tương lai không?', Điều cuối cùng mà người dùng cuối muốn, là làm việc ở giữa phần mềm bị bắn phá với các thông báo bật lên, chúng sẽ bị thất vọng và sẽ bị ứng dụng tắt! Nếu hộp kiểm được đánh dấu, hãy đăng nhập nó vào một tệp thay vì ...
• Thông báo cho người dùng cuối về thông báo lỗi nào sẽ có ... ngụ ý ... đào tạo và tài liệu ... bây giờ đây là một mẹo khó để vượt qua ... bạn không muốn họ nghĩ rằng sẽ có là 'vấn đề' hoặc 'trục trặc' và phải làm gì trong trường hợp đó ... họ không được biết rằng sẽ có những lỗi có thể xảy ra, thực sự khó khăn.
• Luôn luôn, luôn luôn, không ngại yêu cầu phản hồi khi điều không hay xảy ra - chẳng hạn như 'Khi lỗi số 1304 xuất hiện, bạn đã phản ứng như thế nào? Giải thích của bạn là gì '- phần thưởng với điều đó, người dùng cuối có thể cung cấp cho bạn một lời giải thích mạch lạc hơn thay vì' Lỗi 1304, đối tượng cơ sở dữ liệu bị mất! ', Thay vào đó họ có thể nói' Tôi đã nhấp vào đây và do đó, sau đó ai đó đã vô tình kéo cáp mạng của máy ', điều này sẽ gợi ý cho bạn về việc phải xử lý nó và có thể sửa đổi lỗi để nói' Ooops, Kết nối mạng bị ngắt kết nối '... bạn bị trôi.
• Cuối cùng nhưng không kém phần quan trọng, nếu bạn muốn nhắm mục tiêu đối tượng quốc tế, hãy tính đến việc quốc tế hóa các thông báo lỗi - vì vậy đó là lý do để giữ cho nó trung lập, bởi vì sau đó sẽ dễ dịch hơn, tránh các từ đồng nghĩa, từ lóng, v.v. bản dịch vô nghĩa - ví dụ, Fiat Ford, công ty xe hơi đang bán thương hiệu Fiat Ford Pinto của họ, nhưng nhận thấy không có doanh số nào xảy ra ở Nam Mỹ, hóa ra, Pinto là tiếng lóng ở đó cho 'dương vật nhỏ' và do đó không bán được ...
• ( ed ) Tài liệu danh sách các thông báo lỗi dự kiến ​​trong một phần riêng biệt của tài liệu có tiêu đề 'Thông báo lỗi' hoặc 'Hành động khắc phục' hoặc tương tự, liệt kê các số lỗi theo đúng thứ tự với một hoặc hai tuyên bố về cách tiến hành. ..
• ( ed ) Cảm ơn Victor Hurdugaci vì sự đóng góp của anh ấy, hãy giữ các thông điệp lịch sự, đừng khiến người dùng cuối cảm thấy ngu ngốc. Điều này đi ngược lại câu trả lời của Jack Marchetti nếu cơ sở người dùng là quốc tế ...

Chỉnh sửa: Một lời cảm ơn đặc biệt đến gnibbler , người đã đề cập đến một điểm cực kỳ quan trọng khác!

• Cho phép người dùng cuối có thể chọn / sao chép thông báo lỗi để họ có thể nếu họ muốn, gửi email cho nhóm hỗ trợ hoặc nhóm phát triển.

Chỉnh sửa # 2: xấu của tôi! Rất tiếc, nhờ DanM đã đề cập rằng về chiếc xe, tôi đã nhầm lẫn tên, đó là Ford Pinto ... xấu của tôi ...

Chỉnh sửa # 3: Đã đánh dấu bằng ed để chỉ ra các bổ sung hoặc phụ lục và ghi có cho người khác cho đầu vào của họ ...

Chỉnh sửa # 4: Đáp lại bình luận của Ken - đây là của tôi ... Không, không, hãy sử dụng các màu Windows tiêu chuẩn trung tính ... đừng dùng màu sắc lòe loẹt! Giữ màu nền xám bình thường với văn bản màu đen, đây là hướng dẫn GUI tiêu chuẩn thông thường trong thông số kỹ thuật của Microsoft..xem Hướng dẫn UX ( ed ).

Nếu bạn khăng khăng với màu sắc lòe loẹt, ít nhất, hãy tính đến những người dùng mù màu tiềm năng, nghĩa là khả năng truy cập là một yếu tố quan trọng khác đối với những người khuyết tật, thông báo lỗi thân thiện với độ phóng đại màn hình, mù màu, những người mắc bệnh bạch tạng, họ có thể nhạy cảm với màu sắc lòe loẹt, và động kinh cũng ... những người có thể bị một màu đặc biệt có thể gây ra cơn động kinh ...

Cho họ xem tin nhắn. Do dilligence và tất cả, nhưng đăng nhập mọi lỗi vào một tập tin. Người dùng không thể nhớ những gì họ đã làm hoặc thông báo lỗi là vài giây sau sự kiện, nó giống như tài khoản chứng kiến ​​bằng mắt của người điều trị nội trú.

Cung cấp một cách tốt để cho phép họ gửi email hoặc tải lên nhật ký cho bạn để bạn có thể hỗ trợ họ giải quyết vấn đề. Nếu đó là một ứng dụng web: thậm chí tốt hơn, bạn có thể nhận được thông tin về tình huống trước bất kỳ ai thậm chí báo cáo vấn đề.

Câu trả lời ngắn gọn: Bạn không thể.

Câu trả lời ít ngắn hơn: Làm cho chúng hiển thị, có liên quan và theo ngữ cảnh (làm nổi bật những gì chúng gây rối). Tuy nhiên, bạn vẫn đang chiến đấu một trận thua. Mọi người không đọc trên màn hình máy tính, họ quét và họ đã được đào tạo để nhấp vào nút cho đến khi hộp thoại biến mất.

Chúng tôi đặt một hình ảnh dễ nhớ đơn giản vào hộp lỗi: không phải là biểu tượng, bitmap khá lớn và không có gì giống như các biểu tượng thông báo Windows tiêu chuẩn. Không ai có thể nhớ từ ngữ của hộp thông báo (hầu hết sẽ không đọc nó nếu hộp có nút "OK" mà họ có thể nhấn), nhưng hầu hết mọi người đều nhớ hình ảnh họ nhìn thấy. Vì vậy, những người hỗ trợ của chúng tôi có thể hỏi khách hàng "bạn có thấy anh chàng uống cà phê không?" hoặc "bạn có thấy cái bàn trống không?". Ít nhất theo cách đó chúng ta biết đại khái những gì đã sai.

Tùy thuộc vào cơ sở người dùng của bạn, viết thông báo lỗi hài hước / thô lỗ / cá nhân có thể hoạt động tốt.

Chẳng hạn, tôi đã viết một ứng dụng cho phép nhân sự của chúng tôi theo dõi tốt hơn ngày thuê / ngày của nhân viên. [chúng tôi là một công ty nhỏ, rất thoải mái].

Khi họ nhập sai ngày tôi sẽ viết:

Này mông đần, học cách nhập ngày!

EDIT: Tất nhiên một thông điệp hữu ích hơn là nói: "Vui lòng nhập ngày dưới dạng mm / dd / yyyy" hoặc có thể trong mã để thử và tìm ra những gì họ đã nhập và nếu họ nhập "blahblah" để hiển thị lỗi. Tuy nhiên, đây là một ứng dụng rất nhỏ cho một người nhân sự mà tôi biết. Do đó một lần nữa mọi người, hãy đọc dòng đầu tiên của bài đăng này: Tùy thuộc vào cơ sở người dùng của bạn ...

Gần đây tôi đã làm việc trong một dự án của Viện Nghệ thuật, vì vậy các thông báo lỗi được hướng đến khán giả, chẳng hạn như:

Hầu hết nghệ thuật trước thời kỳ Baroque là không dấu. Tuy nhiên, hiện tại chúng ta đã vượt ra khỏi thời kỳ Baroque, vì vậy tất cả các lĩnh vực phải được hoàn thành.

Về cơ bản, hãy hướng nó đến đối tượng của bạn nếu có thể, và tránh nhàm chán vì tất cả các lỗi chung không rõ ràng như: "vui lòng nhập email" hoặc "vui lòng nhập email hợp lệ".

Cảnh báo / cửa sổ bật lên gây phiền nhiễu, đó là lý do tại sao mọi người nhấn nút đầu tiên họ nhìn thấy.

Làm cho nó bớt khó chịu . Ví dụ: nếu người dùng nhập ngày không chính xác hoặc nhập văn bản có số lượng dự kiến, thì KHÔNG bật lên một tin nhắn, chỉ cần tô sáng trường và viết tin nhắn ở đâu đó xung quanh nó.

Tạo một hộp thông báo tùy chỉnh . Đừng bao giờ sử dụng hộp thông báo mặc định của hệ thống, ví dụ hộp thông báo Windows XP gây phiền nhiễu cho chính họ. Tạo một hộp thông báo màu mới, với màu nền khác với mặc định của hệ thống.

Rất quan trọng: đừng nhấn mạnh . Một số hộp thông báo sử dụng hộp thoại Modal và khăng khăng bắt bạn đọc nó, điều này rất khó chịu. Nếu bạn có thể làm cho hộp thông báo xuất hiện dưới dạng thông báo cảnh báo thì sẽ tốt hơn, ví dụ, thông báo Stack Overflow xuất hiện ngay trên đầu trang, thông báo nhưng không gây khó chịu.

CẬP NHẬT
Làm cho thông điệp có ý nghĩa và hữu ích . Ví dụ: không viết một cái gì đó như "Không tìm thấy Bàn phím, nhấn F1 để tiếp tục."

Thiết kế UI tốt nhất sẽ là nơi bạn hầu như không bao giờ hiển thị thông báo lỗi. Phần mềm nên thích ứng với người dùng. Với kiểu thiết kế đó, một thông báo lỗi sẽ là tiểu thuyết và sẽ thu hút sự chú ý của người dùng. Nếu bạn tiêu người dùng bằng các hộp thoại vô nghĩa như thế thì bạn rõ ràng đang đào tạo họ để bỏ qua tin nhắn của bạn.

Theo quan điểm và kinh nghiệm của tôi, đó là người dùng quyền lực, những người không đọc thông báo lỗi. Khán giả phi kỹ thuật mà tôi biết đọc mọi thông điệp trên màn hình một cách cẩn thận nhất và vấn đề ở thời điểm này chủ yếu là: Họ không hiểu nó.

Điểm này có thể là nguyên nhân của trải nghiệm của bạn, bởi vì đến một lúc nào đó họ sẽ ngừng đọc chúng, bởi vì "dù sao họ cũng không hiểu", vì vậy nhiệm vụ của bạn rất dễ dàng:

Làm cho thông báo lỗi dễ hiểu nhất có thể và giữ phần kỹ thuật dưới mui xe.

Ví dụ tôi chuyển một tin nhắn như thế này:

ORA-00237: thao tác chụp nhanh không được phép: tệp điều khiển mới được tạo Nguyên nhân: Một nỗ lực gọi cfileMakeAndUseSnapshot với tệp điều khiển hiện được gắn mới được tạo bằng CREATE CONTROLFILE đã được thực hiện. Hành động: Gắn tệp điều khiển hiện tại và thử lại thao tác.

đến một cái gì đó như:

Bước này không thể được xử lý do các vấn đề nhất thời với cơ sở dữ liệu. Vui lòng liên hệ (quản trị viên của bạn | bộ phận trợ giúp | bất kỳ ai có thể liên hệ với nhà phát triển hoặc quản trị viên để giải quyết vấn đề). Xin lỗi vì sự bất tiện.

Cho người dùng thấy rằng thông báo lỗi có ý nghĩa và đó là cách để cung cấp hỗ trợ cho họ và họ sẽ đọc nó. Nếu đó chỉ là thông điệp vô nghĩa hoặc chung chung, họ sẽ học cách loại bỏ chúng một cách kỳ quặc.

Tôi đã học được rằng nên bao gồm một hộp thoại lỗi với hành động mặc định để gửi (ví dụ: qua email) thông tin chẩn đoán chi tiết, nếu bạn nhanh chóng trả lời những email đó với thông tin có giá trị hoặc cách giải quyết, họ sẽ tôn thờ bạn.

Đây cũng là một công cụ học tập tuyệt vời. Trong các phiên bản trong tương lai, bạn có thể giải quyết các vấn đề đã biết hoặc ít nhất là cung cấp thông tin giải pháp tại chỗ. Cho đến lúc đó, người dùng sẽ biết rằng thông báo này là do X gây ra và vấn đề có thể được giải quyết bằng Y - tất cả là do ai đó đã giải thích cho họ.

Tất nhiên, điều này sẽ không hoạt động trên một ứng dụng quy mô lớn, nhưng hoạt động rất tốt trong các ứng dụng doanh nghiệp với vài trăm người dùng và nhanh nhẹn, phát hành sớm thường xuyên, môi trường.

BIÊN TẬP:

Vì bạn có một cơ sở người dùng rộng rãi, tôi khuyên bạn nên cung cấp phần mềm thực hiện những gì người dùng đang / có thể mong đợi nó làm, ví dụ. không hiển thị cho họ tin nhắn eroror nếu số điện thoại không được định dạng tốt, định dạng lại nếu cho họ.

Cá nhân tôi thích phần mềm không khiến tôi phải suy nghĩ và đôi khi không có gì bạn (nhà phát triển) có thể làm để giải thích ý định của tôi, cung cấp một thông điệp được viết rất tốt (và được xem xét bởi người dùng thực tế).

Đó là kiến ​​thức phổ biến rằng mọi người không đọc tài liệu (bạn đã đọc hướng dẫn quay lại làm gì khi bạn cắm thiết bị gia dụng chưa?), Họ thử cách để có kết quả nhanh chóng, khi thất bại bạn phải thu hút sự chú ý của họ (ví dụ: tắt nút mặc định trong một thời gian) với thông tin có ý nghĩa và hữu ích . Bây giờ họ không quan tâm đến lỗi phần mềm của bạn, họ muốn có kết quả.

Làm cho họ vui vẻ . (Có vẻ như có liên quan, với trang web chúng tôi đang truy cập :))

Để bắt đầu, viết thông báo lỗi mà người dùng thực sự có thể hiểu. "Lỗi: 1023" không phải là ví dụ hay. Tôi nghĩ cách tốt hơn là ghi nhật ký lỗi, hơn là hiển thị nó cho người dùng với một số mã "ưa thích". Hoặc nếu không thể đăng nhập, hãy cung cấp cho người dùng cách thích hợp để gửi chi tiết lỗi đến bộ phận hỗ trợ.

Ngoài ra, hãy ngắn gọn và rõ ràng. Không bao gồm một số chi tiết kỹ thuật. Không cho họ thấy thông tin mà họ không thể sử dụng. Nếu có thể cung cấp một cách giải quyết cho lỗi. Nếu không cung cấp một tuyến đường mặc định, điều đó nên được thực hiện.

Nếu ứng dụng của bạn là một ứng dụng web, thiết kế các trang lỗi tùy chỉnh là một ý tưởng tốt. Họ nhấn mạnh người dùng ít hơn, lấy SO làm ví dụ. Bạn có thể nhận được một số ý tưởng làm thế nào để thiết kế một trang lỗi tốt ở đây: http://www.smashingmagazine.com/2007/07/25/wocate-your-404-error-pages/

Một điều tôi muốn thêm vào.

Sử dụng động từ cho các nút hành động của bạn để đóng thông báo lỗi thay vì cảm thán, ví dụ không sử dụng "Ok!" "Đóng", v.v.

Một mẹo hay mà tôi đã học được là bạn nên viết một hộp thoại như một bài báo. Không phải theo nghĩa kích thước, mà theo nghĩa quan trọng. Hãy để tôi giải thích.

Bạn nên viết những điều quan trọng nhất để đọc, đầu tiên và cung cấp thông tin chi tiết hơn thứ hai.

Nói cách khác, điều này là không tốt:

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?

Thay vào đó, thay đổi thứ tự:

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.

Bằng cách này, người dùng có thể đọc nhiều như anh ta muốn, hoặc cả hai, và vẫn có một ý tưởng về những gì được hỏi.

Xem thêm phản hồi của người dùng Slashdot tại đây .

Trừ khi bạn có thể cung cấp cho người dùng một số cách giải quyết đơn giản, đừng bận tâm hiển thị cho người dùng một thông báo lỗi. Không có điểm nào, vì 90% người dùng sẽ không quan tâm đến những gì nó nói.

Mặt khác, nếu bạn thực sự CÓ THỂ hiển thị cho người dùng một cách giải quyết hữu ích, thì một cách để buộc họ đọc nó là làm cho nút OK được bật sau 10 giây hoặc lâu hơn. Sắp xếp cách Firefox làm điều đó bất cứ khi nào bạn đang cố gắng cài đặt một trình cắm mới.

Nếu đó là một sự cố hoàn toàn mà bạn không thể phục hồi một cách duyên dáng, thì hãy thông báo cho người dùng bằng các điều khoản rất giáo dân nói rằng:

" Tôi xin lỗi, chúng tôi đã làm hỏng, chúng tôi muốn gửi một số thông tin về vụ tai nạn này, bạn có cho phép chúng tôi làm như vậy không? CÓ / KHÔNG "

Ngoài ra, cố gắng không làm cho thông báo lỗi của bạn dài hơn một câu. Khi mọi người (bao gồm cả tôi) nhìn thấy cả một đoạn nói về lỗi, tâm trí tôi chỉ tắt.

Với quá nhiều phương tiện truyền thông xã hội và quá tải thông tin, tâm trí mọi người đóng băng khi họ nhìn thấy một bức tường văn bản.

BIÊN TẬP:

Ai đó một lần gần đây cũng đề nghị sử dụng các mẩu truyện tranh cùng với bất kỳ thông điệp nào bạn muốn hiển thị. Chẳng hạn như một cái gì đó từ Dilbert có thể gần với loại lỗi bạn có thể có.

Từ kinh nghiệm của tôi: bạn không được người dùng (đặc biệt là những người không có kỹ thuật) đọc thông báo lỗi. Cho dù thông điệp rõ ràng và dễ hiểu, đậm, đỏ và nhấp nháy như thế nào, mà bạn hiển thị, hầu hết người dùng sẽ chỉ nhấp vào bất cứ thứ gì họ không quen, ngay cả khi đó là "Bạn có thực sự muốn xóa mọi thứ không?". Tôi đã thấy người dùng nhấp vào "đóng cửa sổ" -icon thay vì "OK" hoặc "hủy" mặc dù họ thậm chí không biết họ đã chọn tùy chọn nào bằng cách làm như vậy ...

Nếu bạn thực sự cần buộc người dùng đọc những gì bạn đang hiển thị, tôi sẽ đề xuất Đếm ngược JavaScript cho đến khi có thể nhấp vào nút. Bằng cách đó, người dùng hy vọng sẽ sử dụng thời gian chờ đợi để thực sự đọc những gì anh ta cần phải làm. Hãy cẩn thận: hầu hết người dùng sẽ khó chịu hơn nữa :)

Hơn nữa, tôi thích ý tưởng của bạn về một liên kết "đọc thêm", mặc dù tôi nghi ngờ rằng điều đó sẽ khiến người dùng quan tâm hơn mà chỉ muốn loại bỏ tin nhắn bằng mọi cách ...

Chỉ để ghi lại: có những người dùng KHÔNG đọc thông báo lỗi nhưng rất sợ rằng họ sẽ không làm gì với nó. Tôi đã từng có một cuộc gọi hỗ trợ nơi khách hàng sẽ đọc một thông báo lỗi cho tôi, hỏi tôi, anh ta nên làm gì. "Chà, lựa chọn của bạn là gì?", Tôi hỏi. "Cửa sổ chỉ có nút 'OK'.", Anh trả lời. ... mmh, khó quá :)

Tôi thường hiển thị lỗi màu đỏ (khi thiết kế cho phép).

Màu đỏ là viết tắt của "cảnh báo", vv vì vậy nó thường được đọc hơn.

Chà, để trả lời trực tiếp câu hỏi của bạn: Đừng để lập trình viên viết thông báo lỗi của bạn. Nếu bạn làm theo một lời khuyên này, bạn sẽ tiết kiệm được, tích lũy, hàng ngàn giờ cho người dùng và năng suất và hàng triệu đô la chi phí hỗ trợ kỹ thuật.

Tuy nhiên, mục tiêu thực sự là thiết kế ứng dụng của bạn để người dùng không thể mắc lỗi. Đừng để họ thực hiện các hành động dẫn đến mát xa lỗi và yêu cầu họ sao lưu. Ví dụ đơn giản, trong một biểu mẫu web yêu cầu tất cả các trường của nó được điền vào, thay vì bật lên một thông báo lỗi khi người dùng nhấp vào nút Gửi, không bật nút Gửi cho đến khi tất cả các trường có chứa nội dung hợp lệ. Nó có nghĩa là nhiều công việc hơn ở mặt sau, nhưng nó mang lại trải nghiệm người dùng tốt hơn.

Tất nhiên, đó là một chút của một thế giới lý tưởng. Đôi khi, lỗi chương trình là không thể tránh khỏi. Khi chúng xảy ra, bạn cần cung cấp thông tin rõ ràng, đầy đủ và hữu ích, và quan trọng nhất là không để hệ thống cho người dùng và không đổ lỗi cho người dùng về hành động của họ.

Một thông báo lỗi tốt nên chứa:

1. Vấn đề là gì và tại sao nó lại xảy ra.
2. Làm thế nào để giải quyết vấn đề.

Một trong những điều tồi tệ nhất bạn có thể làm chỉ đơn giản là truyền thông báo lỗi hệ thống cho người dùng. Ví dụ, khi chương trình Java của bạn đưa ra một ngoại lệ, đừng đơn giản chuyển giao trình lập trình cho UI và hiển thị nó cho người dùng. Hãy nắm bắt nó và có một thông điệp rõ ràng được tạo bởi nhà phát triển hỗ trợ người dùng của bạn mà bạn có thể trình bày cho người dùng của mình.

Tôi đã rất may mắn, trong công việc cuối cùng của mình, được làm việc với một nhóm lập trình viên, những người sẽ không nghĩ đến việc viết thông báo lỗi của riêng họ. Bất cứ khi nào họ thấy mình rơi vào tình huống bắt buộc và chương trình không thể được thiết kế để tránh điều đó (thường là do nguồn lực hạn chế), họ luôn tìm đến tôi, giải thích những gì họ cần và để tôi tạo một thông báo lỗi đã rõ ràng và theo phong cách công ty. Nếu đó là suy nghĩ mặc định của mọi lập trình viên, thế giới điện toán sẽ là một nơi tốt hơn rất nhiều.

Ít lỗi hơn

Nếu một ứng dụng ném nôn vào bạn một cách thường xuyên, bạn sẽ miễn nhiễm với nó và các lỗi trở thành muzak khó chịu. Nếu một lỗi là một sự kiện hiếm gặp, nó sẽ thu hút được nhiều sự chú ý hơn.

Quosh bất cứ điều gì không phải là một vấn đề lớn, đưa ra tất cả những cảnh báo đó, tìm cách hiểu ý định của người dùng, đưa ra quyết định bất cứ khi nào có thể. Tôi có một vài ứng dụng mà tôi tiếp tục hợp lý hóa theo cách này. Các nhà phát triển xem mọi lỗi đều quan trọng, nhưng điều này không đúng với quan điểm người dùng. Tìm kiếm phản hồi chung của người dùng đối với một vấn đề và nắm bắt vấn đề đó, triển khai đó là phản hồi của bạn .

Nếu bạn cần phải đưa ra một lỗi: yếu tố khủng bố ngắn, súc tích, thấp, không có dấu chấm than. Đoạn văn thất bại .

Không có viên đạn bạc, nhưng bạn cần phải có kỹ sư xã hội để làm cho các lỗi quan trọng.

Chúng tôi đã nói với người dùng rằng người quản lý của họ đã được liên lạc (đó là một lời nói dối). Nó hoạt động hơi quá tốt và phải được gỡ bỏ.

Thêm nút "Nâng cao" cho phép thêm một số chi tiết kỹ thuật sẽ cung cấp khuyến khích đọc nó cho một phần của đối tượng mục tiêu tự cho là kỹ thuật

Tôi khuyên bạn nên đưa ra phản hồi (nói rằng người dùng đã mắc lỗi) ngay sau khi xảy ra lỗi. (Ví dụ: khi nhập giá trị của trường ngày, hãy kiểm tra giá trị và nếu sai, hãy làm cho trường đầu vào khác biệt trực quan).

Nếu có lỗi trên trang (tôi thích phát triển web hơn, do đó tôi gọi nó là "trang", nhưng nó cũng có thể được gọi là "biểu mẫu"), hiển thị "tóm tắt lỗi", giải thích rằng có là các lỗi và một danh sách gạch đầu dòng chính xác những gì đã xảy ra lỗi. Tuy nhiên, nếu có nhiều hơn 5-6 từ trên mỗi tin nhắn, chúng sẽ không được đọc / hiểu.

Làm thế nào về việc làm cho nút trạng thái "Nhấp vào đây để nói chuyện với kỹ thuật viên hỗ trợ, người sẽ hỗ trợ bạn về vấn đề này."

Có rất nhiều trang web cung cấp tùy chọn để nói chuyện với một người thực sự.

Tôi đã đọc một ứng cử viên cho giải pháp khủng khiếp nhất trên slashdot:

Chúng tôi đã phát hiện ra rằng cách duy nhất để khiến người dùng chịu trách nhiệm về lỗi là cung cấp cho họ một hình phạt để buộc lỗi biến mất. Đối với người mới bắt đầu, nếu có thể, lỗi sẽ không thực sự đóng cho họ trừ khi chúng tôi nhập mật khẩu quản trị viên để biến mất và nếu họ khởi động lại để loại bỏ nó (Trình quản lý tác vụ bị vô hiệu hóa trên tất cả các PC khách), máy sẽ không mở ứng dụng bị sập trong 15 phút. Tất nhiên, tất cả phụ thuộc vào loại người dùng mà bạn đang giao dịch, vì những người dùng lão luyện hơn về mặt kỹ thuật sẽ không chấp nhận loại hệ thống này, nhưng sau khi thử NĂM theo nghĩa đen để khiến người dùng chịu trách nhiệm về sự cố và đảm bảo bộ phận CNTT biết để khắc phục sự cố trước khi quá khó quản lý, đây là những bước duy nhất có hiệu quả. Hiện nay,

"ATTENTION! ATTENTION! Nếu bạn không đọc thông báo lỗi, bạn S DI DIE!"

Bất chấp tất cả các khuyến nghị trong câu trả lời được chấp nhận, người dùng của tôi vẫn tiếp tục nhấp vào nút đầu tiên họ có thể tìm thấy. Vì vậy, bây giờ tôi hiển thị điều này:

Người dùng có để thực hiện một sự lựa chọn trước khi xuất hiện nút OK

Nếu anh ta chọn tùy chọn thứ 3, anh ta có thể tiếp tục, nếu không thì ứng dụng sẽ thoát.