A ideia de um “processo iterativo" não é novidade no desenvolvimento de software. Está presente em várias metodologias diferentes e provavelmente porque funciona bem principalmente quando se obtém feedback do cliente.
Um dos lugares que também acho útil é ao construir interfaces de administração para plugins do WordPress.
Para ser claro, não sou designer, então quando se trata de trabalho de front-end, sempre me refiro ao guia de estilo e aos modelos que o designer me fornece desde o início do projeto. (Só menciono isso porque acho que é uma prática que qualquer pessoa que não seja designer deve seguir, mas discordo).
Mas quando se trata de trabalhar em telas de administração ou telas de back-end para WordPress, costumo seguir uma regra estrita: certifique-se de que pareça o mais natural possível.
Como, então, o desenvolvimento iterativo e a interface das telas de administração do WordPress têm algo a ver um com o outro?
Design da tela de administração do WordPress
Este artigo em particular deixa de falar sobre coisas que são esperadas para salvar informações. Ou seja, estou assumindo tudo:
- higienização,
- validação,
- cheques nonce,
- verificações de permissão,
E semelhantes são compreendidos e tratados.
Para este post, vou mantê-lo simples. Digamos que queremos ter:
- alguns campos de texto,
- um botão salvar,
- um botão de reset,
- e talvez algo extra no final.
Como isso pode acontecer por meio de um processo iterativo ao projetá-lo?
1 Esboçando
Digamos que você esteja trabalhando em algo e planejando como será a tela administrativa. Dado o que tivemos acima, talvez um esboço inicial possa ser assim:
Fácil o suficiente, certo? Ele representa o que o projeto precisa manter e exibe tudo o que precisamos para essa tela de administração específica.
2 Construindo
Uma vez montado, deve parecer o mais nativo possível. Dados os estilos que temos disponíveis no WordPress, é relativamente fácil construir isso com as APIs e marcações disponíveis:
E o que cada campo e botão fazem?
3 Refinando
É aqui que entra o refinamento da funcionalidade. Por exemplo:
- Não acho que o botão Salvar deva ser ativado até que os campos obrigatórios sejam preenchidos,
- Acho que o botão Redefinir deve limpar o que está presente,
- Deve haver um certo grau de mensagens de erro, todas representando o que precisamos fazer quando algo falha, quando algo pode não estar certo ou algo está completamente errado.
Obviamente, é muito mais fácil falar sobre isso quando não está se referindo a um projeto específico, mas talvez algumas das ideias sejam aplicáveis em qualquer coisa que você esteja fazendo.
Melhorias assíncronas?
Uma das coisas com as quais nos acostumamos com dispositivos como nossos telefones e certas partes de nossos sistemas operacionais é que, quando alternamos um botão ou fazemos uma pequena alteração, os dados são salvos.
Ou seja, nenhuma ação de confirmação (além de algo destrutivo como excluir um arquivo, é claro) é necessária. Os dados são simplesmente salvos e a opção funciona.
No entanto, ainda vemos muitos botões Salvar no WordPress, não é? Que tal salvar entradas via Ajax ou outro método assíncrono? Isso é algo que eu ainda tenho que implementar, mas eu certamente considerei isso.