إعادة تصميم نظام الملاحة ذو المستويات السبعة لشركة SGS: دراسة حالة

SGS (المعروفة سابقًا باسم Societe Generale de Surveillance ) هي منظمة خدمات عالمية ومزود خدمات الفحص والتحقق والاختبار وإصدار الشهادات عبر 14 صناعة. يقوم موقع SGS على الويب (إلى جانب 60 موقعًا محليًا) بالترويج للخدمات الأساسية للمؤسسة بشكل أساسي ، فضلاً عن توفير الوصول إلى العديد من الخدمات المفيدة والمحتوى الإضافي والأدوات. كان هدفنا هو تحويل موقع sgs.com من سطح المكتب فقط إلى كونه سريع الاستجابة.

قدم هذا مجموعة فريدة من التحديات ، لا سيما حول نظام الملاحة القديم ، والذي كان يصل إلى سبعة مستويات في العمق (مقسم إلى جزأين) ويتألف من حوالي 12000 عنصر فردي قابل للملاحة .

مزيد من القراءة على SmashingMag: Link

• تصميم دراسات الحالة: عرض عملية تصميم تتمحور حول الإنسان
• التكيف مع تصميم سريع الاستجابة
• دراسة حالة لتوحيد تصميم المنتج
• 75 دراسة حالة مفيدة - هكذا بنيناها

كان رد فعلنا الطبيعي عند رؤية واستخدام نظام الملاحة الخاص بـ SGS لأول مرة هو أنه من المؤكد أنه كان لابد من تبسيط بنية المعلومات (IA) بسبب الحجم الهائل للروابط والمحتوى القابل للتنقل. ومع ذلك ، بالنظر إلى أن التنقل قد تم تحسينه بالفعل لمحركات البحث و IA قبل هذا المشروع ، وبالنظر إلى أن SGS تقدم مجموعة واسعة من الخدمات عبر العديد من الصناعات (ينعكس في حجم المحتوى) ، كان من الواضح أن إعادة بناء IA لن أن تكون جزءا من الحل.

ببساطة ، يجب أن يظل هيكل شجرة الملاحة كما هو. ومع ذلك ، لم يمنعنا ذلك من إجراء بعض التعديلات الطفيفة على IA. على سبيل المثال ، تم نقل "الأخبار والوسائط والموارد" و "مكاتب ومختبرات SGS" إلى المستوى الأعلى ، لزيادة الوضوح. مع السابق ، كان من المهم أن نعكس بشكل أوضح أن SGS تنشر الأخبار وتستضيف الأحداث بانتظام. مع هذا الأخير ، كان من الضروري أن يسهل الوصول إليه ، إلى جانب صفحة الاتصال ، من أي مكان في هيكل الموقع. لذلك ، كان السؤال الرئيسي هو كيف يمكن جعل مثل هذا النظام العملاق لنظام الملاحة للانتقال بسهولة بين إطارات العرض المختلفة بينما لا يزال قابلاً للاستخدام؟

وضع سياسات المشروع

تعد العلاقة الصحية بين العميل والمصمم ضرورية لنجاح كل مشروع. إن تحديد توقعات واضحة بالإضافة إلى تقديم إرشادات فعالة لا يضمن فقط أن يظل أصحاب المصلحة الرئيسيين مركزين طوال الوقت ، ولكن أيضًا تلك الثقة تتطور بين جميع الأطراف مع تقدم المشروع. كان هذا بالتأكيد هو الحال مع هذا المشروع ؛ كان التعاون بين جميع الأطراف والتقدير المتبادل لأدوار وخبرات كل منهما أمرًا رائعًا حقًا.

ومع ذلك ، لضمان استمرار تركيز جميع الأطراف ، وضعنا في الاجتماع الافتتاحي عددًا من الإرشادات والمتطلبات المهمة التي يمكننا من خلالها أيضًا ممارسة الإبداع (بعضها أصررنا ، والبعض الآخر أصر عليه العميل):

