it-swarm-vi.com

Tôi nên sử dụng Có / Không hoặc Ok / Hủy trên hộp tin nhắn của mình?

Về mặt ngữ nghĩa, các nút Có/Không gần tương đương với các nút Ok/Hủy, nhưng nói chung bạn muốn sử dụng loại nào? Tôi nên luôn luôn sử dụng Có/Không hoặc luôn luôn sử dụng Ok/Hủy? Hay nó phụ thuộc vào trường hợp?

335
laurent

Không bao giờ sử dụng 'Có' hoặc 'OK' khi bạn có thể sử dụng động từ thay thế.

Và bạn có thể hầu như luôn luôn sử dụng động từ thay vì 'Có' hoặc 'OK'.

Tôi đồng ý với định đề của Lukas Mathis rằng không ai đọc hộp thoại của bạn . Sử dụng một động từ bất cứ khi nào có thể thay vì 'Có' hoặc 'OK' vì các nút của bạn sẽ có ý nghĩa ngoài ngữ cảnh với văn bản hoặc tiêu đề giải thích. Đây là chế độ xem được củng cố thêm trong hướng dẫn giao diện người dùng của Microsoft :

Nếu bạn muốn đảm bảo rằng người dùng đọc văn bản cụ thể liên quan đến một hành động, hãy đặt nó trên một điều khiển tương tác.

Có thể chấp nhận:

Trong ví dụ này, có khả năng người dùng sẽ không đọc văn bản giải thích những gì họ đang xác nhận.

Tốt hơn:

enter image description here

Trong ví dụ này, bạn có thể chắc chắn rằng ít nhất người dùng hiểu rằng họ sắp định dạng đĩa.

Apple Nguyên tắc giao diện con người mở rộng hơn nữa, khuyến nghị các động từ nhiều từ thay vì các nút "OK" hoặc "Có" và xác định rõ các vùng được đề xuất cho hộp cảnh báo:

Apple's human interface guidelines on alert boxes

Họ khuyên chỉ nên sử dụng hộp cảnh báo ở nơi đầu tiên nếu hành động không thể hoàn tác. Về chủ đề nhãn nút, họ cung cấp điều này:

Đảm bảo rằng tên nút mặc định tương ứng với hành động bạn mô tả. Đặc biệt, đó là một ý tưởng tốt để tránh sử dụng OK cho nút mặc định. Ý nghĩa của OK có thể không rõ ràng ngay cả trong các cảnh báo hỏi liệu người dùng có chắc chắn họ muốn làm gì đó không. Ví dụ: OK có nghĩa là OK OK, tôi muốn hoàn thành hành động của mình hoặc hay OK, bây giờ tôi đã hiểu kết quả tiêu cực mà hành động của tôi sẽ gây ra cho Tử?

Sử dụng tên nút tập trung hơn, chẳng hạn như Xóa, Chuyển đổi, Xóa hoặc Xóa, giúp đảm bảo rằng người dùng hiểu hành động mà họ thực hiện.

Nói tóm lại, ngay cả khi có vẻ như các tùy chọn hợp lý hoặc hợp lý nhất là cung cấp cho người dùng nút "Có" hoặc "Không" (ví dụ: "Bạn có chắc chắn muốn đăng xuất không?"), Bạn hầu như luôn có thể sử dụng động từ hoặc cụm từ thay thế.

"Bạn có muốn đăng xuất không?"
[.__.] [Đăng xuất] -hoặc- [Hủy]

Theo cách này, người dùng không cần phải đọc tiêu đề hoặc văn bản giải thích để hiểu cách tiến hành và ý nghĩa của việc nhấp vào một trong hai nút có thể bị hiểu sai.

