Cutting Edge

Mobilizando um site da web existente

Dino Esposito

Trata-se de um cenário comum. Você chega em um hotel, aeroporto ou algum outro local público. VocÇe se conecta à rede sem fio local e é redirecionado à página de logon para inserir suas credenciais. A página de logon no seu dispositivo móvel é muito pequena. Tudo que você pode fazer é redimensionar a tela, colocar o formulário de entrada em um tamanho razoável e então digitar suas credenciais.

Esta é uma experiência incômoda, mesmo assim acontece mais geralmente do que não. E isso é mais do que simplesmente um incômodo. O futuro dos sites da web que não aparecem bem em todos os dispositivos é triste. Não oferecer aos usuários móveis uma boa experiência pode cortar os lucros das empresas ao direcionar os usuários para longe do site e em direção ao site do concorrente.

A varinha mágica que muitos desenvolvedores acenam para lançar feitiços na web é o web design responsivo (RWD). O RWD é definitivamente uma opção, mas como qualquer outra, tem seus prós e contras. O problema com o RWD é, para a maior parte, requer um novo projeto.

A ideia básica do RWD é que tudo é fluído. Quaisquer elementos nunca serão maiores do que a tela. Então, por definição, o RWD se adapta a um número infinito de larguras de tela. O ponto do RWD é criar um novo site da web inspirado por uma nova ideia de conteúdo e direcionando um número menor e corrigido de pontos de interrupção. Pressionando o RWD ou uma biblioteca como Twitter Bootstrat em um site da web existente projetado para o desktop dificilmente é uma opção viável.

Além do mais, vender a abordagem RWD é fácil. Existe um site, uma marca e uma base de código servindo várias interfaces do usuário. Implementar o RWD é menos fácil, pois ele muda a experiência de desenvolvimento web. Você precisa de uma visão clara e forte de como o site apresentará a informação. O RWD pode ser fácil de vender, mas não suporta improvisação. A adaptação do conteúdo não é mágica. Ela vem de planejamento atencioso e diligente.

RWD também muda as regras consolidadas do gerenciamento do projeto e geralmente acaba custando mais do que o desenvolvimento de um plano de site não responsivo. Os gráficos de Gantt acompanham o progresso fazer um pouco de sentido como qualquer nova etapa que exige que os membros da equipe meçam os efeitos através de todo o espectro das exibições suportadas. Então, no final, quando ter um site da web responsivo não é uma opção, o que você pode fazer para atender às expectativas do cliente e tornar sua vida mais fácil?

Adicione um site móvel conectado

Quando seu site da web ajuda sua empresa a permanecer no negócio e desempenha uma função central ao atrair, manter e servir os clientes, então fornecer uma experiência específica móvel é vital para fazer com que os clientes voltem. A abordagem mais simples que não requer uma reescrita total do site e não quebra qualquer recurso existente é criar um site específico separado para seu público móvel. Esta abordagem é conhecida como uma construção em um site M.

Um site M, assim como um aplicativo nativo, é mais provável de ser consumido por usuários em movimento - pessoas que estão em pé, com pressa, ocupadas ou aguardando em uma fila. Os usuários que desejam se conectar a um site nestas condições e usar um dispositivo muito pequeno, realmente esperam algum benefício do site. Portanto, o site deve ser direto, conciso, preciso e rápido para carregar e responder.

Adotar a abordagem do site M pode ser barata por duas razões. É um projeto de marca nova, mas é esperado para herdar os serviços principais do site existente. Mais frequentemente do que não, ele herda grandes compartilhamentos de lógica de negócios, que não significa que duplica a base do código. Além disso, um site M geralmente implementa a regra 80/20. Ele geralmente suporta não mais do que 20% dos recursos disponíveis no site completo. A seleção de 20% dos recursos, no entanto, não é tão fácil.

Ao planejar um site M, você deve pensar com a mente de um usuário de site em movimento. Quais partes de informações um usuário em movimento realmente espera consumir no seu site? Quais funções o usuário espera realizar? O que você pode fazer para facilitar e acelerar a interação o máximo possível? Esse último ponto envolve o uso de recursos HTML5 ao máximo.

Em um site que você sabe que será usado em dispositivos móveis, é difícil não definir o tipo de atributo de um elemento de entrada para um número ou data, quando os números ou datas são esperados. Isso simplificaria muito a digitação. Da mesma forma, pode haver novos casos de uso introduzidos na parte superior da lógica de negócio semelhante, para tornar a vida mais fácil e mais agradável para os usuários móveis.

Acessando o seu Site M

