Thanh cuộn đang trở thành vấn đề

 (artemis.sh)
2 điểm bởi GN⁺ 2023-10-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi thanh cuộn ngày càng nhỏ đi hoặc bị ẩn, điều đó trở thành vấn đề khả dụng thực sự không chỉ với người khó dùng bánh xe cuộn hoặc cử chỉ chạm, mà cả với người muốn di chuyển nhanh đến một vị trí trong tài liệu
  • Người dùng gặp khó khăn với điều khiển vận động tinh hoặc dùng thiết bị trỏ có độ chính xác hạn chế như eye tracker sẽ khó nhắm trúng thanh cuộn rộng 8 pixel, và người dùng điều khiển bằng giọng nói cũng muốn nhấp trực tiếp vào vị trí mong muốn thay vì cuộn lặp đi lặp lại
  • Dù GTK, Qt, Firefox, Chrome và Electron đôi khi cho phép chỉnh độ rộng hoặc cách hiển thị của thanh cuộn, chúng lại phụ thuộc vào các cách khó tiếp cận với người dùng phổ thông như sửa CSS, gsettings, about:config, biên dịch lại theme hoặc thiết lập riêng cho từng ứng dụng
  • Trước đây từng có nút cuộn để nhấn giữ và di chuyển từng chút một, nhưng chúng đã l quietly biến mất; phím mũi tên có thể thay thế một phần nhưng hoạt động khác nhau tùy trạng thái focus
  • Những UI như minimap tài liệu, nơi có thể xem nội dung và di chuyển bằng vùng nhấp lớn, có thể trở thành cách điều hướng thay thế hữu ích cả với người dùng eye tracker lẫn bút tablet

Thanh cuộn ngày càng nhỏ và bị ẩn

  • Thanh cuộn là UI cơ bản dùng để nhấp và kéo nhằm thay đổi vị trí hiện tại trong vùng có thể cuộn
  • Gần đây thanh cuộn đã nhỏ đến mức khó cả chụp ảnh màn hình để minh họa, và xu hướng làm chúng nhỏ hơn nữa hoặc ẩn đi đang làm hại khả dụng
  • Cách tiếp cận “chỉ cần dùng bánh xe cuộn là được” mặc định rằng mọi người đều có thể dùng bánh xe cuộn hoặc vuốt trên màn hình cảm ứng
  • Ngay cả người dùng thành thạo bánh xe cuộn đôi khi cũng muốn nhảy nhanh đến một vị trí cụ thể

Tác động đến khả năng tiếp cận

  • Người dùng gặp khó khăn với điều khiển vận động tinh sẽ khó nắm chính xác thanh cuộn mỏng
  • Các thiết bị trỏ như eye tracker rất ấn tượng, nhưng chưa đủ để nhắm ổn định vào thanh cuộn rộng 8 pixel
  • Người điều khiển máy tính bằng giọng nói hoặc âm thanh, kể cả khi dùng công cụ như Talon Voice, có thể thích cách nhìn vào thanh cuộn rồi nhấp vào vị trí mong muốn hơn là lặp lại scroll down hoặc dùng auto-scroll
  • Ngay từ năm 2015, vấn đề độ rộng thanh cuộn trong GTK3 đã được bàn tới, và thanh cuộn mỏng gây gánh nặng cho người dùng không rành kỹ thuật cũng như người có vấn đề về thao tác tay hoặc thị lực

Những cách khiến thanh cuộn trở nên khó dùng hơn

  • Trong một số trường hợp, độ rộng thanh cuộn tính theo pixel vẫn giữ nguyên, nhưng khi độ phân giải màn hình tăng lên thì mục tiêu thao tác thực tế lại nhỏ hơn
  • Trong các trường hợp khác, chính thanh cuộn thực sự đã nhỏ hơn
  • Bài viết cũng nhắc đến trường hợp Ubuntu từng thử dùng thanh cuộn cực mỏng trong quá khứ
  • Trong lúc thanh cuộn thu nhỏ lại, nút cuộn để nhấn giữ và di chuyển từng chút cũng biến mất
    • Phím mũi tên có thể thay thế một phần chức năng, nhưng phụ thuộc vào việc nội dung nào đang được focus
    • Các nút thì có thể dùng bất kể trạng thái focus
  • Nhìn chung, thanh cuộn đã kém hữu dụng hơn, còn các thiết lập người dùng để sửa điều này thì либо không có, либо bị chôn sâu trong các tầng kỹ thuật mà người dùng phổ thông khó tìm tới