• تكافؤ المحتوى . يجب أن يكون المحتوى متاحًا على كل جهاز ومنصة ولا يجب إخفاءه بأي حال من الأحوال على الهاتف المحمول.
• أداء . يجب أن يكون أداء موقع الويب أسرع بنسبة 20٪ على الأقل من المواقع المنافسة. كان هذا مفيدًا بشكل خاص عند تحديد مقدار المعلومات التي يجب نشرها في كل صفحة.
• سهولة الوصول . يجب أن يلتزم موقع الويب بإرشادات الوصول WCAG 2.0 level-AA. لقد نجحنا في تحقيق هذا الهدف ، بصرف النظر عن مشكلة تباين الألوان الحدودية ، بسبب العلامة التجارية للشركة.
• سهولة الاستخدام . كان على الفريق الداخلي التحقق من صحة المفاهيم على نطاق واسع وإجراء اختبار قابلية الاستخدام شخصيًا وعن بُعد.
• عمل غير منقطع . يجب ألا تؤدي إعادة التصميم إلى تعطيل عمل الشركة على الإطلاق. من الواضح أن المهمة لم تكن تحسين خدمات الشركة ، بل تحسين موقع الويب ، مع مراعاة العمليات التجارية المعمول بها. على سبيل المثال ، كانت لدينا الحرية في تحسين نماذج الويب ، ولكن يجب أن تظل بنية البيانات في CRM كما هي.

التحديات الثلاثة الرئيسية

مع وضع المبادئ التوجيهية الرئيسية ومعرفة أن إعادة تصميم الملاحة لن تتطلب إصلاحًا كبيرًا لـ IA ، قمنا بتقسيم إعادة التصميم إلى ثلاث مجموعات رئيسية ولكن مترابطة من الأنشطة:

• وضع التخطيط . تم التعامل مع هذا في الغالب من قبل الفريق الداخلي ، حيث اقترحنا تحسينات والتأكد من أن أي قرارات لن يكون لها آثار جذرية على جوانب أخرى من التصميم سريع الاستجابة الجديد.
• التفاعل وسهولة الاستخدام . تم العمل على هذه بالتعاون مع فريق تصميم SGS. تم تبادل الأفكار عبر البريد الإلكتروني وفي ورش العمل في الموقع وتم التحقق من صحتها بانتظام مقابل المستخدمين وأصحاب المصلحة ومتطلبات العمل العامة.
• أداء . تم التعامل مع هذا من قبلنا فقط ، لأنه كان يمثل تحديًا تقنيًا أكثر ولم يتطلب اتخاذ أي قرار استراتيجي بخلافنا لجعل موقع الويب الجديد سريع الاستجابة.

وضع التخطيط

يعد التنقل عنصرًا أساسيًا في تخطيط الصفحة ، بغض النظر عن حجم موقع الويب أو مدى تعقيده. بينما قد يبدو النمط خارج الشاشة جذابًا عند التعامل مع مثل هذا النظام الملاحي واسع النطاق ، تذكر أنه قد تكون هناك مشكلات عندما لا يكون التنقل مرئيًا للمستخدم.

اختبر فريق تصميم SGS في البداية مجموعة متنوعة من المفاهيم ، لأنه لم يكن عليهم فقط تقييم تفاعل التنقل ، ولكن أيضًا إنشاء التوازن الصحيح مع باقي الصفحة وتجنب الفوضى.

اتخاذ قرار بشأن المفهوم

نظرًا لتعقيد موقع الويب ، كان من الضروري أن يظل التنقل مرئيًا دائمًا وإبلاغ المستخدم بمكان وجوده داخل هيكل الشجرة. بدلاً من تقسيم التنقل إلى جزأين في واجهة المستخدم ، أردنا أن يكون نظام التنقل الجديد سلسًا (من المستوى الأعلى إلى المستويات السفلية). لذلك ، كان يجب أن يمكّن المستخدم من التصفح بسهولة لأعلى ولأسفل في شجرة التنقل ، بالإضافة إلى التنقل الجانبي عبر الأقسام الرئيسية.

لاختبار كل هذه المجموعات والتحقق من صحتها ، قمنا بتطوير نموذج أولي لكل من مفاهيم التنقل الأولية الثمانية. أكدت النماذج الأولية ما اشتبه فيه الفريق الداخلي بالفعل: كان الخيار الأكثر قابلية للتطبيق من حيث سهولة الاستخدام والصيانة وتجربة عرض الشاشة والفوضى المرئية والنداء هو وضع التنقل في الشريط الجانبي على الشاشات الكبيرة والظهور على هيئة القائمة المنسدلة على الشاشات الصغيرة. بشكل أساسي ، ستكون وحدة التنقل قائمة بذاتها وظيفيًا وبصريًا ، بغض النظر عن حجم الشاشة.

