Evolución del flujo de trabajo para diseño web

Más allá de Bootstrap, en busca de mayor control, mayor libertad
Más allá de Bootstrap, en busca de mayor control, mayor libertad

En su día dimos con un flujo de trabajo para el diseño o desarrollo web basado en Bootstrap, y nos pareció la panacea. Sin embargo, pronto tuvimos la sensación de que todavía necesitamos invertir demasiado tiempo para ajustar la interfaz a nuestras necesidades. O tal vez habíamos conseguido rápidamente un producto acabado, pero simplemente se parecía a otros tantos. Es el momento de dar un paso más y subir al siguiente nivel.

El problema

Personalmente llevo mucho tiempo investigando, dándole vueltas y chocando contra los mismos problemas, todos ellos relacionados con el uso de una plataforma o plantilla de origen ajeno:

  • Sensación de callejón sin salida. El uso de plantillas en general tiene la sana intención de ahorrar tiempo. Si encuentras un diseño que se aproxima al que tienes pensado, puede ser que encaje con pocos ajustes. Pero en cuanto necesitas alejarte un poco o añadir alguna funcionalidad extra, se empiezan a romper o alguna otra parte deja de funcionar.
  • Sensación de falta de control. El trabajo hecho por otros tiene que estar muy bien estructurado y comentado para que uno no se acabe perdiendo, pero lo peor es la intuición de que hay una parte importante del framework o plantilla que podrías ignorar o desechar, y que eso está lastrando tu productividad y el rendimiento de la página innecesariamente.
  • Frustración como diseñador. Contra el vértigo de empezar desde cero, nos encontramos la sensación opuesta. El cliente no está contento y lo atribuye a tu poca destreza diseñando. Los ajustes son imprecisos, y tú sólo te sientes autor de una parte del trabajo.

Explorando alternativas

Subir un grado implica básicamente limpiar el cajón de herramientas y quedarnos sólo con lo imprescindible, a saber:

  1. Una capa base de consuistencia gráfica y compatibilidad con navegadores, que podemos llamar un reset.
  2. Una paleta mínima de elementos gráficos por encima de la que ofrecen el sistema operativo o el navegador. Eso incluye control de tipografía, interlineado, botones, etc.
  3. Estructura adaptable, o control posicional que no dependa de tablas HTML. Éste debe ser responsive, por el predominio de los clientes móviles y la servidumbre del posicionamiento en buscadores.
  4. Una colección de módulos o elementos interactivos que responda a nuestras inquietudes como diseñador o las de nuestro cliente: navegación, animaciones, presentación de imágenes, reproducción de vídeo...

Todo esto lo incorporan frameworks como Bootstrap, UIkit, Skeleton o Foundation, pero aparte de los problemas mencionados arriba, nos encontramos con dos grandes inconvenientes:

  • Divitis. Estos sistemas obligan normalmente a anidar div's en varios niveles. Un exceso de anidamientos hace que el producto sea más frágil y más pesado, pero lo más grave es que no obedecen a la estructura real de la información, sino que existen por una cuestión de especificidad del código CSS.
  • Clasitis. En paralelo al problema anterior, se produce una proliferación de clases relacionadas con el aspecto gráfico o con los diferentes formatos (breakpoints). Esto produce una incómoda mezcla de estructura, contenido y diseño que hace difícil el mantenimieto, y mucho más difícil la separación de tareas: el diseñador, el autor y el programador trabajan sobre el mismo elemento.

Herramientas

