สามารถต่อหน้า HTML เล็กๆ จำนวนมากเข้าด้วยกันด้วยการนำทางเพื่อสร้างปฏิสัมพันธ์ได้

 (blog.jim-nielsen.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนวทาง (L)ots of (L)ittle ht(M)l page(s) แทนที่ ปฏิสัมพันธ์ภายในหน้าที่ขับเคลื่อนด้วย JavaScript ด้วยการย้ายไปมาระหว่างหน้า HTML ขนาดเล็กหลายหน้า
  • องค์ประกอบของปฏิสัมพันธ์ถูกจัดวางเป็น การนำทาง ระหว่างหน้า HTML และในสภาพแวดล้อมสมัยใหม่ก็ปรับให้ลื่นไหลขึ้นด้วย CSS view transitions พร้อมเติม JavaScript เพียงเล็กน้อยเมื่อจำเป็นเท่านั้น
  • Menu ของบล็อกไม่ได้เป็น UI แบบขยายออกด้วย JavaScript แต่ใช้วิธีไปยังหน้าเมนูเฉพาะผ่านลิงก์ <a href="/menu/">
  • การปิดเมนูก็ใช้ลิงก์ไปยัง / เป็นค่าพื้นฐานเช่นกัน แต่ถ้ามี document.referrer ก็จะใช้ JavaScript เรียก history.back() เพื่อไม่ให้มีรายการเปิด·ปิดเมนูสะสมอยู่ในประวัติการเข้าชม
  • หากพึ่งพาความสามารถพื้นฐานของเบราว์เซอร์อย่าง การคลิกลิงก์ ก็จะยังทำงานได้บนอุปกรณ์รุ่นเก่า เบราว์เซอร์รุ่นเก่า และสภาพแวดล้อมที่ปิด JavaScript ไว้ อีกทั้งยิ่งรักษาขนาดหน้าให้เล็กเท่าไร ปฏิสัมพันธ์ก็ยิ่งเร็วและทนทานมากขึ้น

วิธีทำเมนูและผลลัพธ์ด้านการออกแบบ

  • ใช้ลิงก์ทั้งตอนเปิดและตอนปิด

    • ในหน้าทั่วไปจะมีลิงก์ไปยังหน้าเมนู และในหน้าเมนูลิงก์นั้นจะเปลี่ยนเป็น “X” เพื่อทำหน้าที่ปิดเมนู
    • การปิดก็ยังคงใช้ลิงก์ไปยัง / เป็นค่าพื้นฐาน แต่ถ้ามี document.referrer ก็จะใช้ JavaScript เรียก history.back() เพื่อไม่ให้รายการเปิด·ปิดเมนูถูกเพิ่มลงในประวัติเบราว์เซอร์
    • ตัวอย่างการทำแบบย่อมีดังนี้ 
      <!-- 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>

  • แยกความต่างระหว่างการเข้าตรงกับการย้ายมาจากภายในไซต์

    • ใช้ document.referrer เพื่อตรวจว่าเข้าหน้าเมนูมาผ่านการย้ายภายในบล็อก หรือเข้าตรงด้วยการพิมพ์ URL และวิธีคล้ายกัน
    • หากเป็นการย้ายมาจากภายใน ก็สามารถเรียก history.back() ที่มีความหมายได้ และถ้าเป็นการเข้าตรงก็จะย้ายไปที่ /

  • วิธีเข้าถึงนี้เป็นตัวกำหนดรูปแบบการออกแบบ

    • แม้จะดูเป็นคำตอบที่เรียบง่าย แต่ต้องคิดร่วมกันทั้งเรื่องแก่นของการนำทาง ปฏิสัมพันธ์ที่คร่อมหลายหน้า และวิธีรักษาขนาดหน้าให้เล็ก
    • ต้องรักษาขนาดหน้าให้เล็กไว้ เพื่อให้ปฏิสัมพันธ์รวดเร็ว ทนทาน และยังคงเข้าใจได้โดยสัญชาตญาณ
    • หากมองเบราว์เซอร์ไม่ใช่เป็นรันไทม์ที่คอยรัน ดึง และคอมไพล์โค้ดตามอำเภอใจเพื่อแสดงผล แต่เป็น เครื่องมือสำหรับสำรวจเอกสาร ก็จะสร้างเว็บไซต์ที่เรียบง่ายกว่าที่เครื่องมือสมัยใหม่มักชักนำให้ทำได้มาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Lobste.rs

  • โดยปกติผมชอบแนวทางที่ ตอบกลับเป็น HTML เสมอ แต่กรณีเมนูยังไม่ค่อยแน่ใจ
    อยากฟังความเห็นจากผู้เชี่ยวชาญด้านการเข้าถึงว่า ระหว่างองค์ประกอบที่สลับเปิดปิดได้กับการสลับทั้งหน้าเพื่อเปิดเมนู แบบไหนดีกว่ากัน
    ในกรณีนี้ Popover API ดูเหมือนเป็นทางออกที่ดีกว่า เพราะสามารถทำเมนูที่ไม่ต้องใช้ JavaScript ได้โดยไม่ต้องมีการรับส่งคำขอทั้งรอบ
    นอกนั้นส่วนใหญ่ก็เห็นด้วยว่าไม่จำเป็นต้องกลัวการเปลี่ยนหน้า ตอนนี้แม้แต่การนำทางแบบ SPA ก็แทบจะทำให้เข้าถึงได้บน SSR·เว็บไซต์แบบสแตติกได้ไม่ยากเสมอไป

    • ไม่ใช่ผู้เชี่ยวชาญด้านการเข้าถึง แต่ในฐานะคนที่ติดตั้ง NVDA ไว้เพื่อพัฒนาเว็บ ผมแทบไม่รู้สึกถึงความต่างด้านประสบการณ์ใช้งาน
      การย้ายหน้าจะรีเซ็ตตำแหน่งปัจจุบัน แต่ถ้าตั้งใจจะเปิดเมนูและไปถึงเมนูจริง ๆ ทั้งสองแบบก็คล้ายกันมาก
      เพียงแต่เหมือนกับคนที่ไม่ได้ใช้สกรีนรีดเดอร์ การเปิดเมนูแล้วถูกพาไปหน้าใหม่ก็ให้ความรู้สึกแปลกพอสมควร
    • คำสำคัญคือ can ไม่ใช่ should ถ้า HTML page เหมาะกับปฏิสัมพันธ์นั้นก็ใช้ไป ถ้ามีวิธีอื่นที่เหมาะกว่าก็ใช้แบบนั้น
      เช่น ถ้าถามว่าจะทำสถานะขยาย/ยุบของคอมโพเนนต์เป็น HTML คนละสองหน้า หรือจะใช้แท็ก <details> คำตอบก็ชัดเจนว่าอย่างหลัง
      เช่นเดียวกัน การใช้ Popover API ก็โอเคเต็มที่ ประเด็นคือพยายามหลีกเลี่ยงไม่ให้ปฏิสัมพันธ์ในหน้าต้องพึ่ง JavaScript ไม่ใช่ยืนกรานว่าจะต้องใช้การนำทางแบบ HTML หลายหน้า

  • วิธีที่เสนอทำให้เมนูถูกโหลดแบบไดนามิกด้วย JavaScript และ onclick จึงเกิด latency และเพิ่มจุดข้อมูลอีกหนึ่งจุดในเส้นทางการใช้งานของผู้ใช้
    แทนที่จะทำแบบนั้น สามารถใส่เมนูไว้ในแต่ละหน้าแล้วใช้ <details> หรือ CSS selector :focus-within เพื่อแสดงหรือซ่อนได้
    https://nlnet.nl ทำงานแบบนี้

  • แนวทางที่อธิบายไว้จริง ๆ แล้วทำงานไม่ถูกต้อง ถ้าปิด JavaScript เปิดบทความบล็อก แล้วลองเปิดและปิดเมนู ระบบจะพาไปหน้าแรก (/) แทนที่จะกลับไปบทความเดิม
    ถ้าจะใส่ลิงก์ที่ถูกต้องให้ปุ่มปิด วิธีนี้จะใช้ได้ก็ต่อเมื่อ backend เรนเดอร์เมนูแบบไดนามิก
    ส่วนตัวถ้าทำได้จะชอบ Popover API มากกว่า เพราะจะเรนเดอร์ทุกอย่างแบบสแตติกได้โดยไม่ต้องมี backend

    • ลิงก์ไอคอน X ในเมนูชี้ไปที่ https://blog.jim-nielsen.com/ แต่เมื่อเปิด JavaScript ดูเหมือนตัวจัดการ onclick จะดักการนำทางไว้ 
      document.referrer  
  ? history.back()  
  : window.location.href = '/';  
return false;
      มันพาไปหน้าที่ต่างจากที่เขียนไว้ใน href จึงเป็น ประสบการณ์ผู้ใช้ที่แย่ ผมมักเอาเมาส์ไปชี้ลิงก์เพื่อดูปลายทางก่อนเสมอ และไม่ชอบความรู้สึกเหมือนถูกหลอกแบบนี้

  • ด้านหนึ่งคือชอบมากจริง ๆ แค่ HTML ก็ทำอะไรได้หลายอย่างที่ลื่นไหลและเรียบง่ายกว่า JavaScript
    แต่อีกด้านหนึ่ง วิธีนี้ดูเหมาะกับมือถือเป็นหลัก ถ้าเป็นหน้าเดสก์ท็อปก็มักคาดหวังให้เมนูแสดงอยู่ตลอดหรือเด้งออกมา ไม่ใช่บังคับให้ย้ายหน้า
    ถ้าอย่างนั้นเราจะต้องมี หน้าคนละสองชุด ตามเบราว์เซอร์กันแล้วหรือ

    • ในทางกลับกัน ถ้าการเชื่อมต่อบนมือถือไม่เสถียร ก็ต้องย้ายไปหน้าเมนูหนึ่งครั้งแล้วค่อยย้ายไปหน้าปลายทางอีกครั้ง
      ความฝืดเพิ่มเป็นสองเท่า
    • คงยังอายุน้อยพอสมควร เมื่อ 20~30 ปีก่อน เว็บไซต์ทั้งหมดก็ทำงานกันแบบนี้ และ HTML ก็ถูกตั้งใจให้ใช้งานประมาณนั้นในระดับหนึ่ง
      JavaScript แทบจะเป็นของที่เกิดขึ้นมาโดยบังเอิญ
      เลยแปลกใจที่บางคนรู้สึกว่าวิธีนี้ยากหรือซับซ้อนกว่าวิธีแก้ด้วย JavaScript ใด ๆ ทั้งที่มันชัดเจนว่าเป็นวิธีสร้างเว็บไซต์ที่ง่ายและตรงไปตรงมาที่สุด

  • ไม่ค่อยชอบวิธีนำทาง แต่ชอบ เอฟเฟกต์เปลี่ยนผ่าน และไม่เคยรู้มาก่อนว่าทำแบบนี้ได้
    ผมเอาไปใช้กับเว็บไซต์ของตัวเองที่ใช้ static generator และ template library ที่เขียนเองด้วย C++: https://vittorioromeo.com/
    คิดว่าเข้ากับตัวสลับธีมมืด/สว่างได้ดีเป็นพิเศษ

  • บนเดสก์ท็อป การคลิก “menu” แล้วถูกพาไปอีกหน้าทำให้รู้สึกไม่ดี มันเกิดการรีเฟรชทั้งหน้า เลยรบกวนความรู้สึกมากกว่าที่คาด
    สำหรับผม มันตัดจังหวะการอ่านและกระแสความคิด เวลาคลิกลิงก์ไปเว็บอื่นจะเหมือนออกจากห้องเดิมไปอีกห้องหนึ่ง จึงพร้อมทิ้งห้องเก่าไว้ข้างหลัง แต่ถ้าเกิดแบบนี้กับเมนู มันเหมือนเดินไปที่ประตูแล้วกลับโผล่ไปอีกห้องหนึ่งเลย ทำให้ไม่สบายใจ
    พูดตรง ๆ คือชอบไอเดียนี้ แต่ความรู้สึกเวลาใช้งานจริงไม่ดี
    แล้วก็ไม่รู้ว่าหมายถึงเอฟเฟกต์เปลี่ยนผ่านแบบไหน เพราะในเครื่องผมพอกดปุ่ม Menu มันก็แค่โหลดหน้า Menu ตามปกติ

    • การเปลี่ยนมุมมองระหว่างเอกสาร ยังใช้ไม่ได้ใน Firefox
      อาจใช้ไม่ได้ในเบราว์เซอร์อื่นด้วย แต่เบราว์เซอร์หลักของผมคือ Librewolf ซึ่งเป็น Firefox fork
      ใน Chromium มองเห็นเอฟเฟกต์เปลี่ยนผ่าน

  • เป็นไอเดียที่น่าสนใจ แต่สงสัยว่าจะทำงานบนเดสก์ท็อปอย่างไร
    เมนูแบบเต็มหน้าดูค่อนข้างเกินไป เลยรู้สึกว่าการสลับทั้งหน้าไม่ค่อยเหมาะ

  • ไม่ได้พูดถึง preload สำหรับลดเวลาหน่วงของการโหลดหน้าเมนู
    อยากรู้ว่าถ้าใช้แล้วจะได้ผลดีแค่ไหน

    • ต้องใส่ cache header ให้ถูกต้องด้วย ที่นี่อาจใช้แค่ expires header แบบง่าย ๆ ก็พอ
      แบบนั้นก็ไม่ต้องกลับไปตรวจสอบกับเซิร์ฟเวอร์ก่อนแสดงผล จึงน่าจะรู้สึกว่าเร็วมาก

  • เมื่อหลายปีก่อนเคยเห็นเกมข้อความที่ @misty ทำ ใช้ลิงก์ธรรมดาเป็นปฏิสัมพันธ์เพื่อสร้าง ภาพลวงของการเลือก
    HTML ธรรมดากับการเล่าเรื่องที่หนักแน่นทำให้มันทรงพลังมาก