¿Qué es UX Writing y cómo impacta positivamente en el producto de una empresa? ¡Vea buenas prácticas, responsabilidades, metodologías y mucho más! UX Writing implica crear contenidos de valor en interfaces y productos digitales, incluyendo textos, basados ​​en la experiencia del usuario, es decir, buscando entregar la mejor experiencia al público. Esta práctica está relacionada con conceptos de marketing, diseño y arquitectura de la información, y tiene como objetivo deleitar y ofrecer valor a través de piezas informativas. Un ejemplo de UX Writing es cuando accedes a una plataforma de enseñanza online, o a una aplicación que al iniciar sesión te demuestra con un tutorial objetivo cada paso que debe realizar el usuario. A continuación se muestra un ejemplo de la aplicación ProJuris ADV. Softplan, que muestra una interfaz limpia y amigable antes de que el usuario decida si crear una cuenta en la aplicación o iniciar sesión, mostrando algunas cosas que se pueden realizar en la aplicación. La experiencia del usuario se ha vuelto cada vez más importante para atraer, convertir y retener clientes. Aspectos como la agilidad de la navegación de tu sitio web, la escaneabilidad y la forma intuitiva de navegar, e incluso los colores elegidos para el diseño de las páginas afectan directamente a las decisiones de los usuarios en cualquier plataforma digital. Cuando hablamos de plataformas digitales con UX Writing, podemos ver como ejemplo a Gestor Obras, que en la primera página del sistema muestra un tutorial práctico de su funcionamiento. Al hacer clic donde está la indicación, le mostrará los siguientes pasos y funciones de cada parte del sistema. Otro ejemplo de UX Writing, que transmite información directa y objetiva, está en Sienge, mostrando en una imagen algunas ventajas de utilizar el sistema, además de una comunicación directa en el CTA “Solicita una Demostración”, alejándose del común “Conoce Más” y llamando a una acción muy objetiva. Por tanto, si tu empresa aún no está optimizando constantemente sus canales de comunicación con los usuarios, especialmente su sitio web, es momento de revisar algunas opciones. Después de todo, el usuario es quien utiliza tu producto o servicio. Para lograrlo, no sólo es crucial el diseño del sitio web a la hora de optimizarlo, sino que también una atención al cliente clara y objetiva y una comunicación en los canales de la marca serán fundamentales para crear una mayor conexión con sus consumidores. Para tener una idea de la experiencia de usuario y cómo se va agregando, este año se realizó una encuesta por Foundever, que reveló que el 80% de los clientes considera la experiencia como un aspecto mucho más valioso que los productos y servicios en sí. Cuando se ejecuta de manera eficiente, la práctica de UX Writing se convierte en una ventaja competitiva significativa en un mercado cada vez más riguroso en términos de calidad y de usuarios que demandan los mejores productos digitales. ¿Cuáles son las principales características del UX Writing? El UX Writing consta de algunas características importantes para que pueda ejecutarse de forma correcta y consistente. Es importante tener esto en cuenta para lograr mejores creaciones que realmente impactarán positivamente en la experiencia del usuario. Claridad y Objetividad: el contenido debe ser claro y directo, facilitando una rápida comprensión por parte del usuario. Coherencia: el lenguaje y el tono deben ser consistentes en todos los puntos de contacto del usuario, creando una experiencia cohesiva. Empatía: comprender y anticipar las necesidades y expectativas de los usuarios para crear textos que realmente les ayuden. Centrarse en la acción: orientar a los usuarios sobre qué hacer a continuación mediante llamadas a la acción (CTA) claras. Brevedad: utilizar la menor cantidad de palabras posible sin sacrificar la claridad, respetando el tiempo y la atención de los usuarios. Escaneabilidad: estructurar el texto de manera que sea fácil de leer y hojear rápidamente, utilizando títulos, subtítulos, listas y párrafos cortos. Accesibilidad: garantizar que los contenidos sean accesibles a todos los usuarios, incluidos aquellos con algún tipo de discapacidad, mediante un lenguaje sencillo e inclusivo. Orientación Visual: Integrar el texto de forma armoniosa con los elementos visuales de la interfaz, contribuyendo a una experiencia de usuario agradable e intuitiva. Personalización: adaptar el contenido al contexto y preferencias del usuario, ofreciendo una experiencia más relevante y personalizada. Tono y Voz de Marca: reflejar la personalidad y valores de la marca en todos los textos, fortaleciendo la identidad y la conexión con el público. Ejemplos de aplicación de UX Writing Es fácil confundir UX Writing con otras estrategias de escritura. Por ello, demostraremos cómo aplicar UX Writing a tu sitio web o aplicaciones digitales. Personalización ¿Quieres ver un ejemplo de UX Writing con personalización? Spotify es un servicio de streaming que, a medida que lo utilizas, va personalizando canciones que acaban siendo recomendadas a los usuarios, con canciones similares a las que el usuario suele escuchar. Además, al final de cada año, la plataforma ofrece a cada usuario un resumen anual de lo más escuchado a lo largo del periodo, así como qué artistas, podcasts y géneros fueron escuchados. Todo esto se hace en un lenguaje objetivo y claro para que el usuario pueda comprender exactamente todo el resumen, sin lugar a dudas. Foto: Reproducción/Spotify Textos objetivos y claros Ahora bien, para una aplicación, por ejemplo, es imprescindible que los textos sean muy objetivos! Por lo tanto, los índices de error del usuario a la hora de utilizarlo serán seguramente mucho menores, además de que la navegación será más intuitiva. Buen y mal ejemplo de un botón de acción con UX Writing aplicado. Fuente: Adobe Anticipar errores Ya hemos hablado de la importancia de dar una buena experiencia al usuario, y esto incluye anticiparse a cualquier posibilidad de errores futuros. En el siguiente ejemplo, podemos ver un formulario siendo llenado, donde la dirección de correo electrónico no está rellenada correctamente y la aplicación le indica al usuario que vea el mensaje, al lado del campo rellenado con error, en el lado izquierdo. Fuente: Adobe Diferencias entre copywriting, UX Writing y Tech Writing Aunque están relacionadas, las estrategias de copywriting, UX Writing y Tech Writing tienen sus diferencias. ¿Veamos cuáles son los principales dentro de algunos enfoques? Objetivo del copywriting: El objetivo es persuadir al lector a realizar una acción específica, como comprar un producto, suscribirse a un boletín informativo o hacer clic en un enlace. Por lo tanto, se centra en las conversiones y las ventas. UX Writing: facilita la interacción del usuario con un producto o servicio digital, haciendo la experiencia más intuitiva, placentera y eficiente. Con UX Writing, el usuario es guiado a través de la interfaz y en la realización de tareas. Redacción técnica: el objetivo es explicar de forma clara y precisa cómo utilizar productos o tecnologías complejos. Centrado en proporcionar instrucciones detalladas e informativas. Enfoque de redacción publicitaria: utiliza técnicas de persuasión y retórica para captar la atención del lector y motivarlo a realizar alguna acción. El tono es más emotivo y atractivo. UX Writing: adopta un enfoque funcional e informativo, priorizando la claridad, la simplicidad y la utilidad. El tono es objetivo, centrado en guiar y ayudar al usuario. Redacción técnica: se centra en el detalle y la precisión, proporcionando instrucciones paso a paso y explicaciones técnicas. El tono es técnico e informativo, con un lenguaje claro y objetivo. Ubicación de la aplicación de redacción publicitaria: se encuentra en materiales de marketing como anuncios, correos electrónicos promocionales, páginas de ventas, publicaciones de blogs y contenido de redes sociales. UX Writing: presente en interfaces digitales, como aplicaciones, sitios web, e-commerce, dashboards y cualquier punto de interacción del usuario con el sistema. Los ejemplos incluyen botones, mensajes de error, instrucciones y menús de navegación. Redacción técnica: aparece en manuales de usuario, guías de instalación, documentación de software, preguntas frecuentes, tutoriales y bases de conocimiento. Métricas de éxito en redacción publicitaria: medidas mediante métricas de conversión como la tasa de clics (CTR), la tasa de conversión, el volumen de ventas y el retorno de la inversión (ROI). Redacción UX: medida por la usabilidad y la satisfacción del usuario, como tasas de error reducidas, tiempo de finalización de tareas, retención de usuarios y comentarios positivos sobre la experiencia del usuario. Redacción técnica: se mide por la claridad y eficacia de la documentación, como la cantidad de tickets de soporte, los comentarios de los usuarios, el tiempo para encontrar información y la facilidad de uso de la documentación. Colaboración en redacción de textos publicitarios: colabora con equipos de marketing, ventas y branding. Redacción UX: trabaja con diseñadores de UX/UI, desarrolladores, investigadores de experiencia del usuario y gerentes de producto para integrar la redacción en el diseño y la funcionalidad del producto. Redacción técnica: colabora con ingenieros, desarrolladores, gerentes de productos y equipos de soporte para garantizar que la documentación sea precisa y útil. En última instancia, mientras que el copywriting busca persuadir y convertir, el UX writing busca facilitar y guiar, y el tech writing se centra en explicar e instruir. Cada estrategia utiliza la escritura como herramienta principal, pero con enfoques y aplicaciones diferentes, pero que se complementan en algún punto del recorrido del usuario. ¿Cómo aplicar UX Writing a un Producto para aportar valor? Ahora que entiendes qué es UX Writing, puedes entender cómo aplicar la estrategia. En este caso, cuando hablamos de UX Writing y Producto, estos términos deben ir de la mano en la creación y optimización constante de un producto. Aquí incluso podemos hablar del “Product Writer”, un profesional totalmente enfocado a trabajar en Productos que busca mejoras, investigando y entendiendo el punto de vista de los usuarios sobre un determinado producto y definiendo soluciones por escrito. Por tanto, debemos entender cómo el UX Writing añade valor a los productos digitales de diferentes maneras, contribuyendo significativamente a la experiencia del usuario y, en consecuencia, al éxito del producto. ¿Veamos algunas prácticas que se pueden implementar en productos digitales? 1. Claridad en los mensajes de error y éxito Mensajes de error: deben ser claros y específicos, informando al usuario qué salió mal y cómo corregir el problema. Por ejemplo, "La contraseña debe tener al menos 8 caracteres" es más útil que "Error de contraseña". Mensajes de éxito: Confirmaciones claras que informan al usuario que la acción se completó con éxito. Por ejemplo, "¡Su compra fue exitosa!" 2. Instrucciones de incorporación y guías de usuario: proporcione tutoriales y guías paso a paso para nuevos usuarios, ayudándolos a familiarizarse con el producto. Tooltips y ventanas emergentes: instrucciones contextuales que aparecen en el momento adecuado para guiar al usuario sin interrumpir su experiencia. 3. Botones y enlaces de llamadas a la acción (CTA) eficaces: utilice verbos de acción claros y directos, como “Compre ahora”, “Regístrese” o “Obtenga más información”. Evite términos vagos como "Haga clic aquí". Jerarquía visual: asegúrese de que los CTA estén resaltados visualmente para guiar la atención del usuario. 4. Menús y etiquetas de navegación mejorados: utilice terminología familiar e intuitiva en los menús y las etiquetas. Por ejemplo, “Cuenta” en lugar de “Perfil de usuario”. Migas de pan: implemente migas de pan para ayudar a los usuarios a comprender dónde se encuentran en la navegación del sitio y cómo regresar a las páginas anteriores. 5. Formularios de microcopia: proporcione instrucciones claras y concisas para cada campo de entrada. Ejemplos: "Ingrese su correo electrónico" en lugar de sólo "Correo electrónico". Retroalimentación inmediata: proporcione retroalimentación instantánea al completar formularios, como marcar los campos correctos con una marca de verificación verde. 6. Ajustes de accesibilidad Texto alternativo: agregue descripciones útiles a imágenes, gráficos e íconos para mejorar la accesibilidad. Lenguaje sencillo: evitar la jerga y los términos técnicos complejos, haciendo que el contenido sea accesible para todos los usuarios, incluidos aquellos con discapacidades cognitivas. 7. Coherencia en el tono de voz Manual de estilo: Desarrollar y adherirse a un manual de estilo que defina la voz y el tono de la marca, asegurando una comunicación consistente en todas las plataformas. Revisión periódica: revise y actualice periódicamente el contenido para mantener la coherencia y la relevancia. 8. Preguntas frecuentes y documentación sobre contenido educativo: cree y mantenga secciones de preguntas frecuentes y documentación de ayuda que sean claras, detalladas y fáciles de navegar. Vídeos tutoriales y consejos: integre vídeos y consejos rápidos que ayuden a los usuarios a comprender y utilizar mejor las funciones de un producto. 9. Pruebas e interacciones Pruebas A/B: Realice pruebas A/B para evaluar la efectividad de diferentes versiones de microcopia, CTA y mensajes de error. Comentarios de los usuarios: recopile y analice los comentarios de los usuarios para identificar áreas de mejora y ajustar el contenido según sea necesario. Conclusión Date cuenta de cuántas acciones pueden ser muy sencillas y que ayudarán enormemente a que un producto entregue una buena experiencia de usuario, con mayor eficiencia y satisfacción. Su producto puede terminar creando más conexión con sus usuarios, fomentando la lealtad y, así, creando una red de consumidores que evangelizarán orgánicamente sobre su producto y lo valioso que es. Por último, no pierdas el tiempo.

