@sapallie , ¿podría hacer que las maquetas de diseño sean accesibles públicamente? A menos que no se compartan en este momento.

Actualmente estoy desarrollando XAML y me encantaría ver algo como esto. O algo así como un buen control de desplazamiento de mensajes.

Desde el punto de vista de la marca de Microsoft, un banner de error estandarizado parece que podría salir terriblemente mal. Temería que los usuarios finales asocien cada error de aplicación con la marca Microsoft. Acabo de leer la propuesta, y lo primero que me vino a la mente fue memelords tuiteando sobre el llamativo estandarte de la muerte.

@sapallie , ¿podría hacer que las maquetas de diseño sean accesibles públicamente? A menos que no se compartan en este momento.

Lo siento @adrientetar , todavía no puedo compartirlos. Los diseños son solo de Microsoft por ahora.

@sapallie , ¡gracias por esta idea de función fenomenal! ¡Soy gerente de programa para WinUI y estoy emocionado de presentar esto al equipo!

Quería escribir un poco sobre nuestro proceso para que puedan estar en sintonía con la forma en que procederemos a partir de aquí. A partir de ahora, trabajaré para refinar el alcance/los requisitos de alto nivel de esta propuesta y la justificación del desarrollo. Luego se lo presentaré al resto del equipo de WinUI y deliberaremos sobre si se alinea con nuestra hoja de ruta (#717) y si creemos que podemos actuar relativamente pronto. Si es así, se me aprobará para averiguar los detalles y comenzar a escribir las especificaciones para que la función esté lista para un desarrollador.

Aquí hay algunas cosas que ya sé para las que necesito tener una idea un poco más...

• Comportamiento visual

¿Su propuesta es de borde a banner? ¿O un mosaico de notificación como lo que hacen las Notificaciones de Windows pero en la ventana de la aplicación, como en el centro, a lo largo del borde inferior o en una esquina?

Lo siento @adrientetar , todavía no puedo compartirlos. Los diseños son solo de Microsoft por ahora.

No creo que pueda obtener la aprobación de esta propuesta sin poder incluir una imagen pública de la solicitud, ya que el repositorio es de código abierto y el lado visual de la conversación se enredaría en el proceso y la experiencia de nuestra comunidad. . En base a las respuestas a lo anterior, me complace intentar redactar una maqueta para la propuesta. ¿Preferirías esto o tienes un cronograma previsto para otorgar tu permiso para hacer público tu diseño? Me encanta su maqueta y estaría ansioso por incluirla en nuestra lluvia de ideas aquí para que no llevemos la discusión innecesariamente en una dirección diferente a su intención. ¡Por favor hagamelo saber! :sonrojo:

El banner informará a los usuarios sobre los errores que les impiden usar una aplicación/función

El banner se podrá descartar por errores no críticos.

¿Estoy en lo cierto al leer estas declaraciones en el sentido de que también debe tener la opción de un banner no descartable para errores críticos? Si es así, ¿podría darme más información sobre el escenario específico de su aplicación para recibir uno/proceder desde el punto de tener un banner no descartable? ¿Están los usuarios relegados a cerrar la aplicación a menos que se resuelva el problema? ¿O es aquí donde vendrían los botones para, por ejemplo, navegarlos a la página de configuración de Red e Internet?

¡Gracias de nuevo y espero refinar esta idea!

¡Todos, siéntanse animados a contribuir con sus necesidades, diseños y perspectivas a esta conversación! :sonrojo:

Me gustaría decir que hay algunas propuestas que piden algo similar. En lugar de hacer que esto sea específicamente un banner de error, ¿por qué no traer la notificación en la aplicación del kit de herramientas de la comunidad? Podría agregarse una propiedad de icono, lo que haría que mostrara un icono de error o un icono de confirmación, etc.

@SavoySchuler : es bueno saber de usted. Traté de responder a todas sus preguntas, pero avíseme si necesita algo más.

Comportamiento visual:
Idealmente, el banner sería similar a un mosaico de Notificación de Windows y estaría anclado en la parte superior o inferior de la ventana de la aplicación. El lugar donde se fija depende de los otros elementos visuales de la aplicación y de dónde se encuentra el foco. Esta decisión debe ser tomada por un diseñador.
Creo que el GIF que publicó @mdtauk sería un excelente punto de partida.

Despedir:
Creo que tendría sentido profundizar en lo que quiero decir con errores críticos frente a errores no críticos:

• Errores críticos = la funcionalidad de la aplicación se ve afectada debido a un problema en todo el sistema (por ejemplo, se perdió la conexión a Internet); estos deben vincularse a la configuración del sistema donde el usuario puede solucionar el problema
• Errores no críticos = parte de la funcionalidad está dañada o una sola función no funciona, pero los usuarios aún pueden hacer otras cosas en la aplicación
• También sería genial presentar una iteración puramente informativa del banner que se pueda usar para que los usuarios sepan que hay actualizaciones de aplicaciones o nuevas funciones disponibles.

Y creo que todos estos deberían descartarse (también actualicé eso en la descripción de la propuesta)

Imágenes de ejemplo
Hice algunos cambios en las imágenes y puedo compartirlos así:

Estos ejemplos son una iteración en la que todo el banner es básicamente un botón grande. Los usuarios pueden descartarlo o hacer clic en él para ir a la configuración del sistema (error crítico), abrir una página web con detalles sobre correcciones de funciones (advertencia 1), volver a cargar la página de la aplicación (advertencia 2) o ir a la tienda de Microsoft para actualizar la aplicación (informativo).
Sería posible expandir este concepto para agregar múltiples botones dentro del banner.

Realmente me gustan esas imágenes para el banner. Movería el texto y el ícono 4 px hacia arriba, para que estén centrados en el área blanca, en lugar de la barra blanca y de color.

Acordado. Las imágenes publicadas se ven bastante bien.

Realmente me gustan esas imágenes para el banner. Movería el texto y el ícono 4 px hacia arriba, para que estén centrados en el área blanca, en lugar de la barra blanca y de color.

No he contado los píxeles, pero parece que están centrados si se tiene en cuenta el espacio para los signos diacríticos por encima de la altura de la X.

@sapallie ¿Ha pensado en permitir que estos controles se descarten automáticamente o mediante programación?

Si se le solicita estar/desconectarse, tendría sentido eliminar mediante programación dicho mensaje cuando vuelva a estar en línea. (He visto aplicaciones que no hacen esto y puede generar una experiencia confusa).

Del mismo modo, tener mensajes no esenciales que no se muestren indefinidamente puede evitar el desorden innecesario de la interfaz de usuario y puede evitar que los usuarios avanzados necesiten salir del flujo una vez que hayan leído un mensaje al no obligarlos a descartar manualmente la notificación.

Entiendo que existen posibles consideraciones adicionales de accesibilidad en torno a dicho control y estos comportamientos, pero creo que estas formas de descartar el control son esenciales.

Creo que es importante señalar que dicho control no está diseñado para mensajes generales dentro de una aplicación. A menos que realmente sea un caso de uso deseado.

¿Se debe permitir que una aplicación muestre varios banners a la vez?
Si es así, ¿cómo se organizarán? ¿Y es esto algo que la aplicación puede controlar?

Esto satisfaría a aquellos que han solicitado un estilo Android Toast en el control de notificaciones de la aplicación, también podría ser útil para escenarios de validación, para mostrar texto de error donde el espacio en el formulario es escaso.

También lo llamaría algo como StatusTip o StatusNotification para que no solo se asocie con usos negativos.

Supongo que el diseño se adaptaría cambiando la ubicación en la barra de color sólido cuando se coloca en la parte inferior de la ventana.

Probablemente debería tener una propiedad de tiempo de espera, e incluso podría tener la capacidad de mostrar un mensaje pendiente, como un anillo de progreso y algún texto como "Iniciar sesión ahora" antes de cambiar a un mensaje de confirmación de error.

Realmente me gustan esas imágenes para el banner. Movería el texto y el ícono 4 px hacia arriba, para que estén centrados en el área blanca, en lugar de la barra blanca y de color.

No he contado los píxeles, pero parece que están centrados si se tiene en cuenta el espacio para los signos diacríticos por encima de la altura de la X.

Creo que era más probable que el texto estuviera centrado verticalmente en el recuadro sin tener en cuenta la barra de color

Así es como la ubicación de la barra de color podría cambiar con la ubicación del control

@mrlacey sí, el despido programático/automático para cuando el banner ya no es relevante es bastante importante; lo agregué a la descripción de la propuesta.

Cambios de estado y errores: para eso se deben usar los banners. No es un mensaje general, estoy de acuerdo con eso.

Y creo que varios banners deberían funcionar. Solo deben apilarse.

@mdtauk Le cambié el nombre a "Banner de estado". Gracias por sus sugerencias.

Para el estado de carga, no creo que eso deba suceder en el banner. La carga de contenido debe mostrarse en la aplicación donde realmente aparecería el contenido.

Y cuando se trata de cambiar la ubicación de la barra de color, sería genial tener la flexibilidad allí dependiendo de dónde se coloque el banner de error en la ventana de la aplicación. 👍

Los problemas #622 y #792 también podrían cubrirse con este control, si se construyera.

@sapallie Su nota sobre las circunstancias de error crítico es interesante con respecto a la orientación sugerida de que los banners de estado señalan al usuario una solución. Mi intuición dice que también puede necesitar una API para deshabilitar, o al menos descartar temporalmente.

Entiendo que existen posibles consideraciones adicionales de accesibilidad en torno a dicho control y estos comportamientos, pero creo que estas formas de descartar el control son esenciales.

@mrlacey , gran convocatoria! Afortunadamente, he trabajado en una parte significativa de esto durante la consideración del cierre automático programado en TeachingTip, y aunque sería necesario asociarse con equipos que poseen configuraciones de accesibilidad propias, no creo que esta función se bloquee debido a problemas de accesibilidad. ¡+1 en todos tus otros puntos!

¿Podría existir la posibilidad de agregar un HyperlinkButton que vincule a una solución o a un acceso directo de configuración, como Redes?

¿Podría existir la posibilidad de agregar un HyperlinkButton que vincule a una solución o a un acceso directo de configuración, como Redes?

Estaba imaginando el subtexto que contenía un hipervínculo a una página en la aplicación o aplicación de configuración (consulte el código de la galería de Xaml Control de TeachingTip). ¿Estabas pensando en algo más estandarizado @mdtauk?

@SavoySchuler ¿ Propiedad de contenido en lugar de MessageText?

Su nota sobre las circunstancias de error crítico es interesante con respecto a la orientación sugerida de que los banners de estado señalan al usuario una solución. Mi intuición dice que también puede necesitar una API para deshabilitar, o al menos descartar temporalmente.

Sí, posiblemente supongo... Definitivamente no está de más agregarlo. Agrega flexibilidad después de todo y probablemente será bastante útil para algunos casos de uso.

@mdtauk - ¡Sí, ciertamente me refiero a la propiedad del contenido!

@sapallie

Su nota sobre las circunstancias de error crítico es interesante con respecto a la orientación sugerida de que los banners de estado señalan al usuario una solución. Mi intuición dice que también puede necesitar una API para deshabilitar, o al menos descartar temporalmente.

Sí, posiblemente supongo... Definitivamente no está de más agregarlo. Agrega flexibilidad después de todo y probablemente será bastante útil para algunos casos de uso.

Por un lado, tiene una ventana emergente no descartable que cubre la interfaz de usuario (y posiblemente causa su propio error basado en el escenario al hacerlo) y, por otro lado, tiene una advertencia de aplicación/error crítico que no es persistente, lo que también hace mis sentidos arácnidos hormiguean.

Tal vez, en lugar de una ventana emergente sobre la interfaz de usuario + estilo tip, ¿una interfaz de usuario + un banner de borde a borde (como el que usa Office Suite para notificar sobre actualizaciones, consulte a continuación) satisfaría las necesidades y al mismo tiempo proporcionado espacio persistente en su interfaz de usuario?

@SavoySchuler Podría haber un comportamiento en el control, donde coloca el encabezado y el contenido en una sola línea, si el ancho del control es lo suficientemente amplio.

Mi sugerencia anterior con los diferentes diseños de posicionamiento también funcionaría si el control se desliza desde el borde de otro control, no solo dentro de la ventana o el panel.

Tal vez, en lugar de una ventana emergente sobre la interfaz de usuario + estilo tip, ¿una interfaz de usuario + un banner de borde a borde (como el que usa Office Suite para notificar sobre actualizaciones, consulte a continuación) satisfaría las necesidades y al mismo tiempo proporcionado espacio persistente en su interfaz de usuario?

Sí, eso también funciona. 👍

Parece que sería ideal tener opciones en línea y superpuestas ya que, en retrospectiva, Office Suite puede confiar en que todas sus aplicaciones tienen una cinta. @mdtauk Me gusta su sugerencia que está comenzando a insinuar cómo pensamos sobre el comportamiento de aparición/desaparición.

@all , ¿alguien puede compartir conmigo escenarios específicos en sus aplicaciones reales donde imagina que se usa este control? Específicamente, me interesan las ideas sobre la entrada visual y la interacción del usuario requerida para provocar el despido. ¿Cubren los requisitos aquí los comportamientos principales que necesita de este control?

@SavoySchuler Teniendo en cuenta la entrada y la salida, podría deslizarse desde un borde, pero también animarse como una superposición flotante si el desarrollador lo elige. Deslizarse desde el borde derecho de la pantalla a nivel del sistema operativo: desde el borde derecho de la ventana de una aplicación o desde el borde de un control o elemento de la interfaz de usuario.

Hay un botón de cierre para el despido, pero para las pantallas táctiles, la capacidad de deslizarlo en la dirección opuesta a la que surgió también podría funcionar. Para garantizar la consistencia, esto debe integrarse en el control.

Tocar el control probablemente debería desencadenar una acción que especificaría el texto del mensaje.
La excepción sería para mostrar el progreso de una acción que no se descartaría hasta que se agote el tiempo con un error o se complete con éxito.

Ejemplos animados

Entrar, Actualizar, Salir - Enlace de YouTube

Animar en - Enlace de YouTube

TeachingTip existe y es una buena manera de apuntar a un control específico o elemento de la interfaz de usuario, y es bueno para resaltar una nueva función en una aplicación. Técnicamente, podría usarse para los mismos propósitos que este StatusBanner, por lo que es necesario reflexionar sobre el uso semántico de cada uno de estos e identificar qué hace que cada uno sea único.

A continuación, se encuentran mis pensamientos personales sobre la diferenciación entre el Banner de estado y el Consejo de enseñanza.

• El banner de estado _Creo_ debe recomendarse para los estados procesables reales y, por lo tanto, debe invocar una sola acción cuando se toca.

  • La sugerencia de enseñanza presentaría acciones como un botón o un hipervínculo, que generalmente se usa para información que se puede descartar fácilmente.

• Cuando una aplicación o la condición del sistema operativo cambia, eso es necesario para la aplicación, entonces eso debería activar la visualización de un Banner de estado.

  • La sugerencia de enseñanza no proporcionaría información crítica y, una vez descartada, no se volvería a mostrar a menos que se agregue algo nuevo para llamarlo.

• El banner de estado debe persistir cuando se muestra, a menos que se descarte con el botón Cerrar, o tal vez un deslizamiento cuando esté en contacto. Con la excepción de que se complete un escenario de progreso continuo o se resuelva el estado del sistema operativo (se restablece la red).

  • La sugerencia de enseñanza posiblemente incluiría una función de tiempo de espera, no se mostraría aleatoriamente mientras se ejecuta la aplicación, se mostraría principalmente al iniciar la aplicación o al navegar a una página/pantalla.

• El banner de estado debe usarse en el shell del sistema operativo de manera coherente; podría haber un conjunto de banners localizados estándar con contenido, íconos, colores, como una enumeración.

• Podría haber alguna lógica del sistema operativo para agregar banners de estado a las ventanas de la aplicación.
  Por ejemplo, cuando una aplicación intenta acceder a la red y no está disponible, el sistema operativo podría mostrar un banner de estado estándar dentro de la ventana de la aplicación, en lugar de en el espacio de la pantalla, o dejar que los desarrolladores lo implementen.

  • La sugerencia de enseñanza sería específica de la aplicación, sin contenido estándar definido, y solo para que la incluya el desarrollador.

@mdtauk , ¡un trabajo fantástico en los videos! 🎉 Son más que útiles para dar vida a estas ideas.

La necesidad de persistencia es un punto excelente y creo que la función de descartar también podría mitigarse con Pautas que sugieran hacer que las notificaciones de estado estén disponibles de forma persistente en un panel de notificación si son críticas o, _posiblemente, volver a aparecer en intervalos no invasivos si los problemas persisten. Estas no son afirmaciones definitivas, solo puntos de consideración para garantizar que esta solución sea adecuadamente integral en su solución de escenario.

La necesidad de distinguir TeachingTip de esta función es acertada y estoy de acuerdo con sus puntos. Este control satisfaría una necesidad distinta que TeachingTip no fue diseñado para resolver, aunque puede haber oportunidades para algunas características o código compartidos.

¿Hay partes interesadas que no verían satisfechas sus necesidades con algo como lo que @mdtauk ha compartido anteriormente?

Parece haber diferencias entre los Banners de estado simulados en el OP y la notificación de ancho completo como se ve en Office (imágenes de arriba en comentarios anteriores) o Visual Studio (como se muestra a continuación)

Las diferencias entre los dos significan que me pregunto si deberían ser el mismo control o separados.

Aquí hay una lista rápida de propiedades que cada uno necesitaría. (nombres, por ejemplo, no fijos pero destinados a inferir significado)

Banderas de estado

• _Icono_
• Mensaje de texto
• Texto adicional (segunda línea)
• Tipo (crítico, advertencia o información)
• Color
• Ubicación
• Dirección de Animación
• Toque Evento/Comando
• Se acabó el tiempo

Notificaciones de ancho completo

• _Icono (posiblemente)_
• Mensaje de texto
• Estilo de enlace (botón o hipervínculo)
• Enlaces (texto y toque evento/comando - múltiples)
• Se acabó el tiempo

Solo las propiedades en negrita existen en ambos. _Icono_ es potencialmente confuso ya que se necesitan diferentes tipos de íconos (en un círculo o contorno) para cada tipo.
También tendría que haber una propiedad para indicar qué estilo usar.

Para mí, parece que hay demasiada diferencia para un solo control y juntar todas estas funciones sería confuso y complicado.
Creo que estos dos conceptos:

• un banner descartable de ancho completo con cero o más subelementos procesables
• un banner destinado a indicar cambios de estado y que funciona como un solo botón

proporcionará el mayor valor y la menor confusión como controles separados.

¿Cómo admitirían los banners de estado animados la visualización de varias notificaciones a la vez?
¿O esto ahora está fuera del alcance?

• El banner de estado debe usarse en el shell del sistema operativo de manera coherente; podría haber un conjunto de banners localizados estándar con contenido, íconos, colores, como una enumeración.
• Podría haber alguna lógica del sistema operativo para agregar banners de estado a las ventanas de la aplicación.
  Por ejemplo, cuando una aplicación intenta acceder a la red y no está disponible, el sistema operativo podría mostrar un banner de estado estándar dentro de la ventana de la aplicación, en lugar de en el espacio de la pantalla, o dejar que los desarrolladores lo implementen.

Este nivel de integración del sistema operativo muestra ambición más allá de un solo control y más allá de WinUI.

¿Los "banners estándar localizados" serían todo lo que estaría disponible o serían además de poder tener algo totalmente personalizable?
Si proporciona algunos por defecto, ¿cuáles serán?
Me preocuparía que solo proporcionar un conjunto limitado de opciones limitaría innecesariamente el potencial de dicho control.

Hacer que el sistema operativo muestre pancartas en la aplicación abierta para escenarios de todo el sistema, como la pérdida de conectividad de red, me genera una serie de preocupaciones.

• El centro de acción ya proporciona una forma de proporcionar notificaciones en todo el sistema.
• Con múltiples ventanas abiertas, ver pancartas en cada una parece innecesariamente intrusivo.
• Hacer que el sistema muestre notificaciones (banners) dentro de una aplicación es algo que esperaría que los desarrolladores quisieran controlar o deshabilitar.
• Si una aplicación solo necesita una conexión de red ocasionalmente, ver un aviso sobre una pérdida de conexión podría ser desconcertante o distraer al usuario si no es relevante para lo que está haciendo actualmente.
• Esto vincularía las aplicaciones a versiones específicas del sistema operativo para obtener actualizaciones o el comportamiento deseado. Un cambio futuro en la función del sistema operativo podría romper o cambiar una aplicación de forma no deseada.
• Las actualizaciones y las correcciones de errores solo estarían disponibles en los calendarios de lanzamiento a nivel del sistema operativo. Parte de la razón detrás de la existencia de WinUI es romper ese vínculo con el sistema operativo y la funcionalidad de la aplicación.

• Uno de los objetivos de un control como el que se describe aquí es facilitar la implementación a los desarrolladores. Eliminar su capacidad para controlarlo causaría problemas para las aplicaciones en las que los escenarios específicos deben manejarse de manera personalizada.

Acabo de encontrar este problema en la publicación de Twitter sobre las maquetas animadas. Parece superponerse a mucho del trabajo que hemos realizado con el control InAppNotification en el kit de herramientas. Incluyendo cosas como cómo se manejan múltiples mensajes.

Hemos aprendido que si bien esto parece un control simple, es bastante complejo. Sin embargo, sería bueno tener una solución holística que pueda integrarse en WinUI para cubrir todos estos casos. Entonces podemos desaprobar el control del kit de herramientas.

Hablando con @ryandemopoulos , y quiero refactorizar un poco esta conversación inicial para centrarme en el problema (necesidad de una interfaz de usuario de error) antes de la solución (cualquier pieza específica de la interfaz de usuario de error).

Con este fin, mi primer objetivo es bloquear los escenarios y los requisitos para la interfaz de usuario de error ( @sapallie , su escenario "Crítico: pérdida de conectividad wifi" es un comienzo perfecto). A partir de ahí, podemos trabajar juntos para decidir si la solución incluye una parte de la interfaz de usuario de notificación de error o un conjunto de componentes de interfaz de usuario de error. A partir de lo cual, ampliaremos el desglose de similitudes de API de @mrlacey (gracias por comenzar esto) para decidir si hay suficientes puntos en común para un enfoque de derivación frente a controles distintos si hay varios resultados de esta conversación. No quiero adelantarme, pero el argumento de @mrlacey para soluciones distintas _ya_ se ve nítido y está bien. Mi enfoque es crear el conjunto correcto de piezas de solución para todos aquí.

Entonces, para cualquiera ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk y @mrlacey) para quien este control sea particularmente relevante, ¿podría proporcionarme lo siguiente aquí o enviarme un mensaje directo a @ saschule @microsoft.com :

