Mài nhẵn UI
(blog.jim-nielsen.com)- Độ hoàn thiện của UI không tăng lên ngay sau khi triển khai, mà qua quá trình lặp đi lặp lại bằng cách thực sự bấm thử liên tục; bài viết ví điều này với việc chà nhám trong nghề mộc
- Chuyển trang và điều hướng cần được kiểm tra qua nhiều đường vào như bấm chuột, nút Back của trình duyệt, “Back” khi nhấp chuột phải, nút quay lại trong ứng dụng, phím tắt bàn phím
- Khi căn chỉnh
labelvàinput type="radio"bằng flexbox rồi thêmgap, khoảng giữa nút radio và nhãn lộ ra là một dead zone không bấm được - Cách xử lý là bỏ
gapvà thêm padding cholabel; vẫn giữ được khoảng cách trực quan trong khi vùng có thể bấm được mở rộng - Ngay cả những lỗi tương tác nhỏ nếu tích tụ cũng sẽ làm hại trải nghiệm người dùng, vì vậy cần dùng UI lặp đi lặp lại và tinh chỉnh cho đến khi không còn bắt gặp “gai nhọn” nào nữa
Tìm các phần thô ráp của UI bằng cách bấm lặp lại
- Làm UI gần với một vòng lặp: tạo ra thứ gì đó, bấm thật nhiều, sửa lại, rồi bấm tiếp
- Với chuyển trang, chỉ kiểm tra một luồng là chưa đủ; cần quay lại và xem xét theo nhiều cách khác nhau
- Sau khi bấm, dùng nút quay lại của trình duyệt
- Sau khi bấm, dùng “Back” trong menu ngữ cảnh khi nhấp chuột phải
- Dùng điều hướng quay lại bên trong ứng dụng
- Dùng phím tắt bàn phím để quay lại
- Quá trình này giống QA theo kiểu “bấm để thử làm hỏng”, nhưng còn gần hơn với cảm giác trong nghề mộc khi chà giấy nhám để tìm những chỗ thô ráp và gai nhọn
- UI phần mềm có thể có quá nhiều trạng thái và biến số, nên cần tinh chỉnh qua việc sử dụng lặp lại cho đến khi không còn bắt gặp “gai nhọn” nào nữa
Click dead zone do flexbox gap tạo ra
- Trong danh sách tùy chọn radio, đặt
<label>và<input type="radio">được liên kết với nhau trên cùng một hàng - CSS là một cấu trúc đơn giản áp dụng
display: flex,flex-direction: row,align-items: center,gap: .5remcho container - Trong lúc bấm lặp lại, phát hiện một dead spot: khi bấm vào khoảng trống giữa nút radio và nhãn, control không được toggle
- Nguyên nhân là
gapcủa flexboxgapgiúp tạo khoảng cách trực quan dễ dàng- nhưng không nằm trong vùng bấm của nhãn hay phần tử input, nên trở thành khoảng trống trong tương tác
- Cách xử lý là loại bỏ
gapvà thêm padding cholabel- Khoảng cách vẫn được giữ
- Vùng có thể bấm của nhãn rộng hơn, khiến dead zone biến mất
- Một lỗi nhỏ có thể trông không đáng kể, nhưng nếu có nhiều “gai nhọn nhỏ” như vậy, trải nghiệm UI có thể trở nên khó chịu
1 bình luận
Ý kiến trên Hacker News
Nếu là một lập trình viên đồng thời cũng là người dùng trực tiếp và thường xuyên của sản phẩm mình đang làm, bạn sẽ có lợi thế rất lớn trong việc phát hiện những vấn đề nhỏ như thế này
Vì trước khi người dùng vướng phải, chính lập trình viên có thể nhận ra những điểm hơi khó chịu, và cũng ở ngay vị trí có thể sửa chúng
Vì vậy, có vẻ những nhóm nhỏ có tinh thần sở hữu mạnh rất hiệu quả. Khi có ý thức làm chủ sản phẩm, những bất tiện nhỏ mà người dùng gặp phải cũng được cảm nhận như việc của mình, và việc làm cho UX mượt nhất có thể trở thành vấn đề tự trọng
Trừ những trường hợp khó dùng nội bộ như sản phẩm doanh nghiệp, dù quyền sở hữu trực tiếp có yếu hơn thì vẫn sẽ có lợi ích gắn với thành công của sản phẩm
Tôi tò mò không biết UI nào được trau chuốt nhất
Ở tầm FAANG thì nhiều tiền, nên tưởng UI/UX sẽ khá ổn, nhưng ai từng dùng Amazon.com, AWS, GCP hay Azure có lẽ sẽ cảm nhận khác
Cá nhân tôi xem mcmaster.com là UI/UX được trau chuốt tốt nhất. Có thể tìm thứ mình cần trong vài phút
Ngược lại, trên các trang của chuỗi cửa hàng lớn như Home Depot hay Lowe’s, việc tìm đúng kích thước của những thứ như ốc vít hay gỗ có thể mất 10–15 phút, và trên di động còn tệ hơn
Đơn giản và thực dụng đến khó tin nhưng vẫn khá mạnh. Có thể thu hẹp dần để tìm linh kiện hoặc tìm kiếm, tự động so sánh giá, và các nhóm giá/chất lượng cũng được gom rất hữu ích
Khi tìm được mã linh kiện, bạn có thể xem khả năng tương thích theo năm sản xuất/hãng/mẫu xe, mô tả ngắn, ảnh, và cả việc nó có được gửi từ cùng kho với các linh kiện khác trong giỏ hàng hay không. Tất cả diễn ra trên một trang, không ma sát, và chạy rất nhanh trên mọi nền tảng
Phản hồi cực nhanh và tôi chưa từng thấy lỗi khi dùng. Nó nâng chuẩn của tôi về việc web app có thể làm được đến đâu
Thực tế họ từng có cả một giai đoạn chuyên để sửa các vấn đề về khả dụng
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
Đặc biệt ảnh đại diện tạm thời là thứ khó chịu nhất. Nó không hoạt động đúng từ gần một năm trước và không tự quay lại ảnh gốc
Có vẻ ở đó chẳng ai đang trau chuốt gì cả
https://littlebigdetails.com chính là một nơi như vậy
Cách giải cơ bản cho vấn đề cụ thể này là đặt phần tử nhập liệu bên trong nhãn
Tôi từng thắc mắc lý do, và có lẽ là vì khi điều chỉnh vị trí/padding của nhãn hoặc phần tử nhập liệu, việc áp dụng theme sẽ đơn giản hơn
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for/id: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...Với radio hay checkbox, không chỉ ô và padding mà toàn bộ nhãn văn bản cũng phải bấm được để bật/tắt
Flexbox có vẻ hơi quá tay. Kể cả với cú pháp không lồng nhau thì nó cũng sẽ được bố trí inline, và tôi nghĩ chỉ cần thêm padding theo cùng cách là đủ
Để giảm thiểu, cần bọc
Footrong một phần tử riêngNhững chuyện như thế này đã biến mất quá nhiều trong Agile
Kỹ sư cần có thời gian để trau chuốt sản phẩm, nhưng thực tế thì không có. Nếu QA không tạo ticket vì vấn đề khoảng cách, nó sẽ không bao giờ được sửa
Khách hàng có lẽ sẽ nhận ra những thứ này, nhưng việc họ báo cáo đã là một phép màu, việc nó cuối cùng trở thành ticket cũng là một phép màu, rồi việc có ai đó ưu tiên để sửa nó lại là một phép màu nữa
Trên thực tế, bảng issue của đa số công ty quá thiếu minh bạch từ góc nhìn khách hàng, nên nếu phát hiện một vấn đề nhỏ hay bug, bạn phải qua lại mất 50 giờ để chứng minh đó là bug và đưa ticket vào tracker, rất bực mình
Có phải bạn nghĩ mô hình thác nước đã cho thời gian rõ ràng để kiểm thử và trau chuốt UI không?
Đây thường là một quy trình mà product manager phải ưu tiên và xử lý cùng một UX engineer hoặc designer có năng lực. Nếu muốn, bạn có thể đưa ưu tiên đó vào bất kỳ phương pháp phát triển nào, nên Agile không liên quan ở đây
Tôi đã báo cáo vài lần trong 3 năm qua, vì việc chỉnh sửa văn bản khi đang soạn cực kỳ khó chịu và bực bội
Là một web developer, tôi tự hỏi ngay từ đầu làm sao thứ như vậy lại bị hỏng được. Không biết phải kém đến mức nào mới làm hỏng một thứ vốn mặc định đã hoạt động. Đây là sửa lỗi chắc không thể mất quá 30 phút và sẽ khiến trải nghiệm người dùng của mọi người tốt hơn 1000 lần, vậy mà 3 năm sau khi báo cáo vẫn y nguyên
Trong Teams, tôi cũng từng báo cáo qua Microsoft Premiere Support một bug khiến không thể dùng phím HOME/END trong ô nhập số điện thoại, và câu trả lời là “hoạt động đúng theo thiết kế”
Không có gì lạ khi khách hàng không còn báo cáo những bug như vậy nữa. Vì nhân viên/developer lẫn công ty rốt cuộc cũng chẳng quan tâm
Tôi là lead developer của một sản phẩm và có rất nhiều vấn đề nhỏ ở khắp nơi. Cảm giác phải chịu trách nhiệm về một số thứ nhưng lại không có quyền sửa chúng chắc chắn không thể tốt được
Từ góc nhìn kinh doanh, lập luận sẽ là: nếu nó không ảnh hưởng đến doanh thu hay thương hiệu thì tại sao phải tốn thời gian và tiền bạc để sửa? Về dài hạn nó sẽ ảnh hưởng đến thương hiệu, nhưng đa số người ta sẽ đổi vai trò hoặc đổi công ty trong vòng 5 năm nên chẳng bận tâm
Nếu còn nhận được phản hồi thì đã là khá hơn rồi
Rõ ràng đang có một quy trình không đáp ứng nhu cầu của khách hàng, nên cứ cùng đội sửa nó là được
Nếu có các nghi thức Scrum thì có thể đưa ra trong retrospective, nhưng thật ra lúc nào cũng làm được. Retrospective chỉ là dịp cố ý nhìn lại vài tuần vừa qua; còn thứ gì nhận ra giữa chừng thì nên cố xử lý ngay giữa chừng
Người có khả năng nhìn ra và sửa những vấn đề UX nhỏ thực sự rất quan trọng
Trong thiết kế UX, những thứ này thường được ví như vết cắt giấy gây ra cho người dùng. Không chí mạng, nhưng làm giảm mức độ hài lòng của người dùng
Bổ sung cho tác giả: nút radio đó không tuân theo thông lệ dùng dấu chấm, thay vì dấu tick, để biểu thị trạng thái được chọn. Người dùng thoạt nhìn có thể hiểu nhầm rằng có thể chọn nhiều mục hoặc không cần chọn mục nào cả
Rất có thể đó là tác dụng phụ của chức năng đóng khi click ra ngoài
Nếu phía tiêu cực có “Papercuts”, thì phía tích cực có Juice, thứ gần đây cũng được HN nhắc đến
Bài này cho thấy rõ vì sao tôi ghét lập trình UI
Những thứ không thể dự đoán và có thể lệch đi theo cách nhỏ nhặt vượt quá sức kiên nhẫn của tôi. Tôi cũng phần nào thích nghĩ về cách một thứ có thể thất bại và viết test cho nó, nhưng cứ click lung tung để xem nó có vỡ không thì thật phân tán và bực bội
Tôi tự hỏi liệu việc triển khai UI vốn dĩ phức tạp như vậy, hay là chúng ta vẫn chưa tìm được mô hình lập trình phù hợp. Đôi khi tôi tự hỏi liệu mong muốn nó trông và hoạt động đúng như dự định ngay từ đầu có phải là unreasonable không?
Việc trau chuốt UI chỉ cần làm khi tạo component lần đầu. Đôi khi có thể cần kết hợp component theo cách khác hoặc làm một triển khai dùng một lần
Thành thật mà nói, nếu biết mình đang làm gì thì không mất lâu đến vậy. Một design engineer giỏi là chuyên gia cho vai trò kiểu này
Có quá nhiều mức độ tự do, trong khi các yếu tố cơ bản như form đáng lẽ chỉ với giá trị mặc định cũng phải hoạt động tốt
Đã có cách biểu diễn UI tốt thông qua code. Vấn đề là trò chơi tổng bằng không ở phía kinh doanh. UI đa nền tảng nếu không làm bằng stack UI xấu nhất là HTML/CSS/JS thì chi phí quá đắt
Nhưng nền tảng web tuy khá ổn cho tài liệu, lại có mức trừu tượng không phù hợp với ứng dụng. Vì vậy UI web cứ được phát minh lại mỗi năm bằng những abstraction mới và rò rỉ
Chỉ riêng việc theo kịp đã là quá nhiều việc
Các lĩnh vực khác cũng tương tự. Nếu không có cách dễ dàng để gửi request hay đưa tham số vào query, vì áp lực tự nhiên, người ta sẽ phát minh đủ kiểu cách nửa vời dù họ cố cẩn thận
Nền tảng web thì tối tân ở mảng đồ họa, nhưng với UI thì thật sự tệ. Vậy mà không ai thừa nhận điều đó và muốn thay đổi. Người ta chỉ tin vào phần đầu, còn di sản và độ phức tạp của trình duyệt thì ngăn cản thay đổi. Nếu làm thành thư viện thì vì không phải “chuẩn” nên chẳng ai quan tâm
Mặt khác, có UI lại dùng ô vuông cho nút radio
Có nút được nhấn mạnh nhưng không kích hoạt bằng phím Enter
Lại còn có ba menu ẩn sau các ký hiệu khác nhau (dấu ba chấm, hamburger, kebab)
Chất lượng chênh lệch rất lớn. Những người trau chuốt UI thật sự đáng được biết ơn
Đến cả Apple cũng làm vậy :(
Tôi không hiểu vì sao cách đặt phần tử nhập liệu bên trong nhãn lại không phổ biến
Làm như vậy thì vấn đề biến mất hoàn toàn, và cũng không cần tạo
idduy nhất để dùng vớiforChỉ là người ta biết rằng vẫn còn một vài công nghệ hỗ trợ chưa diễn giải được mẫu chuẩn hợp lệ mới, nên việc tuân theo chuẩn thời đồ đồng trở thành thực hành tốt nhất [1]
Tôi nghĩ các framework khác cũng tương tự. Nếu bọc hai trường input đó bằng phần tử
labelthì HTML không còn hợp lệ nữaVới radio button thì không thành vấn đề, nhưng có vẻ một số người sau khi gặp chuyện này thì làm vậy “cho chắc”. Giống như thêm dấu chấm phẩy ở cuối dòng JavaScript. Hầu như không cần, nhưng vì không biết chính xác khi nào cần nên cứ thêm ở mọi nơi
Với các ca sử dụng thông thường của checkbox/radio button, cú pháp cũng gọn gàng hơn nhiều
Bọc phần tử nhập liệu bằng label, nếu muốn tạo style cho phần văn bản thì đặt văn bản vào
span. Có thể đặtlabelthànhdisplay:flexvà xử lý vị trí văn bản theo cách đóTrong bug bash chúng tôi dùng cách này, và nó tạo ra nhiều ticket hơn hẳn so với người lập ma trận tích Descartes đa chiều cho các tổ hợp test case
Biết những test case như vậy làm điểm xuất phát là tốt, nhưng để tìm các vấn đề nhỏ, kiểm thử ngẫu nhiên nhanh chóng vượt qua kiểm thử theo kế hoạch
Kiểm thử theo kế hoạch thường chỉ dừng ở luồng bình thường hoặc lỗi dự kiến. Kiểu mài giũa này tìm ra các bug góc cạnh nhanh hơn nhiều
Lúc nào cũng phát hiện vấn đề hoặc điểm cải thiện nhỏ. Những thứ đó thực ra sẽ không lộ ra nhiều qua kiểm thử theo kế hoạch
Tôi đã mài giũa website cá nhân (https://dustinbrett.com) gần 4 năm rồi, và cảm giác như việc này có thể tiếp diễn mãi mãi
May là tôi vẫn thích làm nó
Hy vọng là toàn bộ :-)
Khi thấy kiểu “desktop OS trên một trang web”, đa phần tôi có cảm giác như mới làm được một nửa, và nói thật là đã quá phổ biến rồi, nhưng cái này thì ngược lại: rất chắc chắn và được trau chuốt kỹ
Làm thật sự tốt và truyền cảm hứng. Nghĩ xem mọi thứ đã được triển khai như thế nào cũng khá thú vị
Đó là nhu cầu muốn dùng hệ điều hành dạng cửa sổ trên điện thoại
Nếu phải tìm một thứ còn thiếu thì đó là không thể dùng mouse4/mouse5 trong explorer. Việc “mài giũa” đúng là có thể tiếp diễn mãi mãi