Diretrizes e lista de verificação de blocos e notificações (aplicativos da Windows Store)

Este tópico descreve as práticas recomendadas, soluções de problemas e recomendações de globalização/localização para uso ao criar e atualizar o bloco de seu aplicativo, tanto na tela inicial quanto na tela de bloqueio, e lista qualquer requisito especial relacionado ao bloco que seu aplicativo tem que cumprir para ser aceito na Windows Store.

Um bloco é a representação de um aplicativo na Tela inicial. Um bloco permite apresentar ao usuário conteúdo rico e envolvente na Tela inicial quando seu aplicativo não está sendo executado. Toque ou clique no bloco para iniciar o aplicativo. Os blocos têm dois tamanhos: quadrado e largo. Diversas variações de modelos são oferecidas para cada tamanho, com texto, imagem(ns) ou uma combinação dos dois. Os modelos podem ter um único quadro ou dois quadros empilhados, o que é chamado de modelo dinâmico. Um bloco baseado em um modelo dinâmico é animado entre os dois quadros dentro do espaço do bloco. Modelos de um único quadro não são animados.

Em um canto, um bloco pode opcionalmente mostrar a identidade visual, como o nome do aplicativo ou uma pequena imagem do logotipo.

Os blocos podem ser dinâmicos (atualizados através de notificações) ou você pode mantê-los estáticos. Os blocos começam como blocos padrão, definidos no manifesto do aplicativo. Um bloco estático sempre exibirá o conteúdo padrão, que geralmente é uma imagem de logotipo de bloco inteiro. O bloco pode atualizar o bloco padrão para mostrar conteúdo novo, mas pode voltar ao padrão se a atualização expira ou é removida. No canto oposto à sua identidade visual, um bloco também pode exibir um selo de status, que pode ser um número ou um glifo.

Veja dois pontos muito importantes que sempre devem ser lembrados:

• Se você usa um bloco largo, o usuário pode redimensioná-lo para ficar quadrado ou mudá-lo de quadrado para largo a qualquer momento. Você não sabe o tamanho que está sendo exibido.
• O usuário pode habilitar e desabilitar as notificações de bloco quando quiser.

Diretrizes de experiência do usuário para blocos

Esta seção explica sobre as diretrizes que você deve seguir e as considerações de criação que você deve ter em mente ao planejar a aparência e o modo como seus blocos são usados.

• Filosofia do design de blocos
• Escolhendo entre o tamanho de bloco quadrado ou largo
• Usando blocos padrão
• Usando modelos dinâmicos
• Outras considerações de design
• Usando notificações de bloco

Filosofia do design de blocos

Sua meta é criar um bloco atraente para seu aplicativo. Se você usa um bloco, sua meta é apresentar novo conteúdo envolvente que o usuário achará inestimável ver na Tela inicial e que o convida a iniciar o aplicativo. Para essa finalidade, evite o uso abusivo de cores fortes. Blocos simples, limpos e com design agradável obtêm mais sucesso do que aqueles que gritam para chamar a atenção como uma criança birrenta.

Ao criar seu aplicativo, talvez você se pergunte "Por que devo investir em um bloco?" Há vários motivos:

• Os blocos são a "porta de entrada" do seu aplicativo. Um bloco interessante pode atrair usuários para seu aplicativo quando ele não está sendo executado. O usuário valoriza cada vez mais um aplicativo que é usado com frequência.
• Bloco dinâmico é um ponto de venda que diferencia seu aplicativo, tanto de outros aplicativos na Windows Store (geralmente os usuários preferem o aplicativo com o melhor bloco dinâmico do que um aplicativo semelhante com um bloco estático) quanto de aplicativos em sistemas operacionais que só permitem blocos e ícones estáticos em sua tela inicial.
• Se os usuários gostarem do seu bloco, um posicionamento de destaque desse bloco na Tela inicial ocasionará um novo envolvimento com o seu aplicativo. A descoberta inesperada de conteúdo excepcional no aplicativo através do bloco deixará os usuários empolgados.
• Se os usuários não gostarem do seu bloco, eles poderão colocá-lo no final da Tela inicial ou desafixá-lo completamente, desligar as atualizações ou inclusive desinstalar seu aplicativo.

Algumas características que tornam um bloco atraente são:

• Conteúdo novo e atualizado com frequência que fazem os usuários sentirem que seu aplicativo está ativo mesmo quando não está sendo executado.

  Exemplo: Mostrando as manchetes mais recentes ou uma contagem de novos emails.

• Atualizações personalizadas ou adaptadas que usam as informações que você tem sobre o usuário, como os interesses que você permite ao usuário especificar através das configurações do aplicativo.

  Exemplo: Negociações do dia adaptadas aos hobbies do usuário.

• Conteúdo relevante ao contexto atual do usuário.

  Exemplo: Um aplicativo de condições trânsito que usa a localização atual do usuário para exibir uma mapa de trânsito relevante.

Escolhendo entre o tamanho de bloco quadrado ou largo

Seu aplicativo sempre terá um bloco quadrado. Você deve decidir se quer permitir um bloco largo também. Essa escolha é feita fornecendo uma imagem de logotipo larga ao definir seu bloco padrão no manifesto. Se você não incluir uma imagem de logotipo larga, o bloco sempre será quadrado; ele não pode ser redimensionado pelo usuário nem pode aceitar notificações largas. Para alterar essa situação, lance uma nova versão do seu aplicativo com um manifesto atualizado que inclua uma imagem de logotipo largo..

