Rediseño del sistema de navegación de siete niveles de SGS: un estudio de caso

SGS (anteriormente Societe Generale de Surveillance ) es una organización de servicios global y proveedor de servicios de inspección, verificación, prueba y certificación en 14 industrias. El sitio web de SGS (junto con 60 sitios web localizados) promueve principalmente los servicios principales de la organización, además de brindar acceso a una multitud de servicios útiles, contenido complementario y herramientas. Nuestro objetivo era transformar sgs.com de ser solo de escritorio a ser receptivo.

Esto presentó un conjunto único de desafíos, especialmente en torno al sistema de navegación heredado, que en áreas tenía hasta siete niveles de profundidad (divididos en dos partes) y que constaba de unos 12 000 elementos navegables individuales .

Lectura adicional en SmashingMag: Enlace

• Diseño de estudios de casos: exhibición de un proceso de diseño centrado en el ser humano
• Adaptarse a un diseño receptivo
• Estudio de caso de unificación de diseño de producto
• 75 estudios de casos instructivos: así es como lo construimos

Nuestra reacción natural al ver y utilizar el sistema de navegación de SGS por primera vez fue que seguramente la arquitectura de la información (IA) tenía que simplificarse debido al gran volumen de enlaces y contenido navegables. Sin embargo, considerando que la navegación ya se había optimizado para los motores de búsqueda y el IA antes de este proyecto y considerando que SGS ofrece una amplia selección de servicios en muchas industrias (reflejado en el volumen de contenido), era evidente que refactorizar el IA no Sé parte de la solucion.

En pocas palabras, la estructura del árbol de navegación tenía que permanecer intacta. Aun así, eso no nos impidió hacer algunos ajustes menores a la IA. Por ejemplo, "Noticias, medios y recursos" y "Oficinas y laboratorios de SGS" se movieron al nivel superior para una mayor visibilidad. Con el primero, era importante reflejar más claramente que SGS publica regularmente noticias y organiza eventos. Con este último, era vital que, junto con la página de contacto, fuera fácilmente accesible desde cualquier parte de la estructura del sitio web. Por lo tanto, la pregunta clave era cómo se podía hacer que un sistema de navegación tan gigante hiciera una transición fácil entre diferentes ventanas gráficas sin dejar de ser utilizable.

Establecimiento de políticas del proyecto

Una relación saludable entre el cliente y el diseñador es esencial para el éxito de cada proyecto. Establecer expectativas claras, así como brindar orientación efectiva, garantiza no solo que las partes interesadas clave permanezcan enfocadas en todo momento, sino también que se desarrolle la confianza entre todas las partes a medida que avanza el proyecto. Este fue definitivamente el caso con este proyecto; la colaboración entre todas las partes y la apreciación mutua de los roles y la experiencia de cada uno fueron realmente notables.

Sin embargo, para asegurarnos de que todas las partes permanecieran enfocadas, establecimos en la reunión de lanzamiento una serie de pautas y requisitos importantes dentro de los cuales también podíamos ejercer la creatividad (algunos de los cuales insistimos, otros insistieron en el cliente):

• Paridad de contenido . El contenido debe ser accesible en todos los dispositivos y plataformas y bajo ninguna circunstancia debe estar oculto en el móvil.
• rendimiento El sitio web debe funcionar al menos un 20% más rápido que los sitios web de la competencia. Esto fue particularmente útil al decidir cuánta información debe ir en cada página.
• Accesibilidad . El sitio web debe cumplir con las pautas de accesibilidad WCAG 2.0 nivel AA. Logramos este objetivo, aparte de un problema de contraste de color límite, debido a la marca de la empresa.
• Usabilidad . El equipo interno tuvo que validar ampliamente los conceptos y realizar pruebas de usabilidad en persona y remotas.
• Negocio ininterrumpido . El rediseño no debería interrumpir el negocio de la empresa en absoluto. Claramente, la tarea no era optimizar los servicios de la empresa, sino optimizar el sitio web, teniendo en cuenta los procesos comerciales establecidos. Por ejemplo, teníamos la libertad de optimizar los formularios web, pero la estructura de los datos en el CRM debía permanecer intacta.

Los tres grandes desafíos

Con las pautas clave establecidas y sabiendo que el rediseño de la navegación no requeriría una revisión significativa del IA, subdividimos el rediseño en tres conjuntos de actividades clave pero interdependientes:

