รูปแบบการออกแบบที่น่าผิดหวัง: Mega-Dropdown Hover Menus

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

ไม่น่าแปลกใจที่วิธีทั่วไปในการจัดการกับความซับซ้อนนี้คือการทำให้ลูกค้าเข้าถึงการนำทางจำนวนมากได้อย่างรวดเร็ว นั่นเป็นสาเหตุว่าทำไม mega-dropdowns จึงกลายเป็นสถาบันบนเว็บ ถึงแม้ว่าส่วนใหญ่จะเป็นโครงการที่ซับซ้อนและมีขนาดใหญ่ mega-dropdown นั้นเป็นโอเวอร์เลย์ขนาดใหญ่ที่ปรากฏในการกระทำของผู้ใช้ โดยปกติแล้วจะมีลิงก์ ปุ่ม รูปขนาดย่อ และบางครั้งดร็อปดาวน์และโอเวอร์เลย์ที่ซ้อนกันอยู่ด้วยตัวมันเอง

เป็นเวลาหลายทศวรรษที่พฤติกรรมทั่วไปสำหรับการนำทางประเภทนี้คือการเปิดเมนูเมื่อ วางเมาส์เหนือ และเป็นเวลาหลายทศวรรษที่การร้องเรียนของผู้ใช้ทั่วไปเกี่ยวกับรูปแบบนี้ทำให้ขาดความแน่นอนและการควบคุมว่าการนำทางย่อยจะเปิดและปิดอย่างไรและเมื่อใด

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

เหตุใด Mega-Dropdowns Hover Menus จึงน่าผิดหวัง?

สาเหตุหลักที่ทำให้ mega-dropdowns ใช้งานยาก เป็นเพราะ ความตั้งใจและความคาดหวังไม่ตรงกัน ด้วยเมนูโฮเวอร์ เราพยายามอนุมานและดำเนินการตามเจตนาโดยเฉพาะอย่างยิ่งโดยการติดตามพฤติกรรมของเมาส์ แต่ลูกค้าของเราอาจมีวัตถุประสงค์ที่แตกต่างกันมากและมีข้อจำกัดที่แตกต่างกันมากเมื่อเข้าถึงหน้า

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

สถานการณ์ทั่วไปที่เรามักจะสำรวจคือ:

1. ลูกค้า มุ่งเป้าไปที่ลิงก์หมวดหมู่ และเดินทางไปที่นั่นโดยตรงเพื่อสำรวจรายการการนำทางย่อยในหมวดหมู่นั้น
2. ลูกค้ากำลังเลื่อนเมาส์ไปยัง เป้าหมายบนหน้าจอ แต่วิถีที่เมาส์ต้องเดินทางนั้น ครอบคลุมลิงก์นำทาง ที่เปิดเมนูดรอปดาวน์ขนาดใหญ่

อย่างไรก็ตาม ยังมีสถานการณ์อื่นๆ อีกมากมายที่ต้องพิจารณา เพียงเพื่อชื่อไม่กี่:

1. ลูกค้าต้องการ ค้นหาตัวเลือกเมกะดรอปดาวน์ ขณะพิมพ์การค้นหาการเติมข้อความอัตโนมัติ ในการทำเช่นนั้น พวกเขาต้องเปิดเมกะดรอปดาวน์อีกครั้ง หรือใช้แท็บเรียกดูแยกกัน โดยวางไว้เคียงข้างกัน
2. ลูกค้าอาจ ใช้แทร็คแพด (หรือเมาส์) เพื่อใช้งานจอแสดงผลรองขนาดใหญ่ ดังนั้นการเคลื่อนไหวของตัวชี้จะช้าลง กะทันหัน และไม่ถูกต้อง ซึ่งจะทำให้ mega-dropdown เปิดขึ้นโดยไม่ตั้งใจทุกครั้งที่ผู้ใช้หยุดชั่วคราวเมื่อเดินทางไปยัง CTA หรือตะกร้าสินค้าที่ด้านบนของหน้า
3. ลูกค้าต้องการเปิด หน้าหมวดหมู่ ดังนั้นพวกเขาจึงไปที่ลิงก์หมวดหมู่ คลิกบนหน้านั้น แต่พบการกะพริบเนื่องจากรายการดรอปดาวน์ขนาดใหญ่ปรากฏขึ้นล่าช้า
4. ด้วย เมนูย่อยที่ซ้อนกันภายใน mega-dropdown ลูกค้าต้องการสำรวจรายการที่คล้ายคลึงกันภายในหมวดหมู่ที่พวกเขาอยู่ในปัจจุบัน แต่เนื่องจากการซ้อน พวกเขาจึงต้องเปิด mega-dropdown ใหม่ครั้งแล้วครั้งเล่า และเดินทาง อุโมงค์โฮเวอร์เดียวกันซ้ำแล้วซ้ำอีก
5. ลองนึกภาพสถานการณ์เมื่อคุณต้องการ ปรับขนาดหน้าต่าง และในขณะที่คุณกำลังจะสแน็ปไปที่ขอบด้านขวาของหน้าต่าง เมนูโฮเวอร์จะแสดงขึ้นเรื่อยๆ เพียงเพราะคุณเลื่อนเคอร์เซอร์ของเมาส์ไว้ใกล้เกินไป
6. ผู้ใช้ เริ่มเลื่อนลงอย่างช้าๆ เพื่อประเมินเนื้อหาบนหน้า แต่เมนูยังคงปรากฏขึ้น และทุกครั้งที่ผู้ใช้เลื่อนเคอร์เซอร์ออกเพื่ออ่านเนื้อหาของ mega-dropdown เมนูจะหายไปโดยไม่ตั้งใจ

