Desenvolvimento web

Desenvolvimento de site por R$150,00/Mês

Desenvolvimento Web responsivo com Melhor Custo-beneficio

Planos de desenvolvimento web com hospedagem Gratís
Arquivo de New Technologies | LCF HOST

New Technologies


Erros comuns em desenvolvimento web para campanhas de SEO

Conheça erros comuns em desenvolvimento web para campanhas de SEO e saiba como evitá-los

Uma boa campanha de SEO acontece quando várias ações de otimização são realizadas, conjunta e simultaneamente. E, certamente, uma dos aspectos da estratégia de uma ação de SEO são as ações técnicas tomadas no desenvolvimento web.

Este é um artigo traduzido do original “Why my SEO campaign failed? Part 2: Common Web Development mistakes“, do blog Web SEO Analytics, e sofreu pequenas modificações.

Passar muitos argumentos no URL

Quando o site é dinâmico, os desenvolvedores web precisam ter uma referência sobre o qual a página, o produto ou categoria o visitante quer ver. Normalmente um ID é necessário para recuperar os dados do banco de dados. Em outros casos, devido à complexidade do projetoou devido a más técnicas de programação, mais variáveis são necessárias para identificar uma determinada página. Aqui está um exemplo de um URL dinâmico:

Infelizmente, este tipo de URL não é amigável nem para pessoas, nem para mecanismos de busca. Segundo é possível ler nas Diretrizes Técnicas das Diretrizes para Webmasters da Central do Webmaster Google,

Se você decidir usar páginas dinâmicas (por exemplo, o URL que contém um caractere “?”), saiba que nem todos os spiders de mecanismos de pesquisa rastreiam as páginas dinâmicas e estáticas. Isso ajuda a manter os parâmetros curtos e a quantidade desses parâmetros pequena.

Por isso, é altamente recomendado usar algum tipo de reescrita de URL, como mod_rewrite, para converter as URLs dinâmicas para URLs amigáveis. Qual é o risco, se isso não for feito? Bem, se há muitos parâmetros em URLs: os motores de busca podem não indexar as páginas; além disso, geralmente  URLs não amigáveis não contém palavras-chave importantes no endereço, então, não raramente você pode conseguirá rankings inferiores para essas páginas do que se elas tivessem URLs amigáveis.

Usar muito JavaScript, frames/iframes, AJAX, Flash e Silverlight

JavaScript, frames/iframes, AJAX, Flash e Silverlight são ferramentas úteis e alguns deles, quando bem usados, melhoram a experiência do usuário. Mas nenhum deles é search engine friendly.

As mesmas Diretrizes Técnicas do Google citadas, indicam:

Use um navegador de texto como o Lynx para examinar o seu site, pois muitos spiders de mecanismos de pesquisa veem o site do mesmo modo que o Lynx. Se recursos especiais como JavaScript, cookies, IDs de sessão, frames, DHTML ou Flash permitirem que você veja todo o site em um navegador de texto, os spiders dos mecanismos de pesquisa poderão ter dificuldade em rastrear o seu site.

Se o objetivo é que o site seja amigável aos mecanismos de busca, devemos verificar se eles podem ser vistos usando browsers de texto simples como o Lynx (que é como o googlebot “vê” os sites). É possível usar emuladores do Lynx ou desabilitar CSS e imagens diretamente no navegador (se usar, Firefox, uma ótima opção é usar o plugin Web Developer).

Não usar o atributo alt em imagens e não otimizar o caminho das imagens

Os motores de busca (e computadores, em geral) não são muito bons em identificar o que é representado em uma imagem. Portanto, a fim de compreender sobre o que uma imagem é, os bots analisam o nome e o atributo “alt” das imagens.

O Google Image Search pode trazer uma quantidade significativa de tráfego. Se você não garantir o “apoio” a mecanismos que permitam a otimização de imagens, você pode perder uma boa fonte de tráfego. Assim, garanta que você use corretamente ambos, o atributo alt e o nome da imagem – usar um CMS que permita esse tipo de otimização é uma boa dica.

Usar métodos incorretos para oferecer suporte a idiomas diferentes

Quando você tem sites multilíngue, tenha certeza de que a arquitetura está correta. Não há uma única forma “correta” para fazer isso. Basicamente, há três maneiras corretas para suportar um site em vários idiomas e cada um dos métodos a seguir tem alguns prós e contras:

  • Subdomínios. Exemplo: fr.example.com, gr.example.com, etc
  • Subdiretórios. Exemplo: www.example.com/fr/, www.example.com/gr/, etc
  • Diferente domínios. Exemplo: www.example.fr, www.example.gr, etc

A dica é evitar o envio de conteúdo baseado em IP sem ter a mesma versão do site disponível para todos. Também não implementar soluções ruins como passar o idioma como uma variável GET, por exemplo www.example.com/?lang=fr.

Não se preocupar com o tempo de carregamento da página

Recentemente o Google informou que passou a usar a velocidade de carregamento dos websites em seus algoritmos de classificação (apesar de isso não estar valendo para sites de todos os países do mundo). Há um debate sobre se esse recurso deve ser incluído, uma vez que não tem nada a ver com a relevância de um site. No entanto, a velocidade aumenta a experiência do usuário. Além disso, ter um site leve, que carregue rapidamente, pode melhorar seu ROI e diminuir a carga do seu servidor (conheça 8 maneiras de melhorar a performance de um site).

7 dicas de desenvolvimento web

Algumas dicas para guiar o desenvolvimento de suas páginas web são:

  • Colocar menus, cabeçalhos e rodapés em arquivos separados, a fim de realizar mudanças globais rápidas (funções “include);
  • Tentar usar subdomínios em sites multi idioimas;
  • Usar caminhos absolutos para cada página, imagem, CSS e javascript do site;
  • Usar canonicals para evitar conteúdo duplicado;
  • Usar redirecionamento 301 ao invés de 302 quando o caminho para a página mudar e nunca apagar páginas;
  • Redirecione corretamente as versões sem “www” para as que tenham “www” e vice-versa;
  • Não adicionar IDs de sessão nas URLs.

E você, conhece algum outro erro comum em desenvolvimento web que pode atrapalhar uma campanha de SEO e o que fazer para evitar/corrigir?


Dominando o “this” em JavaScript

A palavra-chave “this” em JavaScript confunde desenvolvedores novos e experientes. Leia este artigo e domine o “this” em JavaScript!

A palavra-chave this em JavaScript confunde desenvolvedores JavaScript novos e experientes. Este artigo pretende elucidar a questão de uma vez, deixando claro como usar this corretamente em todos os cenários, incluindo situações mais peculiares em que normalmente this se revela mais difícil de ser compreendido.

Em JavaScript, usa-se this de forma semelhante ao uso de pronomes em linguagens naturais, como o inglês ou francês. Escreve-se: “João está correndo rápido porque ele está tentando pegar o trem”. Note o uso do pronome “ele”. Poderia se ter escrito: “João está correndo rápido porque João está tentando pegar o trem”. Não se reutiliza “João” dessa maneira, pois se assim fosse, nossa família, amigos e colegas nos abandonariam… De uma maneira graciosamente semelhante, em JavaScript se usa a palavra-chave this como um atalho, um referente; ou seja, o sujeito no contexto ou o sujeito do código em execução.

Exemplo:

Se se usa person.firstName e person.lastName, tal como no último exemplo, o código se torna ambíguo. Considere que poderia haver outra variável global (você estando ciente dela ou não) com o nome “person”. Em seguida, as referências a person.firstName poderiam tentar acessar a propriedade firstName da variável global person e isso poderia levar a erros difíceis de serem depurados. Portanto, usa-se a palavra-chave this não apenas para fins “estéticos” (isto é, como um referente), mas, também, para fins de precisão. Seu uso realmente torna o código mais inequívoco, assim como o pronome “ele” tornou a frase mais clara, informando que se estava referindo ao João específico do início da frase.

Assim como o pronome “ele” é usado para se referir ao antecedente (substantivo a que um pronome se refere), a palavra-chave this é similarmente usada para se referir a um objeto a que a função (onde this é usado) está vinculada. Esta palavra-chave não se refere apenas ao objeto, mas também contém o valor do objeto. Assim como o pronome, isso pode ser pensado como um atalho (ou um substituto razoavelmente não-ambíguo) para se referir ao objeto no contexto (o “objeto antecedente”).

O básico sobre this em JavaScript

Primeiramente, é preciso saber que todas as funções em JavaScript têm propriedades, assim como os objetos têm propriedades. E quando uma função é executada, ela obtém a propriedade this — uma variável com o valor do objeto que invoca a função na qual this é usado.

A referência ao this sempre se refere a (e contém o valor de) um objeto — um objeto singular — e normalmente é usado dentro de uma função ou método, embora possa ser usado fora de uma função no escopo global.

Quando em modo estrito (strict mode), this mantém o valor undefined em funções globais e em funções anônimas que não estão vinculadas a nenhum objeto.

this é usado dentro de uma função (digamos função “A”) e ele contém o valor do objeto que invoca a função A. Isso é preciso para acessar métodos e propriedades do objeto que invoca a função A, especialmente porque nem sempre é possível saber o nome do objeto invocador e, às vezes, não há nenhum nome para usar para se referir ao objeto invocando. Na verdade, this é realmente apenas um atalho-referência ao “objeto antecedente” (ou o objeto invocador).

