Decálogo CSS de buenas prácticas en Outsystems

INTRODUCCIÓN

Hoy por hoy es impensable desligar el concepto de tecnología y diseño. Atrás quedaron los años donde los equipos e infraestructuras informáticas eran sinónimo de grises, cableados, aparatosos componentes electrónicos y otros muchos tipos de elementos que provocan rechazo en muchos individuos a primera vista.

La tecnología contemporánea sustenta su desarrollo e integración social a través del diseño. El diseño en este contexto puede entenderse como la mano amiga que permite la usabilidad y el acceso de las personas a complejos sistemas computacionales. Es, por tanto, una capa necesaria para la unión entre usuario y tecnología.

Esta corriente ha cogido peso los últimos años y no va a dejar de crecer ya que términos como diseño Front, UI/UX y “look-&-feel” que exprimen la estética y usabilidad son requisitos mínimos para que un usuario tenga una buena experiencia a la hora de navegar en una aplicación. Ya no se exige solamente funcionalidad sino también un mínimo de armonía estética y comodidad ante los entornos virtuales. En otras palabras, en la época de las imágenes y formatos multimedia, lo atractivo y llamativo también es un factor decisivo para la prosperidad del nuevo mundo digital.

LENGUAJE CSS COMO HERRAMIENTA DE DISEÑO

CSS (siglas en inglés de Cascading Style Sheets), en español «Hojas de estilo en cascada», es un lenguaje de diseño gráfico para definir y crear la presentación de un documento estructurado escrito en un lenguaje de marcado. Este lenguaje permite idear infinidad de estéticas visuales en proyectos web, mobile e incluso otros muchos otros dispositivos. Este artículo no tiene por objetivo explicar su funcionamiento pero sí el de recalcar su importancia con el usuario. Lo que llamamos UI (User Interface) y UX (User Experience) son factores determinantes a la hora de crear afinidad entre un usuario y una interfaz tecnológica. Un diseño CSS aplicado a una web intuitiva, inteligible y visualmente agradable siempre será una victoria de la tecnología en su objetivo por ser accesible a las personas.

CSS EN OUTSYSTEMS

El CSS en Outsystems se emplea a través de hojas de estilos que dan vida a las pantallas. Cada módulo (aunque también se puede hacer a nivel de pantalla) bebe de una serie de temas donde las clases se aplican en orden de jerarquía. Si hemos asignado un tema por defecto para un módulo, las clases se aplicarán en el primer orden de jerarquía. Si esa clase no se encuentra en el tema de primer nivel, bajará al segundo nivel y así sucesivamente hasta llegar a la Base de Outsystems que suele ser el último nivel jerárquico. Este último nivel es el que se aplica por defecto al crear una aplicación y el cual aplica sus clases sobre los widgets de los que disponemos.