Pelo fato do site M ser um site da Web discreto, qual URL os visitantes devem usar? A melhor opção é um subdomínio como m.yourserver.com? Um nome de domínio de nível superior .mobi ou subdiretório /mobile no desktop funciona melhor? Um subdomínio m. é mais fácil de gerenciar do que um domínio .mobi simplesmente porque é um subdomínio e não um novo nome de domínio. Um diretório é, provavelmente, mais propenso a erros, já que significa que o site móvel será hospedado no mesmo aplicativo que o desktop. Isso pode fazer toda a solução mais frágil.

A abordagem mais simples é o uso de um subdomínio m. com alguma lógica de redirecionamento que automaticamente envia usuários móveis ao site m.yourserver.com. Essa solução é boa para os usuários, pois eles podem usar o subdomínio m. direto e a URL canônica. Para os desenvolvedores, porám, tem o inconveniente de exibir a lógica de detecção do dispositivo, tanto no site de desktop como no site móvel.

Implementar redirecionamento de site

Quando dois sites estão no lugar e funcionam com a mesma URL, você deve processar o nome do host e decidir o que fazer para cada solicitação. Se o nome do host pertence ao site do desktop e o navegador solicitado é detectado para ser um navegador de desktop, então tudo funciona conforme esperado.

Caso contrário, o usuário deve ver uma página de destino, e ser informado de que eles estão tentando acessar um site de desktop com um dispositivo móvel. Então, eles terão uma chance de salvar suas preferências para situações semelhantes no futuro. Essa preferência é armazenada em um cookie e verificada a seguir. Se a solicitação se refere a uma URL no site móvel e o usuário parece ter um navegador de desktop, considere mostrar uma página de destino diferente ou apenas deixe a solicitação ir, como de costume. Finalmente, se uma solicitação é colocada de um dispositivo móvel para um site móvel, ela será servida conforme esperado. Você pode ter seu site olhando para as capacidades do dispositivo e determinar a exibição mais adequada. A Figura 1 apresenta um diagrama do algoritmo.

Figura 1 O Algoritmo do Alternador de Exibição do Desktop/Móvel

No ASP.NET, você pode implementar o algoritmo de rotina como um módulo HTTP e registrá-lo tanto no site do desktop como no site móvel. O módulo captura o evento BeginRequest e usa o redirecionamento simples ou, se possível, reescreve a URL para alterar a página de destino conforme o caso, como mostrado na Figura 2.

Figura 2 Implementação de um Módulo HTTP do Roteador Móvel

public class MobileRouter : IHttpModule
{
  private const String FullSiteModeCookie = "FullSiteMode";
  public void Dispose()
  {
  }
  public void Init(HttpApplication context)
  {
    context.BeginRequest += OnBeginRequest;
  }
  private static void OnBeginRequest(Object sender, EventArgs e)
  {
    var app = sender as HttpApplication;
    if (app == null)
      throw new ArgumentNullException("sender");
    var isMobileDevice = app.Context.Request.IsMobileDevice();
    // Mobile on desktop site, but FULL-SITE flag on the query string
    if (isMobileDevice && HasFullSiteFlag(app))
    {
      app.Response.AppendCookie(new HttpCookie(FullSiteModeCookie));
      return;
    }
    // Mobile on desktop site, but FULL-SITE cookie
    if (isMobileDevice && HasFullSiteCookie(app))
      return;
    // Mobile on desktop site => landing page
    if (isMobileDevice)
      ToMobileLandingPage(app);
  }
  private static Boolean HasFullSiteFlag(HttpApplication app)
  {
    var fullSiteFlag = app.Context.Request.QueryString["m"];
    if (!String.IsNullOrEmpty(fullSiteFlag))
      return String.Equals(fullSiteFlag, "f");
    return false;
  }
  private static Boolean HasFullSiteCookie(HttpApplication app)
  {
    var cookie = app.Context.Request.Cookies[FullSiteModeCookie];
    return cookie != null;
  }
  private static void ToMobileLandingPage(HttpApplication app)
  {
    var landingPage =
      ConfigurationManager.AppSettings["MobileLandingPage"];
    if (!String.IsNullOrEmpty(landingPage))
      app.Context.Response.Redirect(landingPage);
  }
}

Uma vez instalado no site do desktop, este módulo HTTP captura cada solicitação e verifica o navegador solicitado. Se o navegador está executando dentro de um dispositivo móvel, o módulo redireciona para a página de destino especificada. A página de destino será uma página otimizada móvel, que oferece alguns links para o site do desktop e para o site móvel.