Reflita sobre este exemplo básico que ilustra o uso de this em Javascript:

E também considere este exemplo em jQuery:

Explicando melhor o exemplo jQuery anterior: o uso de $( this ), que é a sintaxe da jQuery para esta palavra-chave em JavaScript, é usado dentro de uma função anônima, que é executada no “on click” do botão. A razão pela qual $( this ) está vinculado ao objeto de botão é porque a jQuery vincula $( this ) ao objeto que invoca o método de clique. Portanto, $( this ) terá o valor do objeto jQuery ($( 'button' )) mesmo que $( this ) seja definido dentro de uma função anônima que não pode acessar a variável “this” na função externa.

Importante ressaltar que o botão é um elemento DOM na página HTML e também é um objeto; neste caso, é um objeto jQuery porque está envolvido na função jQuery $().

A maior pegadinha com this em JavaScript

Se você entender este princípio de JavaScript, você entenderá a palavra-chave “this”: não é atribuído um valor a this até que um objeto invoque a função na qual this é definido.

Para fins didáticos, considere onde this está definido como “Função this”. Mesmo que pareça que this se refere ao objeto onde ele é definido, isso só acontece quando um objeto chama a “Função this” a que this está atualmente atribuído. E o valor atribuído é baseado exclusivamente no objeto que invoca a “Função this”.

this tem o valor do objeto sendo invocado na maioria das circunstâncias. No entanto, existem alguns cenários nos quais this não tem o valor do objeto sendo invocado. Cenários estes visto mais à frente.

O uso de this em escopo global

No escopo global, quando o código está sendo executado no navegador, todas as variáveis globais e funções são definidas no objeto window. Portanto, quando se usa this em uma função global, ele se refere a (e tem o valor de) o objeto window global — não no strict mode, como observado anteriormente –, que é o contêiner principal de toda a aplicação JavaScript ou página da web.

Deste modo:

Quando this é mal compreendido e se torna complicado

A palavra-chave this é mais mal compreendida em “métodos emprestados”; quando se atribui um método que usa this para uma variável; quando uma função que usa this é passada como uma função de callback e; quando this é usado dentro de uma closure (uma função interna).

Um pouco sobre “contexto” antes de continuarcontexto em JavaScript é semelhante ao assunto de uma frase na escrita normal. Na frase “João é o vencedor quem devolveu o dinheiro.” o sujeito da sentença é João e é possível afirmar que o contexto da sentença também é João porque o foco da sentença está nele neste momento particular da sentença. Mesmo o pronome “quem” está se referindo a João, o antecedente. E tal como é possível usar um ponto-e-vírgula para mudar o assunto da frase, também é possível ter um objeto que é o contexto atual e mudar o contexto para outro objeto invocando a função com outro objeto.

Similarmente, em código JavaScript:

Ajustando this quando usado em um método callback

As coisas ficam um pouco cabeludas quando passamos um método (que usa this) como um parâmetro para ser usado como uma função de retorno (callback). Por exemplo:

No código acima, uma vez que o botão ($( 'button' )) é um objeto e se está passando o método user.clickHandler() no clique como um callback, sabe-se que this dentro do método user.clickHandler() não mais se refere ao objeto userthis agora se refere ao objeto em que o método user.clickHandler é executado porque este é definido dentro do método user.clickHandler. E o objeto que invoca user.clickHandler é o objeto de botão — user.clickHandler será executado dentro do método de clique do objeto-botão.

Importante observar que, mesmo que se esteja chamando o método clickHandler() através de user.clickHandler (o que é preciso fazer, já que “clickHandler” é um método definido no “user”), o método clickHandler() será executado com o objeto button como contexto para que “this” agora se refere. Então, this agora se refere ao objeto de botão ($( 'button' )).

Neste ponto, deve ser claro quando o contexto muda — quando se executa um método em algum outro objeto do qual o objeto foi originalmente definido, a palavra-chave this já não se refere ao objeto original, no qual this foi originalmente definido, mas se refere ao objeto que invoca o método onde this foi definido.

Solução para corrigir this quando um método é passado como uma função de callback

Como realmente se quer que this.data faça referência à propriedade de dados no objeto “user”, é possível usar os métodos bind()apply() ou call() para definir especificamente o valor de this.

Ao invés dessa linha:

Deve-se usar bind() para clickHandler, assim:

Ajustando this dentro de um closure

Outro exemplo de quando this é mal compreendido é quando se usa um método interno ou closure. É importante observar que closures não podem acessar a função externa dessa variável usando a palavra-chave this porque essa variável é acessível somente pela própria função e não por funções internas. Por exemplo:

this dentro da função anônima não pode acessar o this da função externa, então ele se refere ao objeto global window (quando o strict mode não está sendo usado).

Solução para manter this dentro de funções anônimas

Para sanar a questão, usa-se uma prática comum em JavaScript: atribuir o valor de this a uma variável antes de entrar no forEach:

É bastante comum na comunidade JavaScript escolher o nome “that” para este tipo de “contorno”, caso em que a atribuição da variável (e posteriores referências) ficariam como:

Ajustando this quando método é atribuído a uma variável

Se se atribui um método que usa this a uma variável, o valor de this quase escapa à imaginação. Como em:

Solução para manter this quando um método é atribuído a uma variável

É possível sanar a questão definindo especificamente o valor de this com o método bind:

Ajustando this em “métodos emprestados”

“Métodos emprestados” é uma prática comum no desenvolvimento em JavaScript. Veja o exame da relevância de this no contexto de métodos emprestados.

this do método avg não se referirá ao objeto gameController; ele se referirá ao objeto appController porque está sendo chamado no appController.

Solução para manter this quando um método é atribuído a uma variável

Para corrigir o problema com a garantia de que o this dentro do método appController.avg() se refere a gameController, usa-se o método apply() assim:

O objeto gameController toma emprestado o método avg() de appControllerthis dentro do método appController.avg() será definido para o objeto gameController porque se passa o objeto gameController como o primeiro parâmetro de apply() — o primeiro parâmetro no método apply() sempre define o valor de this explicitamente.

Palavras finais sobre o this em JavaScript

Como visto, this fica um pouco problemático em situações onde o contexto original muda, especialmente em funções de callback, quando invocado com um objeto diferente ou em métodos emprestados. Lembre-se: this é atribuído ao valor do objeto que invocou a função. Mas, ao terminar de ler este artigo, certamente você aprender e/ou revisou o suficiente sobre this em JavaScript e agora tem as ferramentas e técnicas necessárias para trabalhar nos cenários mais inóspitos.

Até lá, bons códigos e boa sorte!


Responsive Components: uma solução para container queries

Conheça Responsive Components, uma solução para componentes responsivos que resolve o problema de Container Queries e pode ser usada imediatamente!

Você já deve ter ouvido falar em Container Queries, uma proposta que permitiria a desenvolvedores web estilizarmos elementos DOM com base no tamanho do elemento contentor (“que contém”) ao invés do tamanho da viewport do navegador. Mas já ouviu sobre Responsive Components?

Se você é um desenvolvedor a par das discussões envolvendo responsividade, provavelmente já ouviu falar sobre Container Queries antes. Desde quando toda a festa de web design responsivo começou, já havia desenvolvedores pedindo por tal recurso (inicialmente Element Queries, depois mudando para Container Queries) — de fato, Container Queries podem ser o recurso CSS mais solicitado que os navegadores ainda não têm.

Já existem muitosmuitosmuitos artigos explicando exatamente porquê container queries são difíceis de fazer no CSS e porquê os fabricantes de navegadores hesitaram em implementá-las. Essa discussão não precisa ser revivida neste post.

Ao invés de focar estritamente na proposta formal de CSS chamada “Container Queries” (Consultas de Contêiner), este artigo abordará o conceito mais amplo de construção de componentes que respondem a seu “ambiente” — responsive components. E se você aceitar esse “enquadramento” maior, realmente já existem novas APIs que permitem que se obtenha isso. Isso mesmo: não é preciso esperar Container Queries chegarem oficialmente para começar a criar componentes responsivos; é possível começar agora!

A estratégia proposta neste artigo permite o uso hoje e é projetada como um aprimoramento, então os navegadores que não suportam as APIs mais recentes ou não executam JavaScript funcionarão exatamente como fazem atualmente. Também é simples de implementar, altamente performática e não requer nenhuma ferramenta especial, bibliotecas ou frameworks.

Para ver alguns exemplos dessa estratégia em ação, existe o site de demonstração Responsive Components, em que cada exemplo aponta para o código-fonte CSS.

Mas antes de começar a realmente ver alguns exemplos, é importante saber como a estratégia proposta funciona.

A estratégia de Responsive Components

A maioria das estratégias/metodologias de web design responsivo funcionam de acordo com estes 2 princípios fundamentais (e aqui não será diferente):

  1. Para cada componente, define-se primeiro um conjunto-base de estilos genéricos que se aplicam independentemente do ambiente em que o componente esteja contextualizado/inserido
  2. Em seguida, definem-se adições ou substituições para os estilos-base que se aplicam em condições ambientais específicas