Cũng lưu ý rằng, được đưa ra lựa chọn giữa 'Không' và 'Hủy', 'Hủy' hầu như luôn luôn tốt hơn vì những lý do chính xác như trên: ý nghĩa của 'Hủy' là rõ ràng ngay cả khi người dùng không đọc phần còn lại của hộp thoại. Ý nghĩa của 'Không' là có lẽ rõ ràng, nhưng ít ý nghĩa hơn khi được ghép nối với một động từ (ví dụ: 'Đăng xuất' và 'Hủy' có nghĩa là đọc một mình hơn là 'Đăng xuất' và ' Không').

477
Nick

Việc sử dụng các từ ngắn như Có/Không trên các nút có thể gây nhầm lẫn nếu người dùng đọc sai tin nhắn trên hộp thoại, đặc biệt là nếu các tin nhắn được viết xấu. (Vì vậy, hãy giữ thông điệp ngắn gọn và rõ ràng ngay từ đầu)

yes/nook/cancel thực sự buộc người dùng phải phải đọc và hiểu thông điệp trước khi biết các tùy chọn áp dụng cho. Đối với người dùng quen thuộc với một sản phẩm, họ thà tự quét các nút hơn là đọc tin nhắn.

Vì vậy, cách tiếp cận tôi muốn thực hiện là xác nhận hành động dài dòng hơn một chút so với OK (Ví dụ: Save changes, Add user, Update password) sao cho nó rất rõ ràng những gì bạn sắp làm. Và sau đó giữ Cancel như hiện tại - một lối thoát ngắn và quen thuộc , đặc biệt là sau đó nên rõ ràng rằng đó là ' Đừng làm tùy chọn hành động.

Ngay cả một câu hỏi đơn giản như bạn có chắc chắn muốn đăng xuất , (nếu thực sự bắt buộc ở vị trí đầu tiên) nên có các nút Log outCancel thay vì Yes/Cancel hoặc Yes/No.

Bằng cách này, người dùng có thể nhanh chóng quét các nút và nhận Gist về những gì họ cần nhấp ngay cả khi không đọc tin nhắn.


Chỉnh sửa - Với tham chiếu đến các nhận xét ở trên về câu trả lời của greengit, đây là một ví dụ từ Skype, về những gì không để làm:

enter image description here

83
Roger Attrill

Một hộp thoại xác nhận (một câu hỏi đặt câu hỏi và không có đầu vào) nên có/không. Ví dụ...

  • Bạn có muốn hủy tài khoản của mình - yesno

  • Bạn có muốn đăng xuất - yesno

Mặt khác, một hộp thoại đại diện cho một "hành động" và mong đợi đầu vào của người dùng, nên có ok/hủy hoặc <hành động>/hủy. Ví dụ...

  • Đặt ngày và giờ sự kiện ... okcancel

  • Thêm một liên hệ mới ... addcancel

  • Cập nhật mật khẩu của bạn ... updatecancel

  • Thay đổi múi giờ của bạn ... donecancel

47
treecoder

Nút Ok/Hủy và Có/Không chỉ được chấp nhận khi bạn quá lười biếng để nghĩ ra một nhãn tốt hơn cho hành động.

Một ví dụ về hộp thoại xác nhận tốt:

  1. Đây là LibreScript/OpenOffice khi bạn cố đóng tài liệu chưa được lưu:

enter image description here

nhãn của nút sẽ phản ánh hành động nào sẽ được thực hiện.

Ngoài ra, không bao giờ gọi bất kỳ hành động nào, chẳng hạn như "hủy đăng ký"/"đóng" tài khoản, là "hủy" để tránh sự mơ hồ với nút hủy. Nghĩa là, nút hủy là một bến cảng an toàn mà người dùng có thể nhấp vào phản xạ mà không có điều gì xấu xảy ra, đừng khiến người dùng sợ hãi khi nhấp vào nút "Hủy".

Lấy ví dụ về greengit, đây là những gì tôi muốn đề xuất cho mỗi người trong số họ:

Do you want to delete your account -- "Delete account" "Cancel"

