Riprogettazione del sistema di navigazione a sette livelli di SGS: un caso di studio

SGS (ex Société Générale de Surveillance ) è un'organizzazione di servizi globale e fornitore di servizi di ispezione, verifica, test e certificazione in 14 settori. Il sito Web di SGS (insieme a 60 siti Web localizzati) promuove principalmente i servizi principali dell'organizzazione, oltre a fornire l'accesso a una moltitudine di servizi utili, contenuti e strumenti supplementari. Il nostro obiettivo era trasformare sgs.com da solo desktop a reattivo.

Ciò ha presentato una serie unica di sfide, in particolare attorno al sistema di navigazione legacy, che nelle aree era profondo fino a sette livelli (diviso in due parti) e che consisteva in circa 12.000 singoli elementi navigabili .

Ulteriori letture su SmashingMag: Link

• Progettare casi di studio: mostrare un processo di progettazione incentrato sull'uomo
• Adattarsi a un design reattivo
• Caso di studio sull'unificazione del design del prodotto
• 75 Casi di studio istruttivi: ecco come l'abbiamo costruito

La nostra reazione naturale vedendo e utilizzando per la prima volta il sistema di navigazione di SGS è stata che sicuramente l'architettura dell'informazione (IA) doveva essere semplificata a causa dell'enorme volume di collegamenti e contenuti navigabili. Tuttavia, considerando che la navigazione era già stata ottimizzata per i motori di ricerca e l'IA prima di questo progetto e considerando che SGS offre un'ampia selezione di servizi in molti settori (riflesso nel volume dei contenuti), era evidente che il refactoring dell'IA non avrebbe essere parte della soluzione.

In poche parole, la struttura dell'albero di navigazione doveva rimanere intatta. Anche così, ciò non ci ha impedito di apportare alcune piccole modifiche all'IA. Ad esempio, "News, Media & Resources" e "SGS Offices & Labs" sono stati spostati al livello più alto, per una maggiore visibilità. Con il primo, era importante riflettere più chiaramente sul fatto che SGS pubblica regolarmente notizie e ospita eventi. Con quest'ultimo, era fondamentale che, insieme alla pagina dei contatti, fosse facilmente raggiungibile da qualsiasi punto della struttura del sito web. Pertanto, la domanda chiave era: come si poteva fare in modo che un tale colosso di un sistema di navigazione passasse facilmente tra diversi viewport pur rimanendo utilizzabile?

Stabilire le politiche di progetto

Un sano rapporto cliente-progettista è essenziale per il successo di ogni progetto. Stabilire aspettative chiare e fornire una guida efficace garantisce non solo che le parti interessate chiave rimangano concentrate per tutto il tempo, ma anche che si sviluppi fiducia tra tutte le parti man mano che il progetto avanza. Questo è stato sicuramente il caso di questo progetto; la collaborazione tra tutte le parti e il reciproco apprezzamento dei reciproci ruoli e competenze sono stati davvero notevoli.

Tuttavia, per garantire che tutte le parti rimanessero concentrate, abbiamo stabilito al kick-off di soddisfare una serie di importanti linee guida e requisiti all'interno dei quali potremmo anche esercitare la creatività (alcuni dei quali abbiamo insistito, altri su cui il cliente ha insistito):

• Parità di contenuto . I contenuti devono essere accessibili su ogni dispositivo e piattaforma e in nessun caso devono essere nascosti sui dispositivi mobili.
• Prestazioni . Il sito Web dovrebbe funzionare almeno il 20% più velocemente rispetto ai siti Web concorrenti. Ciò è stato particolarmente utile per decidere quante informazioni devono essere inserite in ciascuna pagina.
• Accessibilità . Il sito Web deve aderire alle linee guida per l'accessibilità di livello AA WCAG 2.0. Siamo riusciti a raggiungere questo obiettivo, a parte un problema di contrasto cromatico al limite, dovuto al marchio dell'azienda.
• Usabilità . Il team interno ha dovuto convalidare ampiamente i concetti e condurre test di usabilità di persona e in remoto.
• Affari ininterrotti . La riprogettazione non dovrebbe affatto interrompere l'attività dell'azienda. Chiaramente, il compito non era quello di ottimizzare i servizi dell'azienda, ma piuttosto di ottimizzare il sito web, tenendo conto dei processi aziendali consolidati. Ad esempio, avevamo la libertà di ottimizzare i moduli web, ma la struttura dei dati nel CRM doveva rimanere intatta.

