@sapallie , você poderia tornar os modelos de design acessíveis publicamente? A menos que eles não sejam compartilhados neste momento.

Atualmente fazendo desenvolvimento XAML, e adoraria ver algo assim. Ou algo como um bom controle de mensagens de rolagem.

Do ponto de vista da marca Microsoft, um banner de erro padronizado parece que pode dar terrivelmente errado. Eu temia que os usuários finais associassem cada erro de aplicativo à marca Microsoft. Acabei de ler a proposta, e a primeira coisa que me veio à mente foram memelords twittando sobre a chamativa bandeira da morte.

@sapallie , você poderia tornar os modelos de design acessíveis publicamente? A menos que eles não sejam compartilhados neste momento.

Desculpe @adrientetar , não posso compartilhá-los ainda. Os designs são apenas da Microsoft por enquanto.

@sapallie , obrigado por essa ideia fenomenal de recurso! Eu sou um gerente de programa para WinUI e estou animado para lançar isso para a equipe!

Eu queria escrever um pouco sobre o nosso processo para que você possa estar em sintonia com como vamos proceder a partir daqui. A partir de agora, trabalharei para refinar o escopo/requisitos de alto nível desta proposta e a justificativa para o desenvolvimento. Então eu vou lançá-lo para o resto da equipe WinUI e vamos deliberar se ele se alinha com o nosso Road Map (#717) e se achamos que podemos agir em breve. Nesse caso, serei aprovado para descobrir os detalhes e começar a escrever as especificações para que o recurso esteja pronto para um desenvolvedor.

Aqui estão algumas coisas que eu já sei que preciso ter um pouco mais de idéia para ...

• Comportamento visual

Sua proposta é de ponta a ponta? Ou um bloco de notificação como o que as Notificações do Windows fazem, mas na janela do aplicativo, como no centro, na borda inferior ou em um canto?

Desculpe @adrientetar , não posso compartilhá-los ainda. Os designs são apenas da Microsoft por enquanto.

Acho que não conseguiria aprovar esta proposta sem poder incluir um visual público da solicitação, pois o repositório _é_ de código aberto e o lado visual da conversa com o código-fonte fechado envolveria o processo e a experiência para nossa comunidade . Com base nas respostas acima, estou feliz em tentar elaborar uma maquete para a proposta. Você prefere isso ou tem um cronograma previsto para conceder sua permissão para tornar seu design público? Eu amo sua maquete e gostaria de tê-la incluída em nosso brainstorming aqui para que não levemos a discussão desnecessariamente para uma direção divergente da sua intenção. Por favor deixe-me saber! :corar:

O banner alertará os usuários sobre erros que os impedem de usar um aplicativo/recurso

O banner será dispensável por erros não críticos

Estou correto ao ler essas declarações para significar que você também precisa ter a opção de um banner não descartável para erros críticos? Em caso afirmativo, você poderia me contar mais sobre seu cenário de aplicativo específico para receber um/a partir do ponto de ter um banner não descartável? Os usuários são relegados a fechar o aplicativo, a menos que o problema seja resolvido? Ou é aqui que os botões chegariam, digamos, navegue até a página de configurações de Rede e Internet?

Obrigado novamente e estou ansioso para refinar essa ideia!

Todos, sintam-se encorajados a contribuir com suas necessidades, designs e perspectivas para esta conversa! :corar:

Gostaria de dizer que há algumas propostas que pedem uma coisa semelhante. Em vez de tornar isso especificamente um banner de erro - por que não apenas trazer a notificação no aplicativo do kit de ferramentas da comunidade. Pode haver uma propriedade de ícone adicionada, o que mostraria um ícone de erro ou um ícone de confirmação, etc.

@SavoySchuler – bom ouvir de você. Tentei responder a todas as suas perguntas, mas por favor me avise se precisar de mais alguma coisa.

Comportamento visual:
Idealmente, o banner seria semelhante a um bloco de notificação do Windows e seria fixado na parte superior ou inferior da janela do aplicativo. Onde está fixado depende dos outros elementos visuais no aplicativo e onde está o foco. Esta decisão deve ser feita por um designer.
Acho que o GIF que @mdtauk postou seria um ótimo ponto de partida.

Dispensando:
Acho que faria sentido aprofundar o que quero dizer com erros críticos versus não críticos:

• Erros críticos = a funcionalidade do aplicativo é prejudicada devido a um problema em todo o sistema (por exemplo, perda de conexão com a Internet) - eles devem estar vinculados às configurações do sistema, onde o usuário pode corrigir o problema
• Erros não críticos = algumas das funcionalidades estão prejudicadas ou um único recurso não funciona, mas os usuários ainda podem fazer outras coisas no aplicativo
• Também seria legal introduzir uma iteração puramente informativa do banner que pode ser usada para informar aos usuários que atualizações de aplicativos ou novos recursos estão disponíveis.

E acho que tudo isso deve ser descartável (atualizei isso na descrição da proposta também)

Exemplos de recursos visuais
Fiz algumas alterações nos visuais e posso compartilhá-los assim:

Esses exemplos são uma iteração em que o banner inteiro é basicamente um botão grande. Os usuários podem dispensá-lo ou clicar nele para acessar as configurações do sistema (erro crítico), abrir uma página da Web com detalhes sobre correções de recursos (aviso 1), recarregar a página do aplicativo (aviso 2) ou ir para a loja da Microsoft para atualizar o aplicativo (informativo).
Seria possível expandir este conceito para adicionar vários botões dentro do banner.

Eu realmente gosto desses visuais para o banner. Eu moveria o texto e o ícone para cima em 4 px, para que eles ficassem centralizados na área branca, em vez da barra branca e colorida.

Acordado. Os visuais postados parecem bem legais.

Eu realmente gosto desses visuais para o banner. Eu moveria o texto e o ícone para cima em 4 px, para que eles ficassem centralizados na área branca, em vez da barra branca e colorida.

Eu não contei os pixels, mas parece que eles estão centralizados se o espaço para marcas diacríticas acima da altura X for considerado.

@sapallie Você já pensou em permitir que esses controles sejam dispensados ​​automaticamente ou programaticamente?

Se estiver solicitando sobre estar/ficar offline, faria sentido remover programaticamente esse prompt quando estiver online novamente. (Já vi aplicativos não fazerem isso e isso pode levar a uma experiência confusa.)

Da mesma forma, ter mensagens não essenciais não exibidas indefinidamente pode evitar confusão desnecessária da interface do usuário e pode impedir que usuários avançados precisem sair do fluxo depois de ler uma mensagem, não forçando-os a descartar manualmente a notificação.

Eu entendo que existem considerações extras de acessibilidade em torno de tal controle e esses comportamentos, mas acredito que essas formas de dispensar o controle são essenciais.

Acho importante ressaltar que esse controle não se destina a mensagens gerais em um aplicativo. A menos que seja realmente um caso de uso desejado.

Um aplicativo deve ter permissão para exibir vários banners ao mesmo tempo?
Se sim, como serão organizados? E isso é algo que o aplicativo pode controlar?

Isso satisfaria aqueles que solicitaram um estilo Android Toast no controle de notificação de aplicativos, também poderia ser útil para cenários de validação, para exibir texto de erro onde o espaço no formulário é valioso.

Eu também chamaria de algo como StatusTip ou StatusNotification para que não seja associado apenas a usos negativos.

Suponho que o design se adaptaria alterando o posicionamento na barra de cor sólida quando ela é colocada na parte inferior da janela?

Ele provavelmente deve ter uma propriedade de tempo limite e pode até ter a capacidade de mostrar uma mensagem pendente, como um anel de progresso e algum texto como "Efetuando login agora" antes de alternar para uma mensagem de confirmação de erro.

Eu realmente gosto desses visuais para o banner. Eu moveria o texto e o ícone para cima em 4 px, para que eles ficassem centralizados na área branca, em vez da barra branca e colorida.

Eu não contei os pixels, mas parece que eles estão centralizados se o espaço para marcas diacríticas acima da altura X for considerado.

Acho que era mais provável que o texto estivesse centralizado verticalmente na caixa sem levar em conta a barra colorida

Aqui está como o posicionamento da barra colorida pode mudar com o posicionamento do controle

@mrlacey sim, dispensa programática/automática para quando o banner não for mais relevante é muito importante – adicionei na descrição da proposta.

Mudanças de status e erros: É para isso que os banners devem ser usados. Não mensagens gerais – eu concordo com isso.

E acho que vários banners devem funcionar. Eles devem apenas ser empilhados.

@mdtauk eu o renomeei como “Status banner” – obrigado por suas sugestões.

Para o estado de carregamento – não acredito que isso deva acontecer no banner. O carregamento de conteúdo deve ser exibido no aplicativo onde o conteúdo realmente apareceria.

E quando se trata de alterar o posicionamento da barra colorida – seria ótimo ter flexibilidade dependendo de onde o banner de erro é colocado na janela do aplicativo. 👍

As edições #622 e #792 também poderiam ser cobertas por este controle, caso ele fosse construído.

@sapallie Sua observação sobre circunstâncias críticas de erro é interessante com relação à orientação sugerida de que os banners de status apontam o usuário para uma solução. Minha intuição está dizendo que você também pode precisar de uma API para desabilitar, ou pelo menos descartável temporariamente?

Eu entendo que existem considerações extras de acessibilidade em torno de tal controle e esses comportamentos, mas acredito que essas formas de dispensar o controle são essenciais.

@mrlacey , ótimo texto explicativo! Felizmente, eu trabalhei com uma parte significativa disso durante a consideração da dispensa automática cronometrada no TeachingTip e, embora algumas parcerias com equipes que possuem configurações de acessibilidade sejam necessárias, não acredito que esse recurso seja bloqueado devido a questões de acessibilidade. +1 em todos os seus outros pontos!

Poderia haver a capacidade de adicionar um HyperlinkButton vinculando a uma solução ou a um atalho de configurações, como Rede?

Poderia haver a capacidade de adicionar um HyperlinkButton vinculando a uma solução ou a um atalho de configurações, como Rede?

Eu estava imaginando o subtexto contendo um hiperlink para um aplicativo no aplicativo ou Configurações (consulte a página Código de galeria do Xaml Control do TeachingTip). Estava pensando em algo mais padronizado @mdtauk?

@SavoySchuler Propriedade de conteúdo em vez de MessageText?

Sua observação sobre circunstâncias críticas de erro é interessante com relação à orientação sugerida de que os banners de status apontam o usuário para uma solução. Minha intuição está dizendo que você também pode precisar de uma API para desabilitar, ou pelo menos descartável temporariamente?

Sim, possivelmente eu acho… Definitivamente não faz mal adicioná-lo. Afinal, ele adiciona flexibilidade e provavelmente será bastante útil para alguns casos de uso.

@mdtauk - Sim, certamente quero dizer propriedade de conteúdo!

@sapallie

Sua observação sobre circunstâncias críticas de erro é interessante com relação à orientação sugerida de que os banners de status apontam o usuário para uma solução. Minha intuição está dizendo que você também pode precisar de uma API para desabilitar, ou pelo menos descartável temporariamente?

Sim, possivelmente eu acho… Definitivamente não faz mal adicioná-lo. Afinal, ele adiciona flexibilidade e provavelmente será bastante útil para alguns casos de uso.

Por um lado, você tem um pop-up não descartável cobrindo a interface do usuário (e possivelmente causando seu próprio erro baseado em cenário ao fazê-lo) e, por outro, você tem um aviso / erro crítico do aplicativo que não é persistente, o que também torna meus sentidos de aranha formigam.

Talvez, em vez de um pop-up de interface do usuário + estilo de ponta, um banner na interface do usuário + de ponta a ponta (como o que é usado pelo Office Suite para notificar atualizações - veja abaixo) atender às necessidades e também ser ofereceu espaço persistente em sua interface do usuário?

@SavoySchuler Pode haver um comportamento no controle, onde ele coloca o cabeçalho e o conteúdo em uma única linha, se a largura do controle for grande o suficiente.

Minha sugestão anterior com os diferentes layouts de posicionamento também funcionaria se o controle deslizasse para fora da borda de outro controle - não apenas dentro da janela ou painel.

Talvez, em vez de um pop-up de interface do usuário + estilo de ponta, um banner na interface do usuário + de ponta a ponta (como o que é usado pelo Office Suite para notificar atualizações - veja abaixo) atender às necessidades e também ser ofereceu espaço persistente em sua interface do usuário?

Sim, isso também funciona. 👍

Parece que seria ideal ter opções em linha e de sobreposição, pois, em retrospectiva, o Office Suite pode contar com todos os seus aplicativos com uma faixa de opções. @mdtauk Eu gosto da sua sugestão que está começando a sugerir como pensamos sobre o comportamento de aparência/desaparecimento.

@all , alguém pode compartilhar comigo cenários específicos em seus aplicativos reais em que você imagina esse controle sendo usado? Especificamente, estou interessado em pensamentos sobre a entrada visual e a interação do usuário necessária para solicitar a demissão? Os requisitos aqui cobrem os principais comportamentos que você precisa desse controle?

@SavoySchuler Considerando entrada e saída, ele pode deslizar de uma borda, mas também animar como uma sobreposição flutuante, se o desenvolvedor escolher. Deslizando da borda direita da tela no nível do sistema operacional - da borda direita de uma janela de aplicativo ou da borda de um controle ou elemento de interface do usuário.

Há um botão de fechamento para dispensa, mas para telas sensíveis ao toque, a capacidade de deslizá-lo na direção inversa de onde surgiu também pode funcionar. Para garantir a consistência, isso precisa ser incorporado ao controle.

Tocar no controle provavelmente deve acionar uma ação que o texto da mensagem especificaria.
A exceção seria para exibir o progresso de uma ação que não seria dispensada até que o tempo limite com um erro ou seja concluído com êxito.

Exemplos animados

Entrar, atualizar, sair - Link do YouTube

Animar em - Link do YouTube

O TeachingTip existe e é uma boa maneira de direcionar um controle específico ou elemento de interface do usuário e bom para destacar um novo recurso em um aplicativo. Tecnicamente, ele pode ser usado para os mesmos propósitos que este StatusBanner, portanto, é necessário pensar no uso semântico de cada um deles e identificar o que torna cada um único.

Abaixo estão meus pensamentos pessoais sobre a diferenciação entre Banner de Status e Dica de Ensino

• O banner de status _eu acredito_ deve ser incentivado para status acionáveis ​​reais e, portanto, deve invocar uma única ação quando tocado.

  • A dica de ensino apresentaria ações como um botão ou hiperlink, normalmente usado para informações que podem ser prontamente descartadas.

• Quando a condição de um aplicativo ou sistema operacional muda, isso é necessário para o aplicativo, então isso deve acionar um Banner de status para mostrar.

  • A dica de ensino não forneceria informações críticas e, uma vez dispensada, não seria exibida novamente, a menos que algo novo fosse adicionado para ser chamado.

• O banner de status deve persistir ao ser exibido, a menos que seja dispensado com o botão Fechar, ou talvez um deslize quando em contato. Com exceção da conclusão de um cenário de progresso contínuo ou do status do sistema operacional resolvido (a rede é restaurada).

  • A dica de ensino possivelmente incluiria uma função de tempo limite, não seria exibida aleatoriamente enquanto o aplicativo estivesse em execução, principalmente exibida na inicialização do aplicativo ou na navegação para uma página/tela.

• Status Banner deve ser usado no OS Shell de forma consistente - pode haver um conjunto de banners localizados padrão com conteúdo, ícones, cores, como uma enumeração.

• Pode haver alguma lógica do sistema operacional para anexar banners de status às janelas do aplicativo.
  Por exemplo, quando um aplicativo tenta acessar a rede e não está disponível, o sistema operacional pode mostrar um banner de status padrão na janela do aplicativo, em vez de no espaço da tela, ou deixá-lo para os desenvolvedores implementarem.

  • A dica de ensino seria específica do aplicativo e sem conteúdo padrão definido, e para o desenvolvedor incluir sozinho.

@mdtauk , trabalho fantástico nos vídeos! 🎉 Eles são muito úteis para dar vida a essas ideias.

A necessidade de persistência é um ponto excelente e acho que o recurso de descarte também pode ser mitigado com Diretrizes que sugerem tornar as notificações de status persistentemente disponíveis em um painel de notificação se forem críticas ou, possivelmente, ressurgindo-as em intervalos não invasivos se os problemas persistirem. Essas não são afirmações definitivas, apenas pontos a serem considerados para garantir que esta solução seja adequadamente abrangente em sua solução de cenário.

A necessidade de distinguir o TeachingTip desse recurso está no local e concordo com seus pontos. Esse controle atenderia a uma necessidade distinta que o TeachingTip não foi projetado para resolver, embora possa haver oportunidade para alguns recursos ou códigos compartilhados.

Existem partes interessadas que não teriam suas necessidades atendidas por algo como o que @mdtauk compartilhou acima?

Parece haver diferenças entre os Banners de Status simulados no OP e a notificação de largura total como visto no Office (imagens acima em comentários anteriores) ou no Visual Studio (como abaixo)

As diferenças entre os dois significam que eu me pergunto se eles devem ser o mesmo controle ou separados.

Aqui está uma lista rápida de propriedades que cada um precisaria. (nomes, por exemplo, não fixos, mas destinados a inferir significado)

Faixas de status

• _Ícone_
• Mensagem de texto
• Texto adicional (segunda linha)
• Tipo (Crítico, Aviso ou Informação)
• Cor
• Localização
• Direção de Animação
• Toque em Evento/Comando
• Tempo esgotado

Notificações de largura total

• _Ícone (possivelmente)_
• Mensagem de texto
• Estilo de link (botão ou hiperlink)
• Links (Texto e Toque em Evento/Comando - vários)
• Tempo esgotado

Apenas as propriedades em negrito existem em ambos. _Icon_ é potencialmente confuso, pois diferentes tipos de ícone (em um círculo ou contorno) são necessários para cada tipo.
Também precisaria haver uma propriedade para indicar qual estilo usar.

Para mim, parece que há muita diferença para um único controle e juntar todas essas funcionalidades seria confuso e complicado.
Acho que esses dois conceitos:

• um banner de largura total dispensável com zero ou mais subelementos acionáveis
• um banner destinado a indicar mudanças de status e que funciona como um único botão

fornecerá o maior valor e menos confusão como controles separados.

Como os banners de status animados suportariam a exibição de várias notificações ao mesmo tempo?
Ou isso está agora fora do escopo?

• Status Banner deve ser usado no OS Shell de forma consistente - pode haver um conjunto de banners localizados padrão com conteúdo, ícones, cores, como uma enumeração.
• Pode haver alguma lógica do sistema operacional para anexar banners de status às janelas do aplicativo.
  Por exemplo, quando um aplicativo tenta acessar a rede e não está disponível, o sistema operacional pode mostrar um banner de status padrão na janela do aplicativo, em vez de no espaço da tela, ou deixá-lo para os desenvolvedores implementarem.

Esse nível de integração do SO mostra ambição além de um único controle e além do WinUI.

Os "banners localizados padrão" seriam tudo o que está disponível ou seriam além de poder ter algo totalmente personalizável?
Se fornecer alguns por padrão, quais serão?
Eu estaria preocupado que apenas fornecer um conjunto limitado de opções seria desnecessariamente limitando o potencial de tal controle.

Fazer com que o sistema operacional mostre banners no aplicativo aberto para cenários de todo o sistema, como perda de conectividade de rede, levanta várias preocupações para mim.

• O centro de ação já fornece uma maneira de fornecer notificações em todo o sistema.
• Com várias janelas abertas, ver banners exibidos em cada uma parece desnecessariamente intrusivo.
• Ter o sistema exibindo notificações (banners) dentro de um aplicativo é algo que eu esperaria que os desenvolvedores quisessem controlar ou desabilitar.
• Se um aplicativo precisar de uma conexão de rede apenas ocasionalmente, ver um aviso sobre uma perda de conexão pode ser desconcertante ou perturbador para o usuário, se não for relevante para o que ele está fazendo no momento.
• Isso vincularia aplicativos a versões específicas do sistema operacional para obter atualizações ou comportamento desejado. Uma alteração futura na função do sistema operacional pode interromper ou alterar um aplicativo de maneiras indesejáveis.
• Atualizações e correções de bugs só estariam disponíveis em cronogramas de lançamento de nível de sistema operacional. Parte da razão por trás da existência do WinUI é quebrar esse acoplamento com o sistema operacional e a funcionalidade do aplicativo.

• Um dos objetivos de tal controle, conforme descrito aqui, é facilitar a implementação para os desenvolvedores. A remoção de sua capacidade de controlá-lo causaria problemas para aplicativos em que cenários específicos devem ser tratados de maneira personalizada.

Acabei de encontrar este problema no post do Twitter sobre os modelos animados. Parece sobrepor muito do trabalho que fizemos com o controle InAppNotification no kit de ferramentas. Incluindo coisas como como várias mensagens são tratadas.

Aprendemos que, embora pareça um controle simples, é bastante complexo. Seria bom ter uma solução holística que pudesse ser incorporada ao WinUI para cobrir todos esses casos. Em seguida, podemos descontinuar o controle do kit de ferramentas.

Conferindo com @ryandemopoulos , e quero refatorar um pouco essa conversa inicial para focar no problema (necessidade de IU de erro) antes da solução (qualquer parte/partes específicas de IU de erro).

Para esse fim, meu primeiro objetivo é bloquear os cenários e requisitos para a interface do usuário de erro ( @sapallie , seu cenário "Crítico: perda de conectividade wifi" é um começo perfeito). A partir daí, podemos trabalhar juntos para decidir se a solução inclui uma parte da interface do usuário de notificação de erro ou um conjunto de componentes da interface do usuário de erro. A partir disso, expandiremos o detalhamento da similaridade da API de @mrlacey (obrigado por iniciar isso) para decidir se há semelhança suficiente para uma abordagem de derivação versus controles distintos se houver várias saídas dessa conversa. Eu não quero me adiantar, mas o argumento de @mrlacey para soluções distintas _está_ já parecendo nítido e tudo bem. Meu foco é criar o conjunto certo de peças de solução para todos aqui.

Portanto, para qualquer pessoa ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev , @mdtauk e @mrlacey ) para quem esse controle é particularmente relevante, você poderia me fornecer o seguinte aqui ou dm @ [email protected] :