Un temor para todo equipo es elegir una herramienta que rápidamente quedará obsoleta. Si ha estado desarrollando aplicaciones durante algunos años, probablemente ya haya experimentado esto. Por tanto, elegir buenas herramientas es una tarea que implica responsabilidad, ya que puede guiar el proyecto (y la empresa) hacia el éxito o hacia un mar de problemas y gastos. En este artículo, comprenderemos los usos y beneficios del marco Angular. Elegir un marco front-end no es diferente y también implica investigación y estudios. Elegir una “pila”, como la llamamos en este mundo, es trivial tanto para el presente como para el futuro. Sin embargo, en medio de esta elección surgirán algunas preguntas: ¿Encontraremos profesionales calificados para abordar este marco? ¿Podremos mantener un ritmo de actualizaciones? ¿Existe un plan bien definido sobre la dirección que tomará el marco? ¿Existe una comunidad (aquí también nos referimos a las grandes empresas que la apoyan) comprometida? Todas estas preguntas deben responderse antes de iniciar cualquier proyecto, ya que descuidar una pantalla puede generar escenarios devastadores para el producto y, en consecuencia, para la empresa y sus ganancias. Motivaciones para utilizar un marco Quizás la respuesta más directa es que a veces es bueno no seguir reinventando la rueda. Problemas rutinarios como manejar rutas para una aplicación web, o incluso controlar dependencias, generar paquetes optimizados para su publicación en producción, todas estas tareas ya tienen buenas soluciones desarrolladas y, por lo tanto, elegir un framework que te brinde este conjunto de herramientas es perfecto para ganar productividad, solidez en el desarrollo de una aplicación y además mantenerla siempre actualizada siguiendo las mejores prácticas. Además de las motivaciones directas, también puedo mencionar: La facilidad para encontrar herramientas que se integren con el framework La búsqueda de software de calidad, integrado con pruebas y otras herramientas que maduren el proceso de desarrollo Muchas situaciones y problemas ya han sido resueltos ( porque hay mucha gente trabajando con la tecnología) Motivaciones para usar el framework Angular: Construido usando Typecript, uno de los lenguajes más populares en este momento MVC Arquitectura Control e Inyección de Dependencia Modularización (con opción de carga diferida) Buenas bibliotecas para integración Comunidad grande y comprometida 1835 contribuyentes en el repositorio oficial Apoyado y mantenido oficialmente por el equipo de Google La solidez de Angular Actualmente, podemos afirmar claramente que el marco es estable y recibe actualizaciones frecuentes debido a su naturaleza de código abierto. Esto se debe a que lo mantiene el equipo de Google, que siempre busca dejar lo más claro posible la hoja de ruta de lo que está por venir, lo cual es muy bueno. Además, la comunidad Angular es muy activa y comprometida. Es difícil tener un problema que aún no se haya resuelto. Una de las preocupaciones de todo desarrollador es la de realizar cambios drásticos en una herramienta. Cualquiera que haya vivido el cambio de V1 a V2 de Angular sabe este dolor, el cambio fue prácticamente total. Sin embargo, el marco se basó correctamente en Typecript, lo que aportó robustez y otra razón para su adopción: con Typecript, tenemos posibilidades que Javascript por sí solo no puede resolver: escritura fuerte, integración con el IDE, facilitar la vida a los desarrolladores, reconocimiento de errores en el desarrollo. tiempo y mucho más. Actualmente, el framework se encuentra en la versión 17 y ha ido ganando cada vez más madurez y solidez, con el aumento de características innovadoras como el recientemente lanzado aplazar. Actualización fácil El marco proporciona una guía para cada actualización a través del sitio web https://update.angular.io, este recurso ayuda mucho a guiar la actualización de su proyecto. CLI completo Angular es un marco. Por lo tanto, al instalar tu paquete tendremos la CLI lista para lanzar nuevos proyectos, generar componentes, ejecutar pruebas, generar el paquete final y mantener actualizaciones para tu aplicación: Para crear tu primer proyecto, simplemente abre tu terminal y ejecuta el siguiente comando : Diseños de interfaz sólidos Si necesita un diseño para su aplicación que proporcione componentes listos para usar, como alertas, ventanas modales, avisos de snackbar, tablas, tarjetas, una de las posibilidades más populares es elegir Angular Material, un buen punto a Seguir su software es porque Google lo mantiene, por lo que cada vez que el marco avanza en versión, Material generalmente sigue esta actualización. Además de Material, existen otras opciones en la comunidad, como PrimeNG, que trae un conjunto de componentes muy interesante (y grande). Soporte de biblioteca Nx Angular tiene soporte completo para el proyecto Nx, lo que hace posible escalar su proyecto de una manera muy consistente, garantizando principalmente el almacenamiento en caché y posibilidades avanzadas para que pueda mantener y escalar su aplicación local o en su entorno de CI. A continuación se muestran algunos ejemplos específicos de cómo se puede utilizar Nx para mejorar un proyecto de Angular: Puede crear una biblioteca de Angular que se puede reutilizar en varios proyectos. Puede crear un monorepo que contenga todos sus proyectos de Angular, lo que facilita la colaboración entre equipos. Puede automatizar tareas de desarrollo comunes, como ejecutar pruebas e implementar sus proyectos. Pruebas (unitarias y E2E) Además de Karma y Protactor que nacieron con el marco, ahora puedes usar proyectos populares como Jest, Vitest y Cypress. Estado con Redux Una de las bibliotecas más utilizadas por la comunidad es NgRx Store, que proporciona gestión de estado reactiva para aplicaciones Angular inspiradas en Redux. GDE brasileños En Brasil actualmente contamos con dos GDE Angular, lo cual es importante para nuestro país y también para generar contenido Angular en portugués, trayendo noticias e insights siempre actualizados a nuestra comunidad directamente desde el equipo de Google. Loiane Gronner William Grasel Alvaro Camillo Neto Grandes empresas que utilizan y apoyan Quizás la más notoria sea Google, el mantenedor oficial del marco.   Checklist Fácil  Picpay ¿Quieres saber más? ¿Interesado en comenzar con Angular? Visite https://angular.dev/, la documentación más reciente para el marco que incluye tutoriales, un área de juegos y documentación buena y bien explicada. ¡Buen código! 