Le tre grandi sfide

Con le linee guida chiave stabilite e sapendo che la riprogettazione della navigazione non richiederebbe una revisione significativa dell'IA, abbiamo suddiviso la riprogettazione in tre serie di attività chiave ma interdipendenti:

• Posizionamento del layout . Questo è stato gestito principalmente dal team interno, con noi che suggerivamo miglioramenti e assicuravamo che qualsiasi decisione non avrebbe avuto implicazioni radicali per altri aspetti del nuovo design reattivo.
• Interazione e usabilità . Questi sono stati elaborati in collaborazione con il team di progettazione di SGS. Le idee sono state scambiate via e-mail e in seminari in loco e sono state regolarmente convalidate rispetto agli utenti, alle parti interessate e ai requisiti aziendali generali.
• Prestazioni . Questo è stato affrontato esclusivamente da noi, perché si trattava più di una sfida tecnica e non richiedeva alcun processo decisionale strategico se non per rendere veloce il nuovo sito Web reattivo.

Posizionamento del layout

La navigazione è un elemento fondamentale dell'impaginazione, indipendentemente dalle dimensioni o dalla complessità del sito web. Sebbene uno schema fuori schermo possa sembrare interessante quando hai a che fare con un sistema di navigazione su larga scala, ricorda che possono verificarsi problemi quando la navigazione non è visibile all'utente.

Il team di progettazione di SGS aveva inizialmente testato una varietà di concetti, perché non dovevano solo valutare l'interazione di navigazione, ma anche creare il giusto equilibrio con il resto della pagina ed evitare disordine.

Decidere il concetto

Data la complessità del sito web, era fondamentale che la navigazione rimanesse sempre visibile e informasse l'utente dove si trova all'interno della struttura ad albero. Invece di dividere la navigazione in due parti nell'interfaccia utente, volevamo che il nuovo sistema di navigazione fosse fluido (dal livello superiore fino ai livelli inferiori). Pertanto, doveva consentire all'utente di navigare facilmente su e giù nell'albero di navigazione, nonché lateralmente attraverso le sezioni principali.

Per testare e convalidare tutte queste combinazioni, abbiamo sviluppato un prototipo per ciascuno degli otto concetti di navigazione iniziali. I prototipi hanno confermato ciò che il team interno già sospettava: l'opzione più praticabile in termini di usabilità, manutenzione, esperienza cross-screen, disordine visivo e appeal era che la navigazione fosse posizionata nella barra laterale su schermi di grandi dimensioni e che appaia come un menu a tendina su piccoli schermi. In sostanza, il modulo di navigazione sarebbe funzionalmente e visivamente autonomo, indipendentemente dalle dimensioni dello schermo.

Mentre ci concentreremo su decisioni di interazione specifiche tra un minuto, vale la pena sottolineare che i prototipi interattivi non devono necessariamente essere scartati una volta che un concetto prototipo è stato testato e convalidato.

Prototipazione intelligente

Sviluppiamo sempre prototipi direttamente in HTML, CSS e JavaScript utilizzando markup semantico, accessibile e robusto, perché spesso siamo quindi in grado di riutilizzare i prototipi iniziali più avanti nel processo di progettazione. Ciò significava che il nostro prototipo iniziale per il nuovo sistema di navigazione è diventato la pietra angolare per l'eventuale prototipo di sito Web completo, che includeva tutti i modelli di pagina ei moduli.

