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 Development | LCF HOST

Development


Twitter Bootstrap

Conheça mais sobre Twitter Bootstrap e saiba como você pode desenvolver projetos mais robustos, profissionais e visualmente agradáveis com este incrível framework!

Twitter Bootstrap já não é nenhuma novidade para os desenvolvedores que conseguem acompanhar as melhores tendências e ferramentas lançadas “lá fora” por conseguirem ler em inglês e, apesar de a popularidade do Twitter Bootstrap (TB) poder contar com uma curva crescente de uso em solo brasuca, um artigo sobre este fantástico framework vem, sim, em um bom momento. Se quiser saber mais sobre o Twitter Bootstrap, continue lendo!

O que é o Twitter Bootstrap

Se você acompanha os artigos do desenvolvimento para web, deve se lembrar que em março deste ano, no artigo que comentava sobre o novo tema do blog, que uma das tecnologias usadas por aqui é o Twitter Bootstrap. Entretanto, foi só um comentário “por alto” e, neste artigo você encontrará mais informações sobre o TB.

Idealmente e tecnicamente, o Twitter Bootstrap pode ser considerado um framework. Ele é um projeto que nasceu dentro do Twitter pelas mãos dos desenvolvedores @mdo and @fat. Fato curioso é que, inicialmente, tratava-se de um esforço para documentar determinados padrões de design e UI dentro do Twitter, mas a coisa tomou proporções maiores e seus autores decidiram virar amigos da garotada, disponibilizando o Twitter Bootstrap no Github (que, por sinal, é um dos projetos mais populares de lá).

Grosso modo, o TB é um conjunto de HTML, CSS e JavaScript que proporciona uma maneira ultra-rápida, eficiente e profissional de planejar e desenvolver o front-end de web sites, aplicações, sistemas e produtos web através de seus elementos de UI e interações. Na prática, isso quer dizer que você pode “dar vida” a seus sites e produtos web em apenas algumas horas!

Através do uso de HTML5 e CSS3, os projetos feitos com TB são modernos e garantidos de serem “duráveis”. Para melhorar, o CSS é feito com LESS! E, para constar, no momento da descrita deste artigo, a versão do Twitter Bootstrap é a 2.2.0.

Principais características do Twitter Bootstrap

Como citado, o Twitter Bootstrap possui um conjunto incrível de elementos de marcação, estilo e comportamento para que dar a início a projetos de características profissionais seja uma tarefa bem simples para os desenvolvedores web.

Scafolding

Sua poderosa estrutura conta com:

  • Estilos globais que servem para todos os navegadores modernos
  • Sistema de grid
  • Sistema de grid fluido
  • Layout fixo
  • Layout fluido para web design responsivo

Projetar estruturas de layout com o TB é extremamente simples e muito rápido, já que ele já conta com alguns tipos de grid, layouts e exemplos de marcação para se começar com seu uso imediatamente! Por exemplo, ao se conhecer suas classes, ter um layout fluido é tão simples quanto:

CSS

Com o poder das classes pré-definidas do TB, é possível ter um visual incrível dos elementos de marcação mais básicos e contar com elementos de UI fantásticos. O CSS do Twitter Bootstrap abrange:

  • Tipografia
  • Código
  • Tabelas
  • Formulários
  • Botões
  • Imagens
  • Icon Fonts

Por exemplo, veja como é simples apresentar botões bonitos e funcionais apenas usando algumas classes pré-definidas:

Botõesclass=””
btn
btn btn-primary
btn btn-info
btn btn-success
btn btn-warning
btn btn-danger

Componentes

Provavelmente você nunca criou componentes tão funcionais em seus sites usando uma marcação tão simples e bem pensada, com características cross-browser e visual de encher os olhos. São eles:

  • Dropdowns
  • Grupos de botões
  • Dropdown de botões
  • Navegações
  • Barra de navegação
  • Breadcrumbs
  • Paginação
  • Rótulos e emblemas
  • Tipografia
  • Thumbnails
  • Alertas
  • Barras de progresso
  • E mais!

JavaScript

E, além de prover toda a parte visual para sua aplicação web, o TB também oferece a parte de interação destes componentes visuais! Através de seus plugins próprios para jQuery, é possível obter interações como:

  • Transições
  • Modais
  • Dropdowns
  • Scrollspys
  • Abas
  • Tooltips
  • Popovers
  • Alertas
  • Botões
  • Colapsáveis
  • Carrosséis
  • Autocompletes

