Mark Zuckerberg disse uma vez: “O maior erro que cometemos, como empresa, é apostar demais no HTML5 em vez do nativo… porque ele simplesmente não existia. E não é que HTML5 seja ruim. Estou realmente, a longo prazo, muito animado com isso.” E quem não ficaria animado com a perspectiva de uma única base de código que funciona em várias plataformas ?

Leitura adicional no SmashingMag:

• Um guia para iniciantes para aplicativos da Web progressivos
• Os blocos de construção dos aplicativos da Web progressivos
• Criando um aplicativo Web completo no Foundation For Apps

Infelizmente, o Facebook sentiu que o HTML5 não oferecia a experiência que estava procurando construir, e é disso que realmente se trata: a experiência. Acredito que o que Mark estava realmente tentando dizer era que o maior erro deles foi tomar uma decisão baseada na tecnologia em vez de uma decisão baseada na experiência do usuário. No final das contas, devemos tomar decisões que agregam valor aos nossos clientes , e aderir a uma determinada tecnologia geralmente não é a melhor maneira de conseguir isso.

Para nosso cliente Beyond the Rack, um varejista de comércio eletrônico somente online, nosso principal objetivo era criar um aplicativo com uma ótima experiência do usuário. Assim como Zuckerberg, também queríamos seguir o caminho do HTML5 – a abordagem “escreva uma vez, execute em qualquer lugar” para aplicativos escritos em interfaces web HTML5 é extremamente atraente. Mas no mundo de hoje, onde os aplicativos estão se tornando a principal maneira de os usuários interagirem com seu produto, o desempenho não é apenas bom de se ter – é uma vantagem competitiva.

Quase nunca é o caso, no entanto, que todos os recursos do seu aplicativo precisam ser criados com interfaces completamente nativas. Por exemplo, embora possa ser difícil fazer com que as animações de navegação pareçam nativas na Web, uma página da Web que contém pouca ou nenhuma animação complexa pode ser facilmente usada no aplicativo enquanto ainda parece nativa. Isso é tudo o que realmente importa para o usuário. O que é necessário então é uma estratégia “talvez escreva uma vez, talvez execute em todos os lugares – isso realmente depende do recurso…”.

Resumindo, não escolha entre interfaces nativas e web . Use ambos.

Neste artigo, vou guiá-lo através de nossa experiência na construção de um aplicativo para o Beyond the Rack no qual misturamos conteúdo nativo e da web para criar um aplicativo que “parece” nativo.

Estudo de caso: criando um aplicativo para além do rack

Obviamente, era importante determinar quais problemas a Beyond the Rack estava procurando resolver para si e para seus clientes com seu aplicativo. A escolha de se tornar nativo ou web para cada recurso viria naturalmente disso.

Percebemos que, para criar um ótimo aplicativo, precisávamos fazer um ótimo trabalho com todas as três coisas a seguir:

• Interface de compras
  A Beyond the Rack é uma varejista somente online; por isso, ter uma ótima interface para navegar nas vendas e fazer compras é crucial. Como estávamos construindo um aplicativo nativo, tivemos a oportunidade de ir além do que a experiência na web pode oferecer.
• Comparabilidade
  Como um grande gerador de receita para o Beyond the Rack são os clientes que compartilham vários itens de vendas com amigos, precisávamos garantir que o compartilhamento entre iOS, Android e o navegador fosse o mais simples possível.
• Descoberta
  O Beyond the Rack oferece vendas por tempo limitado para seus usuários; portanto, ser capaz de alcançar os usuários rapidamente é muito importante. As mensagens push oferecem a melhor maneira de envolver esses clientes fiéis e, em última análise, foi o maior impulsionador na decisão de criar o aplicativo.

Vamos nos aprofundar em como criamos alguns dos recursos mais importantes de nossos aplicativos Beyond the Rack iOS e Android: quais recursos do aplicativo foram criados usando tecnologia da Web, quais recursos são totalmente nativos e como todos funcionam juntos.