• Título do aplicativo
• Descrição do cenário (erro, crítico/não crítico e descrição de como você gostaria de apresentá-lo)
• Captura de tela da tela do aplicativo onde o erro apresentaria (se disponível)

Atualizei o problema para refletir essa abordagem focada no problema e cataloguei os requisitos, cenários e possibilidades de solução descritos até agora.

@sapallie , tentei ser cortês ao máximo para preservar seu trabalho inicial. O histórico de versões pode ser visualizado no menu suspenso "editado por..." na parte superior da edição. Por favor, deixe-me saber se eu não capturei nada corretamente.

Eu lancei isso para a equipe do WinUI e acreditamos que a funcionalidade definida aqui seria capaz de servir não apenas mensagens de erro, mas mensagens de status de todo o aplicativo de longa duração como um todo. Isso inclui mensagens de status do tipo "atualização disponível" e "backup completo", além de cenários específicos de erro.

Atualizei a edição para refletir essa abordagem mais holística. Espero finalizar os requisitos e cenários nas próximas semanas para que possamos examinar as partes de saída da interface do usuário necessárias para exibir essas mensagens.

Vou reformular meu pedido acima. @sapallie , @adrientetar , @EverydayApps @Felix-Dev , @mdtauk e @mrlacey , para mensagens de status/erro que você deseja exibir em seus aplicativos, você pode me fornecer o seguinte aqui ou em [email protected] :