• Colocación de maquetas . Esto fue manejado principalmente por el equipo interno, con nosotros sugiriendo mejoras y asegurándonos de que cualquier decisión no tuviera implicaciones radicales para otros aspectos del nuevo diseño receptivo.
• Interacción y usabilidad . Estos se trabajaron en colaboración con el equipo de diseño de SGS. Las ideas se intercambiaron por correo electrónico y en talleres presenciales y se validaron regularmente con los usuarios, las partes interesadas y los requisitos generales del negocio.
• rendimiento Solo nosotros nos ocupamos de esto, porque era más un desafío técnico y no requería ninguna toma de decisiones estratégica más que hacer que el nuevo sitio web receptivo fuera rápido.

Colocación de diseño

La navegación es un elemento fundamental del diseño de la página, independientemente del tamaño o la complejidad del sitio web. Si bien un patrón fuera de la pantalla puede parecer atractivo cuando se trata de un sistema de navegación a gran escala, recuerde que puede haber problemas cuando la navegación no es visible para el usuario.

El equipo de diseño de SGS había probado inicialmente una variedad de conceptos, porque no solo tenían que evaluar la interacción de navegación, sino también crear el equilibrio adecuado con el resto de la página y evitar el desorden.

Decidir sobre el concepto

Dada la complejidad del sitio web, era vital que la navegación permaneciera siempre visible e informara al usuario dónde se encuentra dentro de la estructura de árbol. En lugar de dividir la navegación en dos partes en la interfaz de usuario, queríamos que el nuevo sistema de navegación fuera perfecto (desde el nivel superior hasta los niveles inferiores). Por lo tanto, tenía que permitir al usuario navegar fácilmente hacia arriba y hacia abajo en el árbol de navegación, así como también hacia los lados de las secciones principales.

Para probar y validar todas estas combinaciones, desarrollamos un prototipo para cada uno de los ocho conceptos iniciales de navegación. Los prototipos confirmaron lo que el equipo interno ya sospechaba: la opción más viable en términos de usabilidad, mantenimiento, experiencia de pantalla cruzada, desorden visual y atractivo era que la navegación se colocara en la barra lateral en pantallas grandes y apareciera como un menú desplegable en pantallas pequeñas. Esencialmente, el módulo de navegación sería funcional y visualmente autónomo, independientemente del tamaño de la pantalla.

Si bien nos centraremos en decisiones de interacción específicas en un minuto, vale la pena señalar que los prototipos interactivos no necesariamente tienen que descartarse una vez que se ha probado y validado un concepto prototipo.

Prototipos inteligentes

Siempre desarrollamos prototipos directamente en HTML, CSS y JavaScript utilizando un marcado semántico, accesible y robusto, porque a menudo podemos reutilizar los prototipos iniciales más adelante en el proceso de diseño. Esto significó que nuestro prototipo inicial para el nuevo sistema de navegación se convirtió en la piedra angular para el eventual prototipo completo del sitio web, que incluía todas las plantillas y módulos de página.

Al entregar el prototipo completo, también nos aseguramos de que la guía de estilo se generara automáticamente para el equipo de SGS. Al lograr que el equipo de diseño de SGS pensara en términos de diseño y desarrollo de módulos, en lugar de páginas completas, la guía de estilo generada requeriría poco mantenimiento continuo. La guía de estilo en sí se refiere a todos los módulos distintivos utilizados, y cada módulo contiene una descripción precisa, un ejemplo de código y un enlace generado automáticamente a la plantilla de página donde se utiliza. Nuestra tecnología preferida para automatizar tareas y funciones es PHP, pero la automatización se puede lograr usando cualquier lenguaje del lado del servidor, siempre que la salida sea HTML semántico. (Desarrollamos un marco de sistema de archivos específico para nuestros prototipos, pero ese es un tema para otra ocasión). Más adelante en este artículo, explicaremos cómo las secuencias de comandos del lado del servidor nos ayudaron a mantener y probar múltiples versiones de la navegación.

Si bien es vital comenzar con HTML semántico, accesible y sólido, el principio de "primero el contenido, segundo la navegación" es igual de importante porque lo ayuda a tener en cuenta cualquier posible excepción futura. Hubo una excepción a la regla de "contenido primero, navegación segundo" en este proyecto: la página de inicio. Descubrimos, según los análisis, que la navegación se consideraba el elemento más importante de la página de inicio, lo que significaba que tenía que estar antes que cualquier contenido central de la página.

Interacción y Usabilidad

