Usabilidade:Salvar as alterações usando o botão “Aplicar” ou após cada alteração?

Question

Estou interessado em ouvir opiniões e experiências de colegas desenvolvedores sobre design de interface de usuário, usabilidade E manutenção.

A abordagem comum é permitir que os usuários ajustem as opções e depois que o formulário ficar "sujo", ative o botão "Aplicar" e o usuário tenha a possibilidade de voltar atrás pressionando cancelar.Esta é a abordagem mais comum na plataforma Windows (acredito que as diretrizes de usabilidade da MS também dizem para fazê-lo).

Outra maneira é aplicar as alterações após cada alteração ter sido feita nas opções.Exemplo, o usuário marca alguma caixa de seleção e a alteração é aplicada.O usuário altera o valor de alguma caixa de texto e a alteração é aplicada depois que a caixa perde o foco, etc.Você entendeu.Essa abordagem é mais comum no Mac OSX.

Independentemente da minha opinião pessoal (que a Apple é melhor em usabilidade, mas o software que costumo escrever é voltado para usuários do Windows), o que vocês acham?

Editar:Estou plenamente consciente de que esta não é uma questão real, mas sim uma discussão, e que o seu lugar pode não ser no SO, cuja política é ter apenas respostas e perguntas.Mas acredito que poderia ser uma discussão útil, principalmente porque não consegui encontrar nada parecido antes de perguntar.

Answer 1

Ambos têm seus lugares e são usados ​​em muitas plataformas (eles não são realmente um diferencial entre PCs e Macs).

A abordagem do botão "Aplicar" permite que você faça algumas alterações, aplique-as e não precise reabrir a caixa de diálogo para fazer mais alterações.Isso é útil para experimentar coisas, mas quando você deseja que o usuário pense metodicamente (ou se sinta seguro) sobre suas escolhas - o usuário controla precisamente quando suas alterações são aplicadas.Isto é importante em alguns casos onde você pode não querer submeter suas alterações até ter feito várias delas, ou em casos onde o usuário deve saber qual configuração deseja, em vez de precisar "experimentar".Essas caixas de diálogo geralmente também possuem um botão Cancelar que (espero) desfaz quaisquer alterações feitas desde a abertura da caixa de diálogo.Essas caixas de diálogo geralmente são modais, de modo que o usuário fica bloqueado na caixa de diálogo até que faça suas escolhas.

A caixa de diálogo de efeito instantâneo permite ao usuário experimentar e ver atualizações “ao vivo” com base em suas escolhas.Isso é ótimo quando o usuário deseja experimentar opções para ver que efeito elas terão.É preciso ter cuidado com o estilo visual para deixar claro ao usuário que ele está operando "ao vivo", e ele deve ter cuidado porque não pode voltar atrás em suas alterações.A abordagem da Microsoft para esse tipo de diálogo é ter um único botão “Fechar”, o que torna óbvia a abordagem de efeito instantâneo.Esses diálogos geralmente não são modais, ou seja,eles são tratados como "painéis de edição ao vivo" em vez de caixas de diálogo.

Geralmente, a UI está inclinada para o lado da edição ao vivo, pois permite que os usuários sejam experimentais e livres de detalhes técnicos, como ter que pressionar um botão especial para confirmar alterações (veja os painéis de controle no Win7, por exemplo - quase nenhuma caixa de diálogo modal comparada para XP)

No entanto, em última análise, a escolha entre essas duas opções depende do tipo de configuração que você deseja controlar.ou sejaSe você estiver configurando estilos de fonte em algum texto, então você realmente deseja estar no extremo experimental do espectro, mas se estiver configurando grupos de informações importantes e relacionados (por exemplo,o endereço do seu servidor DNS e sua máscara de sub-rede), você pode querer usar algo que exija que você pense/saiba e aplique deliberadamente sua alteração (para que os usuários possam inserir e verificar novamente as informações, e para que possam alterar várias informações relacionadas " simultaneamente".Além disso, se você confirmar um endereço de servidor DNS ao vivo enquanto o usuário o digita, ele perderá a conexão de rede até acertar todos os dígitos - ao vivo simplesmente não faz sentido para isso).

Answer 2

Corresponder às expectativas da plataforma.

Eu também concordo que a Apple é superior em termos de usabilidade, mas suas decisões devem se basear no comportamento mais comum que sua plataforma de destino exibe. Você deve sempre fazer o que surpreende, menos os usuários e para a maioria dos usuários do Windows, acho que é para manter o OK/Apply/Cancel comportamento.

Se você tiver aplicativos de plataforma cruzada, separe as GUIs que respeitam o corresponder às expectativas da plataforma Mantra. Sim, é um trabalho extra, mas mostra que você se importa.