Nel fornire il prototipo completo, ci siamo anche assicurati che la guida di stile fosse generata automaticamente per il team SGS. Inducendo il team di progettazione di SGS a pensare in termini di progettazione e sviluppo di moduli, piuttosto che di pagine complete, la guida di stile generata richiederebbe poca manutenzione continua. La stessa guida di stile fa riferimento a tutti i moduli distintivi utilizzati, con ogni modulo contenente una descrizione precisa, un esempio di codice e un collegamento generato automaticamente al modello di pagina in cui viene utilizzato. La nostra tecnologia preferita per l'automazione di attività e funzionalità è PHP, ma l'automazione può essere ottenuta utilizzando qualsiasi linguaggio lato server, purché l'output sia HTML semantico. (Abbiamo sviluppato un framework di file system specifico per i nostri prototipi, ma questo è un argomento per un'altra occasione.) Più avanti in questo articolo, spiegheremo come lo scripting lato server ci ha aiutato a mantenere e testare più versioni della navigazione.

Anche se iniziare con un HTML semantico, accessibile e robusto è fondamentale, il principio "content-first, navigation-second" è altrettanto importante perché ti aiuta a tenere conto di eventuali future eccezioni. C'era un'eccezione alla regola "content-first, navigation-second" in questo progetto: la home page. Abbiamo scoperto, sulla base dell'analisi, che la navigazione era vista come l'elemento più importante della home page, il che significava che doveva precedere qualsiasi contenuto principale della pagina.

Interazione e usabilità

Una volta presa la decisione di progettare e sviluppare un modulo di navigazione autonomo, indipendente dalle dimensioni dello schermo, è arrivato il momento di concentrarsi sulle interazioni di navigazione. Considerando che abbiamo adottato un approccio mobile first alla progettazione della navigazione, il modulo di navigazione stesso non solo funzionerebbe naturalmente come previsto nelle finestre piccole, ma si adatterebbe facilmente anche alle finestre grandi.

Tre versioni interattive

A causa delle dimensioni della navigazione e del numero potenziale di livelli nidificati, abbiamo dovuto eliminare alcuni dei modelli di navigazione mobile più comuni come opzioni, ad esempio selezionare i menu a discesa e il modello priority+. Ci siamo concentrati sulla prototipazione di tre versioni interattive della navigazione: uno slider, una fisarmonica e una fisarmonica e uno slider. Ognuno ha i suoi pro e contro, che naturalmente hanno influenzato la nostra decisione.

Fisarmonica

La fisarmonica è probabilmente il modello più comune sui dispositivi mobili. Si divulga progressivamente, rivelando informazioni più dettagliate man mano che l'utente avanza nell'argomento o nell'azione. Garantisce inoltre che l'utente non venga sopraffatto, motivo per cui abbiamo voluto utilizzarlo come soluzione di base.

Ecco i pro della fisarmonica:

• Gli utenti lo conoscono.
• Gli utenti possono espandere l'intero albero di navigazione per visualizzare in anteprima più opzioni (sette livelli di navigazione possono essere un po' opprimenti, dopo tutto).
• Funziona senza JavaScript, utilizzando la pseudo-classe :target .
• Svilupparlo è facile.

E i contro della fisarmonica:

• Gli antenati espansi di una categoria di livello profondo spingerebbero l'attuale mirino troppo lontano dalla parte superiore dello schermo, richiedendo così molto scorrimento.
• Sette livelli di navigazione richiedono sette gradi del segnale visivo scelto, che si tratti di sette sfumature di un colore di base (grigio), sette livelli di gerarchia tipografica o sette livelli di rientro.

Dispositivo di scorrimento

Questa era inizialmente la nostra soluzione preferita, ma manca un elemento importante: consentire una navigazione davvero laterale tra le sezioni principali. Non sarebbe un problema se l'utente iniziasse a navigare sempre dalla home page, perché acquisterebbe sempre più familiarità con le sezioni principali. Tuttavia, per gli utenti che atterrano su una pagina in profondità nell'albero di navigazione, sarebbe sicuramente stato un problema di usabilità. Ad esempio, gli utenti che atterrano al terzo, quarto o quinto livello dovrebbero attraversare l'albero per raggiungere la pagina dei contatti. Attraversare sette livelli non è divertente, non importa quanto motivato possa essere l'utente.

Pro dello slider:

• La gerarchia è chiara.
• L'animazione è fluida.
• Segue le convenzioni mobili.
• È relativamente facile da sviluppare.

Contro del dispositivo di scorrimento:

• La navigazione laterale non è possibile.
• L'animazione non è performante.

Ibrido (fisarmonica e slider)

Volevamo davvero mantenere l'attrattiva dello slider, pur consentendo la navigazione laterale. Pertanto, abbiamo sviluppato una soluzione ibrida che combina i migliori elementi dei due modelli di navigazione. Per inciso, è stata anche la soluzione su cui abbiamo deciso.

Pro ibridi:

• È possibile la navigazione laterale.
• L'animazione è fluida.
• La gerarchia è chiara.

Contro ibridi:

• Richiede un po' di apprendimento iniziale.
• È complesso da sviluppare, con molte parti mobili da considerare.
• Ha alcuni problemi di prestazioni.

Come accennato, l'utente dovrebbe essere in grado di navigare su e giù per l'albero di navigazione, sempre consapevole di dove viene e dove lo porterà la navigazione successiva. Tuttavia, questa è solo l'interazione di base: abbiamo dovuto affrontare alcuni problemi aggiuntivi per sviluppare un sistema di navigazione utilizzabile.

Otto tipi distinti di collegamenti

Oltre al fatto che gli elementi di navigazione attuali e precedenti sono distinti nel design (che ora, per fortuna, è una pratica consolidata), abbiamo ulteriormente migliorato la navigazione e l'usabilità generale aiutando l'utente a capire dove si trova e cosa sta esplorando. Aiutare l'utente a comprendere la pagina corrente e i suoi genitori, nonché qualsiasi relazione rilevante con i bambini, era tutt'altro che sufficiente. Sono state necessarie altre azioni importanti:

• poter andare direttamente alla pagina principale;
• essere in grado di visualizzare in anteprima sia il livello genitore che quello figlio, il tutto rimanendo all'URL originale;
• comprendere rapidamente la loro attuale posizione di navigazione, pur essendo in grado di esplorare la navigazione.
• capire rapidamente la loro posizione attuale sulla pagina.
  

Nota: abbiamo utilizzato i breadcrumb per garantire che la posizione della pagina corrente sia sempre chiara per l'utente. Poiché volevamo evitare di saltare del tutto i livelli, le informazioni nei breadcrumb e nella navigazione dovevano corrispondere uno a uno, anche con pseudo-livelli (cioè livelli che non hanno una pagina reale).

I requisiti utente di cui sopra hanno comportato cinque tipi di elementi di navigazione semanticamente diversi, con collegamenti di supporto aggiuntivi che consentirebbero all'utente di spostarsi su e giù per l'albero senza dover lasciare la pagina corrente. Puoi immaginare la complessità e le interdipendenze che derivano da così tante parti mobili.

Dettagli di animazione

Tutti gli elementi della navigazione sono animati tramite CSS, con ogni animazione composta da due parti distinte:

• livelli animati orizzontalmente,
• involucri animati verticalmente.

Innanzitutto, i diversi livelli dell'albero nel dispositivo di scorrimento vengono alternati modificando la classe del wrapper principale. Ad esempio, il wrapper di navigazione chiuso ha una classe di .depth-0 . Quando un elemento di primo livello viene espanso, la classe cambia in .depth-1 . Quando viene selezionato un elemento di secondo livello dall'elemento di primo livello, la classe cambia in .depth-2 e così via. Ciò si traduce in un insieme abbastanza semplice di regole CSS che vengono applicate a un singolo elemento: l'elenco più ordinato in un dispositivo di scorrimento:

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

Nell'esempio sopra, .l-0 corrisponde a una voce di elenco di livello zero e .nav-open viene attivato ogni volta che la fisarmonica è impostata su open . Ciò significa che l'elenco ordinato di un figlio diretto in un elemento dell'elenco a fisarmonica open è assolutamente sfalsato rispetto alla posizione negativa a sinistra.

In secondo luogo, considerando che ogni livello contiene un numero variabile di voci di elenco, la transizione tra due livelli adiacenti qualsiasi deve essere regolare.