Rào cản trong thiết lập GTK

  • Trong GTK2, có thể đổi trực tiếp độ rộng thanh cuộn trong gtkrc, và thậm chí còn có chương trình GUI cho việc này
  • Với GTK3, phải chỉnh qua CSS; nếu không hiểu theme thì gần như không có cách thiết lập thân thiện với người dùng
  • Một thread Reddit giới thiệu script thêm slider { min-width: ...; min-height: ...; } vào gtk.css của GTK3·GTK4, đồng thời xử lý cả Flatpak override và thiết lập overlay scrolling
  • Ứng dụng Flatpak cần override riêng nên có thể không áp dụng nguyên trạng theme hệ thống
  • GTK cũng dùng kiểu mặc định là ẩn thanh cuộn rồi chỉ hiện khi đưa chuột đến vị trí đó
    • Trong GTK3, có thể luôn hiển thị bằng lệnh sau gsettings set org.gnome.desktop.interface overlay-scrolling false
    • Có thể tìm bằng Dconf Editor, nhưng phải biết đúng vị trí
  • Một thread GNOME Bugzilla được trích dẫn cho biết trong GTK4 không thể đặt thiết lập này ở mức toàn cục
    • Trong thảo luận, vấn đề là phải yêu cầu tùy chọn non-overlay scrollbar cho từng ứng dụng một

Rào cản trong thiết lập Qt

  • Độ rộng thanh cuộn của Qt được quyết định bởi plugin style widget Qt đang dùng
  • /u/cfeck_kde giải thích trong câu trả lời trên r/kde rằng theo họ chỉ style Skulpture cho phép chỉnh kích thước, còn các style khác như Breeze thì phải sửa mã nguồn C++ rồi biên dịch lại
  • Plugin style của Qt là mã thực nên cho phép kiểm soát rất mạnh, nhưng bạn phải tìm được plugin có cung cấp đúng thiết lập mong muốn
  • Kvantum có vẻ khó tìm thiết lập độ rộng thanh cuộn, nhưng có thể tắt tính năng làm thanh cuộn biến mất mang tên “Transient scrollbars”
  • Skulpture có thể đáng thử, nhưng bài viết chưa xác nhận được cách cấu hình bằng GUI nếu không có KDE Plasma
  • Nếu phải phụ thuộc vào một theme engine duy nhất, vẫn còn lo ngại liệu nó có tiếp tục được duy trì khi Qt tiếp tục phát triển hay không

Tình hình của Firefox, Chrome và Electron

  • Firefox cũng dùng thanh cuộn rất nhỏ, nhưng hiện vẫn có thể chỉnh trong about:config
    • Nhập about:config vào thanh địa chỉ
    • Sửa widget.non-native-theme.scrollbar.size.override thành số mong muốn
    • Có thể sửa widget.non-native-theme.scrollbar.style để đổi kiểu dáng
    • Giá trị 4 sẽ đặt kiểu hình chữ nhật dày hơn
    • Trong cửa sổ thiết lập thông thường about:preferences, có thể bật “Always show scrollbars”
  • Ví dụ, có thể đặt kích thước thanh cuộn của Firefox thành 50; dù thực tế có thể không muốn dùng lớn đến vậy, điểm hay là ít nhất vẫn có thể phóng to nó
  • Bài viết của Athena Lilith Martin về các thiết lập bổ sung cho thanh cuộn Firefox còn đề cập các cải thiện khác như tắt CSS override của trang web
  • Chrome bị đánh giá là khó kỳ vọng có thiết lập hữu ích
  • Ứng dụng Electron cũng khó cấu hình, và chưa có giải pháp chắc chắn nào được đưa ra, dù có thể việc chèn CSS tùy biến sẽ giúp khắc phục