Onde você coloca a página de destino para permitir que os usuários móveis decidam o que fazer? Geralmente, isso não importa. No entanto, se você colocar no site móvel, você pode implantar seu site móvel com toda a lógica de roteamento necessária, sem tocar na base do código do site do desktop. As mudanças do site do desktop são limitadas para configurar o módulo HTTP no arquivo web.config.

O que o Móvel realmente significa?

O mundo da Web móvel não está simplesmente dividido em dois campos de computadores desktop e todo o resto. O móvel engloba os smartphones e tablets, no mínimo. No site M que tem como alvo smartphones, pode não funcionar tão eficazmente para tablets e vice-versa. Servir páginas otimizadas de smartphones a tablets vai contra a expectativa do usuário comum de obter uma experiência como a do desktop.

Você deveria ter um site T adicional para tablets e um site para dispositivos herdados e, quem sabe, um para dispositivos portáteis? Ao todo, os smartphones merecem uma experiência ad hoc e um site dedicado. Os tablets podem, felizmente, processar o mesmo conteúdo dos computadores desktop com pequenos ajustes, tais como um conjunto diferente de arquivos CSS com mais preenchimento e fontes maiores e algum suporte de consulta de mídia para quando a orientação muda para retrato ou paisagem. Estes ajustes requerem alterações para a base de código do site do desktop existente. No entanto, não é muito de uma alteração intrusiva.

O problema continua a ser como detectar smartphones e qual é a definição de um smartphone que funciona para o seu cenário de negócio.

Ferramentas de detecção do dispositivo

Não existe definição comum para um smartphone. Um smartphone não é um atributo físico como um número da versão do SO. Quando os navegadores solicitam uma página, eles enviam uma cadeia de caracteres do agente usuário, significando que alguns códigos do lado do servidor devem processar a cadeia de caracteres do agente usuário e determinam se o dispositivo é um tablet, um smartphone ou alguma outra coisa.

A detecção do dispositivo requer ferramentas ad hoc, que tem vários níveis de confiabilidade e precisão. Por exemplo, você pode usar alguns plugins Modernizr ou rotinas comuns para verificar os agentes usuários para sub-cadeias de caracteres conhecidas. Isso pode funcionar de forma confiável o suficiente se tudo que você quer fazer é separar os desktops para todo o resto.

Neste contexto, a detecção de qualquer coisa como um Android OS diz ao navegador que não é um desktop. No entanto, detectar o Android não ajuda a determinar se é um smartphone ou um tablet. A estrutura WURFL (wurfl.sourceforge.net) é uma escolha popular com ferramentas que funciona no local, na nuvem e até mesmo no nível do servidor da Web (sem código, apenas configuração) no IIS e outros ambientes.

Se você optar pela criação de um site M para servir conteúdo ad hoc aos usuários móveis, você precisa ser claro sobre quais dispositivos estão sob a jurisdição do site M (escolhendo entre smartphones, tablets e mais) e como detectar os dispositivos para que os usuários tenham uma URL única para chegar ao site, independente do dispositivo.

Conclusão

Os usuários esperam usar perfeitamente as páginas da Web em seus smartphones e tablets, assim como eles fazem em seus desktops. O processamento de energia ou tamanho do cache é limitado nos dispositivos móveis, mas isso não pode ser uma desculpa para servir páginas que exigem ampliação e levam segundos para carregar. Separar o desktop de qualquer outra coisa não é uma escolha detalhada, também. Algum nível de detecção do dispositivo é necessário para fornecer um bom serviço. Quando se trata de detecção de dispositivo e fatores de forma, os custos de complexidade e de desenvolvimento crescerão.

Muitas empresas pensam que o RWD é o Columbus Egg clássico - obviamente uma solução simples e brilhante para um problema difícil. Os sites da Web responsivos são mais complexos e caros para criar do que os comumente reformulados. Mais importante, uma abordagem RWD funciona para sites novos ou significativamente reformulados. Você não pode simplesmente adicionar RWD para mobilizar um site existente que foi elaborado para o desktop. No entanto, responder às necessidades de seu público móvel é uma necessidade do negócio. E quanto mais cedo você responder, melhor.

---

Dino Esposito é o co-autor do "Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) e “Programming ASP.NET MVC 5” (Microsoft Press, 2014). Um evangelista técnico para as plataformas do Microsoft .NET Framework e Android no JetBrains, Esposito frequentemente fala em eventos do setor em todo o mundo e compartilha sua visão do software em software2cents.wordpress.com e no Twitter em twitter.com/despos.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Jon Arne Saeteras