it-swarm-vi.tech

Tại sao một người sẽ sử dụng "nhập tên của dự án để xác nhận"?

Nếu bạn là người dùng GitHub lâu năm, có lẽ bạn đã thấy một cái gì đó như thế này:

Điều này xảy ra mỗi khi bạn thực hiện một việc có khả năng phá hủy vào kho lưu trữ, như chuyển trạng thái công khai/riêng tư hoặc lưu trữ/xóa nó.

Lời nhắc hiển thị trong một phương thức sau khi nhấp vào nút hành động, vì vậy đây là một biện pháp bổ sung để ngăn chặn các hành động vô tình.

Nhưng theo tôi nghĩ, điều này hoặc là không hiệu quả trong việc "thiết lập một rào cản khác" hoặc quá cồng kềnh như "một xác nhận thêm". Người ta có thể chỉ cần sao chép tên kho lưu trữ từ URL hoặc ngay phía trên hộp nhập (văn bản in đậm ở trên), nhưng điều này vẫn phức tạp hơn là chỉ nhấp vào một nút phụ.

Theo tôi, một phương thức bổ sung với màu đỏ tươi button không đáp ứng với các hành động bàn phím (như phím Enter) sẽ đủ. Người ta sẽ phải di chuyển chuột của họ vào nút màu đỏ tươi để nhấp vào nó để thêm phần thận trọng. Điều này ít cồng kềnh và khuyết tật chỉ đơn giản là nhấn phím Enter vừa đơn giản vừa hiệu quả.

Bất cứ ai cũng có thể giải thích làm thế nào "nhập tên dự án" này là một thiết kế UI tốt?

48
iBug

Không nhất thiết là về "thiết kế giao diện người dùng tốt", nhưng nhiều hơn nữa về việc thực hiện tất cả các biện pháp để ngăn chặn việc vô tình xóa và đảm bảo rằng người dùng nhận thức đầy đủ về những gì họ đang xóa .

Mục blog này ở đây nắm bắt nó khá tốt:

Thay vì cung cấp cho người dùng một nút xác nhận mà họ có thể bấm nhầm, hãy cung cấp cho họ một trường văn bản và yêu cầu họ gõ Word xóa xóa để xác nhận. Khi người dùng gõ xóa xóa xóa trong trường văn bản, không có nghi ngờ rằng họ muốn xóa. Không có tình cờ nhấn nút xóa. Không có gì phải hối tiếc khi người dùng xóa, bởi vì trường văn bản xác nhận làm cho họ chắc chắn về những gì họ sẽ làm trước khi họ làm điều đó.
Cách đảm bảo người dùng chắc chắn không cần xóa - Chuyển động UX

Chắc chắn, nhấn một nút sẽ dễ dàng hơn, nhưng điều đó luôn để lại cơ hội bạn đọc sai tên và xóa mục sai.
[.___.] Khi bạn phải gõ tên (hoặc thậm chí sao chép dán nó), bạn có thể chắc chắn 99% rằng người dùng sẽ không làm điều đó sai. Họ sẽ nhận ra nó muộn nhất khi đánh dấu tên để sao chép-dán.

Bên cạnh đó, điều này thường chỉ được sử dụng cho các hoạt động xóa rất quan trọng. Những điều này rất hiếm khi xảy ra, vì vậy tranh luận về việc làm cho nó dễ dàng hơn hoặc ít gây phiền nhiễu hơn không thực sự giữ ở đó.


Dưới đây là một số câu hỏi liên quan:

168
Big_Chair

Chỉ rõ ràng là thiết kế UI "tốt" không có nghĩa là cung cấp cho người dùng những gì họ muốn. Điều đó thường có nghĩa là giúp người dùng trở thành một phiên bản tốt hơn của chính họ.

Ngoài những gì đã được đề cập, mẫu này (và một số giống như vậy) cho phép UI giảm tốc độ. Nói chung muscle memory -> speed -> mistakes -> sad path.

Hãy tưởng tượng rằng bạn đang làm việc trong lĩnh vực chăm sóc sức khỏe. Nếu người dùng xây dựng quá nhiều "dòng chảy" trong các tác vụ thông thường, họ có khả năng có thể mắc một lỗi đơn giản giết chết ai đó. Trong khi truy cập trực quan, thường rất tốt để kéo người dùng ra khỏi luồng của họ bằng cách yêu cầu tương tác (nhiều hơn một hộp thoại xác nhận đơn giản luôn xuất hiện ở cùng một nơi và có thể được thêm vào bộ nhớ cơ).

Gõ văn bản chỉ là một ví dụ về điều này. Tôi cũng đã thấy:

  1. thêm thời gian vào các nút trước khi chúng có sẵn.
  2. Ngẫu nhiên vị trí của các nút tiếp tục quá trình.
  3. Thêm khóa (ví dụ: chạy quy trình với tư cách quản trị viên bằng mật khẩu)

Tất cả các mẫu này nhằm gây khó chịu cho người dùng đến mức họ dừng lại để đánh giá tinh thần quá trình trước khi tiếp tục.