ปัญหาคือเราจำเป็นต้อง สนับสนุนความตั้งใจ ทั้งหมดเหล่านี้และอุบัติเหตุทั้งหมด แต่ในขณะเดียวกัน เราต้องตรวจสอบให้แน่ใจว่าเราไม่ได้สร้างประสบการณ์ที่น่ารำคาญและน่าผิดหวังสำหรับกรณีเหล่านี้เช่นกัน แน่นอน ในฐานะนักออกแบบและนักพัฒนา เราได้คิดค้นเทคนิคจำนวนหนึ่งเพื่อจัดการกับปัญหานี้

เลื่อนการเข้า/ออกล่าช้า

หนึ่งในวิธีแก้ปัญหาแรกและหนึ่งในวิธีแก้ปัญหาทั่วไปก็คือ การแนะนำการเลื่อนการเข้า/ออก เราต้องตรวจสอบให้แน่ใจว่าเมนู ไม่เปิดและไม่ปิดเร็วเกินไป เพื่อให้บรรลุเป้าหมายนั้น เราจึงแนะนำการหน่วงเวลา โดยปกติประมาณ 0.5 วินาที นั่นหมายความว่าเราให้เวลาลูกค้าประมาณ 0.5 วินาทีเพื่อ:

• ข้ามวิถีไปยังเป้าหมายระยะไกลหากจำเป็น หรือ
• ระบุว่าตั้งใจจะสำรวจการนำทางโดยอยู่ในลิงก์หมวดหมู่ mega-dropdown หรือ
• แก้ไขข้อผิดพลาดหากพวกเขาออกจากขอบเขตของ mega-dropdown โดยไม่ได้ตั้งใจ

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

แม้ว่าจะแก้ปัญหาการ กะพริบบนหน้าเว็บโดยไม่ได้ตั้งใจ แต่ก็ทำให้ เกิดความล่าช้า ในกรณีที่ผู้ใช้ออกจากรายการดรอปดาวน์ระดับเมกะนานกว่า 0.5 วินาที ส่งผลให้ทุกการโต้ตอบกับ mega-dropdown ทั่วทั้งไซต์ช้าลง น่าเสียดายที่ระบบจะสังเกตเห็นได้ชัดเจนอย่างรวดเร็ว โดยเฉพาะอย่างยิ่งหากมีการใช้การนำทางเป็นจำนวนมาก

การนำไปใช้งานบางอย่างเพิ่มการเปลี่ยนแบบ เฟด-อิน/เฟด-เอาต์ เพื่อทำให้การปรากฏของเมกะดรอปดาวน์ดูน้อยลงอย่างกะทันหัน แต่ในทางปฏิบัติ จะส่งผลให้การหน่วงเวลาการเข้า/ออกเพิ่มขึ้นเป็น 0.8–0.9 วินาที ซึ่งทำให้เห็นได้ชัดเจนยิ่งขึ้น ล่าช้า ตัวอย่างของมันคือ ADAC.de โดยมีการหน่วงเวลาเฟดอิน 100ms และการเปลี่ยนการเฟดเอาต์ 300ms (การเปลี่ยนแปลงนี้ใช้ไม่ได้เมื่อสลับไปมาระหว่างหมวดหมู่ต่างๆ ของ mega-dropdown)

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

เส้นทางการเคลื่อนที่ของเมาส์ให้อภัย: สามเหลี่ยมวิถี

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