• título de la aplicación
• Descripción del escenario (error, crítico/no crítico y descripción de cómo le gustaría presentarlo)
• Captura de pantalla de la pantalla de la aplicación donde se presentaría el error (si está disponible)

He actualizado el Problema para reflejar este enfoque centrado en el problema y he catalogado los requisitos, los escenarios y las posibilidades de solución descritos hasta ahora.

@sapallie Traté de ser cortés como pude al preservar su trabajo inicial. El historial de versiones se puede ver en el menú desplegable "editado por..." en la parte superior de la edición. Por favor, avíseme si no capturé algo correctamente.

Le presenté esto al equipo de WinUI y creemos que la funcionalidad definida aquí sería capaz de mostrar no solo mensajes de error, sino también mensajes de estado de toda la aplicación de larga duración en su conjunto. Esto incluye mensajes de estado del tipo "actualización disponible" y "copia de seguridad completa", además de escenarios específicos de error.

He actualizado el número para reflejar este enfoque más holístico. Espero finalizar los requisitos y los escenarios en las próximas semanas para que podamos examinar las piezas de salida de la interfaz de usuario necesarias para mostrar estos mensajes.

Voy a reformular mi solicitud anterior. @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk y @mrlacey , para los mensajes de estado/error que desea mostrar en sus aplicaciones, ¿podría proporcionarme lo siguiente aquí o en [email protected] ?

