Prompt de JavaScript, confirmação e alerta considerados "antiquados" [fechado]

Ultimamente, tenho desenvolvido um sistema de gerenciamento baseado na Web para uma academia. O aplicativo anterior foi desenvolvido no Visual Basic. Para o novo aplicativo, todos os scripts de front-end usam jQuery, o servidor está executando PHP e MySQL ... você sabe, a típica pilha baseada em el-cheappo linux.

De qualquer forma, eu estava me perguntando por que as mensagens de alerta, confirmação e alerta do JavaScript são tão subutilizadas hoje em dia. Existem muitos plugins jQuery para janelas modais e mensagens de alerta que tentam imitar algo que o idioma já oferece e todos os navegadores são obrigados a oferecer suporte adequado.

O uso de soluções feitas à mão ou baseadas em plugins é adequado para formulários complexos e necessidades especiais, mas se você precisar apenas pedir um valor único ou confirmar a exclusão de um registro, por que você adicionaria essa sobrecarga ao seu aplicativo da web? Além disso, o iOS e o Android oferecem diálogos de mensagens bem adaptados quando você usa o prompt, a confirmação e o alerta.

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:

1. 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?

2. "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".

3. "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.

4. "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.}

Conclusão: as caixas de diálogo padrão de prompt, confirmação e alerta correspondem ao estilo do seu navegador, não ao estilo do seu site. A maioria das pessoas da interface do usuário deseja que todas as caixas de diálogo fluam com a interface do usuário do site. Eles usam janelas modais para apresentar mensagens e coletar dados usando as mesmas fontes e cores da interface do usuário do site, não o cinza e azul padrão do MSIE ou FF.

Você só adicionará sobrecarga se não precisar das caixas de diálogo sofisticadas em outro lugar, o que provavelmente faz. Nesse ponto, não faz muita diferença se a funcionalidade está incluída como parte do navegador ou como parte da estrutura que você está usando, e você também pode manter todos os seus pop-ups com aparência consistente.

Embora você possa fazer muito com javascript e sem estruturas, lembro como era o desenvolvimento em javascript antes que as estruturas estivessem disponíveis, e eu não gostaria de voltar a ele.

Porque os navegadores não os tratam muito bem . Como você deve ter notado, eles geralmente são diálogos modais e não apenas impedem que os usuários movam e redimensionam seus navegadores, mas também impedem o acesso a outras guias, o que é muito irritante.

Para diálogos como confirmar e alterar, ainda acho que o navegador deve impor o comportamento e, para o navegador Firefox mais recente, você pode ver que eles corrigiram o problema mencionado acima. Eles usam alertas de página com escopo definido para a página atual.

Portanto, sugiro que você substitua o comportamento do alerta para que todos os navegadores possam lidar (pelo menos alertas) com mais elegância.

Alguns motivos resumidos:

• Essa é a API padrão e os desenvolvedores podem descobrir o que você está tentando fazer.
• É mais fácil de usar e parece melhor.
• Suporte à plataforma, sites para celular podem precisar da API nativa.