ตัวอย่างเช่น เราสามารถใช้เทคนิคสามเหลี่ยมของ Amazon ซึ่งเราสร้าง สามเหลี่ยมวิถี ที่เชื่อมต่อตำแหน่งปัจจุบันของตัวชี้เมาส์กับขอบของพื้นที่ดรอปดาวน์ขนาดใหญ่ หากพื้นที่นั้นควรจะปรากฏถัดจากหมวดหมู่ทางด้านขวา (ตามที่แสดงในภาพด้านล่าง) เราจะเชื่อมต่อตัวชี้เมาส์กับขอบขวาบนและล่างขวาของคอนเทนเนอร์ที่แสดงหมวดหมู่

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

Chris Coyier เน้นย้ำถึงความซับซ้อนทางเทคนิคบางประการของเทคนิคนี้ในโพสต์ของเขาในเมนูดร็อปดาวน์ที่มีเส้นทางการเคลื่อนที่ของเมาส์ที่ให้อภัยมากขึ้น พร้อมกับการสาธิต JavaScript วานิลลาโดย Alexander Popov ในเรื่อง “Aim-Aware Menus”

ด้วยเทคนิคนี้ เรา ลดการเสียดสี ของการหายไปอย่างกะทันหันและการปรากฏขึ้นอีกครั้งของการนำทางย่อย แต่อาจไม่ได้ผลหากลิงก์หมวดหมู่อยู่ใกล้กันมากเกินไป หรือเราแสดงเมนูโฮเวอร์โดยวางเมาส์เหนือปุ่มที่ใหญ่กว่า เราสามารถทำได้ดีขึ้นเล็กน้อยด้วยพื้นที่ทางออกของเส้นทาง SVG

พื้นที่ทางออกของเส้นทาง SVG

เมื่อคำนวณสามเหลี่ยมวิถีโคจรด้วยเทคนิคก่อนหน้านี้ บางครั้งเราไม่เพียงติดตามตำแหน่งที่แน่นอนของตัวชี้เมาส์เท่านั้น แต่ยัง คำนวณสามเหลี่ยมใหม่ ทุกครั้งที่ขยับตัวชี้ — ตลอดเวลา เราสามารถปรับปรุงกลยุทธ์ได้โดยการคำนวณ พื้นที่ซ้อนทับ SVG โดยรวมหนึ่งครั้งและติดตามว่าตัวชี้เมาส์อยู่ภายในหรือไม่ โดยไม่ต้องคำนวณสามเหลี่ยมใหม่ตลอดเวลา ตัวอย่างที่ดีคือการใช้งานของ Hakim el Hattab ที่ดึงพื้นที่แบบไดนามิกด้วย SVG ตามตำแหน่งของรายการการนำทางบนหน้าจอ

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

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

อีกครั้ง ที่มาของปัญหาคือลูกค้า ไม่มีสิทธิ์ควบคุมว่า เมื่อใดที่ mega-dropdowns จะเปิดและปิด และมักจะไม่เข้าใจว่าเมนูเหล่านี้จะปรากฏขึ้นหรือหายไปเมื่อใด การขาดความสามารถในการคาดเดานี้มักนำไปสู่ข้อผิดพลาดและความผิดหวัง แต่บางครั้ง mega-dropdowns ยังมีปัญหาการช่วยสำหรับการเข้าถึงที่ซ่อนอยู่

ข้อผิดพลาดของการเปิด Mega-Dropdowns บน Hover

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

Mega-dropdowns ที่เปิดขึ้นเมื่อโฮเวอร์มีปัญหาการเข้าถึงมากมาย แน่นอน เราต้องสนับสนุนการนำทาง ภายใน เมกะดรอปดาวน์สำหรับผู้ใช้คีย์บอร์ดเท่านั้น และเราจำเป็นต้องตรวจสอบให้แน่ใจว่ารายการต่างๆ ได้รับการประกาศอย่างถูกต้องไปยังโปรแกรมอ่านหน้าจอเช่นกัน แต่ในแง่ของเลย์เอาต์ทั่วไป เราจำเป็นต้องระมัดระวังเกี่ยวกับตำแหน่งที่เมกะดรอปดาวน์วางอยู่

การค้นหาถูกขัดจังหวะด้วย mega-dropdown

หากมีการแสดงคุณลักษณะที่สำคัญใกล้กับการนำทาง mega-dropdown ซึ่งมักจะทำให้เกิดปัญหาและข้อร้องเรียนจำนวนมาก ตัวอย่างเช่น หาก แถบค้นหาแสดงอยู่เหนือ พื้นที่ขนาดใหญ่แบบดรอปดาวน์ สิ่งนี้จะทำให้เกิดความเสียดทานและความยุ่งยากอย่างไม่น่าเชื่อในที่สุด