¿Qué es un Modelo Arquitectónico y por qué es importante? Básicamente, un modelo arquitectónico es la estructura abstracta en la que se implementará su aplicación. "La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema que abarca los componentes del software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos". (Bass, Clements y Kasman, Arquitectura de software en la práctica) Para definir el modelo que mejor se adapta a tu proyecto, necesitamos conocer bien las estrategias de la empresa a corto, medio y largo plazo, los requisitos no funcionales y arquitectónicos del software, así como la curva de crecimiento de usuarios en el tiempo y el volumen de solicitudes. . Además de los puntos mencionados a lo largo de este artículo, todavía hay otros a tener en cuenta a la hora de decidir qué modelo arquitectónico aplicar. Como ejemplo, podemos enumerar: Preocupaciones de seguridad; Almacenamiento de datos; Lockins; Volumen total de usuarios; Volumen de usuarios simultáneos; TPS (transacciones por segundo); Plan de disponibilidad/SLA; Requerimientos legales; Disponibilidad en uno o más tipos de plataformas; Integraciones. El estudio de la arquitectura, los RA (requisitos arquitectónicos), los VA (variables arquitectónicas), los RF (requisitos funcionales), los RNF (requisitos no funcionales) y los criterios que definen cada uno de estos elementos influyen directamente en la elección del modelo correcto. La elección del modelo arquitectónico puede afectar todo el ciclo de vida de la aplicación. Por tanto, este es un tema que debemos tratar con mucha atención. El uso de MVP (especialmente aquellos que no entran en producción) puede ayudar mucho en esta tarea. Dan una oportunidad única de equivocarse, ajustar, volver a equivocarse, probar conceptos, ajustar y equivocarse tantas veces como sea necesario para que al final el software tenga la arquitectura en la versión más correcta, trayendo así las verdaderas ganancias de este. elección. Cómo se dividen los modelos arquitectónicos Es ideal dejar claro que como muchas definiciones en el mundo del software, qué son los modelos arquitectónicos y qué son pueden variar. Por eso, en este artículo intenté dividirlos en cuatro grandes grupos: monolíticos, semimonolíticos (o monolitos modulares), monolitos distribuidos (o microlitos) y microcomponentizados. Monolítico Modelo en el que todos los componentes forman una única aplicación o ejecutable integrados en un único código fuente. En este caso, todo se desarrolla, implementa y escala como una sola unidad. Figura 1 – Ejemplo de un modelo monolítico. Ventajas Simplicidad: a medida que la aplicación se trata como una unidad única y cohesiva, se vuelve más simple ya que todas las partes están contenidas en un único código fuente. Mayor adherencia a los Patrones de Diseño: teniendo en cuenta que contamos con un único código fuente, otro factor que lo facilita es que los propios patrones de diseño (Design Patterns, 01/2000) fueron escritos en tiempos de dominio monolítico, haciendo que la aplicación de incluso más adherente. Mayor rendimiento: debido a la baja latencia en la comunicación, los monolitos suelen tener un buen rendimiento, incluso utilizando tecnologías más obsoletas. Menor consumo de recursos: la baja complejidad, la simplicidad y la menor sobrecarga de comunicación entre capas favorecen un menor consumo de recursos. Solución de problemas más sencilla: la creación de entornos de desarrollo y depuración se facilita en los monolitos, ya que los componentes comparten los mismos procesos en ellos. Otro factor que podemos tener en cuenta es que los monolitos tienen menos puntos de fallo externos, simplificando la búsqueda de errores. Contras Tamaño de equipo limitado: las fallas relacionadas con la integración continua y los conflictos de fusión ocurren con mayor frecuencia en monolitos, lo que crea dificultades en el trabajo paralelo para equipos grandes. Escalabilidad: la escalabilidad puede estar limitada en ciertos aspectos. Incluso con facilidad en la escalabilidad vertical, la escalabilidad horizontal a menudo puede convertirse en un problema que podría afectar el crecimiento de la aplicación. Disponibilidad de ventanas: normalmente, para un monolito se intercambian ejecutables, lo que requiere una ventana de disponibilidad sin que los usuarios accedan a la aplicación, lo que no ocurre con otros modelos arquitectónicos que pueden utilizar otras técnicas de despliegue como Blue-Green o incluso trabajar con imágenes. o vainas. Única tecnología: la baja diversidad tecnológica muchas veces puede convertirse en un impedimento para el crecimiento de la aplicación al atender solo un tipo de sistema operativo, por ejemplo, o no atender plenamente las nuevas funcionalidades solicitadas por los clientes al no contar con actualizaciones que tengan capacidad para resolver complejos. problemas. Mayor gasto en compilación y ejecución: los monolitos grandes generalmente tardan mucho en compilarse y ejecutarse localmente, generando un mayor compromiso en el tiempo de desarrollo. Cuándo usar Baja escalabilidad y disponibilidad: si la aplicación tiene una escala limitada donde, por ejemplo, el número de usuarios es bajo o no es obligatoria una alta disponibilidad, el modelo monolítico es una buena solución. Aplicaciones de escritorio: el modelo monolítico es muy recomendable para aplicaciones de escritorio. Equipos de baja antigüedad: los modelos monolíticos, por su simplicidad y ubicación de componentes, permiten que los equipos de baja antigüedad trabajen con un mejor rendimiento. Recursos limitados: para una infraestructura limitada y con recursos escasos. Semimonolítico (o monolito modular) Modelo en el que las aplicaciones están compuestas por partes de estructuras monolíticas. En este caso, la combinación intenta equilibrar la simplicidad del modelo monolítico y la flexibilidad del microcomponentizado. Actualmente, este modelo arquitectónico suele confundirse con los microservicios. Figura 2 – Ejemplo de un modelo semimonolítico. Ventajas Aporta los beneficios de los modelos monolíticos y microcomponentizados: con esto, es posible mantener piezas como estructuras monolíticas y microcomponentizar solo los componentes que tienen una necesidad real. Diversidad tecnológica: posibilidad de utilizar diferentes enfoques tecnológicos. Infraestructura diversificada: este modelo se puede desarrollar para utilizar infraestructura tanto On Premise como Cloud, favoreciendo la migración entre ambas. Soporta equipos más grandes: la segmentación de componentes permite que varios equipos trabajen en paralelo, cada uno dentro de su propio ámbito. Especialidades Técnicas: debido a la segmentación se aprovechan mejor las hard skills del equipo como frontend, UX, backend, QA, arquitectos, etc. Contras Estandarización: debido a la gran cantidad de componentes que pueden aparecer en un modelo semimonolítico, la estandarización (o la falta de ella) puede convertirse en un problema importante. Complejidad: la complejidad inherente a este tipo de modelos también tiende a aumentar con nuevas funcionalidades. Por lo tanto, nuevas características como mensajería, almacenamiento en caché, integraciones, control de transacciones, pruebas, entre otras, pueden agregar aún más complejidad al modelo. Presupuesto: en modelos que soportan el uso de diferentes tecnologías con equipos grandes se necesitan profesionales más especializados y con mayor nivel de veteranía, lo que muchas veces se traduce en un mayor gasto en gastos de personal. Resolución de problemas complejos: la complejidad del modelo y la diversidad de tecnologías hacen que la resolución de problemas de la aplicación sea cada vez más difícil. Esto se debe a la gran cantidad de puntos de falla (incluidos los externos a la aplicación) que llegan a existir y la comunicación entre ellos. Cuándo usar Aceptado en Varios Escenarios: es un modelo flexible que puede afrontar varios escenarios, pero no siempre de la mejor manera. Poca Definición: en proyectos que tienen incertidumbres o incluso que no tienen la definición completa de sus requerimientos, este modelo es el más adecuado. En equipos medianos y grandes: como hemos comentado, la división de componentes en varios grupos facilita el trabajo paralelo en equipos medianos y grandes. Normalmente, los grupos tienen sus propios repositorios de código, lo que hace que el trabajo paralelo sea más ágil. Diverse Seniority: este modelo se beneficia de equipos con este formato, ya que el software semimonolítico presenta desafíos variados, tanto en la capa frontend como backend y en temas de infraestructura (IaC – Infrastructure as a Code). Infraestructura: para una infraestructura híbrida o basada en la Nube, este modelo es más aplicable. Es un modelo que permite, por ejemplo, la adopción gradual entre On-Premise y Cloud, facilitando la adaptación y minimizando los impactos operativos. Monolito distribuido Este modelado es un modelado "moderno" que también ha sido implementado y confundido con el modelo de microcomponentes/microservicios. "No deberías comenzar un nuevo proyecto con microservicios, incluso si estás seguro de que tu aplicación será lo suficientemente grande como para que valga la pena". (Fowler, Martín. 2015) En resumen, en este modelo arquitectónico el software se construye sobre la base del modelo monolítico, pero se implementa según el modelo microcomponenteizado. Actualmente muchos lo consideran un antipatrón. Figura 3 – Ejemplo de modelo de monolito distribuido. No valdría la pena enumerar las características pro (no sé si las hay), pero sí vale la pena mencionar las que van en contra: este modelo arquitectónico reúne los puntos negativos de los otros dos estilos con los que se combina. confundido. En él, los servicios están altamente acoplados y además tienen varios tipos de complejidad, tales como: operacional, testabilidad, despliegue, comunicación e infraestructura. El alto acoplamiento, especialmente entre servicios backend, trae serias dificultades de implementación, sin mencionar el aumento significativo de los puntos de falla en el software. Microcomponenteizado Modelo de software en el que todos los componentes están segmentados en partes pequeñas y completamente desacopladas. Dentro de los microcomponentes podemos mencionar: Microfronteras Microbases de datos Microvirtualizaciones Microservicios Microlotes mejores amigas API Figura 4 – Ejemplo de un modelo microcomponenteizado. "Un microservicio es un componente de aplicación orientado a servicios que tiene un alcance estricto, está fuertemente encapsulado, está débilmente acoplado, se puede implementar y escalar de forma independiente" (Gartner, s.f.). Las opiniones convergen para decir que cada microservicio que funcionó fue primero un monolito que se volvió demasiado grande para ser mantenido y llegó a un punto común de tener que ser separado. Ventajas Escalabilidad: la escalabilidad en este modelo se vuelve bastante flexible. Dependiendo de la necesidad, los componentes se escalan de forma específica. Desarrollo ágil: los equipos pueden trabajar de forma independiente en cada componente, lo que facilita la implementación continua y acelera el ciclo de desarrollo. Resiliencia: si un componente falla, no necesariamente afecta a toda la aplicación. Esto mejora la resiliencia general del sistema. Es importante tener en cuenta que existen enfoques de punto único de falla para evitar este tipo de problema. Tecnología diversificada: cada componente puede desarrollarse utilizando diferentes tecnologías, permitiendo elegir la mejor herramienta para cada tarea específica. Además, también favorece las habilidades existentes de cada equipo. Facilidad de Mantenimiento: los cambios en un componente no afectan automáticamente a otros, facilitando el mantenimiento y la actualización continua. Desacoplamiento: los componentes son independientes entre sí, lo que significa que los cambios en un servicio no afectan automáticamente a otros, facilitando el mantenimiento. Contras Costo: alto costo de todos los componentes de este modelo (entrada, salida, solicitudes, almacenamiento, herramientas, seguridad, disponibilidad, entre otros). Tamaño: el software microcomponente tiende a ser más grande en esencia. No sólo el tamaño de la aplicación, sino todo el ecosistema que la impregna desde el compromiso con el entorno de producción. Complejidad Operacional: hay un aumento exponencial de la complejidad en este modelo. Diseñar buenos componentes arquitectónicos para que se gestione esta complejidad es de gran importancia. Es importante elegir y gestionar bien las herramientas de registro, APM y Monitoreo Continuo, por ejemplo. Administrar muchos microservicios puede resultar complejo. Se requiere un esfuerzo adicional para monitorear, organizar y mantener los servicios en funcionamiento. Latencia: la comunicación entre microservicios puede volverse compleja, especialmente en sistemas distribuidos, lo que requiere estrategias adecuadas de comunicación y gestión de API. Gastos generales de la red: el tráfico de red entre microservicios puede aumentar, especialmente en comparación con las arquitecturas monolíticas, lo que puede afectar el rendimiento. Coherencia entre transacciones: garantizar la coherencia en las operaciones que involucran múltiples microservicios puede ser un desafío, especialmente cuando se trata de transacciones distribuidas. Capacidad de prueba: probar las interacciones entre microservicios puede ser más complejo que probar una aplicación monolítica, lo que requiere estrategias de prueba eficientes. Infraestructura: es posible que deba invertir en una infraestructura sólida para respaldar la ejecución de múltiples microservicios, incluidas herramientas de orquestación de contenedores y sistemas de monitoreo. Dispersión Técnica: en este punto podemos decir que hay una acción de la Ley de Conway “Inversa”, ya que los equipos, así como las tecnologías y herramientas, tienden a seguir la dispersión y la segregación. En equipos, cada persona toma conciencia de una pequeña parte de un todo mayor. De esta forma, para tecnologías y herramientas, cada desarrollador utiliza el framework o herramientas que más le convienen. Diseño basado en dominios: para aumentar las posibilidades de éxito de este modelo, los equipos deben tener conocimientos de DDD. Cuándo usar Volumetría: la arquitectura de microservicios/microcomponentes ha demostrado ser efectiva en sistemas de alto volumen, es decir, aquellos que necesitan lidiar con grandes cantidades de transacciones, datos y usuarios. Disponibilidad: una de las principales razones para adoptar este tipo de arquitectura es la disponibilidad. Cuando está bien construido, el software que adopta la microcomponentización no tiende a fallar en su totalidad cuando las partes pequeñas presentan problemas. Por lo tanto, otros componentes continúan funcionando mientras el componente problemático se recupera. Escalabilidad: si diferentes partes de su aplicación tienen diferentes requisitos de escalabilidad, los microservicios pueden resultar útiles. Puede escalar solo aquellos servicios que necesitan la mayor cantidad de recursos, en lugar de escalar toda la aplicación. Tamaño del equipo: Los equipos pequeños pueden ser un problema. Configuraciones, textos estándar, entornos, pruebas, integraciones, procesos de entrada y salida. Resiliencia > Rendimiento": en casos de incertidumbre, por ejemplo, el volumen de solicitudes y hasta dónde puede llegar, como grandes e-commerces en periodos de alto acceso (Black Friday) donde es necesario que el software sea más resiliente y desempeñarse mejor en la mediana. Lista de verificación comparativa Figura 5 – Lista de verificación Comparación entre modelos. Conclusión En resumen, la elección del modelo arquitectónico es crucial para el éxito del proyecto, requiriendo un análisis cuidadoso de las necesidades y objetivos. Cada modelo arquitectónico tiene sus ventajas y desventajas y debemos guiar la decisión alineándola con los requerimientos específicos del proyecto. Al considerar las estrategias, los requisitos y los estudios arquitectónicos de la empresa, es posible tomar una decisión que tendrá un impacto positivo en el ciclo de vida de la aplicación. El trabajo (y apoyo) del equipo de arquitectura es sumamente importante. También es de gran importancia que la gerencia y áreas afines apoyen brindando tiempo para recolectar toda esta gama de información. ¿Aún tienes dudas? Al principio, comience con el semimonolito/monolito modular. Asimismo, preste mucha atención al modelado de bases de datos. Referencias Garner. (Dakota del Norte.). Microservicio. Obtenido de https://www.gartner.com/en/information-technology/glossary/microservice Gamma, E., Helm, R., Johnson, R. y Vlissides, J. (1994). Patrones de diseño: elementos de software reutilizable orientado a objetos. Addison-Wesley. Bass, L., Clements, P., Kazman, R. (2013). Arquitectura de software en la práctica (3ª ed.). Addison-Wesley. Arquitectura de Microservicios (12/2023). Obtenido de https://microservices.io/ Fowler, S. J. (2017). Microservicios listos para producción. Novatec. Formación ArchExpert. (Dakota del Norte.). Contenido premium. Obtenido de https://one.archoffice.tech/ Monolito Primero (06/2015). Obtenido de https://martinfowler.com/bliki/MonolithFirst.html Microservicios. Consultado el 01/2024.

