การออกแบบระบบนำทางเจ็ดระดับของ SGS ใหม่: กรณีศึกษา

SGS (เดิมชื่อ Societe Generale de Surveillance ) เป็นองค์กรบริการระดับโลกและผู้ให้บริการด้านการตรวจสอบ การตรวจสอบ การทดสอบและการรับรองใน 14 อุตสาหกรรม เว็บไซต์ของ SGS (พร้อมด้วยเว็บไซต์ที่แปลเป็นภาษาท้องถิ่น 60 แห่ง) ส่งเสริมบริการหลักขององค์กรเป็นหลัก ตลอดจนให้การเข้าถึงบริการที่เป็นประโยชน์ เนื้อหาเสริม และเครื่องมือต่างๆ ที่เป็นประโยชน์มากมาย เป้าหมายของเราคือเปลี่ยน sgs.com จากการเป็นแบบเดสก์ท็อปเท่านั้นเป็นการโต้ตอบ

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag: Link

• การออกแบบกรณีศึกษา: การนำเสนอกระบวนการออกแบบที่เน้นมนุษย์เป็นศูนย์กลาง
• การปรับให้เข้ากับการออกแบบที่ตอบสนอง
• กรณีศึกษาการรวมการออกแบบผลิตภัณฑ์
• 75 กรณีศึกษาเชิงแนะนำ – นี่คือวิธีที่เราสร้างมันขึ้นมา

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

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

การจัดทำนโยบายโครงการ

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

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

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

ความท้าทายหลักสามประการ

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

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

การจัดวางเลย์เอาต์

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

ทีมออกแบบของ SGS ได้ทดสอบแนวคิดที่หลากหลายตั้งแต่แรก เนื่องจากพวกเขาต้องไม่เพียงแค่ประเมินการโต้ตอบการนำทางเท่านั้น แต่ยังต้องสร้างสมดุลที่เหมาะสมกับส่วนที่เหลือของหน้าและหลีกเลี่ยงความยุ่งเหยิง

การตัดสินใจเกี่ยวกับแนวคิด

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

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

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

การสร้างต้นแบบสมาร์ท

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

ในการส่งต้นแบบฉบับสมบูรณ์ เรายังทำให้มั่นใจว่าคู่มือสไตล์จะถูกสร้างขึ้นโดยอัตโนมัติสำหรับทีม SGS ด้วยการให้ทีมออกแบบของ SGS คิดในแง่ของการออกแบบและพัฒนาโมดูล แทนที่จะให้หน้าที่สมบูรณ์ คู่มือสไตล์ที่สร้างขึ้นจะต้องการการบำรุงรักษาอย่างต่อเนื่องเพียงเล็กน้อย คู่มือสไตล์อ้างอิงถึงโมดูลที่โดดเด่นทั้งหมดที่ใช้ โดยแต่ละโมดูลประกอบด้วยคำอธิบายที่แม่นยำ ตัวอย่างโค้ด และลิงก์ที่สร้างโดยอัตโนมัติไปยังเทมเพลตของหน้าเว็บที่ใช้ เทคโนโลยีที่เราเลือกสำหรับงานและคุณลักษณะอัตโนมัติคือ PHP แต่การทำงานอัตโนมัติสามารถทำได้โดยใช้ภาษาฝั่งเซิร์ฟเวอร์ใดก็ได้ ตราบใดที่ผลลัพธ์เป็น HTML เชิงความหมาย (เราพัฒนาเฟรมเวิร์กระบบไฟล์เฉพาะสำหรับต้นแบบของเรา แต่นั่นเป็นหัวข้อสำหรับโอกาสอื่น) ในบทความนี้ เราจะอธิบายว่าการเขียนสคริปต์ฝั่งเซิร์ฟเวอร์ช่วยให้เรารักษาและทดสอบการนำทางเวอร์ชันต่างๆ ได้อย่างไร

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

ปฏิสัมพันธ์และการใช้งาน

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

สามเวอร์ชันแบบโต้ตอบ

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

หีบเพลง

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

นี่คือข้อดีของหีบเพลง:

• ผู้ใช้คุ้นเคยกับมัน
• ผู้ใช้สามารถขยายแผนผังการนำทางทั้งหมดเพื่อดูตัวอย่างตัวเลือกต่างๆ ได้ (การนำทางทั้งเจ็ดระดับอาจดูล้นหลามเล็กน้อย)
• มันทำงานได้โดยไม่ต้องใช้ JavaScript โดยใช้ :target pseudo-class
• การพัฒนาเป็นเรื่องง่าย