51
Bryce Howitson

Điều này là để đảm bảo rằng:

  1. Bạn hiểu sự nguy hiểm của những gì bạn đang làm.
  2. Quan trọng nhất là bạn đang thực sự xóa repo đúng.

Nếu một người dùng có nhiều repos với tên dài, có thể dễ dàng khiến chúng bị lẫn lộn. Gõ tên là một cách tốt để đảm bảo bạn không gõ sai, điều này thực sự rất tệ.

15
frodo2975

Tôi sử dụng lại một phím bàn phím không được sử dụng (thông qua AutoHotKey) để sử dụng không liên tục như một cú nhấp chuột trái để giảm căng thẳng do lạm dụng quá mức cổ tay của tôi và đôi khi (hiếm khi) nhấn phím đó vào sai vị trí khi đa nhiệm. Thỉnh thoảng tôi cũng tự đập chuột và vô tình bấm vào nút trên hộp thoại.

Mặc dù "đừng khiến tôi nghĩ" là một quy tắc rất tốt, nhưng thật hợp lý khi giúp người dùng tập trung vào chính xác những gì thực thi một lệnh không thường xuyên, phá hoại sẽ thực sự làm. Tôi thậm chí còn cân nhắc việc người dùng nhập một câu đầy đủ của biểu mẫu, "Vui lòng xóa kho lưu trữ iBug/example-repository, bao gồm wiki, các vấn đề và nhận xét" nguyên văn để làm rõ ý định của người dùng để chính họ = trong tình huống đó, vì người dùng sẽ chỉ làm điều đó một lần trên kho lưu trữ đó.

Bất cứ ai thực sự viết mã đều phải gõ các dòng văn bản đầy đủ, rõ ràng, chính tả rất thường xuyên, do đó, một dòng như vậy để xác nhận hành động phá hoại nhất mà bạn có thể thực hiện trên một dự án là không hợp lý.

9
user117529

Theo tôi, một phương thức bổ sung có nút màu đỏ sáng không phản ứng với các hành động bàn phím (như phím Enter) sẽ đủ. Người ta sẽ phải di chuyển chuột của họ vào nút màu đỏ sáng để nhấp vào nó để có thêm một cảnh báo. Điều này ít cồng kềnh và khuyết tật chỉ đơn giản là nhấn phím Enter vừa đơn giản vừa hiệu quả.

(nhấn mạnh thêm)

Bạn có chắc chắn rằng họ sẽ phải "di chuyển chuột"? Mỗi lần? Ngay cả khi chúng ở trên một thiết bị có độ phân giải khác nhau, nơi có thể mọi thứ không xếp hàng như dự đoán? Hoặc nếu chúng được phóng to? Còn đầu vào cảm ứng thì sao? Còn những người không sử dụng chuột (do sự khác biệt về khả năng/vv) thì sao? Bây giờ bạn phải chắc chắn rằng nó phản hồi với bàn phím theo cách không phá vỡ khả năng truy cập, nhưng không cho phép xóa ngẫu nhiên.

Trong khi có những tranh luận chống lại bừa bãi tuân theo các thực tiễn tốt nhất đơn giản do chúng là các thực tiễn tốt nhất (so với việc phát triển sự hiểu biết về lý do tại sao chúng tồn tại) hoặc ít nhất là " những gì mọi người khác đang làm ", đặc biệt là khi họ không luôn luôn thực sự tuyệt vời, tôi muốn chỉ ra rằng thường thì họ đã trở thành một thực tiễn tốt nhất vì có những vấn đề không lường trước sẽ phát sinh và cố gắng chống lại họ đơn giản vì bạn không thấy quan điểm của họ thường là một ý tưởng tồi. Khi xem xét một cái gì đó là một thực tiễn tốt nhất được áp dụng rộng rãi/được áp dụng rộng rãi, hãy bắt đầu từ giả định rằng nó có ý nghĩa và có ý nghĩa và có khả năng có những lý do cơ bản mạnh mẽ đã phát triển qua nhiều thời gian (và có thể là giữa nhiều người hơn là một, và chắc chắn đã có được xem xét bởi nhiều hơn một người) hơn là một mình bạn có lẽ đã dành cho cùng một bộ vấn đề (và chỉ với quan điểm của riêng bạn hướng dẫn bạn). Không đề cập đến các vấn đề nhất quán toàn cầu.

@ câu trả lời của BigChair cùng với câu trả lời của @ Bryce Howitson cả hai hãy tìm hiểu lý do tại sao đây là cách thực hành tốt nhất cho các hành động không thể phục hồi nói chung. Trong thiết kế giao diện người dùng, điều quan trọng là tạo ma sát cho các hành động quan trọng sẽ không thể phục hồi được và cả hai đều bao quát chủ đề khá tốt cho bối cảnh này.

Tuy nhiên, nếu có thể , tôi khuyên bạn nên chọn một đường dẫn khác trong mọi trường hợp khả thi để thực hiện:

Tránh để hành động không thể phục hồi ngay từ đầu

Như đã nói, cách tốt nhất để tiến lên phía trước là không có hành động của người dùng dẫn đến trạng thái phần mềm không thể phục hồi ở vị trí đầu tiên. Hãy nhớ rằng, những gì một UI thể hiện cho người sử dụng phần mềm không phải phù hợp với những gì phần mềm làm với trạng thái bên trong của nó, theo tỷ lệ 1: 1 của ngữ nghĩa liên quan. Bạn có thể sử dụng cái gì đó được thể hiện cho người sử dụng nó như thế nào để không phù hợp với việc triển khai kỹ thuật về những gì xảy ra khi họ kích hoạt một hành động liên quan.

Đừng xóa những thứ trong phần trình bày phần mềm của bạn chỉ dựa trên đầu vào của người dùng. Đánh dấu chúng đã bị xóa trong đại diện lưu trữ của bạn về chúng và cung cấp phương tiện để truy xuất chúng (thùng rác/vv). Không cho phép tạo ra các tình huống trong đó một người sử dụng sản phẩm của bạn có thể tự lùi vào một góc mà họ không thể tự thoát ra được. UX không chỉ tốt hơn để tránh sự cần thiết của các loại xác nhận này bất cứ nơi nào có thể làm như vậy, nó cũng làm giảm các yêu cầu hỗ trợ và mức độ ma sát liên quan trong các vấn đề hỗ trợ liên quan (cũng là các khía cạnh UX). Khi ai đó đang "xóa" thứ gì đó, hãy làm cho rõ ràng rõ ràng rằng họ cũng sẽ có thể hoàn nguyên hành động họ đã thực hiện cả khi tham gia vào hành động và sau đó (để nếu họ have vô tình "xóa" thứ gì đó mà không đọc màn hình và bao gồm cả hành động, bây giờ họ có thể thấy nơi để hoàn tác nó).

9
taswyn

Tôi đã thực hiện những gì tôi gọi là lỗi vô ý:

  • tay tôi thay đổi lần thứ hai tôi nhấn nút (muốn "Hủy", nhận "OK"). Ngoài ra: một quảng cáo xuất hiện và thay đổi trang.
  • hướng dẫn khó hiểu đến nỗi tôi nhấn nút sai (tất nhiên không phải là ít phá hủy hơn)
  • Tôi đã "oh không không không" và trong hoảng loạn nhấn nút sai
  • Tôi có thể hoặc không thể Juan Pablo Davila

Đây là lý do tại sao tôi thực sự, thực sự thích có trong những trường hợp như vậy một quá trình khiến tôi hành động khác với những gì bộ nhớ cơ gợi ý.

5
WoJ

Những gì Github đang cố gắng làm ở đây là tránh lỗi người dùng, nhưng cụ thể là "trượt" như Don Norman đề cập đến họ trong Thiết kế của những thứ hàng ngày.

Trượt xảy ra khi người dùng có ý định thực hiện một hành động, nhưng cuối cùng lại thực hiện một hành động khác (thường tương tự). Chẳng hạn, gõ một chữ i i thay vì một chữ oio được tính là một phiếu; vô tình để xà phòng rửa tay lỏng vào một bàn chải đánh răng thay vì kem đánh răng cũng là một vết trượt. Việc trượt thường được thực hiện khi người dùng ở chế độ lái tự động và khi họ không dành hết tài nguyên chú ý của mình cho nhiệm vụ trong tay.

Tôi nhấn mạnh phần cuối của trích dẫn là đặc biệt có liên quan.

Bài viết sau đây của nngroup nói về cách chống trượt

lỗi trượt loại thường được thực hiện bởi người dùng chuyên gia, những người rất quen thuộc với quy trình trong tay; không giống như người dùng mới vẫn đang học cách sử dụng hệ thống

https://www.nngroup.com/articles/slips/

Xem xét các loại người sẽ sử dụng Github, bạn sẽ xem xét họ rất cao về một cái gì đó như Thang đo bao gồm kỹ thuật số GDS có nghĩa là họ là những người dùng chuyên gia có nhiều khả năng bị trượt.

Sau đó kết hợp hai người lại và đồng cảm với một người dùng Github chuyên nghiệp, người đã đặt hàng trăm giờ vào một dự án, nhưng mệt mỏi, quên mất dự án nào họ tham gia và trượt để nhấn xóa khi họ không có ý định. Họ cảm thấy như thế nào?

Nhiều người dùng Github có số lượng kho lưu trữ lớn và trên trang xóa sẽ không có nhiều điều để phân biệt với họ nếu bạn không chú ý, có lẽ bạn muốn xóa repo "dự án triệu bảng - dự thảo", nhưng bạn đã ở trong "Dự án triệu bảng".

Đây là những gì họ đang làm và tôi sẽ coi đó là thiết kế UI hiệu quả cho điều đó. Đặt các ràng buộc hữu ích trong cách hoạt động không thể phục hồi là thực hành tốt.

3
dougajmcdonald