• título de la aplicación
• Descripción del escenario (mensaje de estado, crítico/no crítico y descripción de cómo le gustaría presentarlo)
• Captura de pantalla de la pantalla de la aplicación donde se presentaría el error (si está disponible)

Vale la pena señalar que, en mi opinión, los cuadros de diálogo emergentes deben evitarse si es posible. La web está llena de mensajes emergentes en todas partes e interrumpen el flujo tratando de llamar su atención. Por ejemplo, creo que se debe preferir el estado vacío ( ejemplo ), por ejemplo, si algo no se puede cargar en un control.

Con respecto a las imágenes publicadas por @mdtauk , ¿realmente necesitamos ventanas emergentes que se muestren desde los cuatro bordes de la pantalla/aplicación? El objetivo de WinUI debería ser estandarizar la posición y el aspecto de dichos elementos para que todas las aplicaciones usen lo mismo y, en ese sentido, Android Snackbar es una referencia obvia. Otra cosa a tener en cuenta con Snackbar es que no muestra errores con un color rojo brillante ni nada, tiene una apariencia sobria que creo que nuevamente es beneficiosa para no distraer demasiado al usuario de lo que está haciendo.

También necesitaremos orientación sobre cuándo usar esta ventana emergente en lugar de un cuadro de diálogo, por ejemplo, de lo contrario, solo creará fragmentación (diferentes aplicaciones que usan los controles de mensajería de diferentes maneras).

Los controles flotantes tienen un concepto de ubicación, este control podría hacer lo mismo. Aparece desde el borde interior de un control contenedor, ya sea una página o un contenido de pestaña, etc.

@adrientetar No todas las aplicaciones son iguales, por lo que aunque habrá un valor predeterminado para este control, debe haber una manera para que los desarrolladores cambien esta ubicación, sin tener que volver a crear una plantilla o rediseñar el control.

Office usa el espacio debajo de la cinta. Edge usa la parte inferior de la pantalla. Solo el propio Windows podría adjuntarlo a los bordes de Shell o Screen, y probablemente haya una buena razón para evitar que las aplicaciones imiten las alertas de nivel del sistema.

Además, cualquier desarrollador tiene la capacidad de cambiar el estilo de sus propios controles de alerta, por lo que en esta etapa, debe ser lo más flexible posible, y luego el equipo de Shell tendrá algo que decir sobre las restricciones que se aplican al uso del control.

El equipo de Your Phone tiene uno de estos tipos de controles, por lo que tal vez podría preguntarles qué problemas encontraron y persuadirlos para que usen el control WinUI cuando esté listo e incluido.

Dropbox también usa Snackbar en su sistema de diseño (desplácese hacia abajo, de la segunda a la última fila de imágenes).

Recientemente detecté un par de ejemplos más de mensajes de estado de larga duración en toda la aplicación:

(mensaje de "grabación iniciada" en Teams)

("intentando conectarse con el coordinador del juego" en Dota 2)

Lo siento, son pequeñas: la primera imagen se tomó de mi escritorio con un monitor ultra ancho. :)

Algunos snackbars de Dropbox contienen una barra de progreso en la parte inferior. ¿Debería incluirse esto aquí? Puede tener sentido, por ejemplo, para cosas como cargar, descargar, actualizar, sincronizar el progreso. No es un imo imprescindible, pero tal vez podría o debería.

¿Deberían ser redondeados? ¿O no?

Sí, creo que la diferenciación clave aquí de la sugerencia de enseñanza es que las aplicaciones quieren coordinar su espacio de mensajería y pueden tener múltiples errores/actualizaciones de estado para mostrar al mismo tiempo (o en sucesión).

Creo que idealmente, este es un control que el desarrollador configura y coloca dentro de su aplicación y luego canaliza mensajes también (que me imagino que tiene algún tipo de tipo para indicar si es un error, estado, advertencia o algún otro mensaje general).

Tanto en el caso del banner como en el de la ventana emergente, he visto aplicaciones que pueden tener varios mensajes. A veces apilan los banners que luego dominan el estado real de la interfaz de usuario, por lo que sería bueno que esta solución evitara eso (aunque nada evitaría que un desarrollador use varias instancias del control para volver a crear ese comportamiento).

Me sorprende que tampoco hayamos llamado a VS Code, ya que tienen sus paneles de notificación emergentes apilados en la parte inferior derecha que también tienen botones de acción adicionales (para saltar a la configuración, por ejemplo).

Captura de pantalla de ejemplo de código VS:

Tienen diferentes tipos de íconos que aparecen en la parte superior izquierda, acciones de botones personalizables y la capacidad de tener el ícono de 'engranaje' para configurar ajustes sobre las notificaciones por extensión, en su caso.

Acabo de ver esta captura de pantalla de Cortana...

MessageBar de Office UI Fabric se ve muy bien, en mi opinión:

Me di cuenta de que Samsung Notes para Windows 10 usa notificaciones para explicar que se descartó una nota porque no había nada en ella que fuera muy molesto.

¡Hola a todos! Soy administrador de programas de WinUI y retomo esta propuesta de @SavoySchuler. Ya ha habido una gran discusión e intercambio de ideas en este hilo, ¡gracias por todas sus sugerencias!

Como han pasado varios meses desde que hubo alguna actividad aquí, quería volver a consultar con todos y reiterar dónde estamos actualmente.

Como resumen de nuestro alcance actual en la parte superior de la propuesta:

• La notificación será para alertar al usuario de información esencial relacionada con la aplicación en su conjunto.
• Admitirá contenido y estilo personalizados.
• Podrá ser descartado automática y programáticamente
• La notificación debe poder ser descartada por el usuario.
• Debería admitir múltiples notificaciones que se pueden apilar de acuerdo con la especificación de la aplicación.
• Debería responder al cambio de tamaño de la aplicación y a los cambios en la interfaz de usuario
• La notificación no será para mostrar notificaciones en todo el sistema

Siéntase libre de comentar y avíseme si me he perdido algo en mi resumen de alcance o si no está de acuerdo. Quiero estar seguro de que todos estamos en la misma página antes de seguir adelante 😊

Ahora que hemos definido el alcance, hay algunos escenarios específicos y experiencias de usuario que aún deben definirse. Mi esperanza es que definir estas experiencias ayude a guiar las prestaciones de la interfaz de usuario para el control. ¿Cuáles son sus pensamientos para sus escenarios?
CC: @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

Las experiencias son:

• Cómo sale la notificación de la vista
  
  
  
  • El usuario descarta manualmente la notificación.
  
  
  • La notificación se agota automáticamente y se descarta sola.
  
  
  • La notificación solo desaparece después de que el usuario haya realizado una acción relacionada con el motivo por el que apareció la notificación en primer lugar.
    
    
    
    
    
    • es decir, después de recibir una notificación de que Internet se desconectó, la notificación solo desaparece cuando se desconecta Internet
    
    
    
  
  
  • ¿Otro?
  
  
• Cómo reaccionará el usuario a la notificación
  
  
  
  • Inmediatamente tomar acción relacionada con la notificación
  
  
  • Posponer su acción relacionada con la notificación para un momento posterior
  
  
  • Ignorar y/o descartar la notificación por completo
  
  
  • ¿Otro?
  
  
• Cuándo aparecerá la notificación
  
  
  
  • En el lanzamiento de la aplicación
  
  
  • Programáticamente desde el estado de la aplicación
  
  
  • Después de que un usuario realiza una acción (es decir, elige hacer una copia de seguridad de sus documentos)
  
  
  • ¿Otro?
  
  
• Si es posible que aparezcan varias notificaciones a la vez y por qué

¡Gracias nuevamente por todos sus pensamientos y espero sacar esto a la luz!