A interface de compras

Os pedaços nativos

Criamos um site responsivo para o Beyond the Rack no tablet e no celular - um do qual nos orgulhamos. Mas não bastava simplesmente lançar o site em uma visualização da web e encerrar o dia; o site por si só não parece um aplicativo nativo. Uma grande razão para isso é a navegação. Em um navegador, você tem botões para voltar e avançar e uma barra de URL. Nos aplicativos iOS e Android, os usuários têm expectativas muito diferentes de como navegar, e queríamos corresponder a essas expectativas para que nosso aplicativo pareça consistente com cada plataforma.

Fizemos um protótipo que carrega conteúdo dinamicamente via AJAX e gerencia a navegação e as transições em linguagens da web, mas não conseguimos deixá-lo tão suave quanto as transições que você vê em aplicativos nativos. As animações de navegação no iOS e no Android são bastante difíceis de combinar usando a tecnologia da web, e qualquer instabilidade na navegação faria com que nosso aplicativo parecesse menos nativo. Se seu aplicativo não estiver sendo executado a 60 quadros por segundo, os usuários perceberão.

Criamos uma abordagem que achamos que combina o melhor dos dois mundos: carregue o conteúdo principal da web, mas use elementos de navegação nativos:

No iOS, implementar isso foi realmente muito simples. Aproveitamos o controlador de navegação, que gerencia uma pilha de visualizações, bem como uma barra de navegação para controlar a navegação entre cada visualização. No nosso caso, a pilha de visualizações é realmente apenas uma pilha de visualizações da Web — sempre que ocorre uma navegação, em vez de navegar até ela na própria visualização da Web, instanciamos uma nova visualização da Web, enviamos para nosso UINavigationController e navegamos até o novo destino. O uso de pilhas de visualizações da Web também significa que, sempre que o usuário voltar, ele não precisará esperar que a página seja recarregada, o que é ótimo para sua experiência. Se no futuro decidirmos substituir um recurso por uma visualização nativa, simplesmente enviaremos uma visualização nativa para a pilha, em vez da versão de visualização da Web desse recurso.

No Android, o equivalente ao controlador de navegação seria usar pilhas de atividades. Decidimos não usar várias atividades e fragmentos, porque ambos exigem um gerenciamento de ciclo de vida extremamente complexo. Acabamos gerenciando nossa própria pilha de visualizações da Web para o aplicativo e escrevendo animações nativas personalizadas para fazer a transição entre cada visualização.

Vários outros aplicativos aproveitam os elementos de navegação nativos para se adequar aos padrões de design do SO. Confira esta imagem do aplicativo Android do Basecamp, que aproveita uma barra de navegação nativa:

Além disso, compare o aplicativo da Amazon com seu site móvel:

Com essa abordagem, encontramos nosso ponto ideal de ter uma experiência familiar à plataforma , enquanto ainda aproveitamos uma excelente experiência de compra principal da web.

Isso pode ser uma surpresa para muitos, mas os desenvolvedores do aplicativo do Facebook também estão constantemente encontrando o ponto ideal, aproveitando o nativo ou a web quando faz sentido para cada recurso. De acordo com um artigo escrito por um engenheiro do Facebook: “Para áreas dentro do aplicativo em que prevemos fazer alterações com mais frequência, continuaremos a utilizar o código HTML5, pois podemos enviar atualizações do lado do servidor sem exigir que as pessoas baixem uma nova versão do aplicativo .” Parece que o Facebook está adotando a mesma abordagem defendida aqui: escolha a tecnologia para cada recurso com base no desempenho, no esforço de desenvolvimento necessário e na rapidez com que você precisa lançá-lo.

Para seu aplicativo, considere caso a caso se a criação de um recurso nativo ou o aproveitamento do conteúdo da Web faz mais sentido. Dada a dificuldade de construir uma navegação que pareça nativa, provavelmente faz sentido construir pelo menos isso usando componentes nativos.

