Splash Screens – úteis ou não são necessários? – Parte 2

Usos & Problemas Correntes

Quando se trata do tópico ‘splash screens’, a controvérsia é real. Devemos defender as diretrizes apropriadas ou cedemos à tentação do marketing? Será que os utilizadores vão “sair pela porta fora” quando decidimos mostrar um ‘splash screen’ e atrasar artificialmente a sua experiência? Ou a exposição à marca que daí advém é apreciada pelos mesmos, fazendo com que voltem para mais? Em seguida, apresentamos uma lista de problemas que podemos identificar com o uso de ‘splash screens’ em aplicações móveis, classificados por questões técnicas, de usabilidade e de marketing.

Problemas Derivados de Questões Técnicas

Como qualquer outra funcionalidade numa aplicação móvel, o ‘splash screen’ apresenta alguns desafios técnicos, desafios esses que precisam de ser planeados cuidadosamente pela equipa de desenvolvimento. De uma perspectiva puramente técnica, existem alguns problemas com a abordagem tradicional do desenvolvimento de ‘splash screens’.

Hoje em dia, os telemóveis têm capacidade de processamento suficiente para rivalizar com alguns computadores desktop e, como o mesmo, conseguem executar múltiplas tarefas em simultâneo. O que significa que a fase de carregamento de recursos pode e deve ser altamente otimizada, dividindo o trabalho entre várias tarefas em paralelo. Além disto, assim que os recursos são carregados, permanecem na memória durante algum tempo, o que significa que o processo de carregamento em si (e o ‘splash screen’ exibido) é feito apenas uma vez, tornando o ‘splash screen’ (para ser mais preciso, o Espaço reservado da interface do utilizador (placeholder) ou as Imagens de lançamento) inútil .

Seguindo este fio de pensamento, podemos concluir que este tipo de ecrãs não são necessários para a maioria das aplicações. Vamos rever: um ‘splash screen’ é um placeholder para carregar recursos pesados ​​antes do início da aplicação e esse processo pode demorar muito tempo quando hardware antigo é usado. Na verdade, a maioria das aplicações (especialmente aplicações utilitário) nem sequer requerem uma conexão à Internet na sua fase de inicialização e muito menos carregando recursos pesados. Exceptuando casos específicos, como jogos ou aplicações de mapas, a frase anterior é válida. Adicionalmente, podemos ter a certeza de que ambos os engenheiros da Google e da Apple trabalham arduamente por forma a garantir que ambos os sistemas operativos possam carregar aplicações o mais rápido possível e qualquer tipo de ‘splash screen’ retiram essa capacidade às suas aplicações. Como? É uma questão de perspectiva. Imaginemos que uma aplicação Android ao iniciar, exibe o seu ‘splash screen’ e depois revela o seu primeiro ecrã. Tecnicamente, o que acontece é que o ‘splash screen’, que é provavelmente uma instância de uma Activity, carrega rapidamente (aproximadamente 400 milissegundos), aproveitando as otimizações do nível do sistema operativo para o carregamento rápido de aplicações. Para o sistema operativo, a aplicação carregou rapidamente, mas para o utilizador a aplicação é carregada apenas após o ‘splash screen’ ser removido, o equivalente ao tempo de carregamento do ‘splash screen’ + o tempo de apresentação do ‘splash screen’ + o tempo de carregamento do primeiro ecrã (o que é também provavelmente uma instância de Activity) por parte do sistema operativo. O tempo de apresentação do ‘splash screen’ (que geralmente é artificialmente atrasado) que é implementado para garantir que a marca seja notada, piora à medida que os dispositivos se tornam mais poderosos, porque o atraso artificial terá que se tornar mais longo, uma vez que as aplicações naturalmente carregam mais rapidamente!

Continuando com o exemplo da framework Android, qualquer ‘splash screen’ cria falsamente a noção de que uma aplicação Android possui um único ponto de entrada. As aplicações de Android podem ter vários pontos de entrada através do uso de Intent-Filters adequados no seu ficheiro Manifest (enquanto que para aplicações iOS é obrigatório ter um único ponto de entrada), mas o uso de ‘splash screens’ cria a ilusão de que a aplicação pode iniciar apenas via esse contexto específico. Isto, por sua vez, fornece uma condição favorável para a exibição de branding num ‘splash screen’.

Um problema menor, mas ainda muito relevante, refere-se ao aumento de tamanho dos ficheiros apk ou ipa da aplicação com recursos do ‘splash screen’ que são apresentados apenas uma vez. Anteriormente, chegamos à conclusão de que os ‘splash screens’ deveriam ser vistos apenas uma vez, tendo em conta a capacidade da maioria dos dispositivos móveis, a nível do seu desempenho. Independentemente de o ‘splash screen’ ser do tipo imagem / logotipo ou do tipo vídeo, os programadores irão precisar adicionar recursos (como bitmaps, layouts, etc.) para criar o ‘splash screen’. Agora, pensemos na miríade de dispositivos em que a aplicação será executada. Cada framework suporta um conjunto diferente (e às vezes muito grande) de dispositivos com diferentes tamanhos do ecrã, resolução e densidades. De modo a tornar o ‘splash screen’ apelativo em todos estes dispositivos (uma vez que geralmente o seu propósito centra-se no branding, precisa ter uma boa apresentação), variações diferentes do mesmo recurso vão ser necessárias! Assim sendo, ‘splash screens’ que só são exibidos uma vez, podem aumentar drasticamente o tamanho do executável da aplicação resultante!