• Título do aplicativo
• Descrição do cenário (mensagem de status, crítica/não crítica e descrição de como você gostaria de apresentá-la)
• Captura de tela da tela do aplicativo onde o erro apresentaria (se disponível)

Vale a pena notar que, imo, as caixas de diálogo pop-up devem ser evitadas, se possível. A web está cheia de avisos pop-up em todos os lugares e eles interrompem o fluxo tentando chamar sua atenção. Por exemplo, acho que o status vazio ( exemplo ) deve ser preferido, por exemplo, se algo não puder ser carregado em um controle.

Com relação aos visuais que @mdtauk postou, realmente precisamos de pop-ups exibidos em todas as quatro bordas da tela/aplicativo? O objetivo do WinUI deve ser padronizar a posição e a aparência desses itens para que todos os aplicativos usem o mesmo e, nesse aspecto, o Android Snackbar é uma referência óbvia. Outra coisa a notar com o Snackbar é não exibir erros com uma cor vermelha brilhante ou qualquer coisa, tem uma aparência sóbria que eu acho que é novamente benéfica para não distrair muito o usuário do que ele está fazendo.

Também precisaremos de orientação sobre quando usar esse pop-up em vez de uma caixa de diálogo, por exemplo, caso contrário, ele apenas criará fragmentação (aplicativos diferentes usando os controles de mensagens de maneiras diferentes).

Flyouts têm um conceito de posicionamento, esse controle pode fazer a mesma coisa. Aparece a partir da borda interna de um controle de contêiner, seja uma página ou conteúdo de guia, etc.

@adrientetar Nem todos os aplicativos são iguais, portanto, embora haja um padrão para esse controle, é necessário que os desenvolvedores alterem esse local, sem precisar refazer o modelo ou reprojetar o controle.

O Office usa o espaço abaixo da Faixa de Opções. O Edge usa a parte inferior da tela. Somente o próprio Windows seria capaz de anexá-lo às bordas do Shell ou da tela, e provavelmente há um bom motivo para impedir que os aplicativos imitem os alertas no nível do sistema.

Além disso, qualquer desenvolvedor tem a capacidade de alterar o estilo de seus próprios controles de alerta, portanto, neste estágio, ele precisa ser o mais flexível possível e, em seguida, a equipe do Shell terá alguma opinião sobre quais restrições são aplicadas ao uso do controle.

A equipe Your Phone tem um desses tipos de controles, então talvez você possa perguntar a eles quais problemas eles encontraram e convencê-los a usar o controle WinUI quando estiver pronto e incluído?

O Dropbox também usa o Snackbar em seu sistema de design (role para baixo, penúltima linha de imagens).

Recentemente, vimos mais alguns exemplos de mensagens de status de longa duração em todo o aplicativo:

(mensagem "gravação iniciada" no Teams)

("tentando se conectar ao coordenador do jogo" no Dota 2)

Desculpe, estas são pequenas - a primeira foto foi tirada da minha área de trabalho com um monitor ultrawide. :)

Algumas barras de dropbox contêm uma barra de progresso na parte inferior. Isso deve ser incluído aqui? Pode fazer sentido, por exemplo, para coisas como upload, download, atualização, progresso de sincronização. Não é uma imo obrigatória, mas talvez possa ou deva?

Devem ser arredondados? Ou não?

Sim, acho que a principal diferenciação aqui da dica de ensino é que os aplicativos desejam coordenar seu espaço de mensagens e podem ter várias atualizações de erro/status para exibir ao mesmo tempo (ou em sucessão).

Eu acho que idealmente, este é um controle que o desenvolvedor configura e coloca em seu aplicativo e, em seguida, envia mensagens também (que eu imagino ter algum tipo de tipo para indicar se é erro, status, aviso ou alguma outra mensagem geral).

Tanto no caso do banner quanto no pop-up, vi aplicativos que podem ter várias mensagens. Às vezes, eles empilham os banners que dominam o espaço da interface do usuário, então seria bom se essa solução evitasse isso (embora nada impeça um desenvolvedor de usar várias instâncias do controle para recriar esse comportamento ainda).

Estou surpreso que também não tenhamos chamado o VS Code, pois eles têm seus painéis de notificação pop-up empilhados no canto inferior direito, que também possuem botões de ação adicionais (para pular para as configurações, por exemplo).

Captura de tela de exemplo de código VS:

Eles têm diferentes tipos de ícones que aparecem no canto superior esquerdo, ações de botão personalizáveis ​​e a capacidade de ter o ícone de 'engrenagem' para definir configurações sobre as notificações por extensão, no caso deles.

Acabei de ver esta captura de tela da Cortana ...

A MessageBar do Office UI Fabric parece ótima, IMO:

notei que o Samsung Notes para Windows 10 usa brindes de notificação para explicar que uma nota foi descartada porque não havia nada nela que fosse tão irritante

Olá a todos! Eu sou um gerente de programa para WinUI e estou pegando esta proposta de volta do @SavoySchuler. Já houve muita discussão e compartilhamento de ideias neste tópico, obrigado por todas as suas sugestões!

Como já se passaram vários meses desde que houve alguma atividade aqui, eu queria verificar com todos e reiterar onde estamos atualmente.

Como um resumo do nosso escopo atual no topo da proposta:

• A notificação será para alertar o usuário de informações essenciais relacionadas ao aplicativo como um todo
• Suportará conteúdo e estilo personalizados
• Poderá ser dispensado automática e programaticamente
• A notificação deve poder ser dispensada pelo usuário
• Deve suportar várias notificações que podem ser empilhadas de acordo com a especificação do aplicativo
• Deve ser responsivo ao redimensionamento do aplicativo e às alterações da interface do usuário
• A notificação não será para exibir notificações em todo o sistema

Por favor, sinta-se à vontade para comentar e deixe-me saber se eu perdi alguma coisa no meu resumo do escopo ou se você discorda. Quero ter certeza de que estamos todos na mesma página antes de seguir em frente 😊

Agora que definimos o escopo, há alguns cenários específicos e experiências do usuário que ainda precisam ser definidos. Minha esperança é que a definição dessas experiências ajude a orientar as possibilidades de UI para o controle. Quais são seus pensamentos para seus cenários?
CC: @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

As experiências são:

• Como a notificação sai da visualização
  
  
  
  • O usuário descarta manualmente a notificação
  
  
  • A notificação expira automaticamente e é dispensada
  
  
  • A notificação só desaparece depois que o usuário fez uma ação relacionada ao motivo pelo qual a notificação apareceu em primeiro lugar
    
    
    
    
    
    • ou seja, após receber uma notificação de que a internet foi desconectada, a notificação só desaparece quando a internet é desconectada
    
    
    
  
  
  • De outros?
  
  
• Como o usuário reagirá à notificação
  
  
  
  • Agir imediatamente em relação à notificação
  
  
  • Adiar sua ação relacionada à notificação para um momento posterior
  
  
  • Ignorar e/ou descartar totalmente a notificação
  
  
  • De outros?
  
  
• Quando a notificação aparecerá
  
  
  
  • No lançamento do aplicativo
  
  
  • Programaticamente a partir do status do aplicativo
  
  
  • Depois que um usuário fizer uma ação (ou seja, optar por fazer backup de seus documentos)
  
  
  • De outros?
  
  
• Se for possível que várias notificações apareçam ao mesmo tempo e por quê

Obrigado novamente por todos os seus pensamentos e estou ansioso para trazer isso à luz!