Do you want to sign out -- don't even ask this since signing out 
                           is a non-destructive action, if the user 
                           has an unsaved work and signing out could 
                           lead to loss of unsaved work, then you have 
                           two options: ask whether they want to discard 
                           the unsaved work, or automatically save the 
                           work as a draft.

Set event date and time -- "Set time" "Cancel". Although since this is a 
                           non-destructive action, you should probably not 
                           need to ask confirmation and just apply the 
                           action immediately with a "Revert" button.

Add a new contact -- Don't ask for confirmation to "Add", when the user 
                     entered the "Add contact" form and doesn't quit 
                     immediately, they already confirmed that they wanted 
                     to add a contact; automatically save the contact's 
                     information when the user finish entering the 
                     contact's information. Also you might want to have a 
                     "Revert" or "Discard" button.

Update your password -- "Update Password" "Cancel"

Change your timezone -- "Set Timezone" "Cancel". The same with setting 
                        time, if this is non-destructive then don't ask for 
                        confirmation.
20
Lie Ryan

Một số nguyên tắc UI khuyến nghị luôn sử dụng hộp thoại Ok/Hủy thay vì Có/Không.

Tôi, tuy nhiên, tin rằng đây là một sai lầm rất lớn. Ví dụ, gần đây tôi thấy một hộp thoại với câu hỏi như "Bạn có thực sự muốn hủy tài khoản của mình không?" và các nút có nhãn "Ok" và "Hủy". Trong trường hợp này, "Ok" có nghĩa là "Hủy" và "Hủy" có nghĩa là "không hủy".

Ít nhất theo ý kiến ​​của tôi, điều này khá gần với hoàn toàn điên rồ. Tất nhiên, có thể viết lại câu hỏi dưới dạng "Đóng tài khoản của bạn". Mặc dù vậy, một số người có thể nghĩ rằng đó là hủy tài khoản, ngay cả khi bạn không sử dụng/đề xuất Word đó. Trong các trường hợp, một nút có nhãn "hủy" là một ý tưởng tệ hại. Một số người chắc chắn sẽ nghĩ về việc hủy bỏ hành động đóng tài khoản, nhưng những người khác lại tự hủy tài khoản.

Tôi sẽ phải thừa nhận rằng sự thiên vị chống lại "Có"/"Không" cũng có một số công đức. Trong trường hợp này, tôi nghĩ sẽ tốt hơn nếu tránh các nhãn "chứng khoán" và sử dụng cái gì đó như "đóng tài khoản" và "giữ tài khoản mở".

18
Jerry Coffin

Không phải là giải pháp rất tốt nếu bạn đang muốn hỏi người dùng của mình một câu hỏi và cung cấp cho họ các tùy chọn để trả lời. Có/Không hoạt động nếu bạn đang trong một cuộc khảo sát, nhưng nó rất tối thiểu cho một hộp thoại phương thức. OK/Hủy giống như một sự nắm giữ của ngày xưa khi màn hình có độ phân giải thấp và các nút phải thật ngắn gọn để phù hợp.

Vấn đề là các nhãn nút đủ điều kiện là vi mô và do đó cần chú ý các yếu tố khác của giao diện người dùng. Tôi đồng ý hay không đồng ý với điều gì? Tôi đang làm gì hay hủy bỏ? Tại sao thông tin đó không có trên nút?

Vì vậy, quay trở lại và suy nghĩ về cách bạn có thể thay đổi nhãn để rõ ràng hơn. "Xóa hàng này? Có/Không" sẽ dễ quét hơn (đặc biệt là hành động phá hoại) nếu các nút chỉ nói "Xóa hàng này"/"Không xóa bất cứ thứ gì". Tạo kiểu cho hành động mà bạn muốn người dùng thực hiện như một lời kêu gọi hành động lớn hơn và làm cho nút hủy nhỏ hơn (và thậm chí không phải là một nút) cũng có thể giúp ích rất nhiều.

