Neugestaltung des siebenstufigen Navigationssystems von SGS: Eine Fallstudie

SGS (ehemals Societe Generale de Surveillance ) ist eine globale Dienstleistungsorganisation und Anbieter von Inspektions-, Verifizierungs-, Test- und Zertifizierungsdiensten in 14 Branchen. Die Website von SGS (zusammen mit 60 lokalisierten Websites) bewirbt in erster Linie die Kerndienste der Organisation und bietet Zugang zu einer Vielzahl nützlicher Dienste, ergänzender Inhalte und Tools. Unser Ziel war es, sgs.com von einer reinen Desktop-Version in eine reaktionsschnelle Version umzuwandeln.

Dies stellte eine einzigartige Reihe von Herausforderungen dar, insbesondere rund um das alte Navigationssystem, das in Bereichen bis zu sieben Ebenen tief war (in zwei Teile geteilt) und aus etwa 12.000 einzelnen navigierbaren Elementen bestand .

Weiterführende Literatur zu SmashingMag: Link

• Entwerfen von Fallstudien: Präsentation eines auf den Menschen ausgerichteten Designprozesses
• Anpassung an ein responsives Design
• Artikeldesign Vereinheitlichungs-Fallstudie
• 75 lehrreiche Fallstudien – so haben wir es gebaut

Unsere natürliche Reaktion, als wir das Navigationssystem von SGS zum ersten Mal sahen und benutzten, war, dass die Informationsarchitektur (IA) aufgrund der schieren Menge an navigierbaren Links und Inhalten sicherlich vereinfacht werden musste. Bedenkt man jedoch, dass die Navigation bereits vor diesem Projekt für Suchmaschinen und die IA optimiert war und SGS eine breite Auswahl an Dienstleistungen über viele Branchen hinweg anbietet (spiegelt sich in der Menge der Inhalte wider), war es offensichtlich, dass ein Refactoring der IA dies nicht tun würde Teil der Lösung sein.

Einfach gesagt, die Struktur des Navigationsbaums musste intakt bleiben. Trotzdem hat uns das nicht daran gehindert, einige kleinere Anpassungen an der IA vorzunehmen. So wurden beispielsweise „News, Media & Resources“ und „SGS Offices & Labs“ zur besseren Sichtbarkeit auf die oberste Ebene verschoben. Bei Ersterem war es wichtig, klarer zum Ausdruck zu bringen, dass SGS regelmäßig Neuigkeiten veröffentlicht und Veranstaltungen veranstaltet. Bei letzterem war es wichtig, dass es zusammen mit der Kontaktseite von überall in der Website-Struktur aus leicht erreichbar ist. Daher war die Schlüsselfrage, wie ein solches Gigant von Navigationssystem dazu gebracht werden kann, einfach zwischen verschiedenen Ansichtsfenstern zu wechseln und dennoch nutzbar zu sein?

Erstellung von Projektrichtlinien

Eine gesunde Beziehung zwischen Kunde und Designer ist für den Erfolg jedes Projekts unerlässlich. Das Setzen klarer Erwartungen sowie das Bereitstellen effektiver Leitlinien stellen nicht nur sicher, dass die wichtigsten Interessengruppen während des gesamten Projekts konzentriert bleiben, sondern auch, dass sich im Laufe des Projekts Vertrauen zwischen allen Parteien entwickelt. Bei diesem Projekt war dies definitiv der Fall; Die Zusammenarbeit aller Parteien und die gegenseitige Wertschätzung der Rollen und Kompetenzen des jeweils anderen waren wirklich bemerkenswert.

Um jedoch sicherzustellen, dass alle Beteiligten konzentriert bleiben, haben wir beim Kick-off-Meeting eine Reihe wichtiger Richtlinien und Anforderungen festgelegt, innerhalb derer wir auch Kreativität ausüben können (auf die wir einige bestanden haben, andere vom Kunden gefordert wurden):

