¡Hola a todos!

Mi propuesta para este proyecto se centra en la creación de un logotipo generativo para la plataforma Vitalis, una marca ficticia con el objetivo de seguir los datos de salud del usuario. Para ello, se usan JavaScript y la librería p5.js para generar un logotipo que responda de forma dinámica a los datos de salud de cada persona.

El objetivo es que cada sección de la web (Actividad, Ritmo cardíaco, Descanso e Hidratación) tenga una representación visual coherente con las propiedades (variables) de cada métrica, generando una identidad visual propia pero integrada en el estilo general de la marca.

Cada logo se genera a partir de variables clave asociadas a cada apartado:

1. Actividad: pasos, calorías quemadas y minutos de entrenamiento.
2. Ritmo cardíaco: pulsaciones altas, pulsaciones en reposo y variabilidad del ritmo cardíaco.
3. Descanso: horas de sueño, calidad del sueño e interrupciones del sueño.
4. Hidratación: cantidad de agua ingerida y objetivo.

A partir de estas métricas, el programa genera un logotipo dinámico compuesto por formas orgánicas y partículas en movimiento. Cada métrica influye en:

• Color, cada apartado tiene un color característico.
• Forma y deformación del blob central, según el valor de la variable principal.
• Cantidad, velocidad y radio de las partículas, según las variables secundarias y terciarias.

El resultado es un logotipo por apartado con  variación orgánica, reconocible dentro de cada sección y consistente en toda la plataforma.

Ontología

Siguiendo la ontología propuesta por David Casacuberta, podemos clasificar los elementos de la siguiente manera:

Reglas generativas

El programa traduce los valores de cada JSON a decisiones visuales siguiendo estas reglas:

1. Color base:
   • Actividad: tonos naranjas
   • Ritmo cardíaco: tonos rojos
   • Descanso: tonos azules
   • Hidratación: tonos celestes

El color define la esfera de fondo, el blob y las partículas de cada sección.

1. Blob orgánico:
   • Forma central generada mediante ruido Perlin para que no sea un círculo perfecto, sino una figura ondulada que cambia suavemente.
   • La intensidad de la deformación y el movimiento depende de la variable principal:
     • Actividad: pasos
     • Ritmo cardíaco: pulsaciones altas
     • Descanso: horas de sueño
     • Hidratación: progreso respecto al objetivo de agua ingerida (hidratación / objetivo)
2. Partículas orbitando:
   • Representan variables secundarias y terciarias:
     • Actividad: calorías (cantidad de partículas) y minutos de entrenamiento (velocidad de las partículas)
     • Ritmo cardíaco: pulsaciones en reposo (cantidad de partículas) y variabilidad (velocidad de las partículas)
     • Descanso: calidad del sueño (cantidad de partículas) e interrupciones (velocidad de las partículas)
     • Hidratación: la misma proporción hidratación / objetivo se usa para cantidad y velocidad, ya que solo hay dos variables. Esto permite que, aunque Hidratación tenga menos métricas, el logo siga siendo dinámico y coherente.
3. Esfera de fondo:
   • Cada logo se encuentra dentro de una esfera translúcida que unifica visualmente todos los elementos y mantiene consistencia de color.
4. Overview (página principal):
   • Combina los cuatro apartados en un solo logo.
   • Cada métrica tiene su blob y partículas, rotando a distintas velocidades y capas, creando un logotipo multidimensional y dinámico.

Resultados

Fuente 1. Ejemplo de los 5 logos generados con la propuesta comentada. Elaboración propia.

Variaciones y valoración reflexiva

Durante el desarrollo, se realizaron varias iteraciones:

