Ba định luật về giao diện người dùng của Jef Raskin và bài học về trách nhiệm của lập trình viên

Năm 1942, Isaac Asimov đưa ra ba định luật về robot. Gần sáu thập kỷ sau, Jef Raskin — kiến trúc sư trưởng của dự án Macintosh đầu tiên — đáp lại bằng ba định luật về thiết kế giao diện người dùng. Cho đến nay, chưa có bộ nguyên tắc nào vượt qua được chúng.

Khi phần mềm vô tình phá hủy dữ liệu của bạn

Câu chuyện bắt đầu từ David Chisnall, một chuyên gia của dự án CHERI và là người dùng Vim lâu năm. Ông sử dụng tính năng hoàn tác bền vững (persistent undo) của Vim — tính năng lưu các thay đổi vào một thư mục riêng, cho phép bạn hoàn tác liên tục để quay về những chỉnh sửa từ nhiều tuần, thậm chí nhiều tháng trước đó.

Khi Chisnall thử bản fork NeoVim, công cụ này đã ghi đè lên tệp undo của Vim. Dù có cảnh báo, ông vẫn tin rằng dữ liệu sẽ được bảo toàn. Nhưng không — hơn một thập kỷ lịch sử thay đổi đã biến mất.

"Vim đã duy trì được điều này qua các bản nâng cấp lớn trong khoảng 20 năm. Tôi thậm chí không phải nghĩ về nó, đó chỉ là một phần của Định luật thứ nhất Raskin: Một chương trình không được gây hại cho dữ liệu người dùng, hoặc thông qua việc không hành động, để dữ liệu người dùng bị tổn hại."

Ba định luật của Raskin

Marcin Wichary, tác giả cuốn sách về lịch sử bàn phím Shift Happens, đã dẫn lại đầy đủ ba định luật mà Raskin công bố trong cuốn The Humane Interface (2000):

• Định luật 1: Máy tính không được gây hại cho công việc của bạn, hoặc thông qua việc không hành động, để công việc của bạn bị tổn hại.
• Định luật 2: Máy tính không được lãng phí thời gian của bạn hay yêu cầu bạn làm nhiều việc hơn mức thực sự cần thiết.
• Định luật 3: Một giao diện là "nhân văn" nếu nó đáp ứng nhu cầu con người và thấu hiểu những yếu đuối của con người.

Raskin lấy cảm hứng trực tiếp từ Asimov. Ý tưởng của nhà văn khoa học viễn tưởng là đặt ra các quy tắc để chấm dứt thể loại truyện robot sát nhân vốn đã nhàm chán từ năm 1942. Raskin làm điều tương tự với thiết kế phần mềm.

Cuộc chiến giữa "chủ nghĩa anh hùng" và sự tử tế

Raskin nổi tiếng với việc chỉ trích phần mềm dạng modal — loại phần mềm yêu cầu người dùng phải chuyển đổi giữa các chế độ, đòi hỏi thêm nỗ lực trí tuệ. Đây cũng là quan điểm của Larry Tesler, người phát minh ra thao tác cắt/sao chép/dán, với câu nói nổi tiếng "Đừng bắt tôi phải chuyển chế độ!" — ông thậm chí có biển số xe ghi "NOMODES".

Vậy mà Vim và vi — công cụ do Bill Joy viết năm 1976 — lại là phần mềm modal điển hình. Trớ trêu thay, đây lại là trình soạn thảo được nhiều lập trình viên hệ thống tôn sùng suốt hàng chục năm.

Có thể thấy một nét văn hóa trong thế giới Unix và C: kiểu thiết kế phần mềm mang tính "nam nhi" — nơi người dùng lấy làm tự hào vì đã chinh phục được những công cụ khó dùng. Cảm giác ấy không sai, nhưng nó không thay thế được trách nhiệm bảo vệ dữ liệu và thời gian của người dùng.

Bài học cho cộng đồng phần mềm nguồn mở

Chisnall không xa lạ với việc chọc giận cộng đồng Unix. Năm 2018, bài viết C Is Not a Low-level Language của ông từng gây tranh cãi dữ dội. Thậm chí, ông từng bị yêu cầu "tự sát" chỉ vì dám phê bình ngôn ngữ C.

Lần này, sau khi Wichary chia sẻ câu chuyện, cộng đồng NeoVim cũng phản ứng gay gắt. Điều đáng chú ý: NeoVim là trình soạn thảo được khuyến nghị trong Omarchy, và cho đến gần đây, trang web của dự án vẫn dẫn một dòng tweet của DHH. Sau cuộc tranh luận căng thẳng, đoạn trích dẫn này đã bị gỡ bỏ — đúng vào thời điểm các bài viết của Chisnall và Wichary xuất hiện.

Một tia hy vọng từ những cỗ máy nhỏ bé

Không phải mọi phần mềm đều đi theo con đường "tra tấn người dùng". Gần đây, cộng đồng công nghệ thích thú với việc giả lập chiếc Macintosh nguyên bản trên một con chip giá chỉ 0,60 bảng Anh (khoảng 0,80 USD). Thú vị hơn, đó không phải Raspberry Pi Zero mà là Pi Pico — một vi điều khiển.

Điều này cho thấy vẫn còn hy vọng rằng thế giới phần mềm có thể quay lại với những công cụ nhỏ gọn, đơn giản, lấy người dùng làm trung tâm — được xây dựng để thân thiện trước tiên, tính năng phong phú sau. Và tất nhiên, được viết thủ công chứ không nhờ đến sự hỗ trợ của bot.

Điều này có ý nghĩa gì với người dùng Việt Nam?

Với cộng đồng lập trình viên Việt Nam, những người ngày càng sử dụng nhiều công cụ mã nguồn mở, câu chuyện này mang theo bài học thực tiễn:

• Sao lưu cấu hình và dữ liệu quan trọng trước khi thử nghiệm bất kỳ công cụ mới nào, kể cả khi chúng được quảng cáo là "tương thích ngược".
• Cảnh giác với các fork có thể thay đổi cơ chế lưu trữ ngầm mà không thông báo rõ ràng.
• Đặt câu hỏi về trách nhiệm thiết kế: một công cụ tốt không chỉ mạnh mẽ mà còn phải an toàn và tử tế với người dùng.

Ba định luật của Raskin không phải là những quy tắc kỹ thuật khô khan, mà là một triết lý: phần mềm được viết cho con người, không phải để con người phục vụ phần mềm. Sau 35 năm Linux và hàng thập kỷ mã nguồn mở, có lẽ đã đến lúc các nhà phát triển nghiêm túc hơn với "nghĩa vụ chăm sóc" (duty of care) đối với người dùng của mình.