Fico feliz em ver que esta proposta não foi esquecida @gabbybilka e obrigado por aceitar!

Se for possível, você pode entrar em contato com aqueles que trabalham em aplicativos primários que incluem esses tipos de UIs de notificação para fazer uma lista de requisitos, para que eles passem de sua solução personalizada para um controle nativo do WinUI. Suas necessidades, combinadas com os desejos e necessidades da comunidade, devem cobrir o suficiente para uma V1 desse controle.

@chigy seria alguém para conversar sobre especificações finais de design, pois ela trabalha com as equipes de Fluent Design.

A Microsoft deve dar o exemplo com isso, se outros devem ser incentivados a usar um controle WinUI consistente.

• Cortana
• Música Groove
• Cinema e televisão
• Seu telefone

Esses são os aplicativos que vêm à mente.

@gabbybilka , também temos o controle no Windows Community Toolkit , muito feliz em falar sobre isso com você a qualquer momento. Seria muito bom ter um caminho de atualização para nossos usuários aqui e migrá-lo do Toolkit para o WinUI.

Eu acho que do seu resumo inicial que tem a maioria das coisas cobertas, mas poderia ser bom chamar algo sobre ter botões opcionais e acionáveis ​​também? Ou isso sempre seria apenas conteúdo personalizado?

Acompanhamento do kit de ferramentas com algum histórico do controle do kit de ferramentas (já faz um tempo):

• Edição original
• Primeira revisão de relações públicas
• GitHub History - não tenho certeza de como obter a lista completa em uma página, então role para baixo e continue clicando em 'Older'

Os estilos no kit de ferramentas são modelados de acordo com os estilos de notificação originais do Microsoft Edge e do VS Code (ambos atualizados desde então). Mas, como mostrado, é flexível e re-modelável e funcionaria tanto para um aviso no estilo do Office da barra de status de nível superior OU para uma notificação geral no estilo pop-up.

Olá de novo! Como uma atualização sobre isso, recentemente relançei essa proposta para a equipe e recebi o aval para definir melhor esse recurso.

Para os cenários descritos anteriormente, estamos procurando avançar com a criação de um controle atualmente intitulado InformationBar (InfoBar para abreviar) para representar mensagens de status essenciais de longa duração, em todo o aplicativo. O pensamento de design visual inicial é inspirado no MessageBar do FluentUI e em como o Teams exibe suas mensagens "Agora gravando" e "Internet desconectada".
Especificamente, incluindo um ícone, título, área de mensagem flexível e botão de dispensa como componentes visuais primários e mínimos em um contêiner que se ajusta à largura da área de conteúdo em que reside. o usuário ou programaticamente quando a funcionalidade do aplicativo que afeta o status é resolvida, ou seja, a conectividade com a Internet é restaurada, sem animações de introdução/saída.

Equipes (agora gravando)

Office (modo de compatibilidade)

Equipes (sem internet)

À medida que a API começar a se cristalizar, começarei a orientar a discussão sobre as especificações. Enquanto isso , sinta-se à vontade para continuar compartilhando seus cenários onde você usaria uma InfoBar e qual funcionalidade você precisa 😊

No início da discussão , @mrlacey e outros levantaram o potencial de ter dois controles separados que poderiam cobrir os cenários mencionados.

Acho que esses dois conceitos:

• um banner de largura total dispensável com zero ou mais subelementos acionáveis
• um banner destinado a indicar mudanças de status e que funciona como um único botão

fornecerá o maior valor e menos confusão como controles separados.

Reconheço que o estilo visual e os componentes da InfoBar podem não se encaixar em alguns dos casos de uso compartilhados anteriormente. Se seus cenários e funcionalidades de aplicativos específicos exigirem um estilo visual diferente, sinta-se à vontade para continuar compartilhando essas situações neste tópico.

Obrigado novamente a todos!

O controle deve ser projetado para funcionar bem com modelos e estilos - para que possa ser moldado para atender às necessidades, enquanto todos os comportamentos são propriedades do controle.
Animar ou Não Animar.
Mostrar botão Fechar ou Ocultá-lo.
Posição.
Mostrar ícone ou não.

etc

Reconheço que o estilo visual e os componentes da InfoBar podem não se encaixar em alguns dos casos de uso compartilhados anteriormente. Se seus cenários e funcionalidades de aplicativos específicos exigirem um estilo visual diferente, sinta-se à vontade para continuar compartilhando essas situações neste tópico.

Obrigado novamente a todos!

É ótimo daqui pra frente. Esse estilo visual, como mostrado, deixa muito a desejar a ponto de eu não querer usar o aplicativo.

Os designs que @mdtauk postou ou as capturas de tela da Cortana acima seriam muito mais preferíveis. Os designs de aplicativos precisam avançar e não serem retidos por programas.

Isso também funcionaria como um CommandBar descartável, como os usados ​​durante a apresentação/compartilhamento da área de trabalho? Por exemplo

Eu sei que não suportaria a sobreposição sobre tudo, mas em termos de corrigir sua largura e colocá-la em uma camada de sobreposição de um aplicativo, pude ver a sobreposição no design/funcionalidade sendo semelhante nessa direção.

@mdtauk

O controle deve ser projetado para funcionar bem com modelos e estilos - para que possa ser moldado para atender às necessidades, enquanto todos os comportamentos são propriedades do controle.
Animar ou Não Animar.
Mostrar botão Fechar ou Ocultá-lo.
Posição.
Mostrar ícone ou não.

@shaheedmalik

É ótimo daqui pra frente. Esse estilo visual, como mostrado, deixa muito a desejar a ponto de eu não querer usar o aplicativo.

Os designs que @mdtauk postou ou as capturas de tela da Cortana acima seriam muito mais preferíveis. Os designs de aplicativos precisam avançar e não serem retidos por programas.

Obrigado pelo seu feedback lá! Concordo que o controle deve ser flexível o suficiente para esse comportamento básico e personalização no sistema Fluent Design. Os visuais que compartilhei eram principalmente referências de exemplos implementados anteriormente.
Continuaremos tentando encontrar o equilíbrio entre sobrecarregar um único controle com muita funcionalidade, garantindo sua personalização e utilidade o suficiente para os vários cenários de mensagens de status de todo o aplicativo de longa duração.

Isso também funcionaria como um CommandBar descartável, como os usados ​​durante a apresentação/compartilhamento da área de trabalho? Por exemplo

@michael-hawker

Eu acho que este é um cenário interessante ainda não mencionado no segmento e poderia ser suportado por este controle. Obrigado por trazê-lo para a nossa atenção! Em relação ao escopo, este parece ser um cenário de menor prioridade, mas concordo que o design/funcionalidade é semelhante fora da priorização de sobreposição.

Existe alguma atualização sobre este assunto? No momento, estamos planejando uma interface do usuário para exibir o status das operações de arquivo em Arquivos UWP, o design para o qual estamos inclinados pode se beneficiar de tal recurso proposto aqui.

Olá @yaichenbaum , obrigado por fazer o check-in! Como atualização desta proposta, tenho o prazer de compartilhar o documento de especificações que estamos começando a redigir.

Como resumo do que foi definido até agora estamos optando por criar um único controle com dois modos visuais, "Bar" e "Toast" ou "Card". Nossos esforços atuais estão na definição e prototipagem do modo "Bar". Os componentes desses dois modos são os mesmos e estão planejados para diferir apenas no layout visual. Como haverá vários modos visuais, atualmente estou considerando esse controle StatusBanner em vez de InformationBar para não restringir ao estilo único "Bar", no entanto, sinta-se à vontade para compartilhar suas ideias de nomenclatura 😊

Os principais componentes do StatusBanner da esquerda para a direita no layout são:

• Cor do estado
• Ícone
• Título
• Mensagem
• Botão de ação
• Botão Fechar

Essas propriedades são opcionais e o conteúdo personalizado por meio da propriedade "Conteúdo" ainda é uma opção.

Além disso, estamos planejando definir vários BannerTypes que um desenvolvedor pode definir com combinações de ícones e cores predefinidas, dependendo do status. Isso pode simplificar a escolha do Icon ou BannerColor correto com base na criticidade da notificação e fornecer alguma consistência entre os aplicativos. A personalização do ícone ou BannerColor também é suportada.

Protótipo de papel do StatusBanner em modo "Bar" sem botão de ação ou botão de fechamento personalizado.

O design atual dos layouts da barra StatusBanner foi fortemente inspirado nos designs de @mdtauk para o cartão de status, obrigado!

Se você quiser compartilhar comentários sobre o estado atual da especificação, sinta-se à vontade para comentar nesta edição. Nossos próximos passos são solidificar os designs e trechos de código (e expandir para cobrir mais casos de uso) e definir funcionalidades como empilhamento e quebra de mensagens. Obrigado a todos!

@yaichenbaum enquanto isso, há o controle InAppNotification do Toolkit.

@gabbybilka Obrigado pela atualização, um recurso importante que precisarei para o meu caso de uso é a capacidade de mostrar várias mensagens de status ao mesmo tempo, assim como @hawkerm compartilhado anteriormente neste tópico. Ter o controle lidando com o posicionamento de várias mensagens de status será uma vantagem.

@yaichenbaum enquanto isso, há o controle InAppNotification do Toolkit.

@hawkerm Eu não olhei muito para o InAppNotification mas prefiro esperar pela versão WinUI em vez de mudar para o novo controle quando estiver pronto.

Olá a todos!
Pedimos desculpas pela falta de tempo entre a última atualização e agora, estamos trabalhando duro para definir esse controle 😊
Você pode ter visto o protótipo do @chenss3 se fundir no repositório algumas semanas atrás, estamos muito animados para ver isso ganhar vida! Nesta fase, estamos interessados ​​em nos conectar com quaisquer consumidores desse controle que tenham interesse em prototipar e usar isso em suas aplicações. Entre em contato e compartilhe qual aplicativo você está desenvolvendo, os cenários em que você está usando esse controle, se precisar de ajuda para começar e seus comentários sobre o protótipo.

Como começamos a descobrir detalhes de implementação para uma versão pop-up desse controle com suporte para posicionamento e empilhamento de várias notificações, decidimos continuar trabalhando em uma versão em linha para um futuro próximo . Ouvimos seus comentários sobre a necessidade de funcionalidade de pop-up para alguns de seus cenários e continuaremos avançando nessa direção! Enquanto isso, estamos desenvolvendo nossa próxima versão do protótipo que se assemelha mais aos modelos abaixo.