Đôi khi OK/Hủy giới thiệu hai nút vì có một hộp thoại phương thức liên quan. Tự hỏi nếu bạn đã nhận được một hộp thoại phương thức hoặc nếu bạn có thể lấy nó ra và đơn giản hóa trải nghiệm. Ví dụ: nếu bạn có hộp thoại đăng xuất của người dùng, đừng hỏi họ "Bạn có muốn đăng xuất không? OK/Hủy" trong hộp thoại phương thức, nhưng chỉ cần có một nút "Đăng xuất" và người dùng có thể quyết định nhấp vào nó hay không.

Các câu hỏi có liên quan sẽ giúp bạn ra quyết định:

11
Rahul

Nói chung, tôi đồng ý với @Nick nhưng có một điều đáng nói khác:

Tránh các hộp thoại nếu bạn có thể - các hộp thoại chỉ gây khó chịu trong hầu hết thời gian - bạn đang hỏi người dùng nếu anh ấy chắc chắn. Tôi không biết bạn thế nào nhưng tôi thực sự không thích kiểu phản kháng này - máy tính ở đây để phục vụ tôi chứ không phải cách khác!

Vậy - nút xóa thì sao? Thật ý nghĩa khi hỏi trước loại hành động này, phải không? Chà, chắc chắn là có nhưng cũng có giải pháp tốt hơn nhiều - cung cấp chức năng hoàn tác

Thùng rác, hoàn tác liên kết trong thông báo khay, "email giải cứu" được gửi sau khi hủy tài khoản, nhiều phiên bản của cùng một tài liệu, v.v. Đừng lười biếng - hãy đầu tư một chút thời gian để đơn giản hóa giao diện người dùng của bạn, làm cho nó trở nên đơn giản hơn. Người dùng xứng đáng có khả năng vận hành nhanh và nếu họ mắc lỗi thì bạn chỉ nên cung cấp dây an toàn - đó là điều đó. Đừng làm phiền họ trừ khi nó là hoàn toàn cần thiết.

Ngoài ra, đặt xóa tách khỏi các nút khác và làm cho nó nhỏ hơn có thể giúp giảm thiểu những sai lầm này. Các ứng dụng iPhone thường có lưu/hủy (cả hai đều có khả năng gây nguy hiểm) trên màn hình - vì khó chạm vào đó hơn.

EDIT: Ngoài ra còn có bài viết về "hoàn tác xác nhận" từ Aza Raskin

5
Kamil Tomšík

Hầu hết người dùng chỉ tìm kiếm 3 m.

  • Một dương - Yes, OK, Add, Retry, Wait ..etc.

  • Một âm - No, Abort, Quit, Exit

và cái thứ ba là:

  • "Thoát khỏi hộp tin nhắn này" - Cancel

Vì vậy, sử dụng Yes, NOCancel làm cho ba loại khác nhau suy nghĩ.

Điều đó có nghĩa, việc sử dụng của họ phụ thuộc vào trường hợp.

5
Vishnu Haridas

Nó phụ thuộc vào công thức. Tôi sẽ không muốn bất cứ điều gì ngoài Có/Không cho một câu hỏi mong đợi câu trả lời Có/Không. Tôi sẽ không muốn Có/Không cho một câu hỏi không phải là câu hỏi (hoặc câu hỏi được xây dựng theo cách mà có/không không phải là câu trả lời hợp lệ).

4
AProgrammer

Tôi không có bất kỳ số liệu thống kê nào để chứng minh cho tuyên bố sau, nhưng đối với cá nhân tôi, việc có một văn bản tùy chỉnh trên các nút không phải lúc nào cũng tốt hơn.

Ok/Hủy/Có/Không phổ biến đến mức bộ não của chúng ta đã được đào tạo để nhận biết và hành động theo chúng trong tích tắc, trong khi các nhãn tùy chỉnh yêu cầu từ người dùng dừng và chủ động xử lý thông tin, điều này có thể gây khó chịu nếu sử dụng về những hành động thông thường.