Una vez que se tomó la decisión de diseñar y desarrollar un módulo de navegación autónomo e independiente del tamaño de la pantalla, llegó el momento de centrarse en las interacciones de navegación. Teniendo en cuenta que habíamos adoptado un enfoque móvil primero para diseñar la navegación, el módulo de navegación en sí no solo funcionaría naturalmente como se esperaba en ventanas pequeñas, sino que también se escalaría fácilmente para trabajar en ventanas grandes.

Tres versiones interactivas

Debido al tamaño de la navegación y la cantidad potencial de niveles anidados, tuvimos que eliminar algunos de los patrones de navegación móvil más comunes como opciones, por ejemplo, seleccionar menús desplegables y el patrón de prioridad+. Nos enfocamos en crear prototipos de tres versiones interactivas de la navegación: un control deslizante, un acordeón y un acordeón y control deslizante. Cada uno tiene sus pros y sus contras, que naturalmente influyeron en nuestra decisión.

Acordeón

El acordeón es probablemente el patrón más común en el móvil. Revela progresivamente, revelando información más detallada a medida que el usuario avanza en el tema o acción. También garantiza que el usuario no se sienta abrumado, razón por la cual queríamos usarlo como una solución de referencia.

Aquí están los pros del acordeón:

• Los usuarios están familiarizados con él.
• Los usuarios pueden expandir todo el árbol de navegación para obtener una vista previa de múltiples opciones (después de todo, siete niveles de navegación pueden ser un poco abrumadores).
• Funciona sin JavaScript, utilizando la :target .
• Desarrollarlo es fácil.

Y los contras del acordeón:

• Los antepasados ​​​​expandidos de una categoría de nivel profundo empujarían el alcance actual demasiado lejos de la parte superior de la pantalla, lo que requeriría mucho desplazamiento.
• Siete niveles de navegación requieren siete grados de la señal visual elegida, ya sean siete tonos de un color básico (gris), siete niveles de jerarquía tipográfica o siete niveles de sangría.

Deslizador

Inicialmente, esta fue nuestra solución favorita, pero pierde un elemento importante: permitir una navegación verdaderamente lateral a través de las secciones principales. No sería tanto problema si el usuario empezara a navegar siempre desde la página de inicio, ya que se iría familiarizando cada vez más con las secciones principales. Sin embargo, para los usuarios que aterrizan en una página en lo profundo del árbol de navegación, definitivamente habría sido un problema de usabilidad. Por ejemplo, los usuarios que aterrizan en el tercer, cuarto o quinto nivel tendrían que atravesar el árbol para llegar a la página de contacto. Atravesar siete niveles no es divertido, sin importar cuán motivado esté el usuario.

Ventajas del deslizador:

• La jerarquía es clara.
• La animación es resbaladiza.
• Sigue las convenciones móviles.
• Es relativamente fácil de desarrollar.

Contras del control deslizante:

• La navegación lateral no es posible.
• La animación no es performante.

Híbrido (acordeón y slider)

Realmente queríamos mantener el atractivo del control deslizante, al mismo tiempo que permitíamos la navegación lateral. Por lo tanto, desarrollamos una solución híbrida que combina los mejores elementos de los dos patrones de navegación. Por cierto, también fue la solución que decidimos.

Ventajas híbridas:

• La navegación lateral es posible.
• La animación es resbaladiza.
• La jerarquía es clara.

Contras híbridos:

• Requiere un aprendizaje inicial.
• Es complejo de desarrollar, con muchas partes móviles a considerar.
• Tiene algunos problemas de rendimiento.

Como se mencionó, el usuario debe poder navegar hacia arriba y hacia abajo en el árbol de navegación, siempre sabiendo de dónde viene y hacia dónde lo llevará la navegación a continuación. Sin embargo, esa es solo la interacción básica: tuvimos que abordar algunos problemas adicionales para desarrollar un sistema de navegación utilizable.

Ocho tipos distintivos de enlaces

Además de que los elementos de navegación actuales y antiguos tienen un diseño distinto (que ahora, afortunadamente, es una práctica bien establecida), mejoramos aún más la navegación y la usabilidad general al ayudar al usuario a comprender dónde se encuentra y qué está explorando. Ayudar al usuario a comprender la página actual y sus padres, así como cualquier relación relevante con los hijos, estaba lejos de ser suficiente. Se requirieron otras acciones importantes:

• poder ir directamente a la página principal;
• poder obtener una vista previa de los niveles principal y secundario, todo mientras permanece en la URL original;
• comprender rápidamente su posición actual de navegación, mientras puede explorar la navegación.
• comprender rápidamente su posición actual en la página.