และข้อเสียของหีบเพลง:

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

ตัวเลื่อน

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

ข้อดีของตัวเลื่อน:

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

ข้อเสียของตัวเลื่อน:

• ไม่สามารถเรียกดูด้านข้างได้
• แอนิเมชั่นไม่มีประสิทธิภาพ

ไฮบริด (หีบเพลงและตัวเลื่อน)

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

ข้อดีไฮบริด:

• สามารถเรียกดูด้านข้างได้
• แอนิเมชั่นลื่นไหล
• ลำดับชั้นมีความชัดเจน

ข้อเสียไฮบริด:

• มันต้องมีการเรียนรู้เบื้องต้นบ้าง
• การพัฒนานั้นซับซ้อน โดยต้องคำนึงถึงส่วนที่เคลื่อนไหวได้มากมาย
• มีปัญหาด้านประสิทธิภาพบางอย่าง

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

ลิงก์ที่โดดเด่นแปดประเภท

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

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

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

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

รายละเอียดแอนิเมชั่น

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

• ระดับภาพเคลื่อนไหวในแนวนอน
• เครื่องห่อแบบเคลื่อนไหวในแนวตั้ง

ขั้นแรก ระดับทรีต่างๆ ในตัวเลื่อนจะถูกสลับโดยการเปลี่ยนคลาสของตัวตัดหลัก ตัวอย่างเช่น Wrapper การนำทางแบบปิดมีคลาส .depth-0 เมื่อมีการขยายรายการระดับบนสุด คลาสจะเปลี่ยนเป็น .depth-1 เมื่อมีการเลือกรายการระดับที่สองจากภายในรายการระดับบนสุดนั้น คลาสจะเปลี่ยนเป็น .depth-2 เป็นต้น ส่งผลให้มีกฎ CSS ชุดที่ค่อนข้างง่ายที่นำไปใช้กับองค์ประกอบเดียว — รายการที่มีลำดับสูงสุดในแถบเลื่อน:

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

ในตัวอย่างข้างต้น .l-0 สอดคล้องกับรายการระดับศูนย์ และ .nav-open จะถูกสลับทุกครั้งที่ open หีบเพลง ซึ่งหมายความว่ารายการที่เรียงลำดับของลูกโดยตรงในรายการหีบเพลงที่ open อยู่จะถูกชดเชยกับตำแหน่งเชิงลบซ้ายอย่างแน่นอน

ประการที่สอง เมื่อพิจารณาว่าแต่ละระดับมีจำนวนตัวแปรของรายการ การเปลี่ยนระหว่างสองระดับที่อยู่ติดกันจะต้องราบรื่น

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

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

อนิเมชั่นทั้งสองเริ่มต้นพร้อมกัน แต่แอนิเมชั่นที่สองเริ่มต้นหลังจากดีเลย์ 300 มิลลิวินาที ซึ่งเป็นระยะเวลาของแอนิเมชั่นแรกพอดี (ระบุไว้ใน CSS โดยใช้คุณสมบัติ transition-duration ) เหตุผลก็คือประสิทธิภาพของแอนิเมชั่นที่ด้อยประสิทธิภาพในอุปกรณ์ที่มีความสามารถน้อยกว่าเมื่อหลายเลเยอร์ทับซ้อนกันก่อนที่จะหายไป "หลังม่าน" รหัสแบบง่ายมีลักษณะดังนี้:

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

การปรับปรุงเพิ่มเติม

เมื่อเผชิญกับการพึ่งพาอาศัยกันที่ซับซ้อน เราจึงได้ตระหนักว่าเมื่อทดสอบการนำทางว่ายังมีที่ว่างสำหรับการปรับปรุง

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

เนื่องจากทุกอย่างต้องมีขนาดกะทัดรัดมาก (เนื่องจากเราต้องใช้การวางตำแหน่งที่แน่นอนสำหรับแอนิเมชั่นการเลื่อน) ทางออกเดียวคือการรีเซ็ตความสูงขององค์ประกอบที่ได้รับผลกระทบหลังจากโหลดแบบอักษรของเว็บแล้ว ทำได้โดยใช้ Web Font Loader ซึ่งพัฒนาโดย Bram Stein สำหรับ Adobe Typekit และ Google Fonts

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