Una vez definido el orden debemos aplicar lo que hemos bautizado como el decálogo de buenas prácticas en CSS Outsystems, cuya finalidad es obtener un código estable, reutilizable, escalable, estandarizado y debidamente documentado. Estos son sus puntos principales:

  • Incluir índice en el Theme para facilitar navegación. La creación de un índice en nuestro tema debe ser indispensable. Es un punto de partida / base desde la cual partir y poder documentar el código debidamente. El índice de OutsystemsUI es una buena alternativa si no se ha diseñado uno propio:

  • Tener una guía de estilos que muestre a modo de museo las distintas clases de un tema de manera organizada y situar bien las clases dentro de los apartados de los índices. Esta medida ayuda a los desarrolladores a establecer un convenio sobre el diseño de los distintos widgets de Outsystems. Sirve de consulta ante la duda de cómo debemos dibujar un componente en la pantalla. En la forja de Outsystems podemos encontrar algunas aplicaciones que ofrecen este servicio, como ‘OutSystems UI Style Guide Preview’ o ante la duda consultar la guía de Patterns UI de Outsystems.

  • Dejar constancia sobre las modificaciones de clases de OutsystemsUI. Esta regla simplemente tiene por finalidad recalcar que se ha de dejar algún tipo de constancia sobre que clases están siendo renombradas desde nuestro tema, ya que se están modificando las clases de OutsystmsUI.
  • Emplear el uso de variables en colores, espaciado, tipografía y otro tipo de propiedades similares que permitan reutilizar y escalar el código. Declarar este tipo de variables contribuyen a agilizar, reutilizar y, en general, proporcionan un código mucho más estable y legible en grandes desarrollos. Es mucho más fácil cambiar el valor en una variable que ir clase por clase teniendo que cambiar ese valor manualmente de forma repetida. La sintaxis para declarar variables y asignarlas a las clases es la siguiente:
  • Primero tenemos que declarar la pseudo-clase ‘root’ que será la zona donde declararemos nuestras variables:
    :root {

    /* Color variables */

    --color-primary-food_section: #FF0000;
    --color-secondary-food_section: #FC3D3D;
    --color-tertiary-food_section: #7BB3DB;
    }

  • El siguiente paso es introducir esta variable en la propiedad que queramos asignar de la siguiente forma:

    .gantt-container-desktop {
        border-right: dashed 2px lightgray;
        color: var(color-primary-food_section);
        display: flex;
        align-items: center;
    }

  • A partir de ahora cualquier cambio de la variable en ‘root’ afectará a todas las propiedades que contengan esa variable, agilizando mucho más el código.

  • Evitar hardcodear CSS: usar siempre clases del Theme. Cuando se editan los estilos dentro de la pestaña de ‘Styles’ del Service Estudio, exceptuando el recuadro donde se introducen las clases que queremos asignar a nuestro componente, se genera automáticamente un código CSS que no queda reflejado en el tema que estemos empleando. Este código se mantiene local al componente y sus propiedades tienen más prioridad que las declaradas en las clases en el tema. Evitar generar código en esta pestaña ayuda a tener menos conflictos en el CSS y obtener un código más limpio.
  • Eludir la escritura en el theme del módulo local autogenerado. Esta regla es una simple recomendación desde el punto de vista de desarrollo. En caso de construir, por ejemplo, un Web Block,  si generamos el CSS en el tema local al módulo podemos ocultar parte de los estilos al resto del desarrollo. Sin embargo; al incluir ese código en el tema permite que los nuevos estilos sean más visibles al estar centralizados en un único tema principal. Además, a nivel de arquitectura, esta práctica proporciona una mejor práctica al ser independiente el tema del resto de módulos, lo que permite aislarlo ante posibles fallos y errores.
  • Evitar clases con parámetro "!important". Esta propiedad genera comportamientos impredecibles en los estilos de las aplicaciones. Eludir este tipo de prácticas nos evita conflictos entre distintos elementos que, a nivel de jerarquía, heredan propiedades que terminan siendo enmascaradas por el uso de !important. La única forma de aplicar las nuevas propiedades sería mediante el uso de otros !important, lo que generaría unos estilos todavía más impredecibles.
  • Buscar clases necesarias en la guía de estilos y si no están crearlas en el apartado correspondiente o pedir su creación. Una buena organización y documentación en las hojas de estilo de los temas empleados en las aplicaciones permite ubicar mucho mejor los distintos elementos y clases disponibles. Además, evita tener que repetir clases ya existentes, lo que garantiza un código mucho más pulcro. Una de las finalidades de implementar está práctica es ir conociendo y entendiendo poco a poco las distintas clases que se van generando en el tema, tanto implementadas por uno mismo como por otros desarrolladores, de forma que poco a poco se gane agilidad durante desarrollo.
  • Evitar nombres rebuscados. Utilizar las convenciones de ‘naming’ Front. *Ante duda consultar a alguien de Front. En la guía de nomenclatura BEM podemos encontrar la documentación correcta de cómo nombrar las clases CSS. Es una buena práctica ir conociendo poco a poco estas convenciones.
  • Si alguna clase deja de ser utilizada, eliminarla. En ocasiones resulta contraproducente dejar en el tema clases sin uso, ya que además de alargar significativamente la hoja de estilo puede dar lugar a múltiples confusiones o futuros problemas si se decide reanudar el uso de dichas clases. Una recomendación sería borrarlas una vez queden sin uso (la única forma de comprobarlo es mediante la lupa situada en la esquina superior derecha del Service Studio) y volver a crearlas en el apartado correspondiente en caso de necesitarlas de nuevo.

CONCLUSION

Los estilos de una aplicación y su diseño conforman una parte fundamental de los servicios tecnológicos modernos. Las buenas prácticas a la hora de generar código CSS en Outsystems sumado a un buen diseño proporcionan una cohesión fundamental a la hora del desarrollo de aplicaciones en esta plataforma. Seguir lo máximo posible estos puntos nos acercan más al propósito general de la tecnología contemporánea que exige su convergencia con el diseño.