Quando se trata do t\u00f3pico \u2018splash screens\u2019, a controv\u00e9rsia \u00e9 real. Devemos defender as diretrizes apropriadas<\/i><\/u> ou cedemos \u00e0 tenta\u00e7\u00e3o do marketing<\/i><\/u>? Ser\u00e1 que os utilizadores v\u00e3o “sair pela porta fora” quando decidimos mostrar um \u2018splash screen\u2019 e atrasar artificialmente a sua experi\u00eancia? Ou a exposi\u00e7\u00e3o \u00e0 marca que da\u00ed adv\u00e9m \u00e9 apreciada pelos mesmos, fazendo com que voltem para mais? Em seguida, apresentamos uma lista de problemas que podemos identificar com o uso de \u2018splash screens\u2019 em aplica\u00e7\u00f5es m\u00f3veis, classificados por quest\u00f5es t\u00e9cnicas, de usabilidade e de marketing.<\/p>\nProblemas Derivados de Quest\u00f5es T\u00e9cnicas<\/h3>\n
Como qualquer outra funcionalidade numa aplica\u00e7\u00e3o m\u00f3vel, o \u2018splash screen\u2019 apresenta alguns desafios t\u00e9cnicos, desafios esses que precisam de ser planeados cuidadosamente pela equipa de desenvolvimento. De uma perspectiva puramente t\u00e9cnica, existem alguns problemas com a abordagem tradicional do desenvolvimento de \u2018splash screens\u2019.<\/p>\n
Hoje em dia, os telem\u00f3veis t\u00eam capacidade de processamento suficiente para rivalizar com alguns computadores desktop<\/i> e, como o mesmo, conseguem executar m\u00faltiplas tarefas em simult\u00e2neo<\/i><\/b>. O que significa que a fase de carregamento de recursos pode e deve ser altamente otimizada, dividindo o trabalho entre v\u00e1rias tarefas em paralelo<\/i><\/b>. Al\u00e9m disto, assim que os recursos s\u00e3o carregados, permanecem na mem\u00f3ria durante algum tempo, o que significa que o processo de carregamento em si (e o \u2018splash screen\u2019 exibido) \u00e9 feito apenas uma vez, tornando o \u2018splash screen\u2019 (para ser mais preciso, o Espa\u00e7o reservado da interface do utilizador (placeholder) ou as Imagens de lan\u00e7amento) in\u00fatil .<\/p>\n
Seguindo este fio de pensamento, podemos concluir que este tipo de ecr\u00e3s n\u00e3o s\u00e3o necess\u00e1rios para a maioria das aplica\u00e7\u00f5es<\/i><\/b>. Vamos rever: um \u2018splash screen\u2019 \u00e9 um placeholder para carregar recursos pesados \u200b\u200bantes do in\u00edcio da aplica\u00e7\u00e3o e esse processo pode demorar muito tempo quando hardware antigo \u00e9 usado. Na verdade, a maioria das aplica\u00e7\u00f5es<\/i><\/b> (especialmente aplica\u00e7\u00f5es utilit\u00e1rio) nem sequer requerem uma conex\u00e3o \u00e0 Internet na sua fase de inicializa\u00e7\u00e3o e muito menos carregando recursos pesados<\/i><\/b>. Exceptuando casos espec\u00edficos, como jogos ou aplica\u00e7\u00f5es de mapas, a frase anterior \u00e9 v\u00e1lida. 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\u00e7\u00f5es o mais r\u00e1pido poss\u00edvel e qualquer tipo de \u2018splash screen\u2019 retiram essa capacidade \u00e0s suas aplica\u00e7\u00f5es. Como? \u00c9 uma quest\u00e3o de perspectiva. Imaginemos que uma aplica\u00e7\u00e3o Android ao iniciar, exibe o seu \u2018splash screen\u2019 e depois revela o seu primeiro ecr\u00e3. Tecnicamente, o que acontece \u00e9 que o \u2018splash screen\u2019, que \u00e9 provavelmente uma inst\u00e2ncia de uma Activity, carrega rapidamente (aproximadamente 400 milissegundos), aproveitando as otimiza\u00e7\u00f5es do n\u00edvel do sistema operativo para o carregamento r\u00e1pido de aplica\u00e7\u00f5es. Para o sistema operativo, a aplica\u00e7\u00e3o carregou rapidamente, mas para o utilizador a aplica\u00e7\u00e3o \u00e9 carregada apenas ap\u00f3s o \u2018splash screen\u2019 ser removido, o equivalente ao tempo de carregamento do \u2018splash screen\u2019 + o tempo de apresenta\u00e7\u00e3o do \u2018splash screen\u2019 + o tempo de carregamento do primeiro ecr\u00e3 (o que \u00e9 tamb\u00e9m provavelmente uma inst\u00e2ncia de Activity) por parte do sistema operativo. O tempo de apresenta\u00e7\u00e3o do \u2018splash screen\u2019 (que geralmente \u00e9 artificialmente atrasado) que \u00e9 implementado para garantir que a marca seja notada, piora \u00e0 medida que os dispositivos se tornam mais poderosos, porque o atraso artificial ter\u00e1 que se tornar mais longo, uma vez que as aplica\u00e7\u00f5es naturalmente carregam mais rapidamente!<\/p>\n
Continuando com o exemplo da framework Android, qualquer \u2018splash screen\u2019 cria falsamente a no\u00e7\u00e3o de que uma aplica\u00e7\u00e3o Android possui um \u00fanico ponto de entrada<\/i><\/b>. As aplica\u00e7\u00f5es de Android podem ter v\u00e1rios pontos de entrada atrav\u00e9s do uso de Intent-Filters adequados no seu ficheiro Manifest (enquanto que para aplica\u00e7\u00f5es iOS \u00e9 obrigat\u00f3rio ter um \u00fanico ponto de entrada), mas o uso de \u2018splash screens\u2019 cria a ilus\u00e3o de que a aplica\u00e7\u00e3o pode iniciar apenas via esse contexto espec\u00edfico. Isto, por sua vez, fornece uma condi\u00e7\u00e3o favor\u00e1vel para a exibi\u00e7\u00e3o de branding num \u2018splash screen\u2019.<\/p>\n
Um problema menor, mas ainda muito relevante, refere-se ao aumento de tamanho dos ficheiros apk ou ipa da aplica\u00e7\u00e3o com recursos do \u2018splash screen\u2019 que s\u00e3o apresentados apenas uma vez. Anteriormente, chegamos \u00e0 conclus\u00e3o de que os \u2018splash screens\u2019 deveriam ser vistos apenas uma vez, tendo em conta a capacidade da maioria dos dispositivos m\u00f3veis, a n\u00edvel do seu desempenho. Independentemente de o \u2018splash screen\u2019 ser do tipo imagem \/ logotipo ou do tipo v\u00eddeo, os programadores ir\u00e3o precisar adicionar recursos (como bitmaps, layouts, etc.) para criar o \u2018splash screen\u2019. Agora, pensemos na mir\u00edade de dispositivos em que a aplica\u00e7\u00e3o ser\u00e1 executada. Cada framework suporta um conjunto diferente (e \u00e0s vezes muito grande) de dispositivos com diferentes tamanhos do ecr\u00e3, resolu\u00e7\u00e3o e densidades. De modo a tornar o \u2018splash screen\u2019 apelativo em todos estes dispositivos (uma vez que geralmente o seu prop\u00f3sito centra-se no branding, precisa ter uma boa apresenta\u00e7\u00e3o), varia\u00e7\u00f5es diferentes do mesmo recurso v\u00e3o ser necess\u00e1rias! Assim sendo, \u2018splash screens\u2019 que s\u00f3 s\u00e3o exibidos uma vez, podem aumentar drasticamente o tamanho do execut\u00e1vel da aplica\u00e7\u00e3o resultante!<\/p>\n
User Experience (UX) \u00e9 uma parte essencial de qualquer desenho de aplica\u00e7\u00f5es, pois aumenta drasticamente a taxa de sucesso de uma aplica\u00e7\u00e3o. No seu n\u00facleo, as aplica\u00e7\u00f5es m\u00f3veis destinam-se a permitir que os seus utilizadores alcancem um prop\u00f3sito rapidamente. \u2018Splash screens\u2019 (especialmente os que s\u00e3o atrasados artificialmente) impedem-no<\/i><\/b>, bloqueando a intera\u00e7\u00e3o do utilizador normalmente em favor da exposi\u00e7\u00e3o da marca ou algum prop\u00f3sito equivalente.<\/p>\n
Aplica\u00e7\u00f5es de qualidade superior s\u00e3o percepcionadas como r\u00e1pidas e f\u00e1ceis de usar, o que \u00e9 uma mensagem clara para todos os programadores e designers. Os programadores devem optimizar o seu c\u00f3digo o mais poss\u00edvel para que seja capaz de executar o mais r\u00e1pido poss\u00edvel (especialmente aproveitando o trabalho realizado pelos engenheiros do Android e iOS que trabalham arduamente para fazer os sistemas o mais r\u00e1pidos poss\u00edvel), tomando especial cuidado com a renderiza\u00e7\u00e3o da UI, transi\u00e7\u00f5es de contexto e efici\u00eancia no uso da bateria. Os designers devem criar designs visualmente apelativos, mas tamb\u00e9m ser especialmente cuidadosos e conscientes com a sua facilidade de uso (um exerc\u00edcio simples \u00e9 contar o n\u00famero de “etapas” ou intera\u00e7\u00f5es que um utilizador precisa executar para atingir algum prop\u00f3sito).<\/p>\n
Isso traz-nos de volta ao prop\u00f3sito original dos \u2018splash screens\u2019, que deveria servir como espa\u00e7o reservado da aplica\u00e7\u00e3o quando esta carrega. O que ainda \u00e9 v\u00e1lido, de um ponto de vista de usabilidade: se uma aplica\u00e7\u00e3o n\u00e3o pode ser carregada rapidamente ou precisa carregar alguns recursos pesados ao iniciar, o \u2018splash screen\u2019 fornece as deixas necess\u00e1rias para informar o utilizador de que a aplica\u00e7\u00e3o est\u00e1 a \u00a0funcionar corretamente e de qual o status \/ progresso da tarefa que est\u00e1 a ser executada<\/i><\/b>.<\/p>\nProblemas Derivados de Quest\u00f5es de Marketing<\/h2>\n
O temido diabo do branding insiste em mostrar aos utilizadores a informa\u00e7\u00e3o de marca! O branding \u00e9 bem-vindo e deve ser encorajado ao criar aplica\u00e7\u00f5es m\u00f3veis<\/i><\/b>, pois este \u00e9 o gatilho que desencadeia a cria\u00e7\u00e3o de aplica\u00e7\u00f5es visualmente \u00fanicas. No entanto, devem existir momentos e contextos adequados para a exibi\u00e7\u00e3o dessa informa\u00e7\u00e3o.<\/p>\n
Normalmente, os utilizadores alcan\u00e7am uma aplica\u00e7\u00e3o de uma das seguintes formas:<\/p>\n
Essas fontes garantem que os utilizadores reconhecem o logotipo da marca da empresa e tamb\u00e9m indicam que a melhor abordagem para investir na marca est\u00e1 no \u00edcone das aplica\u00e7\u00f5es<\/i><\/b>! \u00c9 a primeira imagem que um utilizador v\u00ea nas lojas de aplica\u00e7\u00f5es e que ficar\u00e1 no menu do dispositivo assim que a aplica\u00e7\u00e3o for instalada. Iste facto deveria tornar in\u00fatil o branding exibido no \u2018splash screen\u2019, uma vez que j\u00e1 est\u00e1 presente no \u00edcone da aplica\u00e7\u00e3o (porqu\u00ea sacrificar o tempo do utilizador, atrasando a inicializa\u00e7\u00e3o da aplica\u00e7\u00e3o quando o utilizador j\u00e1 v\u00ea o \u00edcone da marca?). Al\u00e9m disso, o branding dentro da pr\u00f3pria aplica\u00e7\u00e3o parece ser uma melhor op\u00e7\u00e3o de modo a garantir que os utilizadores realmente reconhe\u00e7am a marca ao usar a aplica\u00e7\u00e3o (por exemplo, personalizando widgets na actionbar \/ toolbar ou adicionando um ecr\u00e3 “Sobre” com essas informa\u00e7\u00f5es), pois estar\u00e1 vis\u00edvel em todos os ecr\u00e3s da aplica\u00e7\u00e3o.<\/p>\nSimple and Clean Approach<\/h2>\n
Agora estamos conscientes da origem, tipos e usos dos \u2018splash screens\u2019. 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 \u2018splash screens\u2019 (dentro do contexto m\u00f3vel), com o objetivo de criar os mesmos de forma mais limpa e simples para nossas aplica\u00e7\u00f5es.<\/p>\n
A primeira linha de orienta\u00e7\u00e3o passa for\u00e7osamente pela finalidade original de um \u2018splash screen\u2019. Se a aplica\u00e7\u00e3o tiver recursos pesados que precisam de ser carregados, devemos mostrar um \u2018splash screen\u2019<\/i><\/b>. Pelo bem de um bom design UX, todas as inst\u00e2ncias de \u2018splash screen\u2019 devem informar o utilizador das tarefas que est\u00e3o a ser executadas<\/i><\/b> em segundo plano e qual o seu progresso<\/i><\/b>. Al\u00e9m disso, quando poss\u00edvel, o utilizador dever\u00e1 ser informado do tempo restante para a(s) tarefa(s) terminar(em)<\/i><\/b> e para o carregamento ficar completo (o utilizador precisa<\/i> de saber o porqu\u00ea de estar \u00e0 espera e quanto tempo falta at\u00e9 o processo finalizar).<\/p>\n
De seguida, devemos tentar chegar a um compromisso para acomodar os objetivos de marketing e as diretrizes t\u00e9cnicas e de UX. Para o conseguir, as diretrizes de design para \u2018Splash Screens\u2019 devem ser seguidas<\/i><\/b> e, por forma a suportar a marca (branding), devemos incluir o \u2018splash screen\u2019 na estrat\u00e9gia de onboarding da aplica\u00e7\u00e3o<\/i><\/b> (vamos dedicar uma publica\u00e7\u00e3o ao Onboarding no futuro). Esta estrat\u00e9gia traduz-se vagamente no seguinte: Em “casos especiais” (ou seja, na primeira execu\u00e7\u00e3o e nas atualiza\u00e7\u00f5es das aplica\u00e7\u00f5es), a sequ\u00eancia onboarding<\/i> deve ser acionada, ou por outras palavras, uma vers\u00e3o “longa” de um \u2018splash screen\u2019 integrado na sequ\u00eancia de onboarding (por exemplo, uma anima\u00e7\u00e3o simples dando boas-vindas ao utilizador para iniciar a sequ\u00eancia). Em todas as outras inst\u00e2ncias de inicializa\u00e7\u00e3o da aplica\u00e7\u00e3o, devemos assegurarmo-nos que as diretrizes das plataformas s\u00e3o seguidas, usando os espa\u00e7os reservados \u00e0 UI (placeholder) e \/ ou imagens de lan\u00e7amento de modo a tornar o carregamento do \u2018splash screen\u2019 instant\u00e2neo, permitindo que os utilizadores realizem as suas tarefas o mais r\u00e1pido poss\u00edvel.<\/p>\n
Acomodando o investimento em objectivos de marketing, considere investir fortemente no \u00edcone da sua aplica\u00e7\u00e3o, pois \u00e9 a primeira imagem que um utilizador ver\u00e1 nas lojas de aplica\u00e7\u00f5es e ela ficar\u00e1 em exibi\u00e7\u00e3o no menu do dispositivo assim que a aplica\u00e7\u00e3o for instalada. Esta \u00e9 a melhor abordagem para investir em branding em aplica\u00e7\u00f5es m\u00f3veis<\/i><\/b>!<\/p>\n
A toler\u00e2ncia dos utilizadores geralmente \u00e9 baixa (especialmente num contexto m\u00f3vel) e, na maioria das vezes, as aplica\u00e7\u00f5es m\u00f3veis s\u00f3 t\u00eam uma hip\u00f3tese de provar seu valor antes de serem consideradas desnecess\u00e1rias, defeituosas ou in\u00fateis… Portanto as nossas aplica\u00e7\u00f5es precisam de ter um visual para impressionar. Assegure-se que \u00e9 inclu\u00eddo uma op\u00e7\u00e3o “ignorar” (se poss\u00edvel) para que os utilizadores possam ignorar a sequ\u00eancia de onboarding e o \u2018splash screen\u2019 integrado.<\/b><\/p>\n
Como toque final, considere a op\u00e7\u00e3o para incluir uma configura\u00e7\u00e3o que permita aos utilizadores desativar qualquer tipo de \u2018splash screen\u2019 <\/b>(ou a sequ\u00eancia de onboarding no seu todo), tornando a vers\u00e3o instant\u00e2nea a \u00fanica possibilidade que pode ser usada.<\/p>\n
Em suma:<\/p>\n