เว้นเสียแต่ว่าจะใช้การเลื่อนการเข้า/ออกที่ล่าช้าเป็นเวลานานพอ mega-dropdown-overlay จะ เข้ามาขวางทางระหว่างผลการค้นหาและผลการค้นหาเสมอ ดังเช่นใน Thesauraus.com ด้านล่าง ทุกครั้งที่ผู้ใช้ย้ายออกจากแถบค้นหาไปยังผลลัพธ์ (และย้อนกลับ) เมกะดรอปดาวน์จะเข้ามาขวางทาง

การนำทางย่อยหลายรายการปรากฏขึ้นพร้อมความล่าช้า

ประสบการณ์จะยุ่งยากเมื่อมีการเปิด การนำทางย่อยหลายรายการ บนโฮเวอร์ ล่าช้า ทีละรายการ ตัวอย่างที่น่าเสียดายของการใช้งานจริงคือเว็บไซต์ Vodafone ด้านล่าง หากในกรณีนี้ ทุกรายการการนำทางทำหน้าที่เป็นลิงก์แบบสแตนด์อโลนไปยังหมวดหมู่ (นอกเหนือจากการเปิด mega-dropdown) เราน่าจะคาดหวังว่าจะ มีเสียงคลิก มากมายทั่วทั้งเว็บไซต์

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

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

นอกจากนี้ เนื่องจากการนำทางระดับที่ 4 จะปรากฏเฉพาะเมื่อวางเมาส์เหนือหากระดับการนำทางที่ 3 เปิดตามปกติ และระดับการนำทางที่ 3 จะปรากฏเฉพาะเมื่อวางเมาส์เหนือ หากระดับการนำทางที่ 2 เปิดอยู่แล้ว ให้ย้ายไปมาระหว่างหน้าที่ 4 ผู้ใช้ต้องเปิดการนำทางซ้ำแล้วซ้ำอีก และจำได้ว่าเคยคลิกตำแหน่งใดก่อนหน้านี้เพื่อเลื่อนอุโมงค์ไปที่ระดับ 4

โดยพื้นฐานแล้วเรา จะทวีคูณความล่าช้าและปัญหาอุโมงค์โฮเวอร์ที่ เราพูดถึงก่อนหน้านี้ ทำให้ผู้ใช้รอให้ระบบนำทางปรากฏขึ้นเสมอ และขอให้พวกเขา ระบุ ให้แม่นยำมากภายในทางเดินลอยเมื่อระบบนำทางปรากฏขึ้น นั่นคือที่มาของความหงุดหงิด

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

ชื่อหมวดหมู่ทำหลายอย่างเกินไป

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

มีตัวเลือกสองสามตัวในการแก้ไขปัญหานี้:

1. เพื่อระบุว่าชื่อหมวดหมู่เป็นลิงก์ การ ขีดเส้นใต้ อาจเป็นประโยชน์
2. เพื่อให้ความแตกต่างระหว่างชื่อหมวดหมู่และรายการแบบเลื่อนลงชัดเจนยิ่งขึ้น ให้เพิ่มตัวคั่นแนวตั้ง (เช่น เส้นแนวตั้ง) และไอคอน (เครื่องหมายบั้ง)
3. ปล่อยให้หัวเรื่องของหมวดหมู่เปิดไว้เฉพาะเมกะดรอปดาวน์ และ เพิ่มลิงก์ไปยังส่วน "หน้าแรก" ของหมวดหมู่ ภายใน โอเวอร์เลย์เมกะดรอปดาวน์ นอกจากนี้ยังอาจเป็นปุ่ม "ดูตัวเลือกทั้งหมด" ที่เด่นชัดแทน (ดูตัวอย่าง The Guardian ด้านบน)

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

ในกรณีก่อนหน้านี้ พวกเขามักจะคาดหวังให้เมนูดรอปดาวน์เปิด และในกรณีหลัง หน้าหมวดหมู่จะปรากฏขึ้น ที่สำคัญกว่านั้น ดูเหมือนว่าพวกเขาจะคาดหวังให้เมนูเปิดเมื่อ แตะ/คลิก แทนที่จะวางเมาส์เหนือ

Mailchimp เป็นตัวอย่างที่ดีของ mega-dropdown ที่หลีกเลี่ยงปัญหาส่วนใหญ่ที่อธิบายไว้ข้างต้น โดยที่ชื่อหมวดหมู่ทำงานเฉพาะเพื่อเปิด mega-dropdown เมนูแบบเลื่อนลง สามารถเข้าถึงได้สำหรับผู้ใช้แป้นพิมพ์ที่ มีรูปแบบ :focus เมื่อเลือกแล้ว แต่ละหมวดหมู่จะถูกเน้นเป็น ขีดเส้นใต้ และอาจทำให้บางคนคิดว่าชื่อนั้นกลายเป็นลิงก์แล้ว โดยเฉพาะอย่างยิ่งเนื่องจากการขีดเส้นใต้เหมือนกันทุกประการสำหรับลิงก์ "การกำหนดราคา" ที่ด้านบนของการนำทาง บางทีการเน้นด้วยสีพื้นหลังก็อาจจะกันกระสุนได้มากกว่านี้ ตัวอย่างการอ้างอิงที่ดีในการพิจารณาเมนูโฮเวอร์

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