• Inhaltsparität . Inhalte sollten auf jedem Gerät und jeder Plattform zugänglich sein und auf keinen Fall auf Mobilgeräten versteckt werden.
• Leistung . Die Website sollte mindestens 20 % schneller sein als konkurrierende Websites. Dies war besonders hilfreich bei der Entscheidung, wie viele Informationen auf jeder Seite erscheinen sollten.
• Zugänglichkeit . Die Website muss den Zugänglichkeitsrichtlinien der WCAG 2.0 Level-AA entsprechen. Dieses Ziel konnten wir, abgesehen von einem grenzwertigen Farbkontrastproblem, aufgrund des Markenauftritts des Unternehmens erreichen.
• Benutzerfreundlichkeit . Das interne Team musste Konzepte ausgiebig validieren und Usability-Tests vor Ort und aus der Ferne durchführen.
• Ununterbrochenes Geschäft . Die Neugestaltung sollte das Geschäft des Unternehmens überhaupt nicht stören. Die Aufgabe bestand eindeutig nicht darin, die Dienstleistungen des Unternehmens zu optimieren, sondern die Website unter Berücksichtigung etablierter Geschäftsprozesse zu optimieren. Wir hatten zum Beispiel die Freiheit, Webformulare zu optimieren, aber die Struktur der Daten im CRM musste erhalten bleiben.

Die drei großen Herausforderungen

Nachdem wichtige Richtlinien festgelegt wurden und wir wussten, dass die Neugestaltung der Navigation keine wesentliche Überarbeitung der IA erfordern würde, haben wir die Neugestaltung in drei wichtige, aber voneinander abhängige Gruppen von Aktivitäten unterteilt:

• Layoutplatzierung . Dies wurde hauptsächlich vom internen Team gehandhabt, wobei wir Verbesserungen vorschlugen und sicherstellten, dass Entscheidungen keine radikalen Auswirkungen auf andere Aspekte des neuen responsiven Designs haben würden.
• Interaktion und Benutzerfreundlichkeit . Diese wurden gemeinsam mit dem Designteam von SGS bearbeitet. Ideen wurden per E-Mail und in Workshops vor Ort ausgetauscht und regelmäßig anhand von Benutzern, Stakeholdern und den allgemeinen Geschäftsanforderungen validiert.
• Leistung . Dies wurde ausschließlich von uns gehandhabt, da es eher eine technische Herausforderung war und keine strategischen Entscheidungen erforderte, außer dass wir die neue responsive Website schnell machen mussten.

Layout-Platzierung

Die Navigation ist ein grundlegendes Element des Seitenlayouts, unabhängig von der Größe oder Komplexität der Website. Auch wenn ein Off-Screen-Muster ansprechend erscheinen mag, wenn Sie es mit einem so großen Navigationssystem zu tun haben, denken Sie daran, dass es Probleme geben kann, wenn die Navigation für den Benutzer nicht sichtbar ist.

Das Designteam von SGS hatte zunächst verschiedene Konzepte getestet, da es nicht nur die Navigationsinteraktion bewerten, sondern auch die richtige Balance zum Rest der Seite schaffen und Unordnung vermeiden musste.

Entscheidung über das Konzept

Angesichts der Komplexität der Website war es wichtig, dass die Navigation immer sichtbar bleibt und den Benutzer darüber informiert, wo er sich innerhalb der Baumstruktur befindet. Anstatt die Navigation in der Benutzeroberfläche in zwei Teile zu unterteilen, wollten wir, dass das neue Navigationssystem nahtlos ist (von der obersten Ebene bis zu den unteren Ebenen). Daher musste es dem Benutzer ermöglichen, den Navigationsbaum einfach nach oben und unten sowie seitlich durch die Hauptabschnitte zu navigieren.

Um all diese Kombinationen zu testen und zu validieren, haben wir einen Prototyp für jedes der acht ersten Navigationskonzepte entwickelt. Die Prototypen bestätigten, was das Inhouse-Team bereits vermutete: Die praktikabelste Option in Bezug auf Benutzerfreundlichkeit, Wartbarkeit, Cross-Screen-Erfahrung, optische Aufgeräumtheit und Attraktivität war es, die Navigation auf großen Bildschirmen in der Seitenleiste zu platzieren und als Dropdown-Menü auf kleinen Bildschirmen. Im Wesentlichen wäre das Navigationsmodul unabhängig von der Bildschirmgröße funktional und optisch in sich abgeschlossen.

