Com que frequência você precisa pesquisar os botões da interface do usuário antes que eles sejam percebidos como atrasados?

Embora seja possível, e algumas vezes desejável, usar interrupções de troca de pinos para ler o estado dos botões, é mais simples pesquisar o estado dos botões loop(). Esta é uma técnica comumente usada.

Se você loop()executar com rapidez suficiente, os pressionamentos de botão sempre serão capturados e o usuário não poderá perceber nenhum atraso ou atraso.

É possível que o seu loop demore tanto a causar um atraso ou atraso.

A questão é: quanto tempo levaria, em geral, até um usuário ver isso?

A resposta curta é que você tem 100 milissegundos para responder ao usuário, se desejar que ele sinta que a ação ocorreu instantaneamente.

De acordo com Jacob Nielsen em seu livro Usb Engineering , de 1993, que é considerado uma referência importante em Usabilidade de Sistemas e Experiência do Usuário:

• 0,1 segundo é o limite para que o usuário sinta que o sistema está reagindo instantaneamente, o que significa que nenhum feedback especial é necessário, exceto para exibir o resultado.

Ele também menciona que esse conselho básico sobre o tempo de resposta tem sido o mesmo há muitas décadas [Miller 1968; Card et al. 1991].

Fiz essa citação neste artigo: Tempos de resposta: os três limites importantes , também escritos por Jacob Nielsen.

Observe que, nesse período, você deve incluir todo o tempo necessário para ler o botão pressionar e dar feedback ao usuário.

Outros limites de tempo de resposta que são importantes para a experiência do usuário, da mesma fonte, mas que não foram mencionados diretamente pelo OP, são:

• 1,0 segundo é sobre o limite para o fluxo de pensamento do usuário permanecer ininterrupto, mesmo que o usuário note o atraso. Normalmente, nenhum feedback especial é necessário durante atrasos superiores a 0,1, mas inferiores a 1,0 segundo, mas o usuário perde a sensação de operar diretamente nos dados.

• 10 segundos é o limite para manter a atenção do usuário focada no diálogo. Para atrasos mais longos, os usuários desejam executar outras tarefas enquanto aguardam a conclusão do computador, portanto, eles devem receber feedback indicando quando o computador espera que seja feito. O feedback durante o atraso é especialmente importante se o tempo de resposta provavelmente for altamente variável, pois os usuários não saberão o que esperar.

É sabido que as pessoas são incapazes de perceber mudanças quando elas acontecem abaixo dos 10ms após a ação. Essa capacidade de resposta resultará em uma experiência recentemente descrita principalmente como "rápida". É perceptível, mas para os usuários é difícil colocar um nome nele.

Então, se você quer perfeição, demora cerca de 15ms. Se você quiser realmente bom, tome 100 ms de atraso. 100ms é 50ms em média e certamente passará para as pessoas.

A aplicação e o tempo de resposta esperado também são vitais. Uma porta ou elevador deslizante recebe uma tolerância muito grande (como o objeto físico sempre leva muito mais tempo), enquanto as interfaces da máquina de venda automática de ingressos não têm tempo algum.

O limite superior para a pesquisa seria de cerca de 1500ms. Por lá, as pessoas sempre notam que é lento.

Esses dados são uma experiência puramente pessoal como jogador e programador. YMMV e lembre-se de que apenas tentar você mesmo é a melhor maneira de descobrir como é. A única resposta "científica" são os <10 milissegundos, além disso, é sobre a capacidade de perceber o atraso (que varia por pessoa e momento) e a tolerância do usuário.

Como uma observação lateral, você pode tentar flutuar os atrasos para economizar tempo de bateria ou CPU quando a interface não está sendo usada. A ação do usuário, mais rápida a pesquisa. Quando o aplicativo estiver funcionando, faça uma pesquisa bem devagar. Melhor pesquisar quando importa!