Confira a especificação se quiser ver mais alguns exemplos:

Obrigado a todos e estou ansioso para ouvir de você!

Isso está disponível apenas no WinUI 3 ou está entrando em um pré-lançamento do WinUI 2?

@kmgallahan WinUI 2 pré-lançamento, ainda não tenho certeza da versão exata do navio, pois queremos receber um pouco mais de feedback da comunidade e dos clientes sobre as versões de protótipo e visualização.

Para maximizar o feedback inicial, recomendo tornar o mais fácil possível experimentar protótipos como este. Talvez empurre-os para compilações de pré-lançamento com isenções de responsabilidade ou forneça versões dev/beta.

Ser obrigado a construir uma ramificação de desenvolvimento do WinUI para experimentar protótipos fornece um bom atrito, especialmente se você for principalmente um consumidor de WinUI em vez de um colaborador (para a base de código de qualquer maneira).

De acordo, uma vez que o protótipo está em um estado sólido (parecido com os modelos mostrados e com suporte para diferentes opções de entrada), gostaríamos de colocá-lo na visualização 2.5. Você seria capaz/interessado em experimentá-lo naquele momento?

Estou interessado em experimentá-lo agora, prefiro consumir do NuGet em vez de adicionar um projeto enorme como o WinUI à minha compilação.

Por enquanto vou esperar o que quer que seja uma prévia.

Olá de novo! Algumas atualizações:

• A especificação continuou a ser revisada e iterada. Por favor, sinta-se à vontade para conferir neste PR e deixar comentários. Uma mudança notável é a adição de uma propriedade ActionButton genérica que receberá seu próprio conteúdo que herda de ButtonBase.

  • Uma inconsistência nas maquetes atuais que gostaria de apontar é a localização deste ActionButton. Na especificação, o botão de ação é mostrado alinhado à direita diretamente à esquerda do botão Fechar, mas a localização real será diretamente à direita da mensagem. A imagem mostrada no meu comentário anterior e abaixo é o local correto. Maquetes aprimoradas continuarão sendo atualizadas e adicionadas às especificações à medida que o desenvolvimento continuar 😊

• O @teaP implementou a versão nativa desse controle à medida que avança para um pré-lançamento do WinUI 2.5 . Obrigado!

Como antes, se você se considera um usuário em potencial desse controle, sinta-se à vontade para comentar sobre o aplicativo que está desenvolvendo e os cenários nos quais você usaria a InfoBar. Obrigado a todos!

Olá de novo! Apenas para destacar, @teaP abriu recentemente o pull request #3325 para InfoBar se você quiser dar uma olhada 😊

Por que isso é chamado de InfoBar? Info é apenas uma pequena classe de informação que pode conter. Ele também suporta erros e avisos, além de ações baseadas neles. A barra também está restringindo artificialmente a 'forma' do controle. Existem vários outros casos de uso para ele além de uma barra.

NotificationView ou MessageView, etc, seriam nomes melhores na minha opinião.

Por que isso é chamado de InfoBar? Info é apenas uma pequena classe de informação que pode conter. Ele também suporta erros e avisos, além de ações baseadas neles. A barra também está restringindo artificialmente a 'forma' do controle. Existem vários outros casos de uso para ele além de uma barra.

NotificationView ou MessageView, etc, seriam nomes melhores na minha opinião.

Foi originalmente proposto como StatusBanner
Em seguida, foi alterado para InformationBar / InfoBar

A versão FluentUI deste controle é chamada MessageBar

Obrigado pelo resumo. O nome ainda não faz muito sentido para mim. A forma como o controle atual é projetado é como uma notificação. Mais generalizado, deve ser uma 'mensagem' para que também possa suportar cenários de ajuda/ensino. Generalizando os vários conceitos, aqui está um design melhor para os controles:

1. ~ MessageView ~ ou Dica : Um controle para exibir status, dica ou informações de ensino para o usuário com uma ação opcional, título, glifo, imagem e botões. Isso pode ser colocado em qualquer lugar e não é um pop-up. Também suportaria diferentes layouts.

2. TeachingTip : Um submenu/popup hospedando um MessageView.

   • Dica hospedada

3. NotificationBar ou StatusTip : Notificação de todo o aplicativo em formato de 'barra' na parte superior do aplicativo ou visualização.

   • Dica hospedada

4. Dica de ferramenta : Agora será possível hospedar também a dica que dará suporte para ações e imagens, etc.

   • Dica hospedada

Realmente precisamos pensar em termos gerais e combinar conceitos de alto nível nos mesmos controles. Caso contrário, criaremos muitos controles muito especializados com propriedades semelhantes, mas diferentes.

Pensei em um nome perfeito para um controle geral 'MessageView': Chame-o de 'Dica'. ToolTip poderia hospedá-lo também. Atualizado em conformidade.

Aqui está outro exemplo do 'mundo real' de uma barra de notificação na parte superior de alguns campos de entrada. O controle atual seria útil para esse cenário:

Aqui está outro exemplo do 'mundo real' de uma barra de notificação na parte superior de alguns campos de entrada. O controle atual seria útil para esse cenário:

TextBoxes estarão recebendo estados de validação que podem cobrir parte disso, mas aqui está como eu vejo os vários controles...

• Dica de ferramenta para um único elemento onde o usuário deseja identificar ativamente;
• TeachingTip para um único elemento que o desenvolvedor deseja que o usuário observe (também pode ser desanexado a um elemento);
• InfoBar para toda a área do app/conteúdo onde o desenvolvedor deseja entregar alguma informação;
• Flyout/Diálogo para quando o desenvolvedor quer que o usuário confirme que leu algo antes de descartá-lo;
• Diálogo de conteúdo para quando o desenvolvedor exige que o usuário faça uma escolha ou tome uma ação acima de tudo;

Eu também evitaria usar a palavra Notificação , pois há a notificação no nível do sistema operacional e o centro de notificação para esses

Eu também evitaria usar a palavra Notificação, pois há a notificação no nível do sistema operacional e o centro de notificação para esses

Bem, acho que os desenvolvedores saberiam a diferença, mas certamente é um ponto justo.

Também é verdade que podemos fazer muitos controles separados. Mas certamente existem alguns conceitos de alto nível sobre notificação/status/mensagens/dicas/ensino que podem ser combinados. Devemos pelo menos fazer uma interface com tudo isso.

As caixas de diálogo do Flyout/Conteúdo são conceitos separados, pois são controles de conteúdo genéricos em sua maior parte.

Eu pensei em um nome perfeito para um controle de tipo 'visualização de mensagem' generalizado para hospedar em vários cenários: chame-o de 'Dica'. Atualizei meu comentário acima de acordo: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

Eu pensei em um nome perfeito para um controle de tipo 'visualização de mensagem' generalizado para hospedar em vários cenários: chame-o de 'Dica'. Atualizei meu comentário acima de acordo: #913 (comentário)

Eu não me sentiria confortável em colocar um aviso importante ou mensagem de erro em uma Dica ...

Também é verdade que podemos fazer muitos controles separados. Mas certamente existem alguns conceitos de alto nível sobre notificação/status/mensagens/dicas/ensino que podem ser combinados. Devemos pelo menos fazer uma interface com tudo isso.

As caixas de diálogo do Flyout/Conteúdo são conceitos separados, pois são controles de conteúdo genéricos em sua maior parte.

Eu realmente gosto dessa ideia. Acho que há pontos em comum nas APIs de ícone, título, mensagem e botão de ação que podem ser consistentes nesses controles de informações. Com InfoBar, não tenho certeza se é algo que podemos implementar nesta versão atual, mas potencialmente para nosso próximo controle dessa natureza.

Eu pensei em um nome perfeito para um controle de tipo 'visualização de mensagem' generalizado para hospedar em vários cenários: chame-o de 'Dica'. Atualizei meu comentário acima de acordo: #913 (comentário)

Eu não me sentiria confortável em colocar um aviso importante ou mensagem de erro em uma Dica ...

Eu também concordo com isso... mais exploração a ser feita.

Eu pensei em um nome perfeito para um controle de tipo 'visualização de mensagem' generalizado para hospedar em vários cenários: chame-o de 'Dica'. Atualizei meu comentário acima de acordo: #913 (comentário)

Eu não me sentiria confortável em colocar um aviso importante ou mensagem de erro em uma dica...

Eu também concordo com isso... mais exploração a ser feita.

Pense em como ele se encaixa com todos os controles e ideias existentes - é perfeito nesse sentido. Mas sim, parece fora de lugar no contexto de erros/avisos. Acho que as pessoas entenderiam rapidamente, mas não posso discutir com essa lógica.

Por que isso é chamado de InfoBar? Info é apenas uma pequena classe de informação que pode conter. Ele também suporta erros e avisos, além de ações baseadas neles. A barra também está restringindo artificialmente a 'forma' do controle. Existem vários outros casos de uso para ele além de uma barra.

NotificationView ou MessageView, etc, seriam nomes melhores na minha opinião.

Concordo com o seu ponto de que o InfoBar pode nem sempre ser uma barra, mas acho que incluir "bar" no nome implica que se destina a cenários de todo o aplicativo, tanto visual quanto conceitualmente. Pesquisando por imagens da "barra de informações" você encontra imagens de experiências semelhantes do IE (não que estejamos necessariamente tentando corresponder ao IE) e acho que isso conota o layout visual e funcional esperado. Não vejo isso como uma 'Visualização', mas gosto do foco na mensagem ou notificação.

@gabbybilka Sim, é bastante semelhante ao antigo StatusBar ou ao AppBar mais recente... CommandBar... etc. O problema é que o uso do controle deve ser generalizado um pouco para também mostrar dicas e mensagens em locais arbitrários. 'Visualizar' também não se encaixa 100%, mas está mais próximo de um nome geral. Realmente minha preocupação é unificar os conceitos subjacentes para que não acabemos com vários controles fazendo variações da mesma coisa.

Editado por me confundir com vários comentários em dois locais.

Ecoando pensamentos que postei em uma das outras edições...

_Respondendo ao fato de que um modo flutuante para o controle não está mais sendo considerado para V2_
Posso entender que a mudança de comportamento e forma faria você se voltar para a dica de ensino como uma alternativa, mas sugiro que a falta de gravidade, cor de status e o design da dica de ensino em si - não seria compatível com o mesmo tipo de mensagens que o controle InformationBar está atendendo.