O poder desses princípios é que eles funcionam mesmo se o navegador não suportar os recursos necessários para cumprir ou permitir condições de ambiente específicas. E isso inclui casos em que o recurso requer JavaScript — usuários com JavaScript desativado obterão os estilos-base e eles funcionarão normalmente.

Na maioria dos casos, os estilos-base definidos no item “1” acima são estilos que funcionam para os menores tamanhos de viewport possíveis (uma vez que viewports menores tendem a ser mais restritivas do que as maiores) e elas não estão envolvidas com nenhum tipo de media query (o que significa que se aplicam em toda parte).

Eis um exemplo que define estilos-base para .MyComponent e depois os substituem em 2 breakpoints arbitrários, 36em e 48em:

Claro, esses breakpoints usam media queries, então eles se aplicam ao tamanho da viewport do navegador. O que os defensores de container queries procuram é a capacidade de fazer algo como isto (nota: esta é a sintaxe proposta; não a sintaxe oficial):

Infelizmente, a sintaxe acima não funciona em nenhum navegador atualmente e não funcioná tão cedo… No entanto, funciona hoje algo mais ou menos como:

Claro, este código assume que os contêineres de componentes têm as classes corretas adicionadas a eles (neste exemplo, .MD e .LG). Mas ignorando esse detalhe por enquanto, a segunda sintaxe ainda faz sentido para qualquer desenvolvedor CSS que quer construir um componente responsivo.

Quer esteja escrevendo uma container query como uma query de comparação de largura (a primeira sintaxe) ou usando classes de breakpoint nomeadas (a segunda sintaxe), os estilos ainda são declarativos e funcionalmente os mesmos. Contanto que seja possível definir breakpoints nomeados, aparentemente não há um benefício claro a favor de um ou de outro.

E para que o restante do artigo fique claro, aqui está o mapeamento das classes/breakpoints (no qual min-width se aplica ao contêiner, não à viewport):

BreakpointLargura do Container
SMmin-width: 24em (384px)
MDmin-width: 36em (576px)
LGmin-width: 48em (768px)
XLmin-width: 60em (960px)

Agora é preciso garantir que os elementos de contêiner tenham sempre as classes de breakpoint corretas; então os seletores de componentes corretos irão corresponder (match).

Observando redimensionamento de contêineres

Quase desde sempre em desenvolvimento web foi possível observar mudanças em window, mas também quase sempre foi difícil ou impossível (pelo menos de uma forma significativa) observar mudanças de tamanho em elementos individuais de DOM. Isso mudou quando o Chrome 64 disponibilizou ResizeObserver.

ResizeObserver, seguindo os passos de APIs semelhantes, como MutationObserver e IntersectionObserver, permite que sejam observadas mudanças de tamanho nos elementos DOM de uma forma altamente performática.

Aqui está um possível código necessário para fazer com que o CSS mostrado anteriormente funcione com ResizeObserver:

Este exemplo usa a sintaxe ES5 porque (como será explicado mais adiante) pode ser interessante inserir este código diretamente no HTML em vez de incluí-lo em um arquivo JavaScript externo. A sintaxe mais antiga é usada para garantir um amplo suporte de navegadores.

O código cria uma instância única de ResizeObserver com uma função de callback. Em seguida, consulta o DOM por elementos com o atributo data-observe-resizes e começa a observá-los. A callback — que é invocada inicialmente após a observação e novamente após qualquer alteração — verifica o tamanho de cada elemento e adiciona (ou remove) as classes de breakpoint correspondentes.

Em outras palavras, esse código transformará um elemento de contêiner com 600px de largura assim:

Para:

E essas classes serão atualizadas automática e instantaneamente sempre que o tamanho do contêiner mudar. Com isso, os seletores .SM e .MD corresponderão (mas não os seletores .LG ou .XL) e esse código funcionará perfeitamente.

Customizando breakpoints

O código na callback de ResizeObserver acima define um conjunto padrão de breakpoints, mas também permite que sejam especificados breakpoints personalizados por componente, passando um JSON através do atributo data-breakpoints.

A estratégia recomendada é alterar o código acima para usar qualquer mapeamento-padrão de breakpoints que faça mais sentido para o projeto que se está trabalhando e, em seguida, especificar inline um conjunto de breakpoints específicos para qualquer componente que precise:

O site Responsive Components tem um exemplo de um componente que configura seus próprios breakpoints juntamente com componentes usando breakpoints padrão.

Lidando com alterações dinâmicas no DOM

O exemplo de código acima apenas funciona para elementos de contêiner que já estão no DOM.

Para sites baseados em conteúdo (content-based sites), isso geralmente é bom, mas para sites mais complexos, cujo DOM muda constantemente, será preciso se certificar de que a observação de todos os elementos de contêiner adicionados dinamicamente está acontecendo.

Uma solução “one-size-fits-all” para este problema é expandir o snippet acima para incluir um MutationObserver que acompanha todos os elementos de DOM adicionados. Esta é a abordagem usada no site Responsive Components, que funciona bem para sites de pequeno e médio porte com modificações de DOM limitadas.

Para sites maiores, com atualizações freqüentes no DOM, já se usa algo como Custom Elements ou algum framework com métodos de lifecycle que rastreiam quando elementos são adicionados/removidos do DOM — se for este o caso, provavelmente é melhor apenas fazer um hook a esses mecanismos.

Por exemplo, um elemento personalizado <responsive-container> poderia ser algo assim:

Embora seja tentador criar um novo ResizeObserver para cada elemento de contêiner, é realmente muito melhor criar um único que observa muitos elementos. Para saber mais, veja as descobertas de Aleks Totic sobre o desempenho do ResizeObserver na lista de discussão blink-dev.

Componentes aninhados

Nas primeiras experimentações com esta estratégia, cada componente não foi envolvido com um elemento de contêiner. Em vez disso, foi usado um único elemento de contêiner por área de conteúdo distinta (header, sidebar, footer etc.) e, no CSS, usados combinadores de descendentes (descendant combinators) ao invés de combinadores de filho (child combinators).

Isso resultou em marcação e estilo mais simples, mas rapidamente se desfez quando se tentou aninhar componentes dentro de outros componentes (o que não é muito raro). O problema é que, com a abordagem do combinador descendente, os seletores corresponderam a vários containers ao mesmo tempo…

Após a construção de alguns demos não-triviais, tornou-se claro que uma estrutura direta filho/pai para cada componente e seu contêiner era muito mais fácil de gerenciar e dimensionar. Observe que os recipientes ainda podem conter mais de um componente, desde que cada um deles seja um descendente direto.

Seletores avançados e abordagens alternativas

Como já explicado, a estratégia descrita neste artigo traz uma abordagem aditiva para estilizar componentes: inicia-se com estilos-base para adicionar mais estilos em seguida. Entretanto, esta não é a única abordagem possível. Em algumas situações, pode ser preciso definir estilos que correspondam exclusivamente e somente se apliquem a um breakpoint específico (ex: ao invés de (min-width: 48em), algo como (min-width: 48em) and (max-width: 60em)).

Se fosse este o caso, seria preciso ajustar um pouco o callback de ResizeObserver para aplicar o nome da classe do breakpoint que corresponde atualmente (currently-matching breakpoint). Então, se o componente estivesse em seu tamanho “grande”, ao invés de definir o nome da classe SM MD LG, seria simplesmente LG.

No CSS, seria possível escrever seletores como:

Importante notar que, ao usar a estratégia para correspondência aditiva, ainda pode haver correspondência exclusiva por meio de um seletor como .MD:not(.LG) — embora a leitura desse seletor seja mais custosa (para humanos e máquinas).

No final das contas, é possível escolher qualquer convenção que faça mais sentido para o projeto em questão; que funcione melhor para a situação concreta que se apresente.

O seletor :matches() ainda não é bem suportado nos navegadores atuais. Mas é possível usar ferramentas como postcss-selector-matches e similares para transpilar em algo que funcione de maneira cross-browser.

Breakpoints de altura

Até agora, todos os exemplos focaram em breakpoints de largura. Não é surpresa, já que a maioria esmagadora das implementações de web design responsivo usam a largura e nada mais (pelo menos quando se trata de dimensões da viewport). Contudo, nada na estratégia apresentada no artigo evitaria que um componente respondesse à altura de seu container, já que ResizeObserver reporta ambas as dimensões.

Portanto, se fosse preciso observar mudanças de altura, seria possível definir um conjunto separado de classes de breakpoints — talvez com um prefixo W- para breakpoints de largura e H- para breakpoints de altura.

Suporte dos navegadores

Na data de publicação deste artigo, ResizeObserver só é suportado no Chrome, mas não há absolutamente nenhuma razão para que não seja possível usá-lo imediatamente. A estratégia descrita aqui é intencionalmente projetada para funcionar bem se o navegador não suportar ResizeObserver ou mesmo se o JavaScript estiver desabilitado.

Em qualquer um desses casos, os visitantes verão os estilos-padrão — que devem ser mais do que suficientes para oferecer uma boa experiência. Na verdade, eles provavelmente serão os mesmos estilos que você já está oferecendo hoje.