1. Primera versión: cada variable de cada apartado tenía reglas independientes, lo que dificultaba que el usuario comprendiera fácilmente el logotipo y su relación con los datos.
2. Segunda versión: en la primera versión no existía una esfera de fondo; solo se mostraban el blob y las partículas. Se añadió la esfera para unificar visualmente todos los elementos y mejorar la legibilidad del logo.
3. Tercera versión: se implementó un logo integrado que agrupa todos los apartados, convirtiéndose en el logo principal de la plataforma, dinámico según las métricas de cada usuario. La composición es más rica y muestra todas las métricas simultáneamente sin perder la identidad de cada sección.

Cada iteración ha buscado equilibrar coherencia visual y dinamismo, logrando logos reconocibles, informativos y visualmente atractivos para el usuario.

Bibliografía

async function – JavaScript | MDN. (s. f.). https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

Blob by mcpecommander -p5.js Web Editor. (s. f.). https://editor.p5js.org/mcpecommander/sketches/GPDsjtaXD

canvas parent by cassie -p5.js Web Editor. (s. f.). https://editor.p5js.org/cassie/sketches/Tad2eI9j3

Casacuberta, D. (2019). En qué consiste el diseño generativo (1.^a ed.). FUOC.

Casos de diseño generativo. (s. f.). https://materials.campus.uoc.edu/daisy/Materials/PID_00267127/html5/PID_00267127.html

document.body – API web | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/API/Document/body

document.getElementById – API web | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/API/Document/getElementById

Eduardo. (2024, 6 junio). Pasar datos via POST con Async/Await. Stack Overflow En Español. https://es.stackoverflow.com/questions/621404/pasar-datos-via-post-con-async-await

element.innerHTML – API web | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/API/Element/innerHTML

Estructura de un diseño generativo. (s. f.). https://materials.campus.uoc.edu/daisy/Materials/PID_00267126/html5/PID_00267126.html#w31aac11

get – JavaScript | MDN. (s. f.). https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get

Gimenez, L. (2022, 10 diciembre). Propiedades de objetos en JavaScript. Stack Overflow En Español. https://es.stackoverflow.com/questions/573088/propiedades-de-objetos-en-javascript

Guía de JavaScript – JavaScript | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/JavaScript/Guide

Interactividad. (s. f.). https://materials.campus.uoc.edu/daisy/Materials/PID_00268941/html5/PID_00268941.html

Isarch Borja, A. (2019). Estructura de un diseño generativo (1.^a ed.). FUOC.

Kantor, I. (s. f.). Objects. https://javascript.info/object

Mitas1c. (s. f.). How to implement Offset on Perlin noise? Stack Overflow. https://stackoverflow.com/questions/70450794/how-to-implement-offset-on-perlin-noise

Noise. (s. f.). https://p5js.org/es/examples/repetition-noise/

NoStroke. (s. f.). https://p5js.org/reference/p5/noStroke/

Referencia CSS – CSS | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/CSS/Reference

Rivas, D. (2022, 28 octubre). Mostrar datos de un foreach en una tabla HTML. Stack Overflow En Español. https://es.stackoverflow.com/questions/564971/mostrar-datos-de-un-foreach-en-una-tabla-html

Tornado_Code. (2022, 20 junio). Converting custom javascript noise/offset functions to p5’s native functions. Stack Overflow. https://stackoverflow.com/questions/72692234/converting-custom-javascript-noise-offset-functions-to-p5s-native-functions

Trabajando con JSON – Aprende desarrollo web | MDN. (s. f.). https://developer.mozilla.org/es/docs/Learn_web_development/Core/Scripting/JSON

Trabajando con objetos – JavaScript | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/JavaScript/Guide/Working_with_objects

Try. . .Catch – JavaScript | MDN. (s. f.). https://developer.mozilla.org/es/docs/Web/JavaScript/Reference/Statements/try. . .catch

Using HTML form validation and the Constraint Validation API – HTML | MDN. (s. f.). https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Constraint_validation

Using the Fetch API – Web APIs | MDN. (s. f.). https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

W3Schools.com. (s. f.). https://www.w3schools.com/js/js_const.asp

