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
Blog | Página 2 de 8 | LCF HOST

Blog


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!


Mitos de interface mobile – Mito 2: sites móveis requerem menos features

Segunda parte da série sobre mitos de interface mobile, abordando o mito: sites móveis requerem menos features.

Tenho certeza de que todos nos lembramos de como costumávamos usar a internet há quase 10 anos — estávamos principalmente procurando por “conteúdos sensíveis ao tempo”. Naquela época, nossas necessidades eram bastante imediatas e específicas.

Não é mais o caso.

Este é o segundo artigo da série sobre 5 mitos de interface mobile:

  • Mito 1: usuários móveis estão sempre com pressa
  • Mito 2: sites móveis requerem menos features
  • Mito 3: simplicidade é bom, complexidade é ruim
  • Mito 4: diretrizes não podem ser quebradas
  • Mito 5: designers e visitantes pensam igual

Mito 2: sites móveis requerem menos features

Naquela época, pessoas em dispositivos móveis acessando um site tinham pouca ou nenhuma intenção de explorar ou comprar qualquer coisa. As conexões de dados eram mais lentas e dispendiosas. Fazia sentido projetar sites móveis para tarefas reduzidas, oferecendo o mínimo.

A mentalidade geral era “se está em dúvida, deixe de fora” e se as pessoas quisessem visualizar o site completo, precisariam acessar de um desktop.

A verdade: priorize e maximize as capacidade que o mobile oferece

De acordo com a Pew Internet, a dependência de smartphones aumentou. 1 em cada 10 adultos nos EUA usa seus smartphones como principal meio para se conectar à internet e esse número está crescendo rapidamente. Para reforçar o cenário, enquanto o uso geral da internet aumentou, serviços de banda larga para residências têm se estabilizado nos últimos anos.

Hoje em dia, quando alguém visita um site em seu dispositivo móvel, espera encontrar tudo o que a versão desktop oferece. A maneira prática de conseguir isso é priorizar e maximizar os recursos de dispositivos móveis, incluindo:

  • Tirar proveito dos superpoderes de sensores de dispositivos móveis (algo que os desktops não possuem)
  • Colocar mais conteúdos e recursos em um site mobile — dependendo dos objetivos do visitante, isso pode significar a adição de botões de compartilhamento fixados na tela uma funcionalidade de toque rápido para voltar ao topo da página
  • Desenvolver sites para se adaptarem às necessidades específicas de cada tipo de dispositivo

A ideia é se livrar do pensamento de que uma tela menor indica menos intenção de explorar/usar. Ao invés de eliminar recursos em dispositivos móveis, priorize-os!

Ninguém está sugerindo que as informações sejam apresentadas exatamente da mesma maneira, independentemente de por qual dispositivo/configuração o acesso seja feito. Veja este exemplo:

Neste comparativo, fica claro que o espaço diminuto da tela é mal aproveitado à direita. À esquerda, já se foi direto ao ponto, estimulando o visitante a realizar a ação principal planejada sem delongas.

Fim da segunda parte sobre mitos de interface mobile

Tal como citado no primeiro artigo da série, este mito também já foi derrubado por Luke Wroblewski em 2011 (!), em seu livro Mobile First. Aqui no desenvolvimento para web também já alertamos sobre isso há anos…

Mas é realmente impressionante como até hoje aqueles que projetam sites continuam perpetrando a prática de remover recursos/informações de sites a partir de visitas mobile. Em muitas das vezes os pobres desenvolvedores não temos nada com isso; o erro vem “de cima”…

De qualquer maneira, fica a lição do artigo: priorize e maximize recursos de dispositivos móveis e tente ao máximo não penalizar quem acessa seu site/app oferecendo menos informações/recursos.


10 dicas que desenvolvedores web iniciantes devem saber

Conheça 10 dicas que desenvolvedores web iniciantes devem saber para começar e/ou continuar suas carreiras

Se você é um desenvolvedor iniciante, pode ser confuso sobre onde você deve começar no mundo do desenvolvimento web, já que o ramo é amplo e oferece muitas opções de escolha. Há muitas perguntas a serem feitas, tais como “Que linguagem de programação quero aprender?” ou “Eu deveria saber sobre front-end ou apenas back-end?”, e existem, literalmente, centenas de outras.

