O que um desenvolvedor iOS deve ter em mente?

Tulio Parreiras
Usemobile
Published in
12 min readApr 20, 2017

Parte 2

Vamos continuar a falar sobre a Guideline da Apple, introduzida no post

"O que um desenvolvedor iOS deve ter em mente? Parte 1"

pelo Desenvolvedor iOS Cláudio Madureira. Agora iremos abordar um pouco sobre UI Design das UI Bars e UI Views.

UI Bars

Navigation Bars, Search Bars, Status Bars, Tab Bars, Toolbars

Navigation Bars:

Podem ser configuradas para esconder quando for apropriado. Exemplos: Teclado visível e tela cheia. Ao configurar a Navigation Bar para esconder, permita que o usuário possa restaurar a mesma apenas com um simples gesto, como o toque na parte superior da tela.

É importante exibir o título da View presente na Navigation Bar. Procure apresentar um título condizente com as informações que são exibidas na tela e/ou com as ações que podem ser implementadas. Exemplo: Em uma tela em que você edita informações de um usuário, é possível atribuir o nome do usuário como título da Navigation Bar. Obs.: Há casos em que exibir o título pode ser redundante, como no aplicativo Notes, pois a primeira linha de texto já serve para atribuir o contexto necessário.

Evitar usar muitos controles e objetos na Navigation Bar. O ideal é exibir apenas 2 botões laterais e um título centralizado da tela. Um botão à esquerda sendo Back e um à direita que realiza uma função customizada, geralmente o botão Done. A Apple aconselha utilizar apenas o botão de retorno padrão, para facilitar a experiência do usuário.

Dica Use: Ao implementar a função de retorno, procure uma maneira de apenas dispensar a tela atual e exibir novamente a tela ocultada, ou seja, evite instanciar a mesma tela mais de uma vez, o que vai manter seu app mais rápido, economizando memória.

Se for usar múltiplos botões com texto, ter cuidado para que haja espaço suficiente para todos os botões.

Dica Use: Fazer a separação dos mesmos usando um objeto de espaçamento fixo (Flexible Space Bar Button Item).

Considere fazer o uso de um Segmented Control na Navigation Bar quando for útil. É possível fazer o uso dele para filtrar informações exibidas, o que facilita a experiência do usuário. Exemplo: Em um app de mensagens, é possível utilizar desse artifício para filtrar mensagens que ainda não foram respondidas das mensagens que já foram respondidas.

Search Bar:

Faça o uso dela em ao invés do Text Field para realizar buscas. O Text Field não possui a aparência padrão da Search Bar que as pessoas esperam. Sempre use os botões Clear e Cancel, para facilitar a experiência do usuário.
É possível utilizar dois tipos de Search Bar, mínimo e proeminente. Saiba escolher entre qual dos dois de acordo com o grau de importância da busca em seu app. Se a busca for fator primordial de seu app, use o estilo proeminente. Caso a busca não seja uma ferramenta muito utilizada em app faça o uso do estilo mínimo.

Considere colocar dicas do parâmetro a ser buscado. Pode ser feito através do Placeholder ou então de um texto acima da Search Bar, o que ficar mais agradável.

Ofereça atalhos que auxiliem a busca e faça uso da auto-sugestão a medida que o usuário digita o parâmetro a ser buscado.

Utilize barras de escopo para refinar a busca. Quando houver categorias em que os dados podem ser divididos é possível facilitar a busca do usuário fazendo uso de um Segmented Control para exibir apenas os itens da categoria que lhe interessa na busca.

Status Bar:

A Apple recomenda o uso da Status Bar que o sistema já disponibiliza. “As pessoas esperam que a status bar seja consistente em todo o sistema. Não substitua a mesma por uma barra customizada.” — Apple.

Coordene o estilo da Status Bar de acordo com o app. É possível utilizar dois tipos de estilos, Default e LightContent. O uso correto dos tipos pode deixar seu app mais agradável.