หมายเหตุ: คุณสังเกตเห็นไหมว่าเราใช้การหมดเวลา 5 วินาที? ในการทดสอบของเรา เราพบว่าสิ่งนี้เป็นจุดที่น่าสนใจที่ทำให้ใช้งานได้บนการเชื่อมต่อพื้นฐาน "ดี 2G" (450 KB ต่อวินาที)!

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

สุดท้าย เราได้เพิ่มโค้ดตัวยึดตำแหน่งใน DOM ด้วย JavaScript ก่อนขอสาขาการนำทาง สิ่งนี้ทำให้ DOM นั้นสะอาดที่สุด

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

ผลงาน

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

คุณรู้หรือไม่ว่า 12,000 ลิงก์เท่ากับ 3 MB ของ HTML?

ถูกต้อง! เมื่อเราแสดงแผนผังการนำทางแบบเต็มเป็นครั้งแรกในต้นแบบของเรา มันมีจำนวน HTML เปล่า 3 MB ไม่มีส่วนหัว ไม่มีส่วนท้าย และไม่มีเนื้อหา — มีเพียงแผนผังการนำทางที่ประกอบด้วยลิงก์ 12,000 ลิงก์

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

สำรวจตัวเลือกเพื่อปรับปรุงประสิทธิภาพ

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

เมื่อพิจารณาถึงขนาดของแผนผังการนำทางที่สมบูรณ์ (ลึกถึงเจ็ดระดับและลิงก์ที่นำทางได้ 12,000 ลิงก์) ความสามารถในการทดสอบส่วนต่างๆ ของแผนผังการนำทางและแผนผังทั้งหมดนั้นมีความสำคัญ นักพัฒนาภายในของ SGS สามารถส่งออกแผนผังการนำทางแบบเต็มเป็นไฟล์ CSV จากระบบการจัดการเนื้อหา ซึ่งช่วยให้เราสร้างฟังก์ชัน PHP ที่กำหนดค่าได้ง่ายเพื่อส่งออกทั้งทรีแบบเต็มหรือบางส่วน ขึ้นอยู่กับสิ่งที่เราต้องการ ทดสอบ.

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

การโหลดลิงค์แบบมีเงื่อนไข

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

ประการแรก ผู้เยี่ยมชมที่สนใจในอุตสาหกรรมประเภทเดียวเท่านั้น ไม่ค่อยได้เยี่ยมชมอุตสาหกรรมอื่น เมื่อเรียกดูหมวดหมู่อุตสาหกรรมที่เลือกแล้ว ผู้เข้าชมแต่ละรายมักจะไปสำรวจหน้าอื่นๆ อีกสองสามหน้า

ประการที่สอง (และอย่างที่เราคิดไว้ในตอนแรก) สาขาเฉพาะอุตสาหกรรมทำให้เกิดค่าใช้จ่ายด้านประสิทธิภาพส่วนใหญ่ เมื่อเราลบสาขาอุตสาหกรรมทั้งหมด HTML ลดลงเหลือ 70 KB ซึ่งดีกว่า 3 MB มาก! ถึงกระนั้น ก็หมายความว่าแต่ละสาขาอุตสาหกรรม 14 สาขามีน้ำหนักระหว่าง 300 ถึง 500 KB เมื่อเราแยกส่วนบริการแต่ละสาขาออกไป เราพบว่าแต่ละระดับที่ตามมาจะมีน้ำหนักโดยเฉลี่ยประมาณ 24 KB

