Avanza Previsión es la entidad aseguradora creada por Grupo Mutualidad Abogacía con la adquisición de Mutualidad de la Ingeniería, implantando un modelo sólido e innovador, flexible y abierto, para adaptarse a las necesidades de previsión y de ahorro tanto de los ingenieros como del resto de colectivos y particulares.
Para esta nueva entidad desarrollamos su nueva área privada de clientes, abordando un proyecto completo end-to-end que cubre el análisis, diseño técnico e implementación de la solución.
La aplicación está disponible tanto versión web como aplicación móvil para Apple y Android, poniendo a disposición de todos los asegurados de servicios como el completo catálogo de productos disponibles, actualización de datos, nuevas contrataciones, seguimiento de productos contratados, contacto con asesores, etc.
Desde el punto de vista tecnológico usamos IONIC, Angular, .Net Core, Identity Server, CI/CD y Azure DevOps mientras que metodológicamente utilizamos metodologías Agile como Scrum y Kanban.
Consultoría para la implantación de un nuevo gestor de contenidos corporativo
Contexto
La Seguridad Social es el sistema de protección del Gobierno de España garantiza a los ciudadanos la subsistencia ante situaciones de necesidad.
Este sistema se divide en entidades gestoras, entidades colaboradoras, servicios comunes todos dependientes del Ministerio de Inclusión, Seguridad Social y Migraciones.
La gestión y administración de las tecnologías de la información y las comunicaciones en el sistema de Seguridad Social es responsabilidad de uno de sus servicios comunes, la Gerencia de Informática de la Seguridad Social (GISS)
Para el desarrollo de los diferentes sitios web de la Seguridad Social, tanto internos como externos, la GISS pone a disposición de las entidades gestoras y de ella misma de varios productos.
Utilizar diferentes soluciones y plataformas para su estrategia de canal online supone problemas en cuanto a la homogenización de estándares, reutilización de código y buenas prácticas, así como el incremento de costes asociado al mantenimiento de diferentes sistemas.
Retos
La Administración Pública tiene la obligación de ofrecer nuevos servicios digitales y mejorar los ya disponibles, en un continuo proceso de modernización todos sus sistemas.
La GISS necesita encontrar una plataforma única, flexible y escalable que le permita abordar el desarrollo de nuevos canales digitales y la evolución y mantenimiento de los actuales, tanto sitos webs como aplicaciones móviles.
La solución debe permitir mejorar los costes de licenciamiento y de servicios profesionales necesarios para el desarrollo y mantenimiento de los sistemas para poder optimizar los presupuestos disponibles, ajustar el “time-to-market” de los proyectos a las necesidades de las entidades gestoras que forman la Seguridad Social, cumplir con los requisitos de accesibilidad establecidos para los portales públicos, compatibilidad con la arquitectura corporativa…
La solución
ITERIAM lidera un equipo de consultoría para analizar la mejor herramienta que se adapte a los requisitos de la GISS en el entorno de gestión de contenidos.
Como parte del análisis realizado de las alternativas existentes en el mercado, se va a abordar el diseño, desarrollo e implantación de una serie de portales que sirvan como piloto para analizar en profundidad las capacidades del gestor de contenidos seleccionado.
Estos portales identificados como parte del piloto presentan varios casos de uso estándar de la organización, y junto a un trabajo de consultoría de implantación y despliegue de infraestructura, deberá dar como resultado si la herramienta puede convertirse en la solución corporativa en el entorno de la Seguridad Social para todo el canal online.
Después de las entrevistas con los equipos de Desarrollo y Producción de la GISS se toma la decisión de evaluar Liferay como solución corporativa de gestión de contenidos.
Resultados
Como primer resultado de la consultoría se presenta una arquitectura de la solución on-premise que pueda dar servicio en alta disponibilidad a los portales que se van a utilizar como piloto para la evaluación de la herramienta.
Abordamos los desarrollos de los portales ejemplo sobre la versión Liferay DXP 7.2.
Se desarrollan dos nuevos portales públicos informativos sobre propuesta de gráfica y de funcionalidades facilitada por la propia GISS; y por otra parte, se realiza una propuesta gráfica de las diferentes revistas digitales existentes (Activa, Mar, Portal de la Seguridad Social Digital) y se desarrolla un sitio web con componentes comunes para poder implementar ese tipo de sitios. En base a esa plataforma se implementa también al completo un sitio web interno incluyendo la migración de contenidos desde WordPress a Liferay.
Propuesta gráfica para la Revista de la Seguridad Social
Como desarrollo adicional, se realiza un piloto con los componentes disponibles de Liferay como suite de herramientas colaborativas para su evaluación por la dirección de la GISS.
Finalmente, y con el equipo de producción, se realiza una migración de la versión 7.2 a la última versión disponible del producto 7.3.
A parte de los proyectos desarrollados, se entrega un manual de buenas prácticas que permita a las entidades gestoras desarrollar y mantener proyectos con Liferay.
Tecnológicamente están involucrados en el proyecto:
Liferay DXP 7.2 y 7.3.
Integración con sistemas corporativos mediante servicios web
Desarrollo Continuo e Integración continua (CD/CI) con una infraestructura basada en Git, GitLab, Jenkins y SonarQube
Escalamos el equipo de desarrollo de canales digitales
Contexto
La contratación de talentos en el sector de las nuevas tecnologías es una de las tareas más complejas para una empresa.
En ITERIAM ayudamos a acelerar este proceso aumentando la capacidad interna de nuestros clientes con el mejor talento, trabajando de forma colaborativa para alcanzar resultados exitosos y de la manera más rentable.
Con más de 30 años de historia, RSI proporciona a través de pago por servicio soluciones bancarias a más de 15 entidades financieras de primer nivel, con más de 8 millones de clientes que realizan una media de 5.000 millones de transacciones al año.
RSI tiene la necesidad de ir gestionando la demanda de desarrollo de aplicaciones para sus clientes, y en particular, la solución de eBanking cobra vital importancia para la compañía para competir ofreciendo soluciones tanto web como app que ofrezcan una experiencia de usuario memorable, facilidad de uso y rapidez en todas las operaciones sin necesidad de desplazarse a una oficina.
Enfoque de la colaboración
ITERIAM monta una célula de desarrollo front-end dentro de nuestro Centro de Desarrollo Especializado, ofreciendo un servicio ágil, flexible y personalizado para RSI asumiendo la demanda cambiante de trabajo según las necesidades de las diferentes entidades financieras.
Los principales beneficios de esta colaboración son:
Sinergias. Proporcionamos talento cualificado que se adapta e integra rápidamente en la estructura operativa del cliente, compartiendo una cultura similar, aportando nuestra experiencia en otros ámbitos y hablando el mismo idioma.
Escalabilidad. Los equipos de TI del cliente pueden crecer rápidamente en su negocio sin el coste adicional de contratación, manteniendo el control de los equipos y de sus proyectos.
Control. RSI se mantiene enfocado en la gestión de su negocio y nosotros nos encargamos de proveer el talento adecuado con las habilidades técnicas y la experiencia que necesita en cada momento.
Flexibilidad. Existe la posibilidad de aumentar o disminuir el tamaño del equipo según las necesidades y la duración del proyecto.
Rentabilidad. Reducción de costes operativos y gastos directos de contratación. Nosotros proveemos talento con las habilidades necesarias que formaran parte del equipo el tiempo que cada proyecto lo demande.
En este caso particular el equipo de conforma con especialistas en desarrollo de soluciones web y aplicaciones móviles con VueJS.
Sanitas como empresa puntera en el ramo de salud con una cuota superior al 20% y referente en innovación en el sector evoluciona de forma continua su proyecto MiSanitas, canal de acceso para los asegurados a todos sus servicios digitales.
En 2021 el 12% de las consultas fueron digitales hasta alcanzar 782.000, con picos que superan las 4.200 diarias. Y todas esas consultas se realizan a través de MiSanitas.
Los asegurados tienen la posibilidad de realizar de forma sencilla y desde un punto único todas sus gestiones:
Pedir citas médicas, gestionarlas, reprogramarlas y cancelarlas
Buscar médicos, hospitales, centros médicos o clínicas dentales
Encontrar el centro de urgencia y especialista más cercano
Consultar el histórico de visitas al médico y las citas pendientes
Guardar médicos favoritos
Consultar informes médicos, analíticas, radiografías, etc.
Subir informes de otros centros para tener toda la información de salud en un solo lugar
Acceder a la tarjeta de salud digital (y de los hijos)
Hacer gestiones de la póliza, como solicitar reembolsos y autorizaciones
Ver los recibos y copagos en tiempo real
Consultar, modificar y personalizar el perfil de cada beneficiario
Cambiar la cuenta bancaria y periodicidad
Acceder a la biblioteca de consejos de salud
Escalamos los equipos de desarrollo
ITERIAM lleva cuatro años participando en este proyecto escalando el equipo del área de Digital de Sanitas mediante la conformación de squads ágiles siguiendo metodologías como Lean Startup o Scrum. Aportamos diferentes perfiles técnicos (product owners, scrum masters, líderes técnicos, UX, desarrolladores front-end, desarrolladores back-end, testers, maquetadores, etc.) y adecuamos la gestión de la demanda con un trato cercano, transparente y comprometido para cumplir con los objetivos de negocio.
La solución técnica se implementa tanto para web como app, realizando integraciones con todos los servicios digitales de la aseguradora mediante una arquitectura de microservicios y ofreciendo una magnífica experiencia de usuario al cliente.
IKEA es probablemente la tienda de muebles más conocida a nivel mundial.
Desde el punto de tecnologías de información, al igual que otras grandes multinacionales, existen tanto sistemas corporativos como soluciones locales a cada país que posteriormente tendrán que consolidar información con los primeros.
IKEA Ibérica disponía de un parque de aplicaciones de escritorio que daban servicios de contabilidad, facturación e impuestos de forma local e independiente de los sistemas corporativos del grupo. Como directriz corporativa, se debía adaptar tecnológicamente ese conjunto de aplicaciones – denominadas internamente como “Service Office” – adecuando la solución tecnológica a los requisitos establecidos por la organización.
Los retos
Como bien sabemos en ITERIAM, la actualización tecnológica de un sistema no solo depende de la tecnología y es muy importante la metodología de trabajo en un proyecto de migración de entornos obsoletos a entornos actualizados.
En muchos casos no existe documentación suficiente y el conocimiento de los aplicativos se encuentra en las personas.
Adicionalmente, en este caso se añadía la complejidad del tiempo, ya que las nuevas aplicaciones deberían estar listas para el inicio del año fiscal, 1 de enero de 2019.
La solución
Aunque inicialmente el proyecto debía ser una actualización tecnológica, desde ITERIAM se planteó un proyecto más ambicioso que incluyese también una redefinición funcional de todas esas aplicaciones aprovechando las ventajas que nos ofrecerían las nuevas tecnologías.
Para llevar a cabo una modernización exitosa de estas aplicaciones debíamos hacer un acercamiento mixto. Por un lado, colaborar activamente con los responsables de las aplicaciones para conocer todo el alcance funcional, recoger los nuevos requisitos y definir correctamente todas las integraciones entre ellas y con los sistemas corporativos. Por otro lado, analizar en profundidad el código fuente de las aplicaciones mediante el uso de herramientas.
Con este acercamiento podemos tener un conocimiento completo de las aplicaciones.
A partir de aquí, y para cumplir el exigente “time-to-market” trazado por el cliente, organizamos varios equipos ágiles de desarrollo, uno por cada aplicación. El equipo técnico iba balanceando entre aplicaciones para compartir experiencias, reutilizar recursos y cumplir la planificación establecida.
Tecnológicamente, las aplicaciones se migran a un desarrollo web con tecnologías .NET, utilizando Entity Framework, Linq, tratamiento de ficheros planos, XML e importación de ETL, diseño de consultas y procedimientos almacenados en SQLServer y Oracle. Toda la solución está soportada sobre Azure.
Los resultados
En un periodo aproximado de 5 meses, se aborda una modernización de aplicaciones de escritorio obsoletas hasta aplicaciones web basadas en arquitecturas de última generación alineadas con los requisitos corporativos de IKEA.
La involucración de los usuarios desde el primer momento del proyecto permite dar valor a las inversiones pasadas y aumenta la motivación de todas las partes para conseguir los objetivos del proyecto: se consigue formar a los usuarios y desplegar las aplicaciones durante un complicado mes de diciembre, que están operativas desde el 1 de enero de 2019 hasta el día de hoy.
Un proyecto de este tipo ejecutado por personal técnico cualificado permite la reutilización real de código, mejora de la mantenibilidad de las aplicaciones y otros aspectos como la accesibilidad, usabilidad, simplicidad y seguridad de las nuevas aplicaciones.
Desde entonces ITERIAM ofrece a IKEA un servicio de mantenimiento correctivo y evolutivo de estas aplicaciones.
Normalmente cuando queremos empezar el desarrollo de una aplicación, solemos pensar en el lenguaje de programación que vamos a usar tanto en la parte de front-end como en la parte de back-end. Una vez elegidos, continuamos pensando en la arquitectura que van a tener ambas partes.
Centrándonos en la parte de front, además de pensar en la arquitectura del lenguaje de programación elegido, tendremos que plantearnos la arquitectura de nuestro código CSS y que nos va a permitir agilizar todo el desarrollo.
Eso sí, no hay que confundir arquitectura con metodología en CSS. Mientras que la arquitectura se va a encargar de organizar las carpetas del proyecto, la metodología se va a encargar de especificar en cómo se va a nombrar las clases.
Teniendo claro esto, he indagado en las diferentes arquitecturas CSS que existen y de las cuales he seleccionado dos para analizar en este artículo: la arquitectura SMACSS y la arquitectura ITCSS. Estas dos arquitecturas se centran en organizar el CSS dependiendo de su función en una categoría o capa.
Arquitectura SMACSS
SMACSS (Scalabre and Modilar Architecture for CSS) nos va a permitir que el código CSS que desarrollemos sea escalable y modular como indica su «imaginativo» nombre. Para conseguirlo, empezamos observando los patrones que caracteriza a cada una de las categorías. Esto se hace, ya que cuando comencemos el desarrollo, sepamos en que categoría agruparlo. Las categorías son las siguientes:
Base
Son aquellos estilos que aplican directamente a los propios elementos HTML y que vamos a usar para establecer los estilos por defecto en nuestra aplicación. También se incluyen aquellos estilos que nos van a permitir eliminar o restablecer las bases a aplicar en todos los navegadores. Esto último hay que planteárselo bien, ya que, si se va a restablecer de nuevo algún valor por defecto en los elementos reseteados, no tiene sentido que se restablezca en primer lugar.
Layout
Son aquellos estilos que tienen por objecto aplicarse sobre los componentes de estructura de nuestra aplicación. Por ejemplo, el header o el footer. Para aplicarle los estilos, se hace mediante el uso del selector ID. Sin embargo, hay veces en que el layout tiene que adaptarse a las preferencias del usuario, para ello se usará una clase con el prefijo ‘l-’. Para el caso de los IDs, se nombran con precisión y sin usar un espacio en la nomenclatura. Esto ayuda a identificar fácilmente la categoría de estos estilos y a separarlos de las categorías module y state.
Module
Son aquellos estilos que aplican sobre los diferentes componentes de nuestra aplicación. Por ejemplo, la barra de navegación y el carrusel de imágenes. Estos se ubican normalmente dentro de los componentes layout aunque también pueden ubicarse dentro de otros componentes module. Para garantizar la flexibilidad, los componentes modules deben de estar diseñados para existir como componentes independientes. Para aplicarles los estilos, se hace mediante nombres de clase y hay que evitar usar IDs y selectores de elementos.
State
Son aquellos estilos que modifican los estilos de un componente cuando se da una condición. Por ejemplo, una sección de un acordeón puede estar oculta o desplegada. Hay bastantes similitudes entre un estilo aplicado a un sub-module y a un state. Ambos modifican el aspecto de un componente, pero se diferencia en lo siguiente:
Las reglas de state se pueden aplicar tanto a las reglas layout como a las reglas module.
Las reglas de state indican una dependencia con Javascript.
Las reglas de state se aplican mediante el uso de las clases. También está permitido el uso del ‘!important’, pero sólo cuando sea estrictamente necesario y evitando usarse para todas las demás reglas.
Theme
Son aquellos estilos que definen los colores y las imágenes que le dan su apariencia a nuestra aplicación. Se debe separar cada tema en su propio conjunto de estilos. Esta categoría puede afectar a las demás y se aplica mediante el uso de clases. Debe tener un nombre que especifique el tema que es y se recomienda tener un archivo por cada tema.
Arquitectura ITCSS
ITCSS (Inverted Triangle architecture for CSS) es una arquitectura CSS que nos va a permitir que el código CSS que desarrollemos sea escalable y manejable. Esto se consigue mediante la organización de los ficheros CSS de tal manera que nos permita manejar la especificidad de estos. Según su especificidad, se separa el código CSS en varias capas que se pueden representar como las secciones de un triángulo invertido. Estas capas son las siguientes:
Settings
Se utiliza con preprocesadores y es donde colocaremos el código de declaración de variables. Por ejemplo, las fuentes y las definiciones de colores.
Tools
Se utiliza con preprocesadores y es donde colocaremos los mixins y las funciones de uso global. En esta capa y en la anterior es importante no generar ningún código CSS.
Generic
Se utiliza para reiniciar y/o normalizar los estilos de los elementos HTML de nuestra aplicación. A partir de esta capa, empezaremos a generar código CSS.
Elements
Se utiliza para establecer los estilos de los elementos HTML de nuestra aplicación. A diferencia de la anterior capa, esta no tiene por objecto convertir los elementos HTML en lienzos en blanco, sino busca darle los valores por defecto a los mismos elementos HTML orientándolo a la propia aplicación.
Objects
Se utiliza para establecer los estilos de los componentes de estructura de nuestra aplicación. Por ejemplo, el header, el grid, el container y el wrap. La capa objects se aplica mediante el uso de las clases con el prefijo ‘o-’.
Components
Se utiliza para establecer los estilos de los componentes de la interfaz de usuario. Por ejemplo, la barra de búsqueda o el botón de una red social. La capa components se aplica mediante el uso de las clases con el prefijo ‘c-’.
Utilities
Se utiliza para sobrescribir o anular los estilos establecidos anteriormente en las demás capas. Es la única capa en la que está permitido el uso del ‘!important’. La capa utilities se aplica mediante el uso de las clases con el prefijo ‘u-’.
Corría el año 1895 cuando unos hermanos apellidados Lumiere desataron un fenómeno mundial que revolucionó la forma de ver la vida y de llevar mensajes a cualquier parte. Cuando hablamos de “video” englobamos todas las artes en que se transforma (cine, televisión, series, etc.) y una enorme lista de recursos en las que por medio de imágenes a gran velocidad conseguimos transmitir un mensaje.
En los últimos años el video ha evolucionado de tal forma que actualmente. Según el CISCO el 80% del trafico de la red es video. Puede resultar un dato impresionante pero si te digo nombro a Netflix, Zoom, Youtube, Tiktok, Facebook, PrimeVideo… ya entiendes que el video es el recurso preferido para comunicarse en el medio preferido por los usuarios: internet.
En este artículo vamos a hablar del video y de la importancia de saber configurarlo correctamente en tu proyecto web. Verás que hay muchas cosas que no sabías y estabas pasándolas por alto. Conocer bien el producto te hará tratarlo con más confianza.
Primeros pasos, lo más importantes
Como no podía ser de otra manera el primer paso es que pienses detenidamente en el destino del video que vas a usar. Es evidente que cada video es un mundo y por tanto cada video, o listado de videos tienes que estudiarlos. El resultado es que en producción ver estos vídeos sea un paseo en barca donde disfrutas de su contenido. Pero sabemos que en ocasiones no es así y esta mala planificación provoca que el usuario no obtenga una buena experiencia en tu sitio web.
A continuación veremos los aspectos más importantes a tener en cuenta a la hora de planificar un proyecto web que incluya vídeos.
Poster
Cuando ponemos un vídeo en una web no siempre queremos que se reproduzca.
Hay videos cortos que se reproducen en bucle y asumen un papel de background, pero si se trata de un video que quieres que se vea porque su contenido es importante has de configurarle un poster . Se trata de esta etiqueta:
Obtenemos dos ventajas al establecerse como un poster:
La pantalla de portada será más atractiva. Probablemente tu video tenga el primer frame en negro, así que si no configuras un poster, tu cuadro de video será una pantalla negra vacía.
Este poster carga al instante y puede que el vídeo, si es muy pesado, tarde un poco en cargar. Conseguimos enmascarar esa carga en segundo plano. Si tienes muchos vídeos en una misma URL que cargan a la vez es un proceso lento así que puedes hacer que cargue al reproducirlo. Esto lo conseguimos con la etiqueta preload:
Está de más decir que el poster ha de tener las mismas dimensiones en px que el video y una resolución de 72ppx. Y por supuesto ha de ser atractivo si quieres que vean el video.
Resoluciones
La palabra resolución, cuando hablamos de video, sufre un mal uso constante. La resolución de un video no es mas que la cantidad de píxeles de alto por ancho. No podemos llamar resolución a .H264 o a 16:9. Por tanto, aclarado lo que es la resolución, veamos cuales son los estándares más usados:
FHD, 1920x1080px. La más usada, aunque el 4k empieza a comer terreno.
HD, 1280x720px. Era la más usada pero la desbancó en poco tiempo FHD.
4k, 3840 x 2160px. Aún en crecimiento porque precisa una gran tasa de datos y una pantalla con mucha densidad de pixeles.
La resolución es junto con el formato quien marcará el peso del vídeo por segundo.
Aquí es donde hemos de tener un gran tacto pues un video muy pesado puede afectar gravemente la usabilidad de la web. En este caso y al igual que pasará con la relación de aspecto, necesitamos una resolución diferente para cada dispositivo. Pero cuidado en este tema porque las pantallas están cambiando y cada vez tienen mayor densidad de píxeles. Por ejemplo, una pantalla de un desktop estándar podríamos decir que está en FHD. ¿Y una pantalla mobile? Pues aquí se ha desatado la locura y por ejemplo IPhone12 tiene 2340×1080 así que menos de FHD sería un error.
Lo aconsejable es hacer un desarrollo donde detectemos la resolución en ancho de la pantalla y en función de eso carguemos los vídeos con las resoluciones óptimas a ese dispositivo. Un código similar a este sería lo aconsejable:
Este código detecta el ancho de la pantalla del dispositivo, no la ventana del navegador. Para que funcione el código simplemente has de tener tu video en diferentes resoluciones y con un nombre igual para todos pero con la matiz de la resolución: _HD, _FHD o _4K.
Formatos
Este es uno de los temas más conflictivos a la hora de cargar un vídeo. Con el resto de ajustes el video se verá mejor o peor, tardará más en cargar o menos, pero por el formato del vídeo puede pasar que se vea o no el video dependiendo del dispositivo o navegador que uses. El formato hace referencia únicamente al tipo de archivo que exportamos.
Del formato podemos diferenciar la extensión y el códec. La extensión es el paquete que engloba ese formato (.mov, .mp4, .avi, etc.) y el códec es el leguaje de compresión que se usa para hacer que el video pese menos (MPEG2, H264, WebM, etc.).
En este caso la etiqueta video cuenta con una sub-etiqueta source y en su atributo src se puede colocar el formato de video. Así para una etiqueta de video, tenemos varios src y cada uno aporta el video en diferente formato.
<video>
<source src="movie.webm" type="video/webm;"/>
<source src="movie.mp4" type="video/mp4;" />
<source src="movie.ogv" type="video/ogg; " />
<video>
Relaciones de aspecto
La relación de aspecto es la relación proporcional entre el ancho y el alto del frame. En esencia, es la forma del video. Hay multitud de estándares para configurar esta relación de aspecto entre los que vamos a destacar los más usados:
16:9. Se trata del estándar más usado actualmente tanto en web como en dispositivos. Su resolución más usada sería FHD 1920x1080px.
4:3. Es una relación que está perdiendo popularidad pues nos ofrece un frame muy cuadrado y el vídeo se aprecia más atractivo en formatos panorámicos. Su resolución mas usada sería 1280x960px, aunque el origen de esta relación proviene del sistema PAL que todos hemos tenido en casa, 720x576px.
Aunque lo normal es usar un estándar hay ocasiones en que el proyecto precisa unas relaciones de aspecto diferentes en cada dispositivo. Por ejemplo un banner en desktop con un video de fondo puede tener una relación de aspecto muy panorámica. Sin embargo en mobile su relación de aspecto será cuadrada o vertical. Aquí es donde entra en juego CSS y sus ajustes para background.
Veamos el siguiente ejemplo:
En este caso el video de fondo lo hemos configurado con la posición absoluta y en cada dispositivo jugamos con top, bottom, right, left y márgenes automáticos. En ocasiones hay que tener videos demasiado versátiles para que la perdida de información que se da de un dispositivo a otro sea asumible.
Reproductor
Por último veamos el modo en que queremos que el usuario interactúe con el video que le presentamos. Como hemos hablado anteriormente, si el video es un background, no tiene sentido que tenga botones, y si no quieres que salgan corriendo de tu página, tampoco debería tener sonido. Por eso vamos a hablar de los vídeos con los que el usuario debe interactuar. La etiqueta video nos ofrece estos atributos:
Autoplay: Booleano para que el video se reproduzca automáticamente tras cargarse.
Controls: Booleano para mostrar o no el panel de control del video de tu explorador.
Muted: Booleano para iniciar el vídeo sin sonido.
Loop: Booleano para indicar la reproducción en bucle del vídeo.
Hay casos en los que hay que desarrollar un estilo personalizado de reproductor. Para ello basta con no poner el atributo controls y configurarlos tu mismo con js y css. Os muestro un pequeño ejemplo:
El vídeo es un elemento complejo al que prestar mucha atención porque configurarlo bien nos devolverá una experiencia positiva de nuestro desarrollo.
Por supuesto hay muchos temas que no hemos hablado en este video relativos al video como los fps (fotogramas por segundo), la tasa de bits de video o los campos (i o p), pero quizás esos temas sean parte del diseño del propio video y no de la implementación.
Para terminar me gustaría dejar ese fragmento del que empecé hablando porque como dicen es importante saber de dónde vienes para saber quién eres:
Svelte (o SvelteJS) es un framework para desarrollar aplicaciones JavaScript por Rich Harris y basado en componentes para crear aplicaciones reactivas.
A diferencia de otros frameworks como Angular, Vue o React, el código es compilado previamente para que el navegador pueda entenderlo.
Si visitamos la web principal de Svelte podemos desatacar sus tres características principales:
Write Less Code. Una de las principales características es que podemos crear componentes con menos líneas de código, que por ejemplo React, donde su creador asegura que si comparamos componentes iguales, estamos ahorrando hasta un 40% de código. Svelte utiliza el principio de Single File Component en el cual, en un mismo archivo tendremos el HTML, Javascript y Css. Esto te puede resultar familiar si has utilizado Vue.
No virtual DOM. Lo más interesante de Svelte es, que como hemos comentado, es precompilado. No hace uso del Virtual DOM para realizar cambios en nuestra aplicación, sino que se aprovecha de la previa compilación para realizar los cambios de estados y propiedades.
Truly reactive. La programación reactiva es la base de cualquier framework de javascript, donde simplemente es que la interfaz del usuario va cambiando según se vayan modificando los datos de éste.
Vamos a ver paso a paso cómo empezar con un proyecto utilizando Svelte 3.
Instalación
Vamos a ver como crear un proyecto sencillo en Svelte y para ello, seguiremos los pasos que nos indican en la web oficial.
Arrancamos una terminal y ejecutamos el siguiente comando:
npx degit sveltejs/template proyecto-svelte
Con este comando lo que estamos haciendo es hacer una copia del repositorio de Github de sveltejs, pero sin la carpeta .git.
El siguiente paso será situarnos dentro de nuestro proyecto: cd proyecto-svelte y hacer un: npm install para instalar las dependencias del proyecto.
Una vez instaladas todas las dependencias podemos ver los distintos ficheros que nos ha creado.
Estructura del proyecto
Si abrimos nuestro proyecto con un editor, nos encontraremos con la siguiente estructura:
Uno de los ficheros a destacar es rollup.config.js, el cual es una herramienta que lo que hace es compilar todo nuestro código en un solo fichero, más grande y complejo (lo que se llama Bundle) como puede ser Webpack o Parcel.
Seguimos analizando nuestro proyecto y vemos el fichero package.json. Como podemos ver, tiene una configuración bastante sencilla con pocas dependencias y los diferentes scripts que podemos ejecutar:
Creación de una sencilla aplicación:
Vamos a crear una pequeña aplicación para ver alguna de las características más importantes de este framework:
Empezamos analizando el fichero main.js, el cual es el fichero de entrada de nuestra aplicación. En él, estamos creado una prop que pasaremos a nuestro componente App.svelte.
En el siguiente ejemplo crearemos un pequeño componente donde habrá un contador y en el que veremos algunas de las características de este framework:
Lo primero que haremos es exportar la prop ‘name’, donde estamos indicando que es un parámetro del componente. Después crearemos una propiedad llamada contador, y un botón el cual llamará a una función para que cada vez que se haga click en él, el contador se incremente. En este botón hemos añadido la directiva on:click, que será el evento que se lance cada vez que pulsemos sobre él.
Aquí lo interesante que tiene Svelte, es que como tiene un paso previo de compilación, está deduciendo que la variable ‘contador’ es un estado, y cada vez que el valor cambie, vuelve a renderizar el componente.
En la siguiente imagen vemos como traduce Svelte nuestro código:
Arrancar el proyecto
Arrancaremos nuestro proyecto y lo ejecutaremos en modo ‘dev’. Para ello ejecutamos el comando: npm run dev y se nos indicará una dirección localhost con el puerto 5000, el cual no llevará a nuestro entorno de desarrollo.
Así se vería nuestro proyecto en el navegador:
Conclusión
Hasta aquí hemos podido ver como configurar nuestro entorno para trabajar con Svelte y algunas de las ventajas que tiene como son la simplicidad de su código, reactividad y que tiene una curva de aprendizaje muy baja.
Podemos ver ejemplos concretos en su misma página, analizarlos y comprobar la potencia que puede llegar a darnos este framework en el desarrollo de nuevas aplicaciones.
Me encanta que los planes (de usabilidad) salgan bien
Cuando nos enfrentamos a cualquier proyecto podemos hacerlo de muchas formas, pero el resultado siempre queremos que sea satisfactorio.
Muchas generaciones recordamos la famosa frase de John Hannibal Smith de la serie “El equipo A” que titula este artículo. Podría haber usado otras series míticas como MacGyver como hilo conductor, pero necesitaba algo más potente. Me tentó también Michael Knight que encajaba bien como ejemplo de tecnología, pero improvisaba mucho.
Por eso el equipo A para lo que os quiero contar me pareció perfecto. ¿Os imagináis a Hannibal sin pensar una forma imaginativa para resolver las aventuras de cada episodio? ¿Sin definir un plan con sus compañeros de equipo? ¿Sin apoyarse en su experiencia previa como miembro de los cuerpos de élite del ejército?
Cuando abordamos un proyecto de usabilidad y experiencia de usuario cometemos errores básicos y simples, producto casi siempre de una insuficiente planificación y de repetir lo que vemos en otros proyectos. Planear bien las cosas tiene un montón de ventajas como evitar el retrabajo, acortar los tiempos de ejecución, asegurar la calidad del resultado, etc.
Os facilito en este artículo algunos ejemplos de buenas prácticas y recomendaciones, para que veáis que con poco que le deis al coco… ¡los planes siempre salen bien!
Mobile First, tatúatelo
Mobile First ha dejado de ser una tendencia y actualmente es un patrón obligatorio para diseñar un proyecto web.
Haz como MA Barracus y tatúatelo. El modo en que los usuarios actuales asumen ver los contenidos está basado en experiencias móviles. Estas experiencias se basan en pantallas sencillas con scroll vertical.
La mayoría de los proyectos ya son responsive, pero no podemos confundir ese término con Mobile First.
Hay un gran error de usabilidad que se sigue cometiendo y es el contenido en las pantallas. Se sigue haciendo contenido para pantalla de escritorio y se desarrollan responsive. El resultado será un sitio web que se verá bien en otros dispositivos, pero tendrá un exceso de contenido en una única pantalla y elementos poco accesibles para operar con una mano.
Por ello hay que recalcar que Mobile First denota también que las pantallas han de ser sencillas, concisas y fáciles de usar desde cualquier dispositivo.
El Header, nuestro vehículo en una web
¿Qué pensaríais si la furgoneta del equipo A se pareciese a ésta?
Es importante hacer un buen estudio del Header ya que es el primer elemento que tocar y se repite en todo el sitio web que estéis diseñando.
Hay varios errores que se repiten y son tan fáciles de corregir con el objetivo de simplificar tus propuestas y centrarte en lo esencial. Estos son algunos de los consejos para crear un Header que funcione:
Entre 5 y 10 items en el header. Muchos botones restan.
Que su altura no sea mayor de 150px. El header es importante, pero se va a repetir en toda la website y por lo tanto ha de ser ligero.
Que contrasten el fondo con las letras y si tu menú permanecerá fijado en la parte superior de la ventana, que contraste muy bien en todo el scroll vertical.
Ordenar por importancia los ítems en el header. No sigas tendencias, si lo importante son tus productos, no pongas en primer lugar “Mi compañía”. O si prevés que la búsqueda será el fuerte del sitio, no la dejes escondida al final con un icono de lupa.
El uso excesivo de iconos en el Nav resta. Más de 4 items con iconos es uso excesivo que despista al usuario.
La distribución más usada y que me mejor funciona es logo izquierda y Nav derecha. Centrar el logo y poner el nav partido o en una segunda fila hace que el header sea excesivamente alto.
Cuidado con los navs desplegables que no dejan de desplegar. Trabaja mucho las categorías que mostrar ya que en mobile es incómodo un Nav que sobrepasa en largo la pantalla.
Espacio libre, ¿un lujo?
Sigo utilizando ejemplos gráficos para avanzar en mis recomendaciones. ¿Te imaginas al Equipo A con un R5 en vez de la furgoneta molona que usaban?
¿Como viajar con todo el equipo a las diferentes misiones? ¿Como disparar esas metralletas?
El espacio, ya sea en un sitio web, en una misión del equipo A o en tu vida, es muy importante. El espacio libre es eso que una persona usa, sin ser consciente, para sentirse a gusto en dicho espacio.
Para que una web sea cómoda y se use a gusto ha de tener mucho espacio libre y estas son algunas de las pautas a seguir:
Planifica muy muy, pero que muy bien tus secciones y el contenido de cada una. Lo adecuado es que una sección no supere el tamaño de una pantalla (excluimos los listados de este consejo).
Si usas fondos o imágenes a sangre, es decir, full-width, no uses el texto en esa configuración.
Deja márgenes amplios entre secciones o contenido. Si lo empastas todo te pasa como con la plastilina, el resultado es una masa marrón.
No abuses del color, el video o la imagen. El blanco da paz y nunca falla.
Anuncios, banners, ventanas modales, políticas de cookies… ¡Que locuraaaa!
Se ha podido demostrar que el “Loco Murdock” no era un personaje ficticio si no que sus trastornos estaban causados por consumir sitios web como el que veis en la siguiente imagen:
Cuando hablamos de obtener una buena experiencia en el uso de una plataforma el tema de las promociones y publicidad pueden tirar por tierra todo lo que hayas trabajado en el Header, en el contenido o en la navegación.
El uso muy moderado de estos recursos de publicidad – bien propia o ajena – resta a tu diseño, pero si te dejan llegar a tu destino debes pensar en si te interesa el impacto que provocan. El uso desmesurado de dichos recursos no es que resten, te anulan. Hacen inservible tu sitio web.
Otros dos factores para destacar que salen de esa publicidad son los logins o suscripciones y las políticas de cookies. El login siempre ha de estar accesible pero no debes atosigar al usuario para que se registre: deja que te conozca y sugiérelo sutilmente. Haz lo mismo con la newsletter.
En cuanto a las políticas de cookies, todos nos hemos subido a ese tren, pero que esa legislación no nos impida ver tu página. No llenes toda la página con ese mensaje porque puedes conseguir que ya no la quieran ver. Un mensaje discreto es lo que mejor funciona.
Botones de redes sociales
Un error muy simple se da cuando alguien decide presumir de sus redes en su página web. Los hay que te las ponen en el Nav y que merecen ser castigados. Otros en el Footer, tienen mi clemencia. Y otros, almas cándidas, por todas partes. Pues compañeros, mal plan.
El sentido de esos botones es que conozcas esas redes, pero vamos a poner a funcionar nuestra materia gris: ¿dónde está expuesto el grueso de nuestro negocio? ¿en las redes sociales? ¿en el sitio web? Debería estar en el sitio web mientras que las redes sociales son canales que usas para que la gente llegue a dicho sitio web.
Os voy a poner un ejemplo. Entráis a una tienda a comprar y delante de cada producto hay otras tres puertas: una puerta que te lleva a la empresa que hace la publicidad de la tienda, otra que te remite a un cartel de la carretera y la otra de nuevo te lleva al escaparate. ¿No tiene sentido verdad? Lo suyo es que ese escaparate, esa publicidad y ese cartel sean los que te llevan a la tienda a consumir tus productos.
Pues en muchos sitios web se ha instaurado esa tendencia y es un gran error. Si al entrar lo primero que ves son las redes sociales estás invitando al usuario a que lo primero que haga es salir de tu página e irse a una red social, donde sí, estás tú, pero también otros cuantos millones de empresas como tú.
Cabe destacar que no podemos confundir el botón de redes sociales del Nav o Footer con los botones en blogs que sirven para compartir dicho post dentro de una red social. Estos si tienen un gran sentido ayudando al SEO de dicha empresa.
El mal uso de los botones que te llevan a redes sociales es algo muy instaurado y es un mal hábito para la usabilidad de cualquier proyecto. Si te hago salir justo cuando entras… ¡no creo que los planes salgan bien!