Während wir uns gleich auf bestimmte Interaktionsentscheidungen konzentrieren werden, ist es wichtig, darauf hinzuweisen, dass interaktive Prototypen nicht unbedingt verworfen werden müssen, sobald ein prototypisches Konzept getestet und validiert wurde.

Intelligentes Prototyping

Wir entwickeln Prototypen immer direkt in HTML, CSS und JavaScript mit semantischem, zugänglichem und robustem Markup, da wir die ersten Prototypen dann oft später im Designprozess wiederverwenden können. Das bedeutete, dass unser anfänglicher Prototyp für das neue Navigationssystem zum Grundstein für den endgültigen vollständigen Website-Prototypen wurde, der alle Seitenvorlagen und Module umfasste.

Bei der Bereitstellung des vollständigen Prototyps stellten wir auch sicher, dass der Styleguide automatisch für das SGS-Team generiert wurde. Indem das Designteam von SGS dazu gebracht wird, in Form von Design und Entwicklung von Modulen statt vollständiger Seiten zu denken, würde der generierte Styleguide nur wenig laufende Wartung erfordern. Der Styleguide selbst verweist auf alle verwendeten markanten Module, wobei jedes Modul eine genaue Beschreibung, ein Codebeispiel und einen automatisch generierten Link auf das verwendete Seiten-Template enthält. Unsere Technologie der Wahl für die Automatisierung von Aufgaben und Funktionen ist PHP, aber die Automatisierung kann mit jeder serverseitigen Sprache erreicht werden, solange die Ausgabe semantisches HTML ist. (Wir haben ein spezifisches Dateisystem-Framework für unsere Prototypen entwickelt, aber das ist ein Thema für eine andere Gelegenheit.) Später in diesem Artikel werden wir erläutern, wie uns serverseitiges Skripting geholfen hat, mehrere Versionen der Navigation zu warten und zu testen.

Auch wenn es wichtig ist, mit semantischem, zugänglichem und robustem HTML zu beginnen, ist das Prinzip „Inhalt zuerst, dann Navigation“ genauso wichtig, weil es Ihnen hilft, mögliche zukünftige Ausnahmen zu berücksichtigen. Bei diesem Projekt gab es eine Ausnahme von der „Inhalt zuerst, dann Navigation“-Regel: die Homepage. Wir haben anhand von Analysen festgestellt, dass die Navigation als das wichtigste Element auf der Startseite angesehen wird, was bedeutet, dass sie vor allen Kerninhalten auf der Seite stehen muss.

Interaktion und Benutzerfreundlichkeit

Nachdem die Entscheidung getroffen war, ein eigenständiges, bildschirmgrößenunabhängiges Navigationsmodul zu entwerfen und zu entwickeln, war es an der Zeit, sich auf Navigationsinteraktionen zu konzentrieren. In Anbetracht dessen, dass wir bei der Gestaltung der Navigation einen Mobile-First-Ansatz gewählt hatten, würde das Navigationsmodul selbst nicht nur natürlich in kleinen Ansichtsfenstern wie erwartet funktionieren, sondern sich auch leicht skalieren lassen, um in großen Ansichtsfenstern zu funktionieren.

Drei interaktive Versionen

Aufgrund der Größe der Navigation und der potenziellen Anzahl verschachtelter Ebenen mussten wir einige der gebräuchlicheren mobilen Navigationsmuster als Optionen eliminieren – zum Beispiel Auswahl-Dropdowns und das Priorität+-Muster. Wir konzentrierten uns auf das Prototyping von drei interaktiven Versionen der Navigation: ein Schieberegler, ein Akkordeon und ein Akkordeon und ein Schieberegler. Jedes hat seine Vor- und Nachteile, die unsere Entscheidung natürlich beeinflusst haben.

Akkordeon

Das Akkordeon ist wahrscheinlich das häufigste Muster auf dem Handy. Es offenbart nach und nach detailliertere Informationen, während der Benutzer das Thema oder die Aktion durchläuft. Es stellt auch sicher, dass der Benutzer nicht überfordert wird, weshalb wir es als Basislösung verwenden wollten.