En este artículo hablaré sobre GraphQL centrándonos en las aplicaciones dotNet. Aquí, mostraré cómo los problemas inherentes de REST motivaron la creación de GraphQL. A continuación, presentaré los conceptos básicos de la especificación de este lenguaje. Luego presentaré la biblioteca Hot Chocolate, que es una de las muchas bibliotecas que implementan la especificación GraphQL. Finalmente, mostraré un pequeño ejemplo del uso de esta biblioteca en una aplicación dotNet. REST Antes de hablar de GraphQL es necesario hablar de REST. El término fue acuñado por Roy Thomas Fielding (2000) en su tesis doctoral. En este trabajo, Fielding presenta REST como un patrón arquitectónico para aplicaciones web definido por cinco restricciones: Cliente-servidor: Esta restricción define que la interfaz de usuario debe estar separada de los componentes del sistema que procesan y almacenan datos. Sin estado: esta restricción dice que el cliente no necesita estar al tanto del estado del servidor, ni el servidor necesita estar al tanto del estado del cliente. Caché: esta restricción indica que, cuando sea posible, la aplicación del servidor debe indicar a la aplicación cliente que los datos se pueden almacenar en el caché. Sistema en capas: esta restricción indica que la aplicación debe construirse apilando capas que se agreguen funcionalidad entre sí. Interfaz uniforme: Esta restricción indica que los recursos de la aplicación deben estar disponibles de manera uniforme, de modo que, al aprender a acceder a un recurso, automáticamente se sepa cómo acceder a los demás. Según el trabajo de Fielding, esta es una de las características centrales que distinguen a REST de otros patrones arquitectónicos. Sin embargo, el propio autor afirma que esto degrada la eficiencia de la aplicación, ya que los recursos no están disponibles de una manera que satisfaga las necesidades específicas de una aplicación determinada. Cómo se ve REST en la práctica En la Figura 1 puede ver parte de la API OneDrive de Microsoft. En esta imagen se puede ver la uniformidad en el acceso a los recursos. Esto se nota cuando notamos que, para obtener datos, simplemente se envía una solicitud GET a un punto final que comienza con el término unidad y va seguido del nombre del recurso y su ID. La misma lógica se aplica a la creación de recursos (POST), modificación de recursos (PUT) y eliminación de ellos (DELETE). Accediendo a la documentación de Google Drive, podemos ver el retorno típico de una API REST. La documentación antes mencionada muestra el gran volumen de datos que puede traer una sola solicitud REST. A pesar de ser grande, es posible que una aplicación cliente aún necesite realizar solicitudes adicionales para obtener más datos sobre el propietario de un archivo, por ejemplo. Considerando las restricciones determinadas por Fielding y los ejemplos mostrados, es fácil ver dos problemas inherentes a REST. El primero de ellos es el tráfico de datos que el consumidor no necesita y el segundo es la posible necesidad de realizar varias solicitudes para obtener los datos necesarios para crear una página web. Figura 1 - Acceda al artículo completo aquí. Comprender GraphQL GraphQL surgió en 2012 en Facebook como una solución a los problemas encontrados en el estándar REST. En 2015, el lenguaje pasó a ser de código abierto y en 2018 se creó la Fundación GraphQL, que se encargó de especificar la tecnología. Es importante resaltar que GraphQL no es una biblioteca ni una herramienta. Al igual que SQL, GraphQL es un lenguaje para buscar y manipular datos. Mientras usamos SQL en la base de datos, GraphQL se usa en las API. La Tabla 1 muestra una expresión SQL para recuperar un número de pedido y un nombre de cliente de una base de datos. De manera similar, la Tabla 2 muestra una expresión GraphQL para obtener los mismos datos de una API que admite GraphQL. En los ejemplos, podemos ver dos ventajas principales de GraphQL sobre REST. El primero está presente en el hecho de que GraphQL permite al consumidor buscar únicamente los datos que necesita para crear su página web. El segundo está presente en que el consumidor podría buscar los datos del pedido y del cliente en una sola llamada. Tabla 1: Ejemplo de selección en una base de datos relacional. Tabla 2: Ejemplo de una expresión GraphQL. Considero interesante mencionar dos características más de una API GraphQL. El primero de ellos es la existencia de un único punto final. A diferencia de REST, donde se crea un punto final para cada recurso, en una API GraphQL todas las consultas y mutaciones se envían al mismo punto final. El segundo es el hecho de que una API GraphQL solo admite el verbo POST. Esta es otra diferencia más en relación con un REST, donde se deben usar diferentes verbos HTTP dependiendo de la intención de la solicitud. Por lo tanto, mientras en una API REST debemos usar los verbos GET, POST, PUT y DELETE, en una API GraphSQL usaremos el verbo POST para obtener, crear, cambiar y eliminar datos. Lenguaje de definición de esquemas Hablemos ahora un poco sobre SDL (lenguaje de definición de esquemas). Cuando se utiliza una base de datos relacional, primero es necesario definir el esquema de la base de datos, es decir, es necesario definir las tablas, columnas y relaciones. Algo similar ocurre con GraphQL, es decir, la API necesita definir un esquema para que los consumidores puedan buscar los datos. Para crear este esquema, se utiliza SDL. El sitio web oficial de GraphQL tiene una sección dedicada a SDL. En esa sección puede encontrar una descripción completa del lenguaje para crear esquemas GraphQL. En este texto, presentaré la sintaxis básica para crear un esquema GraphQL. En la Figura 2 puede ver parte de un esquema GraphQL creado con Apollo. Podemos ver que el esquema comienza con la definición de dos tipos fundamentales: Consulta y Mutación. En el primer tipo definimos todas las consultas que tendrá nuestra API. En nuestro ejemplo, los consumidores podrán buscar clientes, productos y pedidos. El tipo de mutación define qué operaciones de manipulación de datos estarán disponibles para el consumidor. En el ejemplo presentado, el consumidor podrá crear, cambiar y eliminar clientes y productos. Sin embargo, cuando se trata de pedidos, puede crear, agregar un artículo, cancelar y cerrar el pedido. Además de los tipos Consulta y Mutación, puede ver la presencia de los tipos Cliente y Producto. En ambos, hay propiedades ID, String y Float. Estos tres tipos, junto con los tipos Int y Boolean, se denominan tipos escalares. El esquema también muestra la definición de una enumeración denominada OrderStatus. La Figura 3 muestra la definición de tipos de entrada que se utilizan para proporcionar datos de entrada para consultas y mutaciones. Creo que es importante señalar que la forma de crear el esquema varía según la biblioteca que elijas. Cuando se utiliza la biblioteca Apollo para javascript, la definición del esquema se puede realizar a través de una cadena pasada como parámetro a la función gql o mediante la creación de un archivo (generalmente llamado esquema.graphql). Sin embargo, cuando se utilizan bibliotecas como Hot Chocolate para dotNet, la definición del esquema se realiza mediante la creación de clases y la configuración de servicios en la aplicación. Por tanto, la forma en que se crea un esquema GraphQL puede variar mucho según el lenguaje y la biblioteca elegidos. Figura 2. Figura 3. Elementos básicos del lenguaje GraphQL Como se mencionó anteriormente, GraphQL es un lenguaje y por lo tanto tiene una sintaxis. Puede encontrar la guía completa con la sintaxis del idioma en el sitio web oficial de GraphQL. Sin embargo, en este artículo describiré sus elementos básicos.   La búsqueda de datos se realiza mediante consultas, las cuales deben comenzar con la palabra clave consulta seguida del nombre de la consulta. Si tiene parámetros debes abrir paréntesis y, dentro de ellos, debes colocar el nombre de cada parámetro seguido de su valor. Se deben utilizar dos puntos (:) para separar el nombre del parámetro de su valor. Una vez finalizada la lista de parámetros, se deben cerrar los paréntesis. Luego, debes abrir llaves ({) y colocar dentro de ellas el nombre de los campos que deseas. Con la lista de campos finalizada, debes cerrar la llave (}). La Tabla 3 muestra un ejemplo simple de una consulta. Tabla 3: Ejemplo de consulta. Hay escenarios en los que los parámetros de consulta pueden ser complejos. Cuando un parámetro es complejo, es decir, es un objeto con uno o más campos, se deben abrir llaves inmediatamente después de los dos puntos. Dentro de las claves se debe colocar el valor de cada campo del objeto y su respectivo valor, ambos deben estar separados por dos puntos (ver tabla 4). También hay escenarios en los que los campos de consulta pueden ser complejos. En estos casos, debe abrir llaves justo después del nombre del campo. Dentro de las claves, debes colocar los nombres del campo objeto (ver tabla 5). Tabla 4: Ejemplo de consulta. Tabla 5: Ejemplo de consulta. Las reglas descritas hasta ahora también se aplican a las mutaciones. Sin embargo, estos deben iniciarse con la palabra clave mutación en lugar de consulta. Es interesante observar que existen otros elementos en la sintaxis de GraphQL, pero los elementos descritos hasta ahora son suficientes para ejecutar la mayoría de consultas y mutaciones. Al ser un lenguaje, GraphQL debe ser implementado mediante alguna aplicación o biblioteca. Para que nuestra API admita consultas y mutaciones, generalmente necesitamos una biblioteca. Por supuesto, podríamos implementar la especificación del lenguaje por nuestra cuenta, pero eso sería muy improductivo. La sección “Código” del sitio web GraphQL.org muestra una lista de bibliotecas que implementan GraphQL para los más variados lenguajes. Para el mundo dotNet, por ejemplo, existen las bibliotecas “GraphQL para .NET”, “Hot Chocolate” y otras. Cuando se habla de implementaciones GraphQL, es necesario hablar del concepto de “resolvedores”. Un solucionador es una función activada por la biblioteca que implementa GraphQL. Esta función es responsable de recuperar de manera efectiva los datos solicitados por la consulta. Lo mismo ocurre con las mutaciones, es decir, cuando la biblioteca recibe una solicitud para ejecutar una mutación, la biblioteca identifica el solucionador que ejecutará los cambios en la base de datos (insertar, actualizar y eliminar). Nótese, entonces, que en la mayoría de bibliotecas las búsquedas y cambios de datos se realizan mediante su propio código. Se puede ver, entonces, que las bibliotecas que implementan GraphQL son responsables de interpretar la consulta/mutación enviada por el llamante y descubrir la función adecuada para resolver la consulta/mutación solicitada. Para ver un ejemplo de una API sencilla que utiliza Hot Chocolate, visita mi GitHub. En definitiva, GraphQL es un lenguaje creado por Facebook con el objetivo de superar los problemas inherentes a REST. El lenguaje proporciona una sintaxis simple para obtener datos de una API y cambiar datos de ella. Se implementa mediante una amplia variedad de bibliotecas para los idiomas más diversos, lo que permite al desarrollador crear una API GraphQL utilizando su idioma favorito. Referencias "GraphQL". Wikipedia, 9 de junio de 2022, en.wikipedia.org/wiki/GraphQL. Consultado el 6 de noviembre. 2023. La Fundación GraphQL. "GraphQL: un lenguaje de consulta para API". Graphql.org, 2012, graphql.org/. Thomas Fielding, Roy. "Disertación de campo: CAPÍTULO 5: Transferencia de estado representacional (REST)". Ics.uci.edu, 2000, ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Consultado el 6 de noviembre.  

