Diretrizes de blocos e notificações (aplicativos da Windows Store)

Este tópico descreve as práticas recomendadas e as recomendações de globalização/localização que devem ser usadas ao criar e atualizar o bloco do seu aplicativo, tanto na tela inicial quanto na tela de bloqueio, e lista todos os requisitos especiais relacionados ao bloco que seu aplicativo tem que cumprir para ser aceito na Windows Store.

Veja este recurso em ação como parte da nossa série sobre Recursos do aplicativo, do início ao fim:  Interface do usuário de aplicativo da Windows Store, do início ao fim

Um bloco é a representação de um aplicativo na tela inicial. No bloco, você pode apresentar um 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 são fornecidos em três tamanhos quadrados (pequeno, médio e grande) e em um tamanho largo. Diferentes modelos são fornecidos para os tamanhos médio, grande e largo, com texto, imagens ou uma combinação de texto e imagens. Alguns modelos, chamados modelos dinâmicos, consistem em dois quadros empilhados que rolam para frente e para trás no espaço do bloco. Os modelos dinâmicos estão disponíveis para os tamanhos de bloco médio e largo.

Os blocos podem ser dinâmicos (atualizados por meio de notificações) ou 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. Um bloco também pode exibir uma notificação de status, que pode ser um número ou um glifo.

Um bloco médio, largo ou grande pode, opcionalmente, mostrar a identidade visual em um canto inferior, usando o nome do aplicativo (em um bloco padrão ou dinâmico) ou um ícone pequeno (somente em blocos dinâmicos).

Veja dois pontos muito importantes que sempre devem ser lembrados:

  • O usuário pode redimensionar o bloco para qualquer tamanho compatível. Não há como você saber o tamanho que é exibido no momento na tela inicial do usuário. Todos os blocos devem ser compatíveis com os tamanhos pequeno e médio, mas também podem aceitar os tamanhos largo e grande. Observe que o suporte ao bloco grande requer também suporte ao bloco largo. Assim, para aceitar o tamanho de bloco grande, você precisa dar suporte a todos os quatro tamanhos de bloco. Os blocos grande e largo devem ser usados somente quando seu bloco der suporte a atualizações dinâmicas.
  • Se o seu bloco permite blocos dinâmicos, o usuário pode habilitar e desabilitar notificações de bloco quando quiser. Quando as notificações de bloco estiverem desabilitadas, o bloco será estático.

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

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.
  • Um bloco dinâmico é um ponto de venda que diferencia seu aplicativo, tanto de outros aplicativos da 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 fará que seu aplicativo seja visto com outros olhos. A descoberta inesperada de conteúdo interessante no aplicativo através do bloco deixará os usuários empolgados.
  • Se você usar um bloco dinâmico, é mais provável que o usuário fixe seu aplicativo (que está na exibição Aplicativos) na tela inicial para que ele possa ver as atualizações dinâmicas.
  • Se os usuários não gostarem do seu bloco, eles poderão colocá-lo no final da tela inicial ou desafixá-lo completamente, desabilitar 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: mostrar as manchetes mais recentes ou a 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 os diferentes tamanhos de bloco

Seu aplicativo sempre terá um bloco pequeno e médio. Forneça, pelo menos, um ativo de imagem de bloco médio no manifesto do aplicativo. Você também pode fornecer um ativo para o bloco pequeno, mas, se não o fizer, uma versão reduzida do ativo de bloco médio será usada.

Você deve decidir se também deseja permitir um bloco largo ou um bloco grande.

  • Para dar suporte a um bloco largo, inclua uma imagem do logotipo largo (largo 310x150) como parte do bloco padrão no manifesto do aplicativo. Se você não incluir essa imagem do logotipo largo padrão, o bloco só dará suporte aos tamanhos pequeno (quadrado 70x70) e médio (quadrado 150x150); ele não poderá ser redimensionado para o tamanho largo pelo usuário, nem aceitar notificações largas.
  • Para dar suporte a um bloco grande (quadrado 310x310), inclua uma imagem do logotipo largo e uma imagem do logotipo grande como parte do bloco padrão no manifesto do aplicativo. Se você não incluir essa imagem do logotipo grande, o bloco não poderá ser redimensionado para o tamanho grande pelo usuário, nem poderá aceitar notificações que usam modelos grandes. Como o suporte ao bloco grande requer o suporte ao bloco largo, incluir uma imagem do logotipo grande padrão sem incluir uma imagem do logotipo largo padrão é o mesmo que deixá-los de fora.