بينما سنركز على قرارات تفاعل محددة في غضون دقيقة ، يجدر الإشارة إلى أنه لا يلزم بالضرورة التخلص من النماذج الأولية التفاعلية بمجرد اختبار مفهوم النموذج الأولي والتحقق من صحته.

النماذج الأولية الذكية

نقوم دائمًا بتطوير نماذج أولية مباشرةً في HTML و CSS و JavaScript باستخدام ترميز دلالية وقوي وسهل الوصول إليه ، لأننا غالبًا ما نكون قادرين على إعادة استخدام النماذج الأولية لاحقًا في عملية التصميم. هذا يعني أن النموذج الأولي الخاص بنا لنظام التنقل الجديد أصبح حجر الزاوية للنموذج الأولي الكامل لموقع الويب في نهاية المطاف ، والذي تضمن جميع قوالب الصفحات والوحدات النمطية.

عند تقديم النموذج الأولي الكامل ، تأكدنا أيضًا من إنشاء دليل النمط تلقائيًا لفريق SGS. من خلال جعل فريق تصميم SGS يفكر فيما يتعلق بتصميم الوحدات النمطية وتطويرها ، بدلاً من الصفحات الكاملة ، فإن دليل النمط الذي تم إنشاؤه سيتطلب القليل من الصيانة المستمرة. يشير دليل النمط نفسه إلى جميع الوحدات المميزة المستخدمة ، حيث تحتوي كل وحدة على وصف دقيق ومثال رمز ورابط تم إنشاؤه تلقائيًا إلى قالب الصفحة حيث يتم استخدامه. إن التكنولوجيا التي نختارها لأتمتة المهام والميزات هي PHP ، ولكن يمكن تحقيق الأتمتة باستخدام أي لغة من جانب الخادم ، طالما أن الناتج هو HTML الدلالية. (لقد قمنا بتطوير إطار عمل خاص بنظام الملفات لنماذجنا الأولية ، ولكن هذا موضوع لمناسبة أخرى.) لاحقًا في هذه المقالة ، سنشرح كيف ساعدتنا البرمجة النصية من جانب الخادم في الحفاظ على إصدارات متعددة من التنقل واختبارها.

على الرغم من أن البدء باستخدام لغة HTML الدلالية والقوية التي يمكن الوصول إليها أمر حيوي ، فإن مبدأ "المحتوى أولاً ، ثم التنقل ثانيًا" له نفس الأهمية لأنه يساعدك على حساب أي استثناءات مستقبلية محتملة. كان هناك استثناء واحد لقاعدة "المحتوى أولاً ، وثانية التنقل" في هذا المشروع: الصفحة الرئيسية. اكتشفنا ، بناءً على التحليلات ، أن التنقل كان يُنظر إليه على أنه أهم عنصر في الصفحة الرئيسية ، مما يعني أنه يجب أن يأتي قبل أي محتوى أساسي على الصفحة.

التفاعل وسهولة الاستخدام

بمجرد اتخاذ القرار بتصميم وتطوير وحدة ملاحة قائمة بذاتها ومحاطة بحجم الشاشة ، فقد حان الوقت للتركيز على تفاعلات التنقل. بالنظر إلى أننا اعتمدنا نهجًا للجوّال أولاً لتصميم التنقل ، فإن وحدة التنقل نفسها لن تعمل بشكل طبيعي كما هو متوقع في إطارات العرض الصغيرة فحسب ، بل ستعمل بسهولة في إطارات العرض الكبيرة أيضًا.

ثلاثة إصدارات تفاعلية

نظرًا لحجم التنقل والعدد المحتمل للمستويات المتداخلة ، كان علينا التخلص من بعض أنماط التنقل الأكثر شيوعًا كخيارات - على سبيل المثال ، حدد القوائم المنسدلة ونمط الأولوية +. ركزنا على إنشاء نماذج أولية لثلاثة إصدارات تفاعلية من التنقل: شريط تمرير وأكورديون وأكورديون وشريط تمرير. لكل منها مزاياها وعيوبها ، والتي أثرت بشكل طبيعي على قرارنا.

الأكورديون

ربما يكون الأكورديون هو النمط الأكثر شيوعًا على الهاتف المحمول. إنه يكشف تدريجياً ، ويكشف عن معلومات أكثر تفصيلاً مع تقدم المستخدم في الموضوع أو الإجراء. كما أنه يضمن عدم ارتباك المستخدم ، ولهذا أردنا استخدامه كحل أساسي.