Mas, para que você não fique tão perdido, esta lista com 10 dicas que desenvolvedores web iniciantes devem saber realmente pode ajudá-lo a iniciar sua carreira como desenvolvedor ou, caso já tenha começado, servir de norte para a continuação dos caminhos a serem trilhados.

Decida quais habilidades você quer

Ao iniciar na carreira de desenvolvedor web, você realmente precisa se concentrar em alguma coisa e aceitar o fato de que não é possível ser um “generalista” — ou, como a garotada hoje em dia prefere chamar, um desenvolvedor full stack.

Acredite: mesmo dando muita vontade de atuar em vários e vários ramos do desenvolvimento web, isso é impossível para quem está começando. Afinal, é preciso saber atuar em várias frentes para ser um “full stack” e, quando se está começando, mal se tem o conhecimento para uma só. Faz sentido, certo?

Não há nada de errado em querer em ser excelente em vários campos, mas você realmente não poderá fazer isso no começo. O que você pode fazer é centrar seus esforços no aprendizado em uma habilidade e se tornar um perito nesse campo.

Pode ser PHP, Ruby, C#, etc., mas tem que ser bom no que faz. Depois de dominar um deles, você pode seguir em frente, mas não faça isso até que você tenha grande conhecimento nesse campo.

Não há nada de errado em querer em ser excelente em vários campos, mas você realmente não poderá fazer isso no começo.

Esta dica também é bom para front-end designers, que sempre começam com HTML e CSS, depois passam para JavaScript, muito comumente se especializando em frameworks, Node, ou quaisquer outros que estiverem interessados.

Claro, é possível aprender HTML e CSS ao mesmo tempo, mas isso é porque eles meio que trabalham em conjunto. Você não pode realmente dominar PHP e Ruby ao mesmo tempo — a menos que você gaste 20 horas de estudos por dia, o que, definitivamente, não é recomendado –, portanto, para quem possui QI abaixo de 130, o recomendado é adquirir as habilidades uma a uma.

Mas, já que você é um novato e, provavelmente, não deve saber muito sobre linguagens de programação hardcore, escolher uma área para começar pode ser complicado, mas há uma solução: pense no que você quiser desenvolver: se for temas para WordPress, então seu caminho é o PHP; se for sistemas de gestão personalizados, tente ASP.NET; jogos de iPhone, aprender Swift e assim por diante.

Aprenda direito

Outra dica para novatos é, independentemente da linguagem que você escolher, aprenda direito! Se você aprender HTML codificando layouts com tabelas, isso não é nada certo. Codificar usando os mais recentes padrões da web parece inútil para alguns, mas é realmente importante e é altamente recomendado a aprender assim, já que será mais fácil e fará mais sentido ante o cenário atual de desenvolvimento web.

Além do mais, inevitavelmente a situação de ter que pegar o código de alguém para compreender e/ou passar seu próprio código para ser compreendido acontecerá; quanto mais ambos estiverem alinhados com técnicas modernas de desenvolvimento, melhor será para todos.

Google é o seu melhor amigo

Realmente não importa que tipo de problema (relacionado a webdev) apareça, certamente o Google pode mostrar a direção certa para resolvê-lo.

Fóruns de programação são altamente recomendados também, mas, antes de postar uma pergunta em algum fórum, tente buscar uma solução no Google porque, na maioria das vezes, você vai encontrar uma resposta para sua pergunta — ou, pelo menos, uma resposta que irá guiá-lo para resolver a questão.

Analise o código alheio

Pegando o exemplo da área de front-end, às vezes, desenvolvedores têm conhecimentos de design de front-end e fazem seus próprios layouts antes de começar a codificá-los. É importante olhar outros sites para entender como eles são codificados. Se você gosta de algum estilo ou elemento de um site, olhe para o código fonte e o analise!

Atualmente, é praticamente considerado uma insanidade trabalhar com front-end sem usar a DevTools do Chrome. Antes de ela servir para ajudar no trabalho do dia-a-dia, certamente pode servir para ajudar a entender códigos de terceiros.

Entre numa rede de conhecimentos

Outra coisa importante é participar de uma rede dentro de seu campo de conhecimento. Nunca é demais conhecer outros desenvolvedores/designers. É muito interessante (e até gratificante) ter discussões sadias e trocas de informações/ajuda com pessoas da mesma área. Você pode até colaborar com seu colegas desenvolvedores em projetos maiores, já pensou?