Hier sind die Vorteile des Akkordeons:

• Benutzer sind damit vertraut.
• Benutzer können den gesamten Navigationsbaum erweitern, um eine Vorschau mehrerer Optionen anzuzeigen (sieben Navigationsebenen können schließlich etwas überwältigend sein).
• Es funktioniert ohne JavaScript und verwendet die :target .
• Es zu entwickeln ist einfach.

Und die Nachteile des Akkordeons:

• Die erweiterten Vorfahren einer Kategorie auf tiefer Ebene würden den aktuellen Geltungsbereich zu weit vom oberen Rand des Bildschirms wegschieben, wodurch viel Scrollen erforderlich wäre.
• Sieben Navigationsebenen erfordern sieben Stufen des gewählten visuellen Hinweises, seien es sieben Schattierungen einer Grundfarbe (Grau), sieben Ebenen einer typografischen Hierarchie oder sieben Ebenen einer Einrückung.

Schieberegler

Dies war ursprünglich unsere Lieblingslösung, aber es fehlt ein wichtiges Element: das Ermöglichen eines wirklich seitlichen Browsens durch die Hauptabschnitte. Es wäre kein solches Problem, wenn der Benutzer immer von der Startseite aus surfen würde, weil er sich zunehmend mit den Hauptbereichen vertraut machen würde. Für Benutzer, die auf einer Seite tief im Navigationsbaum landen, wäre dies jedoch definitiv ein Usability-Problem gewesen. Benutzer, die beispielsweise auf der dritten, vierten oder fünften Ebene landen, müssten den Baum nach oben durchqueren, um die Kontaktseite zu erreichen. Sieben Ebenen zu durchqueren macht keinen Spaß, egal wie motiviert der Benutzer sein mag.

Slider-Profis:

• Die Hierarchie ist klar.
• Die Animation ist glatt.
• Es folgt mobilen Konventionen.
• Es ist relativ einfach zu entwickeln.

Slider Nachteile:

• Ein seitliches Blättern ist nicht möglich.
• Die Animation ist nicht performant.

Hybrid (Akkordeon und Slider)

Wir wollten unbedingt die Attraktivität des Schiebereglers beibehalten und gleichzeitig das seitliche Surfen ermöglichen. Daher haben wir eine Hybridlösung entwickelt, die die besten Elemente der beiden Navigationsmuster kombiniert. Das war übrigens auch die Lösung, für die wir uns entschieden haben.

Hybrid-Profis:

• Seitliches Blättern ist möglich.
• Die Animation ist glatt.
• Die Hierarchie ist klar.

Hybride Nachteile:

• Es erfordert etwas anfängliches Lernen.
• Die Entwicklung ist komplex, da viele bewegliche Teile zu berücksichtigen sind.
• Es hat einige Leistungsprobleme.

Wie bereits erwähnt, sollte der Benutzer in der Lage sein, den Navigationsbaum nach oben und unten zu durchsuchen, immer wissend, woher er kommt und wohin ihn die Navigation als nächstes führt. Dies ist jedoch nur die Grundinteraktion – wir mussten uns mit einigen zusätzlichen Problemen befassen, um ein brauchbares Navigationssystem zu entwickeln.

Acht unterschiedliche Arten von Links

Abgesehen davon, dass sich aktuelle und Vorfahren-Navigationselemente im Design unterscheiden (was heute glücklicherweise eine etablierte Praxis ist), haben wir die Navigation und die allgemeine Benutzerfreundlichkeit weiter verbessert, indem wir dem Benutzer geholfen haben, zu verstehen, wo er sich befindet und was er erforscht. Dem Benutzer zu helfen, die aktuelle Seite und ihre Eltern sowie alle relevanten untergeordneten Beziehungen zu verstehen, war bei weitem nicht genug. Weitere wichtige Maßnahmen waren erforderlich:

• in der Lage zu sein, direkt zur übergeordneten Seite zu gehen;
• in der Lage zu sein, sowohl übergeordnete als auch untergeordnete Ebenen in der Vorschau anzuzeigen, während die ursprüngliche URL beibehalten wird;
• schnelles Verständnis ihrer aktuellen Browsing-Position, während sie in der Lage sind, die Navigation zu erkunden.
• schnelles Verständnis ihrer aktuellen Position auf der Seite.

Hinweis: Wir haben Breadcrumbs verwendet, um sicherzustellen, dass die aktuelle Seitenposition für den Benutzer immer klar ist. Da wir das Überspringen von Ebenen ganz vermeiden wollten, mussten die Informationen in den Breadcrumbs und der Navigation eins zu eins übereinstimmen, auch bei Pseudo-Ebenen (also Ebenen, die keine eigentliche Seite haben).

Die oben genannten Benutzeranforderungen führten zu fünf Arten von semantisch unterschiedlichen Navigationselementen mit zusätzlichen Hilfslinks, die es dem Benutzer ermöglichen würden, den Baum nach oben und unten zu durchlaufen, ohne die aktuelle Seite verlassen zu müssen. Sie können sich die Komplexität und Abhängigkeiten vorstellen, die mit so vielen beweglichen Teilen einhergehen.

Animationsdetails

Alle Elemente in der Navigation werden mit CSS animiert, wobei jede Animation zwei unterschiedliche Teile hat:

• horizontal animierte Ebenen,
• vertikal animierte Wrapper.

Zunächst werden die verschiedenen Baumebenen im Schieberegler umgeschaltet, indem die Klasse des Master-Wrappers geändert wird. Beispielsweise hat der geschlossene Navigations-Wrapper die Klasse .depth-0 . Wenn ein Element der obersten Ebene erweitert wird, ändert sich die Klasse in .depth-1 . Wenn ein Element der zweiten Ebene innerhalb dieses Elements der obersten Ebene ausgewählt wird, ändert sich die Klasse in .depth-2 und so weiter. Dies führt zu einem ziemlich einfachen Satz von CSS-Regeln, die auf ein einzelnes Element angewendet werden – die oberste geordnete Liste in einem Schieberegler:

 .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%; }

Im obigen Beispiel entspricht .l-0 einem Listenelement der Ebene Null, und .nav-open wird immer dann umgeschaltet, wenn das Akkordeon auf open gesetzt ist. Dies bedeutet, dass die geordnete Liste eines direkten untergeordneten Elements in einem open Akkordeon-Listenelement absolut auf die negativ-linke Position versetzt wird.

Zweitens muss angesichts der Tatsache, dass jede Ebene eine variable Anzahl von Listenelementen enthält, der Übergang zwischen zwei beliebigen benachbarten Ebenen glatt sein.

Um dies zu erreichen, haben wir dafür gesorgt, dass immer genügend vertikaler Raum vorhanden ist, damit die horizontale Animation reibungslos ablaufen kann. Die Höhe wird im laufenden Betrieb berechnet und angewendet, indem der vertikale Versatz des Elements abgerufen wird, das kurz vor dem Eintritt in den Bildschirm steht. Das bedeutet, dass wir insgesamt vier mögliche Szenarien berücksichtigen mussten, aber eigentlich nur zwei lösen mussten, jedes mit einer leicht unterschiedlichen Ausführungsreihenfolge:

• Kurzes Listenelement zu einem längeren Listenelement . Die horizontale und vertikale Animation starten gleichzeitig.
• Langes Listenelement zu einem kürzeren Listenelement . Nachdem die Navigation aufgehört hat, horizontal zu gleiten, beginnt die vertikale Animation.

Beide Animationen werden gleichzeitig gestartet, aber die zweite Animation wird nach einer Verzögerung von 300 Millisekunden gestartet, was genau der Dauer der ersten Animation entspricht (in CSS mithilfe der Eigenschaft „ transition-duration “ angegeben). Der Grund dafür ist eine suboptimale Animationsleistung auf weniger leistungsfähigen Geräten, wenn sich mehrere Ebenen überlappen, bevor sie „hinter dem Vorhang“ verschwinden. Der vereinfachte Code sieht so aus:

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