• Use somente um bloco quadrado se seu aplicativo não for usar notificações de bloco para enviar atualizações ao usuário. O conteúdo do bloco largo sempre deve ser novo e atualizado com frequência. Se você não estiver usando um bloco, não forneça um logotipo largo no manifesto.
• Só use um bloco quadrado com uma notificação se o seu aplicativo for compatível unicamente com cenários de notificações de resumo abreviadas—ou seja, notificações que possam ser expressas somente por uma imagem de notificação ou um único número. Por exemplo, um aplicativo SMS que planeja usar notificações para comunicar apenas o número de novos textos recebidos é um cenário desse tipo. Não inclua um logotipo largo no manifesto.
• Só use o tamanho quadrado se o seu aplicativo envia atualizações que não devem ser mostradas em detalhes na tela inicial. Por exemplo, um aplicativo de holerite pode simplesmente indicar que o novo holerite está disponível, em vez de mencionar detalhes específicos, como o valor. Não inclua um logotipo largo no manifesto.
• Use o tamanho de bloco largo somente se seu aplicativo tiver conteúdo novo e interessante para exibir ao usuário e se essas notificações forem atualizadas frequentemente (pelo menos uma vez por semana).

• Os blocos quadrados mostram menos conteúdo do que os largos, portanto, priorize o seu conteúdo. Não tente colocar tudo o que você pode mostrar em um bloco largo no bloco quadrado.

  

  Se você tem conteúdo de bloco largo com uma imagem mais texto, pode usar o modelo quadrado dinâmico para dividir o conteúdo em dois quadros.

As notificações geralmente incluem um modelo largo e quadrado, pois elas não podem saber o tamanho atual do bloco. Se uma notificação for definida usando somente um modelo largo, e o bloco for exibido como um quadrado, ou se a notificação for definida usando somente um modelo quadrado, e o bloco for exibido como largo, a notificação não será mostrada.

Usando blocos padrão

O bloco padrão do aplicativo é definido em seu manifesto. Ele é estático, quadrado ou largo e normalmente tem design simples. Para alguns aplicativos, o bloco padrão é tudo o que você vai precisar. Quando o aplicativo é instalado, o bloco padrão é exibido na tela inicial até receber uma notificação. Quando uma imagem de logotipo grande é incluída, o bloco largo é usado. Uma atualização pode expirar ou ser explicitamente removida e, nesses casos, o bloco é revertido para o conteúdo padrão até a próxima notificação.

Uso apropriado de blocos padrão

• Use a imagem do bloco padrão para refletir a marca do seu aplicativo, essencialmente como uma tela para o logotipo do seu aplicativo.
• Se você está incluindo um logotipo largo, leve em consideração a relação de design entre as imagens de bloco largo e quadrado que vai incluir. Lembre-se sempre de que o usuário tem a opção de exibir seu bloco quadrado ou largo e pode mudar essa opção quando quiser. Veja algumas regras gerais:
  • Centralize o logotipo horizontalmente no bloco.
  • Mantenha a mesma posição vertical do logotipo nos blocos quadrados e largos, que têm a mesma altura.

  • Inclua o nome do aplicativo na parte inferior do bloco, se o logotipo já não o incluir. Os exemplos a seguir mostram as duas situações.

    Blocos que usam o elemento de nome do aplicativo definido no manifesto:

    

    Blocos que incluem o nome do aplicativo na imagem do logotipo:

    

  • Para aplicativos com nomes maiores, e como o nome pode ser quebrado em duas linhas, verifique se a imagem do logotipo e o nome não ficam sobrepostos. Uma abordagem segura é restringir o logotipo a aproximadamente 80x80 pixels no recurso da imagem 100%.
  • Se você deixar o espaço transparente ao redor do logotipo na sua imagem, a cor da marca do seu aplicativo (declarada no manifesto) será mostrada com um gradiente pré-aplicado como parte da aparência do Windows 8. Essa tática seria usada com um logotipo, como o bloco do aplicativo de email mostrado anteriormente.

Uso inapropriado de blocos padrão

• Não crie o bloco padrão para incluir uma chamada de texto explícita para iniciar o aplicativo, como um bloco que diz "Clique Aqui!"

• Quando o logotipo inclui o nome do aplicativo, não repita o nome no campo Nome. Use um ou outro, como mostrado a seguir:

  

Usando modelos dinâmicos

Modelos dinâmicos oferecem conteúdo de bloco que se alternam entre dois quadros de informações dentro do espaço do bloco. O quadro superior é uma imagem ou uma coleção de imagens, e o quadro inferior é texto ou texto mais imagem. Para ver exemplos, confira O catálogo de modelos de bloco.

Uso apropriado dos modelos dinâmicos

• Use os modelos dinâmicos se o seu cenário tiver os dois tipos de conteúdo primário e suplementar e ambos imagens e texto. Bons exemplos incluem notificações para um email com foto ou uma notícia com layout de imagem/cabeçalho/corpo.
• O modelo dinâmico prende a atenção do usuário com sua animação, dessa forma, ele deve incluir um conteúdo atraente. Caso contrário, você vai apenas perturbar o usuário.
• Quando você usa um modelo dinâmico, sua exibição pode começar em qualquer extremidade (quadro) de seu ciclo—texto totalmente rebaixado ou texto totalmente elevado—e animar até em cima ou em baixo em direção à extremidade oposta. Portanto, verifique se o conteúdo de cada um dos quadros é autônomo.

Uso inapropriado dos modelos dinâmicos

• Não use modelos dinâmicos para exibir informações sobre o que o usuário já sabe. Por exemplo, uma notificação de vídeo pausado que aparece sobre um bloco não deve usar um modelo dinâmico.
• Não use modelos dinâmicos para notificações que não são agrupadas por conceito. Por exemplo, um modelo dinâmico nunca deve ser usado para enviar uma notícia com uma foto (ou fotos) que não faça parte do contexto.
• Não use modelos dinâmicos quando a parte mais importante da notificação pode ficar fora da tela por causa da animação dinâmica. Por exemplo, em um aplicativo de previsão do tempo que mostra a temperatura acompanhada por uma imagem (um sol sorridente ou uma nuvem), o uso de um modelo dinâmico significa que a temperatura (o ponto da notificação) não está sempre visível. Um modelo estático que mostra a imagem e a temperatura ao mesmo tempo é mais útil para o usuário.