ในขณะที่เราทราบดีว่า HTML สามารถลดลงได้อีกโดยการเพิ่มประสิทธิภาพชื่อคลาสและเพิ่มโหนด DOM ผ่าน JavaScript (เพิ่มเติมในหนึ่งนาที) เรายังต้องพิจารณาว่าควรเริ่มต้นคำขอ HTTP เดียวที่ประมาณ 300 หรือไม่ 500 KB หรือเพื่อเริ่มต้นคำขอ HTTP ประมาณ 24 KB ในแต่ละระดับ ในขั้นต้น ดูเหมือนว่าการส่งคำขอขนาด 24 KB ทุกครั้งที่ผู้ใช้ดำเนินการต่อไปในแผนผังการนำทางจะเป็นประโยชน์มากกว่า อย่างไรก็ตาม สิ่งนี้จะส่งผลให้มีการส่งคำขอ HTTP หลายรายการผ่านเครือข่าย ซึ่งยังห่างไกลจากอุดมคติ เนื่องจากเวลาแฝงของเครือข่ายมักเป็นหนึ่งในปัญหาคอขวดที่ใหญ่ที่สุดสำหรับประสิทธิภาพของเว็บไซต์ นอกจากนี้ยังไม่สมเหตุสมผลที่จะคาดการณ์การโหลดของสาขาอุตสาหกรรมใดๆ เช่นกัน ยกเว้นเมื่อผู้ใช้แสดงเจตจำนงโดยวางเมาส์เหนือลิงก์ของอุตสาหกรรม

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

• โหลดสามระดับแรกตามค่าเริ่มต้นใน HTML
• โหลดการนำทางของอุตสาหกรรมด้วย JavaScript เมื่อมีการแสดงเจตนา ตรวจพบโดยใช้เหตุการณ์ mouseover
• แคชโหลดสาขาเพื่อเพิ่มความเร็วในการโหลดหน้าต่อเนื่อง

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

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

การเพิ่มประสิทธิภาพ HTML

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

• เปิดระดับถัดไป (ภายในเราเรียกว่า "ตัวขยาย" เหล่านี้);
• ขึ้นไปอีกระดับ (เราตั้งชื่อว่า "ผู้สนับสนุน" เหล่านี้ - แสดงว่าขาดจินตนาการ)

แม้ว่า DOM ที่เป็นผลลัพธ์ยังคงมีขนาดใหญ่ แต่เครื่องช่วยนำทางก็ไม่จำเป็นต้องถ่ายโอนทีละรายการผ่านเครือข่ายอีกต่อไป

สุดท้าย การปรับแต่งส่วนสุดท้ายที่เราทำคือการลดจำนวนคลาส รวมทั้งลดความยาวของชื่อคลาส ตัวอย่างเช่น . .very-long-class-name กลายเป็น . .vlcn ในขณะที่วิธีหลังให้ผลตอบแทนสูงสุด การปรับให้เหมาะสมดังกล่าวเป็นเรื่องยากที่จะให้เหตุผล เนื่องจากโดยปกติแล้วจะไม่ลดขนาดไฟล์ HTML อย่างมีนัยสำคัญ และที่สำคัญกว่านั้นคือลดความชัดเจนของโค้ด ซึ่งทำให้การบำรุงรักษาทำได้ยากขึ้น อย่างไรก็ตาม การขจัดแม้แต่ไบต์เดียวออกจากแต่ละรายการ 12,000 รายการทำให้เป็นแบบฝึกหัดที่คุ้มค่าและเป็นการแลกเปลี่ยนที่ยอมรับได้

ผลลัพธ์? HTML เริ่มต้น 40 KB หรือมากกว่านั้น (8 ถึง 9 KB เมื่อบีบอัดและถ่ายโอนผ่านเครือข่าย) และ HTML 200 ถึง 300 KB สำหรับแต่ละอุตสาหกรรม (15 ถึง 25 KB เมื่อบีบอัดและถ่ายโอน)

บทสรุป: Marginal Gain Matter

เราชอบที่จะใช้การเปรียบเทียบจากโลกแห่งกีฬา: การปรับปรุงทุกสิ่งเล็กน้อย 1% ช่วยปรับปรุงประสิทธิภาพอย่างมาก สิ่งนี้ใช้ได้กับสิ่งที่เราทำในโครงการ SGS และการนำทางที่ซับซ้อน การมุ่งเน้นที่รายละเอียดปลีกย่อย การปรับปรุงแต่ละรายละเอียดทีละน้อย เราลดความซับซ้อนของการนำทางลงอย่างมากและเวลาในการโหลดที่ดีขึ้น ในขณะที่ยังคงการนำทางที่น่าดึงดูดและมีส่วนร่วมสำหรับผู้ใช้ สิ่งที่อาจเป็นฝันร้ายและยากต่อการแตกหักกลายเป็นโซลูชันที่เกี่ยวข้องทางเทคนิคและเชิงโต้ตอบ ซึ่งยืดหยุ่นพอที่จะรองรับการปรับปรุงเพิ่มเติม

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