فيما يلي مزايا الأكورديون:

• المستخدمين على دراية به.
• يمكن للمستخدمين توسيع شجرة التنقل بأكملها لمعاينة خيارات متعددة (سبعة مستويات من التنقل يمكن أن تكون مربكة بعض الشيء ، بعد كل شيء).
• إنه يعمل بدون JavaScript ، باستخدام :target pseudo-class.
• تطويره سهل.

وسلبيات الأكورديون:

• ستدفع الأسلاف الموسعة لفئة المستوى العميق النطاق الحالي بعيدًا جدًا عن الجزء العلوي من الشاشة ، مما يتطلب الكثير من التمرير.
• تتطلب سبعة مستويات من التنقل سبع درجات من الإشارة المرئية المختارة ، سواء كانت سبع درجات من اللون الأساسي (الرمادي) ، أو سبعة مستويات من التسلسل الهرمي المطبعي أو سبعة مستويات من المسافة البادئة.

المنزلق

كان هذا هو الحل المفضل لدينا في البداية ، لكنه يفتقد إلى عنصر واحد مهم: السماح حقًا بالتصفح الجانبي عبر الأقسام الرئيسية. لن تكون هذه مشكلة إذا بدأ المستخدم دائمًا في التصفح من الصفحة الرئيسية ، لأنه سيصبح أكثر دراية بالأقسام الرئيسية. ومع ذلك ، بالنسبة للمستخدمين الذين يهبطون على صفحة في عمق شجرة التنقل ، فمن المؤكد أنها كانت ستشكل مشكلة قابلية الاستخدام. على سبيل المثال ، سيتعين على المستخدمين الذين يهبطون في المستوى الثالث أو الرابع أو الخامس اجتياز الشجرة للوصول إلى صفحة الاتصال. لا يعد اجتياز سبعة مستويات أمرًا ممتعًا ، بغض النظر عن مدى تحفيز المستخدم.

إيجابيات شريط التمرير:

• التسلسل الهرمي واضح.
• الرسوم المتحركة بقعة.
• يتبع اتفاقيات المحمول.
• من السهل نسبيا تطوير.

سلبيات المنزلق:

• التصفح الجانبي غير ممكن.
• الرسوم المتحركة ليست مؤدية.

هجين (أكورديون وشريط تمرير)

أردنا حقًا الحفاظ على جاذبية شريط التمرير ، مع الاستمرار في السماح بالتصفح الجانبي. لذلك ، قمنا بتطوير حل هجين يجمع بين أفضل عناصر نمطي التنقل. بالمناسبة ، كان هذا أيضًا الحل الذي توصلنا إليه.

الايجابيات الهجينة:

• التصفح الجانبي ممكن.
• الرسوم المتحركة بقعة.
• التسلسل الهرمي واضح.

سلبيات هجينة:

• يتطلب بعض التعلم الأولي.
• إنه معقد التطوير ، مع مراعاة العديد من الأجزاء المتحركة.
• لديها بعض مشاكل الأداء.

كما ذكرنا ، يجب أن يكون المستخدم قادرًا على تصفح شجرة التنقل لأعلى ولأسفل ، وأن يكون على دراية دائمًا بالمكان الذي أتوا منه والمكان الذي سيأخذهم إليه التنقل بعد ذلك. ومع ذلك ، هذا مجرد تفاعل أساسي - كان علينا معالجة عدد غير قليل من المشكلات الإضافية من أجل تطوير نظام تنقل قابل للاستخدام.

ثمانية أنواع مميزة من الروابط

بصرف النظر عن عناصر التنقل الحالية والأسلاف المتميزة في التصميم (والتي تعد الآن ، لحسن الحظ ، ممارسة راسخة) ، فقد قمنا بتحسين التنقل وقابلية الاستخدام العامة من خلال مساعدة المستخدم على فهم مكانهم وما يستكشفونه. كانت مساعدة المستخدم على فهم الصفحة الحالية وأولياء الأمور ، وكذلك أي علاقات أطفال ذات صلة ، بعيدة كل البعد عن أن تكون كافية. مطلوب إجراءات مهمة أخرى:

• القدرة على الانتقال مباشرة إلى الصفحة الرئيسية ؛
• القدرة على معاينة كل من مستويات الوالدين والأطفال ، كل ذلك أثناء البقاء على عنوان URL الأصلي ؛
• فهم سريع لموقف التصفح الحالي الخاص بهم ، مع القدرة على استكشاف التنقل.
• فهم سريع لموقعهم الحالي على الصفحة.

ملاحظة: استخدمنا فتات التنقل للتأكد من أن موضع الصفحة الحالي واضح دائمًا للمستخدم. نظرًا لأننا أردنا تجنب تخطي المستويات تمامًا ، كان يجب أن تتطابق المعلومات الموجودة في مسارات التنقل والتنقل من واحد إلى آخر ، حتى مع المستويات الزائفة (أي المستويات التي لا تحتوي على صفحة فعلية).

أدت متطلبات المستخدم أعلاه إلى خمسة أنواع من عناصر التنقل المختلفة لغويًا ، مع روابط مساعدة إضافية من شأنها أن تسمح للمستخدم بالانتقال إلى أعلى وأسفل الشجرة دون الحاجة إلى مغادرة الصفحة الحالية. يمكنك تخيل التعقيد والاعتماد المتبادل الذي يأتي مع العديد من الأجزاء المتحركة.

تفاصيل الرسوم المتحركة

يتم تحريك جميع العناصر الموجودة في التنقل باستخدام CSS ، حيث تحتوي كل حركة على جزأين مميزين:

• مستويات متحركة أفقيًا
• أغلفة متحركة عموديًا.

أولاً ، يتم تبديل مستويات الشجرة المختلفة في شريط التمرير عن طريق تغيير فئة الغلاف الرئيسي. على سبيل المثال ، يحتوي برنامج تضمين التنقل المغلق على فئة .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 كيلوبايت في الثانية)!

ثانيًا ، نظرًا لأننا قررنا تحميل عُقد التنقل بشكل مشروط من أجل تحسين أداء التحميل الأولي (المزيد عن ذلك في القسم التالي) ، فقد أردنا أن يظل المستخدم على دراية بعدد عناصر التنقل المتاحة ، في حالة حدوث تأخير في تحميل فرع من شجرة التنقل. لقد فعلنا ذلك من خلال تكرار صورة خلفية لعنصر نائب تشبه سلسلة نصية.

أخيرًا ، قمنا بإلحاق رمز العنصر النائب في 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 على تقليل الوزن الإجمالي للصفحة وأوقات التحميل بشكل كبير. ألق نظرة على الإحصائيات التالية قبل وبعد:

هل تعلم أن 12000 رابط يساوي 3 ميغا بايت من HTML؟

هذا صحيح! عندما قدمنا ​​شجرة التنقل الكاملة لأول مرة في نموذجنا الأولي ، بلغت 3 ميغابايت من HTML. لا رأس ولا تذييل ولا محتوى - فقط شجرة التنقل التي تتكون من 12000 رابط فردي.

قبل إعادة التصميم ، كانت كل صفحة تحتوي على شجرة التنقل الأساسية ، وتضمنت كل صفحة صناعة أيضًا شجرة تنقل خاصة بالصناعة ، تم تنفيذها كوحدة منفصلة. ومع ذلك ، فإن التصميم المحسّن لسطح المكتب جعل التنقل الأساسي أو الخاص بالصناعة ليس فقط صعبًا للاستخدام في إطارات العرض الصغيرة ، ولكن أيضًا من الصعب صيانته. لهذا السبب كان أحد الأهداف الرئيسية لإعادة التصميم هو دمج الشجرة في وحدة واحدة سهلة الصيانة.

استكشاف الخيارات لتحسين الأداء

لإجراء اختبار شامل لكل من الإصدارات التفاعلية الثلاثة للملاحة ، فضلاً عن تقييم أدائها ، كان من الضروري وجود بيئة اختبار مرنة. سيمكننا ذلك من إجراء التغييرات بسرعة ، وكذلك الحفاظ على الإصدارات المتزامنة حتى نتمكن من مقارنتها ببعضها البعض بسهولة.

بالنظر إلى حجم شجرة التنقل الكاملة (حتى عمق سبعة مستويات و 12000 رابط قابل للملاحة) ، كان من المهم القدرة على اختبار أجزاء من شجرة التنقل بالإضافة إلى الشجرة الكاملة نفسها. تمكن مطورو SGS الداخليون من تصدير شجرة التنقل الكاملة كملف CSV من نظام إدارة المحتوى الخاص بهم ، مما سمح لنا بإنشاء وظيفة PHP قابلة للتكوين بسهولة لإخراج الشجرة الكاملة أو جزء منها ، اعتمادًا على ما نحتاجه لاختبار.