Wen, A. K. Q. (s. f.). How to work with multiple datasets in p5.js? Stack Overflow. https://stackoverflow.com/questions/69986666/how-to-work-with-multiple-datasets-in-p5-js

¡Hola a todos!

Mi propuesta para este proyecto se basa en la creación de un sistema generativo para etiquetas de café instantáneo, tomando como punto de partida el ejemplo de Sottosopra y aplicando técnicas de diseño generativo mediante Processing. En este proyecto, el programa tiene en cuenta los datos disponibles de la base de datos de la marca (ficticia) los cuales constan de tres variables fundamentales del producto:

1. Tipo de café (cafeinado o descafeinado)
2. Sabor (vainilla, chocolate, avellana, caramelo, etc.)
3. Intensidad (nivel del 1 al 7)

A partir de estos datos, el programa exporta diferentes etiquetas teniendo en cuenta, formas, texturas, etc., para cada variable, siendo coherente con la imagen de la marca.

El objetivo principal es obtener diversas etiquetas teniendo en cuenta las variables anteriores y que sean reconocibles para cada tipo. Se busca un equilibrio entre orden y variación orgánica, de modo que cada etiqueta sea reconocible dentro de una misma familia pero mantenga su propia identidad.

Ontología

Siguiendo la ontología propuesta por David Casacuberta, podemos clasificar los elementos de la siguiente manera:

Reglas generativas

El programa traduce las tres variables del CSV en decisiones visuales teniendo en cuenta las siguientes reglas:

1. Tipo de café: El tipo de café determina el carácter visual y la paleta de colores del fondo:
   1. Cafeinado: colores más contrastados y vivos.
   2. Descafeinado: tonos suaves y desaturados.
2. Intensidad: La intensidad se representa mediante gotas generadas automáticamente por el programa. La cantidad de gotas refleja el nivel de intensidad indicado en la base de datos, proporcionando un indicador visual inmediato del producto.
3. Color de formas y fondo: El color de las formas se genera de manera controladamente aleatoria, considerando el tipo de café y garantizando que un mismo sabor pueda variar según esté cafeinado o descafeinado:
   1. Cafeinado: formas de tonalidad clara.
   2. Descafeinado: formas de tonalidad oscura.
4. Orden de los elementos: El programa organiza los elementos de la etiqueta en capas, asegurando claridad y jerarquía visual:
   1. Fondo generativo
   2. Formas geométricas asociadas al sabor
   3. Recuadro central que contiene la información del café: nombre de la marca, tipo, sabor e intensidad

5. Exportación automática: Cada ejecución genera automáticamente una etiqueta por cada línea del CSV. Los archivos se exportan en formato JPG.

Resultados

Fuente 1. Ejemplo de 4 etiquetas generadas con la propuesta comentada. Elaboración propia.

Variaciones y valoración reflexiva

Respecto a las variaciones, el programa ha pasado por diferentes versiones. En un primer momento, el fondo era uniforme y, según el sabor, se añadía una línea horizontal con un patrón aleatorio de formas:

Fuente 2. Ejemplo de la propuesta de la línea horizontal con un patrón de formas.

Sin embargo, este resultado resultó demasiado básico, por lo que se ajustó para que cada sabor tuviera un fondo de color propio y un patrón de formas distribuidas, rotadas y escaladas de manera diferente en cada diseño.

Tras esta mejora, se detectó la necesidad de diferenciar las etiquetas de los cafés con cafeína y los descafeinados. Para ello, se readaptó el código y se modificaron los nombres de los archivos, estableciendo la siguiente regla:

• Cafeinado: colores más contrastados y vivos, con formas en tonos claros.
• Descafeinado: colores de tonos suaves y desaturados, con formas más oscuras.

Por otro lado, se definió un color fijo para los elementos de la etiqueta.

Finalmente, el indicador de intensidad, que inicialmente se mostraba en formato texto, pasó a representarse como una barra. Más adelante, se optó por un diseño de “gotas” de café generadas mediante código, aportando mayor coherencia con el producto.

