web-development-kb-pt.site

Operações em duas etapas e convenções de botões

Nosso aplicativo da web possui três operações diferentes, procedendo da seguinte maneira:

  1. O usuário é apresentado com um pop-up em que diferentes configurações são selecionadas.
  2. O usuário pode clicar em um botão rotulado com a operação (ex: "Mesclar") ou "Cancelar".
  3. Se o usuário avança, o aplicativo processa a operação, que pode demorar alguns instantes e outro pop-up é apresentado, resumindo o que acontecerá. Neste ponto, a operação não foi confirmada e o usuário pode optar por continuar ou cancelar.

É aqui que nossas três operações não estão alinhadas. Em um caso, a escolha é Continuar/Cancelar, em outro é Concluído/Interromper e, finalmente, temos Finalizar/Cancelar.

Qual destes é o melhor? Existe uma alternativa melhor? Em caso afirmativo, algum argumento de apoio?

buttonspopupconventionslabels
3
carrier

Normalmente, tento me afastar de rótulos genéricos de botões como esses e ser o mais específico possível. Seus rótulos parecem muito "banco de dados-y" para mim e me lembram ferramentas projetadas por programadores para domínios muito abstratos (como ... editores de banco de dados).

Consulte esta pergunta relacionada sobre o posicionamento do botão OK/Cancelar para mais algumas discussões:

OK/Cancelar à esquerda/direita?

Na minha resposta, vinculei a pesquisa de Jakob Nielsen sobre os botões OK/cancelar , onde ele observa que:

Geralmente, é melhor nomear um botão para explicar o que ele faz do que usar um rótulo genérico (como "OK"). Um rótulo explícito serve como "ajuda na hora certa", dando aos usuários mais confiança na seleção da ação correta.

Por exemplo, alguns exemplos:

Além disso, você pode considerar deixar de fora a alternativa . Em alguns casos, isso pode fazer sentido. Eu acho que uma opção "cancelar" é boa para incluir se o usuário está prestes a assumir um compromisso significativo, como comprar algo ou uma operação CRUD que envolve muitos dados.

Mas para algo simples, como twittar, especialmente quando há uma reversão fácil disponível após a operação de confirmação, não há problema em deixar de fora o botão "cancelar" explícito, pois é óbvio que não continuar não confirmará nada.

Um ótimo exemplo é o formulário de comentários do StackExchange, que possui apenas um botão "Adicionar comentário" e não há como ocultar ou cancelar o formulário. Não quer adicionar um comentário? Não clique em "Adicionar comentário"!

10
Rahul

Soa como um assistente. Aqui está um exemplo:

  1. O usuário inicia a função Mesclar
  2. Um pop-up aparece, intitulado Mesclar .
    Ele contém configurações para o comando e Next > e Cancel.
  3. O usuário altera as configurações e clica em Next >.
    O aplicativo processa a operação por alguns instantes.
  4. A próxima página do assistente é exibida. Possui os botões Finish e Cancel.
    Se o usuário clicar em Finish, a operação será concluída; Cancel cancela a coisa toda.

Outra abordagem é torná-lo um processo de uma etapa, mas permitir desfazer. Isso pode ou não ser possível, dependendo da operação.

  1. O usuário inicia a função Mesclar
  2. Um pop-up é exibido, contendo as configurações do comando e os botões Merge e Cancel.
  3. O usuário altera as configurações e clica em Merge.
    O aplicativo processa a operação por alguns instantes e a completa.
  4. A tela mostra os resultados da operação e inclui um botão Undo. Se o usuário clicar em Undo, a operação será revertida.
3
Bennett McElwee

Gostaria de fazer dois pontos:

1) Se o processo de mesclagem real for iniciado após a segunda tela (com resumos), o botão "Mesclar" deverá estar nessa segunda tela. O que me leva a dizer que, no primeiro, o botão deve dizer algo como "Visualizar resultados da mesclagem" ou semelhante, porque este é o próximo resultado que o usuário obterá no fluxo do processo iniciado.

2) Esse é um tipo de sugestão assustadora de recurso, mas talvez faça sentido ter três botões na primeira tela: "Visualização mesclada", "Cancelar" e "Mesclar sem visualização". Isso economizaria algum tempo para o usuário que sabe o que está prestes a fazer e não deseja esperar pelas estatísticas e depois se comprometer com sua decisão. Apenas uma ideia...

0
Jüri

Se você não está realmente realizando a "mesclagem" após clicar em Mesclar, não deve chamá-lo de Mesclagem.

Freqüentemente, o que é usado em um formulário de vários estágios é uma convenção Continuar/Enviar. Continuar implica que você deve continuar para o próximo estágio, mas isso não implica que algum compromisso seja colocado ainda.

No caso de uma loja on-line, o check-out geralmente exige que o usuário siga alguns formulários, fornecendo detalhes de endereço e pagamento. Até a página em que eles finalmente podem confirmar o pedido é usado o botão "Fazer pedido" ou "Confirmar compra".

Eu usaria um botão "Preview Merge" ou "Continue" e, na página em que eles confirmaram, use o botão "Perform Merge" ou "Submit".

0
Nick Bedford