Per raggiungere questo obiettivo, ci siamo assicurati che ci fosse sempre spazio verticale sufficiente affinché l'animazione orizzontale si svolgesse senza intoppi. L'altezza viene calcolata e applicata al volo recuperando l'offset verticale dell'elemento che sta per entrare nello schermo. Ciò significa che dovevamo tenere conto di un totale di quattro possibili scenari, ma in realtà dovevamo risolverne solo due, ciascuno con un ordine di esecuzione leggermente diverso:

• Da una voce di elenco corta a una voce di elenco più lunga . L'animazione orizzontale e verticale inizia contemporaneamente.
• Da una voce di elenco lunga a una voce di elenco più breve . Dopo che la navigazione smette di scorrere orizzontalmente, inizia l'animazione verticale.

Entrambe le animazioni vengono avviate contemporaneamente, ma la seconda animazione viene avviata dopo un ritardo di 300 millisecondi, che è esattamente la durata della prima animazione (specificata in CSS utilizzando la proprietà transition-duration ). La ragione di ciò sono le prestazioni dell'animazione non ottimali su dispositivi meno capaci quando più livelli si sovrappongono prima di scomparire "dietro le quinte". Il codice semplificato si presenta così:

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

Ulteriori miglioramenti

Già di fronte a una complessa serie di interdipendenze, ci siamo resi conto, testando la navigazione, che c'era spazio per miglioramenti.

Innanzitutto, poiché i caratteri Web a volte vengono caricati un po' più tardi rispetto al resto della pagina, alcune stringhe di testo nella navigazione che dovrebbero trovarsi su una riga si espandono su una seconda riga prima che il carattere Web sia stato completamente caricato. Ad esempio, il collegamento della sezione di primo livello "Notizie, media e risorse" cade su due righe quando viene visualizzato con il carattere di fallback.