Para dar suporte a mais tamanhos de bloco que seu aplicativo aceita no momento, você deve lançar uma nova versão do aplicativo com um manifesto atualizado que inclua as imagens adicionais do logotipo padrão.
  • Use somente blocos pequenos e médios se seu aplicativo não for usar notificações de bloco para enviar atualizações ao usuário. O conteúdo de blocos largos e grandes sempre deve ser novo e atualizado regularmente. Se você não estiver usando um bloco dinâmico, não forneça um logotipo largo ou grande no manifesto.
  • Só use o bloco pequeno ou médio com uma notificação se o seu aplicativo aceitar cenários de notificações resumidas — ou seja, notificações que possam ser expressas somente por meio de um badge image ou de um único número. Por exemplo, um aplicativo SMS que pretende usar notificações para comunicar exclusivamente o número de novos textos recebidos. Não forneça um logotipo largo no manifesto.
  • Só use o bloco pequeno e médio se o seu aplicativo enviar 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 forneça um logotipo largo ou grande no manifesto.
  • Use o tamanho de bloco largo ou grande 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).
  • Use o bloco grande para mostrar várias histórias a partir de uma única notificação simultaneamente em um único bloco, para exibir listas mais extensas de itens ou para mostrar imagens que o usuário certamente gostaria de ver em tamanho maior na tela inicial.
  • Os blocos médios mostram menos conteúdo que os blocos largos e grandes; portanto, priorize o conteúdo. Não tente colocar tudo aquilo que você pode mostrar em um bloco largo no bloco médio. O bloco pequeno, ainda menor, aceita apenas notificações como conteúdo dinâmico.

    Um bloco largo com imagem e mensagem de texto ao lado de um bloco médio com apenas parte da mensagem de texto

    Se você tem conteúdo de bloco largo com imagem e texto, pode usar o modelo quadrado dinâmico para dividir o conteúdo em dois quadros. Porém, não use um modelo dinâmico se a própria imagem não for suficiente para transmitir a ideia da história.

As notificações devem fornecer conteúdo de modelo para todos os tamanhos de títulos compatíveis, exceto para o bloco pequeno, pois ele não pode saber o tamanho atual do bloco. Se uma notificação for definida usando somente um modelo largo e o bloco for exibido como médio, ou se a notificação for definida usando somente um modelo médio 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 e normalmente tem design simples. Para alguns aplicativos, o bloco padrão basta. Seu um usuário fixar um bloco da exibição Aplicativos na tela inicial depois que o aplicativo for instalado, o bloco padrão será mostrado na tela inicial até que esse bloco receba uma notificação. Se você forneceu uma imagem de logotipo largo, poderá especificar se o bloco será fixado por padrão na tela inicial como um bloco médio ou largo. Por padrão, o bloco do aplicativo será fixado como um bloco largo, se o tamanho de bloco largo tiver suporte no aplicativo por meio de uma imagem de logotipo largo especificado no manifesto. Caso contrário, o bloco será fixado em tamanho médio. Depois de fixado, o usuário poderá redimensionar o bloco para qualquer tamanho com suporte. Um bloco dinâmico poderá retornar ao seu padrão, se não tiver nenhuma notificação atual válida para mostrar.

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 ou logotipos do tipo largo e grande, considere a relação de design entre as imagens de bloco médio, largo e grande que vai fornecer. Lembre-se sempre de que o usuário tem a opção de exibir seu bloco com qualquer tamanho compatível 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. Mantenha o mesmo posicionamento vertical proporcional do logotipo no bloco grande.
    • Inclua o nome do aplicativo na parte inferior do bloco se a própria imagem do logotipo não o incluir. Lembre-se, entretanto, de que o bloco pequeno não tem a opção de exibir o nome do aplicativo. Os exemplos a seguir mostram as duas situações.

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

      Um bloco médio e um bloco largo, ambos usando o nome do aplicativo.

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

      Um bloco médio e um bloco largo, ambos com uma imagem que inclui o nome do aplicativo.

    • Para aplicativos com nomes maiores, como o nome pode ser dividido em duas linhas, verifique se a imagem do logotipo e o nome não ficam sobrepostos. Por exemplo, uma abordagem segura é restringir seu logotipo a cerca de 80x80 pixels no recurso de imagem 100% para os tamanhos de bloco médio e largo.
    • 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:

    Um bloco médio com o campo de nome e um bloco largo que inclui o nome do aplicativo na imagem do logotipo.

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 modelos dinâmicos se o seu cenário inclui conteúdo de imagem e texto que pode permanecer cada qual autônomo. Por exemplo, você pode mostrar a foto de um destino de viagem na parte superior do modelo e o nome da localidade na parte inferior.
  • 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 não deve ser usado se a foto não tiver nada a ver com o texto.
  • 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.
  • Não use modelos dinâmicos quando o texto for necessário para contextualizar a imagem, por exemplo, em uma notícia.

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:

    Bloco usando nome do aplicativo

    ou a imagem do logotipo, como mostrado aqui:

    Bloco usando logotipo do aplicativo

    Esses itens são definidos originalmente no manifesto do aplicativo, e o desenvolvedor pode escolher qual dos dois exibir em cada notificação seguinte. No entanto, depois de escolher o nome ou logotipo, você deve ater-se a eles para manter a consistência. Observe que, devido a restrições de espaço, alguns modelos não permitem mostrar o nome — sua única opção é mostrar ou ocultar o logotipo.

  • 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.

    Um bloco mostrando a identidade visual em um elemento de texto e um bloco mostrando a identidade visual em um elemento de imagem

    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 na exibição 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".
  • Como o bloco do aplicativo pode apenas iniciar o aplicativo na tela inicial, as atualizações de bloco devem referir-se a elementos do aplicativo que podem ser acessados facilmente nessa tela inicial. Por exemplo, o bloco de um aplicativo de notícias deve mostrar apenas artigos que o usuário pode encontrar facilmente na home page do aplicativo depois de clicar no bloco.

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.