¿Qué son los sistemas de diseño multimarca? Los sistemas de diseño multimarca son sistemas con atributos que los hacen flexibles para su uso en diferentes contextos, patrones visuales y diseño de interfaz. Están desarrollados para casos en los que una única biblioteca pretende servir productos de diferentes marcas. Generalmente, este tipo de sistema de diseño también es independiente de marcos, plataformas o tecnologías; se les llama sistemas de diseño independientes de la tecnología. Actualmente, el sistema de diseño agnóstico más popular es Lightning, desarrollado por Salesforce, también creador del concepto. Beneficios Además de ser una única fuente de información, el sistema de diseño multimarca comparte el costo de operación, lo que hace que el trabajo sea verdaderamente colaborativo entre equipos. Según los diseñadores del grupo Volkswagen, la implementación de GroupUI trajo los siguientes resultados: Mayor agilidad, eficiencia y reducción de costos son algunos de los beneficios de los sistemas de diseño multimarca. Escalabilidad Desarrollados a partir del concepto de tokens de diseño, permiten replicar una misma biblioteca en diferentes productos, independientemente del framework en el que se desarrollen. Al mismo tiempo, permiten que cada uno de estos productos utilice sus propios estándares visuales. Otro punto muy relevante es compartir características como buenas prácticas, capacidad de respuesta, accesibilidad, rendimiento, UX y ergonomía. Uso en diferentes tecnologías Actualmente es común encontrar en sistemas de diseño, incluso aquellos que atienden a una sola marca, diferentes bibliotecas para productos web, iOS y Android. Esto se debe a la existencia de diferentes especificaciones para los navegadores de escritorio y móviles, así como entre dispositivos con sistemas operativos nativos, como Apple y Google. Trabajando independientemente de estas tecnologías, es posible crear instancias del mismo sistema de diseño en diferentes componentes de la biblioteca para cumplir con estas particularidades. Ganancia en eficiencia Según datos difundidos por los líderes de UX y sistemas de diseño del Grupo Volkswagen, a través de la presentación Multibrand Design System dentro del grupo Volkswagen y sus marcas, se produce un gran aumento en la agilidad, productividad y eficiencia al trabajar con el multimarca. concepto . Eficiencia operativa con el uso de sistemas de diseño multimarca. (Fuente: YouTube) Comparando el esfuerzo requerido entre un producto sin sistema de diseño, pasando por uno que tiene su sistema de diseño y llegando a uno que adopta la metodología multimarca, es posible notar una reducción incremental y considerable en la UI. esfuerzos (diseño de interfaz) y desarrollo. Esta implementación permite una forma de trabajar más orientada a la experiencia y el descubrimiento del usuario, al liberar recursos para estas actividades, que hasta entonces se consumían en el diseño e implementación de interfaces. Estandarización Un sistema de diseño detallado y bien especificado se convierte en una única fuente de verdad. Cuando se comparte dentro de la organización, además de facilitar mucho el trabajo de los equipos, permite una estandarización consistente, evitando la necesidad de las mismas discusiones, descubrimientos y definiciones, que quedan listas para ser reutilizadas como resultado del desarrollo constante de un diseño. sistema. Fácil personalización Según los expertos, la principal característica de un sistema de diseño multimarca es la flexibilidad. En este contexto, personalizar significa permitir que cada producto aplique sus decisiones de diseño visual. Para que esto sea posible, se crean bibliotecas de diseño de tokens. Se pueden duplicar y personalizar fácilmente, generando patrones visuales distintos para cada marca y producto. Los tokens de diseño pueden interpretarse como variables que llevan atributos de estilo, como un color de marca, que, aplicado como token, permite, al cambiar el valor que lleva la variable, reflejar el cambio en todos los lugares donde se muestra el color en el interfaz. En el ejemplo anterior, tenemos especificaciones de color de marca para tres sistemas de diseño diferentes y en la columna de la izquierda tenemos el token, que seguirá siendo el mismo en todos los productos. El valor que lleva la variable es diferente en cada caso. Estas definiciones se aplican a cualquier otro atributo visual, como tipografía, espaciado, bordes, sombreado e incluso animaciones. Estructura de los sistemas de diseño multimarca Según Brad Frost, uno de los consultores de sistemas de diseño más influyentes en la actualidad y autor del libro Atomic Design, se recomienda que los sistemas de diseño multimarca tengan tres capas: Estructura de tres niveles de un sistema de diseño . (Fuente: Brad Frost) Agnóstico tecnológico (1ª capa) El nivel agnóstico de un sistema de diseño es la base de los demás, por lo tanto, solo incluye códigos de script html, css y java, con el objetivo de renderizar componentes en el navegador. Esta capa es sumamente importante a largo plazo, ya que permite la reutilización futura de un sistema de diseño. Por ejemplo, en el escenario actual, se puede decir que el lenguaje más popular es React. Sin embargo, esto no siempre fue así y no se sabe qué tecnología será la próxima en destacar. Por este motivo, es importante contar con una capa base, que pueda aplicarse a nuevas tecnologías, sin tener que empezar un nuevo sistema de diseño desde cero. En esta primera capa, los diseñadores y desarrolladores construyen los componentes del sistema de diseño en un entorno de taller, documentados en una herramienta como Figma y Zeroheight. El resultado de este trabajo son componentes renderizados en el navegador, considerando que el framework adoptado hoy puede no ser el mismo que se adopte en el futuro. Tech-specific (2da capa) El nivel de tecnología específica es donde ya existe una dependencia de alguna tecnología y/o plataforma y, además, existe la oportunidad de generar una capa de sistema de diseño para todos los productos que utilizan la misma tecnología. Un buen ejemplo de este tipo de sistema de diseño es Bayon DS, que sirve a los productos SAJ. También es posible utilizarlo para desarrollar cualquier otro producto que utilice tecnología React. Producto específico (tercera capa) La tercera capa es donde todo se vuelve muy específico y todo el esfuerzo se hace para un determinado producto. En este nivel, se puede crear documentación relacionada con estándares únicos que solo se aplican a ese contexto particular. Siguiendo el concepto de Atomic Design, esta capa crea componentes con mayor complejidad y menor flexibilidad, como páginas y plantillas, para generar patrones de productos. En la tercera capa, las aplicaciones individuales consumen la versión específica de la tecnología seleccionada, a través de administradores de paquetes como npm y Yarn. Cómo estamos poniendo en práctica estos nuevos conceptos Hace unos meses, tras el anuncio de la iniciativa Inner Source, comenzamos a estudiar una manera de transformar Bayon, para que pudiera "recibir" este nuevo concepto. Personalmente, comencé una investigación en profundidad sobre los temas tratados en este artículo. Softplan. Componentes web y Stencil A través de reuniones recurrentes con representantes de las empresas del Grupo Softplan, se discute la posibilidad de desarrollar una biblioteca de componentes web. En él, cada atributo visual o decisión de diseño se aplica a través de tokens de diseño, permitiendo una personalización completa que garantiza que cada componente presentará las características visuales del producto correspondiente. Los componentes web son un conjunto de API que permiten la creación de etiquetas HTML personalizadas, reutilizables y encapsuladas para usar en páginas web y aplicaciones. Tienen muchas ventajas, como compatibilidad con aplicaciones que usan o no frameworks, compatibilidad con los principales navegadores. y disponibilidad de bibliotecas de código abierto que reducen el costo de operación. Además de esta tecnología, también se utiliza Stencil.js, un compilador de código abierto que comparte conceptos que se encuentran en los frameworks más populares y que simplifica aún más el desarrollo de componentes, así como el aprendizaje por parte de los desarrolladores. Referencias Sistema de diseño multimarca dentro del grupo Volkswagen y sus marcas Design tokens: ¿Qué son y cómo te ayudarán? Los sistemas de diseño deben ser independientes del marco de JavaScript Creación de sistemas de diseño multimarca Gestión de sistemas de diseño independientes de la tecnología Salesforce Lightning DS Gestión de sistemas de diseño independientes de la tecnología Sistema de diseño multimarca dentro del grupo Volkswagen y sus marcas (Vídeo) En el archivo: Creación de diseño multimarca sistemas (vídeo) Diseño atómico de Brad Frost: un evento aparte Austin 2015 Webcomponents.org MDN Web Docs Stenciljs Creación de componentes web con StencilJS (Youtube) Creación de componentes web con Stencil JS