Outras considerações de design

• Ao determinar como transmitir as informações de marca de um aplicativo em um bloco, escolha o nome do aplicativo, como mostrado aqui:

  

  ou a imagem do logotipo, como mostrado aqui:

  

  Esses itens são originalmente definidos no manifesto do aplicativo, e o desenvolvedor pode escolher qual dos dois exibir em cada notificação seguinte. Esses itens são originalmente definidos no manifesto do aplicativo, e o desenvolvedor pode escolher qual dos dois exibir em cada notificação seguinte.

• Não use os elementos de imagem ou texto para exibir informações de identidade visual do aplicativo em uma notificação de bloco. Não use os elementos de imagem ou texto para exibir informações de identidade visual do aplicativo em uma notificação de bloco. Para fortalecer a marca do aplicativo e manter a consistência para o usuário, a identidade visual deve ser transmitida por elementos do modelo específicos para essa finalidade: o nome do aplicativo (nome curto) ou a imagem do logotipo. O bloco pode mudar consideravelmente a sua aparência de notificação para notificação, mas o local do nome/logotipo é consistente. Isso garante que os usuários encontrem seus aplicativos favoritos com uma verificação rápida, vendo as informações no mesmo local em cada bloco.

  As imagens a seguir mostram blocos que usam os elementos de texto e imagem do modelo para transmitir a identidade visual de forma inapropriada. Observe que, nos dois casos, os blocos também usam o nome ou o logotipo como foram criados, dessa forma, a identidade visual adicional é uma informação redundante.

  

  Para saber mais sobre nome e imagem de logotipo, veja Guia de início rápido: criando um bloco padrão usando o Editor de Manifesto do Microsoft Visual Studio.

• Não use a identidade visual como um dos itens na fila de notificação nem como um dos quadros em um modelo dinâmico. Esses dois cenários envolvem modificações animadas no bloco, que prendem a atenção do usuário. Chamar a atenção do usuário através de uma animação apenas para exibir sua marca, em vez de um conteúdo novo interessante, só vai perturbá-lo.
• Se o nome do seu aplicativo não couber no espaço fornecido pelo "nome curto" opcional, use uma versão mais curta ou um acrônimo significativo. Por exemplo, você pode usar "Jogo da Contoso" no lugar do nome extenso "Jogo Divertido da Contoso Versão 3". Os nomes que excedem o número máximo de pixels são truncados com reticências. O comprimento máximo do nome é de aproximadamente 40 caracteres ingleses em duas linhas, mas varia de acordo com as letras específicas envolvidas. Incentivamos o uso de nomes de aplicativo mais curtos do ponto de vista do design. Observe que também é possível especificar um nome mais longo para o seu aplicativo (o "nome de exibição") no manifesto. Esse nome é usado no modo de exibição "Todos os aplicativos" e na dica de ferramenta, mas não no bloco.
• Não use blocos para anúncios.
• Evite o uso excessivo de cores fortes nos blocos. Blocos simples, limpos e com design agradável obtêm mais sucesso do que aqueles que gritam para chamar a atenção como uma criança birrenta.
• Não use imagens que contenham texto; use um modelo com campos de texto para qualquer conteúdo de texto. O texto em uma imagem não é tão nítido quanto o texto de bloco renderizado. Quando não é fornecido um ativo de imagem adequado à exibição atual, a escala da imagem pode ser ajustada, e isso pode prejudicar ainda mais sua legibilidade.
• Não confie em blocos para enviar informações urgentes em tempo real para o usuário. Por exemplo, um bloco não é a área certa para um aplicativo de comunicações informar ao usuário sobre uma chamada recebida. Notificações do sistema são um meio melhor para mensagens em tempo real.
• Evite conteúdo da imagem com aparência de hiperlink, botão ou outro controle. Blocos não oferecem suporte a esses elementos, e o bloco inteiro é um destino de clique único.
• Não use carimbos de data/hora nem datas relativos (por exemplo, "duas horas atrás") em notificações de bloco, porque eles são estáticos, enquanto o tempo muda continuamente, o que torna a mensagem incorreta. Use data e hora absolutas, como "11h".

Usando notificações de bloco

Escolhendo o método de notificação certo para atualizar seu bloco

Há vários mecanismos que podem ser usados para atualizar um bloco:

• Chamadas locais à API
• Notificações únicas agendadas, usando conteúdo local
• Notificações por push, enviadas de um servidor na nuvem
• Notificações periódicas, que transmitem as informações de um servidor na nuvem em um intervalo de tempo fixo

A escolha do mecanismo a ser usado depende amplamente do conteúdo que você quer mostrar e da frequência de atualização desse conteúdo. A maioria dos aplicativos provavelmente vai usar uma chamada local à API para atualizar o bloco quando o aplicativo for iniciado ou o estado for modificado no aplicativo. Isso garante que o bloco seja atualizado quando for iniciado e encerrado. A opção de usar notificações locais, por push, agendadas ou de sondagem, sozinhas ou combinadas, depende totalmente do aplicativo. Por exemplo, um jogo pode usar chamadas locais à API para atualizar o bloco quando o jogador atinge uma nova pontuação alta. Simultaneamente, o mesmo aplicativo de jogo pode usar notificações por push para enviar ao mesmo jogador as novas pontuações altas que seus colegas atingiram.

Para saber mais sobre como escolher o mecanismo certo para atualizar seu bloco, veja Escolhendo um método de entrega de notificação.

Com que frequência o bloco deve ser atualizado?

Se você usa um bloco, considere sua frequência de atualização.

• Para conteúdo personalizado, como contagens de mensagens ou qual é a fase do jogo, nós recomendamos que você atualize o bloco à medida que as informações ficam disponíveis, principalmente para o usuário não perceber atraso na atualização do conteúdo do bloco, dados incorretos ou ausentes.
• Para conteúdo não personalizado, como atualizações climáticas, nós recomendamos a atualização do bloco no máximo uma vez a cada 30 minutos. Dessa forma, seu bloco fica atualizado sem sobrecarregar o usuário.

