Informação em mobile: Pattern para aumentar o numero de acessos

Com o avanço da tecnologia, e a crescente utilização dos dispositivos móveis para acesso a internet, empresas intensificaram a oferta de produtos a esse nicho de mercado, onde se tem um novo canal de comunicação B2P (Business to Person).

No entanto, não se pode ater somente a um determinado publico, ou seja, aqueles que utilizam os dispositivos moveis para acessar às redes sociais, trocar mensagens, baixar aplicativos para uso com fins de entretenimento, pois existe uma grande vertente que está associada à aplicações corporativas, para auxiliar em resolução de dúvidas ou orientação, mapas, marketing de produtos, dentre outros.

Com esse publico bem diversificado, observa-se uma difusão e disseminação de conteúdos para dispositivos móveis. Jornais, bancos, provedores de e-mails, varejistas, a cada dia aumentam seu marketshare para tais dispositivos, porém, em alguns casos, sem nenhum controle de crescimento ou planejamento da forma como vai ser publicado tal conteúdo.

Passo algumas horas do dia acessando conteúdos através do celular, e o que estou vendo é que alguns canais de informação não possuem uma interface customizada a tal dispositivo. Isso é, o mesmo look and feel que é mostrado para uma monitor de 19” também é apresentado para uma tela de 4”, sem falar nas imagens que são descarregadas sem nenhum tipo de filtro para o celular. Por mais que avancemos na rede móvel,com  aumento de memória dos dispositivos móveis, facilidade de interação, ainda temos problemas de sinal de agente de externo estabilizado, onde depende da localização onde se encontra o aparelho, dificultando downloads dos conteúdos estáticos.

Até agora só identificamos dois requisitos: usabilidade e desempenho, em determinados casos, são cruciais para a satisfação de quem utiliza tal serviço. Pesquisadores de Stanford fizeram estudos relacionados ao consumo de memória navegando em sites através de browsers de celulares, onde conseguiram reduzir, em alguns casos, até 25% do consumo de memória, simplesmente alterando os scripts que eram utilizados pelas páginas, alterando o formato das imagens que eram transferidas aos navegadores, utilização de caches, dentre outros.

Nesse estudo foi focado somente o consumo de memória, restando então a usabilidade. Papel que exige um pouco mais do Arquiteto de software. Na maioria dos projetos, o tempo no cronograma é requisito primordial, ao seja, não se dispõe. Logo não se dá ao projetista o tempo necessário para pensar na melhor forma de se criar componentes ou mesmo o desenho lógico de como tal sistema irá se comportar.

Voltando a prancheta, existem padrões que pode resolver tal problema de requisições de múltiplos clientes (desktop ou móvel). Esse padrão se chama: FrontController. A motivação para utilizar esse padrão passa pelos seguintes aspectos:

– Sistema comum de processamento de serviços por solicitação;

– Centralização da lógica de visão;

– Múltiplas visões são usadas para responder a uma requisição similar de negócio. Dentre outras.

A utilização desse padrão visa a centralização ou mesmo o ponto inicial de contato de uma requisição, que pode ser via desktop, celular, tablet, etc, e redirecionando a camada de negócio ou  mesmo tomando alguma decisão. Nesse controle é gerenciado todo o processo de requisição englobando: serviços de segurança (autenticação e autorização), processar a regra de negócio, gerenciar a escolha de uma visão apropriada, manipulação de erros, e gerenciar a seleção da estratégia da criação do conteúdo.

Associado ao FrontController, podemos utilizar o InterceptingFilter como responsável dentre outros aspectos por:

– Validar se um cliente está ou não autenticado;

– Validar se um cliente tem uma sessão válida;

– Validar se uma requisição é oriunda de uma rede válida (essa constraint é validade pelo google music, onde só se pode acessar seu conteúdo em determinados país, no Brasil ainda não é possível);

– Validar se um determinado tipo de navegador é valido ou não;

Observando a conjunção desses padrões, pude constatar que em sites como o google (em todas as aplicações), banco Itaú, Wikipédia, hotmail, dentre outros. Nesses sites, uma versão mais enxuta é disponibilizada no browser, somente com conteúdo e em alguns casos sem os banners de patrocinadores. O tempo de resposta para o google reader, foi muito superior ao mesmo utilizado no Chrome. O resultado disso, é que estou ganhando mais tempo na leitura de feeds de tal dispositivo.

No banco Itaú, pude ter acesso a consultas de faturas de cartão de crédito anteriores, com poucos toques na tela. A informação foi exibida de uma forma similar ao navegador tradicional e muito mais rápido.

Existem alguns sites que deixei de acessar via celular, pelo fato de não serem providos de tais recursos de gerenciamento de conteúdo. O tempo de renderização da tela sai dos padrões de resposta por ter um tempo muito excessivo, páginas contendo mais de 2MB (dois mega bytes) de tamanho devido às imagens que o contem.

Nesse estudo foi focado em conteúdo publico na internet. Agora já imaginou isso em conteúdo corporativo? Onde um colaborador precisa exercer suas atividades, por exemplo, em coleta de dados em pátio de produção? Será que os projetos para dispositivos móveis serão continuados na empresa?