La seguridad de la información se refiere al conjunto de prácticas, medidas y procedimientos adoptados para proteger la información y los datos sensibles de una organización o individuo contra amenazas, acceso no autorizado, pérdida, robo, daño o cambios no deseados. El objetivo es garantizar la confidencialidad, integridad y disponibilidad de los datos, así como preservar su autenticidad y evitar que caigan en manos equivocadas. La seguridad de la información es esencial en un mundo altamente conectado que depende de sistemas informáticos, redes y tecnologías digitales. Cubre varias áreas, incluyendo: Confidencialidad: Garantizar que la información sólo sea accesible a personas autorizadas evitando el acceso no autorizado mediante autenticación, cifrado y control de acceso. Integridad: Garantizar que los datos sean exactos, completos y no sufran cambios no autorizados durante su almacenamiento, transmisión o procesamiento. Disponibilidad: Asegurarse de que la información esté disponible y accesible cuando sea necesaria, evitando interrupciones causadas por fallas, ataques o desastres. Autenticidad: Garantizar que la información se atribuye correctamente a sus autores y que el origen de los datos es verificable. No repudio: Asegurar que el autor de una acción no pueda negar la autoría o la realización de una transacción. Gestión de riesgos: Identificar, analizar y mitigar amenazas y vulnerabilidades para proteger la información de posibles incidentes de seguridad. Impactos de la falta de seguridad de la información La falta de seguridad de la información puede provocar una serie de impactos negativos importantes para los individuos, las organizaciones e incluso la sociedad en su conjunto. Algunos de los principales impactos incluyen: Robo de datos: los piratas informáticos y los ciberdelincuentes pueden ingresar a sistemas desprotegidos y robar información confidencial como datos personales, números de tarjetas de crédito, información bancaria y otros datos confidenciales. Este tipo de robo puede provocar fraude financiero, robo de identidad y extorsión. Fuga de información: Fuga de información confidencial, como secretos comerciales, propiedad intelectual o información gubernamental confidencial. Como resultado, estas filtraciones pueden dañar la competitividad de las empresas, la seguridad nacional y la privacidad de las personas. Daño a la reputación: Cuando una organización sufre una brecha de seguridad, su reputación puede verse seriamente comprometida. La percepción pública de una falta de atención a los datos de los clientes puede afectar negativamente la confianza de los clientes y socios comerciales. Interrupción del negocio: los ciberataques, como el ransomware o la denegación de servicio (DDoS), pueden dejar los sistemas inoperables e interrumpir las operaciones comerciales. Esta interrupción puede causar pérdida de productividad, daños financieros y frustración del cliente. Pérdida financiera: como el costo de reparar sistemas comprometidos, pagar rescates por ransomware o enfrentar litigios relacionados con violaciones de datos. Infracciones regulatorias y legales: en muchos países, existen leyes y regulaciones que requieren una protección adecuada de los datos y la información confidencial de los clientes. La falta de seguridad puede dar lugar a violaciones de estas leyes, lo que puede dar lugar a multas, sanciones y acciones legales. Espionaje y ciberguerra: Facilitar el ciberespionaje e incluso los ciberataques a gran escala entre países, socavando la seguridad nacional y la estabilidad geopolítica. Daño a la confianza digital: socavar la confianza general en las tecnologías digitales, lo que puede ralentizar la adopción de nuevas tecnologías y dañar la economía digital. Medidas de seguridad Para mitigar dichos impactos, es esencial que las personas y las organizaciones inviertan en medidas de seguridad de la información, como cifrado, autenticación sólida, capacitación en concientización sobre seguridad, actualizaciones periódicas de software y auditorías de seguridad. Además, es esencial que los gobiernos y los sectores industriales trabajen juntos para desarrollar políticas y estándares de ciberseguridad más sólidos. Algunos elementos comunes para garantizar la seguridad de la información incluyen firewalls, sistemas de prevención y detección de intrusiones (IDS/IPS), antivirus, cifrado, copias de seguridad periódicas, políticas de contraseñas seguras, capacitación en concientización sobre seguridad y monitoreo de actividades sospechosas. Es deber de cada uno de nosotros velar por la seguridad de la información, reconociendo la importancia de una postura vigilante en nuestro actuar diario. La responsabilidad no recae sólo en los expertos en tecnología o en departamentos concretos, sino en cada individuo. Por tanto, desconfiar, verificar y validar la información recibida es una práctica fundamental para no caer en trampas de la ingeniería social. Después de todo, esta forma de ciberataque puede originarse en fuentes inesperadas y aparentemente confiables. Sólo asumiendo el papel de nuestro propio aliado en la seguridad digital podremos construir una base sólida para proteger nuestra privacidad, datos personales e información sensible. Reforzando nuestra conciencia y adoptando medidas preventivas, podemos contribuir significativamente a un entorno en línea más seguro y confiable para todos. Es importante prestar atención a herramientas de inteligencia artificial como Chat GPT o Google Bard. Nunca utilices una dirección de correo electrónico corporativa para acceder a estas herramientas, ya que puede suponer un riesgo importante para la seguridad de la información sensible de la empresa para la que trabajas. Cuando utilice estas plataformas, opte siempre por utilizar un correo electrónico personal.