É bom demais ou não é? 😉

Recursos para Twitter Bootstrap

E, se não fosse bom o suficiente, existem diversos projetos complementares ao Twitter Bootstrap para que sua força e poder de desenvolvimento seja ainda mais potencializado!

  • Globo BootstrapÉ fácil traduzir um projeto de sucesso no mundo inteiro e colocar o nome da sua marca… De qualquer maneira, está aí o Globo Bootstrap, que é a tradução do TB para a Língua Portuguesa (sinceramente, a qualidade não está tão boa e não há garantias que acompanhe as atualizações do projeto original Segundo Alexandre Magno, toda a comunidade web é bem vinda a contribuir com o projeto, inclusive traduções, e a ideia é continuar na ativa)
  • Built With Bootstrap. Uma galeria com sites feitos com Twitter Bootstrap que mostra todo o potencial do framework
  • Bootswatch. Algumas pessoas criticam que os sites feitos com o TB se parecem demais. Para os que compartilham desta opinião, não tem mais o que reclamar com o Bootswatch, que é uma coletânea de estilos para o Twitter Bootstrap
  • {wrap}bootstrap. Se quiser investir em templates prontos feitos com TB, esse é o lugar!
  • Font Awesome. Com Font Awesome é possível estender os ícones-fonte do Bootstrap, ficando com uma gama de possibilidades bem maior para compor o visual do seu site.
  • Bootsnipp. Snippets HTML grátis para várias situações comuns de UI para Bootstrap.
  • Fuel UX. Fuel UX estende o Twitter Bootstrap com controles JavaScript adicionais. Complemente as interações de seus projetos em TB com combobox, datagrid, pillbox, busca e spinner.
  • X-editable. Se você precisa de um “edit in place” em seus projetos, o X-editable vai servir perfeitamente. Ele é um edit in place para se trabalhar com Twitter Bootstrap (e possui versões para jQuery UI e jQuery puro).
  • Bootstrap Shortcodes. Para os que adoram usar WordPress (eu!), eis uma coletânea de shortcodes para implementar facilmente os elementos visuais do TB.
  • Datepicker for Bootstrap. Se faltava um datepicker para o seu projeto com Bootstrap, agora não falta mais!

Conclusão

Com Twitter Bootstrap é possível dar vida a um projeto em poucas horas, já que sua curva de aprendizado é curtíssima. À medida em que se o vai usando, mais e mais prática é adquirida e, cada vez mais, a produtividade e agilidade em desenvolver o front-end é alcançada. Este é um projeto realmente diferenciado no mundo do desenvolvimento web e seus autores, definitivamente, contribuíram de forma positiva para a melhoria e facilitação do trabalho de seus pares.


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!


Ser um generalista não é uma coisa ruim

Já pensou em ser um profissional de web “generalista” ao invés de especialista? Leia este artigo e conheça os prós e contras dessa abordagem na carreira.

Nos últimos anos tem havido um afastamento do profissional web generalista para especialista, como estrategistas de conteúdo, arquitetos de experiência do usuário e codificadores front-end. Onde uma vez havia um único emprego, agora existem muitos, com esferas cada vez mais estreitas de responsabilidade.

Mas enquanto a maioria está se tornando mais especializada, muitos têm rejeitado a abordagem, permanecendo “generalistas” — incluindo a ampliação de seus interesses para áreas como marketing, psicologia, estratégia de negócios e outros. Não surpreendentemente, isso pode atrair críticas negativas de alguns pares que veem os generalistas negativamente.

Por que ser um “generalista” é algo ruim?

Parte da crítica se baseia na complexidade da web. Por exemplo, saber tudo sobre web designjá foi possível, mas agora é irrealista. Mas o fato de que o web design se tornou tão complexo significa que precisamos de generalistas para olhar além dos “silos de especialistas”.

O perigo é que, sem generalistas, os especialistas ficam tão envolvidos em seus silos que lhes é difícil trabalhar com especialistas em outras disciplinas. O generalista é necessário para encorajar a colaboração cruzada e para olhar além dos silos em desenvolvimentos emergentes na web.

Não confunda ser um generalista com não possuir habilidades

