it-swarm-vi.com

Bạn có chắc chắn muốn trả lời câu hỏi này?

Tất cả chúng ta đều đã thấy những loại cảnh báo này: "Bạn có chắc chắn muốn tắt Windows không?"

Tôi nghe thấy rất nhiều người bực bội trả lời: "Vâng, tất nhiên, nếu không tôi sẽ không nhấp vào nó!"


Những loại tin nhắn cảnh báo này có thể rất khó chịu, nhưng nó cũng có thể giúp bạn tránh mất dữ liệu.

Trong các phiên bản Windows hiện đại, Microsoft đã loại bỏ thông báo cảnh báo này. Nhưng trong nhiều phần mềm và trên nhiều trang web, chúng ta vẫn thấy các loại cảnh báo sau:

  • "Bạn có muốn lưu công việc của bạn?"
  • "Bạn có muốn đóng tất cả các tab?" (điều mà một số trình duyệt yêu cầu, trong khi một số trình duyệt thì không).

Cách thực dụng để giải quyết vấn đề nan giải này sẽ là nói :

" nhiều người cố tình bấm vào một nút và chỉ một vài người vô tình bấm vào nút, do đó, thông báo cảnh báo sẽ bị xóa. " (mà tôi nghe thấy nhiều). Nhưng đây có phải là cách suy nghĩ đúng đắn?

Vì vậy, câu hỏi là:

Có bất kỳ nghiên cứu hoặc chẩn đoán nào về việc sử dụng thông điệp cảnh báo khi nào và ở đâu và làm thế nào chúng ta có thể ngăn chặn việc sử dụng chúng (nếu đó là ưu tiên)? Ngoài ra tôi tò mò muốn đọc ý kiến ​​của bạn!


Câu trả lời

Hiện tại, câu trả lời của steveverrill về hộp kiểm "không hiển thị lại thông báo này" là giải pháp dễ dàng và an toàn nhất.

Trong một số trường hợp (có thể trong tương lai khi máy tính tiên tiến hơn), các nút tự động lưu và/hoặc khôi phục có thể là một giải pháp tốt hơn. Kiểm tra những câu trả lời cũng nghĩ ra quá!

140
Max de Mooij

Đúng. Có một heuristic rất đơn giản, hiệu quả, điều chỉnh theo sở thích của từng người dùng.

Đặt một hộp kiểm trong hộp thoại thông báo cảnh báo có nội dung:

Đừng hiển thị tin nhắn này một lần nữa

Mà có thể được cải thiện hơn nữa bằng cách nêu nơi hộp thoại đó có thể được kích hoạt lại.

140
Level River St

Đây là các thông báo Xác nhận - Windows có trang khá chi tiết theo hướng dẫn của họ . Toàn bộ trang đó khá hữu ích nhưng đây là một số trích đoạn (nhấn mạnh của tôi):

Xác nhận là hữu ích nhất khi hành động yêu cầu người dùng đưa ra lựa chọn phù hợp và khác biệt mà không thể thực hiện sau này. Sự lựa chọn đó thường liên quan đến một số yếu tố rủi ro không rõ ràng đối với người dùng, nhưng rủi ro không phải là điều cần thiết để xác nhận. Các yếu tố này là cần thiết để chứng minh sự gián đoạn của việc trả lời hộp thoại phương thức.

(Không nhấn mạnh thêm từ tôi cho bên dưới):

Đây có phải là giao diện người dùng phải không?

Để quyết định, hãy xem xét những câu hỏi sau:

  • Là người dùng đang được hỏi một câu hỏi để tiến hành một hành động có hai hoặc nhiều câu trả lời? Nếu không, tin nhắn không phải là một xác nhận.
  • Là giao diện người dùng trình bày một lỗi hoặc vấn đề đã xảy ra? Nếu vậy, sử dụng một thông báo lỗi thay thế.
  • Việc tiến hành hành động có yêu cầu người dùng đưa ra lựa chọn không có mặc định phù hợp không? Nếu vậy, một xác nhận có thể là phù hợp.
  • Có một thiết kế thay thế mà loại bỏ sự cần thiết phải xác nhận? Sự cần thiết phải xác nhận đôi khi chỉ ra một lỗ hổng thiết kế. Thường có một sự thay thế thiết kế tốt hơn mà không cần xác nhận.
  • Là người dùng sắp thực hiện một hành động rủi ro? Nếu vậy, một xác nhận là phù hợp nếu hành động có hậu quả đáng kể hoặc không thể dễ dàng hoàn tác.
  • Là người dùng sắp từ bỏ một nhiệm vụ? Nếu vậy, đừng xác nhận. Giả sử người dùng hiểu hậu quả của việc không hoàn thành một nhiệm vụ.
  • Liệu hành động có hậu quả mà người dùng có thể không nhận thức được? Nếu vậy, một xác nhận có thể là phù hợp.
  • Với bối cảnh hiện tại, người dùng có thể đang thực hiện một hành động bị lỗi không? Nếu vậy, một xác nhận có thể là phù hợp.
  • Người dùng có thực hiện hành động thường xuyên không? Nếu vậy, hãy xem xét một thiết kế thay thế. Xác nhận thường xuyên gây phiền nhiễu và có ít giá trị vì người dùng học cách phản hồi mà không cần suy nghĩ.
  • Liệu hành động có ý nghĩa bảo mật? Nếu vậy, một xác nhận có thể được yêu cầu ngay cả khi các thử nghiệm trước đó cho thấy khác.

