Links quebrados e páginas de Erro 404

Por: Henrique Pereira

Categoria: Experiência de usuário, HTML / CSS / JavaScript, Internet / Web

Links quebrados, também conhecido em inglês como broken Links ou link rot (link podre ou estragado) são links que não mais levam o usuário para onde originalmente deveria levar. Em outras palavras, são links para páginas inexistentes. As causas disso são variadas, como um site que deixou de existir ou uma página que foi migrada para outro local devido ao redesign do site ou a página foi deletada, etc. O fato é que links quebrados são responsáveis por basicamente dois problemas distintos que você deve evitar em qualquer site. O primeiro deles é uma péssima experiência de usuário que os visitantes vão ter no seu site ao se depararem com “páginas inexistentes” – o famoso erro 404 – e o segundo problema é o desperdício de tráfego inútil na web ao requisitar ao servidor uma página que não mais existe.

Se você se preocupa com a indexação do seu site pelos mecanismos de busca você também precisa se preocupar em deixar seu site livre dos links quebrados. A internet é interligada por hyperlinks. Mecanismos de busca são estruturados em torno de links. Quanto mais links apontando pra um endereço mais relevante ele é. Se você possui muitos links quebrados ou páginas com erro 404, o Google pode não encontrar razão em dar alguma relevância para seu site, visto que o mesmo não oferece uma boa experiência de usuário. E isso é razão mais do que suficiente pra você se preocupar em manter seu site sempre atualizado e livre de links quebrados.

Erro 404 e como minimizar uma péssima experiência de usuário

Erro 404 é a denominação da famosa mensagem de “Página não encontrada” que todo mundo já se deparou alguma vez. Trata-se de uma resposta enviada pelo servidor informando que o endereço que você está tentando acessar não existe. E sabe quando essa tela aparece? Quando você deixou algum link interno quebrado ou removeu alguma página e não fez nenhum redirect para um novo endereço.

Geralmente a mensagem enviada pelo servidor, por padrão, não é muito útil como você pode ver na imagem acima. O correto é você personalizar essa página de erro 404 com uma mensagem mais amigável e mais explicativa para o usuário. Infelizmente a maioria dos sites não a personalizam deixando o usuário perdido e sem qualquer possibilidade de encontrar algum conteúdo similar no seu site. A Smashing Magazine publicou um texto sobre várias boas práticas relacionadas com páginas de erro 404 que vale a pena dar uma olhada antes de construir a sua. O Google também publicou algumas observações importantes sobre o assunto.

Evite round-trip times desnecessários

Round-trip Times (tempo de ida e volta em português), também abreviado por RTT é o tempo gasto para que uma aplicação client side (um browser por exemplo) gasta para enviar uma requisição ao servidor somado ao tempo que o servidor vai gastar para responder esse pedido. O RTT não inclui o tempo de transferência desses dados, trata-se apenas do tempo de comunicação entre cliente e servidor.

Vamos supor que na sua folha de estilos de CSS você chama uma imagem de background que não existe. Vamos supor que você nem notou que essa imagem não existe mas a regra de CSS que “linka” essa imagem continua lá. Toda vez que alguém acessa o seu site ou blog, sua folha de estilos vai enviar uma requisição ao seu servidor desnecessariamente. Pode parecer pequeno, mas em sites com grande audiência isso é um grande desperdício de recursos do servidor, consequentemente menos grana no seu bolso. Uma boa prática em desenvolvimento web para deixar sites mais rápidos é minimizar a quantidade round-trip times. Principalmente os desnecessários como aqueles originados dos maditos links quebrados.

Detectando e combatendo links quebrados

Depois de identificado 2 grandes problemas relacionados com broken links, o que você precisa fazer agora é colocar a mão na massa. Se seu site possui muitos links quebrados, ela passa uma impressão amadora e descuidada. Quanto mais importante — financeiramente falando — seu site representar pra você, mais cuidadoso com ele você deve ser. E combater links quebrados é uma tarefa que você não deveria esquivar-se nunca. Não há outra forma de combatê-los senão verificando link por link. Como fazer isso manualmente seria um tanto desumano, existem ferramentas que fazem isso por você.

Há várias soluções de ferramentas que checam links quebrados, mas neste artigo vou indicar apenas algumas que eu já utilizei.

W3C Link Checker: O W3C Link Checker é um verificar de links quebrados online parte de um grupo de ferramentas de qualidade da W3C. A vantagem desse verificador é que você não precisa instalar nada no seu computador.

Xenu’s Link Sleuth: O Xenu trata-se de um aplicativo desktop (roda somente em plataforma Windows) muito popular entre os desenvolvedores. Ele verifica imagens, JavScripts e CSS. Possui algumas informações em relatórios interessantes.

Firefox extension: LinkChecker: O LinkChecker é bem popular e fácil de usar. Basta instalá-lo como uma extension no Mozilla Firefox.