Você está perto de conseguir um projeto mas não tem certeza se você pode lidar com o tipo de trabalho solicitado? Recomende um de seus colegas desenvolvedores! Ele(s) provavelmente irá(ão) executar o trabalho melhor do que você — se for(em) especialista(s) nessa área específica — e você pode fechar algum tipo de parceria em algum momento futuro.

Faça parte de uma rede e a mantenha ativa e sempre por perto. Há sempre a demanda por um desenvolvedor que esteja “ao redor”. Há um discussão interessante no GitHub sobre como encontrar projetos open source para colaborar que certamente vai ajudar bastante.

Entenda os designers

É altamente recomendado compreender designers, caso não tem ideia de como eles trabalham. E isso vale tanto para designers gráficos quanto para front-end designers.

É sempre bom para aprender como eles trabalham e porque eles podem entregar páginas estáticas que realmente não correspondem aos mais recentes padrões da web. Aprenda a conversar com eles e explicar o que está errado e saber pedir para corrigir seus próprios erros. Dessa forma, sua relação de trabalho será mais próxima e o resultado bem melhor.

Não se surpreenda, mas é até indicado que desenvolvedores devem participar do processo de design!

Use ferramentas profissionais

Apesar de HTML, CSS e JavaScript poderem ser feitos até com o Bloco de Notas, isso não é recomendado. E, se isso não é recomendado para front, é igualmente desaconselhado para back. Trabalhe com editores/IDEs profissionais/robustos. Use o que os profissionais usam, caso contrário você não será um deles!

Esse tipo de ferramenta verifica erros, tem autocomplete e dá sugestões durante a codificação. Há uma razão pela qual PhpStorm, VSCode, Neovim, Eclipse, NetBeans e outros são muito usados em todo o mundo: eles ajudam a fazer o trabalho e o fazem em grande estilo!

Deixe as coisas legais por último

Cada linguagem tem a sua própria “versão cool”. Por exemplo, HTML tem HTML5, CSS tem CSS3, JavaScript e AJAX tem jQuery/Zepto e assim por diante. É muito melhor se você aprender a linguagem básica e depois estudar mais até chegar no estágio cool.

Também, as coisas “cool” trabalham a partir dos elementos básicos, então você não será capaz de desenvolver e entender um controle deslizante com jQuery se você não compreender o JavaScript básico.

Mantenha-se informado e atualizado

É sempre bom se manter informado e atualizado sobre o que está acontecendo no mundo do desenvolvimento web, em especial da(s) área(s) que você atua. Você pode fazer isso através da leitura de feeds, livros “de verdade”, blogs, fóruns e screencasts. Fique atualizado e certifique-se de que você é um dos primeiros a oferecer produtos desenvolvidos com a tecnologia mais recente.

No começo, pode não funcionar muito (as pessoas podem querer manter o “velho” até que as novas tecnologias mostrem seu valor), mas, certamente, também há aquelas pessoas que querem ter um produto totalmente novo, desenvolvido com as mais recentes tecnologias — e isto lhe dará uma vantagem e fará você conhecido no ramo.

Não é surpresa para ninguém do ramo que os melhores e mais recentes conteúdos e tutoriais estão em inglês. Então comece a puxar da memória todas aquelas aulas sobre o verbo “to be” ou fixe uma aba do Google Tradutor no seu navegador, porque você vai precisar.

Continue com o processo de aprendizagem

Depois de se tornar um especialista no campo que escolheu, trilhe seu caminho rumo ao aprendizado de outras linguagens e/ou áreas de atuação. Fique de olho aberto nas linguagens mais importantes e aprenda aquelas que julgar serem as mais interessantes. Quando você domina duas, vá para a terceira e assim por diante.

E continue até que não haja muito mais para aprender dentro do que você escolheu. Acredite, compartimentar os estudos para não ficar sobrecarregado é o caminho.

Conclusão

É bastante comum que desenvolvedores iniciantes passem por tempos difíceis neste campo profundo do desenvolvimento web, mas estas dicas servem justamente para ajudar que cada um encontre seu caminho.

Nem sequer importa muito por onde começar, tudo o que importa é começar! Isso geralmente é o que leva mais tempo, então não desperdice estes dias preciosos e comece agora a estudar e a desenvolver a web!

Para ajudar, veste este (não tão recente, mas até que útil) vídeo sobre uma técnica de estudos que pode ajudar a não perder a sanidade ante tudo isso que queremos aprender sobre tecnologia:


URLs amigáveis (slug) à WordPress

Apenda a gerar URLs amigáveis como é feito no WordPress e implemente em seu sistema PHP

desenvolvimento web em WordPress é excelente! O CMS já vem com diversas funções e funcionalidades para facilitar a vida de desenvolvedores e, até mesmo, de pessoas que não tem o mínimo conhecimento em programação (um dos objetivos é esse, mesmo).

Mas muitos desenvolvedores, principalmente os ainda incipientes, esquecem que o WordPress nada mais é do que PHP! Claro, o WP é nada mais, nada menos, que um sistema feito em PHP, como você e eu poderíamos ter feito. Mas, por motivos que me fogem ao conhecimento, as pessoas esquecem isso… Talvez o nível de abstração em programação que o CMS proporcione seja o “culpado”, mas, sinceramente, não tenho certeza.

Então, se você tiver a curiosidade de vasculhar os arquivos PHP que fazem do WordPress o que ele é, vai ter uma grata surpresa e encontrar uma rica fonte de scripts, funções e funcionalidades que você sempre quis implementar e não sabia como!

URLs amigáves à WordPress

Por exemplo, muitos querem implementar uma estrutura de URLs amigáves (gerar os famosos “slugs”) em sistemas desenvolvidos do zero  – seja através de frameworks ou em PHPU (“PHP Unha”) -, mas não sabem como. Ora, se sabemos que o WordPress possui um ótimo sistema de geração de slugs e temos acesso a seu código-fonte, tudo o que é preciso é vasculhar o código-fonte e encontrar as funções certas.

Seguindo o exemplo de gerar slugs, procurando um pouco, é possível saber que as funções necessárias se encontram em /wp-includes/formatting.php. E, como era de se esperar, as funções estão devidamente documentadas com seu escopo, parâmetros e retorno. Precisa de mais?

Para gerar URLs amigáveis à WordPress, são necessárias 4 funções. 3 “preliminares” que são:

E, com essas funções devidamente estabelecidas, a função que gera os slugs, propriamente dita:

Então, para gerar um slug em seu próprio sistema depois de implementar as funções mostradas, basta escrever:

Achou o nome da função grande ou feio? Você tem o código, altere como bem entender!

Considerações finais

O WordPress é software livre (registrado sob a licença GPL), então você pode pegar essas 4 funções e implementar em seu site/sistema/softwares sem o medo de receber uma cartinha do advogado da equipe WordPress amanhã ou depois.

Fica uma pergunta: você tem um software livre à disposição e fica quebrando a cabeça em busca de soluções de código que já existem e estão implementadas nele? Vasculhe todo o código fonte (veja alguns recursos que ajudam no artigo sobre ferramentas e recursos para desenvolvimento web) e procure por aquilo que vai lhe ser útil!

Não seja tímido! 😉


INSTALANDO O WORDPRESS VIA SOFTACULOUS (CPANEL)

 A instalação do WordPress pode ser uma tarefa complicada em um primeiro contato. Mas pelo Softaculous, tudo fica mais fácil. Basta seguir os passos abaixo:

1- Primeiro logue-se em seu painel cPanel com os dados de login e senha.

2- Localize a categoria: Software/Serviços

3- E clique no item: Sofataculous

4- Geralmente o CMS WordPress, fica disponível já na página inicial do script, caso o mesmo não esteja disponível, basta navegar até o menu lateral esquerdo: Blogs

5- E clicar no item do WordPress, depois vá no botão: Instalar e siga os passos descritos na página:

6- Após a escolha e configuração conforme desejado, basta clicar no botão abaixo da página em: Instalar

7- Pronto seu CMS WordPress um dos maiores e melhores scripts de blogs está instalado em seu site.


O que SEO pode aprender com UX?

Pontos interessantíssimos sobre UX, SEO, a relação entre ambos e o que pode acontecer a estas carreiras a partir de agora.

Experiência do Usuário (ou User Experience, também chamada UX) desempenha um papel fundamental em orientar decisões básicas que moldam web sites e produtos digitais e, cada vez mais, está “tomando seu lugar à mesa”, por assim dizer. A razão é porque UX é multidisciplinar, englobando Design, Arquitetura da Informação, Usabilidade, Design de Interface, Estratégia de Conteúdo e Pesquisa. Apesar da sua relativa “juventude”, UX, como disciplina, tem crescido exponencialmente nos últimos anos.