¡Me alegra ver que esta propuesta no ha sido olvidada @gabbybilka y gracias por aceptarla!

Si es posible, puede comunicarse con quienes trabajan en aplicaciones propias que incluyen este tipo de IU de notificación para hacer una lista de requisitos, para que puedan pasar de su solución personalizada a un control nativo de WinUI. Sus necesidades, combinadas con los deseos y necesidades de la comunidad, deberían cubrir lo suficiente para una V1 de este control.

@chigy sería alguien con quien hablar sobre las especificaciones de diseño final, ya que trabaja con los equipos de Fluent Design.

Microsoft debería predicar con el ejemplo con esto, si se anima a otros a usar un control WinUI consistente.

• Cortana
• Música de ritmo
• Cine y televisión
• Su teléfono

Esas son las aplicaciones que me vienen a la mente.

@gabbybilka también tenemos el control en el Kit de herramientas de la comunidad de Windows , por lo que me complace hablar de eso con usted en cualquier momento. Sería genial tener una ruta de actualización para nuestros usuarios aquí y migrarla desde Toolkit a WinUI.

Creo que, según su resumen inicial, cubre la mayoría de las cosas, pero ¿podría ser bueno decir algo sobre tener botones accionables opcionales también? ¿O eso siempre sería solo contenido personalizado?

Seguimiento del kit de herramientas con un poco de historia del control del kit de herramientas (ha existido por un tiempo):

• Problema original
• Primera revisión de relaciones públicas
• Historial de GitHub : no estoy seguro de cómo obtener la lista completa en una página, así que desplácese hacia abajo y siga haciendo clic en 'Más antiguo'

Los estilos en el kit de herramientas están modelados a partir de los estilos de notificación originales de Microsoft Edge y VS Code (que se han actualizado desde entonces). Pero como se muestra, es flexible y se puede volver a crear una plantilla y funcionaría tanto para una barra de estado de nivel superior como una advertencia al estilo de Office O como una notificación general de estilo emergente.

¡Hola de nuevo! Como actualización de esto, recientemente volví a presentar esta propuesta al equipo y recibí el visto bueno para definir aún más esta función.

Para los escenarios descritos anteriormente, buscamos avanzar con la creación de un control que actualmente se llama InformationBar (InfoBar para abreviar) para representar mensajes de estado esenciales de larga duración en toda la aplicación. El pensamiento de diseño visual inicial está inspirado en MessageBar de FluentUI y en cómo Teams muestra sus mensajes "Grabando ahora" e "Internet desconectado".
Específicamente, incluir un icono, un título, un área de mensaje flexible y un botón de descartar como los componentes visuales primarios y mínimos en un contenedor que se ajuste de forma predeterminada al ancho del área de contenido en la que reside. el usuario o mediante programación cuando se resuelve la funcionalidad de la aplicación que afecta el estado, es decir, se restaura la conectividad a Internet, sin animaciones de entrada/salida.

Equipos (ahora grabando)

Office (modo de compatibilidad)

Equipos (sin internet)

A medida que la API comience a cristalizar, comenzaré a guiar la discusión hacia la especificación. Mientras tanto , siéntase libre de continuar compartiendo sus escenarios en los que usaría una barra de información y qué funcionalidad necesita 😊

Anteriormente en la discusión , @mrlacey y otros mencionaron la posibilidad de tener dos controles separados que podrían cubrir los escenarios mencionados.

Creo que estos dos conceptos:

• un banner descartable de ancho completo con cero o más subelementos procesables
• un banner destinado a indicar cambios de estado y que funciona como un solo botón

proporcionará el mayor valor y la menor confusión como controles separados.

Reconozco que es posible que el estilo visual y los componentes de la barra de información no se ajusten a algunos de los casos de uso compartidos anteriormente. Si los escenarios y la funcionalidad de su aplicación específica requieren un estilo visual diferente, siéntase libre de continuar compartiendo esas situaciones en este hilo.

¡Gracias de nuevo a todos!

El control debe estar diseñado para funcionar bien con plantillas y estilos, de modo que pueda moldearse para adaptarse a las necesidades, mientras que todos los comportamientos son propiedades del control.
Animar o no animar.
Mostrar botón de cierre u ocultarlo.
Posición.
Mostrar icono o no.

etc.

Reconozco que es posible que el estilo visual y los componentes de la barra de información no se ajusten a algunos de los casos de uso compartidos anteriormente. Si los escenarios y la funcionalidad de su aplicación específica requieren un estilo visual diferente, siéntase libre de continuar compartiendo esas situaciones en este hilo.

¡Gracias de nuevo a todos!

Es genial que siga adelante. El estilo visual que se muestra deja mucho de desear hasta el punto de que no me gustaría usar la aplicación.

Los diseños que publicó @mdtauk o las capturas de pantalla de Cortana anteriores serían mucho más preferibles. Los diseños de las aplicaciones deben avanzar y no ser frenados por los programas.

¿Actuaría/podría esto también como una CommandBar descartable como las que se usan al presentar/compartir el escritorio? P.ej

Sé que no admitiría la superposición sobre todo, pero en términos de corregir su ancho y colocarlo en una capa de superposición de una aplicación, pude ver que la superposición en diseño/funcionalidad es similar en esta dirección.

@mdtauk

El control debe estar diseñado para funcionar bien con plantillas y estilos, de modo que pueda moldearse para adaptarse a las necesidades, mientras que todos los comportamientos son propiedades del control.
Animar o no animar.
Mostrar botón de cierre u ocultarlo.
Posición.
Mostrar icono o no.

@shaheedmalik

Es genial que siga adelante. El estilo visual que se muestra deja mucho de desear hasta el punto de que no me gustaría usar la aplicación.

Los diseños que publicó @mdtauk o las capturas de pantalla de Cortana anteriores serían mucho más preferibles. Los diseños de las aplicaciones deben avanzar y no ser frenados por los programas.

¡Gracias por tus comentarios allí! Estoy de acuerdo en que el control debe ser lo suficientemente flexible para este comportamiento básico y personalización en el sistema Fluent Design. Las imágenes que compartí eran principalmente referencias de ejemplos implementados previamente.
Continuaremos tratando de encontrar el equilibrio entre sobrecargar un solo control con demasiada funcionalidad y garantizar que sea lo suficientemente personalizable y útil para los diversos escenarios de mensajes de estado de toda la aplicación de larga duración.

¿Actuaría/podría esto también como una CommandBar descartable como las que se usan al presentar/compartir el escritorio? P.ej

@michael-hawker

Creo que este es un escenario interesante que aún no se mencionó en el hilo y podría ser compatible con este control. ¡Gracias por traer a nuestra atención! En lo que respecta al alcance, este parece ser un escenario de menor prioridad, pero estoy de acuerdo en que el diseño/funcionalidad es similar fuera de la priorización de superposición.

¿Hay alguna actualización sobre este tema? Actualmente estamos planeando una interfaz de usuario para mostrar el estado de las operaciones de archivos en Archivos UWP, el diseño al que nos inclinamos puede beneficiarse de esta característica que se propone aquí.

Hola @yaichenbaum , ¡gracias por registrarte! Como actualización de esta propuesta, me complace compartir el documento de especificaciones que estamos comenzando a redactar.

Como resumen de lo definido hasta ahora, optamos por crear un único control con dos modos visuales, "Barra" y "Tostada" o "Tarjeta". Nuestros esfuerzos actuales están en la definición y creación de prototipos del modo "Bar". Los componentes de estos dos modos son los mismos y están planificados para diferir solo en el diseño visual. Como habrá múltiples modos visuales, actualmente considero que este control StatusBanner en lugar de InformationBar no se restringe al estilo único de "Barra", sin embargo, siéntase libre de compartir sus ideas para nombrar 😊

Los componentes principales del StatusBanner de izquierda a derecha en el diseño son:

• color de estado
• Icono
• Título
• Mensaje
• Botón de acción
• botón cerrar

Estas propiedades son opcionales y el contenido personalizado a través de la propiedad "Contenido" sigue siendo una opción.

Además, estamos planeando definir varios BannerTypes que un desarrollador puede configurar que tienen combinaciones de iconos y colores preestablecidos según el estado. Esto puede simplificar la elección del Icon o BannerColor correcto en función de la criticidad de la notificación y proporcionar cierta coherencia entre las aplicaciones. También se admite la personalización de Icon o BannerColor.

Prototipo en papel del StatusBanner en modo "Barra" sin botón de acción ni botón de cierre personalizado.

El diseño actual de los diseños de la barra de StatusBanner se inspiró en gran medida en los diseños de @mdtauk para la tarjeta de estado, ¡gracias!

Si desea compartir comentarios sobre el estado actual de la especificación, no dude en comentar en este número. Nuestros próximos pasos son solidificar los diseños y los fragmentos de código (y expandirlos para cubrir más casos de uso) y definir funcionalidades como el apilamiento y el ajuste de mensajes. ¡Gracias a todos!

@yaichenbaum mientras tanto, está el control InAppNotification del Toolkit.

@gabbybilka Gracias por la actualización, una característica importante que necesitaré para mi caso de uso es la capacidad de mostrar varios mensajes de estado a la vez, al igual que @hawkerm compartió anteriormente en este hilo. Tener el control que maneje la colocación de múltiples mensajes de estado será una ventaja.

@yaichenbaum mientras tanto, está el control InAppNotification del Toolkit.

@hawkerm No he mirado mucho el InAppNotification pero prefiero esperar a la versión de WinUI en lugar de cambiar al nuevo control cuando esté listo.

¡Hola, todos!
Disculpas por la falta de tiempo entre la última actualización y ahora, hemos estado trabajando duro para definir este control 😊
Es posible que hayas visto la fusión del prototipo de @chenss3 en el repositorio hace unas semanas, ¡estamos muy emocionados de ver que esto cobra vida! En esta etapa, estamos interesados ​​en conectarnos con cualquier consumidor de este control que esté interesado en crear prototipos y usarlo en sus aplicaciones. Comuníquese y comparta qué aplicación está desarrollando, los escenarios cuando usa este control, si necesita ayuda para comenzar y sus comentarios sobre el uso del prototipo.

Como comenzamos a determinar los detalles de implementación para una versión emergente de este control con soporte para posicionamiento y apilamiento de múltiples notificaciones, decidimos continuar trabajando en una versión en línea para el futuro cercano . Escuchamos sus comentarios sobre la necesidad de la funcionalidad emergente para algunos de sus escenarios y continuaremos avanzando en esa dirección. Mientras tanto, estamos desarrollando nuestra próxima versión del prototipo que se parece más a las maquetas a continuación.

Consulte las especificaciones si desea ver algunos ejemplos más:

¡Gracias a todos y espero tener noticias tuyas!

¿Esto solo está disponible en WinUI 3 o va a una versión preliminar de WinUI 2?

Prelanzamiento de @kmgallahan WinUI 2, aún no estamos muy seguros de la versión de envío exacta, ya que queremos recibir un poco más de comentarios de la comunidad y los clientes sobre el prototipo y las versiones preliminares.

Para maximizar los primeros comentarios, recomendaría que probar prototipos como este sea lo más fácil posible. Tal vez empujarlos a compilaciones previas al lanzamiento con descargos de responsabilidad, o proporcionar lanzamientos de desarrollo/beta.

Ser necesario para construir una rama de desarrollo de WinUI para probar prototipos proporciona una buena fricción, especialmente si usted es principalmente un consumidor de WinUI en lugar de un colaborador (al código base de todos modos).

De acuerdo, una vez que el prototipo esté en un estado sólido (con un aspecto similar a las maquetas que se muestran y con soporte para diferentes opciones de entrada), nos gustaría ponerlo en la versión preliminar 2.5. ¿Sería capaz/interesado en probarlo en ese momento?

Estoy interesado en probarlo ahora, simplemente prefiero consumir desde NuGet en lugar de agregar un proyecto masivo como WinUI a mi compilación.

Por ahora esperaré por lo que sea que se convierta en una vista previa.

¡Hola de nuevo! Algunas actualizaciones:

• La especificación ha continuado siendo revisada e iterada. Por favor, siéntase libre de comprobarlo en este PR y dejar comentarios. Un cambio notable es la adición de una propiedad ActionButton genérica que incluirá su propio contenido heredado de ButtonBase.

  • Una inconsistencia en las maquetas actuales que me gustaría señalar es la ubicación de este botón de acción. En la especificación, el botón de acción actualmente se muestra alineado a la derecha directamente a la izquierda del botón de cerrar; sin embargo, la ubicación real estará directamente a la derecha del mensaje. La imagen que se muestra en mi comentario anterior y a continuación es la ubicación correcta. Las maquetas mejoradas seguirán actualizándose y agregándose a la especificación a medida que continúa el desarrollo 😊

• @teaP retomó la implementación de la versión nativa de este control a medida que avanza hacia una versión preliminar de WinUI 2.5 . ¡Gracias!

Como antes, si se ve a sí mismo como un usuario potencial de este control, no dude en comentar sobre la aplicación que está desarrollando y los escenarios en los que usaría la barra de información. ¡Gracias a todos!

¡Hola de nuevo! Solo para resaltar, @teaP abrió recientemente la solicitud de extracción n.º 3325 para la barra de información si desea consultarla 😊

¿Por qué se llama InfoBar? Info es solo una pequeña clase de información que puede contener. También admite errores y advertencias, además de acciones basadas en ellos. Bar también restringe artificialmente la 'forma' del control. Hay varios otros casos de uso además de una barra.

NotificationView o MessageView, etc. serían mejores nombres en mi opinión.

¿Por qué se llama InfoBar? Info es solo una pequeña clase de información que puede contener. También admite errores y advertencias, además de acciones basadas en ellos. Bar también restringe artificialmente la 'forma' del control. Hay varios otros casos de uso además de una barra.

NotificationView o MessageView, etc. serían mejores nombres en mi opinión.

Originalmente se propuso como un StatusBanner
Luego se cambió a InformationBar / InfoBar

La versión FluentUI de este control se llama MessageBar .

Gracias por el resumen. El nombre todavía no tiene mucho sentido para mí. La forma en que está diseñado el control actual es como una notificación. Más generalizado, debería ser un 'mensaje' para que también pueda admitir escenarios de ayuda/enseñanza. Generalizando los diversos conceptos, aquí hay un mejor diseño para los controles:

1. ~ MessageView ~ o Sugerencia : un control para mostrar el estado, la sugerencia o la información de enseñanza al usuario con una acción, un título, un glifo, una imagen y botones opcionales. Esto se puede colocar en cualquier lugar y no es una ventana emergente. También admitiría diferentes diseños.

2. TeachingTip : un control flotante/ventana emergente que aloja un MessageView.

   • Sugerencia alojada

3. NotificationBar o StatusTip : notificación de toda la aplicación en formato de "barra" en la parte superior de la aplicación o vista.

   • Sugerencia alojada

4. Información sobre herramientas : ahora también podrá alojar la sugerencia que brindará soporte para acciones e imágenes, etc.

   • Sugerencia alojada

Realmente necesitamos pensar en términos generales y combinar conceptos de alto nivel en los mismos controles. De lo contrario, vamos a crear muchos controles muy especializados con propiedades similares pero diferentes.

Se pensó en un nombre perfecto para un control general 'MessageView': llámelo 'Consejo'. ToolTip podría alojarlo también. Actualizado en consecuencia.

Aquí hay otro ejemplo del 'mundo real' de una barra de notificación en la parte superior de algunos campos de entrada. El control actual sería útil para ese escenario:

Aquí hay otro ejemplo del 'mundo real' de una barra de notificación en la parte superior de algunos campos de entrada. El control actual sería útil para ese escenario:

Los cuadros de texto obtendrán estados de validación que podrían cubrir algo de esto, pero así es como veo los diversos controles...

• Información sobre herramientas para un solo elemento donde el usuario desea identificar activamente;
• TeachingTip para un solo elemento que el desarrollador quiere que el usuario observe (también puede estar separado de un elemento);
• Barra de información para toda la aplicación/área de contenido donde el desarrollador desea entregar alguna información;
• Flyout/Diálogo para cuando el desarrollador quiere que el usuario confirme que ha leído algo antes de descartarlo;
• Cuadro de diálogo de contenido para cuando el desarrollador requiere que el usuario haga una elección o realice una acción por encima de todo;

También evitaría usar la palabra Notificación ya que existe la notificación de nivel de sistema operativo y el centro de notificación para estos

También evitaría usar la palabra Notificación ya que existe la notificación de nivel de sistema operativo y el centro de notificación para estos

Bueno, creo que los desarrolladores notarían la diferencia, pero ciertamente es un buen punto.

También es cierto que podemos hacer muchos controles separados. Pero ciertamente hay algunos conceptos de alto nivel sobre notificación/estado/mensajes/sugerencias/enseñanza que podrían combinarse. Al menos deberíamos hacer una interfaz de todo esto.

Los cuadros de diálogo de Flyout/Content son conceptos separados, ya que son controles de contenido genéricos en su mayor parte.

Pensé en un nombre perfecto para un control de tipo 'vista de mensaje' generalizado para hospedar en varios escenarios: llámelo 'Consejo'. Actualicé mi comentario anterior en consecuencia: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

Pensé en un nombre perfecto para un control de tipo 'vista de mensaje' generalizado para hospedar en varios escenarios: llámelo 'Consejo'. Actualicé mi comentario anterior en consecuencia: # 913 (comentario)

No me sentiría cómodo poniendo una advertencia importante o un mensaje de error en un Consejo ...

También es cierto que podemos hacer muchos controles separados. Pero ciertamente hay algunos conceptos de alto nivel sobre notificación/estado/mensajes/sugerencias/enseñanza que podrían combinarse. Al menos deberíamos hacer una interfaz de todo esto.

Los cuadros de diálogo de Flyout/Content son conceptos separados, ya que son controles de contenido genéricos en su mayor parte.

De veras me gusta esta idea. Creo que hay puntos en común en las API de iconos, títulos, mensajes y botones de acción que pueden ser coherentes en estos controles de información. Con InfoBar, no estoy seguro de si es algo que podamos implementar en esta versión actual, pero potencialmente para nuestro próximo control de esta naturaleza.

Pensé en un nombre perfecto para un control de tipo 'vista de mensaje' generalizado para hospedar en varios escenarios: llámelo 'Consejo'. Actualicé mi comentario anterior en consecuencia: # 913 (comentario)

No me sentiría cómodo poniendo una advertencia importante o un mensaje de error en un Consejo ...

También estoy de acuerdo con esto... más exploración por hacer.

Pensé en un nombre perfecto para un control de tipo 'vista de mensaje' generalizado para hospedar en varios escenarios: llámelo 'Consejo'. Actualicé mi comentario anterior en consecuencia: # 913 (comentario)

No me sentiría cómodo poniendo una advertencia importante o un mensaje de error en un Sugerencia...

También estoy de acuerdo con esto... más exploración por hacer.

Piense en lo bien que encaja con todos los controles e ideas existentes: es perfecto en ese sentido. Pero sí, parece fuera de lugar en el contexto de errores/advertencias. Creo que la gente lo entendería rápidamente, pero no puedo discutir con esa lógica.

¿Por qué se llama InfoBar? Info es solo una pequeña clase de información que puede contener. También admite errores y advertencias, además de acciones basadas en ellos. Bar también restringe artificialmente la 'forma' del control. Hay varios otros casos de uso además de una barra.

NotificationView o MessageView, etc. serían mejores nombres en mi opinión.

Estoy de acuerdo con su punto de que InfoBar puede no ser siempre una barra, sin embargo, creo que incluir "barra" en el nombre implica que está destinado a escenarios de toda la aplicación, tanto visual como conceptualmente. Al buscar imágenes de la "barra de información", encuentra imágenes de experiencias similares de IE (no es que necesariamente estemos tratando de hacer coincidir IE) y creo que connota el diseño visual y funcional esperado. No veo esto como una 'Vista', pero me gusta el enfoque en el mensaje o la notificación.

@gabbybilka Sí, es bastante similar a la antigua StatusBar o la nueva AppBar... CommandBar... etc. El problema es que el uso del control debe generalizarse un poco para mostrar también sugerencias y mensajes en ubicaciones arbitrarias. 'Ver' tampoco se ajusta al 100%, pero está más cerca de un nombre general. Realmente mi preocupación es unificar los conceptos subyacentes para que no terminemos con múltiples controles haciendo variaciones de lo mismo.

Editado por confundirme con múltiples comentarios en dos ubicaciones.

Haciéndose eco de los pensamientos que publiqué en uno de los otros números...

_Respondiendo al hecho de que ya no se considera un modo flotante para el control para V2_
Puedo entender que el cambio en el comportamiento y la forma lo haría volverse hacia el TeachingTip como una alternativa, pero sugeriría la falta de severidad, el color del estado y el diseño del consejo de enseñanza en sí mismo: no sería compatible con el mismo tipo de mensajes que el control InformationBar atiende.

El ancho de la pantalla y las diferencias en los diseños de la interfaz de usuario entre una aplicación WinUI de pantalla completa, una ventana de ancho estrecho y cosas como Hololens y Xbox, no se prestarían a un factor de forma de barra acoplada.