A abordagem recomendada é usar media queries para o layout do site e, em seguida, essa estratégia de componentes responsivos para componentes específicos que precisem dele (muitos não irão precisar).

Se for preciso fornecer uma UI consistente em todos os navegadores, é possível usar o polyfill de ResizeObserver, que oferece um excelente suporte (IE9+). Entretanto, certifique-se de que o polyfill seja carregado somente quando for realmente preciso.

Também é importante levar em consideração que polyfills tendem a ser mais lentos em dispositivos móveis e, dado que componentes responsivos importam mais em viewports maiores, provavelmente não é preciso carregar o polyfill se o visitante estiver em um dispositivo com viewport pequena.

O site de demonstração Responsive Components leva em conta esta última abordagem: ele carrega o polyfill somente se o navegador não suporta ResizeObserver e se a largura da viewport é pelo menos 48em.

Limitações e melhorias futuras

No geral, a estratégia de componentes responsivos descrita neste artigo é incrivelmente versátil e tem poucas desvantagens. A partir de agora, é altamente recomendado que sites com áreas de conteúdo cujos tamanhos possam mudar independentemente da viewport implementem uma estratégia de componentes responsivos ao invés de confiar somente em media queries (ou alguma solução JavaScript que não aproveita ResizeObserver).

Isto posto, passemos a algumas limitações que valem a pena serem discutidas.

Não é CSS puro

Uma desvantagem óbvia desta solução é que requer mais do que apenas CSS para ser implementada. Além de definir os estilos em CSS, também é preciso se valer de marcação no HTML e coordenar ambos com JavaScript.

Certamente uma solução baseada em CSS puro é a ideal; é o objetivo final. Mas não há motivos sólidos para impedir o uso desta estratégia hoje.

“Flash of un/incorrectly-styled content”

Na maioria dos casos, é uma prática recomendada carregar todo o JavaScript de forma assíncrona, mas, neste caso, o carregamento assíncrono pode levar os componentes a renderizar inicialmente no breakpoint padrão para depois alternar para um breakpoint maior depois de o JavaScript ser carregado.

Embora esta não seja a pior experiência do mundo, é algo que definitivamente não estaria na lista de preocupações em uma solução de CSS puro. E uma vez que esta estratégia envolve coordenação com JavaScript, também é preciso prestar atenção quando estilos e breakpoints são aplicados para evitar esse re-layout.

Uma das maneiras mais ágeis para lidar com isso é incorporar o código de container query no final dos templates de HTML, garantindo que seja executado o mais rápido possível. Em seguida, adicionando-se uma classe ou atributo aos elementos de contêiner uma vez que sejam inicializados e estejam visíveis para que se saiba quando é seguro mostrá-los (e se certificar de considerar o caso em que o JavaScript está desativado ou cause erros quando executado). É possível ver um exemplo disso no site de demonstração.

As unidades são baseadas em pixels

Muitos desenvolvedores de CSS (se não a maioria) preferem definir estilos com base em unidades com mais relevância contextual (por exemplo: emvh etc.), enquanto o ResizeObserver, como a maioria das API de DOM, retorna todos seus valores em px.

No momento, não há realmente nenhuma boa maneira para contornar isso.

No futuro, uma vez que os navegadores implementem CSS Typed OM (uma das novas especificações CSS Houdini), será possível converter fácil e economicamente entre várias unidades de CSS.

Até lá, o custo de realizar esta conversão provavelmente afetaria o desempenho ao ponto de prejudicar a experiência do usuário.

Conclusão sobre Responsive Components

Este artigo descreve uma estratégia para o uso de tecnologias web modernas para criar responsive components: elementos DOM que podem atualizar seu estilo e layout em resposta a mudanças no tamanho de seu contêiner.

Enquanto as tentativas anteriores de construir componentes responsivos eram valiosas em sua exploração/tentativa, limitações na plataforma significavam que essas soluções eram sempre grandes demais, lentas demais ou ambas. Felizmente, agora existem APIs de navegador que permitem construir soluções eficientes e performáticas.

A estratégia descrita neste artigo:

  • Funciona, hoje, em qualquer site
  • É fácil de implementar (copiar > colar)
  • Tem performance tão boa quando uma solução baseada em CSS puro
  • Não requer bibliotecas específicas ou frameworks
  • Vale-se de aprimoramento progressivo (progressive enhancement): quem não tiver as APIs necessárias ou esteja com JavaScript desabilitado ainda consegue usar o site

A estratégia apresentada neste artigo é “pronta para produção” (production-ready), mas ainda estamos muito nos primeiros estágios da coisa.

À medida que a comunidade de desenvolvimento web começar a mudar o design de componentes de viewport ou orientado a dispositivo (device-oriented) para orientado a contêiner (container-oriented), certamente todos veremos o emergir de possibilidades e melhores práticas até então inimagináveis!


Problemas comuns de WordPress e como resolvê-los

Conheça problemas comuns de WordPress e saiba como facilmente resolvê-los através de soluções simples e eficientes.

Todos os dias há perguntas postadas nos fóruns de WordPress sobre alguns dos problemas mais comuns que novos usuários enfrentam. É fácil de instalar e divertido de trabalhar com WordPress e os novos usuários se animam, rapidmente, com os poderosos recursos oferecidos por muitos de seus plugins e temas.

Eventualmente, os neófitos se deparam com perguntas, questões e problemas que muitos antes deles também já se depararam. WordPress tem uma enorme comunidade global de usuários por trás, então, não importa o problema que um usuário esteja enfrentando, há uma boa chance de que alguns outros usuários já o tenham enfrentado e que já exista uma solução disponível para corrigir esse problema ou responder a essa pergunta.

Neste artigo, vamos discutir alguns desses problemas comuns de WordPress e aprender, através de suas soluções, como resolvê-los.

Consumo de memória do WordPress

Quando um site rodando em WordPress cresce em popularidade e pageviews, o consumo de memória é um dos primeiros (se não, o primeiro) problema que os mantenedores do site enfrentam. Se eles estão em uma hospedagem compartilhada ou um VPS, seus webhosts enviarão e-mails sobre o uso de memória e limite alocado. Pelo menos, os bons hosts farão isso; se for um de baixa qualidade, seu site pode apenas cair e você sequer vai ficar sabendo disso a tempo…

Felizmente, existem diversas soluções para esse problema.

O motivo pode ser um plugin ou tema mal feito rodando. Para descobrir, instale o plugin WP-Memory-Usage. Desative todos seus plugins, exceto o WP-Memory-Usage e, em seguida, vá ativando um por um. Observar como vai ficar o uso de memória depois de ativar cada plugin pode ajudar a descobrir qual(is) é(são) o(s) vilão(ões) da história.

Depois dessa verificação inicial, se os temas e plugins estiverem funcionando dentro do esperado, então pode ser uma ótima ideia instalar um plugin de cache, como W3 Total Cacheou WP Super Cache. Se um plugin de cache não reduzir significativamente a memória com as configurações padrão, será preciso uma configuração mais específica, alterando parâmetros tais como compressão, minify de scripts, aumentar o intervalo dos caches, etc.

Leia estes excelentes artigos (em inglês) sobre como otimizar instalações de WordPress:

Sites em WordPress hackados

Outro problema comum de WordPress é descobrir que seu site foi invadido! As chances de tal coisa acontecer em seu site podem ser significativamente reduzidas seguindo algumas dicas práticas de segurança para WordPress.

Existem diferentes tipos de hacks que os usuários do WordPress enfrentam. O mais comum deles é quando um site redireciona para algum outro site com conteúdos ilegais e/ou obscenos, links injetados para outros sites, códigos estranhos em arquivos de temas, etc. Lembre-se de que, na maioria das vezes, é fácil corrigir esses problemas.

  • Mantenha sempre a instalação do WordPress atualizada com a última versão
  • Faça backups regulares de sua instalação e banco de dados WordPress
  • Execute o WP-Security-Scan, um excelente plugin para detectar códigos suspeitos em seus temas, plugins e arquivos principais do wordPress. Se você encontrar algo suspeito em plugins ou temas, apague! Se você encontrar algo suspeito no core do WordPress, substitua por novos!
  • Verifique regularmente seu arquivo .htaccess por mudanças e códigos suspeitos
  • Leia o artigo “My site was hacked” no Codex do WordPress, peça ajuda em fóruns, peça a ajuda do seu provedor de hospedagem para ter certeza que não aconteceu um ataque em todo o servidor.

Perda da senha de admin e/ou e-mail

É realmente surpreendente quantas pessoas instalam o WordPress e esquecem seus nomes de usuário, senha e e-mail utilizados durante a instalação. Existem várias maneiras de recuperar senha e nome de usuário e é importante conhecer algumas delas.

Recuperar senha do WordPress via PHPMyAdmin

Se você tiver acesso ao banco de dados através do phpMyAdmin, vá até lá e encontre a tabela wp_users. Clique na aba “Procurar” e, em seguida, encontre seu user_login. Clique no ícone “Editar”, à esquerda da linha. Agora você vai ver sua senha encriptada; exclua e substitua por qualquer senha que quiser. Haverá um drop-down “Funções” ao lado. Clique sobre ele e selecione “MD5”. Clique em “Executar” e pronto, você atualizou sua senha!

