¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.dev
Abigail Rodríguez y Susana Díaz 10/03/2021 Cargando comentarios…
Llevo trabajando como maquetadora web más de 15 años y siempre he tenido la sensación de que HTML y CSS son los grandes desconocidos en el mundo del desarrollo web. Son lenguajes fáciles de entender a priori, lo que ha llevado a creer que no es necesario conocerlos bien para usarlos. El resultado es que se han utilizado mal y, al abordarlos de esta manera, generan frustración y rechazo.
Es fácil escuchar la opinión que afirma que pronto habrá un software que maquete automáticamente un diseño. Esto revela que la maquetación a menudo se ve como un trabajo que no requiere reflexión ni creatividad, que es un trabajo rutinario. Nada más lejos de la realidad.
El desconocimiento general de todo lo que implica la maquetación ha favorecido en los últimos tiempos una tendencia a pensar que no es una tarea en la que merezca la pena gastar demasiado tiempo. A esto ha contribuido también la evolución y auge de Javascript y la explosión de frameworks JS que ha provocado dos fenómenos:
Nos encontramos entonces con una nueva situación en la que hay diferentes perfiles, toda una gama que va desde el maquetador puro al programador puro. Sin embargo, profesionalmente no es habitual que las empresas distingan estos perfiles y se requiere que el Front haga todas esas tareas. ¿Cuál es la consecuencia? Que los perfiles se preparan para conocer un poco de todo y, por tanto, se pierden conocimientos de la especialización.
Es necesario que se conozca la complejidad del desarrollo Front hoy en día y se luche para hacer un buen trabajo entre todos, sin descuidar ninguna de las partes esenciales de nuestro trabajo. Y para ello, incluso dentro de nuestro colectivo, hay que conocer y reconocer el valor de cada una de esas partes. Trabajar para lograr un producto excelente y hacerlo de la manera más eficaz.
Sacar textos, formas y colores de un diseño y replicarlo con HTML y CSS. En este concepto, una herramienta automática podría acercarse mucho al supuesto objetivo, ¿no?
Todo comienza cuando nos llega el diseño. Alguien podría pensar: “Pues ya está, empiezo a poner divs para dividir en zonas e ir metiendo los textos. Miro si hay cosas que hagan algo para montarlo con JS. Luego con CSS le doy el aspecto que muestra el diseño y ¡listo!”
Bueno, la cosa no va exactamente así. Vamos a ver qué demonios es entonces eso de maquetar. No vamos a entrar en entornos de trabajo, herramientas, cómo organizarse en este sentido, sino que vamos a hablar de los lenguajes que son la base de este trabajo.
Maquetar supone realizar una serie de tareas que se pueden abordar de diferentes maneras según la forma de trabajar de cada uno. Aquí propongo un proceso que intenta ser bastante completo para no dejar fuera temas más desconocidos, pero que forman parte de la base del trabajo de maquetación. Si queremos hacer un buen trabajo, no podemos ahorrar nada de esto:
Se puede decir que el diseño que nos llega hay que mirarlo varias veces y con diferentes “filtros”. El primero de todos es el filtro “qué información hay”. Traducir el diseño a una estructura de encabezados, secciones y textos. Escribir esa información etiquetando correctamente con HTML cada elemento y área del diseño (menú, área principal de contenidos, pie de página, elementos textuales...) pensando en qué función desempeñan.
Todo elemento decorativo lo eliminamos de nuestra visión por ahora, evitando que nos condicione a la hora de etiquetar la información. Por tanto, pensar el diseño como documento informativo, conocer bien las etiquetas HTML y usar las adecuadas para los elementos semánticos, es el primer paso para una buena maquetación. Un buen HTML ya produce un buen SEO.
Una vez tenemos esto hecho, para que nuestra web proporcione una información rica y estructurada hay que conocer y aplicar, si es adecuado a nuestro caso, el vocabulario Schema.org a través del marcado de microdatos añadido al HTML o a través del formato JSON-LD en una etiqueta <script> dentro del <head> de la página.
El siguiente filtro con el que debemos mirar en el proceso de maquetación es el visual. Ya tenemos un bonito HTML bien claro y con toda la semántica que puede proporcionar. Ahora escribimos el CSS empezando con una base general y avanzando a lo específico, dando estilos a cada elemento. Vamos de menos a más, del diseño para móvil al de tablet vertical, horizontal y desktop.
Hay que conocer bien el lenguaje y seguir unas pautas para que todo vaya bien a niveles menos evidentes: usaremos medidas relativas para que la web se adapte a todas las situaciones, también incluiremos por CSS los elementos decorativos (imágenes, iconos, etc.), los diferentes estados de los elementos (hover, focus…), y las animaciones (si las hay).
CSS es sintácticamente sencillo, pero montar todo el código CSS de una web adecuadamente no lo es. ¿A qué nos enfrentamos?
Vamos a fijarnos ahora en cómo deben comportarse los elementos que tenemos en la web desde el punto de vista de interacción visual. Analizamos qué interacciones de usuario hay que implementar y cómo. De nuevo, vamos de menos a más (de móvil a desktop) en nuestro JS.
Se trata de analizar cada clic, hover, focus, scroll, elementos colapsables, modales que abren y cierran, avisos que aparecen en determinadas acciones, menús que cambian su comportamiento en móvil respecto a desktop, información que está oculta y aparece tras un clic… Además, habrá ciertas acciones que queremos que solo ocurran en determinadas circunstancias, por ejemplo, solo si el dispositivo es “touch”, o cuando un elemento adquiere foco navegando con teclado (y no de otra forma).
Más allá de lo evidente, hay bastante interacción que hay que manejar y lograr componentes accesibles a todos los usuarios y dispositivos.
La accesibilidad realmente empieza en el punto 1. Una vez que hemos etiquetado correctamente el HTML, creado el CSS necesario, y dado la funcionalidad que se requiere, hay que prestar atención a ciertas cosas, como son esos elementos dinámicos o controles de interfaz avanzados, que necesitan que indiquemos qué son, qué hacen y en qué estado están. Para ello, tenemos que conocer el estándar ARIA (Accessible Rich Internet Applications) que nos proporciona los roles, estados y propiedades para indicar esa información. Por ejemplo, el role=”group” sirve para formar una colección de elementos con funcionalidad relacionada.
La idea importante es pensar que todo aquello que ocurre en la interacción del usuario, debe quedarle claro a este, y no podemos dar por válida una única forma de comunicárselo.
Por otro lado, tenemos que comprobar el contraste de la web y hablar con el diseñador para hacer las correcciones necesarias. También tenemos que navegar con el teclado y comprobar que no hayamos dejado obstáculos para realizar todas las acciones de esta manera.
Hay más comprobaciones pero no darán mucho trabajo si hemos hecho bien todos los pasos anteriores.
Un buen rendimiento depende de diferentes factores, algunos de ellos son responsabilidad de la maquetación, de cómo hemos organizado y construido nuestros archivos y cómo los cargamos.
Debemos conocer los procesos de construcción del CSSOM y DOM, y su combinación en el árbol de representación, conocer el estado del protocolo HTTP y las técnicas adecuadas para cada caso, conocer el modelo RAIL (response, animation, idle, load) que nos proporciona objetivos de rendimiento centrados en el usuario y recomendaciones para alcanzarlos.
Lograr un nivel óptimo de rendimiento y trabajar para mantenerlo y mejorarlo es todo un reto.
Resumiendo, podemos decir que el objetivo no es solo que la web luzca como el diseño, que no es poca cosa, ni hay que descuidar esta tarea fundamental. Pero nuestro objetivo es mayor:
Hablamos de lenguajes y del objetivo que perseguimos. Todo lo demás debe venir después y en función de esto. El interés en probar una novedad; el gusto personal o la moda impuesta incluso por el cliente son secundarios. Si uso un framework u otro, si me organizo así o asá, si uso un preprocesador CSS, otro ¡o ninguno! son cosas a menudo opinables, procedimientos de trabajo, que pueden debatirse siempre bajo la premisa de no afectar para mal el resultado y, claro está, a partir de ahí, valorar la mejor opción.
Maquetar bien no es un trabajo sencillo y requiere atención, más reflexión y cuidado del que a menudo recibe, mucho mimo y darle el tiempo necesario. Vamos a disfrutarlo y a estar orgullosos del resultado.
Fuentes y enlaces de interés:
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.