Nota: Usamos migas de pan para asegurarnos de que la posición actual de la página siempre sea clara para el usuario. Como queríamos evitar saltarnos niveles por completo, la información en las migas de pan y la navegación tenían que coincidir uno a uno, incluso con pseudoniveles (es decir, niveles que no tienen una página real).

Los requisitos del usuario anteriores dieron como resultado cinco tipos de elementos de navegación semánticamente diferentes, con enlaces auxiliares adicionales que permitirían al usuario recorrer el árbol hacia arriba y hacia abajo sin tener que abandonar la página actual. Puede imaginar la complejidad y las interdependencias que vienen con tantas partes móviles.

Detalles de animación

Todos los elementos de la navegación están animados con CSS, y cada animación tiene dos partes distintas:

• niveles animados horizontalmente,
• envoltorios animados verticalmente.

Primero, los diferentes niveles de árbol en el control deslizante se alternan cambiando la clase del contenedor maestro. Por ejemplo, el contenedor de navegación cerrado tiene una clase de . .depth-0 . Cuando se expande un elemento de nivel superior, la clase cambia a . .depth-1 . Cuando se selecciona un elemento de segundo nivel dentro de ese elemento de nivel superior, la clase cambia a .depth-2 y así sucesivamente. Esto da como resultado un conjunto bastante simple de reglas CSS que se aplican a un solo elemento: la lista ordenada en primer lugar en un control deslizante:

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

En el ejemplo anterior, .l-0 corresponde a un elemento de lista de nivel cero, y .nav-open se alterna cada vez que el acordeón está configurado para open . Esto significa que la lista ordenada de un elemento secundario directo en un elemento de lista de acordeón open se desplaza absolutamente a la posición negativa izquierda.

En segundo lugar, teniendo en cuenta que cada nivel contiene un número variable de elementos de la lista, la transición entre dos niveles adyacentes tiene que ser suave.

Para lograr esto, nos aseguramos de que siempre haya suficiente espacio vertical para que la animación horizontal funcione sin problemas. La altura se calcula y aplica sobre la marcha recuperando el desplazamiento vertical del elemento que está a punto de entrar en la pantalla. Esto significa que teníamos que dar cuenta de un total de cuatro escenarios posibles, pero en realidad solo necesitábamos resolver dos, cada uno con un orden de ejecución ligeramente diferente:

• Elemento de lista corta a un elemento de lista más largo . La animación horizontal y vertical comienzan al mismo tiempo.
• Elemento de lista larga a un elemento de lista más corto . Una vez que la navegación deja de deslizarse horizontalmente, comienza la animación vertical.

Ambas animaciones se inician al mismo tiempo, pero la segunda animación se inicia después de un retraso de 300 milisegundos, que es exactamente la duración de la primera animación (especificada en CSS mediante la propiedad transition-duration ). La razón de esto es un rendimiento de animación subóptimo en dispositivos con menos capacidad cuando varias capas se superponen antes de desaparecer "detrás de la cortina". El código simplificado se ve así:

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

Futuras mejoras

Ya enfrentados a un conjunto complejo de interdependencias, al probar la navegación nos dimos cuenta de que había espacio para mejorar.

Primero, debido a que las fuentes web a veces se cargan un poco más tarde que el resto de la página, algunas cadenas de texto en la navegación que deben estar en una línea se expandirían a una segunda línea antes de que la fuente web se haya cargado por completo. Por ejemplo, el enlace de la sección de nivel superior "Noticias, medios y recursos" cae en dos filas cuando se representa en la fuente alternativa.

Debido a que todo tenía que ser realmente compacto (dado que teníamos que usar el posicionamiento absoluto para la animación deslizante), la única solución era restablecer la altura del elemento afectado después de que se cargara la fuente web. Esto se hizo usando Web Font Loader, desarrollado por Bram Stein para Adobe Typekit y Google Fonts.

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

Nota: ¿Te diste cuenta de cómo usamos un tiempo de espera de 5 segundos? En nuestras pruebas, descubrimos que este era el punto ideal que hacía que funcionara en nuestra conexión básica "buena 2G" (450 KB por segundo).

En segundo lugar, debido a que decidimos cargar condicionalmente los nodos de navegación para mejorar el rendimiento de la carga inicial (más sobre esto en la siguiente sección), queríamos que el usuario supiera cuántos elementos de navegación están disponibles, en caso de que haya una demora. en la carga de una rama del árbol de navegación. Hicimos esto repitiendo una imagen de fondo de marcador de posición que se parece a una cadena de texto.