การออกแบบ Mega-Dropdown ที่ดีขึ้น: แตะ/คลิก Menu

สาเหตุทั่วไปประการหนึ่งที่ทำให้ mega-dropdowns มักจะเปิดขึ้นเมื่อวางเมาส์ไว้ เนื่องจากบริษัทขนาดใหญ่หลายแห่งต้องการให้ลูกค้าเห็นตัวเลือกต่างๆ ที่มีอยู่บนเว็บไซต์อย่างรวดเร็ว ด้วยตัวเลือกการนำทางที่เปลี่ยนไปเมื่อวางเมาส์เหนือ เราจึงสามารถแสดงตัวเลือกต่างๆ ได้เร็วขึ้น และลูกค้าสามารถสำรวจตัวเลือกอื่นๆ ได้เร็วขึ้นเช่นกัน นั่นเป็นเหตุผลว่าทำไมจึงเป็นเรื่องยากที่จะจินตนาการถึงผู้ค้าปลีกอีคอมเมิร์ซรายใหญ่ที่ไม่มีโอเวอร์เลย์การนำทางขนาดใหญ่

อย่างไรก็ตาม เป็นความคิดที่ดีที่จะทดสอบว่าเวลาการมีส่วนร่วมและอัตราการคลิกผ่านยังคงเท่าเดิม (หรือเพิ่มขึ้น) หากการนำทางแบบวางเมาส์เหนือแทนที่ด้วยการนำทางด้วยการ แตะ/คลิก อันที่จริง ปัญหาส่วนใหญ่ที่ระบุไว้ข้างต้นสามารถแก้ไขได้ง่ายโดยทำอย่างนั้น: mega-dropdown overlay จะเปิดและปิดก็ต่อเมื่อผู้ใช้แจ้งการดำเนินการนี้อย่างชัดเจนเท่านั้น ดังนั้นจึงไม่จำเป็นต้องติดตามตัวชี้เมาส์ หรือปรับแต่งความล่าช้าในการเข้า/ออก นอกจากนี้ เนื่องจากไม่มีการโฮเวอร์บนมือถือ เราจึงต้องมีตัวเลือกในการเปิดเมนูด้วยการแตะ/คลิกสำหรับมือถือไม่ทางใดก็ทางหนึ่ง เพื่อให้เราสามารถคงไว้ในลักษณะนี้สำหรับหน้าจอขนาดใหญ่ได้เช่นกัน

ตัวอย่างที่ดีของการดำเนินการนี้คือเว็บไซต์ Jewish Museum Berlin แถบการนำทางด้านบนไม่เพียงแต่เปิดเมนูเมกะดรอปดาวน์เมื่อแตะและคลิก แต่ยังเปิดการนำทางแถบด้านข้างตามไอคอนด้วย นอกจากนี้ เนื่องจากผู้ใช้ต้องเปิด/ปิดโอเวอร์เลย์อย่างแข็งขัน เราจึงสามารถ เน้นหมวดหมู่ที่เลือก ด้วยสไตล์ :focus / :active

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

อย่างไรก็ตาม เนื่องจากเว็บไซต์ไม่มีตัวเลือกการนำทางมากมายที่จะแสดง จึงดูเหมือนว่าจะทำงานได้ดีมาก และนั่นเป็น ตัวอย่างอ้างอิงที่ดี ที่ควรคำนึงถึงเมื่อทำงานกับ mega-dropdown ที่สามารถเข้าถึงได้ซึ่งเปิดขึ้นเมื่อแตะ/คลิก

หากคุณมีการนำทางเพิ่มขึ้นเล็กน้อย ตัวอย่างขั้นสูงกว่าเล็กน้อยคือ Allianz.de แทนที่จะใช้โอเวอร์เลย์เมกะดรอปดาวน์ขนาดใหญ่เพียงรายการเดียว การนำทางย่อยจะถูกจัดกลุ่มเป็นรายการดรอปดาวน์ที่เล็กกว่า อย่างไรก็ตาม เมนูนี้ไม่ได้แสดงตัวเลือกทั้งหมดสำหรับแต่ละหมวดหมู่เสมอไป แต่จะเน้น ที่ตัวเลือกที่สำคัญที่สุด โดยมีลิงก์เพื่อดูตัวเลือกทั้งหมดที่ด้านล่าง รายละเอียดเดียวที่อาจหายไปคือบั้งระบุว่าเมนูแบบเลื่อนลงจะปรากฏขึ้นเมื่อคลิก

