Recentemente estive trabalhando na criação de um protótipo para um “website” de adminstração aqui na empresa. Os primeiros requisitos eram que o site seria acessado por usuários administrativos, que normalmente administram o sistema do escritório. Ou seja, podemos presumir que estarão conectados em desktops. Sem muito esforço fiz um protótipo como este:

print-desktop-view

Tudo lindo! Até que alguém tentou acessar em um tablet (um iPad por exemplo). Daí a largura da página, a distância dos itens do menu e até alguns eventos que não eram disparados pelo “toque” na tela passaram a causar grandes problemas. Então, comecei a utilizar uma série de estratégias para dar ao meu protótipo de website uma boa experiência também nos tablets.

Viewport

A primeira coisa que precisei fazer para atingir o meu objetivo foi adicionar uma metatag “viewport”, assim:

<meta name="viewport" content="initial-scale = 1.0,maximum-scale = 1.0" />

O segredo dessa linha é justamente corrigir o comportamento padrão dos browsers de dispositivos móveis que emulam uma resolução virtual para poder renderizar um site  de resoluções grandes como 960 px de largura numa tela de apenas 320 px (fazendo uma relação de 1/3 para cada pixel). Ou seja, o site é sempre mostrado como uma miniatura… e dependendo do dispositivo fica simplesmente inviável navegar sem usar o “zoom” flutuando pela página procurando as coisas. Como não queremos isso, usamos essa linha para travar a viewport sempre no máximo que o dispositivo oferece fisicamente (mantendo a relação de 1/1 para os pixels).

Media Queries

Como usamos o viewport, nós definimos que não queremos uma miniatura do nosso site no dispositivo. Logo temos um problema: Como vamos colocar um site de 960px numa tela de 768px, 480 ou 320px? Não tem jeito! 

Então a estratégia agora é reorganizar o conteúdo do nosso website para que ele ocupe menos espaço e então se ajuste ao espaço que temos disponível. Conceitualmente seria mais ou menos assim:

conceito-mediaqueries

Para realizar essa mudança de estrutura, nós podemos utilizar o “Media Queries”. Para alguns pode ser uma novidade, pois é um recurso relativamente novo do CSS.  Com este recurso, nós podemos alterar a completamente o design do nosso website a partir do tamanho e a capacidade do dispositivo em que o conteúdo está sendo exibido.

Podemos dizer, que de todos os aspectos para tornar seu projeto adaptável à vários tipos de tela, este é o principal recurso que você deve conhecer para desenvolver tais soluções. Vamos ver a estrutura destas “Media Queries” aplicadas no nossos projeto.

Eu preciso definir duas “visões”:

  • Uma para desktop: estou assumindo que qualquer tela que possua uma resolução “física” de mais de 990px é um desktop ou pode visualizar o website nesta estrutura.
  • E outra para tablets: qual resolução menor que 990px iremos mostrar a versão para tablets.

O arquivo CSS do projeto ganhou duas novas seções e além de  todos os estilos padrão, agora temos as duas faixas definidas pelas Media Queries onde iremos sobreescrever os estilos padrão para dar ao website a aparência desejada.

/* Estilos Padrão */
.content { }

/* Tablet */
@media only screen and (max-width: 990px) {
	.content { }
}

/* Desktop */
@media only screen and (min-width: 991px) {
	.content { }
}

Não vou entrar em detalhes sobre como ficaram os estilos de cada uma das versões… pois não é nosso objetivo ensinar CSS neste post, mas você pode acreditar que é perfeitamente possível alterar toda a disposição das divs para que fique igual ao planejado usando alterações no “display”, “float” e “margin”. Iremos abordar este assunto num próximo post sobre “layouts responsivos”.

Pontos de atenção

O resultado da nossa adaptação via CSS fica mais ou menos assim. Destaquei alguns pontos que precisamos observar, pois vão um pouco além da mudança de estrutura. Temos que lembrar que nestes dispositivos os usuários utilizarão o dedo para interagir com a interface do seu aplicativo. Por isso temos que aumentar as margens entre links e alargar alguns botões.

view-tablets-highlight

  1. Alarguei bem os botões que abrem o menu “acordeon” (inclusive aumentei bem a fonte) para que o usuário não tente acionar um menu e acabe acionando outro.
  2. Além de também aumentar a fonte dos links, também aumentei as margens entre os menus. Um ponto muito importante a analisar aqui é que assim como temos que economizar na largura do aplicativo, também precisamos economizar bem na altura… por isso na versão “tablet” do meu aplicativo, optei por organizar os links horizontalmente.
  3. Os botões de ação do grid ganharam um corpo mais largo para facilitar o acionamento usando os dedos.

Eventos

Por último, mas não menos importante. Precisamos tomar muito cuidado com os eventos que utilizamos em nossos scripts. No meu protótipo, eu adiciono um comportamento no botão de excluir do grid através de uma função jQuery que abre um popup de confirmação:

$("a.action-remove").bind("click", (function (e) {
	e.preventDefault();
	// implementação do plugin de popup
}));

A primeira coisa que você precisa observar é que este script não irá funcionar num dispositivo touchscreen, pois o evento que o jQuery usa nestes dispositivos é o “touchstart”. Então se você tiver casos assim, vai precisa tratar também este evento para garantir o funcionando.

Você pode “bindar” vários eventos assim:

$("a.action-remove").bind("click touchstart tap", (function (e) {
	e.preventDefault();
	// implementação do plugin de popup
}));

Mas este caso vai além. Eu não queria que a confirmação popup funcionasse da mesma forma no desktop e no tablet. Usuários de dispositivos mobile não se dão bem com popups… fica muito estranho. Então usei o Modernizr para fazer duas implementações diferentes deste alert de confirmação, mantendo o popup jQuery na versão desktop e o recurso nativo de confirmação em dispositivos com touch.

// se o browser não tem suporte a "touch"
if (!Modernizr.touch) {

	// fazemos a implementação do popup
	$("a.action-remove").bind("click", (function (e) {
		e.preventDefault();
		// implementação popup jQuery
	}));

} else {

	// caso contrário usamos apenas o "confirm" nativo
	$(document).find('a.action-remove').each(function () {
		var lnk = $(this);
		// uso uma chamada simples do "confirm" nativo do browser
		lnk.attr('onclick', "if (! confirm('" + lnk.attr('msg-delete-confirm') + "')) return false;");
	});

}

Ficando assim:

view-confirm-tablet

Conclusão

Vimos que é perfeitamente possível atacar um aplicativo para dar a ele um bom suporte à dispositivos mobile seguindo estratégias simples de desenvolvimento. É claro que o exemplo que exploramos é bastante reduzido, mas demonstra bem como um aplicativo desktop que já está funcionando pode rapidamente transformar-se num aplicativo móvel.