Poiché tutto doveva essere davvero compatto (dato che dovevamo utilizzare il posizionamento assoluto per l'animazione scorrevole), l'unica soluzione era reimpostare l'altezza dell'elemento interessato dopo il caricamento del font web. Questo è stato fatto utilizzando Web Font Loader, sviluppato da Bram Stein per Adobe Typekit e Google Fonts.

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

Nota: hai notato come abbiamo utilizzato un timeout di 5 secondi? Nei nostri test, abbiamo scoperto che questo è il punto debole che lo ha fatto funzionare sulla nostra connessione "buona 2G" di base (450 KB al secondo)!

In secondo luogo, poiché abbiamo deciso di caricare condizionalmente i nodi di navigazione al fine di migliorare le prestazioni di caricamento iniziale (ne parleremo più avanti nella prossima sezione), volevamo che l'utente fosse informato di quanti elementi di navigazione sono disponibili, in caso di ritardo durante il caricamento di un ramo dell'albero di navigazione. Lo abbiamo fatto ripetendo un'immagine di sfondo segnaposto che assomiglia a una stringa di testo.

Infine, abbiamo aggiunto il codice segnaposto nel DOM con JavaScript prima di richiedere il ramo di navigazione. Ciò mantiene il DOM il più pulito possibile.

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

Prestazione

Se ricordi, uno dei nostri obiettivi chiave nel progetto era che il sito Web avesse prestazioni migliori di almeno il 20% rispetto ai siti Web della concorrenza. Non solo abbiamo raggiunto questo obiettivo, ma così facendo abbiamo aiutato SGS a ridurre significativamente il peso complessivo della pagina ei tempi di caricamento. Dai un'occhiata alle seguenti statistiche prima e dopo:

Lo sapevi che 12.000 link equivalgono a 3 MB di HTML?

È corretto! Quando abbiamo eseguito il rendering dell'albero di navigazione completo per la prima volta nel nostro prototipo, ammontava a 3 MB di HTML puro. Nessuna intestazione, nessun piè di pagina e nessun contenuto: solo l'albero di navigazione composto da 12.000 singoli collegamenti.

Prima della riprogettazione, ogni pagina conteneva l'albero di navigazione principale e ogni pagina del settore includeva anche un albero di navigazione specifico del settore, implementato come modulo separato. Tuttavia, il design ottimizzato per il desktop ha reso la navigazione principale o specifica del settore non solo difficile da utilizzare su finestre di piccole dimensioni, ma anche difficile da mantenere. Ecco perché uno degli obiettivi chiave della riprogettazione era consolidare l'albero in un modulo unico e di facile manutenzione.

Esplorare le opzioni per migliorare le prestazioni

Per testare a fondo ciascuna delle tre versioni interattive della navigazione e per valutarne le prestazioni, era essenziale un ambiente di test flessibile. Ciò ci consentirebbe di apportare modifiche rapidamente, nonché di mantenere versioni simultanee in modo da poterle confrontare facilmente l'una con l'altra.

Considerando le dimensioni dell'albero di navigazione completo (fino a sette livelli di profondità e 12.000 collegamenti navigabili), era importante poter testare parti dell'albero di navigazione così come l'albero completo stesso. Gli sviluppatori interni di SGS sono stati in grado di esportare l'intero albero di navigazione come file CSV dal loro sistema di gestione dei contenuti, il che ci ha permesso di creare una funzione PHP facilmente configurabile per produrre l'intero albero o parte di esso, a seconda di ciò di cui avevamo bisogno testare.

La nostra funzione PHP ha anche semplificato la manutenzione HTML della struttura dell'albero di navigazione, perché il markup dei link e i nomi delle classi sopra menzionati possono essere facilmente modificati in un unico posto. L'uso di un linguaggio lato server per evitare di dover ripetere il codice potrebbe sembrare ovvio, ma la creazione di questo tipo di ambiente non è stata solo un'aggiunta gradita, ma in realtà era mission-critical, perché era il prerequisito per la sperimentazione e il test agili.

Caricamento condizionale dei collegamenti

Abbiamo detto che dovevamo caricare condizionalmente i nodi di navigazione per migliorare le prestazioni di caricamento iniziale. La domanda a cui era necessario rispondere era: quanta parte dell'albero di navigazione dovrebbe essere caricata inizialmente e quanto dovrebbe essere caricata in seguito, e quando? Dopo aver testato e confrontato i pesi e le dimensioni dei diversi rami dell'albero di navigazione, nonché aver studiato il comportamento degli utenti sul sito Web live esistente, sono emerse alcune conclusioni interessanti.

In primo luogo, i visitatori interessati a un solo tipo di settore raramente visitavano altri settori. Dopo aver sfogliato la categoria di settore selezionata, ogni visitatore in genere esplora solo un paio di altre pagine.

In secondo luogo (e come inizialmente pensato), le filiali specifiche del settore hanno causato la maggior parte del sovraccarico di prestazioni. Quando abbiamo rimosso del tutto le filiali del settore, l'HTML è stato ridotto a 70 KB, che è molto meglio di 3 MB! Tuttavia, significava che ciascuna delle 14 filiali del settore pesava tra 300 e 500 KB. Quando abbiamo frammentato ulteriormente ogni ramo di servizio, abbiamo scoperto che ogni livello successivo pesava in media circa 24 KB.

Sebbene fossimo consapevoli del fatto che l'HTML potesse essere ulteriormente ridotto ottimizzando i nomi delle classi e aggiungendo nodi DOM tramite JavaScript (ne parleremo più in un minuto), dovevamo comunque determinare se fosse meglio avviare una singola richiesta HTTP a circa 300 a 500 KB o per avviare una richiesta HTTP di circa 24 KB a ogni livello. Inizialmente, sembrava che l'invio di una richiesta di 24 KB ogni volta che l'utente avanzava più in basso nell'albero di navigazione sarebbe stato più vantaggioso. Tuttavia, ciò avrebbe comportato l'invio di più richieste HTTP sulla rete, il che era tutt'altro che l'ideale, considerando che la latenza di rete è spesso uno dei maggiori colli di bottiglia per le prestazioni del sito Web. Inoltre, non aveva senso nemmeno prevedere il caricamento di alcuna filiale del settore, tranne quando l'utente ha mostrato l'intenzione passando con il mouse su un collegamento del settore.

Data la complessità della navigazione e la quantità di link, la seguente disposizione offriva di gran lunga il miglior compromesso:

• Carica i primi tre livelli per impostazione predefinita in HTML.
• Carica la navigazione del settore con JavaScript quando viene mostrato l'intento, rilevato utilizzando l'evento di passaggio del mouseover .
• Rami caricati nella cache per velocizzare il caricamento su caricamenti di pagina consecutivi.

La logica per le pagine più profonde era leggermente diversa, perché la navigazione deve essere accessibile senza JavaScript abilitato. Pertanto, se un utente (o anche un bot di un motore di ricerca) atterra su una pagina profonda, accadrebbe quanto segue:

1. Rendering dei primi tre livelli e del ramo predecessore della pagina corrente e dei fratelli di pagina in HTML, consentendo così all'utente di accedere facilmente alle pagine padre, predecessore e fratello, potendo anche accedere ad altre parti del sito Web seguendo la stessa logica.
2. Carica il ramo corrente con JavaScript e sostituisci il ramo predecessore della pagina corrente inizialmente caricata.

Ottimizzazione dell'HTML

Se vuoi davvero ottimizzare il tuo HTML, tutti gli elementi non essenziali devono essere scaricati su CSS e JavaScript. Abbiamo rigorosamente eliminato tutto tranne l'elenco ordinato, le voci dell'elenco e i rispettivi collegamenti. Tutti i link non essenziali (cioè gli aiuti alla navigazione) sono stati rimossi anche dall'HTML e sono reinseriti nel DOM usando JavaScript (perché sono comunque inefficaci senza JavaScript). Questi collegamenti non essenziali consentono all'utente di fare un paio di cose:

• aprire il livello successivo (internamente, abbiamo chiamato questi "expanders");
• salire di livello (abbiamo chiamato questi "sostenitori" - mostrando una mancanza di immaginazione).

Sebbene il DOM risultante fosse ancora immenso, gli aiuti alla navigazione non avevano più bisogno di essere trasferiti individualmente sulla rete.

Infine, l'ultima ottimizzazione che abbiamo intrapreso è stata quella di ridurre il numero di classi, nonché di accorciare la lunghezza dei nomi delle classi; ad esempio, .very-long-class-name è diventato .vlcn . Sebbene quest'ultimo abbia prodotto i maggiori guadagni, tale ottimizzazione è difficile da giustificare perché di solito non riduce in modo significativo la dimensione del file HTML e, cosa più importante, riduce la chiarezza del codice, rendendo così forse più difficile la manutenzione. Tuttavia, la riduzione anche di un singolo byte da ciascuna delle 12.000 voci dell'elenco lo ha reso un esercizio utile e un compromesso accettabile.

Il risultato? Circa 40 KB di HTML iniziale (da 8 a 9 KB se compresso e trasferito in rete) e da 200 a 300 KB di HTML per ogni settore (da 15 a 25 KB se compresso e trasferito).

Conclusione: i guadagni marginali contano

Ci piace usare un'analogia dal mondo dello sport: migliorare ogni piccola cosa dell'1% migliora notevolmente le prestazioni. Questo vale per ciò che abbiamo fatto nel progetto SGS e nella sua intricata navigazione. Concentrandoci sui dettagli più fini, migliorando di poco ogni dettaglio, abbiamo ridotto significativamente la complessità della navigazione e migliorato i tempi di caricamento, mantenendo la navigazione accattivante e coinvolgente per gli utenti. Quello che avrebbe potuto essere un incubo e un dado difficile da risolvere si è trasformato in una soluzione tecnicamente e interattivamente rilevante, abbastanza flessibile da consentire ulteriori miglioramenti.

Soprattutto, il processo di progettazione di prototipazione continua, indagine sulle opzioni e perfezionamento delle migliori soluzioni si è rivelato estremamente efficace, tanto da fornire al team interno un valido motivo per applicare gli stessi principi fondamentali nello sviluppo di altri prodotti nell'organizzazione, senza contare che aiuterà il team a continuare a perfezionare e ottimizzare il nuovo sistema di navigazione. Nessun progetto web è mai veramente completo; ci sono sempre alcune cose in più nell'elenco delle cose da fare. Va benissimo, purché continuiamo a testare, perfezionare e fornire la migliore esperienza agli utenti.