Nguyên tắc bất ngờ nhỏ nhất

Bách khoa toàn thư mở Wikipedia
Bước tới: menu, tìm kiếm

Nguyên tắc bất ngờ nhỏ nhất (tiếng Anh: Principle of least astonishment) áp dụng cho thiết kế giao diện, thiết kế phần mềmkhoa học lao động. Nguyên tắc phát biểu rằng khi hai thành phần giao diện xung đột hoặc nhập nhằng, hành vi của chúng phải gây bất ngờ ít nhất cho người sử dụng. Đặc biệt, một lập trình viên nên nghĩ về hành vi gây ít bất ngờ nhất cho người sử dụng chương trình chứ không phải suy ra từ hiểu biết về hành vi nội tại của chương trình.[1]

Quy tắc này bao gồm việc áp dụng các giá trị mặc định hợp lý.

Ví dụ[sửa | sửa mã nguồn]

  • Một người sử dụng chuẩn bị nhập tên và mật khẩu vào một chương trình hoặc trang web thì nhận được tin nhắn. Một vài chương trình tin nhắn tức thời ngay lập tức giành quyền đọc bàn phím và chuyển đến trường trả lời của nó, do giả định rằng người dùng sẽ trả lời tin nhắn mới ngay lập tức. Thực tế, người dùng có thể bất ngờ nhận ra vừa gõ mật khẩu vào trình nhắn tin và gửi nó cho người bạn của mình. Nguyên nhân của sự xung đột này là hai chương trình không biết về sự tồn tại của nhau và không thể dễ đang xác định lúc nào có thể can thiệp. Để tránh những xung đột như thế này, hệ điều hành có thẻ hạn chế sự tương tác giữa các chương trình, chẳng hạn bằng cách không cho phép trình nhắn tin cướp quyền đọc bàn phím.
  • Một giao diện người dùng có thể quy định rằng khi nhấn Ctrl+Q chương trình sẽ thoát. Cùng giao diện đó có thể có chức năng ghi vĩ lệnh, một chuyễn các phím tắt có thể lặp lại sau đó, có thể điều khiển mọi khía cạnh của chương trình. Người sử dụng muốn ghi một vĩ lệnh trong đó có chứa tổ hợp Ctrl+Q (thường là lệnh cuối). Nguyên tắc yêu cầu rằng nhấn Ctrl+Q khi ghi vĩ lệnh không được tắt chương trình (điều sẽ gây ngạc nhiên cho người sử dụng), thay vào đó ghi lại tổ hợp phím (giả sử rằng người sử dụng thực sự muốn ghi tổ hợp phím chứ không phải dừng ghi và đóng chương trình, trong trường hợp đó người dùng sẽ không hiểu sao không có gì xảy ra khi anh ta nhấn Ctrl+Q).

Xem thêm[sửa | sửa mã nguồn]

Tham khảo[sửa | sửa mã nguồn]

  1. ^ Joshua Bloch (2006), How to design a good API and why it matters, Association for Computing Machinery, tr. 506–507 

Liên kết ngoài[sửa | sửa mã nguồn]