Criar aplicações corporativas para o mundo mobile (smartphones e tablets) é uma realidade.
Podemos discutir a velocidade da tendência, mas não a sua necessidade.
Como na era da interface gráfica, uns adotaram antes, outros depois, mas não houve como escapar (embora alguns tenham tentado resistir por muito tempo).
Antes, havia uma plataforma (Wintel – Windows + Intel) que praticamente dominava.
Agora, temos pelo menos três (duas e meia para alguns): Android, iOS e WindowsPhone.
Então, a questão de “reuso” e “multi plataforma” virou mantra, pois quanto mais diferença entre as plataformas nós pudermos evitar, mais eficiente, produtivo, etc… será o processo de criação de sistemas.
Ferramentas, suítes e frameworks, como o Magic xpa, focam muito nisso.
Se você observar o desenho da arquitetura RIA do Magic xpa, base para a plataforma Magic Mobile, verá que se trata apenas de trocar o client da solução para termos exatamente a mesma aplicação executando em diferentes plataformas.
Mas se engana quem pensa que isto resolve o desafio de entrar neste novo mundo.
Como mencionado neste outro post, existem outros obstáculos a vencer.
O usuário mobile não irá aceitar que a sua aplicação móvel seja parecida com a sua (mesma) aplicação desktop. Porque ele já está acostumado com outro paradigma, outra forma de interagir com o aparelho.
Por isso, “encolher” as telas desktop para caber na tela de um dispositivo móvel é uma decisão equivocada.
Mas esta não é toda a história.
O usuário virá com feedback a respeito de UI (User Interface) e UX (User eXperience). Mas existem outros aspectos, que são transparentes para ele, mas não podem passar despercebidos para os designers dos sistemas.
Um dispositivo móvel é um computador de mão que faz ligações telefônicas.
Mas é um computador mais “fraco” que o que usamos normalmente (PC ou notebook).
É um computador com menos memória, menos espaço para armazenamento e menos processador.
E isso desemboca num problema real: desempenho.
A mesma tarefa executada de forma razoavelmente satisfatória num notebook ou PC, será mais demorada num smartphone ou tablet.
Por isso, a mesma coisa precisa ser feita de forma diferente nestes novos dispositivos.
E este é um obstáculo real, que vem derrubando muitos.
Por exemplo:
Imagine que exista um processo na aplicação onde é necessário baixar 5 arquivos do servidor para o cliente.
Na versão desktop da aplicação, esta tarefa consome 15 segundos (*).
Na versão mobile, 3 minutos (*).
(*) números fictícios só para exemplificar a diferença entre as plataformas
Na versão desktop, você pode ter uma interface mais ou menos assim:
Já na versão mobile, esta tarefa poderia ser dividida em 5 etapas distintas, assim:
Observe que não houve truque para deixar mais rápido. Continua demorando os mesmos 3 minutos (de repente, até um pouco mais).
É tudo uma questão de percepção (experiência) do usuário.
No segundo design, ele viu progresso. E este experiência de progresso diminui a sensação de lentidão.
É como a ampulheta do MS-Windows. Uma tarefa de 1 min, com ampulheta na tela, o usuário olha e pensa: o sistema está trabalhando. A mesma tarefa sem a ampulheta, ele pensa: o sistema está travado!
Claro que este é um exemplo simples.
Mas a mensagem permanece:
“…
As plataformas mobile são um mundo diferente. E os designers de aplicações para elas, precisam pensar diferente. Precisam pensar “mobile”
…”