Cách điều hướng tốt hơn: minimap

  • Minimap cho phép nhìn thấy nội dung, nhấp vào nội dung và di chuyển đến vị trí của phần nội dung đã nhấp
  • Mục tiêu nhấp rất lớn nên đặc biệt hữu ích với người dùng eye tracker và người dùng bút tablet
  • Các “nguyên tắc thiết kế hiện đại” phổ biến đang vận hành theo hướng bất lợi cho thanh cuộn và cho những người có nhiều cách sử dụng máy tính khác nhau

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-14
Các ý kiến trên Hacker News

  • Không chỉ là vấn đề của riêng thanh cuộn. Vì loại bỏ viền cửa sổ, các cửa sổ có màu tương tự nền không còn phân biệt được, và việc nắm vào mép để đổi kích thước cửa sổ cũng gần như bất khả thi
    Thanh tiêu đề thì bị nhồi đầy ô tìm kiếm và các nút không cần thiết, khiến gần như chẳng còn chỗ nào để nắm kéo di chuyển cửa sổ; việc chuyển tab giữa các ô văn bản cũng không hoạt động như kỳ vọng, hoặc hoàn toàn không hoạt động
    Tooltip gây cản trở và làm rối giao diện, nhiều khi che mất nội dung muốn xem, và 95% là thông tin trùng lặp hoặc vô dụng
    Trong 10 năm qua, UI/UX kiểu sùng bái hàng hóa đã vứt bỏ các nguyên tắc khả dụng tích lũy qua nhiều thập kỷ, tạo ra những thứ chỉ trông đẹp mắt nhưng với nhiều người thì không hoạt động đúng
    Các ứng dụng như Postman, Teams, phần lớn ứng dụng Microsoft gần đây, Chrome, Insomnia nên được dùng làm ví dụ cho việc không nên thiết kế UI phần mềm desktop như thế nào
    Tội lớn hơn là nếu những yếu tố này từng có thể được cấu hình ở cấp hệ thống cửa sổ và nhà phát triển ứng dụng không thể ghi đè thì đã không thành vấn đề, nhưng Windows và Gnome/GTK lại đang đi theo hướng loại bỏ các tùy chọn hiện có

    • Tôi nghĩ gọi là “đồ ngốc” là đúng. Tôi không muốn chửi những người chỉ đang làm việc, nhưng giờ muốn di chuyển cửa sổ thì phải nhấp lung tung như kẻ ngốc để tìm xem đâu là thanh tiêu đề, đâu là nút
      Mỗi lần khởi động “New Teams” lại bị hỏi có muốn quay về Old Teams không; còn nếu mở PDF bằng New Teams trong File Explorer thì cũng không rõ làm sao đóng PDF mà không mất vị trí trong hệ thống tệp
      Hơn nữa mọi thứ đều chậm kinh khủng. Khá nhiều người làm ở Microsoft/Apple/Google đang không làm được việc của mình, và họ nên cảm thấy xấu hổ về điều đó
    • Tôi có cảm giác Windows XP là đỉnh cao của giao diện dùng được, và lẽ ra nên dừng ở đó. Tất nhiên, cũng có thể chỉ là tôi già đi và đang quát bọn trẻ con ra khỏi bãi cỏ nhà mình
      Riêng với Windows thì tôi chắc là như vậy, và tôi cho rằng mọi phiên bản Windows sau đó đều khiến trải nghiệm người dùng tệ hơn
    • Tôi nghĩ không cần lăng mạ. Lý do tôi thích HN là vì đây là một trong số ít nơi mà thảo luận lịch sự được đặt lên trước kiểu lời lẽ thù ghét của các nền tảng khác
      Về cơ bản tôi đồng ý rằng tính khả dụng quan trọng hơn thẩm mỹ, nhưng tôi không rõ “đồ ngốc UI/UX kiểu sùng bái hàng hóa” chính xác là chỉ ai
      Với tư cách người đã làm lãnh đạo UX/UI hơn 20 năm, thủ phạm chính phá hỏng tính khả dụng thường là lãnh đạo kinh doanh và marketer hơn là designer
      Tất nhiên cũng có những designer nghĩ hình thức quan trọng hơn chức năng và cứ thúc đẩy thanh cuộn nhỏ, nhưng khi vấn đề được giải thích, họ thường lùi lại và tạo ra thiết kế dùng được
      Các lãnh đạo cấp C, lãnh đạo marketing và quản lý thì nguy hiểm hơn vì họ không hiểu UI nhưng lại rất chắc ý kiến, đưa ra các yêu cầu kiểu “thanh cuộn của website này hay đấy”, “thiết kế trông chưa hiện đại”
      Việc đấu tranh để bảo vệ tính khả dụng và khả năng tiếp cận quá đau đớn, và một số cấp bậc cần hành xử chuyên nghiệp hơn, tin tưởng chuyên gia hơn. Designer cũng đúng là phải nghĩ đến tính khả dụng trước tiên
    • Vấn đề lớn hơn là giờ gần như không còn nỗ lực nào nhằm cấu trúc hóa thông tin nữa
      Menu cài đặt là cơn ác mộng các danh sách chồng lên danh sách, cấu trúc menu ở mỗi ứng dụng hoàn toàn ngẫu nhiên, và nhiều khi ngay cả những thứ có thể cấu hình cục bộ cũng bị đẩy sang liên kết trang bên ngoài
      Thật sự rất khó hiểu ý đồ của designer, và không thể phân biệt được là mình không tìm thấy cài đặt hay ngay từ đầu họ đã cố tình không đặt nó trong menu này
      Đã quá nhiều lần tôi phải tìm Google chỉ để đổi thiết lập mặc định, kể cả trong game, nơi trải nghiệm chiếm một nửa giá trị sản phẩm
      Menu cài đặt của CS2 có các nút văn bản ở phía trên trông như tab, nhưng thực ra chỉ cuộn đến một điểm tùy ý trong danh sách cài đặt dài, nên rất khó tách bạch trong đầu mỗi nút có nghĩa là gì
      Ý nghĩa của các khái niệm không được liên kết với nhau, cũng không được cấu trúc hóa, khiến việc khám phá điện toán trở nên khó khăn một cách không cần thiết
      Tôi nhớ UI của Macromedia Flash; dù không dùng nhiều nhưng nó thật sự đơn giản và dễ dùng
      Một trong những động lực lớn khiến tôi tìm đến quyền riêng tư và các giải pháp tự làm cũng là vì muốn thoát khỏi sự ô nhiễm trải nghiệm và tri thức đang thấy ngày nay
    • Đó chính là lý do từng có hộp đổi kích thước. Thực ra nó là một mép kéo được nhưng không có phần thịt, tức là nhồi quá nhiều vai trò lên một phần tử 1 pixel và tạo ra xung đột
      Hộp đổi kích thước ngày xưa nằm riêng ở cuối thanh cuộn dọc, ngay dưới nút mũi tên xuống, như một tay nắm chuyên dụng để đổi kích thước cửa sổ
      Vì nó nằm ngay gần nút cuộn để xem nội dung chưa hiện ra trên màn hình ban đầu, nên nó gần như là điểm bắt đầu và mốc tham chiếu tự nhiên để tương tác với viewport
      Trớ trêu là trong UI ứng dụng thì phần lớn đã biến mất, nhưng trình duyệt web đôi khi vẫn render nó trong các phần tử bật cả thanh cuộn và resize như textarea. Chỉ là phần lớn UI không còn các nút cuộn liên quan nữa

  • Gần đây tôi có một nhận ra khá buồn cười. Không phải thị lực của tôi kém đi, mà là UI đã tệ đi
    Những thanh cuộn tiny có độ tương phản thấp đến mức nực cười thì không thể gọi là dễ tiếp cận với bất kỳ ai
    Gần đây tôi bắt đầu dùng KDE với theme Oxygen, và thấy vui vì dùng khá thoải mái, không mỏi mắt
    Những thanh cuộn kiểu này là thứ đáng chán, thậm chí không có chỗ để tùy biến; còn muốn áp theme cho các app bị khóa thì chỉ biết chúc may mắn
    Việc các nhà thiết kế UI không quan tâm đến nhu cầu của người dùng lộ liễu đến mức khó chịu, và ngay cả thế giới FOSS cũng không ngoại lệ
    Thật buồn khi chúng ta đi lùi từ thời có phần mềm đẹp, có chức năng, dễ tiếp cận và nhanh, sang thứ rác Electron bị khóa kín và không thể theme
    Nếu UI có đủ độ tương phản và khả năng đọc, có lẽ đã chẳng cần những thứ như “dark mode”

    • Tôi không dùng dark mode vì độ tương phản, mà vì light mode của rất nhiều phần mềm chỉ là màu trắng tinh. Màn hình thì ngày càng sáng hơn và mạnh hơn
      Khi dùng phần mềm không có white mode, thường nó sáng đến mức bức tường gần đó trông như đang được bật đèn pin chiếu vào
      Vì vậy tôi hạ độ sáng màn hình xuống, rồi màu sắc và độ tương phản trở nên tệ hại, rốt cuộc vẫn chẳng thấy gì
      Tôi nhớ giao diện màu xám thời Win 9x; nó không đẹp, nhưng thực sự nhìn được
    • Độ tương phản cũng là một yếu tố, nhưng trào lưu UI phẳng đã đẩy các sắc xám trung tính và xám sáng ra ngoài, thay bằng trắng tinh và gần như trắng, khiến light mode chói mắt hơn trước rất nhiều
      Sau khi UI phẳng chói lóa thống trị, việc mọi người đòi dark mode chẳng có gì lạ
    • Tôi ước thế giới số có nhiều điều khiển analog hơn. Thay vì nút tăng/giảm 10 mức, tôi muốn có núm xoay
      Kiểu điều khiển thủ công dạng số, nơi rất dễ thoát khỏi menu rồi khi cố quay lại lại chỉnh nhầm sang thứ hoàn toàn khác, đã trở nên quá “số” và rườm rà
      Ngày xưa việc chỉnh độ tương phản và độ sáng của màn hình, âm lượng ampli, TV analog, bộ điều nhiệt, radio trên ô tô, v.v. rất dễ
      Hiện vẫn chưa có xu hướng đưa nhiều điều khiển analog trở lại, nhưng suy cho cùng thế giới của chúng ta là analog. Đầu vào là analog, như lời nói hay chuyển động cơ bắp; đầu ra cũng là analog, chạm tới giác quan như ánh sáng và rung động
      Tôi không hiểu vì sao phần điều khiển lại không analog hơn, có lẽ là do chi phí
      Nếu có màn hình hoặc laptop với điều khiển analog, chắc tôi sẽ mua ngay. Thực ra dù đó là một vòng xoay 16 triệu mức đi nữa, miễn phản hồi tức thời và tạo cảm giác như biến trở thật thì cũng đủ
      Sẽ rất hay nếu có một núm xoay để nhanh chóng thay đổi cường độ tùy tình huống, hoặc xoay qua các lựa chọn để dễ đọc, dễ nghe hơn
      Ngày nay 90% công việc diễn ra trong trình duyệt, nên tôi ước trình duyệt cung cấp API accessibility để có thể điều khiển bằng núm xoay, qua Bluetooth hay gì cũng được. Nó giống như phiên bản nâng cấp của bánh xe cuộn
    • Đặc biệt đáng tiếc là trào lưu “don’t theme my app” mới xuất hiện. Vấn đề stylesheet CSS của GTK nên được giải quyết bằng cách thay CSS bằng một phương thức tạo style tốt hơn, chứ không phải vứt bỏ mọi thứ và không cho người dùng dùng theme của chính họ
    • Tôi cho rằng khoảng 20 năm trước, vào thời Windows 2000, khả năng sử dụng đã đạt đỉnh. Ảnh chụp màn hình trong bài thực ra cũng có vẻ là OS X 10.x đời đầu cùng thời đó, có lẽ khoảng 10.3

  • Tôi thường gặp các website có popover cuộn được hoặc những frame nội bộ kỳ quặc; thanh cuộn của frame nhỏ bên trong bị ẩn, khiến tôi không biết còn nội dung nữa hay không và tưởng rằng site đã hỏng hoàn toàn
    Điều đó thật sự khiến tôi bực, và tôi đổ lỗi cho iOS và macOS vì đã khuyến khích và phổ biến sự điên rồ này. Trào lưu UI “phẳng”, thứ khiến khó đoán cái gì là cái gì, cũng gián tiếp có trách nhiệm
    UI là giao tiếp, vậy mà các nhà thiết kế UI dường như đã quyết định rằng nói lẩm bẩm mới là ngầu

    • Trong bối cảnh iPhone ban đầu, việc ẩn thanh cuộn khi không đang cuộn phần nào có lý. Màn hình chỉ 3,5 inch, nếu mục tiêu là hiển thị nội dung ở mức desktop thì không có nhiều chỗ dành cho thanh cuộn, và phần lớn người dùng cũng sẽ không tương tác trực tiếp với thanh cuộn
      Ngược lại, trên hệ điều hành desktop, ngay cả những màn hình nhỏ nhất được dùng cũng lớn hơn nhiều, nên chẳng có mấy lý do chính đáng để ẩn thanh cuộn
    • Nếu chấp nhận rủi ro lái thread phàn nàn này sang hướng còn dễ bùng lửa hơn, có lẽ nó đang bắt chước phim ảnh và TV ngày nay
      Ngay cả khi bọn trẻ yên lặng, đang ngủ hoặc đã đi học, nhiều phim và series hiện nay vẫn khó xem nếu không bật phụ đề
    • Tôi thậm chí không hiểu nổi UI phẳng này đã trở thành trào lưu như thế nào

  • Một lần nữa phải khen Firefox vì đã cung cấp công cụ để tắt những thứ như thế này trong about:config. Nhìn tích cực thì đó chỉ là đồ trang trí dễ thương, còn nhìn tiêu cực thì gây khó chịu và dễ bị lạm dụng
    UI của trình duyệt gần như nên nằm hoàn toàn ngoài phạm vi mà website có thể thay đổi, và thanh cuộn cũng thuộc phạm vi đó

    • Ngược lại, Chrome làm tôi bật cười lớn ở chỗ “hãy tưởng tượng có thể cấu hình thứ gì đó hữu ích trong Chrome”
      Toàn bộ bài viết được viết rất tốt, xin khen tác giả
      Tôi cũng đã chuyển lại sang Firefox vì Edge cứ liên tục nhét Bing Search và các tính năng khác vào mặt, cả prompt khôi phục tab cũng quá phiền. Tôi chỉ muốn nó im đi và thôi làm vậy
    • Tôi còn nhớ rất rõ mình từng kiên quyết bênh vực tính năng tạo style cho thanh cuộn của IE6 trên các forum đầu những năm 2000. Khi đó phía Mozilla gọi nó là thứ đáng ghét
      Giờ đã lớn tuổi hơn, vừa có sức để nhìn lại vừa có điểm yếu là thị lực kém đi, tôi có thể thừa nhận rằng mình đã sai. Nó quá dễ bị lạm dụng
    • Cuộn mượt cũng nên được đưa vào danh sách đó. Dù cuộn bằng bánh xe chuột hay di chuyển giữa các từ tìm được bằng Ctrl-F thì cũng vậy
      May là có thể ghi đè bằng uBlock Origin
    • Hệ sinh thái rộng lớn của các tác giả extension cũng đáng được khen. Cuối bài, tác giả khen sidebar minimap như một bản nâng cấp của thanh cuộn hiện có, và thực sự có thứ như vậy
      https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
    • Nó cũng hoạt động trên mobile, nhưng cần tìm đúng câu thần chú để ghi đè
      Có lẽ đây là cái đúng
      <https://www.makeuseof.com/change-firefox-scrollbar-style/>

  • Tác giả nhìn thấy một nửa vấn đề nhưng lại đề xuất một nửa tệ hại của giải pháp
    Thanh cuộn không chỉ là một bộ điều khiển, mà còn là chỉ báo vị trí. Nó cho biết viewport hiện tại đang ở đâu trong một vùng hiển thị lớn hơn, chẳng hạn như một danh sách dài
    Việc ẩn thanh cuộn như một số GUI, chẳng hạn macOS, là rất thiếu tôn trọng, giống như làm cho nút bấm không phân biệt được với văn bản, hoặc đặt chữ màu xám nhạt trên nền xám nhạt
    Giải pháp đã có sẵn và gần như được triển khai phổ biến: bánh xe cuộn của chuột và thao tác cuộn trên trackpad
    Rất hiếm khi có một vùng xem có thể cuộn bằng thanh cuộn nhưng lại không thể cuộn bằng gesture trackpad tiêu chuẩn hoặc bánh xe chuột. Chuột của tôi còn cuộn ngang được bằng bánh xe, và điều khiển TrackPoint cũng vậy
    Cách cuộn này thậm chí không cần con trỏ nằm trên thanh cuộn, chỉ cần nó nằm trên vùng xem/điều khiển/widget mong muốn
    Ngay cả với thiết bị nhập không chính xác, tay run, hay thị lực kém, việc này vẫn rất dễ làm
    Nhưng khi đã có một cách cuộn tự nhiên và dễ dàng như vậy, ta lại càng nhớ thanh cuộn hơn khi nó đóng vai trò chỉ báo
    Minimap đôi khi hữu ích nhưng nhiều lúc thì không; cá nhân tôi thấy trong soạn thảo văn bản nó chỉ cồng kềnh mà chẳng giúp ích gì. Tất nhiên tôi ủng hộ việc có nó như một tùy chọn cho những ai thích

    • Bánh xe cuộn và gesture là thiết bị chuyển trang, và thanh cuộn cũng làm vai trò đó, nhưng đồng thời nó còn là một bộ điều khiển kiểu “đưa tôi đến giữa tài liệu”
      Với giả định rằng tài liệu phản hồi đúng, đặc biệt trong tài liệu lớn, thanh cuộn cho phép di chuyển qua những khoảng rất lớn một cách dễ dàng. Nhưng trên web ngày nay thì khó mà tin vào giả định đó
      Với những file PDF cũ, lớn, không có liên kết và dùng số trang theo mục kiểu “B-29”, tôi đã vô số lần dùng thanh cuộn để gần như tìm kiếm nhị phân nhằm tìm một trang bị chôn sâu
      Tất nhiên web hiện đại, với việc lạm dụng lazy loading và cuộn vô hạn, gần như đã phá hủy khả năng dùng thanh cuộn làm chỉ báo
      Trên Mac, nhiều lần tôi đã nhấn Cmd-mũi tên xuống để nhảy đến cuối tài liệu, hy vọng rằng có một điểm kết thúc, và mong rằng tất cả các phần nhúng làm hỏng định dạng sẽ tải xong
      Nhưng rốt cuộc cứ như đang leo lên một đoàn tàu không thấy điểm cuối, không biết mình đã đi được bao xa và còn bao nhiêu nữa
      Vì vậy, vì thanh cuộn trên thực tế đã trở nên vô dụng, tôi đang dùng bánh xe chuột có trọng lượng và ổ bi, được thiết kế cho doom scrolling tốc độ cao
    • Có vẻ bạn chưa đọc bài. Ngay từ đoạn đầu đã nói “có thể bạn sẽ bảo đó là công dụng của bánh xe cuộn, nhưng không phải ai cũng có thể dùng bánh xe cuộn hay vuốt trên màn hình cảm ứng”
      Ngay đoạn kế tiếp cũng bàn về khó khăn mà thanh cuộn nhỏ/ẩn gây ra cho các phương thức nhập khác, chẳng hạn thiết bị theo dõi ánh mắt
    • Đúng vậy. Cuối cùng cũng có người hiểu thanh cuộn dùng để làm gì
      Vai trò chính của thanh cuộn là cho người dùng thấy tài liệu lớn hơn cửa sổ, và vai trò thứ hai là cho thấy phần nào của tài liệu đang được hiển thị. Cho phép người dùng cuộn không phải là chức năng chính
      Tôi đã thật sự ngạc nhiên khi Apple bắt đầu ẩn thanh cuộn theo mặc định trên macOS. Có vẻ các nhà thiết kế UI của Apple không biết các control UI cơ bản thực sự làm gì
    • Thiết bị nhập để cuộn không phải lúc nào cũng được cung cấp phổ biến
      Người dùng Wacom/bút không có bánh xe cuộn
      Nhiều trackball cũng không có bánh xe cuộn, dù một số có vòng cuộn quanh viên bi
      Tôi đã tháo bánh xe cuộn khỏi chuột vì ngón tay dùng để cuộn bị chấn thương do lặp lại. Cũng có lúc tôi dùng tay cầm chuột quá duỗi, nên phải dùng trackball bằng tay còn lại trong vài tuần
    • Khi cần cuộn một quãng rất xa, bánh xe chuột sẽ sụp đổ

  • Cũng cần nói về viền cửa sổ. Tôi mở chồng nhiều cửa sổ VS Code có nền đen và viền đen, lại không có bóng đổ
    Hoàn toàn không thể thấy khung/viền của một cửa sổ nằm ở đâu trên cửa sổ khác. Đây đáng lẽ phải là vấn đề ở cấp hệ điều hành, nhưng apparently lại là vấn đề của ứng dụng
    Hơn nữa, VS Code đã “rút lại” hỗ trợ thiết lập viền: https://github.com/microsoft/vscode/issues/160159

    • Có thêm nhiều nội dung về viền và thanh tiêu đề ở đây
      https://news.ycombinator.com/item?id=37865824
      Theo giả thuyết của tôi, các nhà thiết kế dường như nhắm đến những người dùng chỉ xem một cửa sổ toàn màn hình tại một thời điểm
      Người dùng mẫu của họ ngồi trước laptop 13 inch trong căn phòng có ánh sáng lý tưởng và không phản chiếu, không di chuyển hay đổi kích thước cửa sổ, và mỗi ngày cũng không mở quá 3 tab/tài liệu

  • Mỗi lần đọc những bài như thế này hay các blog về UX, tôi lại thấy quá rõ rằng chúng ta ít quan tâm đến khả năng tiếp cận đến mức nào
    Thiết kế “tốt” có thể tiếp cận được thì khá nhàm chán và ít rườm rà hơn nhiều so với những gì người ta kỳ vọng ở các web app hiện đại
    Sau khi đọc cuốn sách về form của Adam Silver, tôi nhận ra rằng xét từ góc độ khả năng tiếp cận, chúng ta đang làm sai hoàn toàn, nhưng khả năng tiếp cận không phải là ưu tiên

    • Thật mỉa mai là để bình luận có thể tiếp cận được, người đọc lại phải tra xem a11y có nghĩa là “accessibility”
    • Nhìn từ góc độ kinh doanh thì điều đó không hẳn là sai. Nếu doanh nghiệp làm những việc mà họ không thể làm khi xây một website có khả năng tiếp cận, thì về mặt tính toán, nhiều khi kết quả lại tốt hơn
      Đặc biệt, dark pattern đi ngược lại rất mạnh với khả năng tiếp cận
      Vì vậy cần có luật bắt buộc về khả năng tiếp cận

  • Bạn có biết điều gì đang trở thành vấn đề về khả năng tiếp cận đối với nhiều người trên 40 tuổi không? Đó là chữ trắng trên nền tối
    Tôi nghĩ mình nghe mãi cũng không chán những lập luận đòi làm sao để người ở độ tuổi của tôi có thể đọc được trang web
    Mở công cụ dành cho nhà phát triển và sửa CSS của tác giả thì tôi đọc được, nhưng lại khiến shell script không đọc được nữa

    • Dù chưa đến 40 tuổi, tổ hợp này cũng gây áp lực cực lớn lên mắt. Đọc vài đoạn rồi nhìn vào tường thì chữ dư ảnh vẫn còn trong tầm nhìn hơn 30 giây
      Khó chịu đến mức, nếu chọn toàn bộ văn bản mà độ tương phản nền tối/chữ trắng vẫn không dịu đi, tôi sẽ không đọc trang đó luôn
    • Đáng tiếc là các yêu cầu về khả năng tiếp cận thường xung đột với nhau, và người làm trang web cũng không có vô hạn thời gian để bảo đảm tùy chọn cho tất cả mọi người
      Cũng có thể cân nhắc tắt hẳn CSS
    • Tôi chưa 40, nhưng trường hợp của tôi thì ngược lại. Tôi bị ruồi bay trước mắt khá nặng nên trên nền trắng chúng rất nổi bật
      Điều thật sự tốt trong 5 năm qua là hầu hết giao diện người dùng lớn giờ đều cung cấp cả dark mode lẫn light mode
    • Trên trình duyệt, bạn nên thử mày mò tiện ích mở rộng Dark Reader. Thường nó được dùng cho dark mode toàn cục, nhưng cũng có thể đặt white mode theo từng site hoặc toàn cục
    • Không hẳn là cùng một vấn đề, nhưng tôi thường thấy chữ màu tối hoặc xám trung bình đặt trên nền sáng hoặc xám trung bình
      Cách giải quyết của tôi là cái này
      https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
      Ít nhất nó ép văn bản thành màu đen. Khá ổn định, và cũng dễ đặt ngoại lệ khi thỉnh thoảng cần

  • Tôi đồng ý rằng thanh cuộn đang chết dần và trở nên không dùng được. Thanh cuộn phải rộng, nhìn thấy rõ và dễ bấm trúng
    Nó phải có kích thước tỷ lệ để biểu thị phần hiện đang thấy trong tài liệu, và phần di chuyển phải có đặc điểm gợi cảm giác ma sát, chứ không phải trơn trượt
    Các nút mũi tên nên được đặt cùng nhau, không phải ở hai đầu đối diện, và phải dùng màu để báo trạng thái hover và nhấn chuột
    Trong các thanh cuộn cổ điển được nêu ở đây, https://scrollbars.matoseb.com/ Nextstep là gần đáp ứng điều kiện nhất, còn Mac OS 8 nhìn chung là đẹp nhất theo tôi

    • Thêm vào đó, nếu tài liệu hỗ trợ, cũng nên có tùy chọn cho phép pan hai chiều từ một widget thanh công cụ duy nhất. Tôi từng thấy cách triển khai như vậy, nhưng chưa từng thấy dạng các nút mũi tên nằm cùng nhau thay vì ở hai đầu
      Ngày xưa từng có một lĩnh vực nghiên cứu tên là tương tác người-máy tính, nơi người ta học về định luật Fitts và việc các cạnh màn hình trên thực tế có kích thước vô hạn nên đặc biệt có giá trị
      Tôi đang chịu phạt bằng cách mở MS Teams trên OS X, cửa sổ áp sát mép phải màn hình và thanh cuộn nằm ở cạnh phải
      Khi đẩy chuột sang phải, rồi bấm để cố nắm lấy thanh cuộn đã mở rộng khi rê chuột và chạm tới tận pixel mép màn hình, thì cả cửa sổ bị kéo đi
      Tôi không biết làm sao chúng ta lại đi đến mức này. Đã từng có thời người ta tích cực nghiên cứu thế nào là giao diện người dùng tốt, nghiên cứu đó được phản ánh vào trải nghiệm người dùng thực tế, và kết quả thì thấy rõ
    • Tôi chưa từng nghĩ rằng các nút mũi tên nên được đặt cạnh nhau chứ không phải ở hai đầu đối diện, nhưng nghe có lý
      Tôi tò mò vì sao cách đó lại hiếm đến vậy, ngoài lý do “vì xưa nay vẫn thế”

  • Người ta nói “các designer không kiểm thử khả dụng với người dùng không rành kỹ thuật”, nhưng có làm thì cũng chẳng khác mấy
    Tôi làm web developer gần 25 năm và đã cộng tác với nhiều designer; thứ họ quan tâm là layout pixel-perfect khớp với “tầm nhìn” của họ. UX thậm chí còn không phải một ý nghĩ thoáng qua

    • Không phải designer nào cũng vậy, nhưng đúng là nhiều người như thế. Tôi từng thấy một designer sau khi bước ra khỏi một nghiên cứu UX với người dùng thật đã nói: “đây chỉ là một điểm dữ liệu thôi, và chúng tôi cho rằng những người dùng đó sai”
      Trong những trường hợp như vậy thì thuyết phục cũng vô ích