Lưỡi dao cạo của Feynman
(defenderofthebasic.substack.com)- Ngay cả khi phần giải thích kỹ thuật có cân nhắc đến người mới bắt đầu, vẫn phải để lại những manh mối chính xác để người có khả năng hiểu có thể nắm được trạng thái thực tế
- Thông báo lỗi của Outlook nói rằng có thể sao chép nội dung của một tin nhắn không còn tồn tại, từ đó cung cấp cho người dùng một mô hình mâu thuẫn
- Nếu không che giấu những từ như
servervàcache, người dùng quan tâm có thể tìm kiếm và học hỏi, còn người đã biết thì sẽ hiểu vấn đề nhanh hơn - Những chỉ báo trạng thái quen thuộc nhưng không chính xác như
loading…che giấu việc hệ thống thực sự đang làm gì; nói thẳng như “đang chờ bạn nhập xong” sẽ tốt hơn - Việc đơn giản hóa quá mức cản trở suy luận của người dùng, vì vậy ít nhất cũng nên để lại đầu mối dẫn tới sự thật như mã lỗi và hành động có thể thực hiện
Giải thích dễ hiểu cũng không được sai
- “Lưỡi dao cạo của Feynman” là một tiêu chí cho việc giải thích nội dung kỹ thuật tới người dùng phổ thông: nếu người có khả năng hiểu mà vẫn không thể hiểu được, thì đó không phải là một lời giải thích tốt
- Richard Feynman từng nói rằng trong một bài báo, chỉ với thông tin “cỗ máy nặng 7 tấn” thì không thể biết đó là máy gì, và cũng không rõ “atomic bullet” đang chỉ thứ gì
- Điểm cốt lõi không phải là lời giải thích trông có vẻ dễ đến mức nào, mà là khi người đọc có đủ khả năng hiểu thì họ có thực sự hiểu được nội dung đó hay không
Sự hỗn loạn do thông báo lỗi của Outlook tạo ra
- Trong một cuộc thảo luận trên Hacker News, thông báo lỗi sau đã bị đem ra chế giễu
- “This message can't be saved because it no longer exists. It can only be discarded. Make sure you copy the contents of the message before you discard if you want to use them later.”
- Người dùng được báo rằng họ có thể sao chép nội dung của một tin nhắn không tồn tại, nhưng lại không thể lưu nó
- Vấn đề không nằm ở chỗ người dùng phổ thông không biết thuật ngữ kỹ thuật, mà ở chỗ ngay cả với người có thể hiểu thì trạng thái thực tế cũng không được giải thích
Cách không che giấu server và cache
- Một cách diễn đạt thay thế giải thích rằng tin nhắn đã bị xóa trên máy chủ thư, nhưng Outlook vẫn đang giữ nó trong bộ nhớ đệm tạm thời của thiết bị đó
- Người dùng có thể sao chép nội dung tin nhắn hoặc xóa nó khỏi bộ nhớ đệm
- Nếu xóa khỏi bộ nhớ đệm, nó sẽ bị xóa vĩnh viễn
- Một số người phản ứng rằng người dùng phổ thông sẽ không hiểu các từ như
cachehayserver - Tuy nhiên, những từ này trở thành manh mối có thể học được cho người dùng quan tâm để họ tìm kiếm, và với người đã hiểu thì chúng cho thấy tình huống thực tế rõ ràng hơn
- Người không quan tâm có thể sẽ không nhận được nhiều ích lợi từ bất kỳ cách giải thích nào, nhưng với người quan tâm thì cần phải để lại manh mối
Nói đúng trạng thái phần mềm như nó vốn là
- Công cụ
substack-proxytạo ra một URL để vượt qua kiểm duyệt của Twitter dựa trên URL bài đăng Substack mà người dùng sao chép và dán vào - Trong lúc người dùng nhập hoặc sửa URL, có quá nhiều yêu cầu tới máy chủ phát sinh nên đã thêm độ trễ khoảng 1 giây
- Cụm trạng thái ban đầu là
loading…, nhưng thực tế đó không phải là đang tải mà là đang chờ người dùng nhập xong - “Đang chờ bạn nhập xong” phản ánh chính xác hơn trạng thái thực của máy
- Ngay cả khi bị kẹt do lỗi, việc đứng im ở “đang chờ bạn nhập xong” cũng bộc lộ trạng thái có vấn đề rõ hơn so với
loading…
Không cần dạy mọi thứ nhưng vẫn phải trung thực
- Phần mềm không cần phải dạy cho mọi người dùng mọi thứ
- Người dùng thường không muốn biết nguyên nhân, họ chỉ muốn nó hoạt động đúng
- Dù vậy, nếu đã cung cấp lời giải thích thì không nên đưa ra một mô hình kỳ quặc hoặc thiếu chính xác về cách máy tính hoạt động
- Cũng có thể chỉ cung cấp mã lỗi đơn giản và hành động có thể thực hiện
Error code 1027: file cannot be saved.[Copy contents][Delete file]
- Người dùng quan tâm có thể tìm mã lỗi, còn người không quan tâm có thể thấy ngay các lựa chọn có thể thực hiện
Tiêu chí của sự đơn giản hóa
- Sự đơn giản hóa tốt không cắt đứt những đầu mối nối tới sự thật cần được giải thích
- Cách tiếp cận hạ thấp tất cả người dùng về cùng một mức độ dựa trên giả định “người dùng trung bình sẽ không hiểu” là rất nguy hiểm
- “bits and bytes” là một ví dụ giải thích cách bật nguồn và nhấn
entercho người lần đầu dùng máy tính, nhưng trong cùng tập đó vẫn đề cập tới cả mã nhị phân
1 bình luận
Ý kiến trên Hacker News
Ví dụ message-doesn't-exist có vẻ không hẳn là do đơn giản hóa quá mức, mà gần với lỗi thường xảy ra khi người viết quên mất ngữ cảnh
Từ góc nhìn của lập trình viên, họ đã cố lấy thứ gì đó từ máy chủ, và máy chủ trả lời là không có, nên “không tồn tại” có thể đúng
Nhưng trong ngữ cảnh người dùng đang nhìn thấy thông điệp đó ngay trước mắt, “không tồn tại” rõ ràng là sai
Cần đặt lại ngữ cảnh kiểu như “Tin nhắn đó không có trên máy chủ, hiện chỉ tạm thời nằm trên máy tính của bạn, nên hãy sao chép lại”
Dù người dùng không biết “máy chủ” là gì, chỉ cần có thông tin rằng “ở đâu đó thì không có” là câu đã hợp lý hơn nhiều
Nếu thợ sửa ô tô chỉ vào cả chiếc xe và nói “Cái này sẽ được thay”, sẽ gây bối rối; nhưng nếu nói “xxx sẽ được thay”, thì dù không biết xxx là gì vẫn có thể hiểu được
Thiết kế trực tuyến ngày nay có cảm giác đang đi theo hướng làm con người ngu đi, với giả định rằng người dùng càng ít phải suy nghĩ thì càng dễ làm theo
Ví dụ, kết quả tìm kiếm Google dường như mỗi tháng lại càng được điều chỉnh theo mẫu số chung thấp nhất, và ngay cả khi tìm những nội dung tinh tế, thuật toán vẫn đẩy ta tới những câu trả lời không hữu ích
Có thể nhiều người thực sự phản hồi tốt hơn theo cách đó nên dữ liệu trông có vẻ tích cực, nhưng cá nhân tôi không thích
Tôi muốn vừa tương tác với hệ thống vừa học thêm từng chút và tiếp xúc với sự phức tạp, chứ không muốn sự phức tạp đó bị che giấu
Vì vậy họ làm thiết bị có thể điều chỉnh được, hiệu suất cải thiện mạnh và sai sót cũng giảm
Nhưng không hiểu vì sao trong ngành công nghệ lại nói ngược lại: càng tối ưu cho một người dùng trung bình tưởng tượng thì càng tốt hoặc càng kiếm được tiền
Tôi thắc mắc vì sao sự đa dạng cá nhân lại bị coi như có thể phớt lờ
Tôi nhớ Norton Disk Doctor không phải vì làm công việc khôi phục ổ đĩa, mà vì nó có giao diện tôn trọng trí tuệ của người dùng
Các hệ thống liên quan đến lưu trữ khác thì ném ra những câu không thể giải mã như “Mode 5/7? [Y]”, hoặc những câu hỏi bị làm cho quá ngớ ngẩn như “Are you sure? [N]”
Không thể biết mình cần chắc chắn về điều gì, mode 5 là gì, là 7 hay cả hai
Ngược lại, Norton giải thích bằng nhiều đoạn văn mỗi lựa chọn có nghĩa gì, diễn giải khái niệm trong ngữ cảnh, cho biết lợi ích và rủi ro
Thay vì cứ bấm Y liên tục rồi phó mặc cho may rủi, nó cho ta thông tin để lựa chọn
Sự tôn trọng dành cho độc giả và người dùng như vậy áp dụng cho mọi dạng viết kỹ thuật: sổ tay hướng dẫn, giao diện người dùng, bài blog, tài liệu API
Thay vì làm bài viết ngớ ngẩn đi vì “người thường”, tôi nghĩ nên giáo dục để mọi độc giả đã đọc và hiểu nó đều tiến bộ hơn một chút về mặt kỹ thuật
Nhân tiện, “Mode 5/7?” là câu thực sự xuất hiện trên một mảng Hitachi SAN chứa toàn bộ dữ liệu của một cơ quan chính phủ, và tài liệu hướng dẫn chỉ tử tế giải thích rằng tùy chọn này là để bật hoặc tắt mode 5/7
Nếu chọn sai, mảng có thể tự xóa và con mèo có thể chết, hoặc cũng có thể chẳng có chuyện gì xảy ra. Ai mà biết được
Những người tạo ra phần cài đặt hầu như chẳng tốn mấy công sức để thêm chú giải tooltip ngắn cho từng mục, nhưng thực tế họ gần như không làm
Nếu mục tiêu là truyền đạt thông tin thì điều đó đúng
Nhưng nếu mục tiêu là tăng lượt nhấp, giảm yêu cầu hỗ trợ và nâng mức độ tương tác, thì khó có thể nói một phần giải thích cụ thể và chính xác về mặt kỹ thuật tốt hơn một phần giải thích được đơn giản hóa đến mức thiếu chính xác
Nói vậy không có nghĩa là tôi đồng ý với mục tiêu ưu tiên mức độ tương tác hơn truyền đạt thông tin
https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...
Cần khiến việc theo đuổi những mục tiêu đó trở thành một lựa chọn thực sự nguy hiểm đối với những người đã quyết định làm vậy
Tôi phải vật lộn rất nhiều với vấn đề này trong công việc
Không thể giả định rằng độc giả thành thạo tiếng Anh, hiểu chủ đề, hay thậm chí có hứng thú muốn hiểu
Vì vậy tôi đã chọn lối viết đơn giản, không mơ hồ, và hiện còn đang thử nghiệm cả định dạng sao cho chỉ cần lướt qua cũng nắm được ý chính
Cá nhân tôi xem nhs.uk là ví dụ tốt nhất để học hỏi
Con người không ngu; họ chỉ bận, mệt, lười, hoặc không mấy quan tâm đến chi tiết
Có một sự cân bằng giữa việc tôn trọng trí tuệ của độc giả và tôn trọng thời gian của họ
https://www.gov.uk/guidance/content-design/writing-for-gov-u...
Tôi cũng nghĩ “dao cạo của Feynman” vốn theo hướng này. Tôi nhớ đến câu trả lời cho câu hỏi của khán giả trong bài giảng QED ở New Zealand năm 1979
Khi được hỏi “Ông có thích ý tưởng rằng bức tranh của chúng ta về thế giới phải dựa trên các phép tính có bao gồm xác suất không?”, Feynman trả lời rằng ông không nói là thích hay không thích
Ông nói rằng sau thời gian dài được đào tạo như một nhà khoa học, ông đã hình thành một cách nhìn sự vật nhất định; trong bài giảng, ông có thể đơn giản hóa một chút và hơi “đánh lừa” để nghe như thể ông không thích, nhưng ý nghĩa thực sự là “kỳ lạ”
Ông nói rằng mình không nghĩ đến việc có thích điều này hay không, mà nghĩ xem nó là gì và không phải là gì; việc thích hay không hoàn toàn không liên quan nên ông đã loại nó khỏi đầu
Với vấn đề về độ phức tạp và việc giải thích cho người không chuyên, hang thỏ luôn sâu hơn
Trong phần về phép quay không gian của các bài giảng Caltech cũng có một trích dẫn hay. “Chúng ta sẽ không dùng các phương trình này ở mức tổng quát đầy đủ và nghiên cứu mọi hệ quả. Làm vậy sẽ mất nhiều năm, trong khi chúng ta sắp phải chuyển sang chủ đề khác. Trong một khóa nhập môn, ta chỉ có thể trình bày các định luật cơ bản và áp dụng chúng cho một vài tình huống đặc biệt đáng quan tâm”
Nhìn theo hướng tích cực thì đó là thái độ không muốn nói sai hoặc ngụ ý điều không đúng từ vị thế chuyên môn, nhưng đồng thời cũng có vẻ như ông né tránh và không thật sự trả lời câu hỏi
Trong video người phỏng vấn hỏi nam châm hoạt động như thế nào, ông cũng trả lời đúng theo cách đó
“Bình luận tôi thích nhất là của lisper…” nghe hay thật. Có người đã nhận ra tôi
Tôi đang miệt mài viết một loạt bài blog về phương pháp khoa học nhưng hầu như không nhận được phản hồi, nên thật kỳ lạ khi một bình luận nhẹ nhàng như thế này lại được chú ý
Cuộc sống đôi khi buồn cười thật
Chính tác giả bài viết cũng không tái hiện đúng trích dẫn của Feynman
Không phải “And there are not sixty two kinds of particles” mà phải là “And there are now sixty two kinds of particles”
Nếu có thể giải thích theo cách làm hài lòng cả người mới lẫn chuyên gia mà không dùng thuật ngữ kỹ thuật, thì thuật ngữ chuyên môn còn có ích gì?
Ví dụ trong bài không hữu ích cho bên nào, và có hay không có thuật ngữ chuyên môn cũng chẳng làm nó tốt hơn
Nó chỉ là một lời giải thích tệ, nên lập luận tự thân bị yếu đi
Hoặc phải truyền đạt tất cả những điều đó, hoặc phải đi đường tắt bằng thuật ngữ chuyên môn
Trong một số trường hợp, có thể có cách giải thích làm hài lòng cả hai phía, nhưng khó hơn và cần nhiều từ hơn. Ít nhất trong bối cảnh truyền thông, điều này rất quan trọng
Dù vậy, ở đây có một phổ lựa chọn, và tôi nghĩ thường có thể tìm được điểm trung gian phù hợp
Nếu phát sinh nhầm lẫn kiểu “Nội dung không tồn tại mà lại có thể sao chép? Nếu có thể sao chép thì tại sao không lưu được? Nếu không tồn tại thì tại sao phải bỏ đi?”, thì có lẽ viết ít tính giải thích hơn lại tốt hơn
Chỉ cần khoảng: “Tin nhắn này sẽ sớm không còn khả dụng. Nếu muốn dùng về sau, hãy sao chép nội dung tin nhắn trước khi bỏ nó đi”
Nhắc đến cache cũng không giúp ích gì cho người dùng
Giải pháp thực sự là thêm nút “Lưu nội dung tin nhắn vào thiết bị” ở cuối tin nhắn
Khi đó câu chữ sẽ rõ ràng và dẫn thẳng đến hành động
Phần giải thích chi tiết hơn có thể được gắn nhãn, hoặc đặt ở màn hình thứ hai mở bằng nút “giải thích nâng cao”