บนมือถือ mega-dropdown คือ กลุ่มของ accordion โดยมีตัวเลือกความคมชัดของสีและการเยื้องที่ดีเพื่อระบุลำดับชั้นของการนำทาง หีบเพลงแต่ละอันจะไม่แสดงรายการการนำทางมากกว่า 4 รายการในแต่ละครั้ง ตัวอย่างอ้างอิงที่ยอดเยี่ยมสำหรับการนำทาง mega-dropdown ที่ซับซ้อนซึ่งทำงานได้ดี

หากคุณกำลังมองหาการใช้งานทางเทคนิค คุณสามารถตรวจสอบ In Praise of the Unambiguous Click Menu ซึ่ง Mark Root-Wiley จะแสดงวิธีสร้างเมนูคลิกที่สามารถเข้าถึงได้ แนวคิดคือการเริ่มสร้างเมนูเป็นเมนูโฮเวอร์เฉพาะ CSS ที่ใช้ li:hover > ul และ li:focus-within > ul เพื่อแสดงเมนูย่อย

จากนั้น เราใช้ JavaScript เพื่อสร้างองค์ประกอบ <button> ตั้งค่าแอตทริบิวต์ aria และเพิ่มตัวจัดการเหตุการณ์ ผลลัพธ์สุดท้ายมีให้ในตัวอย่างโค้ดบน CodePen และใน GitHub repo นี่ควรเป็นจุดเริ่มต้นที่ดีสำหรับเมนูของคุณเช่นกัน

หีบเพลงกับโอเวอร์เลย์กับเมนูแยกบนมือถือ

มันไปโดยไม่บอกว่าไม่ใช่ทุก mega-dropdown ในการแตะ / คลิกจะทำงานได้ดี Target.com เป็นอีกตัวอย่างหนึ่งที่น่าสนใจสำหรับการนำทางขนาดใหญ่ที่เข้าถึงได้ ซึ่งหลีกเลี่ยงเลย์เอาต์แบบหลายคอลัมน์ และแสดงการนำทางเพียงระดับเดียวในขณะนั้น ซึ่งทั้งหมดจะเปิดขึ้นเมื่อแตะ/คลิก

เมนูแบบเลื่อนลงจะแสดงตัวเลือกในคอลัมน์เดียวในแต่ละครั้ง ดังนั้นเมื่อคุณย้ายภายในหมวดหมู่ คุณจะ จดจ่ออยู่กับการซ้อนทับ บนหน้าจอเดียวกันเสมอ ทุกส่วนที่เลือกจะครอบคลุมทั้งคอลัมน์ ประสบการณ์นั้นคาดเดาได้และสงบ แต่อีกครั้งที่ลูกค้าอาจเห็นการนำทางน้อยลงในแต่ละครั้ง

Dinoffentligetransport.dk ซึ่งเป็นเว็บไซต์บริการขนส่งสาธารณะจากเดนมาร์ก ใช้ หลายคอลัมน์ แทน โดยมีการนำทางที่ด้านบนพร้อมไอคอนรูปตัววี และเปิดได้ด้วยการแตะ/คลิกเช่นกัน

ในการใช้งานอื่น ๆ เราสามารถเห็นการซ้อนทับหลายรายการปรากฏทับ กัน อันที่จริง เป็นกรณีของยูนิลีเวอร์ (ตัวอย่างด้านล่าง) mega-dropdown จะเปิดขึ้นเมื่อแตะ/คลิก โดยมีบั้งหลายตัวแสดงพร้อมกัน บั้งแต่ละอันแสดงถึงอะไร? และลูกค้าควรคาดหวังอะไรเมื่อคลิกที่พวกเขา

“แบรนด์ของเรา” นำไปสู่ หน้าแยกต่างหาก ในขณะที่แต่ละป้ายกำกับเปิดโอเวอร์เลย์การนำทางใหม่ที่ด้านบนของรายการแบบเลื่อนลงขนาดใหญ่ คุณสังเกตไหมว่า "ทุกยี่ห้อ" ถูกขีดเส้นใต้ ในขณะที่ตัวเลือกการนำทางที่เหลือไม่ได้ขีดเส้นใต้ สามารถเห็นความตั้งใจของนักออกแบบที่สร้างเมนู แท้จริงแล้ว "แบรนด์ทั้งหมด" เป็นลิงก์ ในขณะที่ป้ายกำกับอื่นๆ เปิดโอเวอร์เลย์:

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