Ela por padrão é transparente, sendo visível a exibição de conteúdo por debaixo da mesma. Evite que haja interação atrás dela.

Considere esconder temporariamente a Status Bar em modo de exibição tela cheia. Ao fazer uso desse artifício, garanta um meio para que o usuário possa visualizar a barra, como o toque na parte superior da tela. Se a Status Bar ficar sempre escondida, os usuários terão de sair de seu app para visualizar horas, bateria e wifi.

Tab Bar:

Não remova ou desative uma Tab quando a função que a mesma exerce não está disponível, fazer isso pode deixar a interface do app instável. Garanta que todas as Tabs estejam disponíveis e apenas explique o porquê do conteúdo de uma Tab não estar disponível. Exemplo: Se não há músicas em um dispositivo iOS, a Tab My Music no app Music explica como baixar músicas.

Use Tabs apenas para navegar entre telas, caso você queira uma barra com botões que realizem ações, utilize uma Toolbar. Evite o uso de muitas ou poucas Tabs, a Apple aconselha um número entre 3 e 5 em um iPhone, sendo aceitável um pouco mais para iPads. Usar muitas pode deixar o app muito complexo e difícil de localizar as informações. Usar poucas pode fazer com que a interface pareça desconectada.

Use avisos para comunicar discretamente que uma nova informação está associada com a tela apresentada.

Sempre mude de contexto na View relacionada. Para manter sua interface previsível, ao selecionar uma Tab deve sempre afetar a View que está diretamente ligada a Tab Bar, não outra View em qualquer lugar da tela.

Toolbar:

Exibir apenas botões relevantes, em que seu uso é constante. Saiba quando usar uma imagem ou texto nos botões, isso pode ser de acordo com número de funções ou então com o que vai ser executado pelos botões. Use o Flexible Space Bar Button Item para separar os botões igualmente.

Evite Segmented Controls em Toolbars, as mesmas são específicas para a tela que está sendo exibida no momento, enquanto o Segmented Control permite mudanças de contexto.

Saiba a diferença entre Toolbars e Tab Bars. Ambos não devem ser exibidos juntos em uma mesma tela.

UI Views

Action Sheets, Activity Views, Alerts, Collections, Image Views, Maps, Pages, Popovers, Scroll Views, Split Views, Tables, Text Views, Web Views

Action Sheets:

Implemente um botão cancelar, para o usuário ter mais confiança em abandonar uma tarefa. Se a pessoa for realizar uma ação destrutiva, é aconselhável usar um botão vermelho e no topo da tela.

Disponibilizar muitas opções faz com que seja necessário rolar para ver todas as opções. A rolagem exige mais tempo para tomar decisões e isso deve ser evitado.

Activity Views:

O sistema já fornece uma série de atividades (Print, Twitter, Message…), procure evitar customizar atividades que já estão disponíveis, pois o usuário já está habituado com as mesmas. Ao customizar suas atividades, use imagens simples (com medidas 70x70px). Os títulos devem ser condizentes, simples e que sejam apropriadas para o contexto em questão.

Procure usar o botão Action para exibir uma Activity View, os usuários já estão acostumados a usá-lo.

Alerts:

Use apenas em situações importantes, como compras, ações destrutivas ou notificações de problemas. Pequena ocorrência de alertas faz com que os usuários levem eles mais a sério. Garanta que cada alerta forneça informações críticas e escolhas importantes.

Teste a aparência dos alertas nas diferentes orientações. Escreva títulos pequenos e descritivos. Evite alertas explicativos, tente sempre resumir o máximo possível o título e a mensagem deles.

No geral use dois botões de alerta, isso melhora a experiência do usuário. Se achar necessário mais botões considere usar um Action Sheet.

