Saltar al contenido →

Una visión crítica de los frameworks CSS

Este texto pertenece a una colección de publicaciones que he programado bajo el marco de una Guía crítica de Componentes de la Interfaz de Usuario. Está dirigido principalmente a los alumnos del Máster de Diseño Web y Creatividad de la Escuela de Negocios de la Cámara de Comercio de Sevilla, pero también puede servir de ayuda a todo el que se inicia en el Diseño de Experiencia de Usuario y en el Diseño de Interfaz de Usuario. Los profesionales con más experiencia que se acerquen a este texto quizás no encuentren nada nuevo. No obstante espero que, en su caso, sirva como excusa para abrir debate sobre la cuestión.

Los llamados frameworks HTML, frameworks CSS o frameworks Responsive de código abierto proponen soluciones —discutibles, como ahora veremos— a aspectos de composición o diseño. Algunos frameworks de esta tipología destacados son Foundation, Bootstrap, Semantic UI, UiKit o Skeleton, por ejemplo.

El primer premio a la ausencia de diseño se lo llevaría, sin duda alguna, Material Design Lite. Se trata de una un framework CSS que emula la estética de las Android User Interface Guidelines con el objetivo de vencer la fricción del producto digital respecto al sistema operativo del dispositivo a toda costa, incluso sacrificando el diseño (personalizado). El producto se mimetizará con la apariencia del sistema operativo del dispositivo.

Tres puntos a favor de los frameworks CSS de código abierto.

Seré honesto: yo utilizo frameworks CSS. No en todo los proyectos, pero los aplico. Y no todo es malo en ellos siempre y cuando los recursos se gestionen adecuadamente. Desde los objetivos que perseguimos en esta colección de artículos —gestionar y diseñar mejor los componentes de la interfaz de usuario—, podemos destacar las siguientes ventajas de los frameworks CSS:

1. Los frameworks resultan altamente eficientes porque proponen una respuesta multicontexto (responsive) cuyo mantenimiento es mínimo. Los frameworks también responden a la filosofía DRY en el momento en que incluyen un catálogo de componentes predefinidos —predefinidos a todos los niveles: visual e interacción— que hacen posible encapsular los objetos.

2. El grid o rejilla es el recurso maestro, el cual sirve como hilo conductor para trasladar un visual estático hacia una maquetación responsive. Incluso el software para el diseño de experiencia de usuario tiene en cuenta este recurso, como hace por ejemplo Axure. El grid es un recurso visual que se hace tangible a través de hojas de estilo CSS. El grid propone una suerte de esperanto entre el diseñador (de experiencia y de interfaz) y el desarrollador, entre lo estático y lo líquido. El requisito básico de todo framework CSS es que su núcleo consista en una solución de desarrollo para el grid.

Ejemplo de grid
Ejemplo de grid creado con Gridulator

3. Gracias al listado de componentes, el lenguaje y la experiencia de usuario se ha normalizado. Todos los frameworks CSS contienen prácticamente los mismos componentes. Nombran a cada componente de manera similar. Casi todos los componentes se comportan de manera similar —por ejemplo, la forma en la que mostramos una ventana modal al usuario suele ser similar. He elaborado esta tabla comparativa de los componentes más significativos. Observad que en algunos casos siendo el mismo componente se nombran diferentes o tienen variantes:

Componente Foundation Bootstrap SemanticUI UIKit Skeleton
Button (Botón) (#) (#) (#) (#) (#)
Table (Tablas) (#) (#) (#) (#) (#)
Form (Formularios) (#) (#) (#) (#) (#)
Label / Badges (Etiquetas) (#) badge
(#) label
(#) badge
(#) label
(#) (#) badge
(#) label
Alerts (Mensajes contextuales) (#) Callout (#) Alerts
(#) Alerts JS
(#) Message (#) Alert
Breadcrumbs (Migas de pan) (#) (#) (#) (#)
Pagination (Paginación) (#) (#) (#)
Navigation bar (Menús de navegación) (#) Top bar (#) Navbar (#) Menu (#) Navbar
Dropdown (Selector de opciones desplegables) (#) (#) (#) (#)
Tooltip (Descripciones emergentes) (#) Tooltip (#) Tooltip

(#) Popovers

(#) Popup (#) Tooltip
Accordion (Acordeón) (#) Accordion Menú
(#) Accordion
(#) Accordion (#) Accordion (#) Accordion
Tabs & Pills (Navegación por pestañas) (#) Tabs (#) Nav (#) Tab (#) Tab
Slider (Deslizador de contenido) (#) (#) (#)
Modal (#) Reveal (#) Modal (#) Modal (#) Modal

En contra de los frameworks.

Tres puntos en contra de un framework CSS open source:

1. El abuso de frameworks empobrece visualmente los productos digitales. Hace ya varios años que gran parte de la comunidad de diseño viene advirtiendo el problema que supone que todos los productos parezcan lo mismo —en este enlace se refieren a sitios web, pero es aplicable a cualquier otro producto en cuya base se aplique un framework CSS. Este problema se atribuía originalmente a un abuso de tendencias de diseño. Transcurrido el tiempo necesario, queda claro que es un problema de fondo del modelo de producción actual como venimos comentando artículos atrás.

2. Adormece el potencial profesional y la calidad del producto. Está bien tener herramientas que nos permitan agilizar el arranque de productos. Está bien tener procesos predefinidos para no tener que perder tiempo en tareas repetitivas. El problema es que se trata el proceso completo de creación de un producto como una tarea repetitiva en sí misma. Especialmente cuando das servicios en lugar de trabajar en tu propio producto. Y eso, adormece a la bestia. El profesional se vuelve vago en una dinámica machacona —porque somos humanos ¿a quién no le pasaría?—. Eso hace que nos alejemos en el diseño de la diferenciación, la calidad y la excelencia en la creación de productos digitales.

3. Abre una brecha entre los diferentes perfiles. El mal hábito del template y el theme predefinido apartan al diseñador del proceso. Sea por ahorro en costes o el motivo random en lenguaje entrepreneur que prefieran, se crea una brecha que aleja al diseñador del código, algo totalmente pernicioso para el producto digital. La existencia de esta brecha es tan real que a día hoy la responsabilidad en la creación de una Guía de Estilos de Producto Digital recae sobre los desarrolladores antes que sobre los diseñadores, siendo estos últimos los verdaderos responsables de ese material.

Debo añadir en este punto que no todos los desarrolladores se sienten cómodos trabajando con estos frameworks. Desarrolladores como Belén Albeza (@ladybenko) defienden sólidos argumentos en contra. Esto ocurre también en un momento en que ciertos módulos de CSS muy esperados, como CSS Grid Layout, hacen su aparición en escena.

En la siguiente entrega vamos a ver todo lo relacionado con las Guías de estilo.

Published in Sin categoría

  • Daniel Gonzalez

    En mi opinión como desarrollador web, lo que permiten los frameworks, y las plantillas, es evitar un coste como es el diseño y la maquetación. No quiero decir que en muchos casos no sea necesario, pero dependiendo del proyecto, es posible que con una plantilla basada en bootstrap, puedas conseguir un resultado bastante atractivo visualmente y un coste muy bajo, dedicando más recursos al desarrollo.

    ¿Es mejor una plantilla que un diseño a medida? Depende del proyecto, al igual que a veces puede ser mejor utililizar un software open source que hacer algo a medida, pues puede ser que te merezca la pena usar una plantilla. Depende sobre todo del proyecto y de la capacidad económica. A veces un software open source resuelve el problema mucho mejor que un software a medida, por un precio mucho menor y a veces también una plantilla queda mejor que muchos diseños a medida que se ven por ahí.

    ¿Aplica esto a todos los proyectos? No. Algunos proyectos van a requerir si o sí de desarrollo a medida y de diseños a medida.

    En el tipo de proyectos que participo, mis clientes prefieren gastar más en desarrollo y menos en diseño, y la existencia de estos frameworks lo posibilita.

    • abelsutilo

      Gracias por tu comentario @disqus_1D4I3jdilY:disqus

      Totalmente de acuerdo con lo que comentas. No estoy de acuerdo con que se ignore la labor de diseño, quiero decir que estoy de acuerdo en que lo que comentas es una realidad, es algo que ocurre día a día en muchos proyectos. Y es algo que se contempla en el post.

      Los motivos de la decisión de prescindir de un diseñador pueden ser muchos, sin duda. Unos con más justificación que otros, evidentemente. Lo que sí me parece importante señalar son las implicaciones que ello puede tener. ¿Cómo se integra en el proceso un diseñador cuando un producto ya está avanzado y se debe respetar el framework base? Esa es la cuestión.

      Mi experiencia es que, temprano o tarde, al final todo CEO quiere que su producto sea único en experiencia y estética, al margen de que el desarrollo se haya planteado muy bien rápido y en menor coste. Iterar sobre la plantilla, quizás. Eso implica inversión.

      Por lo que, a medio-largo plazo, vender como “desarrollo de menor coste” un proceso basado en framework open source es incorrecto y poco honesto. Habrá que advertir que a medio-largo plazo la inversión es la misma que sin framework. Cuestión aparte es que, como propuesta de valor para el cliente, el framework open source ofrezca libertad en el sentido de que no implica dependencias con un determinado desarrollador.