Para separar estructura, diseño y contenido, desde mi punto de vista hay que dejar el contenido con una estructura mínima y sólo con las clases imprescindibles para alcanzar el propósito. Para ello, buscaremos una rejilla semántica (como Neat o Susy) y una hoja de estilos bien ordenada. Mientras tal vez logremos mayor precisión en menos tiempo, existe una pequeña curva de aprendizaje. En mi artículo anterior, "Un workflow para desarrollo web pensado para diseñadores" exponía algunas reflexiones sobre la necesidad de organizar un workflow eficiente, y sugería algunas herramientas. En este tiempo he estado probando más herramientas, y ahora me toca explicar por qué he decidido reemplazar algunas de ellas.

  1. Sobre el editor. El coloreado de sintaxis y el auto-completado de código son esenciales para una programación eficiente, y que eso venga por defecto para los principales lenguajes y preprocesadores es fundamental. Aunque mantengo Brackets en mi repertorio, el lugar principal lo ocupa Visual Studio Code, porque incorpora un terminal y el control de versiones Git. Es gratuíto y existen cientos de módulos para añadir lenguajes o funcionalidades.
  2. Sobre los preprocesadores. Prepros sigue siendo mi opción. Puede usarse un entorno CLI (interfaz de línea de comandos), incluyendo Ruby o Node, con herramientas de gestión de flujo de trabajo, como grunt, gulp, bower y todos los componentes, pero es un camino propenso a errores, y puede ser bastante frustrante. De hecho, para algunos componentes no hay otra opción, pero la alternativa GUI de Prepros me resuelve todos los problemas con menos trabajo, y no necesita configuración; sólo instalar y listo. Básicamente, funciona como la caja negra que se encarga de convertir todo en simple HTML, CSS y JavaScript.
    Un inciso sobre los generadores de páginas estáticas: he probado múltiples opciones basadas en Node (Metalsmith, DocPad, Assemble) y algun otro generador alternativo sobre Windows (Hugo). Las alternativas basadas en Ruby (Jekyll, Middleman) no son muy amigas del entorno Windows. Finalmente he llegado a la conclusión de que el lenguaje Jade me ofrece todo lo que necesito, y para ello me basta con tener instalado Prepros. Las partes invariables de las páginas pueden ser archivos parciales y con Jade los puedes componer sin problemas. El contenido pueden ser archivos Markdown, y así podemos trabajar contenidos, diseño y estructura por separado.
  3. Por último, pero no por ello menos importante, llegamos al punto de repensar el framework y dar un paso atrás desde nuestro querido Bootstrap. En seguida nos damos cuenta de la necesidad de ampliar horizontes. Vamos a dividir la sección del framework en cuatro: librería de mixins, sistema de retícula responsive, la colección de elementos de interfaz y los efectos especiales. Los frameworks más populares incluyen los cuatro, pero no facilitan mucho amoldarlos a las propias necesidades, básicamente al forzar el uso de clases predefinidas. Dicho de otra forma, conviene dar con una plantilla o tema predefinidos que se aproximen lo bastante a nuestra idea, o de lo contrario terminaremos invirtiendo más horas de lo esperado. Si tenéis una idea de lo que queréis, y no os importa programar un poco el diseño, sugiero seguir leyendo.

El contenido tiene su lugar en el HTML, estático o dinámico (generado por PHP, Python ...) dentro del CMS correspondiente. Pero el estilo y la estructura responsive deben residir en el CSS y los media queries. Creadores de contenido, diseñadores y programadores deben tener cada uno su territorio.

Un framework a medida