Consultores de SEO são trazidos mais tarde ao processo e, geralmente, têm um alcance de trabalho limitado em UX, mas seus esforços podem ter um impacto mais amplo por causa dos números. Então, por que SEO parecem ter menos força com a liderança executiva?

Ambas as disciplinas construíram suas reputações na tomada de decisões apoiadas por dados, mas como especialistas em SEO podem aplicar o sucesso de UX em seus cargos?

Breve história

Pessoas que trabalham com Experiência do Usuário (UX) não acabaram de surgir. Eles eram psicólogos, jornalistas, designers de interface e arquitetos da informação – pessoas que escutam bem e pode traduzir suas descobertas em recomendações contextuais. UX, em sua forma atual, existe desde meados da década de 1990. Anteriormente, pessoas da área de UX estariam trabalhando em áreas afins como:

  • Psicologia
  • Ergonomia
  • Interação Humano-Computador
  • Design de Produtos
  • Biblioteconomia

SEO existe desde, pelo menos, 1997, e evoluiu em conjunto com a tecnologia. Antes disso, o análogo mais óbvio seria marketing. Há pontos em comum definidos nos dados que os profissionais de UX e SEO trabalham, mas as pessoas que trabalham nestas áreas têm diferentes origens e prioridades que podem contribuir para a desconexão entre os dois.

A maioria das pessoas que querem/têm um site veem SEO como uma grande prioridade. Ninguém quer pagar por um sistema que não existe aos olhos dos mecanismos de busca e, portanto, corre o risco de ter seu crescimento obstruído. SEO é uma preocupação crítica, mas é, em última análise, secundária a uma grande experiência.

O papel da UX

Implementar processos centrados no usuário se tornou uma prioridade em muitas empresas porque tem um alto retorno sobre o investimento (ROI), muitas vezes resultando, diretamente, em maior satisfação do cliente, crescimento do negócio e engajamento de marca.

Não existe uma definição singular sobre o que é o processo de UX, já que os que atuam na área trazem sua própria combinação única de habilidades e conhecimentos para os projetos e porque as recomendações variam de acordo com cada contexto em que se está trabalhando.

Alguns diriam que UX se concentra em acrescentar “personalidade” e utilidade para um meio inerentemente sem emoção. Um bom profissional de UX irá:

  • Ajudar pessoas (“usuários”) a alcançar seus objetivos
  • Equilibrar os objetivos do negócio com a integridade da experiência do usuário
  • Em última instância, ajudar as pessoas a melhorar suas vidas através da tecnologia

A grande marca de um consultor de UX é a facilitação (entre as preocupações dos stakeholders, estratégia, design, conteúdo e engenharia). Consultores de UX idealmente atuam como agentes de mudança dentro das empresas.

SEO e UX são diferentes

As pessoas realmente não enxergar uma interseção entre UX e SEO. É mais ou menos como na Corrida de Revezamento: eles não querem se tocar, só querem se apressar e seguir em frente.

Simplificando, SEO leva as pessoas a um site, aumentando a encontrabilidade de informações; e UX as mantêm lá, fazendo com que a informação seja envolvente e utilizável. Não é mágica. Os comportamentos de busca de informação que as pessoas usam para encontrar o que estão procurando pela primeira vez são muito diferentes dos “gatilhos” que levam a tráfego repetido.

Ambas as disciplinas são necessárias para acomodar diferentes tipos de informações de comportamentos de busca; o objetivo primordial deve ser o equilíbrio entre o ranking nos mecanismos de busca e a integridade da experiência da marca. Em última instância, a relação do usuário de longa duração é com a experiência.

“Me dê alguma coisa acionável”

Todo estão fazendo o trabalho necessário para ajudar produtos digitais a encontrarem sua audiência; como isso é alcançado é “o” ponto de diferenciação. Tudo se resume a todos pedindo a mesma coisa: “Me dê alguma coisa acionável”.

O que UX e SEO consideram como “acionável”?

SEO considera métricas web como acionável – dados quantitativos que são derivados a partir de medições. Ao lidar com o tráfego web, minutos ganhos podem se traduzir em números enormes em sites de grande escala. Devido ao fato de os consultores serem trazidos mais tarde no ciclo de planejamento de um produto, há uma ênfase em melhorias incrementais conforme o tempo passa.