Finalmente, agregamos el código de marcador de posición en el DOM con JavaScript antes de solicitar la rama de navegación. Esto mantiene el DOM lo más limpio posible.

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

Rendimiento

Si recuerda, uno de nuestros objetivos clave en el proyecto era que el sitio web funcionara al menos un 20 % mejor que los sitios web de la competencia. No solo logramos este objetivo, sino que al hacerlo ayudamos a SGS a reducir significativamente el peso total de la página y los tiempos de carga. Eche un vistazo a las siguientes estadísticas de antes y después:

¿Sabías que 12.000 enlaces equivalen a 3 MB de HTML?

¡Eso es correcto! Cuando representamos el árbol de navegación completo por primera vez en nuestro prototipo, equivalía a 3 MB de HTML básico. Sin encabezado, sin pie de página y sin contenido, solo el árbol de navegación que consta de 12,000 enlaces individuales.

Antes del rediseño, cada página contenía el árbol de navegación central y cada página de la industria también incluía un árbol de navegación específico de la industria, implementado como un módulo separado. Sin embargo, el diseño optimizado para escritorio hizo que la navegación central o específica de la industria no solo fuera difícil de usar en ventanas pequeñas, sino también difícil de mantener. Es por eso que uno de los objetivos clave del rediseño fue consolidar el árbol en un módulo único y fácil de mantener.

Exploración de opciones para mejorar el rendimiento

Para probar a fondo cada una de las tres versiones interactivas de la navegación, así como evaluar su rendimiento, era esencial contar con un entorno de prueba flexible. Esto nos permitiría realizar cambios rápidamente, así como mantener versiones concurrentes para que podamos compararlas fácilmente entre sí.

Teniendo en cuenta el tamaño del árbol de navegación completo (hasta siete niveles de profundidad y 12 000 enlaces navegables), era importante poder probar partes del árbol de navegación, así como el árbol completo. Los desarrolladores internos de SGS pudieron exportar el árbol de navegación completo como un archivo CSV desde su sistema de administración de contenido, lo que nos permitió crear una función PHP fácilmente configurable para generar el árbol completo o parte de él, según lo que necesitáramos. Probar.

Nuestra función PHP también simplificó el mantenimiento de HTML de la estructura del árbol de navegación, porque el marcado de enlace mencionado anteriormente y los nombres de clase se podían cambiar fácilmente en un solo lugar. Usar un lenguaje del lado del servidor para evitar tener que repetir el código puede sonar obvio, pero crear este tipo de entorno no solo fue una adición bienvenida, sino que en realidad era una misión crítica, porque era el requisito previo para la experimentación y las pruebas ágiles.

Enlaces de carga condicional

Mencionamos que teníamos que cargar condicionalmente los nodos de navegación para mejorar el rendimiento de la carga inicial. La pregunta que entonces necesitaba respuesta era: ¿Cuánto del árbol de navegación se debe cargar inicialmente y cuánto se debe cargar más tarde y cuándo? Después de probar y comparar los pesos y tamaños de las diferentes ramas del árbol de navegación, así como de estudiar el comportamiento de los usuarios en el sitio web en vivo existente, surgieron algunas conclusiones interesantes.

Primero, los visitantes que estaban interesados ​​en un solo tipo de industria rara vez visitaban otras industrias. Una vez que navega por la categoría de la industria seleccionada, cada visitante generalmente continúa explorando solo un par de otras páginas.

En segundo lugar (y como habíamos pensado inicialmente), las ramas específicas de la industria causaron la mayor parte de los gastos generales de rendimiento. Cuando eliminamos las ramas de la industria por completo, el HTML se redujo a 70 KB, que es mucho mejor que 3 MB. Aún así, significaba que cada una de las 14 ramas de la industria pesaba entre 300 y 500 KB. Cuando fragmentamos aún más cada rama de servicio, descubrimos que cada nivel subsiguiente pesaría alrededor de 24 KB en promedio.

Si bien sabíamos que el HTML podía reducirse aún más optimizando los nombres de las clases y agregando nodos DOM a través de JavaScript (más sobre eso en un minuto), todavía teníamos que determinar si era mejor iniciar una sola solicitud HTTP alrededor de 300 a 500 KB o para iniciar una solicitud HTTP de alrededor de 24 KB en cada nivel. Inicialmente, parecía que enviar una solicitud de 24 KB cada vez que el usuario avanzaba más en el árbol de navegación sería más beneficioso. Sin embargo, esto habría resultado en el envío de múltiples solicitudes HTTP a través de la red, lo que estaba lejos de ser ideal, considerando que la latencia de la red suele ser uno de los mayores cuellos de botella para el rendimiento del sitio web. Tampoco tenía sentido predecir la carga de ninguna rama de la industria, excepto cuando el usuario mostraba su intención al pasar el mouse sobre un enlace de la industria.

