Tarjetas

[paulajoglar]

Nombre en Obelisco: Tarjetas Tipo de componente: Molécula Ejemplo en boostrap: https://getbootstrap.com/docs/5.3/components/card/ Ejemplo de aplicación en BA: Tarjetas verticales, Tarjetas Horizontales, Tarjetas de temáticas, Tarjetas de noticias y Tarjetas de Agenda.

[LuCostas]

@Fcunsolo Facu, podrás actualizar estatus, dejar la descripción y requerimientos en esta tarjeta? Gracias!!

Usa si queres este modelo: Nombre en Obelisco: Tipo de componente: Ejemplo en boostrap: Ejemplo de aplicación en BA:

[Fcunsolo]

Nombre en Obelisco: Tarjetas Tipo de componente: Molécula Ejemplo en boostrap: https://getbootstrap.com/docs/5.3/components/card/ Ejemplo de aplicación en BA: Tarjetas verticales, Tarjetas Horizontales, Tarjetas de temáticas, Tarjetas de noticias y Tarjetas de Agenda.

Requerimiento Empatar todas las tipologías de tarjetas con Storybook (https://gcba.github.io/Obelisco/?path=/story/componentes-tarjetas-tipos--title-text-link) y agregar casos que no estén contemplados.

Análisis

• Se hace una auditoría de las tarjetas existentes en Storybook y en las Plantillas ya maquetadas https://gcba.github.io/obelisco-demo/index.html
• Se identifican tipologías de tarjetas: Horizontales, Verticales, de temáticas, de noticias y de agenda.
• Se identifican los elementos que componen estas tarjetas: Títulos, Bajadas, Etiquetas, Fechas de publicación, íconos, imagenes, alineacion del texto, contenedores, tamaño, grilla, etc.
• Se analiza el estado actual de las tarjetas en Figma.

Estado actual en Figma

Conclusión

• Se eliminan o renombran las tipologías de tarjetas actuales: "Tarjetas_de_eventos", "Tarjetas_horizontal_con_ícono", "Tarjetas_horizontal_con_imagen" y "estado_de_la_noticia"

• Se procede a armar el componente "tarjetas_temáticas" Estas tarjetas sólo se renderizan en la Home. Al ser tan particulares solo se disponibilizan las Propiedades: Dispositivo y Estado

• Se procede a armar el componente "tarjetas_horizontal" Se puso especial atención a que sea un componente controlado íntegramente por sus propiedades en Figma. Para todos los casos se arma tanto Desktop como Mobile. Para todos los casos se disponibilizan los estados "Predeterminado", "Sobre", "activo" y "en foco". Para todos los casos se ofrecen adaptaciones a una grilla de 6 columnas (desktop), 4 columnas (desktop) y 2 columnas (mobile). Para todos los casos se dispoibiliza la opción "Con borde" (Booleano: true/false). Para todos los casos se dispoibiliza la opción "Solo título" (Booleano: true/false). Se dividen en 3 grandes grupos: Predeterminada (Solo texto), Con ícono (grande o predeterminado) y Con imagen (Grande o predeterminada) A la vez se creó la propiedad "alineación" (arriba / centrada) para cuando están en contexto con otras tarjetas. Ejemplo de la necesidad de la propiedad "alineación: Arriba" Ejemplo de la necesidad de la propiedad "alineación: Centrada"

• Se procede a armar el componente "tarjetas_vertical" Se puso especial atención a que sea un componente controlado íntegramente por sus propiedades en Figma. Para todos los casos se arma tanto Desktop como Mobile. Para todos los casos se disponibilizan los estados "Predeterminado", "Sobre", "activo" y "en foco". Para todos los casos se ofrecen adaptaciones a una grilla de 6 columnas (desktop), 4 columnas (desktop) y 2 columnas (mobile). Para todos los casos se dispoibiliza la opción "Con borde" (Booleano: true/false). Para todos los casos se dispoibiliza la opción "Solo título" (Booleano: true/false). Se dividen en 2 grandes grupos: Con ícono (predeterminado) y Con imagen (predeterminada) No existe la opción "Solo texto" porque no habría diferencia con las horizontales.

• Se procede a armar el componente "tarjetas_noticias" Ejemplo con todas las propiedades activadas Ejemplo con la menor cantidad de propiedades activadas Se puso especial atención a que sea un componente controlado íntegramente por sus propiedades en Figma. Para todos los casos se arma tanto Desktop como Mobile. Para todos los casos se disponibilizan los estados "Predeterminado", "Sobre", "activo" y "en foco". Para todos los casos se ofrecen adaptaciones a una grilla de 6 columnas (desktop), 4 columnas (desktop) y 2 columnas (mobile). En esta tipología todas las variantes son "Con borde". Para todos los casos se dispoibiliza la opción "Solo título" (Booleano: true/false). Para todos los casos se dispoibiliza la opción "Etiquetas" (Booleano: true/false). Para todos los casos se dispoibiliza la opción "Fecha de publicación" (Booleano: true/false). Solo existe la opción "Con imagen". Se creó el componente "fecha de publicación" para dejar preparado el documento por si se quiere poner la fecha en otro formato. Ej: "DD/MM/AAAA" o "Tipo frase".

• Se procede a armar el componente "tarjetas_agenda" Ejemplo con todas las propiedades activadas Ejemplo con la menor cantidad de propiedades activadas Se puso especial atención a que sea un componente controlado íntegramente por sus propiedades en Figma. Para todos los casos se arma tanto Desktop como Mobile. Para todos los casos se disponibilizan los estados "Predeterminado", "Sobre", "activo" y "en foco". Para todos los casos se ofrecen adaptaciones a una grilla de 6 columnas (desktop), 4 columnas (desktop) y 2 columnas (mobile). En esta tipología todas las variantes son "Con borde". Para todos los casos se dispoibiliza la opción "Solo título" (Booleano: true/false). Para todos los casos se dispoibiliza la opción "Datos" (Booleano: true/false). Solo existe la opción "Con imagen". La fecha del evento es requisito en todas las tipologías (no se puede ocultar)

Oportunidades de mejora

• Eliminar la propiedad "Grilla" (ej: col-6, Col-4) y dejar el elemento en "Fixed" para que el diseñador pueda ajustarlo al tamaño deseado.
• Homologar con desarrollo el uso de los Headings (Se vuelve a H4?).
• Dejar solo la propiedad "alineación: Centrada" en los casos donde se usa solo título.
• Eliminar la propiedad "alineación: Arriba" en los casos donde se usa solo título.
• Revisar cómo escala el tamaño de la imagen en las tarjetas verticales (alinearse con desarrollo)
• El componente "Fecha de publicación" podría dejar de pertenecer a las tarjetas y gestionarse desde otro file más adecuado (Ej: Metadatos).
• Ajustar la paleta de colores de los estados sobre, en foco y activo. Matchearlo con el Storybook.
• Rever la arquitectura del componente "icono en caja". El tamaño corresponde al tamaño del ícono interno, no al total del elemento con contenedor.
• Rever la arquitectura del componente "icono tipo imagen". Confunde, quiza debería llamarse "imagen en caja". El tamaño corresponde al total del elemento con contenedor.
• Corregir algunos ejemplos en desarrollo con el título sobre la imagen (colocar link de referencia)
• Empatar nomenclatura de estilos de texto entre Desktop y Mobile (Ej: "Desktop/Cuerpo/grande · regular" vs. "Mobile/Párrafos/regular_16px")

Pendientes

• Actualizar Branch "Tarjetas" https://www.figma.com/file/ToGlPBzfp1gKDmaCwKWtXS/branch/17gEcCrmVlI5y1V3VXx8wj/UI-KIT---Obelisco?type=design con las posibles mejoras.
• Hacer review interna de Branch
• Actualizar Ficha de Tarjetas
• Mergear Branch a UI KIT
• Maquetar variantes de tarjetas que no existan.

[marusaad]

Se continúa avanzando con el componente de tarjetas según el requerimiento anterior:

Empatar todas las tipologías de tarjetas con Storybook (https://gcba.github.io/Obelisco/?path=/story/componentes-tarjetas-tipos--title-text-link) y agregar casos que no estén contemplados.

Se suma a este requerimiento el análisis de la branch de tarjetas para verificar la construcción de las cards y ver si es posible realizar modificaciones para que haya la menor cantidad de variantes posibles.

Análisis del componente

• Se realizó un benchmark del componente comparándolo con otros design systems.
• Se mapearon los usos del componente y sus variantes en la web de Buenos Aires.
• Se analizó la ficha previa del componente

Las principales conclusiones de este análisis fueron:

• Algunos tipos de tarjetas tienen un uso claro, pero la mayoría de las variantes de la tarjeta predeterminada, no. Salvo las tarjetas de temáticas, noticias, agenda y predeterminadas verticales con ícono en caja para páginas de área, no es posible establecer un patrón de uso recurrente y concreto. Este tema se abordará con mayor detalle cuando se trabajen las plantillas, viendo si es posible bajar lineamientos con respecto al uso.
• La tarjeta de "eventos" que tenía la ilustración del calendario de "Deportes BA" no se encontró dentro del mapeo de la web de Buenos Aires. La que sí aparece es la que está nomenclada en Storybook como "Evento simple", que no tiene la ilustración del calendario.
• La ficha puede prestarse a confusión para explicar la modulación de las tarjetas. Puede ser beneficioso dar menos opciones de organización (por ejemplo, hoy en día dependiendo de si la tarjeta tiene o no un borde se pueden apilar de a 3 ó 4 por fila) para reforzar un estándar único y minimizar las inconsistencias.
• Las tarjetas en Storybook y en la web utilizan etiquetas de información (de color azul), mientras que en el UI Kit se utilizan las predeterminadas (grises)

Análisis de la branch

• La branch presenta varias complicaciones a nivel constructivo. Se utilizan demasiadas variantes (500) que podrían resolverse con propiedades. También, se incluye el estado "activo" para la tarjeta, pero el componente no lo precisa.
• A su vez, se incluyen variantes de tarjetas no recomendadas (por ejemplo, tarjetas verticales al 50%) ya que su uso se pisa con el de destacado
• Es necesario conversar con el equipo de desarrollo acerca de las tarjetas de ancho variable que ocupan el 100% del contenedor disponible, ya que por esta propiedad encontramos en el mapeo tarjetas que ocupan 12 columnas.
• Existen dos variantes de tamaño de multimedia dentro de las tarjetas horizontales: con multimedia de 64x64 y con multimedia de 96x96. Rever si las de 96x96 se utilizan, porque no las vimos en el relevamiento, y ver si podríamos omitiarlas.
• Existe una variante de alineación superior o centrada que hoy se puede resolver con autolayout, por lo tanto se puede omitir esa variante.

La principal conclusión de este análisis fue:

• Es necesario volver a construir el componente de 0 utilizando master components, más propiedades, menos variantes y ajustando el autolayout

[marusaad]

Se comenzó la construcción del componente, dividido en las siguientes variantes

• Tarjetas verticales (incluye tarjeta de noticias, agenda y predeterminadas verticales)
• Tarjetas horizontales (incluye tarjeta de temáticas y predeterminadas horizontales)

Se incorporó una variante que tiene un CTA en forma de enlace. Se llevó a desarrollo para ver las posibilidades. Es necesario pensar bien el uso específico de esta variante, si no es relevante entonces se podría descartar. Se eliminó el estado activo. Se trabajó con variantes y propiedades booleanas.

Al día de hoy, el componente pasó de tener 500 variantes a tener 70 (aproximadamente)

Tarjetas verticales Componentes base: .Media_Vertical, .Contenido_Vertical

Tarjetas horizontales Componentes base: .Media_Horizontal, .Contenido_Horizontal

Cuestiones a seguir trabajando

• Nomenclatura de ancho: los valores de la propiedad "Ancho" son 25% (4-col), 50% (6-col) y 100% sólo para Mobile. Chequear cuál es la mejor forma de nombrar estas variantes.
• Accionable: chequear a nivel usabilidad y accesibilidad la incorporación del enlace como CTA a la tarjeta.

[marusaad]

Luego de reunirnos con Martín y el equipo de desarrollo para ver temas de accesibilidad, se decidió:

• Eliminar la variante Con enlace

A nivel de usabilidad, es recomendable que todas las tarjetas tengan el mismo comportamiento para generar familiaridad en la navegación en la persona usuaria. Además, no aporta mucha información que todas las tarjetas tengan el mismo enlace, por ejemplo “Leer más”.

A nivel accesibilidad, el lector de pantalla lee a las tarjetas moduladas como lista y las presenta a partir del nombre del enlace. Por lo que leería: “Conocé mas-Conocé más-Conocé más” . En caso de querer leer los títulos primero y luego en enlace, hay que agregar más etiquetas a la tarjeta a nivel desarrollo, y hoy en día para las necesidades que queremos cubrir, no es necesario.

• Cambiar la nomenclatura de la propiedad de ancho de las tarjetas horizontales

La nomenclatura que teníamos hasta el momento (Ancho: 25%, 50% y 100%) es confusa y es incorrecta, ya que no sería 25% sino 33,3% de la grilla de columnas de Obelisco.

Propusimos 2 alternativas para la nomenclatura: Ancho 4-col; 6-col; Mobile

Modulación 2 por línea; 3 por línea; Mobile

Consideramos que la mejor en este momento es la primera opción de ancho por columnas, ya que la propiedad "Modulación" puede ser confusa.

Además, continuamos el trabajo en la branch. Enviamos las tarjetas viejas a Análisis de componentes y comenzamos a rellenar la plantilla de documentación.

[marusaad]

Avanzamos con la elaboración de la ficha del componente. Queda para revisión @camilembo. Mañana podemos ver con Martín si agregar algo más para accesibilidad.

[marusaad]

Se actualizó la ficha con el apartado de accesibilidad. Ya está listo @camilembo

[Diehault]

¡Hola! 🐻‍❄️

Actualizamos el componente aprovechando la actualización general de la guía tipográfica. Encontramos evolutivos importantes para el componente que, si bien funciona como debe, hay cosas que se deberían ajustar.

¿Qué hicimos?

• Actualizamos los estilos tipográficos del componente Tarjeta horizontal y del componente Tarjeta vertical.
• Reorganizamos las propiedades de los componentes y la nomenclatura de las mismas.
• Cambiamos la iconografía que quedó fuera de versión por íconos de la librería de Material Design Icons.

¿Qué consideramos importante como evolutivos?

• Dentro del componente Tarjeta horizontal, para la variante de la tarjeta temática (que solo se encuentra en la página de inicio de la web de BA), deberíamos generar una nueva variante sobre el contenedor de información que se ajuste al uso y funcionamiento de este tipo de tarjetas. La variante temática de las tarjetas horizontales tiene la particularidad de que no comparte el mismo ancho máximo para el contenido interno de otras variantes, por lo que en la versión Mobile no se ajusta correctamente y recurrimos al uso de un contenedor Desktop para que funcione como debería. En este caso, tendríamos que evaluar crear otra variante de contenido, únicamente para las tarjetas temáticas, y evaluar cómo debe adaptarse en los diferentes tamaños.

¿Qué dejamos anotado en la página del componente en el UI kit?

¿Cómo se ve la página del componente en la librería del UI kit?

[Diehault]

📢 Nuevo requerimiento

Issues relacionados

311

Qué

Actualizar el componente según el nuevo estilo de grillas de la v.2 de Obelisco.

Por qué

Para estandarizar tamaños, modulación y visualizaciones de todos los componentes.

Quién lo va a trabajar

Diseñadores

Quién lo va a revisar

PM + SGOs

Criterios de aceptación

• [x] El componente se ajusta a la grilla 4px.
• [x] El componente tiene una medida definida para mobile, tablet y desktop.
• [x] El componente tiene una modulación definida para mobile, tablet y desktop.
• [x] El componente tiene su handoff para desarrollo y está marcado como ready for dev.
• [x] El componente está documentado.

🕰️ Changelog

CHANGELOG	Descripción
Agregado
Arreglado
Eliminado
Obsoleto
Cambiado	El width de la tarjeta vertical pasó a 348px, coincidiendo con 4 columnas de la grilla. El width de la tarjeta horizontal de 4 columnas pasó a 348px, coincidiendo con la grilla. El width de la tarjeta horizontal de 6 columnas pasó a 538px, coincidiendo con la grilla. El height del componente base .Media_Vertical pasó a 196px, para que coincidiera con la grilla de 4px y conservara el ratio de la imagen. El height de la tarjeta vertical cambió a 296px por defecto.

✏️ Notas

• No es necesario una variante tablet, porque en producción el componente sigue el comportamiento de un contenedor mayor y responde al tamaño de la pantalla.

[marusaad]

📢 Nuevo requerimiento

Issues relacionados

300

Qué

Actualizar los estilos de color del componente aplicando las variables correspondientes a la v2 de Obelisco.

Por qué

Porque posiciona al sistema en un nivel de calidad superior al cumplir con los criterios de accesibilidad de la WCAG, y facilita la adopción, la personalización y la escalabilidad a nivel global.

Quién lo va a trabajar

Diseñadores

Quién lo va a revisar

PM + SGOs

Criterios de aceptación

• [x] El componente aplica las variables semánticas y funcionales para los elementos del mismo.
• [x] El componente cumple con los criterios de contraste y legibilidad de la WCAG (Criterios de accesibilidad AAA)

🕰️ Changelog

CHANGELOG	Descripción
Agregado	Se añadió el borde del contenedor de la tarjeta debido a que el único uso es en la home de NBA.
Arreglado
Eliminado
Obsoleto
Cambiado	Actualizamos el color para los estados en Hover, utilizando la variable $hover, que aplica tanto al border del componente como también al título teniendo en cuenta que los Enlaces en el componente Tarjetas varía su comportamiento con respecto al mismo. Actualizamos el color para los estados Focused, utilizando a variable $focused, que aplica al border del contenedor del componente, así como también al contenedor del título en las variantes de tarjetas sin borde.

✏️ Notas

N/A.