Expiração de notificações de blocos

O conteúdo do bloco só deve persistir enquanto for relevante. Defina um prazo de validade para todas as notificações de bloco pertinente ao seu aplicativo. Por padrão, as notificações locais e agendadas de blocos nunca expiram; o conteúdo de blocos e de notificações enviado por notificações periódicas ou por push expira três dias após o envio. Quando uma notificação expira, o conteúdo é removido do bloco ou da fila e não é mais mostrado para o usuário.

Você pode definir uma data e hora específicas para o conteúdo da notificação expirar. Um prazo de expiração explícito é particularmente útil para conteúdo com tempo de vida definido. Além disso, se o seu serviço em nuvem parar de enviar notificações, se o seu aplicativo não estiver em execução há um bom tempo ou se o usuário se desconectar da rede por período prolongado, a expiração explícita garantirá a remoção do conteúdo obsoleto, apesar do estado de conectividade do sistema.

Por exemplo, durante um dia de negociações ativo do mercado financeiro, você pode definir a expiração de uma atualização dos valores das ações para duas vezes mais do que seu intervalo de envio (por exemplo, uma hora após o envio da notificação se você estiver enviando notificações a cada meia hora). Outro exemplo é um aplicativo de notícias que pode determinar que o prazo de 1 dia seja um período de expiração adequado para a atualização de blocos de notícias diárias.

Como você define a expiração depende do método de entrega. Para notificações por push e periódicas, ela é definida em cabeçalhos HTTP usados para se comunicar com o serviço em nuvem que entrega as notificações. Para notificações locais e agendadas, a expiração pode ser definida como parte da chamada à API.

Para saber mais, veja Cabeçalhos de solicitação e resposta do serviço de notificação por push, BadgeNotification.ExpirationTime, ScheduledTileNotification.ExpirationTime e TileNotification.ExpirationTime.

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 médio 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 dinâmicos se a única coisa interessante para informar for o último estado do usuário. Aplicativos utilitários, ferramentas para desenvolvedores como o Visual Studio e navegadores que só mostram miniaturas da última sessão do usuário não devem usar blocos dinâmicos.
  • Não use blocos para enviar spam ou anúncios ao usuário. Isso vai fazer que você seja expulso da Loja.

Diretrizes para a experiência do usuário com notificações

Uso apropriado de notificações

  • Só dê suporte ao tamanho de bloco médio com notificação se o seu aplicativo for compatível com cenários de notificações resumidas. Por exemplo, um aplicativo de SMS que pretende mostrar apenas o número de novas mensagens de texto recebidas. Lembre-se de que as notificações são vistas mesmo se o usuário redimensionar o bloco para o tamanho pequeno.
  • Mostre um número na notificação quando ele for suficientemente pequeno para ser expressivo 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. Como estratégia para tornar o número da notificação mais simples, é preferível mostrar a contagem desde que o usuário iniciou o aplicativo pela última vez a mostrar a contagem absoluta. Por exemplo, mostrar o número de chamadas perdidas desde que o usuário iniciou o aplicativo é melhor do 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 notificações

  • 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 presença na tela de bloqueio, toda 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

Se a tela de bloqueio for exibida, isso quer dizer que o usuário 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 entender 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 especificadas nessas notificações, o usuário pode decidir se vai iniciar o aplicativo como forma de resposta, por exemplo, para 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 sua notificação para exibir uma contagem de emails não lidos. Ele atualiza a notificação 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 a notificação quando o aplicativo não tem permissão para exibir o status detalhado. Mesmo quando o status detalhado é mostrado, a notificação é fisicamente separada do bloco. A imagem do logotipo ao lado de uma notificação é 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 uma notificação somente quando há emails não lidos. Quando chegam novos emails, a notificação é atualizada e exibida.
  • 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 a notificação ou o 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 notificações 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.

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 notificações 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
Diretrizes de blocos secundários

 

 

Mostrar:
© 2014 Microsoft. Todos os direitos reservados.