WordPress: Broken Link Checker Plugin para o WordPress que estará sempre monitorando seu blog atrás de links quebrados, te poupando muito esforço.

Além dessas ferramentas é sempre bom nunca tirar os olhos do Google Webmasters Tools e do Yahoo! Site Explorer atrás de problemas de indexação e report de erros. Nada substitui essas duas ferramentas.

P.S.: Sim, eu tenho alguns links quebrados por aqui e pretendo exterminá-los em breve. Eu disse que é algo que precisa ser feito e não que era um trabalho fácil.

Comentários: 3

Book Review: Manual de Tipografia – a história, a técnica e a arte

Por: Henrique Pereira

Categoria: Reviews

O livro “Manual de Tipografia – a história, a técnica e a arte” da Editora Bookman (Do original A Typographic Workbook: A Primer to History, Techniques, and Artistry por Kate Clair & Cynthia Busic-Snyder, 400 páginas, Segunda Edição, ISBN: 9788577803712, Ano 2009) é um livro de estudo (workbook) que tem sido usado em algumas universidades americanas desde sua primeira edição em 1995. Cada capítulo traz exercícios relacionados (técnicos e teóricos) o que deixa bem claro que a autora, professora do curso de design de uma universidade na Pensilvânia, realmente preparou o livro para a sala de aula.

O Manual de Tipografia cobre a história desde os antigos sistemas de escrita até a revolução tecnológica dos computadores, incluindo a evolução das formas de aplicação tipográfica, anatomia dos caracteres, características, classificação, composição tipográfica, etc. Quase que do meio do livro em diante você encontra um apêndice com amostras de várias fontes famosas, contendo uma breve história delas além de exemplos da aplicação da fonte em diferentes tamanhos.

Pontos negativos: O livro é para iniciantes no estudo de tipografia e poderá frustrar os mais experientes. Praticamente cada capítulo do livro esta com uma tipografia diferente e um modelo interno de grid variável (hora em 2, 3, 4 ou 5 colunas) e em outros trechos o modelo de grid parece inexistir. Pesquisei antes de escrever esse texto e esse estranho modelo de organização é uma herança da edição americana.

Pontos positivos: Para o iniciante alguns capítulos são uma mão cheia de informações preciosas compartilhadas de uma forma muito didática. Os capítulos de características (anatomia) dos caracteres e composição de textos tipográficos são muito bem escritos, claros e trazem informações preciosas que todo mundo que trabalha com web deveria saber, como alinhamento, peso de fonte, contraste, serifada ou não serifada, uso de kernel negativo, etc.

Se você nunca parou para estudar tipografia de forma mais organizada recomendo que compre o livro. Mas se você já estudou um pouco ou tem boas noções, recomendo procurar livros mais elaborados com foco em composição, aplicação, etc. Você pode comprar o livro no Submarino ou no próprio site da Editora Bookman.

Comentários: 7

Desenvolvedores são de Marte e profissionais de UX são de Vênus

Por: Henrique Pereira

Categoria: Acessibilidade, Design, Experiência de usuário

A história desse artigo começou assim: a Ale Nahra (@alenahra) fez a seguinte afirmação no Twitter:

“Finalmente entendi a diferença entre sites ruins e bons: a integração entre equipe de UX e desenvolvedores.”

Eu retuitei e em seguida a Aline Couto (@alineideias) fez algumas considerações direcionadas a mim, o que foi o suficiente pra começarmos uma discussão interessante sobre os problemas relacionados com a integração de equipes de experiência de usuário e desenvolvedores. E como as frases jogadas no Twitter me fizeram conectar alguns pontos interessantes, eu não gostaria de deixar que isso morresse por lá.

O problema

Desenvolvimento de projetos para web envolve pessoas com formação e especialidades diferentes. Desde o planejamento até a publicação no servidor, um projeto passa por várias fases nas mãos de diferentes profissionais. Podemos dividir estes profissionais em 2 grandes grupos. De um lado temos profissionais de design, experiência de usuário (UX) e arquitetos da informação. De outro temos os programadores de interface e os desenvolvedores server side. Geralmente os profissionais de experiência do usuário não entendem de tecnologia e desenvolvimento como deveriam e de igual modo os desenvolvedores não entendem de usabilidade, acessibilidade e design centrado no usuário como deveriam entender. Cada grupo com suas especialidades e cada grupo com, digamos, “objetivos” diferentes. Os profissionais de UX querem que o projeto seja fácil de navegar, de encontrar informações e intuitivo. Os desenvolvedores querem que a aplicação funcione sem erros e que cumpra os requisitos que receberam no início do projeto. O que faz com que esses dois grupos tenham tantas divergências no desenvolvimento do projeto?

