Meu nome é Bruno Oliveira e trabalho com Android Developer Relations no Google Brasil. Boa parte do meu trabalho envolve orientar desenvolvedores que estão criando aplicativos para Android e fico muito feliz sempre que tenho a oportunidade de melhorar um app que já existe ou dar conselhos para melhorar o projeto de um app antes do seu lançamento. Pensei em escrever esse blog post falando um pouco sobre os erros comuns que vejo nos apps que reviso, para que essas informações sejam úteis para o maior número de desenvolvedores possível.
1. Atenção ao design. Se você é como eu (engenheiro, gosta de escrever e debugar código, não sabe direito como combinar cores e tem uma grande dificuldade de desenhar qualquer coisa que não seja uma figura de palitinhos), você provavelmente tem noções muito rudimentares sobre o que pode ser considerado uma interface "bonita" e uma interface "feia". Não pense que isso é um assunto fácil: para fazer uma interface bonita, é necessário entender muito bem sobre tipografia, equilíbrio de cores, espaçamento entre componentes, hierarquia visual e até mesmo a psicologia que respalda a escolha de certas cores e formas para associação com cada significado. Em outras palavras, você precisa de um excelente design. Mas quem pode nos ajudar com isso? Dica: um designer. Se você está fazendo o app como um hobby, convide um(a) amigo(a) designer para participar; se você está fazendo um app profissionalmente, contrate ao menos 1 designer.
2. Android é Android. Ao projetar seu app, lembre-se que os apps no Android devem ter um estilo e comportamento próprio do Android. Não tente imitar outra plataforma: os apps que tentam imitar o visual ou comportamento de outros sistemas operacionais são invariavelmente apps de baixíssima qualidade no Android. Recomendo uma leitura completa do
Guia de Estilo, que explica em detalhes qual deve ser a aparência e comportamento de aplicativos no Android.
3. Esqueça os pixels. As telas no Android não são medidas em pixels. Ok, até são, mas pixels não significam nada. Não planeje que "esse botão vai ter 200 pixels por 80 pixels", porque isso fará o botão ter um tamanho físico diferente em cada dispositivo. Não somente cada dispositivo tem um número diferente de pixels, mas eles têm densidades diferentes, o que significa que não há como prever qual será o tamanho físico de um retângulo de 200x80 pixels. A medida mais estável para se utilizar é o
dp (density-independent pixel), que tem o mesmo tamanho físico em qualquer tela. Faz sentido dizer que um botão tem 200x80
dp, pois isso tem um tamanho físico definido. Claro que a relação entre esse tamanho e o tamanho da tela ainda variará de dispositivo para dispositivo, e você deve ter cuidado para que isso sempre faça sentido -- uma boa prática é ter layouts diferentes para tamanhos diferentes de tela.
4. O usuário já sabe usar o seu app... se você não complicar. O usuário usa muitos apps no seu dia-a-dia, então ele está constantemente sendo treinado nos padrões do Android. A cada vez que o usuário usa o GMail, o Youtube ou o Maps, o hábito dele com os padrões de interface e navegação do Android se solidifica mais. Portanto, se você usar os mesmos padrões, o usuário nem precisará pensar em como usar o seu app -- tudo será perfeitamente natural. Só não será natural se você resolver complicar a vida do usuário inventando um padrão de navegação novo que ele nunca viu antes, o que vai exigir que ele o aprenda, e isso frequentemente é uma barreira suficiente para fazer o usuário desistir de usar um app. Portanto, a dica é: não force o usuário a aprender um padrão novo, use os padrões que já existem.
5. Use a Action Bar. Falando em padrões importantes, recorrentes e intuitivos, há um que não pode faltar no seu app: a
Action Bar. A Action Bar é uma solução para fornecer identidade, navegação e acesso a ações frequentes de uma maneira que o usuário já está acostumado. Se o seu app é um daqueles que tem telas onde o usuário pode fazer coisas, a Action Bar é para você. Se o seu app não é desse tipo... você me deixou curioso.
6. O que colocar no título de cada tela na Action Bar? Esse tópico é muito importante. Há desenvolvedores que colocam o nome do app como título na Action Bar em todas as telas. Ok, os usuários podem até ser esquecidos, mas não precisamos chegar a tanto. É suficiente que a tela inicial do seu app mostre o título; quando o usuário está em telas secundárias, o título na Action Bar deve ser o título dessa tela secundária. Um exemplo: se o seu app mostra informações esportivas, a Action Bar da tela inicial (e só da tela inicial) tem o seu logotipo e o nome do app. Agora, numa tela secundária onde você mostra os resultados do Campeonato XYZ 2012, o título que aparece na Action Bar deve ser "Campeonato XYZ 2012", juntamente com o ícone do seu app. Não esqueça de colocar o "up affordance", que é aquela seta apontando para a esquerda na Action Bar, que permite ao usuário navegar "para cima" e voltar à categoria mais geral.
7. Se o usuário quer focar em algo, não o distraia. O usuário tem dois "modos": focado e distraído. Quando o usuário acaba de entrar no seu app, provavelmente está no modo "distraído" -- você pode (e deve) sugerir atividades para ele. Sugira conteúdo, tenha uma tela de conteúdo em destaque, ponha links para levar o usuário a descobrir novas funcionalidades do app. Agora, quando o usuário aperta um botão, ícone ou qualquer outra coisa, é porque o usuário está interessado naquilo que ele clicou. Se o seu app é um app de esportes e o usuário clicou em badminton, é porque ele está interessado em badminton. Nesse caso, faça com que a tela esteja inteiramente focada no que ele quer: badminton. Não coloque tabs ou spinners para permitir ao usuário "mudar de esporte". Ele não quer mudar de esporte. Ele quer badminton. Se ele cansar de badminton e quiser outra coisa, ele usará a tecla back do dispositivo ou o botão "up" da Action Bar (não deixe de ler cuidadosamente o capítulo sobre
navegação). Isso nos leva ao próximo tópico...
8. Não ponha botões para tudo em todas as telas. Às vezes ouço argumentos de que é bom colocar botões para tudo em todas as telas para reduzir "o número de cliques" para fazer algo. Este poderia ser um conselho útil em apps para desktop, onde o espaço é abundante. Porém, numa tela de dispositivo móvel (mesmo tablets), o espaço é muito precioso. Nesse caso o modelo "drill-down" é muito mais apropriado, onde o usuário vai selecionando o que lhe interessa e volta para cima quando quer uma visão mais geral. Apps que levam essa filosofia de "número de cliques" ao extremo fazem aquelas telas que têm mais botões que uma cabine de um avião, tornando a vida do usuário extremamente complicada.
9. Cuidado com gráficos de baixa resolução. Os telefones e tablets de hoje têm resoluções impressionantes, alguns chegando a mais de 320 DPI. Isso significa que você deve sempre fazer seus recursos gráficos de maneira que eles tenham uma boa aparência em todas as telas, inclusive as de mais alta resolução. Sempre forneça assets em LDPI, MDPI, HDPI e XHDPI. O que acontece se você não faz isso? O sistema automaticamente fará a única coisa que ele pode fazer: usar um recurso de baixa resolução e redimensionar, resultando em gráficos distorcidos e com artefatos. Se você está tentando produzir um app profissional e bem acabado, a ilusão acaba ali.
10. Não bloqueie tudo só para carregar algo. Há apps que bloqueiam a tela inteira quando vão fazer ou carregar algo. O usuário inocentemente clica num botão e de repente a tela inteira fica escura e aparece um spinner no meio da tela dizendo "Carregando." Claro que isso já é muito melhor do que apps que nem sequer dizem que estão carregando e ficam "congelados", mas mesmo assim esse comportamento pode ser muito irritante. Lembre-se que sempre que a tela fica escura e a interface fica bloqueada, o usuário se sente interrompido. Isto só deve acontecer em casos muito sérios, como por exemplo um prompt crítico, no qual o usuário está prestes a apagar todos os seus dados ou fazer alguma outra coisa irreversível e muito grave. Nos outros casos, o app deve carregar os dados em background, sem bloquear a interface.
11. Não faça o usuário tomar decisões desnecessárias. Na medida do possível, o app deve fazer a coisa certa em qualquer situação, sem que o usuário precise fazer nada. Um exemplo: se o app depende de sincronização de dados com seu servidor, é tentador colocar um botão no app que alterna entre o "modo online" e o "modo offline", para que o usuário possa usar o app com ou sem conexão. A pergunta é: o usuário realmente precisa fazer essa escolha? Não seria melhor se o app detectasse sozinho se existe ou não uma conexão, e se comportasse apropriadamente para cada caso, sem pedir para o usuário controlar isso com um botão para mudar de "modo"? Pense no GMail: o app do GMail não precisa perguntar para o usuário se ele quer usar o "GMail Online" ou "GMail Offline". Ele simplesmente faz a coisa certa: se está online, ele manda emails; se está offline, ele guarda o email numa outbox para mandar depois. E não chateia o usuário perguntando se ele quer ou não mandar o email que está na outbox.
12. Não peça para o usuário avaliar o app no Google Play após 5 segundos. Se o usuário acabou de instalar o app e o está usando há poucos instantes, provavelmente não tem uma opinião formada sobre o app ainda. Pouco adianta sugerir que ele avalie o app no Google Play. Aliás, é até perigoso: o usuário pode aceitar o seu convite e dar uma baixa avaliação porque se sentiu interrompido. Especialmente se isso acontece toda vez que o usuário roda o app.
Espero que essas dicas sejam úteis para os seus apps!
Postado por Bruno Oliveira, Android Developer Relations.
A partir do hangout da próxima quinta-feira 02/08, o Android Developer Office Hours Brasil passará a se chamar ...