Recuperar senha do WordPress por FTP

Conecte em seu site via FTP, vá em wp-content/themes/SEU_TEMA. Substitua “SEU_TEMA” com o nome do tema ativo em seu site. Edite o arquivo functions.php (se você não tiver um no seu tema, crie). Adicione esta linha:

Substitua “NovaSenha” com qualquer senha que você quiser. O “1” é o para o user_ID – supondo que você é o admin do site e não excluiu o primeiro usuário que criou durante a instalação.

Faça upload do arquivo editado de volta para o servidor. Agora, faça o login usando a senha que você adicionou no functions.php. Uma vez que você tenha conseguido logado, lembre-se de apagar esta linha de seu arquivo de funções.

Escrevendo código em posts e widgets

Para fazer o WordPress mais seguro e proporcionar um ambiente confiável e consistente, por padrão a plataforma não permite que os usuários insiram códigos nos posts, comentários e widgets. No entanto, depois de algum tempo a maioria dos novos usuários se sente confortável o suficiente com o WordPress para querer adicionar funcionalidades diferentes nessas áreas.

Por exemplo, para mostrar os códigos deste artigo, não é possível simplesmente colar o código. Ele seria retirado pelo WordPress e não seria mais legível.

Adicionando código nos posts do WordPress

Codex do WordPress sugere o uso de entidades HTML para escrever código, mas esta é uma forma muito custosa de se fazer isso. Então, se você pretende compartilhar regularmente trechos de código com os visitantes de seu website, então você precisa de algum plugin específico, tal como o Syntax Highlighter Evolved.

O plugin permite escrever código em seus posts e estilizar códigos com shortcodes. É muito fácil de usar, personalizável e suporta várias linguagens incluindo PHP, JavaScript, HTML e CSS.

Adicionando código nos widgets da barra lateral

Também pode haver a necessidade de exibir trechos de códigos em Widgets ou adicionar uma função ou tag em um widget. Para isso, é possível instalar algum plugin, como PHP Code Widget ou Widget Logic.

Conclusão

Certamente, deve haver outras perguntas comuns, questões e problemas que os novos usuários de WordPress muitas vezes se deparam. A primeira coisa a se fazer quando se deparar com qualquer problema com seu site WordPress é pesquisar.

Faça buscas usando diversos termos e você vai ver que muitas pessoas já forneceram soluções para esses problemas de WordPress. Se não, você pode sempre fazer perguntas no Fórum WordPress, IRC e outros fóruns WordPress relacionados.

E você, conhece algum problema comum de WordPress e a solução adequada?


Pixels, pixels ou pixels? Dicas de Web Mobile com viewport

Foi-se o tempo em que pixel significava apenas o menor ponto na tela. Bastava dizer que uma imagem tinha 200px, e então ela ocuparia 200 pontos, ou seja, 25% de uma tela de tamanho padrão 800×600.

Mas o mundo mobile mudou completamente o jogo e, hoje, o conceito de pixel pode significar várias coisas.

(Atualização: escrevi mais detalhadamente sobre esses aspectos dos pixels diferentes e viewport, incluindo telas retina, no meu livro A Web Mobile, publicado pela editora Casa do Código. Se você estuda design responsivo, sites mobile, e assuntos relacionados, vai gostar desse livro.)

Os primeiros Smartphones

Era muito comum que os smartphones da Nokia lá pelos idos de 2007 tivessem uma resolução de 240×320 pixels, como um N95.

Quando surgiu o primeiro iPhone, sem teclado e só touch, a Apple decidiu explorar um tamanho maior de tela, 320×480 pixels. Era o dobro dos pixels normalmente usados na época, com um tamanho físico mais ou menos também com o dobro do tamanho.

Esses valores representam o tamanho físico do aparelho, o número de pixels físicos existentes. Na prática, um iPhone conseguia exibir páginas com mais que 320 pixels de largura. O truque era trabalhar com a ideia de zoom.

Na imagem anterior, abrimos o site da Caelum, que tem 960px de largura, em um iPhone de 320px. Repare como, apesar de menor, o Site está sendo renderizado corretamente.

Mas nosso HTML e CSS não foi codificado pensando em 320px, e sim em 960px. Quando colocamos a imagem do logotipo, por exemplo, nosso HTML diz <img src=".." width="160" height="50">. E, obviamente, o logo não está sendo renderizado a 160px, senão ocuparia metade da tela de 320px do iPhone. Se você medir, verá que o logo está sendo renderizado em mais ou menos 52px, ou 1/6 da tela do iPhone.

CSS pixels e o layout viewport

Repare que usamos uma medida de pixels no HTML/CSS que difere do pixel real usado na tela. O navegador do iPhone, na verdade, se comporta como se tivesse 980px de largura, embora o aparelho tenha apenas 320px. Isso é feito para que o usuário possa ver páginas feitas para Desktop sem problemas.

Nossa página funciona como se tivéssemos 980px disponíveis. Quando escrevemos “245px” no CSS, estamos nos referindo a 1/4 dessa tela imaginária de 980px. Na hora de exibir, porém, os 980px serão encaixados nos 320px reais, aplicando um zoom out.

Essa tela imaginária de 980px é o que chamamos de layout viewport. É o tamanho com o qual trabalhamos no nosso HTML/CSS, sem nos preocuparmos com a renderização no aparelho. Repare que um pixel no layout viewport tem outro significado do pixel físico do aparelho. É comum chamá-lo de CSS pixel.

Zoom e o visual viewport

Mas navegar no celular nessa página gigante sem zoom é praticamente impossível. A grande diferença da navegação mobile com a Desktop é o frequente uso do zoom e o scroll em todas as direções.

Na imagem acima, demos um zoom para ver mais detalhes. Repare que a o layout da página continua o mesmo. Um elemento de “245px” continua ocupando 1/4 do total do nosso layout viewport. A diferença é que, agora, só estamos visualizando uma parte do layout viewport; o restante está fora da tela, e precisaríamos fazer scroll para ver.

Isso nos leva para outro conceito importante: o visual viewport, que representa o tanto do layout viewport que conseguimos visualizar no momento.

Geralmente não estamos interessados no tamanho do visual viewport. Lembre que os CSS pixels são sempre relativos ao layout viewport.

Sites mobile e a meta tag viewport

Abrir um site Desktop no celular é uma experiência pouco agradável. Frequentemente, vamos querer criar uma página otimizada para mobile, que não demande tanto zoom e já mostre o conteúdo em tamanho e formato interessantes para uma tela tão pequena.

Como fazer? Obviamente, não podemos deixar a página com layout fixo em, por exemplo, 960px. Podemos tentar um width:100% no elemento principal, pensando em se adaptar a diversos tamanhos de tela.

Nosso layout viewport é considerado como 980px e o site é mostrado como se fosse de Desktop, com zoom mínimo e conteúdo praticamente ilegível. Que tal colocar width:320px, o tamanho real do dispositivo?

O layout viewport continua em 980px mas o conteúdo fica em 320px. O usuário precisa dar zoom para visualizar e, pior, a página fica com um imenso espaço em branco.

O que precisamos é uma forma de redimensionar o layout viewport para que ele seja mais adequado a tela pequena do mobile. A Apple introduziu uma meta tag viewport no iPhone que, depois, foi adotada em praticamente todas as plataformas móveis – Android, Opera, Windows Phone etc.

<meta name="viewport" content="width=320">

Isso indica ao navegador que o layout viewport deve ser 320px. Agora, colocar width:100% vai significar 320px, deixando a visualização mais confortável.

Viewport flexível com device-width

Deixar “320” fixo na nossa tag de viewport pode não ser uma boa ideia. Há diversos aparelhos diferentes no mercado, cada um com tamanho diferente. E mobile agora também inclui tablets, como o iPad, que tem largura de 800px.

É possível deixar a meta tag viewport com tamanho flexível, baseado no tamanho do aparelho. Basta usarmos:

<meta name="viewport" content="width=device-width">

Isso assumirá o valor, por exemplo, de 320px no iPhone e 800px no iPad. Outros aparelhos poderão assumir outros valores.

Altíssimas resoluções

Antes de aparecerem os Androids de alta resolução e, depois, o iPhone 4, toda a história dos pixels se resumia a diferença entre os CSS pixels e os device pixels. Isso porque um device pixel no iPhone clássico significava um pixel físico na tela.

A retina display mudou isso. O iPhone 4 passou a vir com resolução de 640×960 pixels, melhorando a renderização de textos e imagens. Outros celulares foram até além. O Galaxy Nexus, por exemplo, tem resolução HD de 720x1280px.

Como ficam nossas páginas mobile então que assumiam uma resolução bem menor? Com resolução tão alta quanto um Desktop, os celulares mais modernos vão renderizar as páginas bem pequenas, como um site Desktop? Nossas páginas continuam funcionando porque esses dispositivos de alta resolução continuam reportando um device-width de 320px, pra manter a compatibilidade.

A ideia de reportar um device-width diferente do tamanho de pixels físicos surgiu no Android e depois foi copiada pelo iOS e outras plataformas.