Uso apropriado de notificações de bloco

• Use o que você sabe sobre o usuário para enviar notificações personalizadas a ele pelo bloco. Notificações de bloco devem ser relevantes para o usuário. As informações com as quais você tem que trabalhar são totalmente internas a seu aplicativo específico e podem ser limitadas pelas opções de privacidade do usuário. Por exemplo, um serviço de streaming de televisão pode mostrar ao usuário atualizações sobre seus programas mais assistidos, ou um aplicativo de condições do trânsito pode utilizar o local atual do usuário (se ele permitir) para mostrar o mapa mais relevante.

• Envie atualizações frequentes para o bloco, assim o usuário percebe que o aplicativo está conectado e recebendo conteúdo atualizado dinamicamente. A regularidade das notificações de bloco depende do cenário específico do aplicativo. Por exemplo, um aplicativo de mídia social ocupado pode ser atualizado a cada 15 minutos; um aplicativo de previsão do tempo, a cada duas horas; de notícias, algumas vezes ao dia; de ofertas diárias, uma vez por dia; e um aplicativo de revista, mensalmente. Se o seu aplicativo é atualizado menos de uma vez por semana, convém usar um bloco quadrado simples com uma notificação para evitar que o conteúdo pareça obsoleto.
• Forneça notificações de bloco atraentes e informativas para que os usuários tomem uma decisão consciente sobre quando iniciar seu aplicativo. Em geral, a notificação é um convite para o usuário iniciar o aplicativo com a finalidade de obter mais detalhes ou realizar uma ação. Por exemplo, uma notificação pode fazer com que o usuário queira responder a uma postagem em mídia social, ler uma notícia na íntegra ou saber os detalhes de uma promoção.
• Envie notificações sobre o conteúdo hospedado na home page ou na página de aterrissagem de seu aplicativo. Dessa forma, quando o usuário iniciar o aplicativo em resposta à sua notificação, ele vai encontrar facilmente o conteúdo descrito na notificação.

Uso inapropriado de notificações de bloco

• Não use blocos se não tiver conteúdo interessante, novo e personalizado para o usuário. Um aplicativo de cálculo, por exemplo, não tem nada disso.
• Não use blocos se a única coisa interessante para comunicar é o último estado do usuário. Aplicativos utilitários, ferramentas para desenvolvedores como o Microsoft Visual Studio e navegadores que só mostram miniaturas da última sessão do usuário não devem usar blocos.
• Não use blocos para enviar spam ou anúncios ao usuário. Isso vai tirar você da loja.

Diretrizes de experiência do usuário para selos

Uso apropriado de selos

• Use o tamanho de bloco quadrado com um selo se o aplicativo apenas oferecer suporte para cenários com notificações resumidas curtas. Por exemplo, um aplicativo de SMS que planeja mostrar apenas o número de novas mensagens de texto recebidas.
• Mostre um número na notificação quando ele for suficientemente pequeno para ser significativo em seu cenário. Se a notificação provavelmente sempre mostra um número igual ou maior que 50, pense em usar um glifo do sistema. As estratégias para tornar o número da notificação menos complicado incluem mostrar a contagem desde que o usuário iniciou o aplicativo, em vez da contagem absoluta. Por exemplo, mostrar o número de chamadas perdidas desde que o usuário iniciou o aplicativo é mais útil que mostrar o número total de chamadas perdidas desde que o aplicativo foi instalado.
• Use um dos glifos do sistema fornecidos para indicar uma mudança, quando o número é inútil ou complicado. Por exemplo, o número de novos artigos não lidos em um feed RSS de grande volume pode ser complicado. Em vez disso, use o glifo do sistema newMessage.
• Use um glifo quando o número não é significativo Por exemplo, se o bloco mostra uma notificação "pausada" de uma lista de reprodução, o glifo paused deve ser usado, pois um número não faz nenhum sentido para esse cenário.
• Use o glifo newMessage quando o número é ambíguo. Por exemplo, "10" na notificação do bloco de uma rede social pode indicar 10 novas solicitações, 10 novas mensagens, 10 novas notificações ou alguma combinação disso.
• Use o glifo newMessage em cenários de grande volume, como de email ou de mídia social, em que a notificação do bloco sempre mostra o valor máximo de "99+". Pode ser complicado para o usuário sempre ver o valor máximo, e ele não indica nenhuma informação útil, pois permanece constante.

Uso não apropriado de selos

• Não repita os números da notificação em outro lugar do conteúdo do corpo do bloco largo, pois as duas instâncias estariam sempre fora de sincronia.
• Não use glifos, se eles sempre disserem a mesma coisa. Os glifos representam notificações e estados temporários, e não algum tipo de marca ou estado permanente.

Diretrizes da experiência do usuário para blocos e notificações na tela de bloqueio

Para determinar se o seu aplicativo é um bom candidato para presença na tela de bloqueio, compreenda a operação e as limitações da tela de bloqueio. Um resumo da tela de bloqueio é fornecido aqui. Para saber mais, veja Visão geral da tela de bloqueio.