Identifique os botões destrutivos, mude seu estilo para Destructive para que fique com a informação adequada. Adicionalmente, ofereça a opção de cancelar, para que a pessoa possa escolher seguramente a opção de não realizar a ação destrutiva. Permita que o botão Home também tenha o mesmo comportamento do botão cancelar, dispensando o alerta sem realizar nenhuma ação.

Dica Use: Recomendamos criar uma classe para alertas com funções públicas que você pode chamar facilmente dentro de seu código, variando o título, subtítulo, a quantidade de botões e título dos botões. Assim seu código fica mais limpo, organizado e adaptável nas View Controllers.

Collections:

Evite criar novos designs radicais quando um layout padrão é suficiente, a Collection View deve facilitar a experiência do usuário, não ser o centro das atenções. Faça ser fácil selecionar um item, caso contrário as pessoas irão perder o interesse antes de alcançar o conteúdo que desejam.

Ela é ideal para exibir imagens, quando nessa exibição a pessoa pode interagir com a imagem. Caso queira exibir textos procure utilizar uma tabela ao contrário da Collection View, fica mais simples e eficiente.

Image Views:

Se possível garanta que todas as imagens exibidas em uma Image View possuam um tamanho consistente, se as imagens tiverem tamanhos diferentes, a Image View ajustam as mesmas separadamente. Usar tamanhos consistentes é mais eficiente do que usar tamanhos variados. É ainda mais eficiente usar imagens que já são pré-escaladas e não necessitam de ajustes.

Maps:

Pode ser configurado para exibir um mapa padrão, imagem de satélite ou ambos. Eles podem exibir notas, caso seu app necessite. Permita a interação com o mapa, as pessoas estão acostumadas a interagir com os mapas através de gestos, então vão esperar que seja possível em seu app também.

Use cores de pinos esperadas, as pessoas estão acostumadas com as cores padrão de pinos nos apps de mapas. Evite redefinir o significado dessas cores em seu app. Use vermelho para destino, verde para posição de início e roxo para uma localização especificada pelo usuário.

Pages:

Possui dois estilos para gerenciar a transição entre páginas durante a navegação: Scrolling ou Page-curl. Uma transição Scrolling, não possui aparência específica, as páginas rolam fluidamente de uma para a próxima.

Uma transição Page-curl, faz com que as pessoas passem de uma página para outra de forma ondulada, lembrando a troca de páginas em um livro físico.

Implemente um meio de navegar não linearmente, para caso o leitor queira ir para uma página ou capítulo em específico a qualquer momento.

Popovers:

Mais utilizados em telas grandes (iPads) e podem conter qualquer tipo de elementos, Navigation Bars, Toolbars, Tab Bars. Quando exibidos, as interações com as outras telas devem ser desativadas enquanto o Popover não for dispensado.

Use o botão de fechar apenas quando necessário, como em situações em que for sair sem salvar por exemplo. No geral um popover deve fechar automaticamente quando sua presença não é mais necessária. Na maioria dos casos, um Popover deve fechar quando alguém clica fora dos limites do mesmo ou seleciona um item no Popover. Se múltiplas seleções podem ser realizadas, o Popover deve permanecer enquanto alguém explicitamente dispensar o mesmo ou clicar fora de seus limites.

Faça o uso apropriado da posição do Popover, quando selecionado ele não deve esconder informações essenciais da tela principal e não deve também esconder o botão usado para exibir o Popover. Exiba apenas um por vez, exibir vários desorganiza a interface e causa confusão. Se você precisar mostrar um novo, feche o que está aberto primeiro. Nunca exiba telas acima do Popover, exceto alertas.

Scroll Views:

Configure corretamente o zoom de acordo com sua necessidade. Quando for exibir uma imagem permita que com dois toques seja possível dar zoom ou retirar o zoom na imagem. Estabeleça limites de zoom, para que não aconteça, por exemplo, o zoom de um texto chegue a mostrar uma letra ocupando toda tela.