Eu atribuo esse dilema a um problema característico de cada grupo. Geralmente os profissionais de experiência do usuário não entendem de tecnologia e desenvolvimento como deveriam e de igual modo os desenvolvedores não entendem de usabilidade, acessibilidade e design centrado no usuário como deveriam entender. Estou sendo simplista? Talvez, mas eu acredito que este seja a raiz dos principais problemas de divergência entre equipes.

Eu comecei a trabalhar com internet focado em desenvolvimento, design e programação de interfaces e só depois de muito tempo é que migrei para arquitetura da informação e design centrado no usuário. Até hoje eu perambulo pelos dois mundos. Este texto é uma reflexão de problemas que observei cumprindo os diferentes papeis e eu adoraria muito saber a opinião de vocês sobre eles. Vamos lá:

Não entender nada de tecnologia e de desenvolvimento

Essa é a principal acusação que os desenvolvedores fazem aos designers de interface, planejadores, arquitetos da informação e outros profissionais de UX. Muitas vezes os desenvolvedores estão certos. Vejamos alguns problemas:

Falta de alinhamento com escopo: Os profissionais de UX acham que sempre é possível alterar a interface sem mexer em banco de dados, etc. Nem sempre. Se o projeto, por exemplo, for uma manutenção em um sistema legado, onde apenas a camada de apresentação será alterada, nem sempre dá para tratar as informações de forma diferente como implementada na versão anterior. Tudo depende de como o banco foi estruturado. As vezes dá e as vezes não dá. As vezes o profissional de UX cria uma interface fantástica, muito útil ao usuário, muito fácil de navegar e de encontrar mas não existe tempo hábil para alterar toda a estrutura de banco de dados só para sustentar a tal interface foda. Ou seja, por mais que o profissional de planejamento esteja bem intencionado, ele também precisa seguir o escopo do projeto. Porque os gerentes de projetos e líderes vão cobrar exatamente isso dos desenvolvedores: seguir os requisitos conforme foram definidos. Quer alterar alguma parte do escopo? Então chame os gerentes e o representante dos desenvolvedores para solicitar alterações de escopo e deixar claro pra todos as justificativas de alteração.

Demonstrar na cara do desenvolvedor que você acha que tudo é fácil de ser feito: Profisisonais de experiência de usuário muitas vezes acham que alterar uma interface no meio do projeto é algo “fácil”. Banco de dados são estruturados para serem otimizados de acordo com o que foi planejado. Se um projeto está no meio, muito provavelmente todo o banco já foi modelado e estruturado. É possível alterá-lo? Claro que sim, mas tudo depende do prazo e do tempo hábil para fazer. Não considere e não fique aborrecido se algo não der para ser feito (sempre considerando, prazo, cobrança e tempo hábil). Nem tudo é fácil de ser implementado.

Desconhecer contextos de desenvolvimento: Eu sei o valor que uma busca bem desenvolvida agrega a um projeto. Mas alguns tratamentos finos são muito, muito complexos de serem colocados em prática. Um dicionário de sinônimos (ou tesauro), por exemplo, é uma funcionalidade “linda”. Desenvolvedores precisam lidar com mensuração de carga no servidor, quantidade de consultas, precisam definir se buscas serão pré-indexadas ou não, quantos usuários o servidor aguenta se buscas forem realizadas no mesmo segundo sem derrubar o site, onde ele ficará hospedado etc. Implementar uma funcionalidade “fina” em um site com uma infra-estrutura muito pequena, poderá acarretar em um site muito lento devido a toda carga gerada no servidor. Nestes casos, se aquilo que o profissional de UX planejou for implementado, poderá acarretar em uma experiência de usuário lenta e desestimulante. Em resumo, conhecer o contexto de desenvolvimento é fundamental. E uma boa experiência de usuário no resultado final de um projeto, depende de alinhamento do contexto do projeto.

Desenhar telas sem consultar os analistas: Essa é clássica. Nunca mostre uma interface, wireframe ou o que for ao cliente sem ter certeza que dá pra ser feito, se a informação vai existir em banco, etc. Estamos falando de projetos já fechados. Se você está em fase de planejamento do projeto, apenas certifique que o analista entendeu como será o funcionamento e a natureza do tipo de informação que você pretende printar na tela. Tudo dá para ser feito e não custa nada perguntar e definir com quem vai desenvolver. Não estamos falando em “pedir bença” pro desenvolvedor, estamos falando apenas de alinhar com o que você está em mente. Consultar o desenvolvedor sobre certa implementação não deve fazer você se sentir inferior, com o tempo, você verá que você vai aprender muito sobre como as coisas são desenvolvidas e certas dúvidas que você tem hoje, não as terá no futuro.

Não entender nada de design e experiência de usuário