Debido a la complejidad de la navegación y la cantidad de enlaces, la siguiente disposición ofrece el mejor compromiso con diferencia:

• Cargue los primeros tres niveles por defecto en HTML.
• Cargue la navegación de la industria con JavaScript cuando se muestre la intención, detectada mediante el evento de mouseover .
• Ramas cargadas en caché para acelerar la carga en cargas de página consecutivas.

La lógica para las páginas más profundas era algo diferente, porque la navegación debe ser accesible sin JavaScript habilitado. Por lo tanto, si un usuario (o incluso un bot de un motor de búsqueda) aterriza en una página profunda, ocurriría lo siguiente:

1. Representar los primeros tres niveles y la rama principal de la página actual y las páginas hermanas en HTML, lo que permite al usuario acceder fácilmente a las páginas principal, principal y hermana, al mismo tiempo que puede acceder a otras partes del sitio web siguiendo la misma lógica.
2. Cargue la rama actual con JavaScript y reemplace la rama principal de la página actual cargada inicialmente.

Optimización de HTML

Si realmente desea optimizar su HTML, todos los elementos no esenciales deben descargarse en CSS y JavaScript. Recortamos rigurosamente todo excepto la lista ordenada, sus elementos de lista y sus respectivos enlaces. Todos los enlaces no esenciales (es decir, ayudas a la navegación) también se eliminaron del HTML y se reinsertan en el DOM usando JavaScript (porque de todos modos son ineficaces sin JavaScript). Estos enlaces no esenciales permiten al usuario hacer un par de cosas:

• abrir el siguiente nivel (internamente, los llamamos "expansores");
• sube un nivel (llamamos a estos "patrocinadores", mostrando una falta de imaginación).

Si bien el DOM resultante seguía siendo inmenso, las ayudas a la navegación ya no necesitaban transferirse individualmente a través de la red.

Finalmente, la última pieza de optimización que emprendimos fue reducir el número de clases, así como acortar la longitud de los nombres de las clases; por ejemplo, .very-long-class-name se convirtió en .vlcn . Si bien este último produjo las mayores ganancias, dicha optimización es difícil de justificar porque generalmente no reduce significativamente el tamaño del archivo HTML y, lo que es más importante, reduce la claridad del código, lo que posiblemente dificulte el mantenimiento. Sin embargo, eliminar incluso un solo byte de cada uno de los 12.000 elementos de la lista hizo que valiera la pena el ejercicio y una compensación aceptable.

¿El resultado? Aproximadamente 40 KB de HTML inicial (8 a 9 KB cuando se comprimen y transfieren a través de la red), y 200 a 300 KB de HTML para cada industria (15 a 25 KB cuando se comprimen y transfieren).

Conclusión: las ganancias marginales importan

Nos gusta usar una analogía del mundo de los deportes: mejorar cada pequeña cosa en un 1 % mejora drásticamente el rendimiento. Esto se aplica a lo que hicimos en el proyecto SGS y su intrincada navegación. Al centrarnos en los detalles más finos, mejorando cada detalle un poco, redujimos significativamente la complejidad de la navegación y mejoramos los tiempos de carga, al tiempo que mantuvimos la navegación atractiva y atractiva para los usuarios. Lo que podría haber sido una pesadilla y un hueso duro de roer se convirtió en una solución relevante desde el punto de vista técnico e interactivo, lo suficientemente flexible como para adaptarse a mejoras adicionales.

Por encima de todo, el proceso de diseño de creación continua de prototipos, investigación de opciones y perfeccionamiento de las mejores soluciones demostró ser extremadamente eficaz, tanto que ha proporcionado un caso sólido para que el equipo interno aplique los mismos principios fundamentales al desarrollar otros productos. en la organización, sin mencionar que ayudará al equipo a continuar refinando y optimizando el nuevo sistema de navegación. Ningún proyecto web está realmente completo; siempre hay algunas cosas más en la lista de tareas pendientes. Eso está perfectamente bien, siempre y cuando sigamos probando, refinando y brindando la mejor experiencia para los usuarios.