UX emprega métodos de pesquisa qualitativa e quantitativa em sua busca pelo equilíbrio entre utilidade e prazer. Dependendo do projeto, você pode precisar de dados quantitativos, como web analytics. Outras vezes você pode usar dados qualitativos como:

  • Entrevistas com usuários
  • Análise heurística
  • Pesquisa de campo

Essas fontes de dados, qualitativas e quantitativas, são essenciais para a identificação de oportunidades de mudança – grandes e pequenas.

Estratégia de Conteúdo e SEO a longo prazo

A longo prazo, SEO deve quase que cuidar de si mesmo com uma boa Estratégia de Conteúdoe uma “voz de marca” diferenciada – conteúdo real deveria, teoricamente, levar a ganhos reais de tráfego.

Envolvente, o conteúdo exclusivo é essencial para a sua estratégia, claro. Essa estratégia poderia envolver o crescimento do “estilo” de uma marca ou o estabelecimento de liderança de pensamento em um campo, em particular, ou o desenvolvimento de uma marca orientada a serviço. Conteúdos novos também são cruciais se você está focado em compartilhamento social e backlinking, já que ambos aumentam o alcance de um site e fazem crescer a base de usuários.

Técnicas de SEO podem desvirtuar a Estratégia deConteúdo se aplicadas em excesso. Quando os ganhos são mais de de otimização, ao invés de conteúdo real, relevante, a experiência geral é diminuída. A desvantagem desta maior ênfase na estratégia de conteúdo é que SEOs podem, eventualmente, não serem mais necessários em dado momento.

Mas existe alguma forma de agregar valor e fazer crescer o papel de SEO que não está em desacordo com a experiência holística do cliente?

Educação como chave para a elevação da disciplina

É a educação a chave para elevar a disciplina e levar a SEO para o próximo nível?

Uma coisa que UX tem feito muito bem na última década é se promover. Existe uma comunidade ativa na internet dedicada a melhorar e legitimar a UX, ajudando a próxima geração de profissionais da área a crescer em seus cargos.

Design originalmente se referia ao apelo visual, mas esses esforços criativos muitas vezes tornaram muitos sites inutilizáveis… Design se expandiu para incluir UX, o que transformou o site atrativo num sistema coeso. Os sistemas foram ficando funcionais e atrativos, mas não particularmente interessantes, daí a necessidade da Estratégia de Conteúdo.

Qual é o objetivo de um sistema atraente, funcional e envolvente que não se pode encontrar? Assim, a necessidade de SEO. É um pouco de especialidade nicho que às vezes é tratado como um adendo pelo pessoal que faz a administração.

SEO ainda está, muitas vezes, associado a táticas questionáveis devido à época em que era mais comum que atualmente comprometer a experiência global em função de pequenos ganhos em rankings de busca. Táticas como:

  • “Keyword stuffing”
  • Rodapés obesos, cheios de links
  • Conteúdo falso e/ou de baixa qualidade

Capacitar a próxima geração de designers e SEOs para tomar decisões inteligentes e educar as partes interessadas nesse sentido é a chave para o crescimento da disciplina e elevação da percepção do nível executivo de SEO.

Jakob Nielsen recentemente levantou um excelente ponto sobre SEO de curto prazo ser, principalmente, sobre um bom design. E a definição de “bom design” deve incluir projetar com SEO em mente, para além de todas as outras coisas que os designers de hoje têm de se preocupar. Seria incentivar jovens designers de projetos de sistemas a não violarem osprincípios básicos de encontrabilidade, acessibilidade e credibilidade.

Quando designers se preocupam com os princípios básicos de SEO, eles têm o poder de melhorar a integridade de seus projetos. Quando as pessoas têm um sentimento de “posse” do processo, eles são mais propensos a valorizar a ênfase adicional nas melhores práticas de SEO. Consultores então seriam livres para o trabalho mais especializado ou para encontrar novas maneiras de contribuir para expandir a definição de seus papéis.

O valor de UX

Não existe uma quantidade finita de trabalho, empregos ou de receita; a grande coisa a respeito de UX é o tanto que as pessoas estão dispostas a pagar por isso. Rúben Steiger fala sobre isso em seu artigo “Who’s the Chief Experience Officer?“.

