You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
En la imagen que se muestra en la parte inferior se muestra el uso de un feedback screen dentro de un responsive layout con un background en toda la página que es diferente al default, al tener los feedback full screen el background seteado, ocurre esta disonancia entre el fondo y el background del feedback:
Solución preliminar
En una primera instancia se planteo la siguiente solución:
Se creará una versión del error que no sea full page y su fondo sea transparente, de manera que independientemente del fondo en el que vaya colocado (Sea default o alternative), este elemento debería funcionar.
Esta solución respondía a la pregunta: Qué se puede considerar full page?
En este caso al llevar la pagina otro contenido además de el error y contemplando esta casuística de manera global, en aquellas situaciones en las que un error de carga de contenido venía precedido de una navegación secundaria o filtrado (e.g. unas tabs). No podía considerarse full page.
En la PR además se levanta otra problemática: actualmente no se está utilizando el feedback error, sino que se está usando un feedback genérico. En este caso se considera que en vez de usar el feedback genérico es recomendable el uso del feedback info para los casos en los que el error no es crítico.
Esto haría necesario ampliar la definición de este error feedback "inline" a la variante de info también.
Contexto y variante
Podemos hacer una distinción muy a alto nivel de cómo se dividen los componentes en mística con respecto las variables de contexto y variante:
Componentes que tienen variantes
Componentes que beben del contexto
Los componentes que tienen variantes están principalmente pensandos para ir full screen (donde caería el errorFeedbackScreen), otros ejemplos son el hero o el header. Independientemente del contexto ellos deciden como pintan su background.
Existen sin embargo casos que si setean su variante como es el caso de las highlighted o de las displayData. Estos elementos utilizan ese recurso para resaltar sobre otros elementos de la misma jerarquía, recurso que no aplica en este contexto.
Anatomia de un componente full page
En el caso además de estos componentes full page. Su anatomía ya incluye que la lógica de espaciados de su contenedor con respecto a los límites del viewport se comporte de una manera correcta y se considera incorrecto incluir estos componentes dentro de otro responsiveLayout ya que es redundante.
En algunos componentes esta condición fullPage sólo se da en el eje x (por ejemplo un header) donde se contempla que vayan a fullWidth y convivan con otros componentes en el eje vertical. En el caso particular de los feedbackScreen, su planteamiento no solo contempla el fullWidth sino también el fullHeight, no contemplando convivir con ningún otro componente más allá de navbar y tabBar.
Variantes incompatibles
Existen posibles casos de uso que no acaban de encajar con esta definición inline. El mas preocupante son las pantallas donde el contexto sea inverse. Ya que no se considera una variación válida que un feedback error pueda ir sobre un contexto inverse. Esta presentación es única y exclusiva del feedback success.
El motivo fundamental de esta incompatibilidad es que la connotación que otorga el color del icono de error se pierde cuando va incluido en un color brand.
Alineamiento con los empty states
Actualmente los empty states no tienen una variante full page sino que están pensados para ir inline con el contenido.
En este caso podría asumirse que la creación de una variante inline de los empty error e info alinearía las definiciones de estos dos componentes. Sin embargo, tal y como se indica en el punto anterior, los empty states carecen de la necesidad de generar una connotación a través del color. Por tanto potencialmente pueden funcionar sobre cualquier tipo de background sobre el que se los coloque.
Por poner un ejemplo, un empty sobre inverse no cambiaría su connotación, un error en la misma casuística si lo haría.
Conclusión
Enlazando todos los punto anteriores, se considera que la creación de un componente feedbackError (o success) card resuelve todo lo citado anteriormente.
No pierde la connotación de color en función del contexto en el que vaya incluida
No incluye su propia lógica de espaciado con el viewport por lo que se comportará bien en aquellos escenarios donde se incluye dentro de un ResponsiveLayout
Resuelve otro de los casos que se plantea en: ErrorFeedbackCard #1449 donde surge la necesidad de mostrar un feedback de error en un módulo concreto y no sobre todo el contenido de la página.
Se habilitará la variante info también para esta feedbackCard para dar salida a los errores que no se consideran los suficientemente críticos como para mostrar un error.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Contexto
En la imagen que se muestra en la parte inferior se muestra el uso de un feedback screen dentro de un responsive layout con un background en toda la página que es diferente al default, al tener los feedback full screen el background seteado, ocurre esta disonancia entre el fondo y el background del feedback:
Solución preliminar
En una primera instancia se planteo la siguiente solución:
Se creará una versión del error que no sea full page y su fondo sea transparente, de manera que independientemente del fondo en el que vaya colocado (Sea default o alternative), este elemento debería funcionar.
Esta solución respondía a la pregunta: Qué se puede considerar full page?
En este caso al llevar la pagina otro contenido además de el error y contemplando esta casuística de manera global, en aquellas situaciones en las que un error de carga de contenido venía precedido de una navegación secundaria o filtrado (e.g. unas tabs). No podía considerarse full page.
En la PR además se levanta otra problemática: actualmente no se está utilizando el feedback error, sino que se está usando un feedback genérico. En este caso se considera que en vez de usar el feedback genérico es recomendable el uso del feedback info para los casos en los que el error no es crítico.
Esto haría necesario ampliar la definición de este error feedback "inline" a la variante de info también.
Contexto y variante
Podemos hacer una distinción muy a alto nivel de cómo se dividen los componentes en mística con respecto las variables de contexto y variante:
Los componentes que tienen variantes están principalmente pensandos para ir full screen (donde caería el errorFeedbackScreen), otros ejemplos son el hero o el header. Independientemente del contexto ellos deciden como pintan su background.
Existen sin embargo casos que si setean su variante como es el caso de las highlighted o de las displayData. Estos elementos utilizan ese recurso para resaltar sobre otros elementos de la misma jerarquía, recurso que no aplica en este contexto.
Anatomia de un componente full page
En el caso además de estos componentes full page. Su anatomía ya incluye que la lógica de espaciados de su contenedor con respecto a los límites del viewport se comporte de una manera correcta y se considera incorrecto incluir estos componentes dentro de otro
responsiveLayoutya que es redundante.En algunos componentes esta condición fullPage sólo se da en el eje x (por ejemplo un header) donde se contempla que vayan a
fullWidthy convivan con otros componentes en el eje vertical. En el caso particular de losfeedbackScreen, su planteamiento no solo contempla elfullWidthsino también elfullHeight, no contemplando convivir con ningún otro componente más allá denavbarytabBar.Variantes incompatibles
Existen posibles casos de uso que no acaban de encajar con esta definición inline. El mas preocupante son las pantallas donde el contexto sea inverse. Ya que no se considera una variación válida que un feedback error pueda ir sobre un contexto inverse. Esta presentación es única y exclusiva del feedback success.
El motivo fundamental de esta incompatibilidad es que la connotación que otorga el color del icono de error se pierde cuando va incluido en un color brand.
Alineamiento con los empty states
Actualmente los empty states no tienen una variante full page sino que están pensados para ir inline con el contenido.
En este caso podría asumirse que la creación de una variante inline de los empty error e info alinearía las definiciones de estos dos componentes. Sin embargo, tal y como se indica en el punto anterior, los empty states carecen de la necesidad de generar una connotación a través del color. Por tanto potencialmente pueden funcionar sobre cualquier tipo de background sobre el que se los coloque.
Por poner un ejemplo, un empty sobre inverse no cambiaría su connotación, un error en la misma casuística si lo haría.
Conclusión
Enlazando todos los punto anteriores, se considera que la creación de un componente feedbackError (o success) card resuelve todo lo citado anteriormente.
ResponsiveLayoutfeedbackCardpara dar salida a los errores que no se consideran los suficientemente críticos como para mostrar un error.Ejemplo de card sobre contextos default / inverse
Beta Was this translation helpful? Give feedback.
All reactions