ทำความเข้าใจได้ง่ายขึ้นเล็กน้อยว่าขณะนี้เราอยู่ในระดับใดและมีตัวเลือกใดบ้างสำหรับวิธีการหีบเพลง ดังที่เราเห็นใน Dinoffentligetransport.dk อย่างไรก็ตาม อาจเป็นความคิดที่ดีที่จะขีดเส้นใต้ลิงก์ภายในแต่ละส่วนย่อย เนื่องจากจะกระตุ้นให้ลูกค้าไปที่หน้าของหมวดหมู่ นอกจากนี้ แถบหมวดหมู่ทั้งหมดน่าจะคลิกได้และขยายหีบเพลงได้

ในตัวอย่างข้างต้น ส่วนใหญ่เราอาจสามารถแสดงส่วนการนำทางในแต่ละครั้งได้อย่างจำกัด แต่ถ้าชื่อของแต่ละส่วนค่อนข้างสั้น เราสามารถ แบ่งหน้าจอในแนวนอน และแสดงหลายระดับพร้อมกันได้ LCFC.com เป็นตัวอย่างที่ดีของรูปแบบนี้ในการใช้งานจริง

ตัวเลือกใดทำงานได้ดีที่สุด?

จากประสบการณ์ส่วนตัวของฉัน เมื่อเราเปรียบเทียบการใช้งาน mega-dropdowns บนมือถือ หีบเพลงแนวตั้งดูเหมือนจะ เร็วกว่าและคาดเดาได้ง่าย กว่าการซ้อนทับ (ไม่ว่าจะเป็นคอลัมน์เดียวหรือหลายเลเยอร์) และ เมนูแยก ดูเหมือนจะเร็วกว่าและคาดเดาได้มากกว่าหีบเพลง

มี ข้อดี บางประการที่ทั้งหีบเพลงและเมนูแยกมี:

• ไม่จำเป็นต้องแสดงปุ่ม "ย้อนกลับ" เพื่อกลับไปยังหน้าหลัก
• ตาไม่ต้องข้ามไปมาระหว่างส่วนบนของเมนูการนำทางและการนำทางย่อยของส่วนทุกครั้งที่กระโดด
• ลูกค้าสามารถเลื่อนไปมาระหว่างระดับต่างๆ ได้เร็วขึ้น: แทนที่จะกดปุ่ม "ย้อนกลับ" หลายๆ ครั้ง พวกเขาสามารถข้ามไปยังหีบเพลงที่พวกเขาสนใจได้
• ลูกค้าสามารถสำรวจได้หลายส่วนพร้อมกัน (เว้นแต่การใช้งานจะปิดโดยอัตโนมัติหนึ่งหีบเพลงเมื่อมีการเปิดอีกอันหนึ่ง) มันเป็นไปไม่ได้กับการซ้อนทับ

โดยทั่วไป หีบเพลงและเมนูแยกดูเหมือนจะเป็นตัวเลือกที่ดีกว่า แต่ดูเหมือนว่าจะทำงานได้ไม่ดีเมื่อมีการนำทางจำนวนมาก เมื่อใดก็ตามที่แต่ละหมวดหมู่มีมากกว่า 6-7 รายการ จะเป็นความคิดที่ดีที่จะเพิ่มปุ่ม "เรียกดูทั้งหมด" ใต้ 6-7 รายการภายในหีบเพลงอื่น (หรือในหน้าแยกต่างหาก) หรือใช้ภาพซ้อนทับแทน

ดังนั้นขึ้นอยู่กับปริมาณของการนำทาง เราสามารถ เริ่มต้นด้วย split-menus จากนั้นหากไม่สามารถใช้งานได้ ให้ย้ายไปที่ accordion และหากการนำทางยังคงซับซ้อน ในที่สุดก็เปลี่ยน accordion ให้เป็น overlays

เมื่อ Mega-Dropdown อาจไม่จำเป็นอีกต่อไป

เราได้อ้างอิงงานของทีม Gov.uk ในบทความก่อนหน้านี้แล้ว แต่ข้อมูลเชิงลึกของพวกเขาก็มีประโยชน์ในบริบทของ mega-dropdowns เช่นกัน สำหรับการนำทางขนาดใหญ่ที่มีหลายระดับ ทีมงานได้ตัดสินใจจ้างสิ่งที่ค้นพบโดยหลักการหนึ่งสิ่งต่อหน้าของผู้เชี่ยวชาญของ Caroline Jarrett ตามคำกล่าวของแคโรไลน์ “คำถามที่ 'เข้ากันได้ดี' จากจุดที่นักออกแบบ […] ไม่จำเป็นต้องอยู่ในหน้าเดียวกันจึงจะใช้งานได้สำหรับผู้ใช้” Caroline นำไปใช้ในการออกแบบเว็บฟอร์มเป็นหลัก แต่เราสามารถนำมาใช้ในบริบทของการนำทางได้เช่นกัน

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

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