Em seu livro “Future Shock”, de 1971, o futurista Alvin Toffler falou sobre a vindoura “indústria experiencial” em que as pessoas no futuro estariam dispostas a alocar altos percentuais de seus salários para viver experiências incríveis […] […] Empresas precisam começar a pensar sobre a relação holística entre suas marcas, produtos e serviços. “Moldar” uma experiência requer um projeto que considera estes três elementos de marca, produto e serviço, a fim de gerar resultados bem sucedidos.

Faz sentido que as empresas teriam que sentar e prestar atenção às oportunidade em mãos. Diretores de Experiência (CXOs) até já começaram a fazer incursões na estrutura executiva da indústria da tecnologia. Quantos profissionais fizeram isso recentemente?

Muitas empresas querem ser a Apple, uma empresa reconhecida pela qualidade de sua UX, mas estes “wannabes” (termos pejorativo para se referir a pessoas que querem ser o que não são) não estão dispostos a colocar o trabalho em seus processos de design de produto e cadeia de suprimentos para suavizar os solavancos. Você não pode simplesmente imitar a aparência de um sistema porque, no minuto em que os usuários começarem a tentar fazer as coisas que querem/precisam fazer, as diferenças se tornam claras.

Experiência do Usuário tem um lugar à mesa porque o valor agregado é claro. Processos eficientes de design centrado no usuário resultam em maior satisfação do cliente, o crescimento do negócio e num engajamento global de marca. A contribuição da UX para produtos digitais, em última análise, ajuda as pessoas a melhorarem suas vidas através da tecnologia.

Pode a SEO ganhar um assento à mesa?

Especialistas em SEO podem ter de se adaptar a fim de evitar o destino de “marginalização”. Estratégia de Conteúdo apenas começou a ter seu “lugar ao sol” e sua contínua popularidade poderia reduzir a necessidade de otimização de busca para todos. Especialistas em SEO terão que aprender novas especialidades no futuro ou enfrentar a concorrência cada vez mais dura por trabalhos? Há outras oportunidades além dos paradigmas habituais para fazer crescer a posição de SEO dentro das organizações?

UX capturou o Zeitgeist (“Espírito do Tempo”) porque tem uma comunidade robusta dedicada a crescer, educar e legitimar o campo, e provou seu valor para a liderança executiva. Alguns diriam que SEO tem um problema de percepção, indo sempre pelo caminho do nível executivo.

Pode ser hora de considerar uma reeducação das partes interessadas e membros da equipe sobre o valor de SEO.


HTTP 503: a maneira correta para SEO

Considerações a respeito do status code HTTP 503: o que significa, suas implicações de uso e como usar o HTTP 503 em períodos de manutenção de um site.

Você dá a devida importância aos códigos de status que são enviados nos cabeçalhos HTTPdas páginas de seu site? Saiba que enviar um cabeçalho de resposta HTTP com um código errado pode ser fatal… Principalmente quando alguma manutenção está sendo feita no site ou sistema. Neste artigo, breves considerações a este respeito e quais medidas tomar em relação ao status code 503 quando seu site entrar em manutenção.

Códigos de status HTTP e mecanismos de busca

Um mecanismo de busca constantemente verifica se o conteúdo que ele está indexando ainda existe e/ou não mudou. Geralmente, mecanismos de busca verificam 2 coisas:

  • Se o conteúdo está sendo “encabeçado” com o código HTTP 200;
  • Se o conteúdo ainda é o mesmo.

Um código 200 de HTTP significa: “Tudo está bem, aqui está o conteúdo que você pediu”. É o único status que indica que tudo está bem com o conteúdo. Se o conteúdo foi movido, você pode redirecioná-lo – permanentemente, com um HTTP 301 ou; temporariamente, com um HTTP 302 ou 307.

Se o servidor retorna qualquer outro código de status HTTP, significa que o mecanismo de busca já não pode encontrar o conteúdo. Se um servidor retorna um HTTP 200, mas a página é, de fato, um erro e diz algo como “Arquivo não encontrado” ou tem muito pouco conteúdo, o Google vai classificá-la como um “soft 404” no Google Webmaster Tools.

Como mecanismos de busca lidam com o tempo de inatividade do servidor (downtime)

Se, durante um rastreamento, um motor de busca encontra algum conteúdo que não existe mais, por exemplo, ele retorna um status code HTTP 404 que, geralmente, remove o conteúdo dos resultados de pesquisa até que o crawler possa voltar e verificar se ele está lá novamente. Se isso acontece, geralmente vai demorar um pouco para que o conteúdo volte a aparecer nos índices de busca novamente.

