Executando verificação de segurança...
13
salinas
2 min de leitura ·

Interface Otimista - O que é?

Imagine que ao desenvolver uma aplicação de gerenciamento de tarefas, uma das funcionalidades pode ser a atualização do título de uma tarefa. Nesse caso, a probabilidade de algo dar errado é mínima, já que não há restrições complexas associadas ao título da tarefa. Portanto, podemos adotar uma abordagem otimista para essa operação.

Na abordagem otimista, não é necessário aguardar pela confirmação do back-end para refletir a mudança na interface do usuário. Assim que o front-end envia uma requisição ao back-end para atualizar o título da tarefa, o novo valor é imediatamente apresentado na tela. Se ocorrer algum erro durante a requisição, simplesmente revertamos para o título anterior exibido na tela. Caso contrário, mantemos a modificação realizada.

Essa abordagem proporciona uma experiência de usuário mais fluida, eliminando a espera desnecessária e mantendo a interface responsiva, enquanto assegura a integridade dos dados.

Veja esse exemplo que encontrei na internet de um TODO utilizando essa o conceito de interface otimista para criação de novas tarefas:

UI OTIMISTA

Repare que no momento em que ele adiciona, o item já aparece!

Agora dá uma olhada nessa versão com loading state, que seria a maneira tradicional:

LOADING STATE

Viu a diferença?

A abordagem é chamada de "otimista" porque assume que as coisas vão dar certo desde o início, sem esperar pela confirmação do servidor. Em vez disso, ela atualiza a interface imediatamente, proporcionando uma experiência mais rápida e responsiva para o usuário.

Mas claro que essa abordagem possui seu lado bom e ruim, como tudo na vida! Então cabe a você decidir quando utilizar.

Carregando publicação patrocinada...
1
FelipeLimaCoelho

Para mim essa abordagem "otimista" acaba carregando um potencial perigo para a experiência do usuário, me lembrando até dos mandamentos do Go Horse. Te dou 2 analogias para tentar te mostrar como um otimismo pode levar a péssimas situações para uma pessoa/usuário:

  • Você confia no seu código e acredita que ele sempre irá cumprir o seu propósito, pois você utiliza linguagem tipada e sempre confere o resultado seja no console, debug ou interface e, dessa forma, você acredita que não precisará realizar testes unitários, de integração etc. Nem preciso dizer que isso é um Go Horse de carteirinha e essa prática vai dar merd@ em algum momento.

  • Um princípio do UX é que se você faz uma ação, você precisa saber o resultado da sua ação. Se você recebe o resultado da sua ação e após algum momento, por qualquer motivo, esse resultado precisa vir com "pedido de desculpas" falando que o resultado não era realmente o que antes foi afirmado, isso fere totalmente o princípio mencionado, além de proporcionar uma experiência em que o usuário sempre precisará ficar alerta devido a falta de compromisso com a "verdade".

Dito isso, inicialmente o otmimismo parece realmente produtivo mas, ao meu ver, é preciso ter um certo pragmatismo ao codar.

1
salinas
Autor
Autor

Por isso, como mencionei anteriormente, a abordagem possui seus lados positivos e negativos. Mas tenha cuidado pois aplicar o conceito de interface otimista não implica que toda a aplicação deva seguir essa linha.

Sendo assim deve-se utilizar essa abordagem em situações específicas onde ela possa agregar valor à experiência do usuário.

Por exemplo, não é recomendável aplicar a abordagem otimista na funcionalidade principal da aplicação. No entanto, pode ser aplicada em situações triviais, onde não há muita lógica ou regra de negócio associada, onde a chance de falhar é baixa ou sem valor grandioso em caso de falha.

Um exemplo disso é, atualizar o nome do cachorro do usuário - uma tarefa que não está diretamente ligada ao core da aplicação. Qual a chance de algo dar errado nesse caso? Digo no sentido de o sistema apresentar um erro, já que não há uma regra de negócio cabeluda para definir o nome do cachorro do usuário.

E mesmo que ocorra um problema, como o sistema não estar online por alguma circunstância, qual seria o impacto em informar posteriormente ao usuário que a mudança não foi bem-sucedida? Afinal, essa funcionalidade não é essencial para o funcionamento do sistema.

Entendo que isso possa parecer uma violação do princípio de UX, mas em algumas situações, pode-se abrir mão desse princípio em prol da fluidez e velocidade na interação com o usuário.
É igual desenvolver uma aplicação com conceitos SOLID, você vai usar todos os conceitos? de S a D? Não, você vai usar o que for pertinente e quando for pertinente!

É essencial ressaltar que a abordagem otimista não substitui a necessidade de testes, sejam eles unitários, de integração ou E2E. A realização de testes é fundamental para garantir a funcionalidade da aplicação, independentemente da abordagem utilizada na interface - seja ela tradicional, otimista ou qualquer outra! Os testes são elementos agnósticos a abordagem utilizada na interface.

Linguagem tipada ou dinâmica, programador experiente ou não, falhas e bugs podem e vão ocorrer em qualquer momento ou feature da aplicação. Portanto, é importante reconhecer os limites e possibilidades da abordagem otimista, e utilizá-la quando cabível, como mais uma ferramenta em nossa caixa de ferramentas de desenvolvimento.

1