• Um máximo de sete notificações de aplicativo podem aparecer na tela de bloqueio. As informações da notificação refletem as informações da notificação no bloco da tela inicial do aplicativo. A notificação (um glifo ou um número) é acompanhada por um ícone monocromático (imagem do logotipo) para identificar o aplicativo ao qual a notificação está associada.
• Somente um desses sete aplicativos pode ocupar uma área de status detalhado, que permite a ele exibir o conteúdo de texto da atualização de bloco mais recente do aplicativo.
• O bloco de status detalhado da tela de bloqueio não mostra as imagens incluídas na atualização do bloco.
• O usuário é responsável por definir quais aplicativos podem exibir informações na tela de bloqueio e quais desses aplicativos podem exibir o status detalhado.
• Todos os aplicativos com presença na tela de bloqueio também podem executar tarefas em tela de fundo. Todos os aplicativos que podem executar tarefas em tela de fundo têm presença na tela de bloqueio. Um aplicativo não pode usar tarefas em tela de fundo sem também requerer uma área na tela de bloqueio.
• A fila de notificação não é permitida no bloco de status detalhado da tela de bloqueio. Apenas a última atualização é mostrada.
• Um aplicativo com presença na tela de bloqueio, desde que tenha definido a opção Toast Capable (Capacidade de Notificação do Sistema) como "Yes" (Sim) em seu manifesto, mostra suas notificações do sistema recebidas na tela de bloqueio quando ela está sendo exibida. A notificação do sistema mostrada na tela de bloqueio é idêntica a que é mostrada em qualquer outro local.
• Atualizações de bloco, atualizações de notificação e notificações do sistema não foram especificamente criadas nem enviadas para a tela de bloqueio. Você, como remetente, não sabe se o dispositivo está bloqueado no momento. Para um aplicativo com uma presença da tela de bloqueio, qualquer notificação é refletida na Tela inicial e na tela de bloqueio.

Características da boa presença na tela de bloqueio

A única maneira de seu aplicativo poder ter uma presença de tela de bloqueio é se o usuário oferecer permissão explícita. Ele pode fazer isso em resposta a uma solicitação de seu aplicativo (e só é possível perguntar uma vez) ou manualmente pela página Personalizar de Configurações do PC. Ao dar essa permissão, o usuário declara que as informações provenientes de seu aplicativo são importantes para ele. Seu aplicativo deve valer muito a pena. Portanto, considere se o aplicativo é um bom candidato para ter presença na tela de bloqueio.

Um bom candidato para presença na tela de bloqueio tem os seguintes atributos:

• Informações rapidamente assimiláveis
• Informações sempre atualizadas
• Informações claras sem contexto adicional
• As informações devem ser pessoais e úteis para o usuário
• As informações devem aparecer apenas quando houver uma mudança
• Somente notificações do sistema devem reproduzir um som ao chegarem

Informações rapidamente assimiláveis

Se a tela de bloqueio for exibida, isso significará que o usuário no momento não está interagindo com o dispositivo. Portanto, qualquer informação de atualização que o seu aplicativo exibir na tela de bloqueio deverá ser compreendida e assimilada rapidamente. Como analogia, pense em uma chamada recebida em um celular. Você olha para o telefone para ver quem está ligando e atende ou deixa cair na caixa postal. As informações exibidas na tela de bloqueio devem ser fáceis de compreender e manipular como no visor do celular. Todas as outras características dão suporte a essa.

Informações sempre atualizadas

Boas atualizações de notificação, atualizações de bloco e notificações do sistema, independentemente de aparecerem na tela inicial ou na tela de bloqueio, são todas potencialmente acionáveis. Com base nas informações fornecidas pelas notificações, o usuário pode decidir se vai iniciar o aplicativo como resposta, por exemplo, ler um novo email ou comentar sobre uma postagem na mídia social. Na tela de bloqueio, isso também significa desbloquear o dispositivo. Portanto, as informações têm que estar atualizadas para que o usuário tome uma decisão bem informada. Quando os usuários começam a perceber que as informações do aplicativo na tela de bloqueio não estão atualizadas, você perde a confiança deles e eles provavelmente vão encontrar um aplicativo informativo mais confiável para ocupar essa área na tela de bloqueio.

Bons exemplos: informações atualizadas

• O aplicativo de mensagens envia uma notificação quando chega uma nova mensagem. Se a notificação for ignorada, o aplicativo vai atualizar sua notificação com o número de mensagens perdidas. Se o usuário estiver presente, ele poderá ligar a tela para avaliar a importância da mensagem e decidir se vai responder na hora ou aguardar. Se o usuário não estiver presente, ele vai ver uma contagem precisa de mensagens perdidas quando retornar.

• Um aplicativo de email usa seu selo para exibir uma contagem dos emails não lidos. Ele atualiza o selo imediatamente quando chega um novo email. Um usuário pode ligar rapidamente sua tela para verificar quantos emails não lidos ele tem e confiar que a contagem está correta. Ele tem as informações para decidir se vai desbloquear seu dispositivo e ler os emails.

Maus exemplos: informações desatualizadas

• O aplicativo de mensagens atualiza sua notificação com o número de mensagens perdidas apenas uma vez a cada meia hora. O usuário não pode confiar no número da notificação para decidir se vai desbloquear o dispositivo.
• Um aplicativo de previsão do tempo que usa a área de status detalhado continua mostrando um alerta de mau tempo depois que o alerta já expirou. Isso não apenas transmite ao usuário informações incorretas, mas é particularmente negligente quando o texto especifica a data de término do alerta, deixando óbvio para o usuário que se trata de uma informação antiga. O usuário perde a confiança na capacidade do aplicativo de mantê-lo bem informado. O aplicativo deveria ter limpado essa informação no momento em que ela expirou.
• Um aplicativo de calendário continua exibindo um compromisso no passado. Mais uma vez, o aplicativo deveria ter limpado essa informação no momento em que ela expirou.

Informações claras sem contexto adicional

Estas informações contextuais não estão presentes na tela de bloqueio:

• O bloco que vai com o selo, quando o aplicativo não tem permissão para exibir o status detalhado. Mesmo quando o status detalhado é mostrado, o selo é fisicamente separado do bloco. A imagem de logotipo ao lado de um selo é a única identificação do aplicativo que ele representa.
• Imagens nas atualizações de bloco. Apenas a parte do texto da atualização aparece na área de status detalhado.
• A fila de notificação. Apenas a atualização mais recente aparece na área de status detalhado.