Entonces, con eso en mente, tal vez la barra de información debería envolverse, junto con un control de tarjeta de información en una API de AppMessage, para que las mismas propiedades de gravedad, color, título, mensaje, botones de acción, etc. se puedan colocar en el XAML, o en el el código de la aplicación y la forma en que se presentan en la pantalla cambia para adaptarse al factor de forma/familia de dispositivos.

Una sugerencia de enseñanza no adjunta podría reemplazarse, pero no admitiría aquellas personalizaciones que son adecuadas para los mensajes de estado de la aplicación, que es la intención original detrás de este control.

Entonces, ¿qué pasaría si tuviéramos un 'Consejo' que en realidad es solo un mensaje? Tiene glifo, imágenes, texto de mensaje, título.

Luego, derivado de Tip, tenemos AppMessage que agrega gravedad, acciones y cosas. La sugerencia aún se podría utilizar en TeachingTip y ToolTip tal como existen hoy. también sería útil en mi escenario para sugerencias contextuales en línea.

Entonces, ¿qué pasaría si tuviéramos un 'Consejo' que en realidad es solo un mensaje? Tiene glifo, imágenes, texto de mensaje, título.

Luego, derivado de Tip, tenemos AppMessage que agrega gravedad, acciones y cosas. La sugerencia aún se podría utilizar en TeachingTip y ToolTip tal como existen hoy. también sería útil en mi escenario para sugerencias contextuales en línea.

TeachingTip sin cola parece perfecto para su situación...

TeachingTip sin cola parece perfecto para su situación...

No sabía que podía hacer eso con TeachingTip. Además, mi control ha existido por mucho más tiempo que TeachingTip, por lo que nunca investigué realmente cómo actualizarlo hasta ahora. De cualquier manera, si puedes hacer eso, es un descuido de mi parte.

Editar: no importa, incluso sin una cola, sigue siendo una superposición que se descarta de una forma u otra. La 'pista' que estoy describiendo está en línea y persiste hasta que el usuario básicamente crea el primer elemento. Es simplemente un control que presenta información, no en una ventana emergente, flotante u otra vista no persistente.

Todavía estoy convencido de que hay muchos puntos en común para dividirse en interfaces/controles utilizados en múltiples lugares. Todos estos controles que estamos discutiendo tienen muchas más similitudes que diferencias. Lo único que cambia es dónde/cómo se presenta la información subyacente. Todo esto está maduro para la simplificación.

TeachingTip sin cola parece perfecto para su situación...

No sabía que podía hacer eso con TeachingTip. Además, mi control ha existido por mucho más tiempo que TeachingTip, por lo que nunca investigué realmente cómo actualizarlo hasta ahora. De cualquier manera, si puedes hacer eso, es un descuido de mi parte.

Todavía estoy convencido de que hay muchos puntos en común para dividirse en interfaces/controles utilizados en múltiples lugares. Todos estos controles que estamos discutiendo tienen muchas más similitudes que diferencias. Lo único que cambia es dónde/cómo se presenta la información subyacente. Todo esto está maduro para la simplificación.

Cuando lo desglosa, es solo un ícono y texto, y no hay un "contexto" asociado con él. Pero supongo que mi sugerencia de envolverlo en un AppMessage podría incluir Consejos de enseñanza no adjuntos como otra forma de interfaz de usuario.

Cuando lo desglosa, es solo un ícono y texto, y no hay un "contexto" asociado con él. Pero supongo que mi sugerencia de envolverlo en un AppMessage podría incluir Consejos de enseñanza no adjuntos como otra forma de interfaz de usuario.

Lo siento, mira mi edición anterior. La sugerencia de enseñanza todavía no está en línea y simplemente flota en la parte inferior hasta que se descarta. También hay una imagen y un título a considerar.

Cuando lo desglosa, es solo un ícono y texto, y no hay un "contexto" asociado con él. Pero supongo que mi sugerencia de envolverlo en un AppMessage podría incluir Consejos de enseñanza no adjuntos como otra forma de interfaz de usuario.

Lo siento, mira mi edición anterior. La sugerencia de enseñanza todavía no está en línea y simplemente flota en la parte inferior hasta que se descarta.

No tiene que estar en la parte inferior.

En línea es quizás un caso de uso inusual para una sugerencia, ya que desplazaría otro contenido a su alrededor.

Podría sugerir que un V2 agregue soporte para un modo de visualización en línea/no flotante

Para dar un poco más de contexto al comentario de @mdtauk , aquí estaba mi respuesta inicial a su pregunta sobre la eliminación del modo flotante de la sección "Características previstas para InfoBar V2" en la especificación.
De mi parte:

Saltando aquí para la discusión de diseño. Buen ojo al notar que las características previstas de V2 cambian 😉 En este momento no nos comprometemos con el modo flotante para InfoBar en una versión V2 por un par de razones. Me gustaría explorar más a fondo si el modo flotante _debería_ estar en una barra de información o si las notificaciones tipo brindis deberían ser un control completamente diferente. Mientras investigamos, nos dimos cuenta de que una implementación básica del modo flotante sería increíblemente similar a la sugerencia de enseñanza y que, para explorar completamente la funcionalidad de escenarios de notificación tipo brindis, como las opciones de apilamiento, posicionamiento y superposición (consulte StackMode de WCT InAppNotification ) es probable que sea necesario. Esto ampliaría el alcance y la intención de la barra de información para que sea mucho más amplia que su enfoque inicial. Para tener en cuenta, no hemos cerrado completamente la puerta para agregar capacidades flotantes a InfoBar, pero nos inclinamos por no.

Para la propuesta de InformationBar e InformationCard basada en una clase básica de AppMessage, me gusta esta idea. Usted mencionó que "la forma en que se presentan en la pantalla cambiaría para adaptarse al factor de forma/familia de dispositivos", que me gustaría explorar más a fondo. Creo que hay escenarios más adecuados para la UX de la tarjeta (especialmente mensajes transitorios, mensajes de error específicos de la página y aplicaciones sin superficies acoplables) que la UX de la barra y viceversa.

Para mí, existen diferencias tanto en "cuándo" usar una InfoBar/InfoCard/Teaching Tip (vinculado a las necesidades visuales y funcionales) como en el "por qué" usar (basado en la percepción del usuario final y la consistencia de la experiencia). Los mensajes transitorios son un claro punto culminante para mí como algo que debería ser compatible con una tarjeta de información y no con una barra de información. Los mensajes no descartables por el usuario son un ejemplo de lo contrario, ya que el contenido superpuesto persistente es difícil de admitir desde una perspectiva de accesibilidad.

Sin embargo, no se desvíe :) Todos estos diversos controles presentan, en su mayor parte, el mismo tipo de información, solo que en diferentes áreas/estilos. Esto necesita ser generalizado y unificado. Creo que podemos unificarnos en torno a un control común 'AppMessage' si quieres llamarlo así. Luego, solo tenga diferentes contenedores para presentar ese 'AppMessage' de diferentes maneras. Se puede presentar en un TeachingTIp, ToolTip, NotificationBar, como una tarjeta en algún lugar, etc. Cada contenedor puede modificar el estilo para adaptarse a su caso de uso. Sin embargo, las propiedades y los tipos subyacentes se unificarían.

No estaba tratando de malinterpretar ningún contexto con la respuesta de @gabbybilka 😄

Para la propuesta de InformationBar e InformationCard basada en una clase básica de AppMessage, me gusta esta idea.

Aquí es donde entra en juego el nombre. Me gusta "AppMessage" ("Tip" sería increíble, ya que parecería que fue el plan desde el principio), pero si vamos con eso, debería ser el alojamiento "MessageBar" y "MessageCard". eso.

Para mí, existen diferencias tanto en "cuándo" usar una InfoBar/InfoCard/Teaching Tip (vinculado a las necesidades visuales y funcionales) como en el "por qué" usar (basado en la percepción del usuario final y la consistencia de la experiencia).

Definitivamente estoy de acuerdo con estos diferentes casos de uso y presentaciones. Sin embargo, siguen presentando un mensaje que puede generalizarse y estandarizarse. Creo que todos estamos de acuerdo en ese concepto ahora :)

Ejemplo de un mensaje de tarjeta/consejo

Creo que uno de los objetivos debería ser alentar a las aplicaciones de la bandeja de entrada y de primera mano/Windows Shell a alejarse de sus soluciones personalizadas para usar un control de la bandeja de entrada/API coherente.

Probablemente debería agregar que en una aplicación para UWP en la que trabajo, algunos de estos conceptos ya estaban unificados. La versión simplificada relevante para esta discusión es:

Existe una clase 'Mensaje' (no es un control, solo una estructura de datos) con las siguientes propiedades:

        protected MessageDisplayMode _DisplayMode;
        protected List<Message>      _InnerMessages;
        protected MessagePriority    _Priority;
        protected string             _Text;
        protected DateTimeOffset?    _Timestamp;

La prioridad es básicamente la misma que ya ha decidido (ahora está bastante estandarizada). DisplayMode admite Notificación, Ninguno y Emergente. Cuando el código de back-end genera un mensaje, se pasa al front-end que lo mostrará como una notificación rápida en una "barra" en la parte superior de la aplicación para descartarlo. O como una ventana emergente de bloqueo para mensajes más graves.

Además, hay un control 'MessageView' que toma un mensaje por sí mismo pero agrega un glifo y un título y lo presenta como la 'Pista' contextual en línea de la que hemos hablado anteriormente.

Eso es exactamente lo que propondría: hacer la abstracción en la capa de la aplicación. Tenga una clase ViewModel simple que pueda adjuntar a cualquier vista. Es fácil de hacer y más flexible. Tal vez también desee iniciar sesión con su marco de registro preferido, desee tener prioridades personalizadas, desee agregar sus propios datos. Todo fácil de hacer en su ViewModel.

La intención de los controles que mencionó es proporcionar una forma unificada de hacer ciertos escenarios, en muchas aplicaciones y casos de uso del sistema operativo, en lugar de que cada aplicación tenga una interfaz de usuario y un comportamiento ligeramente diferentes. ToolTips e InfoBar/MessageBar son conceptos bien conocidos, tanto para desarrolladores como para usuarios finales. Aunque ambos presentan información, se utilizan para cosas muy diferentes. No veo mucho beneficio en tener una clase base común o un concepto común para estos. ¿Por qué querría poner un mensaje en una información sobre herramientas, que ya se muestra en la barra de información de la aplicación global (y dónde adjuntaría esta información sobre herramientas)? No es como si esto llevara a mucha reutilización.

