Introdução· Decidir· Analizar· Organizar· Melhorar· Rever· Manutenção·
QA Homepage· Latest News· QA Resources· QA IG· QA WG· QA Calendar·
Esta é a tradução do artigo "Web Standards Switch - or how to improve your Web site easily" de autoria de Karl Dubost publicado no site do W3C.
1. A versão oficial e original, em inglês, deste tutorial, encontra-se em: http://www.w3.org/QA/2003/03/web-kit e os seus direitos são conforme:
Copyright ©2002 W3C® (MIT, INRIA, Keio), Todos os direitos reservados. São aplicáveis as disposições do W3C relativas a responsabilidade, marcas, uso de documentos e licença de software
2. A única versão oficial deste documento é a versão em língua inglesa que se encontra no sítio do W3C.
3. O presente documento traduzido para a língua portuguesa do Brasil, pode conter erros de tradução.
Este documento foi traduzido em 05 de janeiro de 2005 por: Maurício Samy Silva e encontra-se hospedado no seu sítio "CSS para WebDesign" em http://www.maujor.com/
A traduçao foi feita somente para este documento, vale dizer, as páginas remetidas pelos links aqui indicados, estão em sua versão original em língua inglesa.
Este artigo foi escrito para fazer parte das publicações do grupo de trabalho Quality Assurance Interest Group do W3C. Qualquer comentário sobre este artigo poderá ser enviado para um arquivo público através da lista de discussão public-evangelist@w3.org ou via uma mensagem privada para karl@w3.org.
O autor agradece aos colaboradores que dedicaram seu tempo para revisões e sugeriram idéias para este artigo.
Traduções para este documento são bem-vindas. Antes de começar sua tradução leia as informações sobre traduções, em Copyright FAQ, e confira a lista das traduções existentes para este documento(disponível em http://www.w3.org/QA/translations#switch).
Seja você um administrador, um desenvolvedor Web, um membro do depatamento de Marketing ou de Comunicações ou talvez um Web master individual, você já deve ter lido sobre Web standards. Você deve ter entendido que as standards são benéficas ao seu Web site em termos de custos, facilidade de manutenção e rentabilidade, e, assim, você decidiu mudar - adequando seu Web site para as standards.
Infelizmente, você não encontrou um guia explicando por onde começar e como organizar o processo de migração para tornar seu Web site em conformidade com as standards. Você deve estar pensando que o fato do seu site ser muito grande torna esta tarefa impossível. Se você tem alguma dúvida sobre o que é Web standards nós o convidamos a ler o que significa Web standards [WEB-QUALITY], como adquirir e desenvolver um Web site de qualidade [REQ-WEBAGENCY], e porque um Web site accessível [WAI-PROFIT] e rentável.
O método proposto neste documento é válido para Web sites de qualquer tamanho e preenche suas necessidades quer elas sejam para um site individual de um pequeno negócio, quer para um enorme Web site corporativo.
Nós o guiaremos passo a passo - habilitando-o a cumprir por si mesmo cada um deles - desde a análise do web site existente até a organização do seu novo Web site. Cada um dos passos foi projetado de maneira estanque, podendo ser cumprido de forma gradativa, em diferentes níveis e por diferentes pessoas, independente do grau de conhecimento de cada uma delas, mas tudo de acordo com um fluxo de trabalho.
Seja grande ou pequeno, o seu Website deve ser inicialmente avaliado contra as standards; provavelmente uma considerável quantidade de páginas não estará de acordo com os critérios de qualidade estabelecidos para seu Web site.
Reuna os departamentos de comunicações, técnico, marketing e administradores, com o objetivo de se criar uma lista de itens a serem avaliados no Web site. Nesta fase do trabalho não há necessidade de priorizar as soluções a implementar, mas pelo menos checar a validação (HTML e CSS), a acessibilidade e os critérios de internacionalização do website. Explicaremos mais adiante algumas técnicas relacionadas.
Este artigo esta focado na melhoria do seu web site de acordo com as W3C standards, mas, você poderá usar esta estratégia para tornar seu site em conformidade com qualquer outra norma ou diretriz. Abaixo uma proposta simples de lista de verificação:
Em alguns casos, nem você e nem qualquer membro da sua equipe tem o conhecimento sobre os diferentes aspectos do web site; se for este o seu caso, peça ajuda. Convide um especialista em acessibilidade ou internacionalização para fazer parte da equipe. Exemplificando: considerando os critérios de acessibilidade (a maneira como as pessoas com necessidades especiais acessam o seu site), você pode pedir ajuda a uma entidade local, tal como um instituto para cegos - na maioria dos casos eles ficarão felizes por poder ajudá-lo. Se você pertence a uma grande corporação é muito provável que existam funcionários portadores de necessidades especiais. Vá ao seu departamento de recursos humanos e sugira a participação deles no seu projeto.
Agora que você já tem conhecimento do que irá testar, você deverá localizar os problemas existentes no Web site. Uma boa maneira para começar é criando uma lista de URI's que pertencem ao site. Isto não é um processo complicado - um simples "spider" capaz de varrer os links e relacioná-los em um arquivo de texto (por exemplo: uma URI em cada linha) é o suficiente) .
Poderá ocorrer que as tecnologias usadas no seu Website bloqueiem "spiders"; isto pode constituir-se em um meio de determinar quais páginas do seu Web site são inacessíveis. Basicamente este exercício lhe mostrará quais páginas estão bloqueadas aos mecanismos de buscas e não poderão ser indexadas, significando ainda que também estão bloqueando e reduzindo tráfego para seu site.
Uma vez que você tenha feito a lista das URIs, poderá usar o LogValidator [LOG-VALIDATOR], que é um programa projetado especificamente para auxiliá-lo no processo de testes. O LogValidator, quando alimentado por uma lista de URI's procede a uma análise segundo um módulo pré determinado por você ao iniciar os testes. (O módulo de testes deverá ser discutido em conjunto com a equipe técnica com o objetivo de determinar como implementá-lo de forma a atender as configurações do site). Para cada URI aplica-se uma série de testes e são retornados os resultados correspondentes.
Concluida esta primeira análise, você terá um mapa dos problemas no Web site, ficando então em condições de definir uma estratégia de trabalho visando a corrigir os problemas. Você poderá ter uma considerável quantidade de páginas não conformes com os critérios estabelecidos. Por exemplo; todas as páginas poderão ser inválidas para HTML ou XHTML. Mas não se preocupe - isto na verdade é uma grande notícia! - Por que? Porque se você usa um gerador de templates ou um gerenciador de conteúdos no seu Web site é muito provável que eles estejam gerando os erros nos templates.
A solução é simples; corrija os erros no template e rode o teste novamente; o número de erros deverá ser menor, ou, talvez, até mesmo não haver mais qualquer erro. Se não foi você quem desenvolveu o CMS (NT: Sistema Gerenciador de Conteúdos) para o Web site, peça para a pessoa ou pessoas que o desenvolveu para corrigir os erros. No futuro quando ocorrer o re-design do Web site siga as recomendações contidas no documento Buy standards compliant Web sites (Compre Web sites que cumpram as standards) [REQ-WEBAGENCY].
Se persistirem erros após este primeiro passo, não se preocupe - esta matéria foi escrita para ajudá-lo nas correções.
Este primeiro passo tem um benefício adicional que é o de proporcionar uma idéia concreta do conjunto de todas as páginas do Web site, isto significa que se você decidir mover uma página ou suprimir uma seção do Website, terá uma visão bem melhor de como redirecionar para novas páginas, consequentemente não perdendo tráfego vindo de links externos (tais como, links de outros Web sites e os dos mecanismos de busca). Lembre-se, boas URIs não "quebram".
Você, agora, está de posse de uma lista de todas as páginas que não validam ou que tem qualquer outro tipo de problema ou erro. O método aqui descrito e explicado não se altera quer a lista seja longa ou curta. O primeiro princípio é simples: "Não corrija! Aperfeiçoe - organize seu trabalho "
Não é necessário corrigir tudo de uma só vez no Web site, por duas razões principais:
E mais, não tente isolar e corrigir uma determinada categoria de erros separadamente deixando outros erros para correção posterior. Por exemplo; você pretende validar o HTML e tornar acessível suas páginas - realize as duas validações ao mesmo tempo - Se você validar um após o outro, poderá, no segundo ciclo da validação, introduzir erros nas páginas validadas anteriormente.
Resumindo: Não corrija tudo de uma só vez, não corrija por ciclos - Aperfeiçoe seu processo.
A chave do sucesso deste método consiste em ser realista ao tomar-se decisões, e assegurar-se que estas decisões tragam resultados efetivos. Se você pretende melhorar suas páginas Web deverá estimar o tempo necessário por página para a correção dos problemas já identificados. Tome como base de estimativa algumas páginas com problemas em comum no Web site e leve em consideração os conhecimentos da equipe e os recursos disponíveis para o fluxo de trabalho.
Feita uma estimativa de tempo para uma pequena quantidade de páginas, você estará em condições de dimensionar pessoal e recursos a alocar para a tarefa, bem como, determinar realisticamente a quantidade de páginas a corrigir por dia.
Nós o incentivamos a estabelecer uma taxa de correção diária em lugar de estabelecer uma taxa semanal. Isto facilitará o trabalho de planejamento do tempo pelo responsável pela correção além de demandar menos tempo por dia que por semana. É mais fácil e menos desgastante corrigir 5 páginas por dia do que 25 páginas em um dia ao longo da semana.
Faça reuniões periódicas com a equipe envolvida no processo; peça opiniões, incentive argumentações e tire proveito de experiências individuais no assunto. Isto vai ajudá-lo a determinar se os problemas são provenientes do CMS (Sistema de Gerenciamento de Conteúdos) ou do processo usado para editar as páginas. Você estará apto a aperfeiçoar tanto o processo, quanto a qualidade das ferramentas usadas.
Decorrido algum tempo e baseado na experiência adquirida com a implementação deste método, você estará apto a fixar metas. Por exemplo; 50% do tráfego do Web site chega a páginas que estão em conformidade com os critérios que foram estabelecidos. Quando esta meta for atingida você poderá estabelecer nova meta em 60% e assim por diante. Para o que você decidir, seja testar, seja alcançar, estabeleça uma meta racional e pequena; este método preconiza progressos e melhorias em escala contínua e acessível.
Para tornar seu projeto um verdadeiro sucesso, você deve integrar à equipe de tabalho cada pessoa que faça parte do processo de publicação. O entendimento das ferramentas utilizadas neste método que estamos desenvolvendo o ajudará a identificar de onde estão vindo os problemas surgidos — é um problema criado pela ferramenta ou pela pessoa que usa a ferramenta? Quando a ferramenta gera os erros, será de grande ajuda fazer os comentários e negociar com os criadores da ferramenta a melhoria do seu software. Isto é particularmente verdadeiro no contexto de uma grande empresa, onde há uma razoável quantidade de usuários; esta é a forma mais inteligente de se assegurar que as melhorias poderão ser realizadas.
Publique as melhorias - se não para o público em geral, pelo menos para a equipe. Isto mostrará os progressos alcançados e motivará cada um a continuar. Se você já identificou os problemas existentes no sistema de publicação, a tendência é só de melhorias daqui para frente.
O LogValidator [LOG-VALIDATOR], que já foi citado anteriomente nesta matéria vai ajudá-lo a melhorar seu site, identificando as partes do Web site que apresentam falhas. No seu modo "default", esta ferramenta foi projetada para checar progressivamente a validade do HTML dos documentos. Seu princípio básico é direto: de posse de um arquivo de registros do servidor (server log file), a ferramenta lista as páginas mais visitas por dia, em ordem decrescente, e, tomando as primeiras n páginas da lista assim ordenada (onde n é um número especificado por você), as envia ao Validador de marcação do W3C. Em seguida você receberá os resultados da validação.
Quais são os benefícios? Por este caminho, você corrige primeiramente as páginas mais acessadas, melhorando seu web site sob o ponto de vista do tráfego - não em termos de número absoluto de páginas.
O LogValidator tem uma arquitetura aberta e modular escrita em Perl e você está livre para desenvolver o módulo que quiser de acordo com suas necessidades. Por exemplo; você poderá desenvolver um módulo para correção ortográfica ou um módulo para checar se as informações de logotipo e rodapé estão corretas nas páginas ou talvez um módulo para verificação de links dentro do próprio site. Esta ferramenta é de fácil instalação e é parte dos arquivos CPAN.
O número de possibilidades é indeterminado, então é melhor ficar na real quando pensar em objetivos a atingir.
Ao optar pelo uso do LogValidator, existem diferentes formas de procedimento e de análise dos resultado obtidos. Por exemplo; você poderá automatizar o envio de e-mail matinal para a equipe de garantia de qualidade, informando uma lista de URIs que merecem atenção e a equipe terá que responder informando a solução ao problema ou se o problema é de outra área.
Este método passo a passo ajudará a manter a qualidade do Web site, mas você deverá verificar regularmente a ocorrência de problemas.
A intervalos regulares (de três em três meses por exemplo), repita toda a análise; isto vai ajudá-lo a saber se você progrediu na qualidade geral do Website e também a determinar a existência de problemas com o seu gerador de templates. Também será uma valiosa ajuda na consecução dos objetivos estabelecidos ao início do processo. Se a qualidade do seu Web site não estiver aumentando, isto é indício de que há algo a ser corrigido no processo.
Mostrando os progressos alcançados, finalmente estará recompensado o trabalho da equipe, das pessoas envolvidas neste esforço. Pouco a pouco você irá adquirindo experiência que será benéfica para sua empresa. Paralelamente ao trabalho de revisão, anote tudo o que foi realizado e publique. Isto se constituirá em um manual atualizado sobre a qualidade do seu web site.
É comum a existência de um manual definindo estilos e a política da empresa para logotipo e uso de cores. Acresente a este manual algumas técnicas simples para auxiliar as pessoas a melhorar o Web site quando ocorrer um erro.
O método aqui descrito não é uma diretriz estática e rígida, ele é dinâmico; evolui de acordo com suas necessidades. Se o seu sistema de publicação tem facilidades não relevantes ou mesmo novas facilidades são adicionadas, será necessário ajustes no processo, para garantia da qualidade.
A solução para avaliar e melhorar a qualidade, conforme estamos propondo, passa pela compartimentação dos componentes em entidades estanques e não dependentes umas das outras, assim, você poderá remover componentes existentes ou acrescer novos componentes, sempre que for necessário.
Poderá ocorrer o caso em que um determinado problema não possa ser resolvido de imediato porque a solução não depende somente de você. Por exemplo; quando você usa uma ferramenta que gera código inválido. Você já tentou métodos alternativos, já tentou "workaround", mas nada resolveu. Faz-se necessário coletar todas as informações possíveis e encaminhá-las ao fabricante do produto, não como uma solicitação individual, mas com a assinatura da sua empresa. Você representa uma fatia do mercado consumidor e o fabricante da ferramenta irá considerar o pedido.
Para manter a qualidade do seu site você deve recompensar os bons autores internos e ajudar aqueles com maiores dificuldades. Não haverá sucesso se os usuários não usufluirem dos benefícios trazidos pelo método que você escolheu. Convide e motive seus usuários a reportar problemas encontrados com o processo, ferramentas, etc. Isto trará melhorias para toda a empresa.
Este método é simples e tem sido aplicado há anos no W3C na área de HTML, ele tem nos ajudado a manter todas as páginas válidas. Este método pode ser muito poderoso se você usá-lo na sua própria empresa ou equipe.
Obrigado às pessoas que fizeram revisões neste artigo: Olivier Théreaux, Stephanie Troeth, Denis Boudreau e ao pessoal da public-evangelist mailing-list.