عملت وظيفة PHP أيضًا على تبسيط صيانة HTML لهيكل شجرة التنقل ، لأنه يمكن بسهولة تغيير ترميز الارتباط وأسماء الفئات المذكورة أعلاه في مكان واحد. قد يبدو استخدام لغة من جانب الخادم لتجنب الاضطرار إلى تكرار التعليمات البرمجية أمرًا بديهيًا ، ولكن إنشاء هذا النوع من البيئة لم يكن مجرد إضافة مرحب بها ، ولكنه كان في الواقع مهمًا مهمًا ، لأنه كان شرطًا أساسيًا للتجربة والاختبار السريع.

روابط التحميل المشروط

ذكرنا أنه كان علينا تحميل عقد التنقل بشكل مشروط لتحسين أداء التحميل الأولي. كان السؤال الذي احتاج بعد ذلك إلى إجابة هو ، ما مقدار شجرة التنقل التي يجب تحميلها في البداية وكم يجب تحميلها لاحقًا ، ومتى؟ بعد اختبار ومقارنة أوزان وأحجام فروع شجرة التنقل المختلفة ، بالإضافة إلى دراسة سلوك المستخدم على الموقع المباشر الحالي ، ظهرت بعض الاستنتاجات المثيرة للاهتمام.

أولاً ، نادرًا ما يزور الزوار المهتمون بنوع واحد من الصناعة صناعات أخرى. بمجرد تصفح فئة الصناعة المحددة الخاصة بهم ، سيستمر كل زائر عادةً لاستكشاف صفحتين أخريين فقط.

ثانيًا (وكما اعتقدنا في البداية) ، تسببت الفروع الخاصة بالصناعة في غالبية نفقات الأداء. عندما أزلنا فروع الصناعة تمامًا ، تم تقليل HTML إلى 70 كيلوبايت ، وهو أفضل بكثير من 3 ميغابايت! ومع ذلك ، فإن هذا يعني أن كل فرع من فروع الصناعة الأربعة عشر يتراوح وزنها بين 300 و 500 كيلوبايت. عندما قمنا بتجزئة كل فرع خدمة أكثر ، وجدنا أن كل مستوى لاحق قد يصل وزنه إلى حوالي 24 كيلو بايت في المتوسط.

بينما كنا ندرك أنه يمكن تقليل HTML بشكل أكبر عن طريق تحسين أسماء الفئات وإضافة عقد DOM عبر JavaScript (المزيد عن ذلك في دقيقة واحدة) ، لا يزال يتعين علينا تحديد ما إذا كان من الأفضل بدء طلب HTTP واحد عند حوالي 300 إلى 500 كيلو بايت أو لبدء طلب HTTP لحوالي 24 كيلو بايت في كل مستوى. في البداية ، بدا أن إرسال طلب بحجم 24 كيلوبايت في كل مرة يتقدم فيها المستخدم إلى أسفل شجرة التنقل سيكون أكثر فائدة. ومع ذلك ، كان من الممكن أن يؤدي ذلك إلى إرسال طلبات HTTP متعددة عبر الشبكة ، وهو ما لم يكن مثاليًا ، مع الأخذ في الاعتبار أن زمن انتقال الشبكة غالبًا ما يكون أحد أكبر الاختناقات لأداء موقع الويب. كما أنه لم يكن من المنطقي التنبؤ بتحميل أي فرع من فروع الصناعة ، إلا عندما أظهر المستخدم نيته بالمرور فوق ارتباط الصناعة.

نظرًا لتعقيد التنقل وكمية الروابط ، فإن الترتيب التالي يقدم أفضل حل وسط:

• قم بتحميل المستويات الثلاثة الأولى افتراضيًا بتنسيق HTML.
• قم بتحميل التنقل الصناعي باستخدام JavaScript عند إظهار النية ، واكتشافها باستخدام حدث mouseover .
• تحميل الفروع في ذاكرة التخزين المؤقت لتسريع التحميل على تحميلات متتالية للصفحة.

كان منطق الصفحات الأعمق مختلفًا إلى حد ما ، لأن التنقل يجب أن يكون متاحًا بدون تمكين JavaScript. لذلك ، إذا وصل المستخدم (أو حتى روبوت محرك البحث) إلى صفحة عميقة ، فسيحدث ما يلي:

