Manipulando vários pop-ups de "alerta"?

ninguém gosta de alertas (que eu saiba), mas para várias mensagens assíncronas, uma interface de 'rosnar' até agora parece bastante atraente. Depois de revisar vários plugins específicos do jQuery para 'notificação', achei o seguinte bastante útil:

http://pines.sourceforge.net/pnotify/

Tente clicar nas demonstrações simples e observe as notificações em javascript no lado direito da sua página.

Consideração básica aqui: você precisa interromper o usuário?

O erro precisa ser mostrado em um pop-up ou pode ser mostrado no fluxo do aplicativo? Por exemplo. é uma exceção ou é uma notificação? "A página não pôde ser carregada" tem um significado e peso diferentes para algo como "O retweet falhou. O Twitter não respondeu."

Pensar nessas diferenças leva a alguns pensamentos:

• Se for um erro crítico, você deve interromper o fluxo do aplicativo e alertar o usuário. "A página não pôde ser carregada" precisa aparecer porque não há mais nada que possa acontecer em paralelo.
• Erros não críticos, como "Falha no retweet" em um aplicativo do Twitter, não devem interromper o fluxo, pois você interromperá o uso do aplicativo pelo usuário, que geralmente será algo como ler ou escrever.
• O que o usuário está fazendo? Se o usuário estiver executando alguma tarefa seqüencial, por exemplo. preenchendo um formulário e depois mostre ao usuário os diferentes erros agrupados.
• Considere projetar sua saída do problema. Por exemplo, não trate o erro como um erro. No exemplo "retuitar", a API do Twitter é uma dependência externa e, portanto, todas as chamadas para ela devem ser tolerantes a falhas, incluindo feedback para o usuário na interface do usuário. Isso afeta a maneira como o usuário percebe seu aplicativo: se você sempre exibir um erro sempre que alguma exceção acontecer, o usuário perceberá um aplicativo instável e irritante que a interrompe. Se você alinhar os erros e exibi-los como notificações inevitáveis ​​que simplesmente acontecem porque o Twitter pode estar inativo às vezes, ele será apresentado de maneira muito diferente.
• Veja as convenções de plataforma para o iPad. Consulte as diretrizes da interface humana Apple Human Interface e veja os principais aplicativos. Minha experiência com o iPad foi a de que existem muito poucos estados de erro nos aplicativos; isso pode ser devido a ótimos testes ou devido a o fato de os designers terem projetado possíveis estados de erro fora do aplicativo. Considere o seguinte exemplo: em um formulário da Web, se você solicitar números de telefone em um determinado formato específico, você acabou de introduzir um possível estado de erro no qual o usuário preenche incorretamente No entanto, se você aceitar qualquer formato, esse é um problema a menos para o usuário se preocupar.Por vezes, me pergunto se os designers de aplicativos para iPad se inclinam para esse tipo de design.

Sruly postou uma resposta enquanto eu escrevia isso e parece muito específico e técnico. Espero que minha resposta possa contribuir com algum pensamento de alto nível.

ivo

Howl é para iPad o que Growl é para Mac

É capaz de empilhar automaticamente vários alertas. Os alertas podem desaparecer após um segundo, se não for um alerta grave. Você também pode criar alertas que o usuário deve dispensar. Growl é usado em um grande número de programas para Mac, não sei quão popular é o Howl.

Embora você não queira usar padrões do Windows para um produto Apple.

Alguns padrões a serem considerados. (No Windows)

• Os ícones do notificador da barra de tarefas mostram uma mensagem de cada vez e, quando você fechá-la ou atinge o tempo limite, outra é exibida.

• Algumas mensagens são empilhadas e cada mensagem subsequente é movida alguns pixels para baixo e para a direita.

• Algumas mensagens (como um alerta em JS) são bloqueadas até serem respondidas, portanto, obviamente, só pode haver uma de cada vez.

• Algumas mensagens (como os alertas do sistema Windows quanto a riscos à segurança) são exibidas em uma caixa, mas com todas as mensagens existentes.

• Os sites StackExchange colocam notificações importantes em cima e as menos importantes podem aparecer depois que você executa uma ação.

Como não sei exatamente o que você está construindo, é difícil fazer uma sugestão, mas através de um processo de eliminação posso reduzi-la.

Como você tem pixels de tela limitados, o agrupamento de mensagens em uma caixa pode roubar muito espaço na tela.

Você provavelmente não deseja que seu aplicativo seja bloqueado, a menos que haja um erro crítico, portanto os alertas no estilo JS provavelmente estão fora.

O empilhamento de pop-ups sem bloqueio não funcionaria novamente devido à falta de espaço na tela.

Eu acho que isso deixa você com apenas algumas opções. Um pop-up que não bloqueia, desaparece ou desaparece quando clicado (como o ícone de notificação aparece na barra de tarefas do Windows ou as pequenas notificações no StackExchange) ou uma área de notificação (como a barra superior no StackExchange)

Eu provavelmente exibiria um alerta de estilo transparente de placa de rua e o deixaria no canto superior direito ou no canto inferior direito.

Sempre que ocorrer um erro, você poderá exibir o símbolo e, se ocorrer outro erro, poderá piscar o alerta com uma cor mais brilhante e adicionar um contador ao lado dele com o número de erros que eles receberam. Além do símbolo e do contador, você pode querer um rótulo de um ou dois Word. Algo curto e direto ao ponto seria provavelmente o melhor para economizar em imóveis.

Quando o usuário pressiona (clica) no alerta, ele pode exibir uma caixa com sua lista de erros.