Dessa forma, conseguimos evoluir a resolução da tela com densidades de pixels maiores (dpi) sem afetar a forma como o usuário usa nosso Site mobile, que continua otimizado para telas pequenas.

Os três pixels

Um pixel, pode então, representar três conceitos diferentes quando lidamos com mobile:

Pixel físico: número real de pixels na tela. Nos celulares modernos, é um número altíssimo, com ótima resolução, geralmente com densidade acima de 300 dpi.

Device pixel: é o número de pixels reportado pelo aparelho como sendo seu tamanho. É pensado pra ser um valor que ofereça conforto visual para o usuário olhando para aquele tamanho de tela. É comum que esse valor seja 320px em celulares, copiado do iPhone original.

CSS pixel: é o que usamos no HTML/CSS como px, representando um tamanho dentro do layout viewport. Quando colocamos a meta tag viewport com valor width=device-width, estamos dizendo que nosso CSS pixel é igual a um Device pixel.

Hoje, no Desktop, esses três pixels são equivalentes**. Mas, em breve, teremos que lidar com esse tipo de diferença também no Desktop com a chegada das telas de alta densidade também aos computadores.

Lidando com zoom

Mesmo otimizando nossa página para 320px, o usuário ainda pode dar zoom na página. Em alguns cenários, pode ser interessante desabilitar o zoom, o que pode ser feito na tag viewport com user-scalable:

<meta name="viewport" content="width=device-width, user-scalable=no">

De maneira geral, é interessante deixar o usuário dar zoom caso queira, já que este é um gesto comum ao usar a Web no celular. Podemos, porém, controlar os níveis de zoom com as propriedades minimum-scale e maximum-scale:

<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=4">

O código acima indica que o usuário pode aumentar até 4x a página e diminuir até pela metade.

Podemos controlar também o nível padrão de zoom quando a página é aberta, com initial-scale:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

O valor 1.0 é muito comum quando trabalhamos com device-width e significa o zoom padrão. Se tivermos uma página Desktop não otimizada pro viewport de mobile, podemos usar essa propriedade para controlar o zoom inicial (lembre que o inicial é mostrar todo o layout viewport de 980px, o que pode não ser interessante).

Por fim, é importante citar um bug do iOS que afeta o zoom e o viewport quando rotacionamos o dispositivo em uma página com width=device-width que permita zoom. Se você abre a página no modo retrato, ele vai assumir o scale como 1.0, deixando o visual viewport igual ao layout viewport. Ao rotacioná-lo para modo paisagem, o dispositivo mantém o visual viewport no valor antigo, mas aumentando o layout viewport. Na prática, a página dá zoom automático e o lado direito da página não fica visível. O usuário, que não deu zoom, precisa diminuir o zoom para ver tudo.

É um bug famoso que acontece só no Mobile Safari do iOS, não existindo no Android e outras plataformas. A solução mais direta é desabilitar o zoom por completo, algo que é feito em diversos sites mobile por causa desse bug. Mas não é a solução ideal, já que poder dar zoom é uma feature que interessa ao usuário mobile. Existem alguns hacks para tentar resolver esse problema no iOS.

Conclusão

Trabalhar com telas diferentes é um grande desafio. O uso da meta tag viewport procura facilitar a padronização das páginas nos mais diversos tamanhos de telas e densidades de pixels. Compreender os diferentes significados de viewports e pixels é essencial para se desenvolver para mobile.

E, usando ainda media queries, podemos criar páginas que se adaptem facilmente a diversos dispositivos.

O curso WD-43 da Caelum, de desenvolvimento Web, trata também de tópicos de Web Mobile. Mostramos o uso do viewport e media queries para criação de uma página responsiva. Além disso, meu livro A Web Mobile, aprofunda em diversos assuntos de design responsivo e aspectos técnicos de sites para dispositivos móveis.

Referências

** No Desktop, quando damos zoom numa página, também temos a complicação dos viewports diferentes e a diferença entre CSS pixels e device pixels. Mas, na prática, todo mundo ignora e assume zoom de 100%, onde os CSS pixels são iguais aos device pixels.


Missões de manutenção do site
Mantenha seu negócio on-line funcionando sem problemas com um controle mensal dessas áreas cruciais
Recentemente, eu estava na concessionária de automóveis assistindo o trabalho de mecânica no meu carro, e de repente um pensamento me pareceu: quantos proprietários de empresas on-line verificam regularmente sob o capô para garantir que seus sites estejam funcionando sem problemas?

E mesmo que você faça exames freqüentes no seu site, você tem certeza de que está dando uma resposta completa? Cerca de uma vez por mês, você deve “pular o capuz” para realizar um check-up abrangente, encontrar o que não está funcionando e consertá-lo. Aqui está o que você deve procurar:

Estatísticas de tráfego O
seu host deve fornecer estatísticas básicas, mas considere obter o programa gratuito do Google Analytics ou usar os serviços de uma empresa de análise de internet baseada em taxas – você terá uma visão mais profunda de como seus visitantes viajam através do seu site. Você deve ser capaz de responder as seguintes perguntas:

  • Em quais páginas seus visitantes deixam seu site? Por exemplo, eles abandonam seu site na página da ordem sem fazer um pedido? Em caso afirmativo, talvez haja um problema com o processo de check-out.
  • Quanto tempo os visitantes gastam no seu site e em cada página individual? Se eles visitam sua página inicial e depois saem quase que imediatamente, obviamente você não está chamando sua atenção.
  • Como seus visitantes o acham? São sites particulares que enviam muito tráfego ao seu lado? Você pode aproveitar isso de alguma forma em parceria com eles? A maioria de seus visitantes vem de um motor de busca específico? Em caso afirmativo, qual poderia ser o motivo disso – e como você pode contrariar o tráfego de outros motores de busca? Quais palavras-chave e ofertas em seus anúncios de pagamento por clique estão melhorando? Você pode incorporá-los em outros lugares em seu site?
  • O que está causando picos de trânsito? De onde vêm os visitantes? Existe um novo link apontando para o seu site? Uma campanha de e-mail ou anúncio de PPC é particularmente bom? Poderia haver uma razão sazonal? Como você pode fazer isso uma ocorrência regular?
  • Onde vivem os seus visitantes? Se houver muito interesse de um determinado local, você pode ajustar seu site para atender especificamente a essas pessoas (por exemplo, oferecendo serviços em outro idioma)?
  • Quais termos de pesquisa e palavras-chave resultam na maior parte do tráfego para o seu site? Você pode colocar mais destes – ou outras palavras-chave semelhantes – em seu código e conteúdo para atrair ainda mais tráfego?

Estatísticas de vendas O
tráfego é bom, mas as vendas fazem você ganhar dinheiro. Acompanhe suas taxas de conversão – a porcentagem de seus visitantes que realmente se tornam clientes pagantes. Muitas rotas com poucas conversões indicam que existe algum tipo de desligamento entre a mensagem que leva as pessoas ao seu site e a mensagem que eles estão a ver quando chegarem lá. Olhe para onde você perde essas pessoas e você verá por onde começar a ajustar e testar. O menor tráfego com altas conversões significa que você está fazendo as coisas certas no seu site e você precisa se concentrar em obter mais tráfego.

Taxas de resposta por e-mail
Verifique sempre seus números de tráfego e vendas cuidadosamente após cada envio de e-mail. Você pode descobrir quais linhas de assunto e ofertas promocionais estão funcionando melhor para você, e mesmo quais horas do dia, semana e ano são melhores para seus e-mails.

O e-mail ainda é uma das técnicas de marketing mais eficazes, e você aproveitará o máximo se você automatizar todas essas tarefas de e-mail desde o início. Um sistema de gerenciamento de e-mail como iContact economizará tempo e fornecerá resultados detalhados em um formato amigável para que você possa facilmente analisar o que está funcionando e o que precisa funcionar.

Manutenção geral
Aqui estão algumas outras coisas relacionadas ao seu site que você deve observar de perto:

  • Verifique se há links quebrados e outras falhas técnicas em seu site. As Ferramentas do Google para webmasters podem ajudar com isso. Outro bom recurso para verificar links quebrados e outros fatores que afetam o desempenho do seu site – como a velocidade de carregamento do seu site – é o Sitereportcard.com .
  • Procure palavras-chave relevantes para sua indústria para ver se o seu site aparece nos resultados da pesquisa.
  • Verifique os sites dos seus concorrentes regularmente para ver se eles estão executando promoções especiais ou têm novos produtos. Se você realmente deseja ver seu funcionamento interno, você pode usar uma ferramenta paga como KeywordSpy ou iSpionage para ver quais palavras-chave estão usando e onde. E certifique-se de se inscrever para seus boletins informativos ou feeds RSS – é uma ótima maneira de manter a guia sobre o que eles estão fazendo.
  • Procure na web frases aleatórias das páginas do seu site para se certificar de que ninguém esteja usando seu conteúdo sem voltar para você.
  • Procure no nome da sua própria empresa e URL para ver se alguém está dizendo algo ruim sobre você.

Um mau funcionamento no seu site pode ser tão prejudicial para o seu negócio como uma falha de freio seria para o seu carro. Idealmente, você deve reservar um dia a cada mês para realizar uma revisão importante do site. Isso manterá seu negócio funcionando tão bem como um motor bem oleado.