A percepção é que os generalistas são comuns e relativamente não-qualificados, porque todos começamos como um quando adentramos no desenvolvimento web. Mas essas pessoas não são verdadeiros generalistas.

Um generalista é alguém que é bem informado a respeito de uma ampla gama de assuntos. Isto não descreve a maioria dos desenvolvedores web — e, certamente, aqueles que estão começando. É importante não confundir ser um generalista com não ser qualificado.

Para facilitar o entendimento dos generalistas em desenvolvimento para web, alguns remetem ao termo “Pau-para-toda-obra”. Mas isso também é problemático, porque pode trazer uma conotação negativa em alguns casos. De qualquer maneira, os generalistas se sentem orgulhosos de suas capacidades de amplo conhecimento em diversas áreas.

Ser um especialista não é a única maneira de conseguir bons trabalhos

Não podemos negar que existe uma “percepção geral” de que a especialização é uma maneira muito melhor de se diferenciar em um mar de generalistas, que muitas vezes leva a empregos melhores — tanto em sentido pecuniário, quanto em satisfação pessoal.

Certamente, especializar-se é uma maneira de se diferenciar, ninguém pode negar este fato. Mas não a única maneira. Pode-se, também, confiar no trabalho de qualidade, no conhecimento de certos setores e até na amplitude da experiência e do conhecimento. Quanto aos especialistas mais qualificados para trabalhar em projetos maiores, isso também não é verdade.

Grandes projetos envolvem grandes equipes, e um generalista é muitas vezes necessário para reunir os diferentes especialistas e fazê-los trabalhar juntos de forma eficaz.

Generalistas também são chamados “passantes”, já que conseguem passar pelas diversas áreas do desenvolvimento web, facilitando a comunicação entre diferentes grupos de profissionais.

Isso significa que devemos todos rejeitar a especialização e nos tornarmos generalistas? De modo nenhum! Mas, em muitas situações, um generalista é necessário.

Você deve ser um generalista?

Como sabemos, não há nada de errado com a especialização. O que se está querendo chamar atenção é que, em certas circunstâncias, ser um generalista tem suas vantagens — e propicia vantagens para muitos profissionais trabalhando juntos num mesmo projeto web.

Aqui estão algumas circunstâncias que vêm à mente:

  • Prosperar na variedade. Generalistas têm mais oportunidades do que outros para explorar novos desenvolvimentos, técnicas e tecnologias. Se você é levado a constantemente aprender coisas e enfrentar novos desafios, então a variedade constante de disciplinas na web pode muito bem lhe servir.
  • Sua equipe de web é pequena. Pequenas equipes em grandes organizações, agências, produtoras etc, precisam de generalistas. Essas equipes exigem que todos façam o que é preciso ser feito, o que, inevitavelmente, exige que você cuide de muitas tarefas.
  • Freelancer. Trabalhar por si próprio muitas vezes exige que você seja Pau-para-toda-obra. A maioria dos clientes vai precisar de você para ajudá-los com tudo o que é relacionado à web. Especializar-se atuando como freelancer é possível, mas, certamente, não é a norma.
  • Pesquisa e Desenvolvimento. Em organizações e agências maiores, alguém precisa manter um olho em tecnologias emergentes. Enquanto especialistas vão fazer isso dentro de seus nichos, tendências inevitavelmente surgirão ao longo do tempo . O generalista será aquele que irá identificar essas novas oportunidades e avaliar quando investir nelas.
  • Você gere seu próprio negócio. Ser um generalista quando se gere o próprio negócio de desenvolvimento web não só permite se manter informado sobre uma variedade de tópicos e vendê-los aos clientes, como ajuda a entender o que as pessoas relacionadas à empresa fazem e se certificar de que as disciplinas funcionam bem em conjunto.

Enquanto alguns de nós devemos nos tornar generalistas por escolhas de carreira ou temperamento, há também boas razões para escolher este caminho em detrimento de outro.

Por que se tornar um generalista?

Os generalistas se sentem orgulhosos de suas capacidades de amplo conhecimento em diversas áreas.

Tornar-se um generalista é, em muitos aspectos, um excelente caminho a se tomar na carreira web. Para começar, ele mantém suas opções abertas: um generalista está sempre procurando novas áreas para explorar e, por isso, está idealmente posicionado para se deslocar para novos campos, como mobile ou HTML5.

Mantenha-se ágil e se adapte às mudanças