Miễn là hành động dự kiến ​​được bắt đầu bởi người dùng và hộp thoại theo cùng một logic, đơn giản Có/Không là tuyệt vời. Tôi đã biết những gì tôi đang làm, tôi chỉ cần xác nhận nó. Bất kỳ giải thích thêm chỉ là loại tiếng ồn.

Một ví dụ là hành động Thùng rác. Tôi muốn được nhắc nhở mỗi lần để tránh các lần nhấp ngẫu nhiên, nhưng khi tôi nhấp vào mục đích đó, tôi muốn kết thúc với nó càng nhanh càng tốt. Chỉ cần nhấp - nhấp, tôi không muốn đọc văn bản của hộp thoại, tôi đã mong đợi những gì nó sẽ hỏi và tôi mong đợi trả lời Có hoặc Không (hoặc Ok/Hủy), vì đó là bộ câu trả lời thông thường.

Một giải pháp tốt cho IMHO này là sử dụng nhãn nút ở dạng "Có, làm gì đó". Bằng cách này, bạn vẫn dễ dàng quét văn bản và tìm ra ý nghĩa, nhưng nếu bạn bối rối về hộp thoại, bạn có thể đọc mọi thứ và chắc chắn nút này làm gì.

2
ivanhoe

Tôi đồng ý với hầu hết các câu trả lời khác rằng hầu như luôn luôn tốt hơn để hiển thị các phản hồi cụ thể thay vì các nút Có/Không.

Tuy nhiên, Nguyên tắc thiết kế của Microsoft (ngày tháng 5 năm 2018) trên hộp thoại đề cập đến một số trường hợp có/không có thể phù hợp:

  1. Để thực hiện xác nhận yêu cầu suy nghĩ
  2. Để tránh phrasing dài hoặc khó xử

(Tôi không chắc là mình có đồng ý hay không, nhưng tôi thấy thật thú vị khi sử dụng "Có/Không" trong các ví dụ này là một quyết định thiết kế có chủ ý.)


  1. Xác nhận yêu cầu suy nghĩ

phần Xác nhận trong Nguyên tắc Thiết kế của Microsoft lập luận rằng việc sử dụng Có/Không có thể phù hợp trong các xác nhận có hậu quả đáng kể.

Không sử dụng xác nhận chỉ vì có khả năng người dùng mắc lỗi. Thay vào đó, các xác nhận có hiệu quả nhất khi được sử dụng để xác nhận các hành động có hậu quả đáng kể hoặc không lường trước được. [...]

Để xác nhận có giá trị, người dùng cần hiểu lý do không tiến hành. Đôi khi lý do rất rõ ràng, như khi người dùng đang đóng tài liệu với những thay đổi chưa được lưu:

confirmation-obvious

Trong ví dụ này, lý do xác nhận là rõ ràng.

Trong các tình huống khác, lý do có thể không quá rõ ràng.

Khi chọn nhãn nút cam kết cho hộp thoại, nguyên tắc chung là chọn nhãn là phản hồi cụ thể cho hướng dẫn chính. Điều này dẫn đến việc ra quyết định hiệu quả vì người dùng phải đọc một lượng văn bản tối thiểu để tiến hành. Tuy nhiên, mục tiêu hiệu quả này có thể phản tác dụng đối với các xác nhận. Xem xét ví dụ này:

Không chính xác:

confirmation-incorrect

Trong ví dụ này, phản ứng chính xác đòi hỏi phải suy nghĩ.

Nếu bạn đưa ra xác nhận này ngay lập tức sau khi người dùng đưa ra lệnh Gỡ cài đặt, phản hồi của người dùng có thể là "Tất nhiên tôi muốn gỡ cài đặt!" Người dùng sẽ nhấp vào Gỡ cài đặt mà không cần suy nghĩ thứ hai.

