Có thể ghép nhiều trang HTML nhỏ bằng điều hướng để tạo tương tác

 (blog.jim-nielsen.com)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Cách tiếp cận (L)ots of (L)ittle ht(M)l page(s) thay thế tương tác bên trong trang dựa trên JavaScript bằng việc di chuyển giữa nhiều trang HTML nhỏ
  • Tương tác được cấu thành bằng điều hướng giữa các trang HTML, được cải thiện trong môi trường hiện đại bằng CSS view transitions, và chỉ thêm một chút JavaScript khi cần
  • Menu của blog không phải là UI mở rộng bằng JavaScript, mà hoạt động bằng cách đi theo liên kết <a href="/menu/"> để chuyển tới một trang dành riêng cho menu
  • Việc đóng menu về cơ bản cũng là một liên kết đến /, nhưng nếu có document.referrer thì JavaScript sẽ chạy history.back() để không làm tích thêm mục mở/đóng menu vào lịch sử duyệt web
  • Khi dựa vào điều hướng liên kết, tức tính năng mặc định của trình duyệt, thì nó vẫn hoạt động trên thiết bị cũ, trình duyệt cũ và cả môi trường tắt JavaScript; đồng thời, càng giữ kích thước trang nhỏ thì tương tác càng nhanh và vững chắc

Cách triển khai menu và kết quả thiết kế

  • Cả mở lẫn đóng đều xử lý bằng liên kết

    • Ở trang bình thường có liên kết tới trang menu, còn trong trang menu thì liên kết đó đổi thành “X” và đóng vai trò đóng menu
    • Hành động đóng về cơ bản cũng là liên kết tới /, nhưng nếu có document.referrer thì JavaScript sẽ chạy history.back() để không thêm mục mở/đóng menu vào lịch sử duyệt web của trình duyệt
    • Cách triển khai đơn giản hóa như sau 
      <!-- Normal page -->
<nav>
  <a href="/menu/">
    <svg>...</svg>
  </a>
</nav>

<!-- Menu page -->
<nav>
  <a href="/" onclick="document.referrer ? history.back() : window.location.href = '/'; return false;">
    <svg>...</svg>
  </a>
</nav>

  • Phân biệt truy cập trực tiếp và di chuyển nội bộ

    • Dùng document.referrer để phân biệt người dùng đến trang menu thông qua di chuyển bên trong blog hay truy cập trực tiếp như nhập URL
    • Nếu là di chuyển nội bộ thì có thể chạy history.back() một cách có ý nghĩa, còn nếu là truy cập trực tiếp thì sẽ chuyển tới /

  • Cách tiếp cận định hình thiết kế

    • Đây là một lời giải trông có vẻ đơn giản, nhưng cần đồng thời cân nhắc bản chất của điều hướng, tương tác trải dài qua nhiều trang và cách giữ kích thước trang luôn nhỏ
    • Cần giữ kích thước trang nhỏ để tương tác luôn nhanh, vững chắc và trực quan
    • Nếu nhìn trình duyệt không phải là một runtime để thực thi, tải về, biên dịch rồi hiển thị mã tùy ý, mà là công cụ để duyệt tài liệu, thì có thể tạo ra những website đơn giản hơn rất nhiều so với những gì các công cụ thường dẫn dắt

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Lobste.rs

  • Bình thường tôi luôn thích cách phản hồi bằng HTML mọi lúc, nhưng riêng phần menu thì tôi chưa chắc
    Tôi muốn nghe ý kiến của chuyên gia về khả năng truy cập xem giữa phần tử có thể bật/tắt và việc chuyển hẳn sang một trang khác để mở menu thì cái nào tốt hơn
    Ở đây Popover API có vẻ là giải pháp tốt hơn. Vì nó có thể cung cấp menu không cần JavaScript mà không phải thực hiện một vòng yêu cầu đầy đủ
    Còn lại thì tôi đồng ý rằng phần lớn trường hợp không cần phải sợ chuyển trang. Giờ đây ngay cả kiểu điều hướng như SPA trên site SSR/tĩnh cũng hầu như luôn không khó để làm cho có khả năng truy cập

    • Tôi không phải chuyên gia accessibility, nhưng với tư cách người đã cài NVDA để phát triển web, tôi không cảm nhận khác biệt lớn về trải nghiệm người dùng
      Chuyển trang sẽ đặt lại vị trí hiện tại, nhưng nếu mục đích là mở menu và thực sự đi tới menu thì hai cách này khá giống nhau
      Tuy vậy, giống như cả những người không dùng screen reader, việc mở menu mà lại chuyển sang trang mới vẫn thấy khá kỳ
    • Từ khóa ở đây là can, không phải should. Nếu trang HTML phù hợp cho tương tác thì dùng, còn nếu cách khác phù hợp hơn thì dùng cách đó
      Ví dụ nếu hỏi nên tạo trạng thái mở/đóng của một component bằng hai trang HTML khác nhau hay dùng thẻ <details>, thì dĩ nhiên là cách sau
      Tương tự, dùng Popover API cũng hoàn toàn ổn. Ý chính là tránh để tương tác trong trang phải cần JavaScript, chứ không phải khăng khăng dùng điều hướng HTML nhiều trang

  • Cách được nêu ra tải menu động bằng JavaScript và onclick, nên phát sinh độ trễ và thêm một điểm dữ liệu nữa vào hành trình người dùng
    Thay vào đó có thể đặt menu ngay trong từng trang và dùng phần tử <details> hoặc selector CSS :focus-within để hiện hoặc ẩn nó
    https://nlnet.nl hoạt động theo cách này

  • Cách tiếp cận được mô tả thực ra không hoạt động đúng. Nếu tắt JavaScript, mở một bài blog rồi mở và đóng menu, bạn sẽ bị đưa về trang chủ (/) thay vì bài gốc
    Muốn đặt liên kết đúng cho nút đóng thì backend bắt buộc phải render menu động, khi đó cách này mới đứng vững
    Cá nhân tôi thích Popover API hơn nếu có thể. Như vậy có thể render mọi thứ tĩnh hoàn toàn mà không cần backend

    • Liên kết biểu tượng X trong menu trỏ tới https://blog.jim-nielsen.com/, nhưng khi bật JavaScript thì có vẻ trình xử lý onclick sẽ chặn điều hướng 
      document.referrer  
  ? history.back()  
  : window.location.href = '/';  