A largura da tela e as diferenças nos layouts da interface do usuário entre um aplicativo WinUI de tela cheia, uma janela de largura estreita e coisas como Hololens e Xbox - não se prestam a um fator de forma de barra ancorada.

Então, com isso em mente, talvez o InformationBar deva ser encapsulado, juntamente com um controle InformationCard em uma API AppMessage - para que as mesmas propriedades de Severity, Color, Title, Message, Action Buttons, etc, possam ser colocadas no XAML ou no o código do aplicativo - e a maneira como eles são apresentados na tela mudam para se adequar ao fator de forma/família de dispositivos.

Uma dica de ensino não anexada poderia funcionar, mas não suportaria as personalizações adequadas para mensagens de status do aplicativo - que é a intenção original por trás desse controle.

E daí se tivéssemos uma 'Dica' que fosse apenas uma mensagem. Tem um glifo, imagens, texto da mensagem, título.

Em seguida, derivando de Tip, temos AppMessage que adiciona gravidade, ações e coisas. Tip ainda seria utilizável em TeachingTip e ToolTip como existem hoje. também seria útil no meu cenário para dicas contextuais em linha.

E daí se tivéssemos uma 'Dica' que fosse apenas uma mensagem. Tem um glifo, imagens, texto da mensagem, título.

Em seguida, derivando de Tip, temos AppMessage que adiciona gravidade, ações e coisas. Tip ainda seria utilizável em TeachingTip e ToolTip como existem hoje. também seria útil no meu cenário para dicas contextuais em linha.

A dica de ensino sem cauda parece perfeita para sua situação...

A dica de ensino sem cauda parece perfeita para sua situação...

Não sabia que você poderia fazer isso com TeachingTip. Além disso, meu controle existe há muito mais tempo do que o TeachingTip, então nunca investiguei a atualização até agora. De qualquer forma, se você pode fazer isso, é um descuido da minha parte.

Edit: Não importa, mesmo sem cauda ainda é uma sobreposição que é descartada de uma forma ou de outra. A 'dica' que estou descrevendo é toda embutida e persiste até que o usuário basicamente crie o primeiro elemento. É simplesmente um controle que apresenta informações - não em um pop-up, flyout ou outra visualização não persistente.

Ainda estou convencido de que há muitos pontos em comum para dividir em interfaces/controles usados ​​em vários lugares. Todos esses controles que estamos discutindo têm muito mais semelhanças do que diferenças. É apenas onde/como a informação subjacente é apresentada que muda. Isso tudo está maduro para simplificação.

A dica de ensino sem cauda parece perfeita para sua situação...

Não sabia que você poderia fazer isso com TeachingTip. Além disso, meu controle existe há muito mais tempo do que o TeachingTip, então nunca investiguei a atualização até agora. De qualquer forma, se você pode fazer isso, é um descuido da minha parte.

Ainda estou convencido de que há muitos pontos em comum para dividir em interfaces/controles usados ​​em vários lugares. Todos esses controles que estamos discutindo têm muito mais semelhanças do que diferenças. É apenas onde/como a informação subjacente é apresentada que muda. Isso tudo está maduro para simplificação.

Quando você o divide, é apenas um ícone e texto, e não há "contexto" associado a ele. Mas minha sugestão de envolvê-lo em um AppMessage poderia incluir dicas de ensino não anexadas como outra forma de interface do usuário, eu acho.

Quando você o divide, é apenas um ícone e texto, e não há "contexto" associado a ele. Mas minha sugestão de envolvê-lo em um AppMessage poderia incluir dicas de ensino não anexadas como outra forma de interface do usuário, eu acho.

Desculpe, veja minha edição acima. A dica de ensino ainda não está em linha e apenas flutua na parte inferior até ser dispensada. Há também uma imagem e título a considerar também.

Quando você o divide, é apenas um ícone e texto, e não há "contexto" associado a ele. Mas minha sugestão de envolvê-lo em um AppMessage poderia incluir dicas de ensino não anexadas como outra forma de interface do usuário, eu acho.

Desculpe, veja minha edição acima. A dica de ensino ainda não está em linha e apenas flutua na parte inferior até ser dispensada.

Não precisa ser no fundo.

Inline talvez seja um caso de uso incomum para uma dica, pois deslocaria outro conteúdo ao seu redor.

Você pode sugerir que um V2 adicione suporte para um modo de exibição em linha/não flutuante

Para dar um pouco mais de contexto ao comentário de @mdtauk , aqui estava minha resposta inicial à sua pergunta sobre a remoção do modo flutuante da seção "Recursos pretendidos para InfoBar V2" na especificação.
De mim:

Entrando aqui para a discussão de design. Fique de olho em perceber que os recursos pretendidos da V2 mudam 😉 No momento, não estamos nos comprometendo com o modo flutuante para InfoBar em uma versão V2 por alguns motivos. Eu gostaria de explorar mais se o modo flutuante _deve_ estar em uma InfoBar ou se as notificações do tipo toast devem ser um controle totalmente diferente. Ao investigar, percebemos que uma implementação básica do modo flutuante seria incrivelmente semelhante à dica de ensino e que, para explorar totalmente a funcionalidade de cenários de notificação do tipo toast, como empilhamento, posicionamento e opções de sobreposição (consulte StackMode do WCT InAppNotification ) provavelmente são necessárias. Isso expandiria o escopo e a intenção do InfoBar para ser muito mais amplo do que seu foco inicial. Para observar, não fechamos totalmente a porta para adicionar recursos flutuantes ao InfoBar, mas inclinamos para não.

Para a proposta InformationBar e InformationCard baseada em uma classe AppMessage básica, gosto dessa ideia. Você mencionou que "a maneira como eles são apresentados na tela mudaria para se adequar ao fator de forma/família de dispositivos" que eu gostaria de explorar mais profundamente. Acho que existem cenários mais adequados para UX de cartão (especialmente mensagens transitórias, mensagens de erro específicas de página e aplicativos sem superfícies acopláveis) do que UX de barra e vice-versa.

Para mim, existem diferenças no "quando" usar um InfoBar/InfoCard/Dica de Ensino (vinculado às necessidades visuais e funcionais), bem como no "porquê" usar (com base na percepção do usuário final e consistência da experiência). Mensagens transitórias são um destaque claro para mim como algo que deve ser suportado por um InfoCard e não suportado por um InfoBar. As mensagens descartáveis ​​que não são do usuário são um exemplo do oposto, pois o conteúdo sobreposto persistente é difícil de suportar do ponto de vista da acessibilidade.

Mas não se desvie :) Todos esses vários controles estão apresentando, na maioria das vezes, o mesmo tipo de informação -- apenas em áreas/estilos diferentes. Isso precisa ser generalizado e unificado. Acho que podemos unificar em torno de um controle 'AppMessage' comum, se você quiser chamá-lo assim. Depois é só ter diferentes containers para apresentar essa 'AppMessage' de maneiras diferentes. Pode ser apresentado em um TeachingTIp, um ToolTip, um NotificationBar, como um cartão em algum lugar, etc. Cada container pode modificar o estilo para se adequar ao seu caso de uso. As propriedades e tipos subjacentes seriam unificados.

Eu não estava tentando interpretar mal nenhum contexto com a resposta de @gabbybilka 😄

Para a proposta InformationBar e InformationCard baseada em uma classe AppMessage básica, gosto dessa ideia.

É aqui que entra a nomeação. Eu gosto de "AppMessage" ("Dica" seria incrível, pois parece que era o plano o tempo todo), mas se formos com isso, deve ser a hospedagem "MessageBar" e "MessageCard" isto.

Para mim, existem diferenças no "quando" usar um InfoBar/InfoCard/Dica de Ensino (vinculado às necessidades visuais e funcionais), bem como no "porquê" usar (com base na percepção do usuário final e consistência da experiência).

Eu definitivamente concordo com esses diferentes casos de uso e apresentações. No entanto, eles ainda estão apresentando uma mensagem que pode ser generalizada e padronizada. Acho que todos concordamos com esse conceito agora :)

Exemplo de uma mensagem/dica de cartão

Um dos objetivos, eu acho, deveria ser encorajar a caixa de entrada e os aplicativos de primeira parte/Windows Shell a se afastarem de suas soluções personalizadas para usar um controle/API consistente da caixa de entrada

Eu provavelmente deveria acrescentar que em um aplicativo UWP eu trabalho em alguns desses conceitos já unificados. A versão simplificada relevante para esta discussão é:

Existe uma classe 'Message' (não é um controle, apenas uma estrutura de dados) com as seguintes propriedades:

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

A prioridade é basicamente a mesma que você já decidiu (é bastante padronizado hoje em dia). DisplayMode suporta Notificação, Nenhum e Popup. Quando uma mensagem é gerada pelo código de back-end, ela é passada para o front-end que a exibirá de acordo como uma notificação rápida em uma 'barra' na parte superior do aplicativo a ser descartada. Ou como um pop-up de bloqueio para mensagens mais graves.

Além disso, há um controle 'MessageView' que recebe uma mensagem por si só, mas adiciona um glifo e um título e o apresenta como a 'Dica' contextual sobre a qual falamos anteriormente.

É exatamente isso que eu proponho: Faça a abstração na camada App. Tenha uma classe ViewModel simples que você possa anexar a qualquer uma das visualizações. É simples de fazer e mais flexível. Talvez você também queira fazer log com sua estrutura de log preferida, queira ter prioridades personalizadas, queira adicionar seus próprios dados. Tudo fácil de fazer no seu ViewModel.

A intenção dos controles que você mencionou é fornecer uma maneira unificada de fazer determinados cenários, em muitos aplicativos e casos de uso de SO, em vez de cada aplicativo ter uma interface do usuário e um comportamento ligeiramente diferentes. ToolTips e InfoBar/MessageBar são conceitos bem conhecidos, tanto para desenvolvedores quanto para usuários finais. Embora ambos apresentem informações, eles são usados ​​para coisas muito diferentes. Não vejo muito benefício em ter uma classe base comum ou conceito comum para estes. Por que você gostaria de colocar uma mensagem em uma dica de ferramenta, que já é mostrada no aplicativo global InfoBar (e onde você anexaria esta dica de ferramenta)? Não é como se isso levasse a muita reutilização.

