El arte de maquetar para ser leído
Una reflexión sobre el tratamiento histórico de la maquetación web y la necesidad de nuevos formatos
Desde que empezamos a desarrollar nuestros primeros visores de libros electrónicos hace ya más de 5 años, nuestra relación con la edición y la lectura ha ido creciendo sin parar.
Los primeros compases de esta relación se centraron más en las herramientas de lectura y marcado que en la maquetación propiamente dicha, dado que esta surgía del proceso de convertir de forma automática los contenidos preparados para ser consumidos en papel (en cualquiera de las versiones recogidas bajo el estándar PDF) a los formatos propios de internet (HTML5 + CSS3) . Pero cuando empezamos a trabajar en Content First todo cambió.
Cuando empezamos el desarrollo de nuestro CMS editorial (sistema de gestión de contenidos por sus siglas en inglés: Content Management System) muestra premisa fundamental era la de separar el contenido de la forma, permitiendo a los autores trabajar en conjunción con el equipo editorial en la nube en un contenido base que tomaría diversas formas según los distintos formatos a generar: versión para impresión, versión para su consumo en pantalla, aplicaciones nativas para iOS / Android, materiales complementarios, cursos online, etc.
Antes de nada es importante matizar el tipo de problema que estamos intentando resolver:
La mayor parte del negocio de la industria editorial está enfocado a ficción adulto, que tiene unos requisitos de maquetación mínimos y muchos formatos (como es el caso de ePub) capaces de resolver el problema con soltura.
En nuestro caso la solución está enfocada a publicaciones científico técnicas y más generalmente a contenidos orientados a formación, por lo general ricos en ilustraciones y recursos, y de formato mucho más complejo.
Esta separación nos permite trabajar en un contenido semántico común a los distintos formatos en los que será presentado, aunque dichos formatos están muy presentes en la definición de la semántica del mismo. Será la unión de contenido y forma la que modele el mensaje y por lo tanto el ingrediente más importante (aunque no el único) del producto que el lector finalmente consumirá.
Para hacer esto posible fue necesario reinventar nuestros formatos digitales y redefinir las prioridades de los formatos tradicionales en papel.
Este proceso nos llevó a lo que probablemente fue el mayor reto del proyecto: programar una inteligencia artificial capaz de tomar decisiones de maquetación para adaptar el contenido semántico a las características de cada superficie en la que el contenido deba ser presentado, entendiendo tanto las características funcionales de la misma (tipos de formato e interactividad) como la mejor manera de explotar el espacio disponible para presentar el contenido.
La decisión de realizar este proceso mediante una IA viene motivada tanto por la explosión actual de formatos de pantallas (además de las versiones para papel) como por la necesidad de disponer de contenidos vivos, que necesariamente no pueden implicar la re-maquetación de todos los formatos tras cada modificación.
Si he visto más lejos es porque estoy sentado sobre los hombros de gigantes. (Bernardus Carnotensis)
Para poder lograr un reto de esta magnitud, tomamos la decisión desde el primer día de basar en HTML5 todos los elementos de interface, tanto el contenido semántico como las herramientas, sustentando nuestros esfuerzos sobre los pilares del mundo de la web (en el que los gigantes de nuestra industria han depositado la mayor inversión que probablemente se haya realizado jamas en una transformación tecnológica).
Ya en enero de 2012, tuve la ocasión de escuchar a Sanders Kleinfeld en una magistral ponencia en el Digital Book World de Nueva York exponer las ventajas que tiene HTML5 como estándar semántico para la industria editorial y desde entonces he visto cómo se extendía la adopción de esta propuesta.
Nosotros solo hemos llevado esta idea un paso más allá: no solo hemos querido que nuestro contenido semántico se base en HTML5, sino que la presentación del mismo (incluso la enfocada a ser impresa en papel) también adopta los estándares de internet.
Pero no todo fueron ventajas en el camino, y esa es la razón de este artículo.
Como parte del viaje tuvimos que descubrir los porqués de los modelos de maquetación tradicionales y cómo en nuestro día a día, en el mundo web, pisoteábamos sin preocuparnos muchos de los principios que habían ido decantando a lo largo de los años (desde Gutenberg hasta nuestros días) en un proceso de descubrimiento continuo para encontrar la mejor manera de presentar un contenido pensado para ser leído.
Cuando empezamos a trabajar con maquetadores y a estudiar libros de maquetación tradicional para enseñar a nuestro sistema cómo disponer los elementos en el espacio y replicar su trabajo para la generación automática de la versión impresa de los productos de nuestros clientes, descubrimos que la inmensa mayoría de las razones que escondían las normas aplicadas durante años eran completamente recomendables también para la versión digital.
Además (aunque esto pueda ser evidente para la gente que trabaja en la industria editorial no lo es tanto para los que siempre hemos estado en el mundo web), son normas ampliamente basadas en la evidencia y sustentadas sobre muchos estudios estadísticos que ayudan a determinar el impacto que tienen en la lectura sostenida todo tipo de variaciones en el formato. Al fin y al cabo nuestro cerebro tiene que realizar una cantidad muy elevada de tareas para transformar lo que están captando nuestros ojos en las palabras que percibe nuestro pensamiento consciente.
De esta forma descubrimos grandes modelos de los que no habíamos sido conscientes hasta entonces:
- Los cánones de tamaño que deben seguir los distintos niveles de profundidad para que percibamos correctamente los distintos estratos jerárquicos de títulos y énfasis
- El efecto que la serifa tipográfica tiene de cara a ayudar a que nuestro subconsciente sea capaz de distinguir glifos confusos y por lo tanto no generar una sensación de fatiga en sesiones de lectura prolongadas
- La relación que debe haber entre el interlineado y el tamaño de letra para evitar que se cruce de línea la lectura y simplificar la ordenación mental del contenido
- El ancho óptimo de carro (entre 60 y 80 caracteres por línea) para evitar que nos perdamos en cada cambio de renglón
- La importancia del ritmo horizontal (una rejilla imaginaria como las que empleamos en web verticalmente que garantiza el equilibrio entre todas las líneas base de los textos)
- La estructura de referencias, su ordenación, su correcta nomenclatura y la relación de distancia que debe de existir entre la referencia al recurso y su incorporación al contenido
- La importancia de evitar viudas y huérfanas
- Qué elementos pueden ser separados y cuáles nunca deben separarse para no alterar el significado semántico
Estudiando estos y otros puntos enseguida comprendimos dos cuestiones básicas:
- Los cánones de formato visual de la web habían evolucionado conforme a una necesidad: mensajes (en muchas ocasiones de carácter publicitario) cortos y contundentes, y no para el estudio y la lectura sostenidos
- A día de hoy en los distintos LMS (Learning Management Systems) con los que hemos tenido ocasión de trabajar los estudios del impacto formativo (sobre todo en estudios de grado y postgrado) siempre indican lo mismo: a día de hoy el texto escrito sigue siendo el elemento que más impacto tiene en el proceso de aprendizaje
¡Ojo!. Con esto no quiero decir que los videos, animaciones y otros formatos no sean útiles. Por contra son muy capaces de ayudar a establecer mapas mentales, introducir temas, incentivar al estudio despertando interés, pero en casi todos los escenarios los pilares fundamentales de la formación son la base teórica y el entrenamiento práctico de dicha base.
La combinación de estas dos cuestiones da como resultado una realidad incómoda: en la actualidad sigue costando encontrar formatos de calidad para el estudio y (como muestra de nuestra falta de acierto tecnológico) la mayor parte de los materiales empleados en los sistemas de formación digital como soporte documental a día de hoy están o bien en formato PDF (y derivados como visores online) o bien en formatos que dificultan tremendamente la lectura sostenida.
No es raro escuchar a alumnos universitarios decir que prefieren el papel para estudiar (a pesar de que muchos de ellos son nativos digitales) y con lo que sabemos a día de hoy no les quitaría la razón.
Creo que en esta ocasión una parte muy importante de la responsabilidad recae sobre la parte tecnológica que, en un acto de prepotencia, no ha sabido entender la importancia y naturaleza de los formatos formativos tradicionales y se ha apresurado a reemplazarlos con animaciones y artificios que solo sirven para resolver una pequeña parte del problema.
Creo que en este caso comprender el problema fué la parte más importante de darle solución.
La solución propuesta
El espectro de formatos de superficie en los que se debe mostrar un contenido ha explotado en los últimos años y resulta cada vez más complejo aprovechar el espacio disponible en todas estas superficies.
Abarcar desde la pequeña pantalla de un SmartWatch o un teléfono móvil (no seré yo quien anime a nadie a estudiar en su reloj, pero no para de sorprenderme lo bien que está funcionando el m-learning últimamente) hasta las enormes pantallas de las smart TV con 4K, pasando por tablets, netBooks, portátiles y monitores de todos los gustos y colores (cada vez de mayor tamaño) con un solo formato en el que compaginar un ancho de carro adecuado para la lectura con el aprovechamiento del espacio solo tiene una solución posible: la maquetación en columnas.
Si nos imaginamos una pantalla como la que yo empleo para trabajar (una pantalla 4K que cada vez serán más comunes) no resulta difícil entender el problema: O empleamos una fuente inmensamente grande (cosa que no sería recomendable) o una longitud de línea muy larga llevando el carro de extremo a extremo (con las dificultades que esto supone cada vez que nuestro ojo tiene que cambiar de línea) o aplicamos la solución tipo: colocar el contenido en una sola columna (típicamente centrada) desaprovechando la mayor parte del espacio disponible o maquetamos en múltiples columnas.
Si estás viendo este artículo en un monitor de HD o superior no te costará entender la naturaleza del problema (dado que con la ventana maximizada se desaprovecha casi todo el espacio) y eso que a mi parecer Medium ofrece una excepcional experiencia de lectura.
El problema que trae consigo el uso de múltiples columnas es que es intrínsecamente incompatible con el desplazamiento (scroll) vertical al que todos estamos acostumbrados.
Bajar a la parte inferior de una columna para tener que subir para leer la siguiente sencillamente no funciona para textos largos y hace que todas nuestras buenas intenciones de mejora de formato se vayan al traste.
Afortunadamente con los grupos de prueba hemos podido comprobar que la curva de aprendizaje es rápida y se establece el hábito de uso del nuevo patrón de desplazamiento de forma natural y rápida.
Un problema asociado es que algunos dispositivos (ratones especialmente) no están preparados para esto, pero incorporando la funcionalidad de desplazamiento de columna en las teclas y mapeando el scroll del ratón para esta funcionalidad todo se comporta como queremos.
Dado que establecemos el desplazamiento horizontal para movernos por el contenido de un artículo o capítulo, resulta intuitivo incorporar el desplazamiento vertical para movernos entre los distintos capítulos, haciendo que el proceso de desplazamiento por la obra sea lo más orgánico posible.
Solo hay una excepción a este modelo: aquellos escenarios donde las características del dispositivo haga recomendable la lectura a una sola columna.
En este caso (por ejemplo en el uso en un teléfono móvil) el desplazamiento por el texto es vertical y nos moveremos por los distintos capítulos horizontalmente.
Antes de que la inteligencia artificial inicie el proceso de maquetación, lo primero que hará el sistema es determinar el número óptimo de columnas para mostrar, identificando un ancho que (dado el tamaño de letra que esté empleando el usuario) cumpla con la norma de mostrar entre 60 y 80 caracteres por línea al mismo tiempo que cuadre con el ancho de la pantalla para no dejar una columna parcial en el lado derecho (principio de paridad).
Si como resultado de esta operación el sistema toma la decisión de que lo oportuno es maquetar a columna sencilla, será cuando se adopte la modalidad de scroll horizontal, estando disponible para aquellos usuarios que elijan tamaños de letra muy grandes o modifiquen el ajuste de número de caracteres por recomendado por línea.
Es importante indicar que, a pesar de que hemos dado la opción de ajustar el formato al modo de desplazamiento vertical habitual en la web, tras observar las estadísticas ninguno de los usuarios de la plataforma están empleando esta opción a día de hoy (en algunos casos la han probado durante un tiempo decantándose finalmente por la maquetación en columnas).
Los grandes retos y resistencias del HTML5 actual
HTML5 ha ayudado mucho en el proceso y ha permitido solucionar el 95% del problema, la cuestión es que el 5% adicional ha resultado muy complejo y, aunque todos damos por sentado que permite hacer casi cualquier cosa, aún le faltan algunos matices para cubrir todas las necesidades de un proyecto así.
Un estándar de maquetación en columnas insuficiente
En general siempre que menciono HTML5 en el artículo me refiero a la combinación de HTML5 + CSS3, y en este caso específico es la especificación CSS3 la que se queda a medio camino.
CSS3 incorpora una nueva forma de definir maquetación por columnas que nos permite hacer bastantes cosas si lo aplicamos bien:
div.columnas {
column-width: 200px;
column-gap: 40px;
width: auto;
height: 400px;
}Nota: en los ejemplos emplearé los nombres de propiedades CSS genéricos y no los propios de cada navegador para simplificar la explicación.
Con este ejemplo cuantos más párrafos y texto tengamos en un div con la clase columnas más crecerá de manera horizontal, manteniendo un ancho de columna de 200px y un alto de 400px con una separación entre columnas de 40px.
El problema con el que nos topamos fue el de hacer que un elemento se muestre maquetado a doble columna:
Comprobamos que en la especificación hay una propiedad CSS3 aplicable a los elementos interiores del contenedor con maquetación por columnas para que este ocupe múltiples columnas denominada column-span . Lamentablemente y a pesar de lo que cabría esperar: solo acepta los valores all y none (aparte de los generales inherit, initial, y unset).
Tras dedicar mucho tiempo tuvimos que abandonar este enfoque y construir nuestro propio engine de maquetación por columnas en JS.
Es muy probable que nos hubiéramos encontrado con otro tipo de problemas derivados de la gestión del tracking, el ritmo horizontal, la ubicación de recursos en determinadas posiciones y la división de tablas, pero este primer problema nos dejó con la sensación de que el sistema de columnas en HTML5 estaba muy lejos de su madurez.
Uno de los principales problemas que afrontamos con nuestro engine de maquetación de columnas es el de que en muchas ocasiones es necesario tomar la decisión de dividir un párrafo entre dos columnas preservando su estado, por ejemplo: evitando que la última línea de la primera columna quede en bandera si hay una palabra a medias cortada por un guión en un párrafo justificado.
La única solución que encontramos a este problema fue la de crear dos párrafos, uno añadido a cada columna (ambas con overflow:hidden;):
- El primero añadido a la columna inicial (quedando el texto sobrante oculto al salir de la columna).
- El segundo incorporado en la siguiente columnas con un
topomargin-topnegativo igual al total del elemento menos el espacio que empleamos de la columna anterior.
Como se puede ver en la imagen de “párrafo partido complejo” este modelo puede complicarse algo más en algunos escenarios, pero nos ha funcionado siempre por compleja que fuera la casuística que quisiéramos resolver.
Curiosamente después de aplicar esta solución nos topamos en algunos foros con un equipo que había recorrido exactamente el mismo camino y había desarrollado FTColumnflow. El equipo responsable (FT Labs) es el laboratorio tecnológico del Financial Times y hemos intercambiado información en numerosas ocasiones sobre alguno de los problemas en foros (especialmente en lo relacionado con la parte de impresión).
Como parte de su desarrollo ilustran muy bien la naturaleza de la solución:
La separación silábica incompleta para nuestro idioma
CSS3 a día de hoy nos permite controlar la separación silábica la propiedad
hypens, pero presenta problemas en español en distintos navegadores, incluidos algunos raros en Google Chrome.
Afortunadamente HTML nos permite crear nuestras propias reglas de separación silábica desde tiempo inmemoriales empleando el código ­ (soft hyphen) entre las sílabas de una palabra.
De este modo el navegador conoce cómo partirlas en caso de ser necesario.
Pues por raro que parezca, no encontramos ninguno de calidad escrito en JavaScript (y eso que tiene toda la lógica del mundo emplearlo en el lado cliente para evitar una sobrecarga de comunicación innecesaria) y tuvimos que desarrollarlo internamente, así que en cuanto tengamos un hueco lo publicaremos como paquete NPM para ahorrarle el trago al resto de miembros de la comunidad que tengan que sufrir este este mismo problema.
La velocidad del DOM
Este fue uno de los puntos clave a la hora de darle a la IA de maquetación información sobre el tamaño de los distintos elementos.
Todos conocemos bien este problema, de hecho empleamos React, su Virtual DOM y su fantástico algoritmo de reconciliación de contenidos para no tener que lidiar directamente con el DOM.
Pero hay un escenario que no cubrimos con esta solución: conocer información que solo está disponible tras añadir elementos al DOM.
Una de las tareas más importantes que tiene que realizar la IA de maquetación es jugar con el tracking (la separación entre palabras y caracteres) para conseguir que desaparezca una palabra suelta, que un párrafo acabe justo al final de una columna y en ocasiones recombinando el tracking de muchos elementos generar un hueco más adelante que de lo contrario no podría existir.
Es un proceso muy complejo que requiere de una información concreta: dado un ancho de columna, y los ajustes que el usuario haya elegido de tipo de letra, tamaño, etc. ¿Cuántos pixels de alto requiere un párrafo (o lista, tabla, pie de recurso, énfasis, etc.) para el navegador actual?
Y digo para el navegador actual porque sorprendentemente varía. Incluso varía para un mismo navegador dependiendo de los ajustes de suavizado de texto del propio navegador o del sistema operativo. Y por supuesto varía para un mismo navegador según el sistema del usuario.
Desde que programaba en Turbo C de Borland hasta hoy es la primera vez que tengo un lenguaje de programación de UX que no me permite hacer un MeasureString (por citar la versión de c# que fue la última que tuve que emplear, prima hermana de la clase FontMetrics de Java).
Incluso soluciones como la que ofrece FontMetrics son muy poco óptimas en rendimiento, teniendo que pintar los glifos en un canvas, cosa que debería ser mucho más sencilla a estas alturas para los navegadores.
La solución: por sorprendente que parezca y tras probar muchas técnicas nuestro sistema hace lo siguiente:
- Según se obtiene el contenido de un artículo del servidor (en nuestro caso vía Web Socket para mejorar la latencia) se añade en bloque a un a zona no visible de pantalla (mientras sigue la señalización de carga) en 5 columnas con 5 valores de tracking distintos, estableciendo todo el markup en bloques de una sola vez.
- El el componentDidMount un algoritmo recorre cada una de esas grandes columnas virtuales para recoger la muestra del tamaño de los elementos en los distintos trackings, enriqueciendo la estructura de datos del artículo con la información sobre dimensiones y eliminándolo del DOM con un cambio de estado para pasar de esta fase de pre-procesamiento a la fase de maquetación.
- Se invoca la IA con toda la información de cómputo de tamaños preprocesada para que genere la jerarquía de columnas a pintar.
- Finalmente se pinta el modelo de datos ya estructurado en columnas mediante componentes React.
Gracias a este sistema, el tiempo de maquetación de un artículo muy largo (unas 70 páginas impresas en tamaño folio y más de 100 columnas en una pantalla HD con el navegador maximizado) requiere un promedio de 287 milisegundos.
Hay que tener en cuenta que para este mismo contenido nuestro modelo inicial habría tardado varios segundos en calcular la estructura óptima del artículo.
El ritmo horizontal
Antes de nada tuvimos que adaptarnos nuestro mindset para expresar cualquier medida visual en
em(normalmente fracciones de1em).
Pero esto solo fue el principio, dado que en muchas ocasiones (imágenes por ejemplo) la disposición en línea hacía que los elementos siguientes quedasen desplazados con respecto a su ritmo horizontal.
Por lo que para que todo funcione correctamente, junto con cada recurso recibimos información sobre su relación de aspecto y la maquetación deseada (1/2 columna, 1 columna, 3/2 columna o 2 columnas) y el sistema basa los cálculos en estos valores.
Es en la fase de pintado en la que según lo que la IA determine como resultado final de la maquetación (teniendo en cuenta la información sobre la densidad de píxeles del dispositivo) solicitará una u otra resolución del recurso al servidor (que tiene siempre precalculada una matriz de resoluciones para todos los recursos).
Tablas… un mundo aparte
Probablemente uno de los elementos que más trabajo ha llevado en todo el proceso es el algoritmo de división de tablas.
En este caso Miguel Rodríguez Rosales ha asumido la totalidad del esfuerzo.
Entre otros muchos retos, cabría destacar el que supuso la división de tablas.
El sistema detecta el tamaño de columnas adecuado para mostrar una tabla, que si tiene mucho contenido será a doble columna.
Pero en ocasiones encontramos tablas enormes (que ocupan múltiples páginas en la versión impresa) y deben de ser divididas, indicando que es continuación del fragmento anterior.
Para esto el sistema debe de identificar las cabeceras que tiene que repetir para titular correctamente la continuación de la tabla.
En contenidos con títulos parciales a mitad de tabla, collspans, rowspans y todo tipo de estructuras complejas la resolución de este problema fue realmente compleja.
Por ejemplo, si la resolución vertical de de la pantalla solo permitiera visualizar en la siguiente tabla hasta el término Meduloblastioma, pero la siguiente fila no cupiera al completo…
… el sistema tendría que realizar una división de la tabla interpretando el significado de las columnas:
Este problema se ramifica en muchas variantes que muestran que la división entre contenido y forma en el caso de las tablas de HTML5 (por una cuestión de retrocompatibilidad con los primeros formato) no es ni mucho menos tan buena desde el punto de vista semántico como otras partes del estandar.
Lamentablemente la nueva definición de CSS Grid está orientada a lo contrario: no busca un modelo para expresar el significado de la información (para que el navegador la tabule de forma correcta) sino mostrar en forma de tabla (mediante una hoja de estilos) contenidos cuyo markup HTML no implica una disposición en celdas.
SVGs incrustados y tipografías
[Pendiente]
Tener que convivir con DPIs históricos
[Pendiente]