Hay otras áreas donde los conceptos comunes serían mucho más útiles en mi opinión. Piense en Button, AppBarButton, MenuItem. Todos estos muestran texto y un ícono, todos se usan para desencadenar una acción. A menudo, proporciona los mismos comandos tanto en un MenuItem (ContextMenu) como en una AppBar/CommandBar. Aquí, un concepto común sería muy útil, donde podría poner su comando, texto, ícono, tal vez también un mensaje largo (información sobre herramientas). ¿Pero tener un concepto común para ToolTip y MessageBar? Realmente no veo la necesidad de esto. Claro, si reescribiéramos UWP desde cero, podríamos haber creado una clase base común. Pero no creo que sea necesario o demasiado útil.

@lukasf Tus puntos tienen sentido; se puede hacer en la propia aplicación. Sin embargo, hay muchos conceptos muy similares y todos pueden beneficiarse de una unificación aquí.

ToolTip se incluyó en la discusión porque podría ser beneficioso tener un glifo y un título junto con un mensaje. Conceptualmente, todos estos controles también son mensajes de alguna forma; solo dónde/cómo se muestran son diferentes. Incluso si no hacemos una gran estandarización, una barra de mensajes y una tarjeta de mensajes aún requerirían muchas propiedades/tipos compartidos. No queremos tener MessageBarPriority junto con los enemigos MessageCardPriority. Todavía se debe pensar para asegurarse de que incluso los tipos básicos estén preparados para el futuro.

Combinar todo esto con las ideas existentes en el Consejo de enseñanza solo me parece lógico. Estoy seguro de qué dirección tomar tendría sentido con una comparación lado a lado de todos los controles mencionados y sus propiedades. Si tengo tiempo, haré la comparación yo mismo.

Sus comentarios sobre Button/AppBarButton/etc. son un ejemplo perfecto del pensamiento que no queremos proliferar. Microsoft está adquiriendo el hábito de hacer varios controles similares pero diferentes sin gastar tiempo/esfuerzo en hacerlos coherentes. Este largo plazo no es bueno para un marco de ningún tipo por varias razones.

He reunido una comparación de los controles de mensajería. Lo regalaré como consulta gratuita ya que es tan duro como es :)

Este es el tipo de documentación de estrategia y comparación de alto nivel que esperaría que se creara internamente en Microsoft. Si fuera yo mismo quien dirigiera las revisiones de especificaciones/diseño, exigiría este tipo de análisis o nadie puede esperar irse con aprobación. Es absolutamente importante:

1. Cerrar las brechas en la comprensión entre los miembros del equipo
2. Superar los 'silos' que se producen en grandes equipos y organizaciones
3. asegurar una dirección futura coherente del marco para que la funcionalidad futura se pueda agregar sobre una buena base (lo más importante)

Microsoft de alguna manera perdió estos principios generales después de WPF y parece que ya no hay una visión de "nivel superior" por parte del liderazgo en este espacio. De todos modos, no estoy al tanto de las discusiones internas, así que espero que haya mucha más planificación interna con algunas personas que tienen mucha experiencia y una larga historia de los principios con XAML.

Dicho esto, siéntase libre de romper el documento a continuación. Es la discusión en sí lo que es más importante.

Comparación de control de mensajes 20200929.xlsx

Gracias por el documento de comparación, ¡muy bueno ver sus pensamientos sobre los controles de información de manera integral! Dos temas principales sobre los que quiero continuar la discusión son 1. ¿Por qué _no deberían_ el Consejo de enseñanza y la barra de información tener diferentes API/propiedades/funcionalidad? y 2. ¿Cuál sería la diferencia entre una barra de información y una tarjeta de información si la tarjeta de información no fuera una ventana emergente como se describe en el documento de comparación?

Para la primera pregunta, puedo resaltar las decisiones de diseño tomadas en los elementos con texto rojo y brindar un poco más de claridad:

• TeachingTip Subtitle vs InfoBar Message: Funcionalmente, ¡sí, son lo mismo! Son el mensaje secundario con texto sin negrita en estos controles. En una sugerencia de enseñanza, este mensaje siempre se mostrará debajo del título y tiene sentido nombrarlo como subtítulo. Para la barra de información, este mensaje estará en línea y directamente a la derecha del título, lo que conceptualmente no tiene tanto sentido como un subtítulo.
• TeachingTip HeroContent vs InfoBar Content: Teaching Tip tiene tanto HeroContent como Content, mientras que InfoBar solo tiene contenido. La propiedad HeroContent es exclusiva de Teaching Tip debido a que admite estas imágenes más grandes para ayudar a enseñar. InfoBar no admite explícitamente imágenes, ya que se centra en un diseño horizontal. La propiedad Content para ambos controles es para contenido personalizado adicional y está debajo del resto de los elementos de la interfaz de usuario en ambos.
• Estrategia de botón de Sugerencia de enseñanza frente a estrategia de botón de InfoBar: las principales diferencias aquí son que InfoBar admite más tipos de botones fuera del clásico "Botón" y no fomenta la personalización del botón de cierre para incluir texto.
  
  
  
  • Un escenario común para InfoBars es incluir un botón de hipervínculo. Debido al contraste de color con el color de primer plano del botón de hipervínculo predeterminado y nuestros colores de fondo de varios colores, queríamos asegurarnos de poder aplicar nuestro propio estilo personalizado a cualquier botón de hipervínculo incluido en la barra de información para que permanecieran accesibles.
  
  
  • Decidimos no incluir la personalización del botón de cierre (para el texto, todavía hay una propiedad CloseButtonStyle para hacer un estilo ligero si lo desea) en la barra de información después de nuestras revisiones de diseño para garantizar que el enfoque permanezca en el texto incluido y la acción única. De manera relacionada, como se menciona en la especificación, estamos pensando en un ActionContentArea en V2 para admitir más de un botón de acción aquí y podríamos investigar la posibilidad de habilitar la personalización del botón de cierre nuevamente allí.
  
  
• InfoBar IsClosable & IsIconVisible: La sugerencia de enseñanza no tiene IsClosable como una sugerencia de enseñanza siempre debe poder cerrarse, ya que es una ventana emergente y muestra información urgente/sin bloqueo. Tampoco tiene IsIconVisible ya que un ícono no aparece con su estilo predeterminado, lo que hace InfoBar a través de los diferentes niveles de gravedad. Queríamos proporcionar una forma para que un desarrollador eliminara el icono proporcionado si lo deseaba. Intentamos establecer IconSource en nulo, lo que causó muchos errores funky y se simplificó a través de la propiedad IsIconVisible.

¿Tienen sentido? Creo que hay diferentes propósitos para ambos controles y las diferencias en la funcionalidad lo reflejan. ¡Espero que estas explicaciones y la justificación del diseño hayan sido útiles!

Editar por problemas de formato y error tipográfico😊 x2

No abogaría por la armonización entre estos controles directamente, ya que existe una justificación para que estos controles hagan lo suyo dentro de sus propios contextos.

Sin embargo, la creación de una API de mensajería en la aplicación, que actúa como una estructura unificadora, pero puede adaptarse al factor de forma, no necesita cambios en los controles.

Hay preguntas para discutir y responder para este tipo de API:

• ¿Debe/cómo usted, como desarrollador, puede especificar qué tipo de control muestra una llamada de mensaje en la pantalla?
• Si no especifica un tipo de control, ¿la API toma las propiedades dadas y "elige" la más adecuada?
• ¿Cómo pasaría las opciones de comportamiento a los controles subyacentes?
• ¿Qué factores de forma anularían en función de la idoneidad de la plataforma?

Y probablemente muchos más en los que no he pensado jajaja

Tomando Xbox como plataforma
Los métodos de entrada son muy diferentes, al igual que el tamaño/escalado de la pantalla.

Las barras de información de ancho completo deberían tener en cuenta la sobreexploración en los bordes de la pantalla y, por lo tanto, para estas aplicaciones, una tarjeta de información puede ser más adecuada.

Pero, ¿cómo manejarías el despido?

No hay cursor para moverse sobre un botón de cierre, pero ¿quiere que la tarjeta se haga cargo de las entradas del controlador? Esto lo hace modal. Pero luego, si está superpuesto sobre el contenido, ¿cómo lo seleccionas y le das el foco?

Entonces, ¿aparece en línea y empuja el contenido hacia abajo, pero no tiene el ancho completo?

Además, Xbox tiene su propio sistema de notificación tipo brindis, entonces, ¿esta API debería funcionar con eso? ¿Puede funcionar con él, o es solo el sistema?

1. ¿Por qué el Consejo de enseñanza y la barra de información no deberían tener diferentes API/propiedades/funcionalidad?

El objetivo siempre debe ser proporcionar API comunes para las mismas cosas. Toda esta discusión se trata de mensajes orientados al usuario en general y aparecieron varias similitudes una vez que se entendió. Es indiscutible que los casos de uso para TeachingTip y un control de tipo MessageBar son diferentes. Fundamentalmente, uno presenta un Mensaje y el otro también un Consejo. No estoy cuestionando las opciones generales de diseño aquí. Sin embargo, hay MUCHAS más similitudes que diferencias con estos controles. Solo mire el diseño solo: todos tienen ícono, título, subtítulo, contenido, botón de acción y botón de cierre (sin embargo, los nombró de manera diferente y hay un área de superficie de API diferente). Si no ve por qué es una buena idea estandarizar al menos los nombres y las enumeraciones aquí, no hay nada más que pueda decir. Esto es algo fundamental para una buena arquitectura.

Para los botones, ambos controles admiten un botón de acción y un botón de cierre. Pero lo hiciste de maneras completamente diferentes. Explicaste algunas razones arriba, pero ahora tenemos una API 'fea' para usar botones en situaciones como esta. ¿Por qué no generalizamos esto ahora para tener algo bueno para el futuro? Botones como este se aplican a varios controles: ContentDialog, TeachingTip, InfoBar y quién sabe qué sigue. Seguimos diseñando pensando solo en el control actual: ¡mala arquitectura!

Para el texto del mensaje o tip, uno se llama Subtitle y el otro Message fundamentalmente estos pueden ser los mismos, ¿por qué se usan diferentes términos además de que diferentes gerentes de proyecto están trabajando en estos controles?

En general, ¿no sería útil para los desarrolladores si los controles funcionaran de la misma manera? ¡Sí, por supuesto! ¿Significa eso que habrá el mismo control debajo de todo esto? No necesariamente, pero deberíamos usar los mismos nombres de propiedad, los mismos conceptos de botón de acción y los mismos tipos. Sin embargo, todavía espero que podamos tener una estructura de mensajes o una interfaz para unir todo. ¿No sería genial simplemente configurar un mensaje en la barra de mensajes y que se muestre en lugar de tener que configurar todas estas propiedades manualmente?