แนวทางอื่นคือการใช้ รูปแบบการนำทาง "ฉันต้องการ" นอกเหนือจากการนำทางแบบเดิม เราสามารถจัดเตรียม "เมนูแบบเลื่อนลงของการนำทาง" เพื่อให้ลูกค้าสามารถ สร้างคำถามเกี่ยวกับการนำ ทางตามที่ต้องการ และนำตรงไปยังหน้าที่พวกเขากำลังค้นหา โดยพื้นฐานแล้ว มันคือชุดของรายการดรอปดาวน์ที่ปรากฏใต้รายการอื่น เพื่อให้ผู้ใช้เลือกสิ่งที่พวกเขาตั้งใจจะทำหรือค้นหาบนเว็บไซต์

ชั่วขณะหนึ่ง รูปแบบนี้ถูกใช้บน Commonbond (ดูวิดีโอด้านบน) และรูปแบบนี้ใช้กับ Corkchamber.ie ด้วย เป็นวิธีที่น่าสนใจและแปลกใหม่ในการเข้าถึงการนำทางในระดับลึกโดยไม่ต้องใช้เมกะดรอปดาวน์เลย

รายการตรวจสอบการออกแบบการนำทางแบบเลื่อนลงขนาดใหญ่

ทุกครั้งที่เราพูดถึงเรื่อง Mega-dropdown menu ทุกคนดูเหมือนจะแยกกันอยู่สองสามกลุ่ม: เพื่อนร่วมงานบางคนชอบโฮเวอร์ คนอื่นๆ ชอบแตะและคลิก บางคนชอบทั้งคู่ และคนอื่นๆ ไม่สนใจตราบเท่าที่อยู่ตรงนั้น เป็นทั้งลิงค์หมวดหมู่และไอคอนที่เปิดเมนู

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

และเช่นเคย ต่อไปนี้คือสิ่งที่ควรคำนึงถึงเมื่อออกแบบและสร้างเมกะดรอปดาวน์:

• หลีกเลี่ยงการวางรายการสำคัญที่ใช้บ่อยไว้ใกล้กับการนำทางแบบเลื่อนลงขนาดใหญ่ (เช่น แถบค้นหา, CTA, ไอคอนตะกร้าสินค้า) (หากวางเมาส์เหนือ)
• หลีกเลี่ยงการนำทางย่อยหลายรายการ ภายใน mega-dropdown ที่ปรากฏต่อกันโดยมีความล่าช้า (หากวางเมาส์เหนือ)
• หลีกเลี่ยงการโหลดชื่อหมวดหมู่ที่ มีหลายฟังก์ชันมากเกินไป
• ขีดเส้นใต้ชื่อหมวดหมู่เพื่อระบุว่าเป็นลิงก์ไปยังหน้าหมวดหมู่ (แน่นอนว่าเชื่อมโยงกับหน้าหมวดหมู่)
• หากทำได้ ให้เพิ่ม ลิงก์ "หน้าแรก" หรือปุ่ม "เรียกดูทั้งหมด" ในแต่ละหมวดหมู่ย่อย แทนที่จะลิงก์หมวดหมู่โดยตรง
• หลีกเลี่ยงการวางซ้อนในแนวนอน และพิจารณาแทนที่ด้วยหีบเพลงแนวตั้งและเมนูแยก
• เพิ่มไอคอน เพื่อระบุว่าชื่อหมวดหมู่เรียกเมกะดรอปดาวน์เมื่อคลิก (เช่น บั้ง) และทำให้ใหญ่พอสำหรับการแตะอย่างสบายเสมอ (เช่น 50×50px)
• หลีกเลี่ยงการเปลี่ยนแบบเฟด-อิน/เฟด-เอาต์แบบยาว เมื่อ mega-dropdown ปรากฏขึ้น/หายไป (สูงสุด 300 มิลลิวินาที)
• ลองทดสอบคำแนะนำแบบมีโครงสร้างหรือแบบสอบถามการนำทาง (รูปแบบการนำทาง "ฉันต้องการ") แทนหรือเพิ่มเติมกับรายการแบบเลื่อนลงขนาดใหญ่
• หลีกเลี่ยงเมนูโฮเวอร์เมกะดรอปดาวน์ ถ้าเป็นไปได้