Portanto, suas atualizações devem ser compreensíveis ao usuário sem o contexto adicional disponível para você na tela inicial. Vale lembrar que as notificações não podem ser especificamente direcionadas na tela de bloqueio. Portanto, todas as comunicações de atualização do seu aplicativo devem cair na regra "compreensível sem contexto adicional".

Observação  Diferentemente do bloco detalhado, a notificação do sistema inclui tanto a imagem (se houver) quanto o texto — a notificação do sistema exibida na tela de bloqueio é idêntica à notificação do sistema de outros locais, por isso ela não perde contexto.

Bons exemplos: compreensível sem contexto adicional

• Um aplicativo de email usa sua notificação para exibir o número de emails não lidos. Mesmo que o bloco da tela inicial mostre mais informações, como trechos de texto dos emails mais recentes ou imagens dos remetentes, o que a notificação está transmitindo é compreensível sem essas informações extras.
• Um aplicativo de rede social usa a área de status detalhado para informar aos usuários sobre as atividades recentes de seus amigos. Quando um amigo lhes envia uma mensagem, o nome dele é incluído no texto da notificação (por exemplo, "Ana enviou uma nova mensagem a você!"). Na tela inicial, o usuário pode ter uma experiência elaborada com a imagem de seu amigo na notificação; enquanto na tela de bloqueio, mesmo sem nenhuma imagem, o texto ainda deixa claro quem enviou a mensagem.

Maus exemplos: incompreensível sem contexto adicional

• Um aplicativo de mensagens atualiza seu bloco com a mensagem recebida por último, mostrando apenas a imagem do remetente e o texto da mensagem. Na Tela inicial, fica claro para o usuário quem enviou a mensagem. Na tela de bloqueio, sem a imagem do remetente, o usuário não tem ideia de quem enviou a mensagem.
• Um aplicativo de rede social atualiza seu bloco com uma colagem de fotos, sem nenhum texto. Na tela inicial, é um bloco agradável e distinto. Na tela de bloqueio, como não há nenhum texto na atualização do bloco, não aparece nada.

As informações devem ser pessoais e úteis para o usuário

Dois dos principais objetivos da tela de bloqueio são: proporcionar uma superfície personalizada para o usuário; e exibir as atualizações do aplicativo. Avalie ambos os objetivos ao julgar se seu aplicativo é um bom candidato para uma presença de tela de bloqueio.

Aplicativos com presença na tela de bloqueio são muito especiais — apenas sete podem estar na tela de bloqueio de cada vez. Ao dar ao aplicativo uma dessas valiosas áreas da tela de bloqueio, o usuário mostra que as informações provenientes desse aplicativo são importantes o suficiente para visualização mesmo quando ele não estiver usando ativamente o dispositivo. Portanto, o aplicativo deve passar informações pessoais e úteis para o usuário.

Observação  Por definição, a tela de bloqueio é exibida quando o dispositivo está bloqueado. Nenhum logon ou outra barreira de segurança é necessária para ver o conteúdo da tela de bloqueio. Assim, apesar de as informações exibidas lá serem idealmente personalizadas, lembre-se de que qualquer um pode vê-las.

Bons exemplos: informações personalizadas para o usuário

• Um aplicativo de email exibe o número de emails não lidos na conta do usuário.
• Um aplicativo de mensagens exibe o número de mensagens perdidas enviadas para o usuário.
• Um aplicativo de notícias exibe o número de artigos novos nas categorias sinalizadas pelo usuário como favoritas.

Maus exemplos: informações impessoais

• Um aplicativo de notícias exibe o número de novos artigos vindos de seu serviço, sem considerar nenhuma das preferências indicadas pelo usuário.
• Um aplicativo de compras envia uma notificação sobre uma promoção, mas sem se basear em nenhuma preferência de categoria ou item especificada pelo usuário.

As informações devem aparecer apenas quando houver uma mudança

Como nós já mencionamos, o objetivo é que as informações na tela de bloqueio sejam assimiladas rapidamente. Dessa forma, quando o aplicativo não exibe uma notificação, fica uma lacuna na tela de bloqueio onde deveria aparecer a notificação. Isso aumenta as chances de um usuário perceber que alguma coisa precisa de sua atenção — a aparência da notificação e do logotipo que acompanha um evento é mais perceptível do que se eles estivessem lá o tempo todo sem passar nenhuma informação nova.

Não mostre o status pura e simplesmente. Status de longa execução ou que nunca são alterados só bagunçam a tela de bloqueio, ocultando as informações mais importantes. Uma notificação deve ser exibida apenas quando acontecer alguma coisa que o usuário tenha que saber. Isso também vale para a atualização de bloco. Remova o conteúdo obsoleto da notificação de seu bloco, fazendo com que o bloco seja revertido à sua imagem padrão na tela inicial e não exiba nada na tela de bloqueio.

Bons exemplos: somente informações úteis são exibidas

• Um aplicativo de email exibe um selo somente quando há emails não lidos. Quando chegam novos emails, o selo é atualizado e exibido.
• Um aplicativo de mensagens exibe o status da conexão apenas quando o usuário não consegue receber mensagens. O status "conectado" é o estado padrão considerado do aplicativo, portanto, não faz sentido passar essa informação. "Tudo está bem" não é uma notificação útil. Porém, informar ao usuário quando ele não pode receber mensagens é uma informação útil.

Maus exemplos: status de longa execução

• Um aplicativo de email ou mensagens não tem o número de mensagens não lidas para exibir e, portanto, mostra o status da conexão até chegarem novas mensagens ou emails. Isso reduz a capacidade do usuário de ver rapidamente se ele tem novas mensagens, pois a notificação está sempre presente.
• Um aplicativo de calendário exibe uma mensagem informando que o usuário não tem compromissos. Mais uma vez, isso reduz a capacidade de uso rápido da área de status detalhado, pois vai ter sempre alguma coisa exibida lá.

Somente notificações do sistema devem reproduzir um som ao chegarem

