Este documento discute a importância da usabilidade em ferramentas de desenvolvimento de software. Ele apresenta o palestrante André Valenti e sua experiência com ferramentas de baixa usabilidade. O documento explica que aspectos como o site oficial, configuração e documentação de uma ferramenta devem ser claros e intuitivos para proporcionar uma boa experiência ao usuário. Finalmente, exemplos de ferramentas com boa usabilidade são apresentados para ilustrar os princípios discutidos.
6. Por que esta palestra?
● Bibliotecas, frameworks, automação de
build...
● Você já passou por algum destes problemas
ao tentar usar uma ferramenta de
desenvolvimento nova?
○ Erros bizarros
○ Documentação ilógica
○ Conceitos obscuros
7. Por que esta palestra?
● Anos e anos de frustração com falta de
usabilidade em ferramentas
● Sonho de mudar esse cenário
11. iPhone & Galaxy
● Satisfação
○ Uso o produto porque fico feliz com o resultado
● Produtividade
○ Resolvo rápido o que eu preciso resolver
● Confiabilidade
○ Boto fé que o produto continuará funcionando bem
● Fidelidade
○ Voltarei a ter outro produto desses ou produtos
similares da mesma marca
12. iPhone & Galaxy
● Não é assim com todo mundo, claro!
● Mas é assim com muita gente
15. Siemens CF62
● Frustração
○ Só uso porque sou obrigado
● Improdutividade
○ Demoro uma vida para fazer qualquer coisa
● Desconfiança
○ A qualquer momento, posso ficar na mão
● Aversão
○ Na primeira oportunidade, tchau!
16. Siemens CF62
● Não é assim com todo mundo, claro!
● Mas é assim com muita gente
19. Ferramenta de desenvolvimento
● Bibliotecas
● Frameworks
● Automação de build
● Utilitários em linha de comando?
● Linguagens de programação?
● Sistemas operacionais?
22. Exemplo 1
● Joãozinho está trabalhando em um projeto
Java para web, de compras online
● Ele precisa gerar emails para os clientes do
site quando alguém faz uma compra
● Como ele vai implementar isso?
23. Exemplo 1
● Precisa ficar mais ou menos assim:
<html>
<body>
<p>Olá, Maria</p>
<p>Pedido de número 1234 enviado!</p>
</body>
</html>
24. Exemplo 1
● Joãozinho disse:
○ Legal! Vou usar esse tal de Velocity aí...
● Será que foi uma boa ideia?
○ Vamos descobrir...
26. Quais foram os problemas?
● Site complicado
● Documentação prolixa
● API complexa
● Configuração difícil
27. Usabilidade ruim
● Frustração
○ Só uso porque sou obrigado
● Improdutividade
○ Demoro uma vida para fazer qualquer coisa
● Desconfiança
○ A qualquer momento, posso ficar na mão
● Aversão
○ Na primeira oportunidade, tchau!
31. Site oficial
● O que é?
○ Primeiro e principal meio de comunicação
○ Visto por 99% dos usuários
○ Cartão de visitas da ferramenta
● Qual o objetivo?
○ Fornecer todas as informações básicas do projeto
■ Quais?
32. Site oficial
● MINIMAMENTE, precisa deixar claro:
○ Que problemas a ferramenta resolve
○ Como instala
○ Como roda um exemplo básico ("Hello, World")
● Altamente desejável incluir também:
○ Por quê vale a pena usá-la
○ Quando vale a pena usá-la
○ Quando NÃO vale (melhor usar outra ou nenhuma)
33. Site oficial
● Se o site oficial não responder nenhuma
dessas perguntas...
34.
35. Site oficial
● Para refletir:
○ "Propaganda eu vejo na televisão. Fala logo o que a
ferramenta faz e deixa que eu decido se uso ou
não!" (Andrei Tognolo)
36. Configuração
● O que é?
○ Mecanismo de ajuste para que a ferramenta faça
exatamente o que se quer
● Qual o objetivo?
○ Adequar a ferramenta às necessidades do usuário
■ Ou seja: configs devem fazer sentido para ele
■ (encapsulamento? serviços?)
37. ● Deve ser:
○ Óbvia de encontrar
○ Fácil de entender
○ Fácil de modificar
Configuração
39. Configuração
● Tipos de configuração:
○ Mínima
■ O estritamente necessário para a ferramenta
funcionar
○ Padrão
■ Aquela que vem de fábrica com a ferramenta, ou
que pode ser gerada com um comando óbvio
40. Configuração
● Mínima
○ A exigida para um "Hello, World"
○ Deve ser óbvia de achar ("Getting Started")
○ Idealmente, é vazia (faz o básico sem configuração)
● Padrão
○ A que já vem embutida no pacote da ferramenta
■ Ou gerada por comando que venha embutido
(rails new app, grails create-app app)
○ Idealmente, é a mínima + recursos úteis (logging,
cores, atalhos de teclado etc.)
■ "Usável, por padrão"
41. Configuração
● Padrão ⊇ Mínima (contém)
○ É só baixar e já pode brincar
○ :)
● Padrão ⊉ Mínima (não contém)
○ Só pode brincar depois de fazer a lição
○ :(
42. Configuração
● Padrão ⊇ Mínima (contém)
○ Evita decoreba
○ Evita trabalho repetitivo do desenvolvedor
○ (alguma relação com encapsulamento?)
● Padrão ⊉ Mínima (não contém)
○ Obriga o desenvolvedor a escrever sempre a
mesma coisa quando for usar a ferramenta
○ É o tal do boilerplate
○ Exemplos:
45. ● Por que é bom a padrão oferecer recursos
úteis já configurados (logging, cores, atalhos
de teclado etc.)?
○ Ninguém sabe da existência de todas as
funcionalidades ao começar a usar algo
○ Muitas funcionalidades, porém, são úteis para todos
○ Não espere que alguém procure-as. Exponha-as!
○ Entregue a ferramenta "Usável, por padrão"
Configuração
46. Configuração
● Para refletir:
○ "Se você não consegue decorar a configuração
mínima, está complicada demais." (André Valenti)
○ "A configuração padrão é a que será usada por 90%
dos usuários." (André Valenti)
■ Duvida?
50. Configuração
● Olhe o seu ~/.bashrc:
○ alias ls='ls --color=auto'
○ alias grep='grep --color=auto'
51.
52. Configuração
● Você sabia disso?
● Mais importante:
○ Você PRECISAVA saber disso?
● Mais importante ainda:
○ Você saberia da existência dessa funcionalidade se
ela não viesse ativa por padrão?
○ Alguém já pensou nisso e entregou-nos o Bash
"Usável, por padrão"
55. Configuração
● E como é que faz isso?
○ git config --global color.ui auto
● Como eu descobri isso?
○ Eu usava Windows + Git Bash (MSYS modificado)
■ Git Bash já vinha colorido de fábrica
■ Ao mudar pro Linux, não vi cores no git
■ Googlei "git colors" e descobri o comando acima
○ Pergunta pra mim se eu teria imaginado sozinho
que o git tinha o recurso de cores
56. Documentação
● O que é
○ Detalhamento da ferramenta e de suas partes
● Quais os objetivos?
○ Ensinar a ir além do básico
○ Indicar soluções para problemas mais específicos
○ Explicar detalhes da API
57. Documentação
● Minimamente, deve ser:
○ Óbvia de encontrar
○ Fácil de pesquisar
● Idealmente, deve:
○ Possuir seções autocontidas
58. Documentação
● Para refletir:
○ "A melhor documentação é a ausência de
[necessidade de] documentação." (André Valenti)
■ Duvida?
60. Committer: André Willik Valenti
<fi@deskdofi.(none)>
Your name and email address were configured
automatically based on your username and
hostname. Please check that they are accurate.
You can suppress this message by setting them
explicitly:
git config --global user.name "Your Name"
git config --global user.email you@example.com
After doing this, you may fix the identity
used for this commit with:
git commit --amend --reset-author
63. Documentação / Configuração
(Procura no Google... Procura no
Google...)
(Ah, tá! Não existe ainda o meu
usuário no banco.)
(Ah tá! Já vem um usuário chamado
postgres. Tenho que logar como ele.)
64. Documentação / Configuração
fi@deskdofi:~$ psql -U postgres
psql: FATAL: Peer authentication
failed for user "postgres"
(Hein?)
(Procura no Google... Procura no
Google...)
65. Documentação / Configuração
(Ah tá! Preciso pôr a senha, que é
postgres também!)
fi@deskdofi:~$ psql -U postgres -W
Password for user postgres: ********
(Agora vai!!)
67. Documentação / Configuração
● Penamos um pouquinho, mas conseguimos
entrar no console do Postgres!
● Só que...
○ ...não
○ Esse desfecho não é o verdadeiro!
○ O verdadeiro foi assim:
82. Flyway
● http://flywaydb.org/
● Framework de migração de banco de dados
para Java
● Tem seções explicando:
○ O que é migração de banco de dados
○ Como a ferramenta funciona
○ Como começar a usar
90. Ideologia
● Software
○ Feito por seres humanos para seres humanos
● Comunicação é falha
○ Lide com isso
○ Esclareça, repita, frise
● Erro é inevitável
○ Verifique suas premissas (Pragmatic Programmer)
○ Avise o que deu errado
○ Sugira maneiras de corrigir
91. Ideologia
● Pessoas têm diferentes níveis de
conhecimento
○ Presuma o mínimo de conhecimento prévio
○ Explique brevemente os conceitos básicos
■ Ex: Flyway
○ Ou referencie páginas que os expliquem
94. Ideologia
● Dê exemplos!
○ De preferência, do mundo real
○ Exemplo: Jasmine
■ Especifica a si mesmo usando a si mesmo
95. Ideologia
● Evite exemplos bobos e batidos:
○ OO: classe Ponto
■ { private x; private y; getX, getY, setX, setY }
○ TDD: soma
■ { assert soma(a, b) == a + b }
○ BDD: pilha
■ { when i push('x') then pop().should_equal 'x' }
96. Ideologia
● Prefira exemplos concretos e úteis:
○ OO: nós de uma árvore (p. ex., sintática)
■ { public abstract String gerarCodigo(); }
○ TDD: teste um algoritmo complicado
■ { arvore.inserir(nóEsquisito);
assert arvore.indiceDeBalanceamento == 7 }
○ BDD: teste uma regra de negócio
■ { when i buy(product) from seller then
seller.points.should_have increased_by 100
and buyer.notifications.should_include
confirmationEmail }
97. Ideologia
● DEAE:
○ Didática: saiba explicar, saiba ensinar
○ Empatia: coloque-se no lugar do usuário
○ Agilidade: entregue uma funcionalidade por vez
○ Encapsulamento: somente informação relevante
102. Conclusão
● A resposta longa é DEAE:
○ Didática: saiba explicar, saiba ensinar
○ Empatia: coloque-se no lugar do usuário
○ Agilidade: entregue uma funcionalidade por vez
○ Encapsulamento: somente informação relevante
103. Conclusão
● Vários desafios envolvidos:
○ Alcançar simplicidade
■ Dá trabalho!
○ Escrever documentação objetiva e completa
■ Dá trabalho!
○ Conciliar boa curva de aprendizado com evolução
de funcionalidades
■ Dá trabalho!
104. Conclusão
● Grande fonte de inspiração:
○ Inventing on Principle (Bret Victor)
■ http://vimeo.com/36579366
○ "Creators need an immediate connection to what
they are creating"