Weitere Verbesserungen

Da wir bereits mit einer komplexen Reihe von Abhängigkeiten konfrontiert waren, stellten wir beim Testen der Navigation fest, dass es Raum für Verbesserungen gab.

Erstens, weil Webfonts manchmal etwas später geladen werden als der Rest der Seite, wurden einige Textzeichenfolgen in der Navigation, die in einer Zeile stehen sollten, auf eine zweite Zeile erweitert, bevor der Webfont vollständig geladen war. Beispielsweise fällt der Abschnittslink der obersten Ebene „News, Media and Resources“ auf zwei Zeilen, wenn er in der Fallback-Schriftart gerendert wird.

Da alles sehr kompakt sein musste (da wir für die Gleitanimation eine absolute Positionierung verwenden mussten), bestand die einzige Lösung darin, die Höhe des betroffenen Elements zurückzusetzen, nachdem der Webfont geladen wurde. Dies geschah mit dem von Bram Stein für Adobe Typekit und Google Fonts entwickelten Web Font Loader.

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

Hinweis: Haben Sie bemerkt, wie wir ein 5-Sekunden-Timeout verwendet haben? In unseren Tests haben wir festgestellt, dass dies der optimale Punkt ist, der dazu geführt hat, dass es mit unserer „guten 2G“-Basisverbindung (450 KB pro Sekunde) funktioniert!

Zweitens wollten wir, weil wir uns entschieden haben, die Navigationsknoten bedingt zu laden, um die anfängliche Ladeleistung zu verbessern (mehr dazu im nächsten Abschnitt), den Benutzer darüber informieren, wie viele Navigationselemente verfügbar sind, falls es zu einer Verzögerung kommt beim Laden eines Zweigs des Navigationsbaums. Dazu haben wir ein Platzhalter-Hintergrundbild wiederholt, das einer Textfolge ähnelt.

Schließlich haben wir den Platzhaltercode im DOM mit JavaScript angehängt, bevor wir den Navigationszweig angefordert haben. Dadurch bleibt das DOM so sauber wie möglich.

 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); });

Leistung

Wenn Sie sich erinnern, war eines unserer Hauptziele im Projekt, dass die Website mindestens 20 % besser abschneidet als die Websites der Konkurrenz. Wir haben dieses Ziel nicht nur erreicht, sondern wir haben SGS dabei geholfen, das Gesamtseitengewicht und die Ladezeiten erheblich zu reduzieren. Werfen Sie einen Blick auf die folgenden Vorher-Nachher-Statistiken:

Wussten Sie, dass 12.000 Links 3 MB HTML entsprechen?

Das ist richtig! Als wir den vollständigen Navigationsbaum zum ersten Mal in unserem Prototyp gerendert haben, belief er sich auf 3 MB reines HTML. Keine Kopfzeile, keine Fußzeile und kein Inhalt – nur der Navigationsbaum, der aus 12.000 einzelnen Links besteht.

Vor der Neugestaltung enthielt jede Seite den Kernnavigationsbaum, und jede Branchenseite enthielt auch einen branchenspezifischen Navigationsbaum, der als separates Modul implementiert wurde. Allerdings erschwerte das Desktop-optimierte Design den Kern oder die branchenspezifische Navigation nicht nur in kleinen Viewports, sondern auch in der Wartung. Aus diesem Grund war eines der Hauptziele des Redesigns, den Baum in einem einzigen und einfach zu wartenden Modul zu konsolidieren.

Untersuchung von Optionen zur Verbesserung der Leistung

Um jede der drei interaktiven Versionen der Navigation gründlich zu testen und ihre Leistung zu bewerten, war eine flexible Testumgebung unerlässlich. Dies würde es uns ermöglichen, Änderungen schnell vorzunehmen und gleichzeitige Versionen zu pflegen, sodass wir sie leicht miteinander vergleichen könnten.