return false;
      Nó đưa người dùng tới trang khác với nơi ghi trong href, nên đây là trải nghiệm người dùng tệ. Tôi thường rê chuột lên link để kiểm tra đích đến, nên cảm giác bị đánh lừa như vậy không dễ chịu chút nào

  • Một mặt thì tôi thật sự rất thích. Chỉ với HTML cũng có thể làm được nhiều việc mượt hơn và đơn giản hơn JavaScript
    Mặt khác, cách này có vẻ chủ yếu hợp trên di động. Nếu là trang desktop thì tôi sẽ mong menu luôn hiện hoặc bật ra, chứ không phải yêu cầu chuyển trang
    Vậy chẳng lẽ giờ lại cần hai bộ trang cho từng trình duyệt sao

    • Ngược lại, trên di động nếu kết nối không ổn định thì phải chuyển sang menu một lần rồi lại chuyển tiếp tới đích
      Ma sát tăng gấp đôi
    • Có vẻ bạn còn khá trẻ. Cách đây 20~30 năm mọi website đều hoạt động kiểu này, và HTML phần nào cũng được thiết kế để dùng như vậy
      JavaScript gần như là thứ phát sinh ngoài dự tính
      Tôi thấy lạ khi cảm giác cách này khó hoặc phức tạp hơn bất kỳ giải pháp JavaScript nào. Đây rõ ràng là cách đơn giản và dễ nhất để làm website

  • Tôi không thích kiểu điều hướng này, nhưng lại thích hiệu ứng chuyển cảnh, và trước giờ không biết là làm được như vậy
    Tôi cũng đã áp dụng nó cho site của mình dùng static generator C++ tự viết và thư viện template: https://vittorioromeo.com/
    Tôi nghĩ nó đặc biệt hợp với trình chuyển đổi giao diện tối/sáng

  • Trên desktop, nhấn “menu” mà lại bị chuyển sang trang khác thì không dễ chịu. Việc tải lại toàn bộ trang xảy ra nên khác kỳ vọng và khá khó chịu
    Với tôi thì nó làm đứt mạch đọc và mạch suy nghĩ. Khi nhấn liên kết sang site khác, tôi có cảm giác như rời khỏi căn phòng này để sang chỗ khác nên chấp nhận bỏ lại phòng cũ; nhưng nếu điều đó xảy ra với menu thì giống như đi ra cửa rồi thấy mình đang ở hẳn một căn phòng khác, nên rất khó chịu
    Ý tưởng thì thành thật mà nói là hay, nhưng cảm giác sử dụng thực tế lại không tốt
    Và tôi cũng không biết đang nói tới hiệu ứng chuyển cảnh nào. Ở môi trường của tôi, nhấn nút Menu chỉ đơn giản là tải trang Menu như bình thường

    • Chuyển cảnh view giữa các tài liệu hiện vẫn chưa chạy trên Firefox
      Có thể cũng không chạy trên các trình duyệt khác, nhưng trình duyệt chính của tôi là Librewolf, một bản fork của Firefox
      Trên Chromium thì có thấy hiệu ứng chuyển cảnh

  • Ý tưởng thú vị, nhưng tôi tự hỏi trên desktop nó sẽ hoạt động thế nào
    Menu kiểu nguyên trang có vẻ hơi quá tay, nên cách thay cả trang trông không thật sự phù hợp

  • Không thấy nhắc tới preload để giảm độ trễ khi tải trang menu
    Tôi muốn biết nếu dùng cái này thì sẽ hoạt động tốt tới đâu

    • Cũng cần thêm cache header đúng cách. Ở đây có lẽ chỉ cần header expires đơn giản là đủ
      Khi đó trình duyệt cũng không cần quay về máy chủ để xác thực trước khi hiển thị, nên sẽ cho cảm giác rất nhanh

  • Vài năm trước tôi có xem một game văn bản do @misty làm, dùng các liên kết đơn giản như tương tác để tạo ra ảo giác về lựa chọn
    HTML đơn giản cùng phần kể chuyện mạnh đã để lại ấn tượng sâu sắc với tôi