Existem outras áreas onde os conceitos comuns seriam muito mais úteis IMO. Pense em Button, AppBarButton, MenuItem. Todos eles mostram texto e um ícone, todos são usados ​​para acionar uma ação. Muitas vezes você fornece os mesmos comandos em um MenuItem (ContextMenu) e um AppBar/CommandBar. Aqui, um conceito comum seria muito útil, onde você poderia colocar seu comando, texto, ícone, talvez também uma mensagem longa (dica). Mas ter um conceito comum para ToolTip e MessageBar? Eu realmente não vejo a necessidade disso. Claro, se reescrevermos a UWP do zero, poderíamos ter criado uma classe base comum. Mas não acho que seja necessário ou muito útil.

@lukasf Seus pontos fazem sentido; isso pode ser feito no próprio aplicativo. No entanto, existem muitos conceitos muito semelhantes e todos podem se beneficiar de uma unificação aqui.

A dica de ferramenta foi lançada na discussão porque poderia se beneficiar com um glifo e um título junto com uma mensagem. Conceitualmente, todos esses controles também são mensagens de alguma forma - apenas onde/como eles são exibidos são diferentes. Mesmo se não fizermos uma grande padronização, um MessageBar e MessageCard ainda exigiriam muitas propriedades/tipos compartilhados. Não queremos ter MessageBarPriority junto com Enems MessageCardPriority. O pensamento ainda precisa ser colocado para garantir que mesmo os tipos básicos sejam à prova de futuro.

Combinar tudo isso com as ideias existentes na Dica de Ensino só me parece lógico. Tenho certeza de qual direção seguir faria sentido com uma comparação lado a lado de todos os controles mencionados e suas propriedades. Se eu tiver tempo vou fazer a comparação eu mesmo.

Seus comentários sobre Button/AppBarButton/etc. são um exemplo perfeito do pensamento que não queremos proliferar. A Microsoft está adquirindo o hábito de fazer vários controles semelhantes, mas diferentes, sem gastar tempo/esforço para torná-los coesos. Este longo prazo não é bom para uma estrutura de qualquer tipo por várias razões.

Eu montei uma comparação dos controles de mensagens. Vou dá-lo como consulta gratuita, já que é tão difícil como é :)

Este é o tipo de comparação de alto nível e documentação de estratégia que eu esperaria que fosse criada internamente na Microsoft. Se fosse eu mesmo liderando as revisões de especificações/design, eu exigiria esses tipos de análise ou ninguém pode esperar sair com aprovação. É absolutamente importante:

1. Preencher lacunas no entendimento entre os membros da equipe
2. Supere os 'silos' que ocorrem em grandes equipes e organizações
3. garantir uma direção futura coerente da estrutura para que a funcionalidade futura possa ser adicionada em cima de uma boa base (mais importante)

A Microsoft de alguma forma perdeu esses princípios gerais após o WPF e parece não haver mais nenhuma visão de 'nível superior' da liderança neste espaço. De qualquer forma, não estou a par das discussões internas, então espero que muito mais planejamento esteja ocorrendo internamente com alguns indivíduos que têm muita experiência e um longo histórico dos princípios com XAML.

Com isso dito, sinta-se à vontade para separar o documento abaixo. É a discussão em si que é mais importante.

MessageControlComparison 20200929.xlsx

Obrigado pelo documento de comparação, muito legal ver seus pensamentos sobre os controles de informações de forma holística! Dois tópicos principais sobre os quais quero continuar a discussão são: 1. Por que _não deveria_ a dica de ensino e a InfoBar ter APIs/propriedades/funcionalidade diferentes? e 2. Qual seria a diferença entre um InfoBar e InfoCard se o InfoCard não fosse um Popup conforme descrito no documento de comparação?

Para a primeira pergunta, posso destacar as decisões de design feitas nos itens com texto em vermelho e fornecer um pouco mais de clareza:

• TeachingTip Subtitle vs InfoBar Mensagem: Funcionalmente, sim, eles são os mesmos! Eles são a mensagem secundária com texto sem negrito nesses controles. Em uma Dica de Ensino, esta mensagem sempre será exibida abaixo do Título e faz sentido nomeada como Subtítulo. Para InfoBar, esta mensagem será na maioria das vezes em linha e diretamente à direita do título, o que conceitualmente não faz sentido chamado de subtítulo.
• TeachingTip HeroContent vs InfoBar Content: O Teaching Tip tem HeroContent e Content, enquanto o InfoBar tem apenas conteúdo. A propriedade HeroContent é exclusiva da dica de ensino devido ao suporte dessas imagens maiores para ajudar no ensino. A InfoBar não suporta imagens explicitamente, pois se concentra em um layout horizontal. A propriedade Content para ambos os controles é para conteúdo personalizado extra e está abaixo do restante dos elementos da interface do usuário em ambos.
• Estratégia de botão de dica de ensino versus estratégia de botão do InfoBar: As principais diferenças aqui são que o InfoBar suporta mais tipos de botões fora do clássico "Botão" e não incentiva a personalização do botão Fechar para incluir texto.
  
  
  
  • Um cenário comum para InfoBars é incluir um botão de hiperlink. Devido ao contraste de cores com a cor de primeiro plano do botão de hiperlink padrão e nossas cores de fundo de várias cores, queríamos garantir que pudéssemos aplicar nosso próprio estilo personalizado a qualquer botão de hiperlink incluído na InfoBar para que eles permanecessem acessíveis.
  
  
  • Decidimos não incluir a personalização do botão Fechar (para texto, ainda há uma propriedade CloseButtonStyle para fazer um estilo leve, se desejado) na InfoBar após nossas revisões de design para garantir que o foco permaneça no texto incluído e na ação única. Da mesma forma, como mencionado na especificação, estamos pensando em um ActionContentArea na V2 para dar suporte a mais de um botão de ação aqui e poderíamos investigar a ativação da personalização do botão Fechar novamente lá.
  
  
• InfoBar IsClosable & IsIconVisible: A dica de ensino não tem IsClosable como uma dica de ensino deve sempre ser fechada, pois é um pop-up e exibe informações não bloqueantes/urgentes. Ele também não possui IsIconVisible, pois um ícone não aparece com seu estilo padrão, o que o InfoBar faz por meio dos diferentes níveis de gravidade. Queríamos fornecer uma maneira para um desenvolvedor remover o ícone fornecido, se quisesse. Tentamos definir IconSource como null, o que causou muitos bugs estranhos e simplificou através da propriedade IsIconVisible.

Estes fazem sentido? Acredito que há propósitos diferentes para ambos os controles e as diferenças na funcionalidade refletem isso. Espero que essas explicações e lógica de design tenham sido úteis!

Edite para problemas de formatação e erros de digitação😊 x2

Eu não defenderia a harmonização entre esses controles diretamente, pois há justificativa para esses controles fazerem suas próprias coisas dentro de seus próprios contextos.

No entanto, a criação de uma API de mensagens no aplicativo, que atua como uma estrutura unificadora, mas que pode se adaptar ao formato, não precisa de alterações nos controles.

Há perguntas a serem discutidas e respondidas para esse tipo de API:

• Deve / Como você, como desenvolvedor, pode especificar que tipo de controle uma chamada de mensagem exibe na tela?
• Se não especificar um tipo de controle, a API pega as propriedades fornecidas e "escolhe" a mais adequada?
• Como você passaria pelas escolhas comportamentais para os controles subjacentes?
• Quais fatores de forma substituiriam com base na adequação da plataforma?

E provavelmente muitos mais que eu não pensei lol

Tomando o Xbox como uma plataforma
Os métodos de entrada são muito diferentes, assim como o tamanho/escala da tela.

Barras de informações de largura total precisariam levar em consideração o overscan nas bordas da tela e, portanto, para esses aplicativos, um cartão de informações pode ser mais adequado.

Mas como você lidaria com a demissão?

Nenhum cursor para mover sobre um botão de fechamento, mas você deseja que o cartão assuma as entradas do controlador? Isso o torna modal. Mas então, se ele estiver sobreposto ao conteúdo, como você o seleciona e dá foco?

Então, ele aparece em linha e empurra o conteúdo para baixo, mas não tem largura total?

Além disso, o Xbox tem seu próprio sistema de notificação de brinde, então essa API funcionaria / deveria funcionar com isso? Funciona com ele ou é somente sistema?

1. Por que a dica de ensino e a InfoBar não devem ter APIs/propriedades/funcionalidade diferentes?

O objetivo deve ser sempre fornecer APIs comuns para as mesmas coisas. Toda essa discussão é sobre mensagens voltadas para o usuário em geral e várias semelhanças apareceram uma vez que isso foi entendido. É indiscutível que os casos de uso para TeachingTip e um controle do tipo MessageBar sejam diferentes. Fundamentalmente, um está apresentando uma Mensagem e o outro uma Dica também. Não estou questionando as escolhas gerais de design aqui. No entanto, há muito mais semelhanças do que diferenças com esses controles. Basta olhar apenas para o design: todos eles têm ícone, título, legenda, conteúdo, botão de ação e botão fechar (ainda que você os nomeou de maneira diferente e há uma área de superfície de API diferente). Se você não vê por que é uma boa ideia padronizar pelo menos a nomenclatura e as enumerações aqui, não há mais nada que eu possa dizer. Isso é apenas algo fundamental para uma boa arquitetura.

Para botões, ambos os controles suportam um botão de ação e um botão de fechamento. Mas você fez isso de maneiras completamente diferentes. Você explicou alguns motivos acima, mas agora temos uma API 'feia' para usar botões em situações como essa. Por que não generalizamos isso agora para termos algo bom para o futuro? Botões como este se aplicam a vários controles: ContentDialog, TeachingTip, InfoBar e quem sabe o que vem depois. Continuamos projetando pensando apenas no controle atual - arquitetura ruim!

Para o texto da mensagem ou dica, um é chamado Subtitle e o outro Message fundamentalmente, estes podem ser os mesmos, por que são usados ​​termos diferentes que não sejam gerentes de projeto diferentes que estão trabalhando nesses controles?

No geral, não seria útil para os desenvolvedores se os controles funcionassem da mesma maneira? Sim claro! Isso significa que haverá o mesmo controle por baixo de tudo isso? Não necessariamente, mas devemos usar os mesmos nomes de propriedade, os mesmos conceitos de botão de ação e os mesmos tipos. Ainda espero que possamos ter uma estrutura de mensagem ou interface usada para unir tudo. Não seria ótimo apenas definir uma mensagem para o MessageBar e exibi-la em vez de ter que definir todas essas propriedades manualmente?

Qual seria a diferença entre um InfoBar e InfoCard se o InfoCard não fosse um Popup conforme descrito no documento de comparação?