Saiba mais sobre Wireframes antes de contratar um desenvolvedor da Web
Você deve explicar sua visão se você espera que seu desenvolvedor web compartilhe sua visão.
As opiniões expressas pelos contribuintes empresariais são próprias.

Como alguém que esteve em ambos os lados do contrato, como freelancer e como cliente, uma das coisas mais bem vindas que você pode fazer para um freelancer é ajudá-los com seu trabalho de forma significativa.

Você é o cliente do inferno?

Quando se trata de desenvolvimento web, isso significa duas coisas. Primeiro, leia os Clientes do Inferno e se esforça para nunca ser “esse cara”. Em segundo lugar, esteja pronto para apresentar seu desenvolvedor web com um wireframe.

Quando digo a palavra wireframe, o que você imagina? Se você está pensando em CGI e modelos poligonais dos anos 80, você está um pouco fora da marca. Um wireframe de design web é como esse esqueleto poligonal, mas para um site.

O que é um wireframe?

É um layout gráfico e design que não exige nenhuma codificação, manipulação de imagem, ou mesmo mais do que colocar um lápis em uma folha de papel quadrado. Basta verificar alguns desses exemplos .

Um wireframe é uma ferramenta incrivelmente útil para um desenvolvedor web. Isso mostra exatamente o que você tem em mente e dá-lhes uma idéia da escala de vários elementos, os elementos cruciais que você deseja incluir em suas páginas. O wireframe é uma espécie de truque de codificação que eles podem precisar para implementar para que tudo aconteça.

Desta forma, você não os surpreende com “oh, e por sinal, eu quero a navegação na barra lateral” ou “hey, na verdade, você pode fazer essa imagem estática uma apresentação de slides?”

Você economizará tempo, você economizará dinheiro e você salvará o sangue, o suor e as lágrimas de você e seu desenvolvedor web.

Mas espere! Eu estou assustado.

Se você tem medo da complexidade de um wireframe, não se preocupe com isso. Você não precisa fazer um design em escala completa de todas as páginas em seu site. Tudo o que você realmente precisa são os princípios básicos. Você quer saber onde você terá sua navegação e qual o tipo de layout que deseja para as páginas do produto.

Você quer um par de detalhes sobre quantos slots extras você precisa para miniaturas de artigos ou outros produtos relacionados. Alguns dos wireframes da galeria acima são muito simples, não mais do que um punhado de caixas aninhadas em outras caixas, mas ainda é suficiente para um desenvolvedor web começar.

Além disso, lembre-se, faz parte do trabalho do desenvolvedor para ajudá-lo a refinar o design. Eles podem dizer-lhe “hey, este design é um pouco confuso, e se cortarmos isso e mudarmos para lá?”

O design moderno é uma chave.

Eles podem dizer-lhe que os padrões de design modernos sugerem que você não deveria ter sua navegação no lado direito na calha. Eles podem usar seu wireframe como base. Apenas corta as primeiras cinco ou seis fases de prototipagem de ida e volta, o desenvolvedor normalmente teria que passar para chegar a este estágio com você.

Os wireframes também são muito fáceis de criar, desde que você tenha e mantenha uma visão do que você deseja que seu site pareça. Eu já disse que você pode colocar um lápis em uma folha de papel e fazer um, mas você também pode usar uma das dezenas de aplicativos lá fora.

O padrão da indústria que encontrei é o Balsamiq, que é livre para tentar e barato para comprar. Ou você pode usar outras ferramentas como Wireframe.cc, Moqups ou UXPin para soluções baseadas na web.

Se preferir trabalhar a partir de um tablet ou dispositivo móvel, o OmniGraffle funciona no iOS, o Wire Flow funciona no Android e o Fluid UI funciona em ambos.

Tudo o que você faz é um processo.

Na verdade, não é tão difícil quanto parece – ou soa. Lembre-se, produzir qualquer coisa é um processo iterativo. Passando de uma idéia para um esboço, de um esboço para um wireframe, de um wireframe para um projeto mais detalhado, e de lá para um protótipo é típico.

Qualquer quantidade de ajuda que você possa trazer para o seu desenvolvedor percorrerá um longo caminho – e confie em mim – é muito apreciada.


Novo Firefox funciona como um coelho

Novas versões de versões dos navegadores não recebem o zumbido que costumavam obter, mas o Firefox Quantum é uma exceção.

A última versão do navegador da Fundação Mozilla, lançado na terça-feira, é tudo sobre desempenho. O Firefox é duas vezes mais rápido que o ano passado, afirmou a Mozilla. Não é apenas rápido na inicialização – permanece zippy mesmo quando tributado por várias abas.

“Temos um melhor equilíbrio de memória com o desempenho do que todos os outros navegadores”, disse o vice-presidente do Firefox, Product Nick Nguyen.

“Nós usamos 30 por cento menos memória, e o motivo disso é que podemos alocar o número de processos que o Firefox usa em seu computador com base no hardware que você possui”, disse ele à TechNewsWorld.

$ 1 milhão de experiência em US $ 300 para laptop

As melhorias de desempenho em Quantum podem ser uma bebida da fonte da juventude para muitos sistemas de usuários do Firefox. “Um número significativo de nossos usuários estão em máquinas com dois núcleos ou menos, e menos de 4 gigabytes de RAM”, explicou Nguyen.

O aumento de desempenho pode ser atraente para outros usuários também.

“Nós temos um ótimo navegador para você, mesmo que você não tenha o computador mais recente”, disse Nguyen. “Nós vemos uma grande oportunidade para pessoas com US $ 300 laptops ter uma excelente experiência moderna”.

O público-alvo da Quantum provavelmente é proprietário de PCs mais antigos que sentem a maior dor no momento, disse Rob Enderle, analista principal do Grupo Enderle .

“A geração atual de navegadores avançados é bastante intensiva em recursos, o que retarda as máquinas e cria atrasos que os usuários acham realmente irritantes”, disse ele à TechNewsWorld.

Além das melhorias sob o capô, a Mozilla redesenhou a interface do usuário do Firefox.

“Chamamos essa iniciativa” Photon “, e seu objetivo é modernizar e unificar tudo o que chamamos de” Firefox “, enquanto aproveitamos o novo e rápido mecanismo”, escreveu Mark Mayo, vice-presidente sênior do Firefox, em uma publicação online.

“Para criar o Photon, nossa equipe de pesquisa de usuários estudou como as pessoas navegavam na Web”, explicou. “Nós olhamos para o hardware do mundo real para tornar o Firefox ótimo em qualquer exibição, e nós nos certificamos de que o Firefox parece e funciona como o Firefox independentemente do dispositivo que você está usando”.

Momento fortuito?

Além de anunciar o lançamento da Quantum, a Mozilla informou na terça-feira que fez do Google seu provedor de busca padrão nos Estados Unidos e no Canadá.

As receitas dessa parceria devem beneficiar a Mozilla.

“Esperemos que ele ajude a continuar seus esforços de desenvolvimento e construir o motor Quantum”, disse Ross Rubin, analista principal da Reticle Research .

O lançamento de Quantum pela Mozilla foi uma jogada defensiva, ele disse à TechNewsWorld. “É para evitar uma nova erosão da base de usuários do Firefox, que teve um forte sucesso nos últimos anos”.

O Quantum poderia fazer mais por Mozilla do que simplesmente evitar defecções do Firefox, manteve Charles King, analista principal da Pund-IT .

“A Quantum parece ser projetada para trazer usuários anteriores, que abandonaram a Mozilla em última análise para o Google Chrome, de volta ao Firefox”, disse ele à TechNewsWorld.

“A chegada de Quantum também coincide com o que parece um crescente descontentamento entre os usuários do Google Chrome e o Microsoft Edge”, acrescentou King. “Em outras palavras, não poderia haver um tempo melhor para a Mozilla para apresentar um novo navegador inovador”.

Tough Browser Market

Mesmo com vantagens de desempenho, a Quantum terá dificuldade em conquistar o compartilhamento de navegador do líder Chrome, que possuía cerca de 47% do mercado de desktop a partir do mês passado, de acordo com números do NetMarketShare.

Com 6,53 por cento do mercado, o Firefox foi um terceiro distante, por trás do Microsoft Internet Explorer com 12,52 por cento.

“O novo Firefox Quantum é consideravelmente mais rápido, o que foi um grande problema para o antigo Firefox”, disse Greg Sterling, vice-presidente de estratégia e visão da Local Search Association .

“Comparado com o Chrome, o antigo Firefox era muito lento, então esta é uma melhoria real”, disse ele à TechNewsWorld.

“O desafio será conquistar os usuários que desertaram para o Chrome – além dos que são filosóficamente opostos ao Google”, afirmou Sterling. “Eu suspeito que veremos uma melhoria incremental no compartilhamento de mercado do Firefox, mas esse lançamento não mudará as coisas drasticamente”.


Campus Party 2018 traz fundador da Apple, discussão sobre bitcoin e batalha de drones

A 11ª edição do evento acontece entre 31 de janeiro a 4 de fevereiro, no Anhembi, em São Paulo; Neste ano, 12 mil pessoas acamparão no local.