Não inclua código no aplicativo que reproduza um som quando o selo ou bloco for atualizado. Entretanto, uma notificação do sistema que chega pode reproduzir um som como foi projetada para fazer.

Seguindo as diretrizes descritas neste artigo, você pode criar aplicativos que exibem as informações certas, da forma correta, na tela de bloqueio, o que aumenta a satisfação do usuário e a confiança em seu aplicativo.

Quando usar a API de solicitação de tela de bloqueio

Chame a API de solicitação de tela de bloqueio (RequestAccessAsync) apenas se o aplicativo realmente precisar de privilégios de tela de fundo para funcionar adequadamente. Como há somente sete áreas em tela de fundo disponíveis, os usuários precisarão diferenciar quais aplicativos realmente precisam de privilégios em tela de fundo para funcionar adequadamente e quais não precisam (mesmo se ganhassem funcionalidade adicional).

Se um aplicativo absolutamente exigir privilégios em tela de fundo para atender às expectativas do usuário, recomendamos que ele use a API de solicitação para informar que o usuário precisa colocar o aplicativo na tela de bloqueio.

Entretanto, se um aplicativo atender às expectativas do usuário sem precisar de privilégios em tela de fundo, recomendamos que você não solicite explicitamente que o usuário coloque o aplicativo na tela de bloqueio. Em vez disso, deixe que o usuário coloque o aplicativo na tela de bloqueio pela página Personalizar de Configurações do PC.

Exemplos de aplicativos que devem chamar a API de solicitação:

• Um aplicativo de mensagens que exige privilégios em tela de fundo para receber mensagens quando o aplicativo não está em primeiro plano.
• Um aplicativo de emails que exige privilégios em tela de fundo para sincronizar a caixa de entrada do usuário quando o aplicativo não está em primeiro plano.

Exemplos de aplicativos que não devem chamar a API de solicitação:

• Um aplicativo climático que usa notificações periódicas em vez de atividade em tela de fundo para atualizar as previsões climáticas
• Um aplicativo de notícias que atualiza sua contagem de selos dos novos artigos em um horário específico do dia

Observação  Seu aplicativo não deve implementar sua própria caixa de diálogo para solicitar que os usuários adicionem o aplicativo à página de bloqueio. Se o seu aplicativo exigir que o acesso à tela de bloqueio seja executado adequadamente, basei-se na caixa de diálogo apresentada pela API de solicitação de tela de bloqueio. Se um usuário negou anteriormente direitos de tela de bloqueio ao seu aplicativo por meio dessa caixa de diálogo, a caixa de diálogo poderá não ser mostrada novamente. Nesse caso, você poderá usar o texto embutido em seu aplicativo para direcionar usuários para a página Personalizar de Configurações do PC para adicionar seu aplicativo à tela de bloqueio.

Solucionando problemas de notificações de bloco

Esta seção aborda alguns erros comuns que você pode encontrar ao trabalhar com blocos e modelos de bloco. A menos que especificado o contrário, cada solução aplica-se a todos os tipos de envio de notificação: notificações locais, agendadas, periódicas ou por push.

Também pode haver etapas de solução de problemas específicas a seguir em seu método de entrega da notificação. Para saber mais, veja estes tópicos:

• Diretrizes e lista de verificação de notificações periódicas
• Diretrizes e lista de verificação de notificações programadas
• Diretrizes e lista de verificação de notificações por push

A notificação de bloco local não é exibida

O problema mais comum nesta situação é que o XML utilizado para definir a sua notificação está incorreto de alguma forma. No entanto, há outras causas possíveis, para as quais estas etapas o guiarão:

• Verificar as configurações do usuário
• Fornecer recursos de logotipo grandes no manifesto do aplicativo
• Verificar os tamanhos de suas imagens
• Verificar suas URLs
• Examine seus formatos de imagem
• Verificar a sintaxe do seu XML
• Verificar a hora de expiração da notificação
• Verificar se você habilitou a fila de notificação

Verificar as configurações do usuário

Causa possível: O usuário ou administrador desabilitou notificações nas configurações. Verifique se o aplicativo forneceu uma opção Ativar/desativar bloco na barra de aplicativos e que ela não está definida como "desligado". Para o administrador, há diversas políticas de grupo que podem desabilitar as notificações. Verifique com o administrador para garantir que as notificações sejam habilitadas.

Correção: Habilite as notificações nas definições ou solicite que o administrador habilite notificações pela política de grupo.

Para saber mais, veja TileUpdater.Setting.

Fornecer recursos de logotipo grandes no manifesto do aplicativo

Causa possível: O manifesto do aplicativo não especificou uma imagem de recurso de bloco grande padrão. Se a imagem de bloco grande padrão não for fornecida, o bloco nunca exibirá modelos de notificação de formato grande. Além disso, notificações de bloco devem fornecer um modelo grande e quadrado na carga de notificação, porque, a menos que o bloco intencionalmente não tenha uma imagem grande, o remetente nunca tem garantia de que o bloco será exibido como quadrado ou grande quando a notificação chegar. Essa configuração é totalmente a critério do usuário.

Correção: Forneça um recurso de imagem de logotipo grande padrão no manifesto do aplicativo.

Verificar os tamanhos de suas imagens

Causa possível: As imagens de todas as notificações devem ser menores que 1024 x 1024 pixels e menos de 200 KB de tamanho. Se qualquer imagem na notificação exceder qualquer uma dessas dimensões, a notificação será descartada.

Correção: Reduza suas imagens.

Para saber mais, veja Tamanhos de imagens de bloco e notificação do sistema.

Verificar suas URLs

Causa possível: Erros de sintaxe da URL.

As imagens em notificação são fornecidas como uma referência de recurso ou um caminho literal. Se um caminho for usado, ele deverá ser fornecido usando um destes três protocolos:

Observação  O caractere ' /' funciona como um separador em cada tipo de especificação. Recomendamos que você sempre use ' /' em vez de ' \' para evitar confusão inadvertida com caracteres de escape.

Exemplos de boa formação:

Exemplos de má formação:

Examine seus formatos de imagem

Causa possível: As imagens estão em um formato sem suporte.

Notificações só podem usar imagens em formato .gif, .png ou .jpg/.jpeg. O formato da imagem também deve corresponder à sua extensão. Renomear simplesmente um tipo de arquivo incompatível com a extensão permitida não funciona.

A causa mais comum de erros no formato de imagem é a serialização de bitmaps para o armazenamento Windows.Storage.ApplicationData.current.localFolder. Certifique-se de chamar seu formato preferido ou a imagem será armazenada como um bitmap do Windows, e seu cabeçalho incluirá "BMP".

Para verificar: primeiro, verifique se você consegue enviar uma notificação somente de texto para restringir o problema à imagem. Uma forma de verificar o formato de sua imagem é carregar a sua imagem para um programa de processamento de imagem e salvá-la como .jpg. Se você mencionar este novo arquivo .jpg em sua notificação e o erro não se repetir, provavelmente ocorreu um erro de formato de imagem. Você também pode abrir o arquivo no editor binário do Visual Studio e examinar seu cabeçalho.

Correção: Altere ou corrija seus formatos de imagem.

Verificar sua sintaxe XML e conteúdo

Causa possível: Erros de sintaxe ou de validação XML.

Além da sintaxe básica, verifique se o seu XML está completo e correto. Alguns pontos comuns de falha no conteúdo XML incluem o seguinte:

• Diferenciação de maiúsculas e minúsculas. Nomes de marca, nomes de atributo e valores de atributo diferenciam maiúsculas de minúsculas. Verifique se o seu XML tem o uso correto de maiúsculas e minúsculas.
• Um elemento binding pode ser fornecido para cada tamanho de bloco. Se você oferecer suporte a blocos grandes, deverá fornecer os elementos binding de modelo quadrado e largo para cada bloco enviado.
• As cadeias de caracteres de texto não devem conter caracteres XML reservados. Por exemplo, você não pode aplicar itálico nas cadeias de caracteres do bloco incluindo as marcas <i> e </i>. Se você pretende mostrar os caracteres literais "<i>", eles devem ser o escape apropriado. Para saber mais sobre os caracteres de escape no XML, veja Entidades de caracteres XML e XAML.
• Os valores fornecidos para os atributos lang devem estar em conformidade para a especificação ITEF BCP 47.
• As cadeias de caracteres XML criadas localmente (para notificações locais ou agendadas) devem usar a codificação UTF-8. Quando são enviadas por meio de notificações por push ou sondadas de uma URL, as cadeias de caracteres devem usar a codificação UTF-16.
• Se você incluir um elemento image à sua carga XML com um atributo src não vazio, deverá incluir uma referência a uma imagem válida ou a notificação falhará.

Você pode usar o Log de Eventos para verificar se há erros quando sua notificação de bloco não for exibida. Procure eventos envolvendo sua notificação de bloco no Visualizador de Eventos em Aplicativos e Logs de Serviços > Microsoft > Windows > Immersive-Shell > Microsoft-Windows-TWinUI > Operacional.

Para verificar: Use um verificador de sintaxe XML, como o editor Visual Studio, para procurar erros básicos de sintaxe. Consulte a referência de modelo apropriada (TileTemplateType) para garantir que você tenha o número correto de imagens e que esteja atribuindo as imagens corretas para o índice de imagem correto.

Correção: Altere seu XML ou use um modelo diferente de acordo com seu conteúdo.

Certificar-se de que sua notificação não tenha expirado

Causa possível: O tempo de expiração é definido com um valor muito pequeno.

Se você tiver definido o tempo de expiração em sua notificação usando o método ExpirationTime (para uma notificação local) ou o campo do cabeçalho X-WNS-TTL (em uma notificação por push), certifique-se de que os valores representam milissegundos. Por exemplo, se você quiser que uma notificação de bloco dure exatamente uma hora, o valor deve ser 60 * 60 * 1000 = 3600000.

Correção: Use um valor maior.

Certifique-se de que você tenha habilitado a fila de notificação se quiser passar em ciclos pelas notificações

Causa possível: A fila de notificação de bloco não foi habilitada.

Por padrão, os blocos exibem apenas uma atualização por vez, e uma nova notificação de entrada substitui a existente. Se quiser exibir as últimas cinco notificações em uma rotação, você deve chamar TileUpdater.EnableNotificationQueue(true) no código de iniciação do seu aplicativo. Isso precisa ser feito pelo menos uma vez durante o ciclo de vida do seu aplicativo. Para saber mais, veja Como usar a fila de notificação com notificações locais.

Correção: Chame EnableNotificationQueue(true) em seu código de inicialização. Além disso, certifique-se de que as marcas de notificação sejam exclusivas.

Lista de verificação

Para saber mais sobre os requisitos gerais da Windows Store, veja Requisitos de certificação para aplicativos do Windows. Observe que, para ser aceito na Windows Store, você não pode usar seus blocos ou notificações para exibir anúncios.

Tópicos relacionados

Amostra de blocos e selos do aplicativo

Exemplo de aplicativo de tela de bloqueio

Guia de início rápido: Criando um bloco padrão com o editor de manifesto do Visual Studio

Guia de início rápido: Enviando uma atualização de bloco

Guia de início rápido: enviando uma atualização de notificação

Guia de início rápido: mostrando notificações na tela de bloqueio

O catálogo de modelos de bloco

Como agendar uma notificação de bloco

Como configurar notificações periódicas para blocos

Como usar a fila de notificação com notificações locais

Esquema XML de blocos

Visão geral de blocos e notificações de bloco

Visão geral das notificações

Visão geral da tela de bloqueio

A fila de notificação

Escolhendo um método de entrega de notificação