Nomeando funcionalidades
Para mim já virou prática: Sempre que me vejo usando um termo para explicar outro termo eu me pergunto: oras, não deveria ser este o nome da funcionalidade?
Beck: Então você clica neste botão para criar um Acesso Rápido na Home.
Usuário: O que é Acesso Rápido?
Beck: É uma espécie de um atalho.
Então propus para o time: Vamos chamar a funcionalidade Acesso Rápido de Atalho.
Beck: Agora na administração tem a funcionalidade de Arquivos Removidos.
Usuário: Para quê serve isso?
Beck: É como se fosse uma lixeira.
Então propus para o time: Vamos chamar a funcionalidade Arquivos Removidos de Lixeira.
– Agora clica no botão Logout para sair – Eu disse para o usuário ao telefone.
Então propus para o time: Vamos chamar a funcionalidade Logout de Sair.
Depois que fizemos as mudanças nunca mais precisamos explicar o que fazia cada coisa.
Nomear os termos numa Interface de Usuário é mais importante do que indica o escasso debate sobre o tema. Esta é uma dica simples mas que realmente pode ajudar:
Rafael Cavazin
25 de março de 2013Muito legal Beck !, realmente uma das coisas mais complicadas que eu acho, não só na parte de UX, é dar nomes as coisas. Principalmente dentro do próprio software. Nomes de módulos, nomes de métodos, nomes de procedimentos. O método por exemplo deveria ser um comando quase que atômico. Tipo : getDate() …. se você colocar alguma condição mais complexa dentro desse método já tiraria a “beleza” intrínseca do próprio nome do método (simplesmente pegar a data ) …. não seria o mesmo com UX como vc acabou de descrever ? 🙂
Beck Novaes
25 de março de 2013Concordo com você Rafael.
De fato, um dos Refactorings mais conhecidos existe justamente por isso: o rename. Uma dica interessante neste caso é usar o rename para eliminar comentários desnecessários. Ou seja, se perceber que o comentário explicar o método com outros nomes, talvez este deva ser o nome do método e o comentário é desnecessário. O código se torna a própria documentação neste caso.
[]’s
Beck