Problemas Derivados de Questões de Usabilidade

User Experience (UX) é uma parte essencial de qualquer desenho de aplicações, pois aumenta drasticamente a taxa de sucesso de uma aplicação. No seu núcleo, as aplicações móveis destinam-se a permitir que os seus utilizadores alcancem um propósito rapidamente. ‘Splash screens’ (especialmente os que são atrasados artificialmente) impedem-no, bloqueando a interação do utilizador normalmente em favor da exposição da marca ou algum propósito equivalente.

Aplicações de qualidade superior são percepcionadas como rápidas e fáceis de usar, o que é uma mensagem clara para todos os programadores e designers. Os programadores devem optimizar o seu código o mais possível para que seja capaz de executar o mais rápido possível (especialmente aproveitando o trabalho realizado pelos engenheiros do Android e iOS que trabalham arduamente para fazer os sistemas o mais rápidos possível), tomando especial cuidado com a renderização da UI, transições de contexto e eficiência no uso da bateria. Os designers devem criar designs visualmente apelativos, mas também ser especialmente cuidadosos e conscientes com a sua facilidade de uso (um exercício simples é contar o número de “etapas” ou interações que um utilizador precisa executar para atingir algum propósito).

Isso traz-nos de volta ao propósito original dos ‘splash screens’, que deveria servir como espaço reservado da aplicação quando esta carrega. O que ainda é válido, de um ponto de vista de usabilidade: se uma aplicação não pode ser carregada rapidamente ou precisa carregar alguns recursos pesados ao iniciar, o ‘splash screen’ fornece as deixas necessárias para informar o utilizador de que a aplicação está a  funcionar corretamente e de qual o status / progresso da tarefa que está a ser executada.

Problemas Derivados de Questões de Marketing

O temido diabo do branding insiste em mostrar aos utilizadores a informação de marca! O branding é bem-vindo e deve ser encorajado ao criar aplicações móveis, pois este é o gatilho que desencadeia a criação de aplicações visualmente únicas. No entanto, devem existir momentos e contextos adequados para a exibição dessa informação.

Normalmente, os utilizadores alcançam uma aplicação de uma das seguintes formas:

• Boletim informativo por e-mail ou link direto de um website
  • Neste caso, os utilizadores saberão exatamente quais as aplicações que estão a descarregar e porque as irão utilizar. Se o ponto de partida for um boletim de e-mail, isso significa que um utilizador já é um cliente fiel dessa marca específica.
• Pesquisa nas lojas de apps para obter uma marca específica
  • Neste caso, os utilizadores já conhecem a marca e sabem exatamente o que estão à procura, sendo por isso capazes de reconhecer o logotipo da marca.
• Pesquisa por uma palavra-chave e reconhecimento do ícone da aplicação
  • Neste caso, os utilizadores sabem o que estão à procura e, provavelmente, vão notar a aplicação cujo logotipo eles reconhecem, o que significa que também estão cientes do logotipo da marca.

Essas fontes garantem que os utilizadores reconhecem o logotipo da marca da empresa e também indicam que a melhor abordagem para investir na marca está no ícone das aplicações! É a primeira imagem que um utilizador vê nas lojas de aplicações e que ficará no menu do dispositivo assim que a aplicação for instalada. Iste facto deveria tornar inútil o branding exibido no ‘splash screen’, uma vez que já está presente no ícone da aplicação (porquê sacrificar o tempo do utilizador, atrasando a inicialização da aplicação quando o utilizador já vê o ícone da marca?). Além disso, o branding dentro da própria aplicação parece ser uma melhor opção de modo a garantir que os utilizadores realmente reconheçam a marca ao usar a aplicação (por exemplo, personalizando widgets na actionbar / toolbar ou adicionando um ecrã “Sobre” com essas informações), pois estará visível em todos os ecrãs da aplicação.

Simple and Clean Approach

Agora estamos conscientes da origem, tipos e usos dos ‘splash screens’. Conhecemos todos os pontos de vista dos diferentes atores que giram em torno dos mesmos. Somos assim capazes de propor uma abordagem para o desenvolvimento de ‘splash screens’ (dentro do contexto móvel), com o objetivo de criar os mesmos de forma mais limpa e simples para nossas aplicações.