Answer 3

Concordo que, em geral, você precisa corresponder às expectativas da plataforma.

Pessoalmente, no entanto, geralmente prefiro o uso de aplicar/salvar por dois motivos: 1) uma mudança parcialmente aplicada pode ser perturbadora (em atraso ou em artefatos de tela real) 2) Certos estados ou combinações podem não ser válidos (ou podem não ser válido na percepção do usuário). 3) Se você fornecer uma maneira de desenrolar as alterações ou salvar alterações com nomes significativos, fará sentido agrupá -los logicamente com base em quando o usuário optar por pressionar Aplicar ou salvar. Como desenvolvedor, gosto de uma abordagem de comprometimento/reversão das coisas, e gosto disso nas minhas UIs também.

Answer 4

Só consigo pensar em duas boas razões para ter um botão Aplicar:

1. As alterações não podem ser aplicadas instantaneamente, mas bloquearão a GUI por uma quantidade perceptível de tempo.
2. As mudanças só fazem o SEnce juntos (como uma transação).

Nenhum deles é muito comum. Historacalmente, eu costumava ser verdadeiro para quase qualquer opção. Atualmente, mas hoje os computadores são mais rápidos e 1 raramente é relevante. Se o efeito da alteração pode ser visto instantaneamente, por que alguém não gostaria disso? Portanto, a GUI (mas muitas vezes não o código) pode ser simplificada pulando a etapa Aplicar. Eu não acho que seja muito comum que um usuário realmente precise do botão Cancelar, em parte porque é meio ambíguo. O que devo esperar se fizer uma alteração, aplicar, fazer alguma outra alteração e pressionar cancelar? A primeira mudança será revertida (na maioria dos aplicativos, a resposta não é porque é mais fácil de implementar)?

Se sim, esse é o objetivo de ter o botão Aplicar, então tudo é decidido e depois pressionar OK/Cancelar de qualquer maneira? Ou precisamos considerar mais uma opção que a janela está fechada; nesse caso, a primeira alteração é mantida, mas a segunda revertida?

Se não, aplique basicamente defina um marcador que será revertido é o cancelamento é pressionado. Mas esse tipo de comportamento complexo é realmente necessário em qualquer caso de uso da vida real?

É sensato manter esse tipo de complexidade de razões históricas porque acredita -se que os usuários (acredite -se) esperam? Vi usuários sempre pressionarem se aplicarem, depois OK. Por quê? Talvez apenas porque a GUI é muito complexa. Ou porque não tem certeza se "aplicar" significa "aplicar e descartar diálogo" (o que ela faz em alguns aplicativos) e que OK pode não aplicar as alterações (eu vi aplicativos de buggy onde OK apenas fecha a janela sem se aplicar e talvez eles também). Pelo menos não acho que os usuários em geral estejam a serem previstos das lógicas exatas dessas escolhas complexas, portanto, não precisam e não precisam estar lá. As pessoas tendem a distinguir principalmente entre as ações "positivas" (sim, ok, avançar, aplicar) e "negativo" (não, cancelar, abortar, voltar) são diálogos, ter mais de um dos dois requer mais atensão do usuário. Curiosamente, a troca de uma ação positiva com outra parece não afetar muito a percepção dos usuários. Se uma caixa de diálogo com botões sim/não for alterada para OK/Cancelar, muitos usuários nem perceberão.

Isso sobre usabilidade (que é muito mais importante IMHO). A aplicação instantânea de manutenção em termos de capacidade pode ser muito confusa se for feito errado, mas também muito limpo e sustentável, então feito corretamente. Se o aplicativo for escrito com uma abordagem Aplicar-se-ALT-ANDE, geralmente existe uma função. Chamar essa função para cada pequena mudança, obviamente, não é muito eficiente. O que eu vi isso geralmente é resolvido dividindo a função em várias funções diferentes para aplicar coisas diferentes, idealmente uma função dedicada para todo tipo de alteração que pode ser feita. Isso é tornar o aplicativo muito mais receptivo, mas é horrível de manter. Então não vá lá. Uma solução elegante é usar o MVC (Model-View-Controller) e criar um modelo para cada item de configuração e vinculá-los aos campos no formulário de configuração, bem como às partes relevantes do aplicativo (e ao armazenamento de configuração- termine para que todas as alterações sejam salvas automaticamente). Se nenhum MVC estiver disponível no ambiente em questão, definitivamente vale a pena escrever um.

Answer 5

+1 para economizar alterações após o preenchimento de todo o formulário em vez de todos os campos.

Mas deve ter validações sempre que um campo perde o foco para que você possa dar feedback imediato, se houver alguma coisa errada.