Como decía más arriba, en cuanto decidimos explorar más allá de Bootstrap, no tardamos en averiguar que necesitaremos dar con una pieza diferente para cada propósito. Echemos ahora un vistazo más próximo a las cuatro caras de nuestro framework:

  • La librería de mixins de encarga de la robustez general del sitio, dejando que los mantenedores se ocupen de la matemática, mientras nosotros simplificamos nuestro código. Eso incluye el prefijado de la compatibilidad entre navegadores (auto-prefixing) y, básicamente, el proceso de las rutinas más repetitivas e invariables. La detección de recursos del entorno web (Modernizr) y la consistencia entre navegadores (normalizer o reset) pueden funcionar sin nuestra intervención. Pero el prefijado automático sí requiere un mínimo código, y una de las mejores opciones para ello son las librerías de mixins SASS. Entre los más populares, probablemente Compass y Bourbon. Bourbon es más conciso y se ajusta a las necesidades más básicas.
  • El sistema de retícula responsive se ha convertido en el centro de cualquier web moderna y cualquier framework, ya que la navegación móvil es ahora esencial para nuestra audiencia. En esta faceta se puede hablar de dos grandes enfoques: sistemas basados en clases predefinidas donde sólo hay que decidir cuántas columnas se muestran después de cada breakpoint (utilizado tanto en Bootstrap como en Foundation), y los métodos semánticos que se definen sobre CSS (utilizado en Susy o Neat). La principal ventaja de estos últimos es que se consigue un HTML más limpio, y una separación más clara entre estructura y contenido. Además, se obtiene un código más conciso, lo que se traduce en la depuración y actualización más eficiente. Yo prefiero usar Neat, El código de Susy es un poco más escueto y como retícula es más potente, pero Neat se integra perfectamente con Bourbon y ambos son requeridos para algunos elementos que me gustan de Refills.
  • Nuestra colección de elementos de UI debería incluir los componentes gráficos elementales de la interfaz de usuario: botones, menús, cajas, estilos de texto, gestión de imagen y medios... Hay mucho material disponible en este terreno. Siempre podemos usar partes de los frameworks más conocidos: tanto Bootstrap como Foundation permiten hacer descargas personalizados incluyendo sólo lo que uno necesita. Pero por supuesto, siempre puede uno diseñar desde cero. A veces es preferible eso a aprender una nueva lista de clases. Si sólo necesitamos un botón, podemos ahorrar mucho tiempo tecleando nuestros propios mixins y clases. Después de varios proyectos similares, uno puede acabar acumulando una colección de componentes a los que nos hemos habituado, y de este modo aumentar gradualmente la productividad. Yo me quedo con Bourbon + Refills.
  • Efectos especiales. La parte más llamativa del diseño a menudo se confunde con la propia colección de elementos básicos. Pero más bien se trata de una capa adicional que puede afectar a bloques de múltiples componentes, o incluso a toda la página. Básicamente estamos hablando de animaciones y comportamientos de interfaz de usuario (menús sticky o pegajosos, efectos parallax, herramientas de galería...). Obviamente, en esta ocasión no voy a sugerir que se programe de cero. Estos efectos son lo bastante complejos como para utilizar una biblioteca existente, generalmente JavaScript, a menudo sólo CSS, o al menos usar parte de ella. Para la animación, hace poco descubrí el tándem perfecto: animate.css y wow.js . El primero ofrece una amplia gama de transiciones y efectos de reclamo. El último es el encargado de desencadenar el efecto, por ejemplo, al desplazar hacia abajo. Para cualquier otro efecto, jQuery y la lista interminable de plug-ins basados en él, son el método más recurrente. Pensemos en cualquier efecto deseado, y encontraremos el correspondiente módulo de jQuery. Por supuesto, existen alternativas (MooTools, Prototype), pero ninguno de ellos ha alcanzado un ecosistema como el de jQuery. jQuery se define como una herramienta para controlar y manipular elementos DOM.

En resumen, si nuestro framework resulta excesivo, no debemos temer la búsqueda de nuestro propio flujo de trabajo con los componentes que mejor se adapten a nuestras necesidades. No buscamos otra cosa que herramientas más cómodas y eficientes para llevar a cabo nuestro trabajo.

El resultado

Como muestra de este trabajo de optimización gradual del flujo de trabajo, os sugiero explorar mi nueva plantilla en sus dos versiones Bourbonpug (basada en Jade/Pug) y Bourbonslim (basada en Slim). En ella afloran todas mis inquietudes. De momento es sólo una página básica sin columnas, pero con algunos efectos interesantes. Poco a poco le quiero ir incorporando elementos más complejos. Para mí es un divertimento y una aportación de oxígeno a todos los quebraderos de cabeza que he ido superando. Os invito a descargarla y trastear con ella. Me ha costado encontrar algo parecido, y finalmente he decidido construirlo desde la base. Llevo tiempo buscando la sensación de disponer de una herramienta abierta, que puedes controlar y que tenga algo tuyo, y por fin siento que me voy acercando.