1. UX: caixas de mensagem são principalmente más
As caixas de alerta são ruins em todos os casos do ponto de vista do UX. Em aplicativos de desktop. Nos aplicativos da web como alertas ou mensagens JavaScript embutidas. Em toda parte.
Você pode ler About Face 3, de Alan Cooper¹, se quiser saber o porquê; explica muito bem como isso interrompe o fluxo de trabalho e incomoda o usuário e como quase todas as caixas de alerta existentes no software atual estão profundamente erradas . Na página 542, "A caixa de diálogo que clamava" Lobo! "" Explica que as caixas de alerta são descartadas rotineiramente, para que seu modelo seja completamente quebrado. Na página 543 do livro, estão listados três princípios principais de design:
- Faça, não pergunte.
- Torne todas as ações reversíveis.
- Forneça feedback sem modelo para ajudar os usuários a evitar erros.
Em seguida, os autores nos dizem como substituir as caixas de alerta pela abordagem de design correta.
As mensagens de prompt são um pouco diferentes. E ainda assim, eles quebram a experiência do usuário do seu aplicativo. Se você deseja que o usuário insira algo, considere usar uma caixa de texto ou uma área de texto, decorá-lo com JavaScript quando necessário. Não seja preguiçoso, forneça uma interface rica em uma era de aplicativos habilitados para RIA e AJAX ; em todos os casos, se o JavaScript estiver desativado, seu prompt não será exibido.
Nas páginas da Web, as caixas de alerta e os prompts são principalmente irritantes. Alguns exemplos:
Alguns fóruns permitem criar listas solicitando infinitamente os itens da lista. Isso significa que, ao criar a lista, você não pode usar a própria página, incluindo copiar e colar. Você também tem um único campo minúsculo. E o texto longo? E negrito e itálico?
"Se você continuar, a foto será removida definitivamente do seu perfil. Você tem certeza?" . Claro que tenho certeza! Caso contrário, clique em "Remover foto do meu perfil"? Por que seu aplicativo Web suponha que eu seja tão estúpido? Na verdade, os aplicativos do Google como GMail mostram a abordagem correta. Você pode remover, excluir, destruir o que quiser e, ao fazer isso, o aplicativo exibe um pequeno link "Desfazer".
"Você quer fazer nossa maior pesquisa?" . Bem, na verdade eu estava lá para visitar o seu site, mas como você me incomoda com suas mensagens irritantes, prefiro ir para outro lugar.
"O botão direito do mouse está desabilitado neste site para proteger fotos protegidas por direitos autorais" . Bem, na verdade, cliquei com o botão direito do mouse para alterar o idioma do corretor ortográfico antes de enviar meu comentário. Claro, vou enviá-lo sem verificar a ortografia.
Conclusão: do ponto de vista da experiência do usuário, os aplicativos usam caixas de mensagens incorretamente na maioria das vezes.
Mas espere! Muitos sites de baixa qualidade substituem as caixas de alerta irritantes por mensagens irrelevantes do JQuery por um plano de fundo semitransparente que cobre toda a página. Portanto, as desvantagens permanecem.
Bem, existem outros motivos para não usar caixas de mensagens em aplicativos da web:
2. Design: caixas de alerta têm seu próprio design
Você não pode criar uma caixa de alerta. Você não pode mudar sua cor, tamanho, fonte. Isso torna ainda mais irritante para o usuário: você estava trabalhando com um aplicativo Web e seu fluxo de trabalho é interrompido por uma mensagem que parece vir do nada e nem sequer corresponde ao aspecto visual do aplicativo. Sem contar que o idioma dos botões também corresponde ao idioma do sistema operacional / navegador, e não do aplicativo da web.
Para os designers, as mensagens JavaScript são muito mais poderosas que as caixas de alerta.
Eles também são muito mais extensos. Você pode adicionar negrito e itálico, pode escolher seus próprios botões (que tal: "Pedimos desculpas, mas a senha digitada é inválida. [Redefinir minha senha] [Tente outra] [Cancelar]"?) ².
3. JavaScript: o fluxo do aplicativo para
Ao exibir uma caixa de alerta, o JavaScript para de executar até o usuário clicar. Em um site, pode estar tudo bem. Com um aplicativo Web, muitas vezes se torna um problema.
4. Sandbox: não force o usuário a reiniciar seu computador
Lembra dos sites ruins que mostram um número infinito de caixas de mensagens ? A única maneira de os usuários sem formação técnica suficiente para continuar trabalhando era de fato reiniciar o computador. Isso nos leva a um problema: as caixas de alerta estão fora do escopo do site ou aplicativo da web. Você não está autorizado a impedir que o usuário acesse outras guias do navegador³.
O mesmo problema forçou os navegadores a resolvê-lo de maneiras diferentes. O Firefox, por exemplo, permite o acesso a outras guias ao exibir um alerta na sua guia. O Chrome, por outro lado, permite que você verifique se não deseja mais receber caixas de alerta de uma página, mas ainda bloqueia o acesso a outras guias.
Embora a abordagem do Firefox seja perfeitamente válida, a do Chrome pode ser criticada (já que ainda bloqueia todas as guias) e causa um problema: e se o usuário estivesse severamente irritado com várias caixas de mensagens emitidas pelo seu aplicativo e verificasse o caso, e então, você tentou mostrar algo realmente importante? Certo, o usuário nunca o verá.
O fato permanece o mesmo: a maioria dos usuários fica incomodada com as caixas de alerta, por isso ainda não são muito amigáveis e podem bloquear severamente um usuário sem experiência técnica suficiente. Inline, as mensagens JavaScript podem bloquear a página, mas não o próprio navegador. Como o modelo de aplicativo da web é uma espécie de sandbox, onde você não pode, por exemplo, acessar o teclado do usuário ou reinicializar o computador ou ler arquivos do disco rígido ou ir para tela cheia ou usar dois monitores, as caixas de alerta com efeito de bloqueio quebram severamente isso. modelo de sandbox .
Por último, mas não menos importante, e se o usuário estivesse em outra guia quando seu aplicativo decidisse mostrar a caixa de alerta? E se o usuário estivesse fazendo algo importante e não quiser interagir com seu aplicativo no momento?
¹ Sobre a Face 3, Os fundamentos do design de interação , Alan Cooper, Robert Reimann e David Cronin, ISBN 978-0-470-08411-3; Capítulo 25: Erros, alertas e confirmações.
² Este é apenas um exemplo. Por favor, não faça isso em seus aplicativos da Web, pois é realmente uma má escolha de design.
³ Se você quiser uma comparação com o mundo dos aplicativos de desktop, uma mensagem JavaScript embutida é como uma caixa de mensagem de um aplicativo de desktop. Uma caixa de alerta em um navegador, por outro lado, é como uma janela que aparece do nada, definida como superior, em um fundo opaco de tela cheia que impede você de acessar qualquer outro aplicativo da área de trabalho. Qualquer aplicativo que decidir fazer isso uma vez no meu computador será removido imediatamente e para sempre.