Esta é a principal acusação dos profissionais de experiência de usuário, arquitetura da informação, etc. Desenvolvedores na maioria das vezes não sabem o que é design centrado no usuário. E sabe o que é curioso? Eles também estão certos. Muitos desenvolvedores são hábeis e excelentes em programação mas desconsideram boas práticas de interface, funcionalidade, etc. Vejamos alguns problemas:

Não seguir boas práticas de desenvolvimento: Muitos desenvolvedores acham que o sucesso de um projeto está no fato de ele “não dar pau”. Ou seja, se tudo “funciona”, se o site não cai, o projeto foi um sucesso. Estes são os piores tipos de desenvolvedores que eu conheço. São capazes de ignorar qualquer outro requisito que não seja os “explícitos”. Deixar de seguir boas práticas de desenvolvimento é deixar de pensar no usuário. SEO, acessibilidade, separar conteúdo da apresentação e outros detalhes do desenvolvimento melhoram a experiência de usuário e nem sempre são requisitos que chegam documentados. Depende do “bom senso” do desenvolvedor. Deixar de seguir boas práticas de desenvolvimento é deixar de pensar no usuário. E muitas vezes os desenvolvedores poderiam fazer algo a respeito mas preferem colocar a culpa na falta de documentação.

Achar que design é apenas deixar uma tela bonitinha: Se você pensa assim, precisa se informar melhor do que é design. Se tivesse um pouco mais de conhecimento saberia que desenvolvimento de software e aplicações web também é uma disciplina de design. E design é feito para usuários. Existem milhares de boas práticas relacionadas a interação do usuário, comunicação de erros, agrupamentos de informação, organização, feedback ao usuário, etc. Design é um conjunto de definições que deve ser centrado no usuário. A tela nem precisa ser “bonitinha” mas precisa ser fácil de usar.

Achar que a atenção a detalhes é frescura: Uma vez ocorreu o seguinte caso: um sistema possuía um grid de resultado de busca com paginação. Se você estava em um intervalo x da paginação (página 15 de 40, por exemplo) e acessasse um dos registros, ao dar backspace ou usar o voltar do browser ou salvar o registro, o usuário era sempre levado a página 1 do resultado de busca. Eu disse que, ao “voltar”, o usuário deveria ser levado exatamente para a página da paginação em que ele estava anteriormente. Um dos desenvolvedores achou aquilo uma “frescura”. Mas são detalhes assim que tornam a vida do usuário útil. Estes detalhes poupam tempo quando pensamos que o usuário do tal sistema faz isso várias vezes ao dia. Imagine que toda vez que o usuário volta para a página 1 da paginação, ele precisa dar pelo menos 1 clique (no mínimo) a mais para voltar na página 15. Pense em quantos cliques e carregamentos de página eu não conseguiria economizar em 15 usuários que trabalham no sistema 6 horas por dia. Entendeu o porque eu preciso pensar no usuário?

Como essa relação pode ser melhor?

Em todos os projetos de sucesso que eu trabalhei, os projetos só foram um sucesso por causa do alinhamento entre os profissionais sobre qual é o objetivo do projeto, e não o objetivo individual de cada um como profissional. E para isso é fundamental todo mundo entender qual será a contribuição de cada um. O desenvolvedor só odeia os profissionais de UX quando estes se acham superiores aos desenvolvedores. Acham que por eles não “entenderem” de design centrado no usuário, não deveriam participar do planejamento. Se você deixar o desenvolvedor entender a importância do trabalho de UX, se mostrar sobre quais bases seu trabalho está fundamentado é bem possível que ele se interesse por boas práticas de desenvolvimento para alcançar seus objetivos.

Já os profissionais de UX odeiam os desenvolvedores quando os mesmos os tratam como ignorantes em TI. Tratam os profisisonais como se não fossem profissionais de “web”, quando na verdade os dois grupos lidam com tecnologia o tempo inteiro. Acham que tudo o que vem dos caras de UX é frescura e tudo o que eles planejam só serve para tornar o projeto mais caro. Profisisonais de UX não precisam ser especialistas em desenvolvimento como você, e eles são muito capazes de compreender como as coisas são gravadas e recuperadas em banco, assim como você. O que é necessário é treiná-los para entender mais sobre desenvolvimento e fugir das pequenas armadilhas do dia a dia.

Não estou falando que todo profisisonal de experiência de usuário precisa estudar programação e nem que todo desenvolvedor precisa ser especialista em arquitetura da informação. Mas eu defendo que os dois lados precisam conhecer melhor a especialidade do outro. Cursos e workshops de tecnologia, desenvolvimento e experiência de usuário irá agregar muito em todos os times. Um não é mais importante que o outro, porque um trabalho excelente nunca vai existir sem um desenvolvimento decente e uma boa usabilidade.

TI influencia na experiência final

Veja abaixo apenas 3 exemplos de como a forma com que um site é desenvolvido pode contribuir ou atrapalhar a experiência que o usuário terá:

• Site lento: Implemente cache, etags, expire header, reduza o número de consultas o quanto for possível. Isso é tão sério do ponto de vista do usuário que o Google resolver atualizar o algoritmo do pagerank e colocou o tempo de carregamento como um fator importante para a relevância de um site. Sites mais lentos faz com que os usuários permaneçam menos tempo navegando dentro deles.
• Acessibilidade: Desde atribuir o pseudo elemento :focus no CSS até fazer com que um formulário funcione sem javascript, são implementações que melhoram a acessibilidade para os usuários. Já navegou com a tecla tab em um site que não possui o :focus definido? Acessibilidade não é só para cegos.
• SEO: SEO não são macetes para trapacear com os mecanismos de busca. SEO trata-se de fazer com que seu site seja mais amigável para os mecanismos de busca, para que consequentemente seja também mais fácil de ser encontrado pelos usuários que precisam da informação que o site que você está desenvolvendo possui. Isso chama-se “encontrabilidade”. A forma com que o conteúdo do site é tratada (semanticamente falando) pode facilitar (código semântico) ou dificultar (código porco dependente de JavaScript) o acesso ao mesmo.

Pronto, desabafei! Até a próxima!

Comentários: 14

Como eu entrei no mundo do desenvolvimento para web!

Por: Henrique Pereira

Categoria: Pessoal

Muitas pessoas já perguntaram como eu entrei no mundo dos padrões web, desenvolvimento, experiência do usuário, design de interfaces, etc etc etc. Me perguntam se eu fiz cursos, faculdade ou como eu aprendi as coisas com as quais eu trabalho no meu dia a dia. Faz tempo que eu queria escrever um texto sobre isso mas me perguntava se poderia ser útil para o blog. Ainda tenho minhas dúvidas. Mas dessa vez vou considerar que será uma reflexão pessoal e profissional dos caminhos que eu percorri até agora, nos meus quase 31 anos de idade. Cada um tem sua história e abaixo é a minha.

Eu cheguei na web devido ao meu interesse por arte e filosofia. Fim do post, pode ir embora. Brincadeira. Mas é sério, eu cheguei aqui porque desde moleque eu era apaixonado por arte em geral, quadrinhos, filosofia, história, fotografia e por ai vai. Eu estudei desenho aos 12 anos com um italiano (ou descendente, sei lá) chamado Luiz Cesar Raniero Spini, cara este que eu adoraria reencontrar pra bater um papo, ele me marcou muito. Nem faço idéia de onde ele está e nem se está vivo. Descobri pelo Google apenas que ele escreveu um livro de poesias e só! Com ele eu aprendi sobre luz e sombra, como apontar um lápis de forma decente (eu tive 1 dia inteiro de aula só sobre como apontar lápis de desenho), tipos de papéis (sério, eu estudei muito papel), desenho com carvão, natureza morta, tinta nanquim, desenho de observação, proporção, textura, etc. Com aquelas aulas eu conectava vários pontos relacionados com desenho, e o todo começava a fazer mais sentido.

Dos 13 aos 16 eu me afundei (no bom sentido) nos livros por influência da minha mãe que me levava pra passear na biblioteca desde os 6 anos de idade, como se lá fosse o maior parque de diversões da Terra. E eu realmente gostava de bibliotecas. Mas minha educação escolar, apesar de nunca ter repetido de ano, era meio “abandonada”. Abandonada por falta de guias. Eu não era influenciado pelos professores e não os via como “guias”. O primeiro e único professor que realmente marcou minha educação foi o Fernando Pessoa (não o escritor), que foi meu professor de literatura no primeiro colegial. Esse sim me dava desafios e me fazia ver as coisas com outros olhos. Esse cara é outro que eu adoraria reencontrar pra bater um papo. De resto, eu aprendia linkando as coisas sozinho, em uma era sem internet. Achei Anne Frank estudando o Nazismo, que me levou pra história disso e daquilo, que me levava pra outro lugar, e pra outro livro e assim por diante. Fui me conectando e pulando de link em link.

Eu li muita merda e muita coisa que me marcou porque eu não tinha um “guia” e a internet não existia. Então eu fazia as perguntas e ia pra biblioteca tentar respondê-las. Você consegue se lembrar de quando o Google não existia? Como você respondia as dúvidas que você tinha? Quando eu tinha uma pergunta naquela época eu anotava ela em um papel e esperava dois ou três dias pra ir na biblioteca tentar respondê-la. O melhor exercício que eu fazia era escrever em um caderno os resumos e considerações de tudo o que eu lia. Eu achava que escrevendo eu aprendia melhor.