O que você deve fazer é garantir que um código de status HTTP 503 será retornado! Esta é a definição do código de status 503 da RFC (que define esses códigos de estado):

O servidor atualmente é incapaz de lidar com o pedido devido a uma sobrecarga temporária ou manutenção do servidor. A implicação é que esta é uma condição temporária que será aliviado após algum atraso. Se conhecido, o tempo de atraso PODE ser indicado em um cabeçalho Retry-After. Se nenhum Retry-After é fornecido, o cliente DEVE lidar com a resposta como seria para uma resposta 500.

Então, você tem que enviar um código de status 503 em combinação com um cabeçalho Retry-After. Basicamente, você está dizendo: “Espere! Estamos fazendo alguma manutenção, por favor, volte em X minutos”. Isso soa muito melhor do que um erro que diz: “Not Found”. Um código de status 404 literalmente significa que o servidor não pode encontrar qualquer recurso para retornar à URL acessada.

Como enviar um cabeçalho HTTP 503?

A maneira como se envia um código HTTP 503 como resposta a uma requisição depende da linguagem server-side que você está trabalhando. Por exemplo, em PHP, envia-se esse HTTP 503 assim:

O tempo de atraso do exemplo, 3600, é dado em segundos, de modo que 3600 segundos corresponde a 60 minutos (ou 1 hora). Você também pode especificar o tempo exato em que o visitante deve voltar enviando uma data em GMT ao invés do número em segundos. Algo como:

Quando preferir usar GMT, faça isso com muita cuidado e consciência! Especificar uma data errada pode causar resultados inesperadamente desastrosos!

“Meu site nunca está em manutenção, eu uso WordPress!”

Bobagem. Toda vez que você atualiza o core do WordPress ou quando você está atualizando plugins, o WP fornece uma página de manutenção. Essa página, por padrão, envia um cabeçalho HTTP 503 adequado.

Você pode substituir essa página de erro padrão com um arquivo maintenance.php na sua pasta wp-content, mas, se fizer isso, você tem que ter certeza de que o arquivo envia os cabeçalhos HTTP 503 apropriados! Na dúvida, você pode dar uma olhada no código da função wp_maintenance().

Se seu banco de dados caiu, o WordPress envia um erro interno do servidor usando a função dead_db(). Se você está fazendo uma manutenção planejada no banco de dados, é preciso criar uma página personalizada com uma mensagem de erro – usando o arquivo db-error.phpem ​​sua pasta wp-content, que envia o cabeçalho HTTP 503 adequado.

Cuidado com o cache!

Se você está trabalhando com algum tipo de sistema de cache, muito cuidado ao realizar essas mudanças! Tenha absoluta certeza de que o código HTTP 503 está sendo enviado corretamente durante o tempo em que a manutenção está sendo realizada.

Se não tomar cuidado, o código HTTP 500 (“Internal Server Error”, um erro genérico) pode ser enviado e, definitivamente, isso é algo que você não vai querer que aconteça.

HTTP 503 através do robots.txt

Segundo este post de Pierre Longe no Google+, se você enviar um código de status HTTP 503 para o arquivo robots.txt, o Google vai parar todo o rastreamento no domínio até que seja autorizado a rastrear o robots.txt novamente. Essa é uma forma muito útil de prevenir uma eventual sobrecarga no servidor ao fazer manutenções.

Usar essa técnica ainda exige que você envie um HTTP 503 para cada URL do site, incluindo as que apontam para recursos estáticos, mas, depois que o Google tiver acesso ao robots.txt novamente, provavelmente vai parar de martelar seu servidor por um tempo.

Conclusão: saiba que cabeçalhos HTTP você está enviando

Em suma, você deve ter ciência do que está acontecendo em seu site/sistema e saber, exatamente, quais códigos de status HTTP são enviados em quais situações e por quanto tempo.

tweet de Vanessa Fox reforça bem essa ideia:

It’s about more than number of pages crawled – you need to know about important pages & what response code they return @vanessafox

Quer dizer: É muito mais do que sobre o número de páginas indexadas – você precisa saber a respeito das páginas importantes e qual código de resposta elas retornam.

É a mais pura verdade!


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.


Página 2 de 812345...Última »