O perigo é que, como especialista, você se torna tão obscurecido por sua área de especialização que você não pode detectar novas oportunidades ou, pior ainda, não pode antecipar uma eventual retirada do mercado lenta de seu nicho. Considere aqueles que sabem como programar em nada mais que ColdFusion ou Flash… Essas tecnologias estão completamente mortas? Ainda não, mas os sinais mostram que é questão de tempo.

O potencial para mais trabalho

Ao ser capaz de se adaptar rapidamente a novas circunstâncias, um generalista raramente fica sem trabalho. Além do mais, ele pode criar a maioria dos produtos do início ao fim. Não só muitos generalistas acham isso gratificante, mas também maximiza a lucratividade, já que eles raramente precisam terceirizar. Isso está alinhado com as expectativas do cliente, que, geralmente, é que o fornecedor entregue a maioria de suas necessidades web — claro, pode haver ocasiões em que você precisa recorrer a especialistas.

Mas, antes de você resolver abandonar o caminho de ser um especialista, é justo compartilhar alguns perigos de ser um generalista.

Perigos de ser um generalista

Mais uma vez: o mote não é sugerindo que ser um generalista é certo para todos ou que algo está errado ao se especializar.  Mas ser um verdadeiro generalista não é um mar de rosas.

A luta para mostrar seu valor

Certamente, um dos maiores desafios para ser um generalista é se estabelecer como um expert e se destacar na multidão.

Generalistas muitas vezes são vistos quase como párias dos profissionais de web. Mas a verdade é que verdadeiros generalistas, aqueles com conhecimento extenso a respeito de uma ampla gama de assuntos, são muito raros. Os clientes compreendem que eles têm que pagar mais por habilidades altamente especializadas, mas não reconhecem a necessidade de pagar tanto por um conjunto amplo de habilidades diversas.

Além disso, generalistas raramente são os inovadores — se você é o tipo de pessoa que se importa com essas coisas. Eles não recebem a glória de desenvolver novas técnicas CSS ou estabelecer novos estilos de design. Em vez disso, os generalistas marcham atrás da vanguarda, selecionando os elementos que valem a pena adotar no mainstream.

A corrida constante pelo aprendizado

Generalistas continuamente têm de digerir o conteúdo de uma enorme variedade de fontes e decidir o que é de valor e o que se deve ignorar. Isso é incrivelmente exigente e, não raramente, alguma nova tecnologia ou tendência pode ser “descartada” para somente mais tarde, devido a movimentos vários da indústria, descobrir que vale a atenção.

Um generalista está sempre procurando novas áreas para explorar.

Se você não tem um perfil de ser estudioso/curioso, então ser um generalista certamente não é para você. Um generalista investe muito tempo todos os dias para ler blogs de especialistas que inovam para que possa ficar atualizado — também é preciso assimilar o que é aprendido, o que envolve tentar/testar uma variedade de técnicas.

E, certamente, algumas dessas novas técnicas podem simplesmente estar além das habilidades de um generalista.

Os limites de um generalista

Cair na armadilha de querer experimentar praticamente qualquer coisa que atravessa seu caminho é comum para um generalista. Embora admirável, essa qualidade pode acarretar prejuízo: generalistas podem desperdiçar horas tentando fazer o que um especialista poderia fazer em minutos. Pior ainda, o resultado pode ser não tecnicamente impecável e prejudicial à sua reputação.

Generalistas precisam conhecer seus limites — seja por saber quando chamar um especialista para ajudar ou simplesmente aceitar que eles não podem ser envolvidos em certas tarefas.

Conclusão sobre generalistas na web

É importante que haja um contrapeso ao impulso cada vez maior para a especialização. Mas é mais do que isso. Também é preciso haver um “respeito recém-encontrado” em relação aos generalistas: um reconhecimento de que o desenvolvimento de uma compreensão ampla dos aspectos cada vez mais complexos da web demanda tanta habilidade e esforço como se tornar um especialista em uma área.

Finalmente, este artigo também pode ser considerado um apelo àqueles que se consideram generalistas: levem seu papel a sério! Sejam generalistas verdadeiramente eficazes, que podem oferecer serviços valiosos para seus clientes e colegas e assumir compromisso de forma profissional.

Dessa maneira, certamente generalistas não ficarão carentes de bons trabalhos.


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!


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:


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 1 de 3123