Não coloque um Scroll View dentro de outra Scroll View, ao fazer isso você cria uma interface imprevisível e difícil de controlar. No geral, exiba apenas uma Scroll View por vez, se for exibir duas, faça em orientações diferentes, horizontal e vertical. Ao fazer isso dificilmente um gesto de rolagem irá afetas as duas Scroll Views.

Split View:

Escolha uma exibição que pareça harmônica, onde as telas não fiquem desbalanceadas, geralmente a primeira tela ocupa um terço enquanto a segunda ocupa o restante. Mantenha a seleção da tela primária sublinhada, para que sempre seja possível saber o que está sendo acessado na tela secundária. Lembre-se de restringir a navegação a apenas uma das telas, isso facilita o discernimento da relação entre as duas.

Caso a tela primária seja dispensada para exibir a secundária, forneça meios para que seja possível retornar a tela primária.

Tables:

É possível implementar dois tipos de tabelas: Plain e Grouped. O tipo Plain pode exibir um índice à direita da célula e um cabeçalho à esquerda, com uma imagem. O tipo Grouped exibe as células em grupos, que podem ser precedidos por um cabeçalho e seguidos por um rodapé.

Comece exibindo conteúdo rapidamente, ao iniciar a Table View já disponibilize os textos, que carregam rápido, mesmo que todos os recursos ainda não tenham sido carregados. Caso os dados exijam tempo para serem exibidos, mostre uma barra de progresso para que as pessoas saibam que o app ainda está rodando e não travou.

Mantenha o conteúdo de sua tabela sempre atualizado, para sempre refletir em novos dados. Em alguns apps é exibido um indicador quando uma nova informação é adicionada, sendo possível acionar esse indicador que pula até a informação nova. Uma boa ideia também é disponibilizar uma ferramenta para atualizar a tabela manualmente.

Procure usar os estilos padrão de células para definir como o conteúdo é exibido:

  • Default: Uma imagem, seguida de uma texto. Uma boa opção para exibir itens que não requerem informações complementares.
  • Subtitle: Um texto alinhado na esquerda em uma linha e outro texto como mesmo alinhamento na linha seguinte. Esse estilo funciona bem em tabelas em que as linhas tem visual similar. O Subtitle ajuda distinguir uma linha de outra.
  • Value 1: Um título alinhado a esquerda com um subtítulo alinhado a direita com uma fonte mais clara e na mesma linha.
  • Value 2: Um título alinhado a direita, seguido de um subtítulo em uma fonte mais clara alinhado a esquerda na mesma linha.
    Mantenha o texto sucinto, palavras grandes e frases são difíceis de ler e interpretar. Providencie um feedback quando for feita uma seleção, as pessoas esperam que algo aconteça quando uma célula for selecionada.
    Implemente uma célula customizada para tabelas não padronizadas, células padrão são ótimas para usar uma variedade de cenários comuns, porém alguns conteúdos de seu app podem requisitar uma aparência customizada para a tabela. Nesse caso procure criar uma classe para a célula customizada e via código apenas vá atribuindo os valores e iniciando as células.

Text Views:

Por padrão, o conteúdo de um Text View é alinhado à esquerda e usa a fonte do sistema em preto. Mostre o teclado apropriado, para agilizar a entrada de dados, o teclado exibido durante a edição de texto deve ser apropriado para o tipo de conteúdo exibido no Text Field.

Web Views:

Evite usá-la para construir um navegador, o Safari é o navegador primário que as pessoas usam para navegar na internet em iOS, tentar replicar suas funções é desnecessário. Habilite o avanço e retorno na navegação quando for apropriado, se as pessoas usam sua Web View para visitar muitas páginas, habilite os botões Forward e Back.

Vamos ficar por aqui.
Na Guideline da Apple encontra-se mais informações. Esperamos que tenham gostado do conteúdo apresentado e se tiver algo para acrescentar deixe seu comentário.

--

--