Fuente 3. Ejemplo de una de las propuestas de indicación de las características del café.

¡Hola a todos!

Partiendo de los ejemplos analizados en la PEC2, mi propuesta consiste en el desarrollo de un cartel generativo usando Processing como herramienta principal. El objetivo es explorar nuevas relaciones entre forma, color y estructura, aprovechando los materiales disponibles en las carpetas de los diferentes proyectos (altos, bajos, copy, fonts, medios, static, formas, círculos, líneas).
A diferencia de los ejemplos analizados, que se enfocan principalmente en la disposición regular de imágenes dentro de cuadrículas, este proyecto busca romper la rigidez compositiva introduciendo reglas que generen tensión entre orden y caos, así como dinamismo y variación.

Ontología

Siguiendo la ontología propuesta por David Casacuberta, podemos clasificar los elementos de este proyecto de la siguiente manera:

Reglas generativas

El programa se ejecuta en base a una serie de reglas que establecen cómo interactúan los distintos elementos. Estas normas delimitan la acción de la aleatoriedad, asegurando al mismo tiempo coherencia y variedad en los resultados:

1. Rejilla flexible: El cartel se organiza sobre una rejilla flexible que combina bloques regulares, similares a los de los ejemplos 3 y 4, con zonas libres donde los elementos pueden salirse de los límites, creando composiciones más orgánicas.
2. Superposición: Las capas se ordenan de la siguiente manera: fondo cromático → formas geométricas → imágenes principales → texto. Se aplican transparencias de manera aleatoria dentro de un rango del 30–70 %, permitiendo que los elementos interactúen visualmente sin perder legibilidad.
3. Color dinámico: La paleta parte de cinco tonos base (rojo, azul, verde, rosa y naranja). Cada ejecución genera variaciones dentro de la misma gama.
4. Escala: Las imágenes de las carpetas “altos” y “bajos” varían su tamaño entre un 80 % y un 120 % de su escala original, adaptándose a la composición sin perder sus proporciones.
5. Tipografía: Los textos (copy) varían en posición, contribuyendo a la dinamización del diseño.
6. Equilibrio: Se evalúa la densidad de elementos en cada cuadrante del cartel para evitar concentraciones excesivas en una sola zona. Si se detecta un desequilibrio, algunos objetos se reubican automáticamente.
7. Exportación: Cada ejecución genera una serie de 10 carteles en formato JPG.

Resultado

Fuente 1. Ejemplo de 3 carteles generados con la propuesta comentada. Elaboración propia.

Variaciones y valoración reflexiva

Al principio, en el desarrollo del código, se había establecido que el elemento static estuviera en sintonía con el copy, sin una restricción fija, buscando mayor flexibilidad. Sin embargo, al observar los resultados, se notó que esto rompía significativamente la armonía visual del diseño. Por esta razón, se decidió finalmente tratar static como un elemento estático, siguiendo el ejemplo de los casos analizados previamente, donde la idea funcionaba de manera más coherente.

En cuanto a la gama cromática, se exploraron varias alternativas de color con el objetivo de encontrar combinaciones que mantuvieran la legibilidad y la armonía visual. No se trató solo de escoger colores agradables, sino de asegurar que los cambios aportaran claridad y cohesión al conjunto.

Además, se hicieron pruebas con las proporciones y la disposición de los elementos dentro de la cuadrícula. La idea era encontrar un equilibrio entre mantener un orden claro y permitir cierta libertad creativa: aunque se permitieran pequeñas variaciones que rompieran ligeramente la estructura, se buscaba que todo siguiera teniendo sentido visual y no generara sensación de caos. 

En resumen, este proceso ayudó a encontrar un punto medio entre creatividad y coherencia, logrando que el diseño fuera flexible y dinámico, pero sin perder su armonía y coherencia.