Campus Party, o maior evento de tecnologia e cultura nerd da América Latina, levará para São Paulo de discussões sobre a tecnologia por trás do bitcoin e sobre como a tecnologia pode fazer a diferença na sala de aula, além de palestras de peso, como a de Steve Wozniak, que fundou a Apple com Steve Jobs. Uma das novidades neste ano para quem visita a área aberta do evento é a batalha de drones, em que os pilotos tentam derrubar as aeronaves dos rivais

A 11ª edição da Campus Party ocorre no Pavilhão de exposições do Anhembi, em São Paulo, entre 31 de janeiro a 4 de fevereiro. Neste ano, 12 mil pessoas acamparão no local.

A expectativa da organização é que o número de visitantes chegue a 100 mil. A capacidade total de conexão, um assunto sensível para campuseiros, será de 40 Gibabits por segundo. Pela primeira vez, haverá áreas com Wi-Fi e monitoramento para evitar ataques hacker.

“Aqui a gente monta a internet de uma cidade inteira em coisa de um dia”, brincou Franceso Farruggia, presidente do Instituto Campus Party.

Francisco Farruggia, presidente do Instituto Campus Party, durante apresentação da programação 2018 (Foto: Helton Simões Gomes/ G1)Francisco Farruggia, presidente do Instituto Campus Party, durante apresentação da programação 2018 (Foto: Helton Simões Gomes/ G1)

Francisco Farruggia, presidente do Instituto Campus Party, durante apresentação da programação 2018 

Bitcoin e Blockchain

Boa parte da programação de oficinas e palestras da Campus Party será dedicada a discutir o bitcoin, a moeda virtual que passou a chamar a atenção do mundo ao se valorizar mais de 1000% em 2017 e chegar próxima da cotação de US$ 20 mil. Só que o objetivo não será analisar se a criptomoeda enfrenta uma bolha especulativa ou não, debate que dominou o mundo financeiro em 2017.

O foco será a “blockchain”, a tecnologia por trás do bitcoin, que funciona como um livro contábil em que todas as transações com a moeda são registradas de forma segura e confiável. Don Tapscott, um dos principais palestrantes desse ano, subirá ao palco para falar sobre isso. Ele é autor do livro “Blockchain Revolution: How the Technology Underlying Bitcoin is Changing Business, Money and the World” (“Revolução Blockchain: Como a Tecnologia Sustentando o Bitcoin está Mudando Negócios, Dinheiro e o Mundo”).

Boné para tirar sono

Alguns dos eventos são levados à Campus Party por patrocinadores, como Petrobras, Visa, TV Globo e Ford. “Vocês poderiam se perguntar por que uma montadora de 115 anos está aqui. E eu poderia passar o dia inteiro falando disso. A gente veio porque aqui é um celeiro de tecnologia e inovação”, afirmou Fernão Silveira, diretor de comunicação para América Latina da Ford, que vai expor um Mustang 5.0 GT, modelo que a empresa começa a importar agora para o Brasil.

A montadora mostrará algumas de suas tecnologias, como seus serviços conectados para carros e até um boné que faz caminhoneiros que estiverem dirigindo ficarem acordados.

Drones, games e educação

Apesar de palestras e workshops serem feitos em uma área de acesso restrito aos campuseiros, há atividades na área aberta da Campus Party.

Em uma arena ocorrerá o campeonato brasileiro de drones, em que pilotos profissionais usam todas suas habilidades para correr mais rápido que os adversários. Lá também os visitantes do evento poderão participar de duelos de drones. Durante eles, a velocidade fica em segundo plano e o objetivo é derrubar a aeronave dos rivais.

Em outro espaço, ocorrerá torneios de games como “Dragon Ball Z”, “Counter Strike”, “Injustice 2”, entre outros.

Outra novidade de 2018 da Campus Party é uma nova área de atuação: a educação. Haverá oficinas de robótica para crianças e adolescentes e batalhas de robôs virtuais.

Simuladores

Também na área aberta, a Campus Party reunirá 8 simuladores, como asa delta a kart, por exemplo. O destaque fica por conta do MotionSphere, um simulador de sensações vivenciadas por pilotos de aviões super-rápidos. Ele é capaz de imitar acelerações, curvas e impactos de até sete vezes a força da gravidade.

Startups e universidade

Outra área a que os visitantes poderão ir e que já esteve presente em outras edições da Campus é a Startup & Makers. Nela, 120 empresas iniciantes de tecnologia mostrarão como funcionam seus negócios, em busca de parcerias e até de investidores.

Já na Campus Future, estudantes universitários expõem protótipos de novas tecnologias criadas a partir de suas pesquisas.


5 IDEIAS DE NEGÓCIOS DIGITAIS PARA VOCÊ COMEÇAR DO ZERO

Quem não sonha em ter seu próprio negócio e faturar muito dinheiro sem sair de casa? E o melhor de tudo, sem ter que investir muito dinheiro. Muitos brasileiros sonham em deixar de ser assalariado, e os negócios digitais são uma ótima alternativa para tornar esse sonho, realidade.

Pois saiba que a internet oferece várias opções, basta você escolher o negócio que melhor se encaixa no seu perfil. Justamente por isso o meu objetivo no post de hoje é lhe apresentar algumas ideias de negócios online para te ajudar nessa escolha.

VEJA AGORA 5 IDEIAS DE NEGÓCIOS DIGITAIS PARA VOCÊ COMEÇAR DO ZERO

1 # Criação de Blogs

Atualmente esse é um dos negócios digitais mais rentáveis da internet. Você já deve ter visto vários blogueiros de sucesso que ganham muito dinheiro nesse meio. Quantas vezes você já se perguntou como eles conseguem faturar com uma página na internet?

Na verdade, o lucro está nos anúncios exibidos na página. Quando o usuário clica, o webmaster já está ganhando.

Além disso, hoje muitos blogueiros faturam alto promovendo produtos de outras empresas, marcas e até mesmo pessoas comuns, tudo isso através do Programa de Afiliados, conforme veremos mais a diante.

Mas o primeiro passo é buscar um nicho de mercado que seja rentável e que ao mesmo tempo lhe traga satisfação pessoal. Isso porque a motivação é muito importante para conseguir dar sequência as estratégias de marketing digital necessárias para gerar tráfego no blog e ter sucesso no mercado dos negócios online.

Quando falamos em marketing digital, é importante salientar que se trata de um processo que requer planejamento e tempo.

É fundamental que o nicho de sua escolha seja um tema que você tenha certo domínio ou interesse, para que assim essa experiência não seja monótona e cansativa, isso garante maior facilidade para tratar dos assuntos referentes ao blog.

Além disso, é preciso estudar muito o mercado e o público com quem você vai trabalhar no blog. Alguns empreendimentos digitais de sucesso tratam de temas referentes a dieta, fitness, culinária, beleza, negócios, etc.

2 # Criação de Vídeos para a internet

O primeiro passo para montar um bom vídeo é planejar e definir um assunto interessante e pesquisar seus detalhes. O conteúdo precisa ser original e relevante para atrair a atenção do público.

Organize a estrutura do vídeo como se fosse um roteiro de filme, com começo, meio e fim. O ideal é colocar tudo no papel para as ideias ficarem mais claras.

A criação de vídeos para a internet é um dos negócios digitais mais rentáveis atualmente, isso porque os internautas acessam diariamente milhões de vídeos no Youtube. Inclusive esse canal é o mais famoso para expor gravações.

Uma boa dica é ver outros vídeos que tratem do assunto que você deseja abordar.

Observe quais são os mais visualizados e se inspire. Pode ser vídeos engraçados, tutoriais, cursos, etc. Quanto mais criatividade e habilidade você tiver na criação de vídeos, melhor será o desempenho da sua publicação.

Realizar vídeos com imagens e áudio também é uma boa opção para prender a atenção dos visitantes.

Outra tendência em negócios pela internet é desenvolver vídeos institucionais animados para exibir produtos, uma teoria ou um conceito com criatividade e relevância. Para isso basta ter familiaridade com programas de animação para criar bons vídeos de divulgação.

 

3 # Comércio eletrônico

Mais uma ideia de negócios digitais é abrir uma loja virtual para vender algum produto pela internet.

Atualmente existem também Franquias Virtuais que permitem que você tenha o seu próprio negócio com um baixo investimento, como esta que eu fui franqueado e super recomendo Clicando Aqui.

Mas, caso você não pretenda correr o risco de investir em um empreendimento de alto nível, você pode abrir uma loja virtual de forma gratuita.

Primeiro, selecione os produtos que pretende comercializar e desenvolva um catálogo online. Organize as fotos e a descrição dos produtos para tornar a página mais completa e atraente aos usuários.

É essencial oferecer bastante dados sobre o produto e as maneiras de entrega. Seja específico ao determinar o conteúdo da loja para ganhar espaço nesse mercado de comércio eletrônico.

Assim como outros negócios online, trata-se de um mercado competitivo que exige estratégias bem definidas para o empreendedor conseguir alcançar seus objetivos em venda.

Lembre-se de estabelecer um planejamento para conseguir atingir suas metas. Acesse o site da LCF Host para saber mais sobre loja virtuais e Blogs desenvolvimento seguro e profissional clique aqui


Página 1 de 212