A primeira linha de orientação passa forçosamente pela finalidade original de um ‘splash screen’. Se a aplicação tiver recursos pesados que precisam de ser carregados, devemos mostrar um ‘splash screen’. Pelo bem de um bom design UX, todas as instâncias de ‘splash screen’ devem informar o utilizador das tarefas que estão a ser executadas em segundo plano e qual o seu progresso. Além disso, quando possível, o utilizador deverá ser informado do tempo restante para a(s) tarefa(s) terminar(em) e para o carregamento ficar completo (o utilizador precisa de saber o porquê de estar à espera e quanto tempo falta até o processo finalizar).

De seguida, devemos tentar chegar a um compromisso para acomodar os objetivos de marketing e as diretrizes técnicas e de UX. Para o conseguir, as diretrizes de design para ‘Splash Screens’ devem ser seguidas e, por forma a suportar a marca (branding), devemos incluir o ‘splash screen’ na estratégia de onboarding da aplicação (vamos dedicar uma publicação ao Onboarding no futuro). Esta estratégia traduz-se vagamente no seguinte: Em “casos especiais” (ou seja, na primeira execução e nas atualizações das aplicações), a sequência onboarding deve ser acionada, ou por outras palavras, uma versão “longa” de um ‘splash screen’ integrado na sequência de onboarding (por exemplo, uma animação simples dando boas-vindas ao utilizador para iniciar a sequência). Em todas as outras instâncias de inicialização da aplicação, devemos assegurarmo-nos que as diretrizes das plataformas são seguidas, usando os espaços reservados à UI (placeholder) e / ou imagens de lançamento de modo a tornar o carregamento do ‘splash screen’ instantâneo, permitindo que os utilizadores realizem as suas tarefas o mais rápido possível.

Acomodando o investimento em objectivos de marketing, considere investir fortemente no ícone da sua aplicação, pois é a primeira imagem que um utilizador verá nas lojas de aplicações e ela ficará em exibição no menu do dispositivo assim que a aplicação for instalada. Esta é a melhor abordagem para investir em branding em aplicações móveis!

A tolerância dos utilizadores geralmente é baixa (especialmente num contexto móvel) e, na maioria das vezes, as aplicações móveis só têm uma hipótese de provar seu valor antes de serem consideradas desnecessárias, defeituosas ou inúteis… Portanto as nossas aplicações precisam de ter um visual para impressionar. Assegure-se que é incluído uma opção “ignorar” (se possível) para que os utilizadores possam ignorar a sequência de onboarding e o ‘splash screen’ integrado.

Como toque final, considere a opção para incluir uma configuração que permita aos utilizadores desativar qualquer tipo de ‘splash screen’ (ou a sequência de onboarding no seu todo), tornando a versão instantânea a única possibilidade que pode ser usada.

Em suma:

• Regra 1 – Se houver o uso de recursos pesados ​ para serem carregados, mostre um ecrã inicial.
  • Regra 1.1 – Todas as instâncias de ecrãs splash devem informar o utilizador do progresso e, se possível, das ações em segundo plano (o usuário precisa saber do quê que é que ele está à espera e quanto tempo falta até o processo estar concluído).
• Regra 2 – A fim de suportar a marca, faça parte da estratégia de bordo:
  • Regra 2.1 – As primeiras atualizações e execução da aplicação podem desencadear a versão “longa” de um ecrã Splash.
  • Regra 2.2 – Todos as outras aplicações iniciadas devem seguir as diretrizes das plataformas: o uso de espaços reservados para lançamento de imagens da UI e lance instantaneamente o ecrã inicial para que o utilizador possa realizar a  tarefa pretendida  o mais rápido possível.
• Regra 3 – Considere investir no ícone da aplicação para melhorar a promoção desta.
• Regra 4 – Assegure-se que adicione uma chamada “ignorar” para que o utilizador possa ignorar a seqüência de bordo e a tela de abertura integrada.
• Regra 5 – Assegure-se em adicionar uma configuração para que os utilizadores possam desativar qualquer forma de ecrã inicial (ou o onboarding) tornando a versão instantânea a única possibilidade que pode ser exibida.

• About
• Latest Posts

Paulo Ribeiro

paulo.ribeiro@simdea.pt
Hardworking and passionate individual keen on learning and clearing any challenges coming his way.
Working in such a fast paced industry as Application Development, Paulo always aims to try and learn new technologies and new ways to perform his work, either through optimization or efficient process management. He is always open to embrace projects as long as they represent a brand new challenge and learning experience for him.

Latest posts by Paulo Ribeiro (see all)

• Splash Screens – úteis ou não são necessários? – Parte 2 - 28/07/2017
• Splash Screens – úteis ou não são necessários? – Parte 1 - 27/06/2017
• Davos For Geeks – A Sequela - 03/02/2017

Usos & Problemas Correntes Quando se trata do tópico ‘splash screens’, a controvérsia é real. Devemos defender as diretrizes apropriadas ou cedemos à tentação do marketing? Será que os utilizadores...