¿Cuál sería la diferencia entre una barra de información y una tarjeta de información si la tarjeta de información no fuera una ventana emergente como se describe en el documento de comparación?

Mi conclusión final de la comparación es que MessageBar/MessageCard debería ser el mismo control y también admitir el caso de uso de mi sugerencia en línea o ejemplo de sugerencia a través de la personalización del estilo.

• Es posible unificar MessageBar/MessageCard y Tip en un solo control. La única preocupación es la diferencia conceptual entre 'mensaje' y 'consejo'.
• Sin embargo, debe ser el mismo control subyacente, el estilo debe ser altamente personalizable para admitir ambos casos. La única preocupación es la diferencia conceptual entre 'mensaje' y 'consejo'. El diseño es extremadamente similar.

Editar: En general, creo que mi preocupación fundamental es que de alguna manera retrocedimos en el pensamiento arquitectónico. El diseño de control ahora se realiza como si fuera la época de Windows Forms. Los nuevos controles de UWP deben basarse en conceptos de WPF. Los controles se están volviendo altamente especializados y no veo los subprocesos unificadores que abarcan el marco que realmente "asombró" a los desarrolladores que tocaron WPF por primera vez. En mi opinión, debemos volver a la mentalidad del 'panorama general'.

Estoy 100% de acuerdo con @robloo en que los nombres de propiedad y los nombres de enumeración para cosas similares deben alinearse (en la medida de lo posible) con los controles existentes. Los controles similares deberían tener una superficie de API similar. Si se agregara una clase MessageCard en un momento posterior (en lugar de extender MessageBar, que personalmente preferiría), al menos debería tener una API muy similar a MessageBar.

Hay otras áreas donde los conceptos comunes serían mucho más útiles en mi opinión. Piense en Button, AppBarButton, MenuItem. Todos estos muestran texto y un ícono, todos se usan para desencadenar una acción. A menudo, proporciona los mismos comandos tanto en un MenuItem (ContextMenu) como en una AppBar/CommandBar. Aquí, un concepto común sería muy útil, donde podría poner su comando, texto, ícono, tal vez también un mensaje largo (información sobre herramientas).

@lukasf ¿Conoce la clase XamlUICommand ? Eso le permite agrupar estas propiedades en un solo lugar y luego asignarlas a su Button/MenuItem/... simplemente pasando su XamlUICommand definido a la API Command de estos controles.

@Felix-Dev Sí, tienes razón. Casi me olvido de eso. No lo uso porque no estaba disponible en WinUI cuando lo probé la última vez, pero también porque no es una solución completa. AppBar y ContextMenu tienen más que solo enlaces de comando. Para una solución completa, necesitaríamos:

• Comando XamlUI
• XamlToggleUICommandXamlToggleUICommand
• XamlUICommandSubItem (menú secundario/menú desplegable)
• XamlUICommandSeparatorXamlUICommandSeparatorXamlUICommandSeparator

Lo que también falta es una propiedad "Visible" y/o una propiedad "HideIfDisabled".

Entonces necesitaríamos un ItemsSource en MenuFlyout y AppBar/CommandBar y controles similares. El control de nivel superior crearía los subcontroles correspondientes para cada elemento de comando.

Solo cuando todo esto estuviera en su lugar, podríamos tener una colección de comandos en nuestra aplicación y vincularlos a MenuBar, ContextMenu, AppBar, NavigationView. Pero tal como está ahora, necesito mantener una lista de clases definidas personalizadas, implementar y usar manualmente cosas como DataTemplateSelectors y otras soluciones molestas, solo para que la misma definición de comando funcione en diferentes lugares.

XamlUICommand fue un buen comienzo, pero no es una historia completa.

Disculpas por mi demora en responder aquí, @robloo gracias por compartir tu perspectiva y la tabla de comparación de hace un par de semanas. ¡Realmente aprecio todos los pensamientos y consideraciones para mejorar WinUI! 😊

En InfoBar y en toda la plataforma, mi opinión es que, mientras diseñamos, nos esforzamos por encontrar el equilibrio adecuado para que los controles estén especialmente diseñados para escenarios específicos como un patrón de interfaz de usuario definido, mientras que son lo suficientemente genéricos y personalizables para extenderse a los escenarios que no tenemos. aún identificado. Como alguien más nuevo en el equipo, me encantaría saber por qué los controles de WinUI deberían volver a los conceptos de WPF. ¿Qué problemas cotidianos enfrentan usted y otros desarrolladores de UWP cuando los controles conceptuales similares no tienen la misma estructura subyacente? ¿Qué beneficios hay para usted para que podamos entender mejor por qué debemos dedicar recursos a la creación de esta estructura? ¿Hay otros controles en WinUI que se beneficiarían de estar unificados (veo la conversación sobre el botón arriba de @lukasf) Creo que también podemos continuar esta conversación en un nuevo problema general si hay un área donde podemos modificar los enfoques de controles/lluvia de ideas existentes para controles futuros. @SavoySchuler por cualquier aporte aquí.

Para InfoBar, todavía no preveo ningún cambio a medida que avanza en la vista previa de esta conversación. Para las API del botón de acción y el botón de cierre en particular, si hay necesidades específicas que no se satisfacen, háganoslo saber para que podamos evaluar cualquier cambio potencial. Podría anticipar que se implementará una interfaz o una clase base común de AppMessage con una v2 en asociación con un control InfoCard o como un DisplayMode separado para habilitar la funcionalidad de diseño variable 'Auto' que @mdtauk mencionó anteriormente. Además, el equipo de WinUI aún no ve el valor de alinear aún más la sugerencia de enseñanza y la barra de información en este momento, sin embargo, podemos continuar la conversación aquí para abordar esto si no se satisfacen las necesidades de uso. Una vez que InfoBar entra en vista previa y se puede implementar en las aplicaciones, sería genial escuchar cualquier escenario específico o comentarios de uso antes del lanzamiento oficial.

Como pregunta general, si tiene escenarios que coinciden con la intención de una barra de información y hay aspectos de su funcionalidad o diseño visual que no satisfacen sus necesidades, infórmenos mientras avanzamos en la vista previa. ¡Gracias de nuevo por todos sus comentarios y conversaciones!

En InfoBar y en toda la plataforma, mi opinión es que, mientras diseñamos, nos esforzamos por encontrar el equilibrio adecuado para que los controles estén especialmente diseñados para escenarios específicos como un patrón de interfaz de usuario definido, mientras que son lo suficientemente genéricos y personalizables para extenderse a los escenarios que no tenemos. aún identificado. Como alguien más nuevo en el equipo, me encantaría saber por qué los controles de WinUI deberían volver a los conceptos de WPF. ¿Qué problemas cotidianos enfrentan usted y otros desarrolladores de UWP cuando los controles conceptuales similares no tienen la misma estructura subyacente? ¿Qué beneficios hay para usted para que podamos entender mejor por qué debemos dedicar recursos a la creación de esta estructura? ¿Hay otros controles en WinUI que se beneficiarían de estar unificados (veo la conversación sobre el botón arriba de @lukasf) Creo que también podemos continuar esta conversación en un nuevo problema general si hay un área donde podemos modificar los enfoques de controles/lluvia de ideas existentes para controles futuros. @SavoySchuler por cualquier aporte aquí.

El objetivo de tener una estructura es que los programadores puedan codificar más rápido con menos errores para tener un código de alta calidad.

Debido a que gran parte de Microsoft son equipos aislados, en muchos casos hay varias formas de hacer algo, pero no hay unificación de dichos procedimientos, lo que da como resultado redundancia y trata de arreglar algo que ya está arreglado.

Después de que se creó WPF, Microsoft entró en una mentalidad de "es lo suficientemente bueno", esto se expresa directamente en la calidad de las aplicaciones, incluso de los propios equipos de Microsoft. Si las propias aplicaciones de la bandeja de entrada de Microsoft no pueden estar en la misma página con una consistencia uniforme de alta calidad en el código y la uniformidad de las aplicaciones, ¿cómo esperamos que los socios externos entreguen esto?

La entrega de código genérico pero personalizable da como resultado aplicaciones de referencia genéricas. La mayoría de los desarrolladores no harán un esfuerzo adicional para que su aplicación se vea funcional y pulida, solo harán lo suficiente para que su aplicación funcione. Este nivel de "hacer lo suficiente para que sea funcional" es recogido por el usuario final como "a medias".

En mi opinión, el objetivo de los controles es tener un código de alta calidad que pueda usar y personalizarlo si lo desea.

Dar opciones al desarrollador, sobre cómo usan los controles también tiene sus aspectos positivos, en lugar de bloquearlos en una sola forma de administrar mensajes y notificaciones.

Pero asegurarse de que cualquier opción que elijan, se vea y se comporte de una manera familiar, y "pertenezca" a Fluent Design, tiene el beneficio de la consistencia.

Entonces, si los propios controles en WinUI no brindan un enfoque unificado, quizás el kit de herramientas de Windows podría crear una API auxiliar que lo administre.

Le sugiero que lo proponga en ese repositorio, y puede usar los controles de WinUI para presentarlo en la aplicación

Hola a todos, como actualización, el control InfoBar ahora está en vista previa 🎉 Si tiene una aplicación que se beneficiaría de este control, pruébela y comparta sus comentarios con nosotros.
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
¡Gracias por todo su compromiso hasta ahora para este control!

Aquí hay otro ejemplo de una Barra/Cuadro/Tarjeta de Información

Editar: Me acabo de dar cuenta de que el siguiente problema ya está solucionado por https://github.com/microsoft/microsoft-ui-xaml/issues/3581. Ignore el problema a continuación. Gracias por hacer el control! Se ve muy bien en Nightingale :)

@gabbybilka Voy a usar la barra de información en mi aplicación de cliente Nightingale REST. Es perfecto para uno de mis escenarios. En mi prueba rápida, parece que el ícono en la barra de información no es compatible con el tema claro. O tal vez estoy haciendo algo mal en mi uso XAML del control. Aquí hay algunas capturas de pantalla

¿Consideraría agregar un evento "Abierto" al control? En algunos casos, es apropiado cerrar automáticamente la barra de información después de unos segundos. Un controlador de eventos "Abierto" sería el lugar adecuado para iniciar el temporizador.

Creo que debería cambiarse el color Success , en el Dark Theme. @YuliKl @anawishnoff @chigy @teaP
El color del tema oscuro actual es el #393D1B , que parece ser un color verde amarillento, casi de color oliva. Mientras que el tema claro usa un verde más claro, casi como el verde menta.

_Arriba los colores actuales, debajo de un cambio propuesto_

#1d3d1b

No es solo por el valor estético, sino también porque la barra de color más verde oliva no se distingue tanto del color de advertencia.

Así es como se vería