Dos 16 aos 18 eu estudei Carl Yung e Sigmund Freud e adorava colocar os dois para brigar um com o outro na minha cabeça, tentando escolher quem eu mais gostava. Li o Diário de Anne Frank e me apaixonei pelas reflexões de uma criança escondida em uma casa por causa da perseguição nazista. Lia os diários de navegação de Amir Klink e sabia tudo sobre Jack Cousteau (que era meu herói). Era fã de Cosmos, de Carl Sagan, lia sobre fotografia, Gestalt, Guilherme de Occam, Sherlock Holmes, Santo Agostinho, Nostradamus (eu não disse que eu lia alguma merda em meio a coisas de muita qualidade?), Richard Bach, histórias da idade média, Batman, Star Wars, estudei um pouco de percussão (nunca foi pra frente) e me apaixonei por computadores.

Com 18 anos eu comecei a trabalhar com mídia impressa. Eu trabalhava com vetorização de arte para material publicitário. Preparava fotolitos, impressão laser, impressão para silk, cartaz, impressão em material publicitário como canetas, canecas, chaveiros, etc. Entrei na faculdade de artes plásticas e um ano e meio depois entrei em filosofia na UFU em Uberlândia. Fiquei 4 anos e pouco na universidade e não me formei em nenhum dos dois cursos. Sabe o que eu fazia esse tempo todo lá dentro? Estudava só aquilo que me dava prazer e faltava as outras aulas. Nunca consegui estudar cerâmica, que era uma das aulas de início do curso. Alguns problemas pessoais contribuíram pra minha saída, mas o fato é que mesmo depois desses 4 anos eu nunca deixei de estudar as coisas que tenho interesse.

No começo da faculdade eu tinha que trabalhar como “chapa” naquelas lojinhas de 1,99. Pegava minha grana inteira e compra em livros de fotografia, filosofia e arte, além de papeis, lápis importados e tinta nanquim. Me apaixonei por astronomia e comprei um telescópio. Aprendi inglês ouvindo música, lendo os quadrinhos importados que demoravam a chegar por aqui (com dicionário na mão) e eventualmente servindo de intérprete para gringos que vinham ao Brasil naqueles encontros de igrejas protestantes. Ah, detalhe, isso foi na mesma época em que eu estudei 3 anos de teologia sistemática e fiz parte de uma comunidade religiosa (longa história). Cheguei a começar a estudar um pouquinho de grego koiné. Superei essa fase, apesar do grande aprendizado, e hoje sou ateu (ou quase isso, não importa).

Depois me apaixonei pela mitologia grega e pelos gregos. Li Paideia, a formação do homem grego, e fiquei viciado em história antiga. Estudei muita história do mundo, do ocidente ao oriente, história da arte, da física (apesar de até hoje ser muito fraco em matemática). Aprendi a gostar de Jazz e cada vez mais de rock ‘n roll. Adorava desenhar ou escrever ouvindo música. Na faculdade eu frequentava as aulas de estética (um dos braços da filosofia), astronomia, teoria do conhecimento (também conhecido como epistemologia), métodos de pesquisa científica, produção de textos, cinema, fotografia, teoria da arte, teoria da educação em arte, literatura, desenho 1 e 2, antropologia e outras cositas mas. Publiquei e dei aula de história em quadrinhos por 2 anos. Fiz freelas como redator em uma agência em Uberlândia. Fui professor de história voluntário por 2 anos para adultos que pararam de estudar e queriam concluir o colegial. E essas coisas iam me fazendo, de uma maneira ou de outra, ir estudando somente as coisas que eu gostava.

Em 2004 eu já fazia freelas como web designer e logo entrei na Webroom pra trabalhar ao lado de um cara chamado Edson Simão Júnior, que explodiu minha cabeça me mostrando um negócio chamado Tableless. Com o “Edinho” (apesar do diminutivo é um cara de quase 2 metros de altura) eu aprendi a ser “pro” no desenvolvimento para web, e que não bastava só saber fazer uma página “funcionar” usando um editor de HTML, você precisava entender o que está acontecendo por trás daquilo. E, modéstia a parte, eu já era especialista em “entender” o contexto das coisas por causa de todas as outras coisas que eu já tinha estudado na vida. O melhor de trabalhar com ele naquela época é que ele era gente fina pra caralho e tudo o que ele fazia era melhor do que o que eu fazia. E isso pra mim era o máximo. Ele não tinha medo de me ensinar e eu não tinha medo de aprender. Ele era experiente e eu estava aprendendo a ser “pro” com ele. Ele ficou um tempo fora de web e acabou voltando um tempo depois. Hoje nós ainda trabalhamos juntos e esse é um dos caras que eu ainda tenho o privilégio de sempre que eu quero, bater aquele papo. Há pouco tempo eu convenci ele a entrar no mundo dos blogs e se eu fosse você, assinava o feed dele, vai aprender muita coisa.