...

Hãy xem xét các phương án thiết kế

Dưới đây là một số lựa chọn thay thế thiết kế loại bỏ sự cần thiết phải xác nhận thông lệ:

  • Ngăn ngừa lỗi. Thiết kế các tác vụ sao cho những lỗi đáng kể rất khó thực hiện. Ví dụ, tách biệt các lệnh phá hủy vật lý khỏi các lệnh khác và yêu cầu nhiều hành động để hoàn thành.
  • Cung cấp hoàn tác. Cung cấp khả năng hoàn nguyên các hành động. Ví dụ: xóa một tệp trong Microsoft Windows thường không yêu cầu xác nhận vì các tệp đã xóa có thể được phục hồi từ Thùng rác. Lưu ý rằng nếu một hành động rất dễ thực hiện, chỉ cần người dùng làm lại hành động đó là đủ.
  • Cung cấp phản hồi. Làm cho kết quả không mong muốn trở nên rõ ràng. Cung cấp hoàn tác một mình là không đủ nếu người dùng không nhận ra khi họ mắc lỗi. Ví dụ, hiệu ứng của thao tác trực tiếp (chẳng hạn như thao tác kéo và thả) phải luôn rõ ràng.
  • Giả sử kết quả có thể xảy ra, nhưng giúp bạn dễ dàng thay đổi. Nếu bạn không chắc chắn người dùng muốn gì nhưng có một sự lựa chọn an toàn, an toàn và an toàn , giả sử lựa chọn đó, làm cho nó rõ ràng những gì đã xảy ra và làm cho nó dễ dàng thay đổi bằng cách sử dụng menu ngữ cảnh. Ví dụ: Microsoft Word giả định rằng người dùng muốn đánh vần các từ chính xác. Nếu nó nhận ra một từ sai chính tả và nó biết chính tả có khả năng đúng, Word sẽ tự động sửa nhưng cho phép người dùng hoàn nguyên.
  • Loại bỏ hoàn toàn lựa chọn. Nếu lựa chọn không quan trọng, người dùng sẽ không quan tâm. Tốt hơn để đơn giản hóa chương trình của bạn và loại bỏ sự lựa chọn.

Chỉnh sửa:

Ngoài ra, điều mà tôi nghĩ cũng đáng được đề cập từ một trang riêng trên nguyên tắc UI được lấy từ nhiều cuốn sách khác nhau nói về người dùng mới làm quen :

10. Nguyên tắc an toàn

...

Người dùng Novice cần được đảm bảo rằng họ sẽ được bảo vệ khỏi sự thiếu kỹ năng của chính họ. Một chương trình không có mạng lưới an toàn sẽ khiến loại người dùng này cảm thấy khó chịu hoặc bực bội đến mức họ có thể ngừng sử dụng chương trình. "Bạn có chắc không?" hộp thoại và các tính năng hoàn tác đa cấp rất quan trọng đối với loại người dùng này.

Nguyên tắc của Apple dường như không có bất kỳ nguyên tắc nào về thời điểm, chỉ "không sử dụng quá mức" :

Khi có thể người dùng không biết rằng hành động của họ có thể có hậu quả tiêu cực, có thể thích hợp để diễn đạt thông điệp cảnh báo dưới dạng câu hỏi. Ví dụ: một câu hỏi như là Bạn có chắc chắn muốn xóa lịch sử không? xác định chính xác hành động người dùng đã thực hiện và nhắc họ xem xét kết quả. Tuy nhiên, don lồng quá lạm dụng loại cảnh báo này; Người dùng mệt mỏi nhanh chóng khi được hỏi liệu họ có chắc chắn họ muốn làm gì đó không.

Thiết kế tài liệu của Google gợi ý rằng bạn chỉ nên sử dụng chúng cho các tình huống rủi ro cao và sử dụng một câu hỏi rõ ràng thay vì 'bạn có chắc không ? ' (đó rõ ràng là what bạn nên viết, thay vì khi):

Cảnh báo với thanh tiêu đề