Minha conclusão final da comparação é que MessageBar/MessageCard deve ser o mesmo controle e também dar suporte ao caso de uso de minha dica embutida ou exemplo de dica por meio de personalização de estilo.

• É possível unificar MessageBar/MessageCard e Tip em um único controle. A única preocupação é a diferença conceitual entre 'mensagem' e 'dica'.
• Deve ser o mesmo controle subjacente, mas o estilo precisa ser altamente personalizável para dar suporte a ambos os casos. A única preocupação é a diferença conceitual entre 'mensagem' e 'dica'. O design é extremamente semelhante.

Edit: No geral, acho que minha preocupação fundamental é que, de alguma forma, retrocedemos no pensamento arquitetônico. O design de controle agora é feito como se fosse nos dias do Windows Forms. Novos controles UWP devem ser baseados em conceitos WPF. Os controles estão ficando altamente especializados e não vejo os tópicos unificadores abrangendo a estrutura que realmente impressionaram os desenvolvedores que tocaram o WPF pela primeira vez. Devemos voltar à mentalidade do 'grande quadro' na minha opinião.

Concordo 100% com @robloo que nomes de propriedades e nomes de enumeração para coisas semelhantes devem ser alinhados (na medida do possível) com os controles existentes. Controles semelhantes devem ter uma superfície de API semelhante. Se uma classe MessageCard fosse adicionada posteriormente (em vez de estender MessageBar, que eu pessoalmente preferiria), ela deveria ter pelo menos uma API muito semelhante à MessageBar.

Existem outras áreas onde os conceitos comuns seriam muito mais úteis IMO. Pense em Button, AppBarButton, MenuItem. Todos eles mostram texto e um ícone, todos são usados ​​para acionar uma ação. Muitas vezes você fornece os mesmos comandos em um MenuItem (ContextMenu) e um AppBar/CommandBar. Aqui, um conceito comum seria muito útil, onde você poderia colocar seu comando, texto, ícone, talvez também uma mensagem longa (dica).

@lukasf Você está ciente da classe XamlUICommand ? Isso permite que você agrupe essas propriedades em um só lugar e as atribua ao seu Button/MenuItem/.... apenas passando seu XamlUICommand definido para a API Command desses controles.

@Felix-Dev Sim, você está certo. Eu quase esqueci disso. Não estou usando porque não estava disponível no WinUI quando tentei da última vez, mas também porque não é uma solução completa. AppBar e ContextMenu têm mais do que apenas links de comando. Para uma solução completa, precisaríamos de:

• Comando XamlUI
• Comando XamlToggleUI
• XamlUICommandSubItem (submenu / submenu)
• XamlUICommandSeparator

O que também está faltando é uma propriedade "Visible" e/ou uma propriedade "HideIfDisabled".

Então precisaríamos de um ItemsSource em MenuFlyout e AppBar/CommandBar e controles semelhantes. O controle de nível superior criaria os subcontroles correspondentes para cada item de comando.

Somente quando tudo isso estivesse no lugar, poderíamos ter uma coleção de comandos em nosso aplicativo e vinculá-los a MenuBar, ContextMenu, AppBar, NavigationView. Mas como está agora, eu preciso manter uma lista de classes definidas personalizadas, implementar manualmente e usar coisas como DataTemplateSelectors e outras soluções irritantes, apenas para obter a mesma definição de comando funcionando em lugares diferentes.

XamlUICommand foi um bom começo, mas não é uma história completa.

Peço desculpas pelo meu atraso na resposta aqui, @robloo obrigado por compartilhar sua perspectiva e a tabela de comparação de algumas semanas atrás. Eu realmente aprecio todos os pensamentos e considerações para tornar o WinUI melhor! 😊

Na InfoBar e em toda a plataforma, minha visão é que, enquanto projetamos, estamos nos esforçando para encontrar o equilíbrio certo para que os controles sejam especialmente projetados para cenários específicos como um padrão de interface do usuário definido - embora genérico e personalizável o suficiente para estender aos cenários que não temos ainda identificado. Como alguém mais novo na equipe, adoraria saber por que os controles do WinUI devem voltar aos conceitos do WPF. Quais problemas do dia a dia você e outros desenvolvedores de UWP estão enfrentando quando controles conceituais semelhantes não têm a mesma estrutura subjacente? Quais são os benefícios para você para que possamos entender melhor por que devemos dedicar recursos para criar essa estrutura? Existem outros controles no WinUI que se beneficiariam de serem unificados (eu vejo a conversa do botão acima de @lukasf) Acho que também podemos continuar essa conversa em um novo problema geral se houver uma área em que possamos modificar os controles/abordagens de brainstorming existentes para controles futuros. @SavoySchuler para qualquer entrada aqui.

Para o InfoBar, ainda não prevejo nenhuma alteração à medida que entra em pré-visualização desta conversa. Para as APIs de botão de ação e botão de fechamento, em particular, se houver necessidades específicas que não foram atendidas, informe-nos para que possamos avaliar possíveis alterações. Eu poderia antecipar uma classe base ou interface AppMessage comum a ser implementada com uma v2 em associação com um controle InfoCard ou como um DisplayMode separado para habilitar a funcionalidade 'Auto' de layout variável @mdtauk apresentada anteriormente. Além disso, a equipe do WinUI ainda não vê o valor de alinhar ainda mais a dica de ensino e a barra de informações neste momento, no entanto, podemos continuar a conversa aqui para resolver isso se houver necessidades de uso não atendidas. Uma vez que o InfoBar entra em pré-visualização e pode ser implementado em aplicativos, qualquer cenário específico ou feedback de uso seria ótimo ouvir antes do lançamento oficial.

Como uma pergunta geral, se você tiver cenários que correspondam à intenção de uma InfoBar e houver aspectos de sua funcionalidade ou design visual que não atendam às suas necessidades, informe-nos à medida que entramos na visualização. Obrigado novamente por todos os seus comentários e conversas!

Na InfoBar e em toda a plataforma, minha visão é que, enquanto projetamos, estamos nos esforçando para encontrar o equilíbrio certo para que os controles sejam especialmente projetados para cenários específicos como um padrão de interface do usuário definido - embora genérico e personalizável o suficiente para estender aos cenários que não temos ainda identificado. Como alguém mais novo na equipe, adoraria saber por que os controles do WinUI devem voltar aos conceitos do WPF. Quais problemas do dia a dia você e outros desenvolvedores de UWP estão enfrentando quando controles conceituais semelhantes não têm a mesma estrutura subjacente? Quais são os benefícios para você para que possamos entender melhor por que devemos dedicar recursos para criar essa estrutura? Existem outros controles no WinUI que se beneficiariam de serem unificados (eu vejo a conversa do botão acima de @lukasf) Acho que também podemos continuar essa conversa em um novo problema geral se houver uma área em que possamos modificar os controles/abordagens de brainstorming existentes para controles futuros. @SavoySchuler para qualquer entrada aqui.

O ponto de ter estrutura é para que os programadores possam codificar mais rapidamente com menos erros para ter um código de alta qualidade.

Como grande parte da Microsoft são equipes isoladas, em muitos casos existem várias maneiras de fazer algo, mas nenhuma unificação desses procedimentos, o que resulta em redundância e na tentativa de consertar algo que já está corrigido.

Depois que o WPF foi criado, a Microsoft entrou em uma mentalidade "é bom o suficiente", isso se expressa diretamente na qualidade dos aplicativos, mesmo das próprias equipes da Microsoft. Se os próprios aplicativos de caixa de entrada da Microsoft não puderem estar na mesma página com consistência uniforme de alta qualidade no código e uniformidade dos aplicativos, como esperamos que os parceiros de terceiros forneçam isso?

A entrega de códigos genéricos, mas personalizáveis, resulta em aplicativos genéricos de linha de base. A maioria dos desenvolvedores não fará um esforço extra para tornar seu aplicativo funcional e polido, eles farão apenas o suficiente para tornar seu aplicativo funcional. Este nível de "faça o suficiente para torná-lo funcional" é captado pelo usuário final como "meio assing it".

Na minha opinião, o objetivo dos controles é ter um código de alta qualidade que você possa usar e personalizá-lo com base, se desejar.

Dar opções ao desenvolvedor, de como eles usam os controles também tem seus pontos positivos, em vez de bloqueá-los em uma única maneira de gerenciar mensagens e notificações.

Mas garantir que qualquer opção que eles escolherem, pareça e se comporte de maneira familiar e "pertença" ao Fluent Design - tem o benefício da consistência.

Portanto, se os próprios controles no WinUI não fornecerem uma abordagem unificada, talvez o Windows Toolkit possa criar uma API auxiliar que o gerencie.

Eu sugiro que você o proponha nesse repositório, e ele pode usar os controles WinUI para apresentá-lo no aplicativo

Olá a todos, como uma atualização, o controle InfoBar agora está em pré-visualização 🎉 Se você tem um aplicativo que se beneficiaria desse controle, experimente e compartilhe seus comentários conosco.
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
Obrigado por todo o seu engajamento até agora para este controle!

Aqui está outro exemplo de uma barra/caixa/cartão de informações

Edit: Acabei de perceber que o problema abaixo já foi corrigido por https://github.com/microsoft/microsoft-ui-xaml/issues/3581. Por favor, desconsidere o problema abaixo. Obrigado por fazer o controle! Parece ótimo em Nightingale :)

@gabbybilka Vou usar a barra de informações no meu aplicativo cliente Nightingale REST. É perfeito para um dos meus cenários. No meu teste rápido, parece que o ícone na barra de informações não suporta o tema claro? Ou talvez eu esteja fazendo algo errado no meu uso XAML do controle. Aqui estão algumas capturas de tela

Você consideraria adicionar um evento "Aberto" ao controle? Em alguns casos, é apropriado fechar automaticamente a InfoBar após alguns segundos. Um manipulador de eventos "Aberto" seria o lugar certo para iniciar o cronômetro.

Acho que a cor do Sucesso , no Tema Escuro, deveria ser mudada. @YuliKl @anawishnoff @chigy @teaP
A cor do tema escuro atual é #393D1B - que parece ser uma cor verde-amarelada, quase verde-oliva. Onde como o tema claro usa um verde mais claro, quase menta como o verde.

_No topo das cores atuais, abaixo de uma alteração proposta_

#1d3d1b

Não é apenas pelo valor estético, mas também porque a barra mais verde-oliva não é tão distinguível da cor de aviso

Aqui está como ficaria