nome

Projetando o seu componente web

Publicado em 10 de dezembro de 2018
Autor: Mateus Ávila Isidoro

Este texto vem ajudar a dialogar com uma necessidade crescente das agências digitais e startups que tratam sobre componentes digitais. Aqui é apenas uma pequena contribuição para a ideia.

Os componentes podem ser entendidos como peças de um carro. Cada peça possui uma função que auxilia o carro a funcionar, e ela tem seus estados de ação, isto é, se ela está ativa, desligada, em modo econômico, em modo turbo, entre outros. E esta peça, se tirarmos de um carro, e adaptarmos a outro, irá funcionar da mesma forma. Claro que um alternador de um Fox não vai funcionar numa Ferrari, mas para efeitos de entendimento, imaginamos que exista apenas 1 modelo de carro no universo, e que cada componente dele pode ser trocado livremente, bastando trocar as cores e algumas peças para o encaixe correto.

A questão neste texto é auxiliar designers a pensarem de maneira global, para que ele tenha controle fino sobre todos os estados possíveis definidos na regra de negócio de um componente. Não significa que ele vá deixar de projetar um layout do início ao fim, mas que algumas partes do projeto são componentizáveis e que podem ser reaproveitadas em outros projetos.

Para auxiliar equipes de designers e desenvolvedores a terem uma comunicação saudável, vamos criar aqui um projeto bem simples de um formulário de newsletter. A newsletter tem uma utilidade auto explicável, que consiste num formulário simples que coleta o e-mail de um usuário do site para que ele receba as atualizações da sua empresa. A questão que vamos tratar aqui é que vamos desenvolver um componente que vai ser reutilizado em vários sites, para vários clientes, gerando assim maior velocidade de desenvolvimento e consistência.

Uma newsletter possui alguns estados possíveis, a seguir:
1. Estado virgem, que fica disponível em uma parte do site e o usuário não fez nenhuma interação.
2. Estado foco no input de e-mail, alguma ação que ocorre com o input.
3. Estado de validação de e-mail — queremos certificar que nossos usuários não mandem e-mails como johndoe@c ou johndoe.com.br
4. Email validado, podendo o usuário enviar o e-mail.
5. Estado de processamento após submit, por exemplo, um loading ou alguma coisa visual dizendo que o site está processando a requisição.
6. Estado de processado, que exibirá o resultado da ação, tanto positivo quanto negativo.

É bastante coisa para um bloco que tem 1 campo de email e um botão de submit!

Para facilitar a visão global deste componente, vou criar as telas conforme estes estados possíveis. Já alerto ao designer que meu senso estético é bem rudimentar, tenho certeza que vocês farão um trabalho bem superior.

Estado Virgem

Estado virgem do componente. Imagina que ele ficará assim em muitas partes do site, apenas tendo vida a partir do momento que o usuário clicar no campo de e-mail.

Neste estado, consideramos que o usuário viu a newsletter, entretanto não fez nenhuma ação nele. Nos projetos que recebo, 95% deles apenas passam esta tela. O objetivo é que a gente dê vida ao site no design.

Estado foco no input

A cor da borda vira azul, e o foco está no campo de e-mail. O placeholder do input está ativo até a digitação da primeira letra.

Este estado estamos alertando o usuário que ele está com o cursor no campo de input. O programador irá definir a cor da borda usando :focus.

Estado de validação de e-mail – input inválido

O usuário queria processar o formulário com este e-mail, que é inválido. Alteramos a cor da borda e a cor do texto, para reforçar que o campo está errado.

Definimos que o componente, para funcionar corretamente, tem a exigência que só seja processado o formulário caso o e-mail seja válido. Nem todo usuário é confiável, e mesmo sem querer, alguns usuários podem apertar tab e alguma tecla que faça o submit ser processado. Prever os estados possíveis inclui também prever erros dos usuários.

Estado de validação de e-mail – input correto

Fazemos uma validação pré-submit avisando o usuário que o e-mail está valido e pode ser enviado. Ele também pode ser usado para pré-validar se o e-mail já foi enviado para a base de dados, evitando repetição de dados.

Os feedbacks visuais para definir o certo e errado são fundamentais para que o usuário não fique frustrado. Ao prever que ele preencheu corretamente o formulário, segundo as regras de negócio do componente, dá maior certeza e segurança para ele, além de ser um excelente upgrade na conversão.

Estado de processando a requisição – ou loading

Não é legal ver a página travada por causa de uma requisição em ajax.

Os browser realizam geralmente uma tarefa por vez (não cabe aqui neste post tratar de Workers do Javascript), e ao executar uma requisição de formulário, o browser fica parado, focando em executar a tarefa que lhe foi dada. Um feedback visual de loading auxilia o usuário a esperar um pouco, pois ele sabe que o sistema demora algum tempinho para processar o formulário.

Estado de processamento finalizado, com retorno do servidor, com o dado válido.

Exibimos uma mensagem simples de sucesso, e um botão de fechar no canto, para que o usuário possa repetir a ação com outro e-mail, se desejar.

O estado processado envolve o resultado final da requisição, isto é, a resposta que o servidor entrega ao cliente. No padrão de negócio que desenvolvemos, consideramos que o usuário precisa apenas enviar um e-mail válido. Mas temos que prever também outras situações chave, tais como proteções contra ataques de CSRF e evitar que o usuário envie o mesmo e-mail duas vezes, avisando-o que o e-mail dele já está cadastrado.

Estado de processamento finalizado, com retorno do servidor, com o dado inválido.

Queremos nos certificar que sempre será enviado um e-mail único. As validações devem ser feitas pelo backend, para certificar que não há e-mail duplicados na base de dados. Repare que troquei a cor de fundo do texto, de verde para vermelho, pois esta cor funciona como um alarme, de que algo não está correto e que precisa ser corrigido.

Ao entender os estados de um componente, conseguimos rapidamente implementar ele em outros projetos. Cabe ao front-end garantir a consistência do componente, para que ele funcione em qualquer ambiente. O objetivo deste artigo é auxiliar designers a darem melhores direções para o nosso trabalho.

Mas e a agência, que desenvolve muitos projetos por vez? Sempre teremos que fazer estes componentes em todos os projetos? A resposta é sim, mas há margem para negociação. Quando afirmamos, estamos querendo que a direção de arte do projeto seja completa, pensando em todos os esquemas de cores, de funcionalidades, de utilidades do projeto. Ao tratar o projeto com este carinho e polimento, estamos oferecendo ao cliente uma solução pensada nos detalhes, e não apenas num esqueleto sem vida. No entanto, sabendo que as agências tem dinâmicas malucas, uma boa forma de agilizar os processos é passar os padrões previamente desenvolvidos em outros projetos, passando apenas para o desenvolvedor as tonalidades corretas das cores e os textos.

A guisa de conclusão

Queremos aqui tratar que componentes são peças que podem ser reaproveitadas em outros projetos. A grande sacada está em desenvolver a lógica dele completa uma única vez, apenas alterando o estilo conforme as necessidades estéticas dos clientes. Como se fosse um mantra: perca tempo agora para não perder tempo nunca mais.Queremos aqui tratar que componentes são peças que podem ser reaproveitadas em outros projetos. A grande sacada está em desenvolver a lógica dele completa uma única vez, apenas alterando o estilo conforme as necessidades estéticas dos clientes. Como se fosse um mantra: perca tempo agora para não perder tempo nunca mais.


Originalmente este post está hospedado no link https://medium.com/@mavisidoro/projetando-o-seu-componente-web-974289945af6 , entretanto neste post foram feitos alterações para melhor qualidade do texto.