Desde então eu estudei e li uma porrada de coisas relacionadas com design centrado no usuário, tipografia, design de interface, teoria do design, acessibilidade, grids, cores, antropologia, funcionamento da relação cliente servidor (client side / server side), como funciona a infra da internet, marketing digital (tá certo, é tudo comunicação integrada), direito digital, links patrocinados, métricas, usabilidade, desenvolvimento para dispositivos móveis, fotografia, tesauros, semântica web, linguagens de marcação, CSS e uma porrada de coisas que sempre ficam de fora das listas.

Sabe porque eu contei essa história (chata para a maioria das pessoas)? Porque eu não consigo separar o que eu sei sobre desenvolvimento para web de todas as outras coisas que eu já estudei. Cada um dos meus vícios influenciam diretamente no meu interesse por tecnologia. Eu tenho muita dificuldade de focar somente em uma coisa só. Simplesmente porque eu acredito que aprender uma coisa só é se perder do todo.

Eu adoro dar o exemplo do que eu acredito ser a melhor formação de um “designer de interface”. Se você constroe interfaces para serem “consumidas” na web, você precisa estudar cor, entender como aquilo vira código (HTML + CSS), saber de boas práticas de acessibilidade, como aquilo é mensurado (métricas), ter um belo conhecimento de grids (Design), como as pessoas se relacionam com ambientes de informação (arquitetura da informação), como aquele conteúdo é discutido na web (mídias e redes sociais), técnicas de redação e geração de conteúdo, como aquilo pode ficar mais leve (técnicas de otimização), como ele é indexado (SEO), por onde o usuário chega no site (landing pages) etc. Não ache que manjar de Photoshop fará de você um web designer foda. E isso vale para todas as áreas relacionadas com desenvolvimento pra web: se ficar só com os conhecimentos do seu campo de estudo, você sempre vai se perder do todo.

Eu ainda tenho um monte de coisas pra aprender. Essas que eu descrevi aqui é apenas um resumo rápido dos meus primeiros 30 anos de idade. Estou em formação e meus vícios vão continuar me ajudando com isso. Agora eu estou começando os próximos 30. Nos vemos por aí.

Comentários: 18

Book Review: Refatorando HTML – Como melhorar o projeto de aplicações web existentes

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript, Reviews

Já ouviu falar de refatoração? Refatoração é a melhoria gradual de trechos de código sem alterar o comportamento da aplicação web, site, sistema, etc. O objetivo é remover problemas de código antigo e/ou ilegível (difícil de dar manutenção) para código mais moderno, claro e mais fácil de manter e de realizar manutenções evolutivas.

Dentre as razões para refatorar código podemos notar, por exemplo, a melhoria da acessibilidade, otimização de mecanismos de busca, performance, redução do tamanho de arquivos de HTML e CSS, tornar o código mais claro e fácil de dar manutenção, dar suporte a um novo browser, etc. Refatoração se faz necessária quando você precisa evoluir uma aplicação web mas você não tem dinheiro, tempo ou pessoal suficiente para reescrever a aplicação do zero. Estou falando de aplicação web, mas pode muito bem ser um blog, site institucional, etc.

Li recentemente o livro Refatorando HTML – Como melhorar o projeto de aplicações web existentes (Do original Refactoring HTML: Improving the Design of Existing Web Applications, Ano 2010, 360 páginas, ISBN 9788577806317) do autor Elliotte Rusty Harold publicado pela editora Bookman e achei muito bom e tenho algumas considerações.

Refatoração se faz necessária quando você precisa evoluir uma aplicação web mas você não tem dinheiro, tempo ou pessoal suficiente para reescrever a aplicação do zero.

O livro pode ser encarado como guia de consultas rápido ou um livro de estudo com uma abordagem muito curiosa. Ele tem uma abordagem focada em problemas a serem resolvidos e não na teoria. Ao invés de focar em conceitos, o livro pega dezenas de problemas do mundo real que precisam ser resolvidos e traça estratégias de resolução associando aos conceitos necessários.

Essa abordagem faz com que esse livro não seja indicado a iniciantes. Se você quer começar no mundo do desenvolvimento existem livros mais apropriados. Este é um livro para desenvolvedores intermediários e avançados. E acredite, o Refatorando HTML tem muitas abordagens maduras relacionadas a semântica de HTML, acessibilidade, performance, cache, validação etc.

O livro tem uma divisão lógica excelente. Veja abaixo a estrutura de capítulos:

Capítulo 1 – Refatoração: Descreve o que é refatoração e as razões contra e a favor. Uma aula conceitual sobre o assunto.

Capítulo 2 – Ferramentas: Analisa várias ferramentas de desenvolvimento e a contribuição de cada uma no processo de refatoração. São ferramentas de expressão regular, edição de HTML, validação, etc.

Já os capítulos 3 a 8 são divididos respectivamente pelos assuntos Documentos bem formados, Validade, Layout, Acessibilidade, Aplicações web e Conteúdo. E todos esses capítulos seguem a seguinte estrutura de tópicos:

1. Descrição / Problema: explica qual é o tipo de problema relacionado ao assunto do capítulo
2. Motivação: considerações e defesa sobre o porque é importante refatorar nesse tipo de situação / problema
3. Potenciais perdas e ganhos: considerações que não podem ser ignoradas ao refatorar determinado tipo de problema.
4. Mecânica: Descrição prática (com exemplos de código) de como resolver o problema descrito.

Enfim, achei o livro excelente e me surpreendeu. No início achei bem chato, pra ser sincero, devido a essa abordagem muito prática. Mas depois que você entende a razão e a organização do livro, percebe que é a abordagem que faz toda a diferença. Vale a pena adquirir principalmente se você trabalha com equipes de desenvolvimento que dão manutenção em aplicações web.

O livro “Refatorando HTML” pode ser adquirido no site da própria Bookman ou no Submarino.

Comentários: 4

Seeding mal feito é spam

Por: Henrique Pereira

Categoria: Internet / Web, Marketing / Comunicação

Sabe o que é seeding? Seeding é disseminar uma informação na web, “espalhando” ela em vários lugares possíveis, principalmente fazendo uso das chamadas “mídias sociais”, como redes de relacionamento e blogs. Já recebeu aqueles convites de festas (com cartaz geralmente) nos comentários do Orkut e você descobre que aquele cara deixou o mesmo comentário em vários profiles ao mesmo? Isso é seeding. Já recebeu algum comentário no seu blog divulgando uma URL e a mensagem termina dizendo “visitem meu site” e blá blá blá? Isso é seeding. E basicamente, se tornou sinônimo de spam. Agora veja a imagem abaixo:

A imagem acima mostra 3 comentários que não foram aprovados dentro do meu WordPress. Os 3 comentários foram enviados do mesmo computador (veja os IPs logo abaixo da URL) apesar da pessoa ter usado um nome diferente em cada comentário. Os comentários foram submetidos apenas com alguns minutos de diferença entre eles e o que todos tem em comum é que eles são completamente irrelevantes.

O que o autor desse comentário tentou fazer, foi um “seeding” para otimizar a URL dos 3 sites dele, de forma barata e burra. Se ele soubesse que existe um “nofollow” em todos os links inseridos nos comentários do Revolução Etc, ele não teria perdido o precioso tempo dele aqui. Isso é basicamente uma estratégia de SEO porca e mal feita. Recebo dezenas desse tipo de comentário por dia e todos vão para o lixo.

Seeding precisa ser bem feito e relevante pra eu topar deixar aqui no blog. Meu ego não se enche com “seu blog é legal”, “excelente post”, etc. Isso é irrelevante e não vai fazer os leitores se interessar pelos comentários. A conclusão mais simples que você precisa chegar é: seeding é o spam das caixas de comentários dos sites e blogs. Precisa otimizar seu site para alavancar seu negócio na web? Seja relevante e estude outras formas de fazer isso. A prática de SPAM só prejudica seu negócio.

Para saber mais sobre seeding, leia este texto aqui escrito pelo Cardoso e vai seguindo os links.

Comentários: 27

WaSP Interact – Curso gratuito de desenvolvimento para web

Por: Henrique Pereira

Categoria: Design, Experiência de usuário, HTML / CSS / JavaScript, Internet / Web

Já ouviu falar do pessoal do Web Standards Project, certo? Então, já faz um tempo que os caras criaram o WaSP Interact, um site de e-learning gratuito para profissionais de web.

O objetivo do WaSP Interact é agrupar material de quadros curriculares com competências que profissionais de web devem ter, seguindo boas práticas em cada uma das disciplinas. O curso é dividido em 6 fases que são, fundamentos, desenvolvimento front-end, design, ciência do usuário (Experiência do Usuário), desenvolvimento server-side e práticas profissionais. As disciplinas seguem uma ordem de competências que o estudante precisa conhecer antes de pular para a próxima disciplina.

A iniciativa tem parceria com o Opera Web Standanrds Curriculum, que inclusive utiliza parte do conteúdo produzido por eles. O restante do conteúdo dos cursos é todo produzido pelo membros e colaboradores do Web Standards Project. E isso é uma garantia de que o conteúdo é produzido por excelentes profisisonais do mundo inteiro.

Quem acha que, pelo fato de ser coordenado pelo Web Standards Project, o foco dos cursos será somente HTML e CSS, está enganado. Eles tem módulos de design, arquitetura da informação, design de interação, gerência de projetos, produção de conteúdo para web dentre outros. Os cursos não são de “tecnês” e trazem excelentes conteúdos teóricos. Pra quem sabe estudar sozinho e sabe inglês, é o ponto de partida perfeito para quem quer se tornar um profissional de desenvolvimento para web.

Comentários: 5