1. اعرض المستويات الثلاثة الأولى وفرع سلف الصفحة الحالية وإخوة الصفحة في HTML ، مما يسمح للمستخدم بالوصول بسهولة إلى صفحات الأصل والأصل والأشقاء ، مع القدرة أيضًا على الوصول إلى أجزاء أخرى من موقع الويب باتباع نفس المنطق.
2. قم بتحميل الفرع الحالي باستخدام JavaScript ، واستبدل الفرع الأصلي للصفحة الحالية التي تم تحميلها في البداية.

تحسين HTML

إذا كنت تريد حقًا تحسين HTML الخاص بك ، فيجب إلغاء تحميل جميع العناصر غير الأساسية إلى CSS و JavaScript. لقد قمنا بتشذيب كل شيء بدقة باستثناء القائمة المرتبة وعناصر القائمة والروابط الخاصة بكل منها. تمت إزالة جميع الروابط غير الأساسية (مثل أدوات المساعدة على التنقل) من HTML وأعيد إدخالها مرة أخرى في DOM باستخدام JavaScript (لأنها غير فعالة بدون JavaScript على أي حال). تتيح هذه الروابط غير الأساسية للمستخدم القيام بأمرين:

• افتح المستوى التالي (داخليًا ، أطلقنا على هذه "الموسعات") ؛
• اصعد مستوى (أطلقنا على هؤلاء "الداعمين" - مما يدل على نقص في الخيال).

بينما كان DOM الناتج لا يزال هائلاً ، لم تعد أدوات الملاحة بحاجة إلى النقل بشكل فردي عبر الشبكة.

أخيرًا ، كان آخر جزء من التحسين الذي قمنا به هو تقليل عدد الفئات ، وكذلك تقصير طول أسماء الفئات ؛ على سبيل المثال ، أصبح .very-long-class-name .vlcn . في حين أن هذا الأخير حقق أكبر المكاسب ، يصعب تبرير هذا التحسين لأنه عادةً لا يقلل حجم ملف HTML بشكل كبير ، والأهم من ذلك أنه يقلل من وضوح الكود ، مما يجعل الصيانة أكثر صعوبة. ومع ذلك ، فإن حلق بايت واحد من كل عنصر من عناصر القائمة البالغ عددها 12000 جعلها تمرينًا مفيدًا ومقايضة مقبولة.

النتائج؟ 40 كيلوبايت أو نحو ذلك من HTML الأولي (8 إلى 9 كيلوبايت عند ضغطها ونقلها عبر الشبكة) ، و 200 إلى 300 كيلوبايت من HTML لكل صناعة (15 إلى 25 كيلوبايت عند ضغطها ونقلها).

الخلاصة: المكاسب الهامشية مهمة

نحب استخدام تشبيه من عالم الرياضة: إن تحسين كل شيء صغير بنسبة 1٪ يؤدي إلى تحسين الأداء بشكل كبير. وهذا ينطبق على ما فعلناه في مشروع SGS والتنقل المعقد فيه. من خلال التركيز على التفاصيل الدقيقة ، وتحسين كل التفاصيل بمقدار ضئيل ، قللنا بشكل كبير من تعقيد التنقل وتحسين أوقات التحميل ، مع الحفاظ على التنقل جذابًا وجذابًا للمستخدمين. ما كان يمكن أن يكون كابوسًا وصعوبة كسره تحول إلى حل ذي صلة تقنيًا وتفاعليًا ، مرنًا بدرجة كافية لاستيعاب المزيد من التحسينات.

الأهم من ذلك كله ، أن عملية تصميم النماذج الأولية المستمرة ، والتحقيق في الخيارات وتحسين أفضل الحلول أثبتت أنها فعالة للغاية - لدرجة أنها قدمت حجة قوية للفريق الداخلي لتطبيق نفس المبادئ الأساسية عند تطوير منتجات أخرى في المنظمة ، ناهيك عن أنه سيساعد الفريق على مواصلة تحسين وتحسين نظام الملاحة الجديد. لا يوجد مشروع ويب مكتمل بالفعل ؛ هناك دائمًا عدد قليل من الأشياء الأخرى في قائمة المهام. هذا جيد تمامًا ، طالما أننا نواصل الاختبار والتحسين وتقديم أفضل تجربة للمستخدمين.