Để xác nhận, chúng tôi không muốn người dùng đưa ra quyết định vội vàng, tình cảm. Để khuyến khích người dùng suy nghĩ về phản ứng của họ, chúng tôi cần cung cấp một cú hích tốc độ ra quyết định nhỏ. Khi thực tế, tốt hơn là làm điều này bằng cách cẩn thận thực hiện các nút cam kết. Ví dụ: chúng ta có thể sử dụng ngôn ngữ bổ sung để chỉ ra rằng có một lý do để không tiếp tục.

Tốt hơn:

confirmation-better

Trong ví dụ này, "anyway" được thêm vào nhãn nút cam kết để chỉ ra rằng xác nhận đưa ra lý do không tiếp tục.

Nếu cách tiếp cận đó không thực tế, chúng ta có thể sử dụng các nút cam kết Có/Không.

Cũng tốt hơn:

confirmation-also-better

Trong ví dụ này, sử dụng các nút cam kết Có/Không buộc người dùng ít nhất phải đọc hướng dẫn chính.


  1. Để tránh phrasing dài hoặc khó xử

Xem xét phrasing hướng dẫn chính là một câu hỏi có hoặc không nếu các nút cam kết với cụm từ cụ thể hóa ra là dài hoặc khó xử. Ngoài ra, bạn có thể sử dụng các liên kết lệnh cho các phản hồi dài hơn (năm từ trở lên) cho hướng dẫn chính.

Sai:

long-phrasing-incorrect

Chính xác:

avoid-long-phrasing-correct

Các cụm từ cụ thể trong ví dụ không chính xác quá dài, vì vậy ví dụ đúng sử dụng Có và Không.

1
sonny

Tôi sẽ sử dụng Có/Không trong Hộp thoại nếu quy trình làm việc cần giải thích cách tiếp tục. OK/Hủy nên được sử dụng theo nghĩa "Tiếp tục?" với quy trình xử lý/công việc vì thông thường Hủy có nghĩa là một cái gì đó bị dừng hoặc gián đoạn nếu tôi nhấn hủy. Tôi sẽ không sử dụng hộp thoại OK/Hủy kết hợp với một câu hỏi như "Chúng ta có nên dừng ở đây không?" ... đây là phần giải thích Có/Không (xem quy trình làm việc và giải thích). Vì vậy, sự lựa chọn đúng luôn luôn phụ thuộc vào câu hỏi. Chà, có thể xây dựng các câu hỏi làm phiền người dùng ... nhưng tại sao bạn nên làm điều này?

1
Beachwalker

Tôi thích sử dụng Verb và hủy bỏ, như được mô tả bởi @Nick, nó có ý nghĩa hơn và thân thiện với người dùng hơn. Ví dụ: nếu bạn đang đóng một Cửa sổ và nếu bạn hỏi người dùng "Bạn có muốn đóng Cửa sổ không?" Có hai loại tùy chọn bạn có thể có "Có/Không" và "Đóng/Ở lại" .. "Ok/Hủy" không có ý nghĩa.

Vì vậy, ưu tiên đầu tiên đi đến động từ sau đó có/không.

0
DevC

Những ngày có nhãn nút Có/Không và Ok/Hủy không còn nữa. Đã đến lúc sử dụng nhãn nút dành riêng cho hành động trên các hộp thoại của bạn như bài viết này gợi ý.

Tại sao nút 'Ok' không còn dài nữa

Nó sẽ giúp người dùng không đọc văn bản hộp thoại khi bấm nhầm nút. Họ có xu hướng di chuyển nhanh qua giao diện, do đó, bằng cách gắn nhãn các nút của bạn bằng Word dành riêng cho hành động, tất cả những gì họ phải làm là đọc nhãn nút để biết nên nhấp vào nút nào. 'Ok' là mơ hồ và không mô tả hành động hoặc nhiệm vụ nào mà người dùng đang làm.

0
Fluke