In Anbetracht der Größe des gesamten Navigationsbaums (bis zu sieben Ebenen tief und 12.000 navigierbare Links) war es wichtig, Teile des Navigationsbaums sowie den gesamten Baum selbst testen zu können. Die internen Entwickler von SGS waren in der Lage, den vollständigen Navigationsbaum als CSV-Datei aus ihrem Content-Management-System zu exportieren, wodurch wir eine einfach konfigurierbare PHP-Funktion erstellen konnten, um je nach Bedarf entweder den vollständigen Baum oder einen Teil davon auszugeben zu testen.

Unsere PHP-Funktion vereinfachte auch die HTML-Pflege der Struktur des Navigationsbaums, da das oben erwähnte Link-Markup und die Klassennamen einfach an einer einzigen Stelle geändert werden konnten. Die Verwendung einer serverseitigen Sprache, um zu vermeiden, dass Code wiederholt werden muss, mag naheliegend klingen, aber die Schaffung dieser Art von Umgebung war nicht nur eine willkommene Ergänzung, sondern tatsächlich unternehmenskritisch, da sie die Voraussetzung für agiles Experimentieren und Testen war.

Bedingtes Laden von Links

Wir haben erwähnt, dass wir die Navigationsknoten bedingt laden mussten, um die anfängliche Ladeleistung zu verbessern. Die Frage, die dann beantwortet werden musste, war, wie viel des Navigationsbaums sollte anfänglich und wie viel später geladen werden, und wann? Nach dem Testen und Vergleichen der Gewichte und Größen der verschiedenen Zweige des Navigationsbaums sowie der Untersuchung des Benutzerverhaltens auf der bestehenden Live-Website ergaben sich einige interessante Schlussfolgerungen.

Erstens besuchten Besucher, die sich nur für eine Branche interessierten, selten andere Branchen. Nach dem Durchsuchen der ausgewählten Branchenkategorie würde jeder Besucher normalerweise nur ein paar andere Seiten erkunden.

Zweitens (und wie wir zunächst dachten) verursachten die branchenspezifischen Zweige den größten Teil des Performance-Overheads. Als wir die Industriezweige ganz entfernten, wurde der HTML-Code auf 70 KB reduziert, was viel besser ist als 3 MB! Dennoch bedeutete dies, dass jeder der 14 Industriezweige zwischen 300 und 500 KB wog. Als wir jeden Service-Zweig weiter fragmentierten, stellten wir fest, dass jede nachfolgende Ebene im Durchschnitt etwa 24 KB wiegen würde.

Obwohl wir uns bewusst waren, dass der HTML-Code weiter reduziert werden könnte, indem wir die Klassennamen optimieren und DOM-Knoten über JavaScript hinzufügen (mehr dazu gleich), mussten wir dennoch feststellen, ob es am besten ist, eine einzelne HTTP-Anforderung bei etwa 300 to zu initiieren 500 KB oder zum Initiieren einer HTTP-Anforderung von etwa 24 KB auf jeder Ebene. Anfänglich schien es vorteilhafter zu sein, jedes Mal eine 24-KB-Anforderung zu senden, wenn der Benutzer weiter nach unten in der Navigationsstruktur fortschreitet. Dies hätte jedoch dazu geführt, dass mehrere HTTP-Anfragen über das Netzwerk gesendet wurden, was alles andere als ideal war, wenn man bedenkt, dass die Netzwerklatenz oft einer der größten Engpässe für die Leistung von Websites ist. Es machte auch keinen Sinn, das Laden von Industriezweigen vorherzusagen, außer wenn der Benutzer seine Absicht zeigte, indem er mit der Maus über einen Industrielink fuhr.

Aufgrund der Komplexität der Navigation und der Menge an Links bot die folgende Anordnung den mit Abstand besten Kompromiss:

• Laden Sie die ersten drei Ebenen standardmäßig in HTML.
• Laden Sie die Branchennavigation mit JavaScript, wenn die Absicht angezeigt wird, die mithilfe des mouseover Ereignisses erkannt wird.
• Geladene Zweige zwischenspeichern, um das Laden bei aufeinanderfolgenden Seitenladevorgängen zu beschleunigen.

Die Logik für tiefere Seiten war etwas anders, da die Navigation ohne aktiviertes JavaScript zugänglich sein muss. Wenn also ein Benutzer (oder sogar ein Suchmaschinen-Bot) auf einer tiefen Seite landet, würde Folgendes passieren:

1. Rendern Sie die ersten drei Ebenen und den Vorfahren-Zweig und die Geschwisterseiten der aktuellen Seite in HTML, wodurch der Benutzer problemlos auf die Eltern-, Vorfahren- und Geschwisterseiten zugreifen kann, während er auch in der Lage ist, nach derselben Logik auf andere Teile der Website zuzugreifen.
2. Laden Sie den aktuellen Zweig mit JavaScript und ersetzen Sie den Vorgängerzweig der ursprünglich geladenen aktuellen Seite.

Optimierung von HTML

Wenn Sie Ihr HTML wirklich optimieren möchten, müssen alle nicht wesentlichen Elemente in CSS und JavaScript ausgelagert werden. Wir haben alles außer der geordneten Liste, ihren Listenelementen und ihren jeweiligen Links rigoros beschnitten. Alle nicht unbedingt notwendigen Links (also Navigationshilfen) wurden ebenfalls aus dem HTML entfernt und per JavaScript wieder in das DOM eingefügt (weil sie ohne JavaScript ohnehin wirkungslos sind). Diese nicht wesentlichen Links ermöglichen dem Benutzer, einige Dinge zu tun:

• Öffnen Sie die nächste Ebene (intern nannten wir diese „Expander“);
• eine Stufe höher gehen (wir haben diese „Unterstützer“ genannt – was einen Mangel an Vorstellungskraft zeigt).

Während der resultierende DOM immer noch immens war, mussten die Navigationshilfen nicht mehr einzeln über das Netzwerk übertragen werden.

Die letzte Optimierung, die wir vorgenommen haben, bestand schließlich darin, die Anzahl der Klassen zu reduzieren und die Länge der Klassennamen zu verkürzen; aus .very-long-class-name wurde .vlcn . Während letzteres die größten Gewinne brachte, ist eine solche Optimierung schwer zu rechtfertigen, da sie die Größe der HTML-Datei normalerweise nicht wesentlich verringert und, was noch wichtiger ist, die Übersichtlichkeit des Codes verringert, was möglicherweise die Wartung erschwert. Allerdings war es eine lohnende Übung und ein akzeptabler Kompromiss, auch nur ein einziges Byte von jedem der 12.000 Listenelemente abzuschneiden.

Das Ergebnis? Etwa 40 KB anfängliches HTML (8 bis 9 KB bei Komprimierung und Übertragung über das Netzwerk) und 200 bis 300 KB HTML für jede Branche (15 bis 25 KB bei Komprimierung und Übertragung).

Fazit: Marginal Gains Matter

Wir verwenden gerne eine Analogie aus der Sportwelt: Jede kleine Sache um 1 % zu verbessern, verbessert die Leistung dramatisch. Dies gilt für das, was wir im SGS-Projekt und seiner komplizierten Navigation getan haben. Indem wir uns auf die feineren Details konzentrierten und jedes Detail um ein kleines bisschen verbesserten, haben wir die Komplexität der Navigation erheblich reduziert und die Ladezeiten verbessert, während die Navigation für die Benutzer ansprechend und ansprechend blieb. Was ein Alptraum und eine harte Nuss hätte werden können, wurde zu einer technisch und interaktiv relevanten Lösung, die flexibel genug war, um weitere Verbesserungen zu ermöglichen.

Vor allem der Designprozess des kontinuierlichen Prototypings, der Untersuchung von Optionen und der Verfeinerung der besten Lösungen hat sich als äußerst effektiv erwiesen – so sehr, dass er ein starkes Argument für das interne Team geliefert hat, die gleichen Grundprinzipien bei der Entwicklung anderer Produkte anzuwenden in der Organisation, ganz zu schweigen davon, dass es dem Team hilft, das neue Navigationssystem weiter zu verfeinern und zu optimieren. Kein Webprojekt ist jemals wirklich abgeschlossen; es stehen immer noch ein paar dinge auf der to-do-liste. Das ist völlig in Ordnung, solange wir weiter testen, verfeinern und den Benutzern das beste Erlebnis bieten.