Os bits da web

Hoje, quase todo mundo concorda que é uma boa ideia aprimorar sites progressivamente : use uma base de marcação para o menor denominador comum de navegadores e sobreponha-a com funcionalidade e aprimoramentos usando JavaScript e CSS, dependendo do contexto - sem bases de código ou modelos separados para diferentes dispositivos necessários. Assim como não faz sentido criar modelos separados para a web móvel e desktop, queríamos usar os modelos de site ao vivo dentro do próprio aplicativo. O aplicativo é apenas mais um contexto.

Eu chamo isso de construção de sites responsivos com reconhecimento de aplicativos . Ao construir nosso site com o contexto e o desempenho do aplicativo em mente, estaremos prontos para enviar a todos os nossos usuários em várias plataformas o quanto antes.

Os sites precisam ser capazes de detectar o contexto do aplicativo em três lugares: CSS, JavaScript e o servidor. Criamos uma classe de app para escrever CSS condicional e um método isRunningInApp para escrever JavaScript condicional e anexamos App ao agente do usuário para lógica condicional do lado do servidor.

Um exemplo de onde usamos o aprimoramento progressivo no aplicativo está na página de exibição do produto. Nós o otimizamos adicionando um botão “Adicionar ao carrinho” de posição fixa apenas para aplicativos:

Poderíamos ter adicionado um botão de posição fixa “Adicionar à bolsa” no navegador também, mas não o fizemos porque, no Safari, clicar perto da parte inferior abrirá a barra de navegação do Safari. Ter essa barra aberta acidentalmente quando o usuário tenta adicionar um produto ao carrinho seria uma falha de usabilidade inaceitável, apesar das vantagens de ter um botão persistente “Adicionar ao carrinho” na parte inferior da página:

Outra área em que fizemos ajustes específicos do aplicativo no site está no carrinho de compras. A lógica do carrinho é normalmente um dos aspectos mais complicados de qualquer site de comércio eletrônico e, como ficamos bastante satisfeitos com a experiência do carrinho no celular, decidimos reutilizá-lo no aplicativo, embora com uma aparência ligeiramente modificada:

Comparabilidade

A capacidade de compartilhar links e abrir links compartilhados é um recurso crítico que deve funcionar bem para o Beyond the Rack. Queríamos que o compartilhamento fosse perfeito. Se alguém compartilhar um link de sua área de trabalho e seu amigo o abrir no aplicativo, o link precisará abrir corretamente; da mesma forma, se alguém compartilhar um produto do aplicativo, ele deve ser aberto corretamente na área de trabalho; e se o amigo estiver no celular mas não tiver o app instalado, ele deve abrir no navegador. Estávamos determinados a tornar isso uma experiência incrível, porque isso normalmente é algo em que os aplicativos são fracos.

Tornar o conteúdo compartilhável entre a web e o aplicativo pode ser difícil . Para fazer isso com sucesso, você precisará mapear os links do seu aplicativo e os links da web. Isso era doloroso nos dias de pré-responsividade, quando a abertura de um URL de desktop levava você à página inicial de um URL de celular, devido a redirecionamentos e afins. Estamos vendo exatamente o mesmo problema hoje com aplicativos - banners no Safari e no Chrome solicitam que você abra um link em um aplicativo, apenas para que o aplicativo não mostre o que você estava procurando, deixando você pesquisar tudo novamente. Felizmente, lidar com links da web no aplicativo do Beyond the Rack é muito fácil, porque tudo o que precisamos fazer é carregar esse URL em uma visualização da web. Só precisamos garantir que os links da Web levem os usuários ao aplicativo em vez do navegador.

No Android, abrir uma URL em um aplicativo é simples. Você só precisa configurar um filtro de intent para carregar o aplicativo sempre que um usuário tentar carregar o URL especificado (no nosso caso, www.beyondtherack.com ). Depois que o aplicativo for instalado, os usuários terão a opção de abrir o URL no aplicativo ou no navegador:

O iOS teve um caminho um pouco mais difícil para permitir que URLs da Web sejam abertos diretamente em aplicativos. Anteriormente, o iOS só permitia que você registrasse um esquema de aplicativo para cada aplicativo (por exemplo, beyondtherack:// ). Como era impossível saber quais aplicativos estavam instalados, a única opção era abrir um determinado link no Safari e, a partir daí, tentar abrir esse link no aplicativo. Isso veio com um pequeno aborrecimento: se o aplicativo não estivesse instalado, o usuário receberia uma mensagem de erro irritante: “O Safari não pode abrir a página porque o endereço é inválido”. Felizmente, um hack permite suprimir esse erro usando iframes. Se você deseja oferecer suporte a links diretos no iOS 8, esta é a melhor opção.

Felizmente, o iOS 9 introduziu a vinculação universal, que permite que os aplicativos interceptem links da web antes que os links passem pelo Safari. ## Descoberta A pontualidade é extremamente importante para uma empresa como a Beyond the Rack. Tradicionalmente, a principal forma da empresa de informar os clientes sobre as vendas era por meio de campanhas por e-mail. Mas com os aplicativos, é capaz de **comunicar-se diretamente com seus clientes sobre vendas**, o que é muito poderoso. (É claro que as notificações push estão chegando aos navegadores lentamente, com o [Chrome liderando a carga](https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). Mas para dispositivos Android mais antigos e para iOS, a escolha de usar a tecnologia nativa ou da web já foi feita para nós.) Assim como no compartilhamento, nossa decisão de aproveitar o conteúdo da web diretamente no aplicativo facilitou muito a configuração das **notificações push**. Como todos os produtos e vendas podem ser identificados pelo mesmo URL no site e no aplicativo, é simples educar os profissionais de marketing sobre como enviar notificações por push para seus clientes - tudo o que eles precisam fazer é compartilhar os mesmos URLs que estão acostumados a compartilhar em campanhas de e-mail. Uma diferença interessante entre iOS e Android é o **sistema de permissão** para notificações push. No iOS, a permissão para notificações é controlada pelo sistema operacional, enquanto a permissão não é necessária no Android. Ainda assim, sentimos que solicitar permissão era a coisa certa a fazer do ponto de vista do atendimento ao cliente. Assim, quando o usuário faz login no aplicativo pela primeira vez, perguntamos se ele deseja receber notificações:

Também decidimos construir essas **caixas de diálogo de notificação** com interfaces da web. Nada neles exigia desempenho avançado, portanto, construí-los com interfaces de usuário da Web e reutilizá-los em plataformas fazia sentido. Este é outro exemplo de como tornar o site sensível ao aplicativo: essas caixas de diálogo fazem parte do site, mas são mostradas condicionalmente no aplicativo.

Resultados

Após o lançamento do aplicativo, queríamos comparar seu desempenho com a experiência do navegador. Comparar diretamente suas análises não era suficiente, porque, em nossa experiência, qualquer pessoa que instalou o aplicativo provavelmente era um cliente mais fiel e, portanto, provavelmente converteria melhor. Para evitar viés de seleção, montamos um teste A/B; metade dos usuários foram mantidos no aplicativo e metade foi chutada para o navegador, o que garantiu que os únicos participantes do experimento fossem os usuários que tinham o aplicativo instalado (os usuários mais fiéis).

• As transações por visitante único foram 76% maiores com a experiência do aplicativo do que com a web.
• Os usuários diários únicos do aplicativo tiveram 20% mais chances de converter .
• Os usuários de aplicativos gastaram 63% mais tempo navegando do que os usuários da web .

Vitórias de desempenho rápido

Criar um aplicativo que carregue conteúdo da web e pareça nativo não sai da caixa no iOS ou Android. Aqui estão alguns dos desafios de desempenho que enfrentamos que valem a pena compartilhar:

• No iOS, o momento de rolagem em uma visualização da Web não corresponde ao momento de rolagem em uma visualização de rolagem nativa. Isso foi descoberto em testes com usuários. Aqui está um forro para resolver isso: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• Tenha cuidado ao redimensionar visualizações da web . Encontramos problemas em que redimensioná-los causava repinturas inteiras, o que acabava com o desempenho de rolagem em dispositivos mais antigos.
• Lidar com centenas de diferentes implementações de visualização da Web no Android pode ser doloroso. O problema mais doloroso que encontramos é um bug de visualização da Web conhecido no Android 4.4.2, que lança uma exceção fatal no Chromium que faz com que o aplicativo falhe. Removendo transform: translate3d nessa versão do Android parece fazer o truque. Como alternativa, você pode usar o Crosswalk para enviar seu próprio tempo de execução da Web compilado com seu aplicativo (não fizemos isso, mas planejamos fazê-lo em projetos futuros).
• Use o FastClick, não apenas porque ele remove o atraso de clique de 300 milissegundos, mas também porque corrige um bug de clique na visualização da Web introduzido no iOS 8.4.1. Para nós, o bug se manifestou ao não permitir que a página mudasse se o clique fosse muito lento.
• Faça tudo o que puder para tornar a rolagem incrível. Você pode debounce eventos de rolagem, evitar repinturas desnecessárias e muito mais. Se a rolagem não estiver sendo executada a 60 quadros por segundo, os usuários perceberão, ainda mais em um aplicativo do que na web.
• Faça tudo o que puder para carregar as páginas em menos de 1000 milissegundos.

Ferramentas para construir um aplicativo aproveitando seu site

Você tem várias opções para criar um aplicativo que aproveita seu site existente. A abordagem que adotamos é construir o aplicativo específico para cada plataforma (usando Xcode e Android Studio), aproveitando visualizações da web ou visualizações nativas sempre que necessário.

Ao carregar uma visualização da Web para um recurso específico, recomendamos integrar a visualização da Web do Cordova, em vez de usar diretamente as bibliotecas de visualização da Web fornecidas pelo iOS e Android. Isso dará às suas visualizações da Web uma série de recursos que você teria que construir sozinho, como uma ponte da Web para nativo para se comunicar de JavaScript para código nativo e vice-versa, a capacidade de acessar eventos de ciclo de vida, bem como acessar para uma variedade de plugins Cordova. Alternativamente, algumas outras pontes web-to-native estão disponíveis para as várias plataformas, se você quiser evitar depender do Cordova.

Existem algumas estruturas disponíveis para ajudá-lo a criar aplicativos dessa maneira, como Supersonic e Astro, uma estrutura de aplicativo nativa que estamos criando para facilitar o gerenciamento da complexidade da criação de aplicativos usando interfaces nativas e web.

Conclusão

Com o Beyond the Rack, nos propusemos a construir um aplicativo no qual pudéssemos facilmente entregar valor aos usuários sem sacrificar a experiência. Ao seguir uma abordagem que coloca a tecnologia em segundo plano , permitindo-nos usar a tecnologia certa para a tarefa, acreditamos que conseguimos exatamente isso. Com qualquer alteração ou introdução de um recurso, sempre nos perguntamos: “Que experiência queremos projetar aqui que melhor resolva o problema do usuário? Essa experiência requer o uso de desempenho avançado ou animações?”

A resposta a essa pergunta determinará se construímos o recurso com tecnologia web e o reutilizamos no navegador e no Android e iOS ou o construímos de forma personalizada para cada plataforma.

Em última análise, acredito que é assim que os aplicativos devem ser construídos. Mas vai levar uma mudança de mentalidade. Em vez de tentar determinar se a web triunfará sobre a nativa ou se tornará uma relíquia do passado, devemos abraçar o melhor de ambos. Devemos reconhecer suas respectivas vantagens e desvantagens e usar a tecnologia que faz mais sentido para o determinado recurso.