Chỉ sử dụng cảnh báo trên thanh tiêu đề cho các tình huống rủi ro cao, chẳng hạn như mất khả năng kết nối. Người dùng có thể hiểu các lựa chọn chỉ dựa trên tiêu đề và văn bản nút.

Nếu một tiêu đề là bắt buộc:

  • Sử dụng một câu hỏi hoặc tuyên bố rõ ràng với lời giải thích trong khu vực nội dung, chẳng hạn như "Xóa bộ nhớ USB?".
  • Tránh những lời xin lỗi, sự mơ hồ hoặc những câu hỏi, chẳng hạn như Cảnh báo trên mạng! hoặc bạn có chắc không?

Google design screenshot

60
icc97

Tôi ngạc nhiên không ai đưa ra hộp thoại tắt Mac OS X. Nó trình bày cho bạn một "Bạn có chắc không?" cửa sổ, nhưng có một bộ đếm thời gian để nếu người dùng bỏ đi, hy vọng máy tính sẽ tắt, nó sẽ vẫn cho phép người dùng có thời gian để hủy bỏ.

29
sneelhorses

Có 3 trường hợp.

Hành động phá hoại

Bạn có muốn xóa tập tin này?

Đừng. Chỉ cần thực hiện hành động và hiển thị xác nhận snackbar (không chặn tiện ích nhỏ ở nơi có thể nhìn thấy nhưng không theo cách vận hành) cho phép hủy (sau đó, trì hoãn hành động hoặc thực hiện chắc chắn bạn có thể hoàn nguyên nó một cách dễ dàng).

Câu hỏi chỉ có thể được trả lời bởi người dùng. ví dụ.

Bạn có muốn cho phép ứng dụng này truy cập bất cứ điều gì?

Lần đầu tiên, hiển thị một cửa sổ bật lên. Nếu bạn sử dụng "Đừng hỏi lại tôi", hãy đảm bảo rằng việc thay đổi ý định của họ là cực kỳ dễ dàng. Google gợi ý một thanh đồ ăn nhẹ cho phép không phô trương người dùng để thay đổi cài đặt đó sau đó.

Các hành động cam kết

Tắt máy tính? Gửi email này? Xuất bản bài viết này?

Phụ thuộc vào bạn khả năng để hủy bỏ hành động. Một số tùy chọn có sẵn. Trong thứ tự ưu tiên:

  1. Trì hoãn hành động để cung cấp cho người dùng thời gian để hủy bỏ.
  2. Hãy chắc chắn rằng bạn có thể hoàn tác bất cứ điều gì đã được thực hiện. (ví dụ: khởi động lại phần mềm nhanh chóng và khôi phục trạng thái trước đó)
  3. Yêu cầu xác nhận. Cố gắng tránh làm điều đó. Nó gây phiền nhiễu hầu hết thời gian và hiếm khi hữu ích.
14
njzk2

Tôi là một người ủng hộ lớn không hiển thị các tin nhắn chặn người dùng thực hiện những gì họ dự định làm. Giải pháp UX với cửa sổ bật lên xác nhận xuất phát từ thời kỳ đồ đá UX của máy tính. Nó bắt nguồn từ một giả định chính xác rằng nếu chúng ta có một tài nguyên quan trọng, chúng ta không nên để người dùng làm hỏng nó do tai nạn. Tuy nhiên, một tai nạn được gọi theo cách đó vì nó xảy ra hiếm khi . Điều này có nghĩa là trong phần lớn các trường hợp xác nhận chỉ là một sự lãng phí của một nhấp chuột.

Tuy nhiên, chúng tôi phải bảo vệ người dùng khỏi tai nạn. Vì vậy, cách đúng đắn để làm điều này là lưu trạng thái hiện tại trong ngăn xếp hoàn tác, tiến hành thao tác, nhưng sau đó cho phép người dùng hủy hoặc hoàn tác nó. Tôi sẽ xem xét giải pháp này giống như một hướng dẫn hơn là một quy tắc, nhưng tôi chắc chắn rằng nó có thể được áp dụng cho nhiều trường hợp.

Chẳng hạn, trong trường hợp tắt máy Apple lưu trạng thái hiện tại cho tất cả các ứng dụng của bạn. Khi bạn bật nguồn trở lại, bạn quay lại công việc của mình như thể bạn chưa tắt máy.

Nếu một hoạt động có thể phá hủy tài nguyên quan trọng không thể đảo ngược (ví dụ: xóa thứ gì đó trong ứng dụng bên 3d qua API), sau đó lên lịch hành động để bắt đầu trong tương lai gần nhất, giả sử trong 60 giây, nhưng hãy để người dùng hủy nó, nếu họ muốn.

Điều đó nói rằng, tôi nghĩ rằng trong hầu hết các trường hợp các loại xác nhận này là không cần thiết.

9
mikryz