Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)

30 outubro, 2005

Candidaturas à Presidência e Web Standards

Nem na porra de páginas acabadinhas de fazer... O João Craveiro, colocou no seu site uma página muito semelhante à página da candidatura de Cavaco e Silva à Presidência da República. Às vezes faço uma leitura demasiado apressada e dá nisto. Vejo uma simulação melhor que o original. E gosto do que vejo (não não estou a falar de política, mas do código da página simulada). Só então reparo que aterrei primeiro na simulação. Depois vou ver a página oficial e... Está à vista que nada mudou continuamos a apertar porcas com chaves de fendas na construção de websites. Penso que os construtores de websites devem ter necessidade de alguém que lhes ensine que uma chave de fendas não serve para apertar uma porca e que uma tabela num website deve ter informação tabular e não deve ser usada para criar arranjos de páginas. Ou será que quem a fez nunca olhou para as especificações do W3C e de algumas explicações para o uso correcto dos elementos num página (e já agora respectivos atributos). Os defeitos que o João encontou no sítio oficial, encontram-se nos sítios dos restantes candidatos (Soares, Manuel Alegre, Manuela Magno (chega a ter páginas com duas(?) declarações DOCTYPE [é um site assinado por uma empresa, provavelmente a evitar, se a qualidade dos restantes sítios for semelhante]), Francisco Louça. Jerónimo de Sousa é um caso à parte usa frameset e tabelas. É claro que é um site para não ser visitado via telemóvel. Já agora em alguns dos restantes também nada se vê por terem posto botões gráficos em vez de texto (com eventual subsituição/sobreposição) para dispositivos que os pudessem apresentar. Não digo que apliquem técnicas semelhantes às do Stu Nicholls para simular frames, ou as técnicas para criar um arranjo harmonioso de com várias colunas, as do João devem são adequadas e perfeitamente nacionais. Só não digo para o contratarem pois pode acabar por gastar algum tempo mais do que os 45 minutos que investiu na criação do seu modelo. Aliás as candidaturas parecem achar que não vale a pena sequer o esforço de permitir o acesso a partir de dispositivos alternativos como os telemóveis ou os televisores. Quase que me apetece fazer versões de texto, sem grafismos, com som, para cada uma das candidaturas. A candidata Manuela Magno tem o sítio alojado num servidor lento ou então com muitos hop entre mim e o site dela (demora muito mais do que 15s a ter algo de útil para ver). A candidatura de Mário Soares tem um títulos(?) com umas cores com baixo contraste

29 outubro, 2005

410

Erro 410 HTTP: Deixei de estar acessível (fui eliminado ou não me querem dar acesso)

O erro 410 do protocolo HTTP é um afilhado do erro 404 (Recurso não encontrado). O erro 410 significa que o recurso deixou de ser acessível, ou seja, existia aqui um recurso neste local, mas deixou de existir. Não só deixou de existir, mas não sei (ou não lhe quero dizer) para onde foi. Se soubesse e lhe quisesse dizer, então utilizaria o erro 301 (redirecionamento permanente) e qualquer cliente inteligente simplesmente apontava para o novo endereço. Mas o erro 410 significa que o recurso desapareceu e não há endereço de reendereçamento.

Não há assim tanta informação sobre o erro 410 facilmente disponível. Se efectuar uma busca no Google pelo erro 410 vai encontrar uma série de páginas onde o erro foi gerado. Há poucas páginas que dão uma pequena descrição do erro mas visto esta condição não ser muito frequente (ou não ser usada com frequência) pouco mais é dito. Além disso parece que todos tivemos uma lavagem ao cérebro acreditando que todos os recursos devem ser permanentes o que não é verdade.

Usar o erro código 410 do HTTP significa aceitar a temporalidade de todas as coisas.

Passemos pois à implementação. Lendo a documentação do Apache, encontram-se várias formas de especificar que um recurso desapareceu. O primeiro usa «Redirect»:


    Redirect gone /caminho/para/recurso
    

Por exemplo se criar uma página temporária:


    http://aindaapensar.cafonso.pt/tmp/imagem.png
    

(*este recurso não existe de qualquer forma) e queira maisd tarde apagar esse ficheiro por qualquer razão devo colocar no ficheiro .htaccess:


 Redirect gone /tmp/imagem.png

O caminho é um caminho virtual do recurso no meu servidor, não o nome completo do ficheiro no disco, e também não o URL completo.

Pode ainda usar RedirectMatch para vários ficheiros, usando expressões regulares. Por exemplo, isto iria corresponder a todos os ficheiros na pasta tmp/ com a extensão .png:

RedirectMatch gone /tmp/*.png

A terceira opção seria usar mod_rewrite, o que permite condicionais complexos para decidir quando servir um erro 410. Por exemplo tenho uma edição móvel que contém uma página de índice e páginas dos cinco artigos mais recentes simplificadas. Estes artigos não devem ser permanentes. Tudo funciona como se fosse um RSS feed, com a excepção de que é repartido por várias páginas devido ao que é esperado pelos dispositivos móveis. Cada página tem o seu endereço próprio, mas têm vida curta. Também não posso usar os mesmos URLs sucessivas vezes como por exemplo colocar os artigos em /movel/1 até /movel/5 pois tal poderia confundir alguns proxies.

Assim quando os artigos deixarem de figurar na página de índice eu elimino-os do meu servidor e desejo servir um código apropriado de erro para proxies e bots que apareçam mais tarde. Pelo que lhes posso dizer o erro 410 é o código de erro perfeito para isso. Não desejo manter de forma manuak uma lista de regras de Redirect (redireccionamento) e assim uso o mod_rewrite:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule movel/[0-9]{6}.html$ - [G,L]

Em português isto quer dizer:

  1. Se houver um pedido para um ficheiro que não exista (!-f)
  2. e o ficheiro estiver na pasta móvel e for identificado por qualquer dos seis algarismos + .html (é a expressão regular)
  3. então usar o código de erro 410 (indicador G)
  4. e retornar imediatamente sem demora adicional (indicador L).

Isto não é uma solução perfeita: se indicar um URL arbitrário de páginas que nunca existiram mas que correspondem ao padrão, irá obter um erro 410 em vez do mais correcto 404. Mas cobre os casos mais prováveis de um proxy ou motor de busca voltar e pedir um recurso que anteriormente tiver apanhado e descobrir que já não existe.

Contudo podemos usar métodos para determinar se houve em algum momento determinado ficheiro (usando uma base de dados/tabela sendo considerado apagado quando a tabela assim o indicasse (de forma deirecta ou indirecta) ou em vez de apagar um ficheiro passar o seu tamanho para zero e assim o erro seria reportado quando o ficheiro tivesse zero bytes). Claro que se podia criar ainda outras regras que permitissem determinar facilmente se um ficheiro poderia já ter existido (por exemplo ficheiros com nomes crescentes).

Quando um user agent pede uma página que tenha marcado com um código 410 o Apache gera uma página de erro por omissão que se parece com:

    Morreu

    O recurso pedido
    /caminho/para/recurso/pedido
    não está mais disponível neste servidor e não há endereço de reencaminhamento. Por favor remova todas as referência para este recurso.

…que está muito bem, excepto quanto a razões estéticas tal como a página por omissão do erro 404. Recurso não encontrado. Mas pode criar uma página 410 à sua medida tal como pode criar páginas de erro à medida para outras condições usando uma directiva de ErrorDocument no seu ficheiro .htaccess:


    ErrorDocument 410 /caminho/para/página/àmedida

Trata-se novamente de um caminho virtual no seu servidor, o qual pode ser o endereço web sem domínio. (Pode ainda ser um URL completo numa máquina remota, mas nesse caso o "user agent" não iria receber um erro 410; iria receber um estado de reencaminhamento em seu lugar. Por isso talvez seja melhor manter a resposta local, de forma a ser emitido o código adequado.

Outros usos possíveis para o erro código 410:

  • Páginas temporárias
  • Posts de blogues apagados
  • Experiências num servidor que oferece hospedagem gratuita por determinado período após expiração do mesmo sem pagamento pelo utilizador pela continuação
  • Sítios de utilizadores que deixem de pertencer a uma comunidade online
  • ...

Não é um erro frequente, e não tenho a certeza de estar a usar isto de forma correcta.

Para quem queira avaliar por si poderá por exemplo consultar o RFC2616.

28 outubro, 2005

Acessibilidade II

Acessibilidade na UMIC

A UMIC vai actualizando o seu site com algumas informações que poderiamos achar interessantes. Entre essas informações encontra-se a de umas jornadas da Fundação SIDAR".

Essas jornadas propõe um rascunho para conclusões com o seguinte texto:

Propomos às Autoridades das Cidades e Localidades as seguintes estratégias que as levarão sem dúvida a dotar os seus cidadãos da oportunidade de participar activamente na Sociedade da Informação acessível e inclusiva para todos:

Estratégias sobre a produção ou concepção da informação

A experiência nas administrações públicas que conseguiram avanços em prole de uma comunicação acessível para todos, dá-nos conta que os elementos que se seguem, que podem ser implementados de uma forma gradual ou simultânea, demonstraram ser uma valiosa ajuda:

  1. Inclusão de uma cláusula de acessibilidade em todos os contratos de desenho, desenvolvimento ou manutenção de páginas, sítios, ou serviços Web, para a administração pública.
  2. Redacção ou publicação de um anexo para as aquisições ou cadernos de encargos da administração pública no qual se explicitem e clarifiquem os requisitos de acessibilidade para os conteúdos na Internet.
  3. Inclusão de uma cláusula nos regulamentos dos programas e gestores de fundos públicos, que obriguem a conformidade para com as directrizes de acessibilidade a todos os projectos que incluam conteúdos para Internet e que sejam financiados total ou parcialmente por fundos públicos.
  4. Estabelecer um centro auditor da acessibilidade das administrações públicas, que não apenas vigie o cumprimento dos requisitos de acessibilidade mas que sirva como centro de referência e apoio para os webmasters da própria administração, assessorando-os nas técnicas e conhecimentos necessários para implementar e manter a acessibilidade.
  5. Promover as boas práticas, mediante a sua exposição atráves da constituição de uma "Galeria da Acessibilidade" e de instituição de menções públicas ou compensações de diversa ordem.
  6. Estabelecer um serviço público de certificação da acessibilidade, preferencialmente a partir de uma entidade normalizadora e certificadora do Estado, baseada numa norma técnica previamente publicada ou, caso não exista, que a referida entidade apoie as organizações de referência neste campo no estabelecimento da certificação.
  7. Publicar periodicamente estudos de diagnóstico de determinados sectores chave da sociedade civil, como por exemplo a banca, hipermercados que ofereçam os seus produtos através da Internet, centros de comércio electrónico, centros de lazer (venda de entradas para cinemas e teatros), etc.

Meus comentários

  1. Não entendo como é que não faz já agora (e já há algum tempo) parte desse tipo de contrato cláusulas quanto à qualidade dos sítios (a acessibilidade seria só um componente dessa qualidade). Acho pois esta recomendação excessivamente simplista, mas também acho que tem que se começar por algum lado.
  2. Aqui parece-me que não se deve inventar muito. Olhe-se para as recomendações/directrizes existentes e se for caso disso façam-se adaptações (não se invente a roda por favor). Só se devem acrescentar algo se for estritamente necessário.
  3. Totalmente de acordo (acho mesmo que não só deviam fazer cumprir as recomendações de acessibilidade como deviam fazer cumprir as recomendações mais gerais na linha do WaSP. Acho mesmo que no caso de não cumprissem quer com as regras de acessibilidade, quer com as regras mais gerais se deviam estabelecer as "penas" a aplicar.
  4. Quanto ao centro auditor da acessibilidade das administrações públicas, algo que devia ser feita além do indicado seria permitir um escrutínio público activo das más práticas, não com a finalidade principal de penalizar os organismos públicos/empresas fornecedoras, mas levam a uma mudança de atitude.
  5. Acho que a promoção de boas práticas deveria incluir sítios piloto de demonstração (no sentido que que se podia observar um caso prático em funcionamento). Os sítios que apresentassem boas práticas deveriam ter louvor público (um ícone que pudessem ostentar e não a coisa ridícula que significa ter um buraco de fechadura) das pessoas responsáveis pelos sítios. Essas pessoas deveriam ser incentivadas a tornar públicas em formato acessível ao todos nós sobre a maneira como concebiam o sítio ou sítios em causa.
  6. Não gastem dinheiro, numa primeira fase, em serviços públicos de certificação de acessibilidade. Façam uma revisão por processo automático e uma autoavaliação e avaliação pelo próprio público. Não criem normas técnicas num campo em permanente actualização. Usem as normas / recomendações / directrizes existentes e confrontem-nas com os vossos próprios sítios.
  7. Não publiquem só estudos de diagnóstico de.... Vejam em série temporal se cada sector chave faz algum esforço.

Aquilo que cada um de nós pode fazer

Sem necessidade de sermos obrigados a fazer, podemos, cada um de nós, fazer um pequeno esforço para melhorar a situação. Se por exemplo visitarem a página traduzida das WAI pela UTAD podem verificar que a página mesmo não sendo validada está muito próximo de ser acessível (talvez com a excepção de uma linguagem demasiado técnica, mas parece-me que neste caso perfeitamente aceitável).

Depois cada uma das pessoas que se ache com essa capacidade tome um sítio debaixo da sua asa e faça uma avaliação humana da acessibilidade nesse sítio e faça conhecer ao responsável pelo sítio aquilo que tenha encontrado que possa ser melhorado. Espere algum tempo e se ele não lhe responder (quer alterando quer enviando-lhe um e-mail) trate de assinalar o facto num local eventualmente a criar.

Assinale os problemas que encontra indicando o problema, para que incapacidade isso pode ser gravoso, que mecanismos alternativos utilizaria, que meios (computador, programas, telemóvel, pda, etc).

Não nos podemos esquecer que a internet não tem só como potencial utilizador o utilizador do computador, julgo que no futuro haverá provavelmente mais utilizadores de meios alternativos e esses devem ser contemplados.

Eu vou continuar a alimentar a minha lista de sítios públicos e vou tentar ver se evoluíram muito entre 2003 e a actualidade quer em relação as web standards quer em particular à acessibilidade. É curioso que não vi até agora nenhum sítio de ministério que não usa-se tabelas para layout. (Não use o telemóvel nestes sítios). Alguns acham mesmo que toda a gente tem JAVA activo, ou imagens.

Parece-me que o caminho será longo, mesmo muito longo. E acho que de facto é genérico em todo o mundo, não é só uma questão nacional.

Já agora quem saiba de algum sítio empresarial ou público que cumpra com as recomendações da WSP cá fazia o favor de me enviar esse dado. Desde já os meus agradecimentos.

Semiótica e Arquitectura de Informação

Semiótica e Arquitectura de Informação

A semiótica em termos simples é o estudo dos sinais. O que se pode tornar complicado é definir o que é um "sinal".

Quando pensamos em sinais, pensamos em algo visual como um sinal de trânsito. Mas os "sinais" são feitos de muitos componentes diferentes - palavras, sons, linguagem corporal e contexto - todos combinados para criar uma linguagem visual que nos ajuda a compreender algo, seja o caminho para a praia, ou se alguém, nos detestou da primeira vez que nos viu.

Este artigo não é sobre semiótica. Não vou aprofundar este assunto muito mais, pois num campo desta natureza nunca poderia deixar de só arranhar a superfície. Vou tentar falar é do uso da simeótica na Arquitectura de Informação. Isto, só por si, já é um campo muito grande pelo que só vou fazer uma introdução.

Introdução

Já dissemos que a semiótica é o estudo dos sinais e que os sinais podem ser feitos de todo o tipo de coisas tal como a língua, imagens, linguagem corporal, etc. Mas o que é que isto nos diz na prática? Bem, poderá ajudar-nos a dar uma revisão ao campo da semiótica e depois passar para algumas teorias que ajudam a constituir o seu núcleo.

Os semióticos modernos, não estudam só sinais - vai muito mais ao fundo - estudam como é que o significado se forma. Estudam como é que as pessoas interpretam um sinal, e como é a sua experiência cultural e pessoal os faz compreender um sinal. Neste sentido a semiótica é sobre comunicação (vê os paralelos com o design?).

Há três áreas principais na semiótica: os sinais, a sua forma de organização num sistema e o contexto em que aparecem.

Vejamos os sinais.

Os Sinais

Ícone - um ícone é um sinal que se assemelha a algo, tal como fotografias de pessoas. Um ícone pode ser ilustrativo ou diagramático, por exemplo um sinal de "proibido fumar".

Indíce - um sinal indíce é um sinal onde há uma ligação directa entre o sinal e um objecto. A maior parte dos sinais de trânsito são índices pois representam informação relativa a um local (por exemplo "perigos vários", colocado numa zona perigosa para o trânsito).

Símbolo - Um símbolo não tem um significado lógico entre ele e o objecto. Infelizmente a web está cheia de maus exemplos deste tipo de sinal, mas há bons exemplos - uma porta aberta para a página de entrada por exemplo. Outro tipo de simbolos que podem ajudar a explicar a diferença são as bandeiras. As bandeiras são simbolos que representam países ou organizações. Novamente o cruzamento entre design e marca está muito evidenciado nestes sinais.

Sausurre propôs uma estrutura mais simples do que é que um sinal é:

  1. um "significante" - a forma que o sinal toma e
  2. um "significado" - o conceito por si representado.

Para Saussure um sinal signo é uma combinação dos dois. Mas, o que é que isto significa em termos da Web?

A Semiótica e a Web

A Web está cheia de sinais. Pense nisso.

A maior parte dos utilizadores efectua uma tarefa num website, de modo a alcançar o que tenham a visam alcançar para navegar para o local correcto. Para que o façam seguem os sinais. Entende?

Não só sinais visuais. Vejamos a Arquitectura de Informação por um momento.

A AI é um campo do desenvolvimento que trata da organização da informação. Em tempos tive uma amiga que me descreveu o que é que a excitava no seu trabalho. Faço listas, disse ela com um grande sorriso. Depois faço listas dentro de listas. Parece-lhe excitante? Trocamos impressões sobre o sentido das palavras e do seu efeito sobre o seu trabalho.

As palavras são importantes, disse ela. Provavelmente mais do que tudo o resto. Podes ter um mau design, mas se as palavras forem as correctas no local correcto, o utilizador acabará por encontrar aquilo que pretende.

A conclusão desta conversa foi que as palavras também são sinais na web. A palavra correcta no sítio correcto - é disso que trata a navegação ou não? Contexto. Passemos agora a algo um pouco mais visual.

Tomemos o exemplo da concepção de um sistema icónico para uma aplicação online. Os paralelos com o design de software são óbvios - um interface gráfico de utilizador GUI, têm bons ícones, ou será que devo dizer sinais. Então o que é que deve fazer para tornar esses sinais compreensíveis pelo utilizador?

  • Seja evidente - seja corajoso
  • Deixe a "criatividade" para os maus designers - Este não é o local para fazer algo de diferente. Se existe uma convenção use-a
  • Posição, posição - Esteja no sítio certo.

Há mais, mas estas seriam as três coisas mais importantes, na minha opinião, para uma sinalização bem sucedida (não se esqueça que os ícones na web são sinalização e quando os está a desenhar está a criar uma sinalização quer o queira quer não).

Comentários de José Afonso (ainda sem website):

Penso que a semiotica é antes de mais um termo. Um termo que, entre várias coisas, designa uma ciência: a ciência dos signos (" Charles Peirce

general theory of signs, which he called semiotic, is a promising candidate for the theory of symbolism apparently missing as yet from the anthropological paradigm.
").

E, o problema, acho eu, surge logo no momento de distinguir signo de sinal. Penso que isto aparece pelo menos de dois modos: do ponto de vista da intencionalidade e do ponto de vista da codificação.

(
"Semiotic is the general theory that attempts to specify the general logical features of signs and the similarities and differences between the great variety of forms they can take. "
)

Um sinal de trânsito, penso eu, ser na verdade um signo. Um signo intencional de aviso de que uma regra ou norma deve ser cumprido. Um signo, também, do ponto de vista da codificação que remete de uma linguagem visual para uma linguagem verbal - a questão seguinte é saber em que medida se pode falar de linguagem visual (como alguns falam de pensamento visual) e da sua relação com (o código) (d)a linguagem verbal.

Não! Devia?... E depois há a comunicação... será que o sinal de trânsito visa comunicar-nos que a ou b deve ser feito ou transmitir-nos o que deve ser feito em determinada situação? Qual a diferença entre "comunicação"(teoria da informação) e "transmissão" (mediologia)?

O que se segue é uma classificação dos "sinais" (signos?) segundo Pierce (uma classificação segundo que princípio)? Ver Umberto Eco, Tratado... "Símbolos, índices, ícones: uma tricotomia insustentável" (curiosamente esta secção fala da "tipologia dos signos" - julgo que uma tipologia é uma classificação de tipos de signos segundo um princípio inerente ao sistema por eles formados)

A fotografia é um bom caso problemático para esta semiótica, cujo princípio de classificação, penso eu, serem as "causas". O que depois apresentas como o "poder ser" do ícone são as suas modalidades de classificação segundo o seu aspecto, constituição, organização ou apresentação material.

Será um símbolo o que "está por" ou "em vez de"?

Há ainda bastantes notas mais só que as vou guardar para amanhã.

27 outubro, 2005

Comentários sobre Web Standards em Portugal III

João Craveiro

João Craveiro enviou-me a seguinte mensagem/comentário:

Para começar, agradeço a referência ao meu artigo -- e já reparei que também fui referido noutro contexto/post. ;)

Já agora, no âmbito desse artigo, indico-lhe um link para uma (que pretendo/pretendia que fosse a 1ª de algumas) experiência (que fiz por altura do artigo) de conversão de páginas da AP para boas práticas de webdesign.

Depois, dado que os comentários estão desactivados (pelas razões que já li, e que na verdade são um dos caveats em utilizar uma plataforma gratuita e/ou de "mexibilidade" limitada):

«Para o João não é muito importante a validação automática, para mim ela só é importante como avaliação inicial da qualidade da página, pode haver algumas razões para que uma página não valide, mas é importante, na minha opinião, perceber se são ou não importantes as razões para a não validação.»

Eu não lhe dou uma importância suprema, porque acho (aliás, tenho a certeza) que não existe uma dependência funcional, em qualquer um dos sentidos, entre "aprovação na validação automática" e "bom webdesign - markup acessível, compatível e semântica". É possível fazer um site "matrioska de tabelas" que valide na perfeição em XHTML 1.1 , da mesma maneira que um site que não valide na sua totalidade pode ser um exemplo a seguir nos parâmetros de bom webdesign que referi.

«O atributo de língua <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">Deve querer dizer que a língua em que o documento está feito é o inglês (não é o que se verifica felizmente)»

Há piores: os que mudam o doctype de «//W3C//DTD XHTML 1.0 Transitional//EN» para «//W3C//DTD XHTML 1.0 Transitional//PT». ;)

Para terminar, em resposta a 2 dos parágrafos de um comentário que fez a um artigo mais recente sobre o assunto:

«Já agora se reparar bem nem os sites das nossas universidades cumprem adequadamente os requisitos médios de acessibilidade, isto para não falar também do desgosto que me provoca olhar para alguns deles como por exemplo o da Universidade de Lisboa (Clássica).»

Eu sei, estudo numa faculdade da Clássica. ;) Até agora, não contando com o site da própria UL, o cúmulo de "querer benzer-se e partir a cabeça" em todos os aspectos (i.e., não se ganhou propriamente muito em 'user experience' por se utilizar uma tecnologia avançada, mas pouco amiga da acessibilidade) é o site de uma cadeira em que cada opção do menu é uma applet Java (só para fazer um efeito rollover).

«Acho que os responsáveis não percebem para que serve ter um site acessível, acessível a cegos, ambliopes, pessoas com dificuldades motoras, pessoas com dificuldades de aprendizagem.»

Este parágrafo dum artigo meu , em inglês, é uma metáfora+hipérbole daquela que acho uma maneira realmente efectiva de "seduzir" (pelo menos o sector privado) ao uso dos webstandards e cumprimento de requisitos de acessibilidade:

«"I don’t care about blind people, are there any real benefits?"

Well, I could answer that by making yet another paragraph advocating the benefits of using semantic markup and separating content from presentation, yada yada, but I won’t. I’ll just cut straight and enlighten the selfish you, who doesn’t care about disabled people, or thinks that blind people don’t need to read you because you write about camcorders and digital still cameras, that search-engine robots are also blind users. Google doesn’t have pigeons looking at every site, to visually distinguish titles (big letters) from text (normal size letters), nor do they perfom OCR on a screnshot of your homepage for that matter. They look at your site’s markup, and build the hierarchical strcture of it based on the headings present and each one’s level. Google, visits, people, fame [we can add "money" to this list, works like a charm ;) ]. Does THAT appeal to you?»

Nota: Os realces são da minha responsabilidade

26 outubro, 2005

Para os nostálgicos da informática

Este post não é para se repetir (está fora do âmbito deste blogue) todos os dias mas de vez em quando vou actualizar esta lista. Já agora hoje, 26 de Outubro de 2005 vai para o ar uma nova entrevista.

Entrevistas com luminárias da informática
  • Dan Drake, um dos fundadores da Autodesk (Autocad).
  • Dave Winer, pai do RSS e dos blogues
  • Tim O'Reilly, o pioneiro do Open Source
  • Brewster Kahle, o fundador do arquivo da internet
  • Bill Joy, o co-fundador da Sun Microsystems
  • Max Levchin, o co-fundador do PayPay
  • Andy Hertzfeld, um dos programadores originais de sistema do Macintosh

As entrevistas são apresentadas em várias formas de áudio MP3, Ogg Vorbis Audio, AAC Audio e transcritas.

O Andy diz

Desejos CSS-3

Tenho pensado em arranjos líquidos ultimamente e julgo que seriam úteis as seguinte propriedades: min-padding, max-padding, min-margin e max-margin.

Normalmente em arranjos líquidos é normal indicar as padding/margin usando percentagens para criar um intervalo líquido entre elementos. Contudo uma vez tendo sido reduzido o arranjo para além de um certo limite esse intervalo torna-se demasiado pequeno. Assim seria muito bom podermos definir um intervalo mínimo de separação entre elementos de forma a aumentar a legibilidade.

Inversamente em ecrã ao baixo (muito mais largos que altos), esses intervalos podem ficar excessivamente grandes causando uma pulverização entre elementos do conteúdo. Indicar um intervalo máximo evitava este problema e mantinha os elementos visualmente associados.

Tendo em conta que há "min" e "max" "width", parece um esquecimento não haver os equivalentes min e max para padding e margin.

No 456 diz-se que isto claro só deve tratar-se da forma abreviada. quando so Andy disse:

min-padding: 0em 1em 1em 2em;

Estava claro só a falar da versão abreviada a versão completa seria algo como:


min-padding-top: 0em; 
min-padding-right: 1em; 
min-padding-bottom: 1em; 
min-padding-left: 2em; 

AJAX - I

AJAX - I

Este é o meu primeiro artigo sobre como Começar a Desenvolver/Trabalhar com AJAX. Faça o favor de o incluir nos seus marcadores preferidos, guardá-lo, imprimi-lo ou o que quer que seja.

Eis uma lista de Guias Fundamentais para desenvolvimento de AJAX:

  • Centro de Desenvolvimento do Mozilla: AJAX:Introdução - É um bom local para começar a estudas o que é que é o AJAX. A equipa do Mozilla fez um belicímo trabalho à introdução do AJAX dando alguns exemplos os quais pode experimentar de imediato.
  • Responsáveis pelo desenvolvimento do Meebo: Introdução ao AJAX - Os responsáveis pelo desenvolvimento do Meebo falam de como começar a trabalhar com AJAX no seu projecto, alguns conselhos que pode usar para arranjar ideias e desenvolver o seu próprio projecto AJAX.

  • Kevin Meyer - tem uma série de artigos sobre introdução ao AJAX e ASP. Tem um tutor com código de exemplo, e assim todos os "malucos" por ASP podem seguir os exemplos.
  • PASSEÀFRENTE: AJAX e JAVA - Aqui a gente da Getahead partilham os seus conhecimento sobre usar AJAX com DWR que é uma biblioteca AJAX para JAVA. É bem escrita e documentada com exemplos de código. Os "malucos" pelo JAVA, estão no seu território.
  • developerfusion: Introdução ao AJAX em ASP.NET - Para "malucos" por produtos da Microsoft, eis alguns bons exemplos de código, assim como documentação.
  • 5411 - Exemplos de AJAX - Neste sítio irá encontrar uma série de ligações para vários exemplos de AJAX para que possa ver como o AJAX está a ser usado.

Vejam esta aplicação para criar sql scripts usando técnicas AJAX.

25 outubro, 2005

ALA - 206

A List Apart - nº 206

Saiu o número 206 do A List Apart com dois artigos do número:

  • Os bons designers redesenham, os ases do design realinham escrito por Cameron Moll.

    A diferença entre redesenhos que fazem parecer estar ocupado e dão aos interessados algo para discutirem, e revisões estratégicas que recolocam a sua marca e o ajudam a estabelecer e atingir objectivos.

  • O ataque das cópias zombiede Erin Kissane.

    Já os viu na web, estas frases zombie - mesmo com os erros de sintaxe, frases vazias de tudo excepto da terrível fome por cérebro humano. Eis como contra-atacar.

O artigo repescado é A noite do image map, de Stuart Robertson e escrito em 2003

No seu artigo Cameron deseja distinguir dois tipos de pessoas que concebem páginas Web aqueles que as redesenham e aqueles que as realinham sendo ele (claro que na sua opinião) um realinhador. Eu cá tenho que admitir que sou um reles observador.

Entre as distinções encontramos as razões de base para se fazer uma alteração aos sites.

Como é habitual há aquelas pessoas que se preocupam com a terminologia exacta (é sempre bom usarmos as palavras mais adequadas para descrever algo, contudo se as redefinimos tal não será tão importante (embora o seja)).

Os comentários pelo menos até aqui são geralmente triviais.

O segundo artigo trata de algo problemático: os conteúdos textuais. Resumindo (muito) diz que é necessário pensar antes de escrever e que não deve ser usado vocabulário demasiado hiperbólico e pouco usado.

O Terceiro artigo (o respescado) é um excelente artigo sobre utilização de ligações com imagens (por exemplo menus) e algum CSS para criar "aquela" página.

24 outubro, 2005

Web Standards em Portugual

O João Craveiro publicou em 14 de Agosto um artigo chamado Acessibilidade na Web em Portugal. Ele fez algumas observações sobre os diversos sites que percorreu. Eu desejei ver se algum desse sites tinha sido actualizado. Parece que as observações feitas pelo João se mantêm. Só que para mim o problema é mais grave do que o que ele apresenta. Os ministérios, os organismos públicos têm uma tendência para não ligarem nada às regras estabelecidas pelo próprio estado na concepção de páginas. Realmente quando vejo uma página que me diz ser válida (qualquer validade xhtml, html [até aceito 3.2 pois sou pouco exigente]) e olho para o seu código até fico horrorizado.

UMIC

Isto passa-se mesmo em organismos que era suposto serem bastante exigentes com estes aspectos como por exemplo a UMICAgência para a Sociedade do Conhecimento.

Nesta página começa-se por ter um DTD <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">. Tal parecia ser um compromisso sério com a qualidade da página, claro que se passarem pela validação automática irão verificar que a página gera uns 50 erros. Alguns são verdadeiros erros, outros parecem comprimissos com alguns navegadores específicos.

Para o João não é muito importante a validação automática, para mim ela só é importante como avaliação inicial da qualidade da página, pode haver algumas razões para que uma página não valide, mas é importante, na minha opinião, perceber se são ou não importantes as razões para a não validação.

Ligar Portugal

Uma das ligações proeminentes na UMIC é a ligação Ligar Portugal onde somos presenteados com uma aplicação logo na abertura (dificilmente fazem bem à acessibilidade).

Aqui vemos duas coisas um DTD <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> com 16 erros. O principal erro é a utilização de caracteres que de acordo com o SGML são usados para controlo. Provável confusão com Windows-1252. Os restantes erros estão relacionados com a utilização de flash.

O atributo de língua <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">Deve querer dizer que a língua em que o documento está feito é o inglês (não é o que se verifica felizmente).

Como já seria de esperar ao elemento <embed>não corresponde um elemento <noembed> dava muito trabalho. Estou a falar destes dois sites pois são mais recentes do que os dos ministérios e portanto deveriam nascer de raiz sem os problemas apresentados por coisas mais antigas e antiquadas.

Quanto se mistura este tipo de coisas ninguém está à espera de um site que separe conteúdo, aspecto e comportamento. Assim as coisas bonitas continuam <body vLink="#ffffff" aLink="#ffffff" link="#ffffff" bgColor="#ffffff">.

Numa página html 1.0 não estava a perceber como aparece uma série de atributos que foram dados como em vias de ficarem obsoletos desde a versão 3.2 do HTML. Se não sabem usar Flash de forma a que seja acessível tratem de aprender

B-On

Vejamos se um site universitário tem melhor sorte, mais a mais foi actualizado nos últimos tempos, só não sei se já está activo e aquilo que estou a ver é a primeira versão, ou se já é a nova versão.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Biblioteca do Conhecimento Online - INICIO</title>
<meta name="description" content="b-on Biblioteca do Conhecimento Online. Portald e acesso às principais revistas científicas internacionais" />
<meta name="keywords" content="b-on; revistas científicas; ciência; umic; fccn; portugal; inovação; comunidade académica; universidades" />
<meta name="Generator" content="Mambo - Copyright 2000 - 2005 Miro International Pty Ltd.  All rights reserved." />
<meta name="robots" content="index, follow" />
 <link rel="shortcut icon" href="http://aesop.fccn.pt/images/favicon.ico" />
     <link rel="shortcut icon" href="http://aesop.fccn.pt/templates/b_on_novo_hp/templates/b_on_novo_hp/images/favicon.ico" />
   <link rel="stylesheet" type="text/css" href="http://aesop.fccn.pt/templates/b_on_novo_hp/css/template_css.css" />

   <link href="css/template_css.css" rel="stylesheet" type="text/css">
</head>

<body>
<table width="760"  border="0" align="center" cellpadding="0" cellspacing="0" class="alinhacentroborder">
  <tr>
    <td><table width="100%"  border="0" cellspacing="0" cellpadding="0">
      <tr>
        <td class="fundocima_esquerda" valign="top"><table width="100%"  border="0" cellspacing="0" cellpadding="0">
          <tr>
            <td width="14%"></td>
            <td width="86%">
                 <table cellpadding="0" cellspacing="0" class="moduletable">
      <tr>
    <td>
    <table width="100%" border="0" cellpadding="0" cellspacing="1"><tr><td nowrap="nowrap"><span class="mainlevel-nav">  </span><a href="index.php?option=com_contact&Itemid=58&lang=PT" class="mainlevel-nav" >contactos</a><span class="mainlevel-nav"> | </span><a href="index.php?option=com_sitemap&Itemid=57&lang=PT" class="mainlevel-nav" >mapa do site</a><span class="mainlevel-nav">  </span></td></tr></table>    </td>
   </tr>
   </table>
   </td>
          </tr>
        </table></td>
        <td><img src="/templates/b_on_novo_hp/images/cima_direita.jpg" alt="b-on Biblioteca do Conhecimento Online" width="581" height="103"></td>
      </tr>
    </table></td>
  </tr>
  <tr>
    <td class="barracimavermelha">
      <table width="100%"  border="0" cellspacing="0" cellpadding="0">
        <tr>
          <td>   <table cellpadding="0" cellspacing="0" class="moduletable">
      <tr>
    <td>

Peço desculpa por ter extraído uma porção tão grande da página mas necessita de pergunta se alguém já lei o que as especificações dizem sobre o elemento <meta> começo a desconfiar que não. Sabiam que aquele "/" realçado por mim significa que o cabeçalho terminou, ou será que querem que explique a asneira. Pensei para com os meus botões será que a FCCN Fundação para o Cálculo Cientifico Nacional tinha a mesma utilização dos meta e não é que tem mesmo.

meta

Talvez devam consultar cuidadosamente o que é que a especificação apropriada diz sobre o uso dos metadados.

Se repararem os meta não são terminados por "/>" pois tal fecha o próprio cabeçalho, pelo que depois aparecem uma série de erros por simpatia.

body

Depois do passeio pelo cabeçalho, já não tinha esperança nenhuma sobre o que ia ver no corpo e claro está lá estava a tabela da ordem, claro está com outras lá dentro para "facilitar" a acessibilidade da página. Será que nunca se vai aprender não usar tabelas para definir o arranjo da página (nunca, nunquinha...)

Vejo que usam um CMS que era suposto não ter problemas destes embora a página de entrada no seu site tenha quatro erros pois não terminam quatro elementos img. Não entendo pois como não gastar cinco minutos a corrigir estes defeitos, será que seria assim tão caro.

Já agora já alguém viu a página com JavaScript desligado, onde é que está essa degradação agradável, desaparece a navegação principal e as buscas deixam de ser possíveis para degradação simpática não está mal.

Tenho de admitir contudo que a busca é muito boa.

20 outubro, 2005

Limpeza de Primavera (de facto de Inverno)

A equipa de de desenvolvimento do Internet Explorer pede que os programadores de página as limpem de truques CSS que possam falhar no IE7 quando publicado. Assim vou falar-lhe do que sei sobre o assunto e como é que criei uma concepção de emergência há já uns dois meses.

O meu plano não era no início criar código que fosse à prova do futuro mas para retirar tantos truques de CSS quanto possível para reescrever um pequeno síte tipo brochura, rapidamente e depois passá-lo a outro responsável de desenvolvimento cuja experiência e capacidades me eram desconhecidas. O resultado final foi retirar quase todos os truques excepto um. Um efeito secundário foi tornar o código mais estruturado e mais fácil de manter (julgo) e mais lógico.

Para que servem os truques CSS

Os truques CSS permitem aos responsáveis pelo desenvolvimento de páginas web enviar um conjunto de regras diferentes a diferentes navegadores, normalmente (paradoxalmente) para que cada navegador reproduza o site com o mesmo aspecto. É necessário normalmente visto o Internet Explorer 5 e 6 terem muitos defeitos e assim tornarem más boas regras.

Há dois tipos de truques CSS:

  • Análise - Os truques de erro baseiam-se no facto do navegador deixar de ler quando numa regra vê uma combinação esquisita de caracteres tal como“\”}\”", enquanto o navegador "Y" continua e recebe as regras que se lhe seguem. O problema com isto é que se não estiverem bem comentadas não se percebe o que fazem pois estão mal documentadas.
  • Truques devidos a suporte incompleto das CSS - usa o facto de o IE não poder suportar selectores avançados CSS, e o responsável pelo desenvolvimento usa esses selectores para alimentar um navegador mais avançado. O problema com estes é que o IE7 está a aparecer no horizonte e irá perceber estas regras. Pode ou não haver um problema, mas se quizer ter a certeza de que o seu sítio não rebenta com o IE7 deve tratar deste assunto.

Há uma imensidade de truques CSS documentados, mas um dos mais usados é o truque do modelo de caixa devido ao modelo de caixa errado no IE5. É um truque de erro de análise, a maior parte do qual existe para enganar os navegadores para verem ou não o truque. Por exemplo, todos os contorcionismos da "voice family" existe para enganar o IE5 para não ler o resto da regra, de forma a não sobrepôr as suas dimensões excessivamente grandes:


  #conteudo{margin:0; padding: 0 15px;
  width: 194px; /*IE 5.5 Truque do Tantek *
  voice-family: "\"}\"";
  voice-family:inherit;
  width: 164px; /*Largura devida*/ }
  html>body #conteudo{
  width:164px;}
 

Uma segunda regra ("html>body") é uma regra para ser simpático com o Opera pois o Opera também pararia no lixo da "voice family" e herdaria 194px, o que não desejamos e o seu modelo de caixa está correcto. Agora no IE7 embora leia a regra simpática para o Opera essa será a largura necessária de qualquer modo e nenhum dano é feito.

Com a excepção do pobrezinho que venha depois de mim, poluir o CSS desta forma ofende a alma. Visto tudo isto servir para corrigir um defeito do Internet Explorer seria ou não muito bom se pudessemos ter uma folha de estilo, boa, válida, sem truques e uma com a marcação para o IE5! Isto é consigo! Podemos usando comentários condicionais.

Como funcionam os comentários condicionais

Isto são comentários html, com um marcador de forma a que o Internet Explorer os distinga e pode usá-los para envolver qualquer código html - incluindo a ligação a folhas de estilo. Visto serem comentários html são invisíveis aos restantes navegadores e passam a validação, pelo menos de um ponto de vista formal.

Eis a sintaxe que uso para alimentar regras para o IE5:


 <link rel="stylesheet" href="estilos.css" type="text/css" />
 <!--[if < IE 6]>
 <link rel="stylesheet"  href="modelocaixa.css" type="text/css" />
 <![endif]-->

Assim o ficheiro principal estilos.css tem uma regra simples:


 #conteudo{margin:0; padding: 0 15px;
 width: 164px;} /*ver modelocaixa.css para regra específica do IE5 */
e o ficheiro modelocaixa.css - que seria só servido ao IE5 - utilizaria esta regra:

 #conteudo{width: 194px;} /*as outras regras encontram-se em estilos.css */

Nada de truques "voice-family" ou regras de simpatia para o Opera! Porreiro!

AsneirasIE.css - Correção dos principais erros do IE6 e anteriores

Muitos dos truques são usados para alimentar o IE6 e anteriores versões para compensar a ausência de capacidades importantes de um desenvolvimento moderno da Web como por exemplo transparência Alfa de ficheiros PNG, "min-height" (altura mínima de um elemento) CSS, por exemplo.

Podemos retirar os truques chamando uma folha de estilos designada por AsneirasIE.css para navegadores Internet Explorer com versão igual ou anterior à 6, desta forma:


 <!--[if lte IE 6]>
 <link rel="stylesheet"  href="AsneirasIE.css" type="text/css" />
 <![endif]-->

Simulação de "min-height"

Suponha que tem uma caixa que nunca deve ter uma altura inferior a 100px - pode ter por exemplo uma imagem de fundo com 95px que deseja que seja vista sempre, mas não pode prever a quantidade de conteúdo. Num navegador respeitador das normas utilizaria "min-height", o que não funciona nas actuais versões de produção do IE.

Para contornar este problema adicionamos uma regra especificando a altura (que funciona da mesma forma que min-height devia funcionar). Assim a regra na folha de estilos principal temos algo como #caixa {min-height:100px;} que no AsneirasIE deve ser ultrapassado por


 #caixa {height:100px; overflow:visible;} /*simula min-height */

Dar GIFs ao IE e PNGs aos bons

Muita gente que tem uma maior orientação para a componente gráfica das páginas do que eu já usa há muito tempo o formato PNG nas suas páginas visto permitir uma maior liberdade. Infelizmente o IE6 não usa o PNG de forma adequada e assim temos vindo a usar um outro truque para enviar GIF ao IE e PNG aos restantes. Eis um exemplo do truque * html que só o IE entende:


 #amoroso  {background: url(amoroso.png) no-repeat;}
 * html #amoroso {background: url(amoroso.gif) no-repeat;}

Agora que o IE7 pode usar adequadamente os PNG e não irá compreender a regra * html, irá receber o PNG enviado com a primeira regra: tudo bem. Mas esta regra é para navegadores pré IE7 e assim deve ser enviado para o canil AsneirasIE.CSS.

Uma vez banido deixará de ser necessário o prefixo * html visto a folha de estilo ser só enviada para IE<7, e irá ultrapassar a regra principal. Assim a folha de estilo principal mantem:

#amoroso  {background: url(amoroso.png)no-repeat;}

e no AsneirasIE.css é adicionado


 #amoroso {background: url(amoroso.gif) no-repeat;}

Evitar que palavras muito compridas estraguem o layout

Ao contrário do que as especificações determinam o IE permite que palavras muito compridas deitem para fora da caixa em que estejam - o que pode facilmente destruir um arranjo de página se outras caixas flutuarem para a direita o que pode ser perigoso quando o conteúdo não pode ser rigidamente controlado e testado, tal como em comentários de diários onde uma pessoa pode acidentalmente (ou maliciosamente) inserir uma palavra particularmente grande que estrague o arranjo.

Há uma extensão CSS específica do Internet Explorer a qual corrige o problema mas não é validável. Por mim estou perfeitamente satizfeito quando uso lixo para corrigir o lixo do IE em particular fora da folha de estilos principal claro que os puristas me podem bater na cabeça.

Adicione esta regra à caixa que contem os comentários do seu diário (blog) (ou faça como eu adicione ao marcador «body»):


body {word-wrap: break-word;}
(Não sei se o IE7 elimina este erro e por isso talvez seja melhor colocar esta regra numa folha de estilo para todos os navegadores IE - cf. IE.css).

Correção IE6 avançada

No caso de o design do seu site exigir uma capacidade de poder ter um comportamento "hover" (rato por cima) num elemento que não seja uma âncora (<a>) o IE normalmente impede-o de o fazer. Pode adicionar o comportamento csshover na folha de estilo AsneirasIE:


body { behavior:url("csshover.htc"); }

(Pode ainda simular a totalidade do IE7 com a Biblioteca de JavaScript do Dean Edwards, usando comentários condicionais para puxar a biblioteca JavaScript.)

Outra razão potêncial para um IE.css que ainda não investiguei a fundo pode ser adicionar Arranjo IE a certos elementos que podem ajudar a corrigir tantos erros de reprodução do IE6.

IE.css - alimentar de estilos todas as versões IE

Outro bom uso de comentários condicionais é segregar extensões só do IE de CSS normalizado, pois tais extensões se usadas na folha principal de estilos fazem com que esta não seja validada (e não são necessárias em navegadores que não o IE e portanto não devem sequer ser enviadas).

Tais extensões são por exemplo filtros para imagens, ou elevadores lateriais coloridos.

Eis o código para a cabeça da página:


 <!--[if  IE]>
 <link rel="stylesheet"  href="IE.css" type="text/css" />
 <![endif]-->

Se não necessita destas extensões ou não se importa de ter este tipo de coisa na sua folha de estilos principal que não poderá ser validada (e num mundo prático, não há nenhum efeito secundário pernicioso se o fizer pode simplesmente deixar isto na folha de estilos principal, embora eu prefira separar isto completamente.

IE/Mac: o novo Netscape 4

Não sendo bafejado pela sorte para usar um Mac, não testei isto que se segue, mas por razões de alargamento do âmbito aqui vai. O quirksmode diz-nos que os comentários condicionais só funcionam no IE/ Windows. Se necessitar de fornecer regras ao IE/Mac (que nos dizem estar tão moribundo quanto o Netscape 4), há truques disponíveis, mas deve levar em conta a possibilidade de os importar numa folha especifica onde tenha todas as regras para o IE/Mac:


 <style type="text/css">
 @import("IEMac.css");
 </style>

A formatação de importação deve ser exactamente como mostrado acima. (A nota do chapéu)

Em Resumo

Para recapitular eis todo o código que deve figurar no «header» (cabeçalho) (é provável que não necessite dele todo):


 <link rel="stylesheet" href="styles.css" type="text/css" />
 <!--[if  IE]>
  <link rel="stylesheet"  href="IE.css" type="text/css" />
 <![endif]-->
 <!--[if <= IE 6]>
  <link rel="stylesheet"  href="AsneirasIE.css" type="text/css" />
 <![endif]-->
 <!--[if < IE 6]>
  <link rel="stylesheet"  href="modelocaixa.css" type="text/css" />
 <![endif]-->
 <style type="text/css">
 @import("IEMac.css");
 </style>

Reduzindo os pedidos http

Cada folha de estilo puxada exige um pedido extra http, o que pode fazer com que as coisas fiquem mais lentas pois os obreiros do http podem ficar facilmente cansados. Assim, de forma a minimizar os seus esforços pode juntar todos os truques relativos ao IE num único ficheiro mas teria que manter mesmo neste caso um ficheiro separado para o truque do modelo da caixa para o IE5 de forma a que este fique com a caixa maior. Para enviar 164px ao IE6 e 194px ao IE5 é necessário recorrer como anteriormente ao voice-family para o IE mas não ao Ser Simpático com o Opera. Eis o código:

 #conteudo{width: 194px; /*Largura IE 5.5 truque do Tantek */
 voice-family: "\"}\"";
   voice-family:inherit;
 width: 164px; /*largura devidah*/ }

O grão de areia no teste

Se usar as versões de teste múltiplas do IE, não entre em pânico quando o seu modelo de caixa (modelocaixa.css) parecer não funcionar. Independentemente de qual o IE que manda executar para teste o analisador de comentários condicionais julga que está a usar a última versão instalada. Para aqueles que se sentem confortáveis a alterar directamente o Registo há uma solução (Chapelada de Simon Pieters).

Final

Embora não tenha objecções religiosas ao uso de truques CSS, temos que ter em conta que rapidadamente o novo navegador da MS chegará ao mercado. É boa prática, de desenvolvimento, modularizar o nosso código espera-se que o IE7 um ano após o respectivo lançamento se torne no principal navegador (não sei de onde vem esta previsão) e assim os truques podem deixar de ser tão úteis.

Pessoalmente acho mais fácil desenvolver em Firefox em primeiro lugar com uma folha de estilo limpinha, quando as coisas ficam esquisitas o validador de CSS é uma ferramenta últil de diagnóstico. Este utilitário fica maluco quando as folhas de estilo ficam cheias de truques. Assim gosto de ter tudo a funcionar num browser moderno e só depois aplico os truques, usando comentários condicionais.

Quer acredite que alimentar os navegadores diferentes com conteúdos diferentes é filosoficamente válido ou o Trabalho do Diabo que irá resultar Na Destruição da Web é algo que não me preocupa grandemente. Pode ter a opinião de que sendo específicos do IE os comentários condicionais são ainda piores do que os truques css. Assim seja, está no seu direito. Sou um purista pragmático e esta metodologia funciona comigo.

Vejamos então, sr. Santos

É fantástico que a Microsoft esteja

  1. a escutar e
  2. fale conosco
. Chegou o momento de começarmos a brincar com a versão beta do IE7 e ver o que sucede e dar a nossa opinião à sua equipa de desenvolvimento de forma a que melhore.

Actualização: E os comutadores de folhas de estilo?

Esta técnica funciona quando se pode estabelecer um número relativamente baixo de navegadores alvo. No caso do seu site ter várias peles que sejam carregadas com folhas alternativas poderá que ter que manter os truques CSS. Tudo bem. A maior parte dos seus truques devem funcionar no IE7 (embora fosse bom que tal seja testado

Estou a falar de sítios com uma capacidade quase camaliónica ao nível de um Zen Garden onde a totalidade da página muda de arranjo. Estou a construir um sítio que se limita a permitir ao utilizador alterar tipos de letra, combinações de cores, etc. E isto pode ser facilmente efectuado com as técnicas do comentário condicional visto que nesse aspecto o IE não estar tão roto que necessite de páginas alternativas para declarações de cores e tipos.

E um dia, quando o IE6 desaparecer simplesmente tiro os comentários condicionais e com um sorriso apago o AsneirasIE.css do meu servidor. Um dia.

Bem sei que os comentários não são uma forma totalmente correcta de fornecer conteúdos alternativos a vários navegadores contudo parece-me a forma mais pragmática de o fazer.

Segunda observação de encerramento sei que não usei os truques mais breves para fazer algumas das coisas por exemplo o truque relativo à largura poderia ser feito como aqui:

width:164px;width /**/: 194px;

Mas tal em minha opinião tem um defeito não ter comentários.

P.S. Onde virem no código < vejam lt e onde virem <= vejam lte

12 outubro, 2005

ALA

Saiu o nº 205 do A List Apart

O horror de um projecto Web sem finalidade! O diabo insidioso da informação que não consegue ser encontrada!

Nunca se Envolva Numa Guerra Terrestre na Ásia (ou Nunca Construa um Website Sem Razão)

Se não souber o que é que é suposto que o website em que esteja a trabalhar faça, irá tornar muito difícil que seja bem sucedido. Greg Storey dá cria um processo de desenvolvimento estratégico da web para todos.

"Encontrabilidade" ambiente: Truques de encontrabilidade

Num excerto do seu novo livro Ambient Findability, Peter Morville expõe porque é que a encontrabilidade é um elemento exigído ao bom design e à boa engenharia e o que tal significa para si.

Mais Barato do que Melhor: por que é que os clientes aceitam menos do que mais

E repesca o artigo de Adam Schumacher que investiga as razões pelas quais os clientes contratam maus web designers e o que os bons designers podem fazer quanto a isso.

Web Standards em Portugal - V

Web Standards e a iniciativa Ligar Portugal

Valida o respectivo CSS, também outra coisa não seria de esperar de algo tão simples.

A validação da marcação informa que o documento não é XHTML 1.0 Transitional válido!

Não sei a que se deve o problema com alguns caracteres na linha 21.

Depois vem a linha 29 que é a que nos permite ver o flash embebido. Bom <embed... não faz parte da directrizes do W3C para XHTML. Será que ninguém olhou para um artigo sobre como colocar ficheiros flash em documentos xhtml.

Isto tratava dos restantes erros e depois de ver quais os caracteres que provocam problemas a página passaria também a validar.

Isto é esta página passaria a validar aí com 30 minutos de trabalho.

Quanto a verificações de acessibilidade

Regra 1.1.9 Quando são usados elementos embed é necessário usar um elemento noembed no documento, esta regra não é respeitada (e só há um elemento embed).

Regra 11.2.1 Evitar usar algo que esteja em vias de ficar obsoleto. body com atributo em vias de ficar obsoleto bgcolor

O Cintia diz que os restantos pontos são observados ou não são aplicáveis ou não estão definidos.

Uma página simples e directa e graficamente apelativa.

Web Standards em Portugal - IV

Web Standards em Portugal - Portal do Cidadão

Não gosto muito de criticar terceiros sem dar oportunidade para comentar a minha crítica. Mas neste caso vou abrir uma excepção pois trata-se de um organismo público com particular responsabilidade na infraestrutura pública de acesso à informação do estado por todos os cidadãos.

O Portal do Cidadão é um elemento importante da net em Portugal e tal como analisei outros sectores quiz ver como se comportava o estado, infelizmente não muito melhor do que os particulares embora até possua linhas de orientação que espero mais tarde ou mais cedo conduzam a forte melhoria na situação.

Como se sabe para aceder a um determinado site essa entrada poderá não ser feita pela entrada (principal) mas por qualquer página e neste caso entrei por: http://www.portaldocidadao.pt/PORTAL/entidades/MCTES/UMIC/pt/ORG_umic+++agencia+para+a+sociedade+do+conhecimento++ip.htm

.

Esta página tal como se apresenta se passar pelos validadores do W3C gera 69 erros. Alguns deles são de fácil resolução e referem-se ao <HEADER>.

A escolha do DTD é muito importante, no caso de estarmos a usar a declaração: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > não podemos por exemplo fechar as instruções de metadados isto é não podemos fazer como a UMIC:

<HTML lang=pt>
  <HEAD>
  <style >.panel { OVERFLOW: auto }
  </style>
  <title>Portal do Cidadão -  UMIC - Agência para a Sociedade do Conhecimento, IP</title>
  <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  <meta name="AREA" content="entidades"/>
  <meta name="TEMPLATE" content="Organismo" />
  <meta name="DESCRIPTION" content="A UMIC — Agência para a Sociedade do Conhecimento, IP, é um instituto público, dotado de personalidade jurídica, com autonomia administrativa e financeira e património próprio.  Tem por missão o planeamento, a coordenação e o desenvolvimento de projectos nas áreas da sociedade da informação e governo electrónico.  Exerce a sua actividade sob a tutela e..." />
  <meta name="GUID" content="{93BC05F1-9DFF-4A52-B01C-DEA02926DB74}" />
  <meta name="PMOVEL" content="1" />
  
  <link href="/PORTAL/include/default.css" type="text/css" rel="stylesheet">
  <link href="/PORTAL/include/base.css" type="text/css" rel="stylesheet">
  <script src="/PORTAL/include/fonte.js" type="text/javascript"></script>
  <script type="text/javascript" src="/PORTAL/include/cookies.js"></script>
  ...

Pois tal pode ser interpretado como encerrando o cabeçalho como se pode ver na recomendação HTML W3C sobre estrutura do cabeçalho de um documento HTML 4.01.

Devido a este erro sistemático surgem 2 erros devidos aos link (das folhas de estilo).

Este é um erro comum quando se está a fazer uma transição de HTML para XHTML fácil de corrigir.

Já agora no estilo podiam acrescentar «type="text/css"» para evitar outro erro evidente.

  <script language="JavaScript">
  
   //alert(document.all['panelvisivel');

Depois na linha 45 e na linha 94 do documento (extracto acima no caso da 45) falta type="text/javascript". O erro assinalado na linha 110 trata-se de consequência do encerramento dos metas (o cabeçalho já foi dado como terminado).

 <BODY id="body" leftMargin="30">

Esta linha apresenta dois erros, um devido ao erro dos metas (body já está por omissão aberto e não pode haver duas secções body num documento. O Segundo erro tem a haver com uma extensão proprietária da Microsoft leftMargin="30", curiosamente não aparece a da Netscape e descendentes. Isto podia muito bem ser regulado por uma regra de estilo.

 <form name="Homepage" method="post" action="Organization.aspx?NRMODE=Published...

O erro apontado na linha 112 é uma chinesice pois a recomendação embora recomende o uso do atributo «id» diz que «name» é mantido por questões de retrocompatibilidade.

 <td width="19%" align="right" valign="top" id="header" nowrap>

Este é um erro de lana caprina alguém se esqueceu de verificar que só se pode usar uma identificação uma vez. Este erro é repetido várias vezes, linhas 142 (acima), 151, 168.

 <tr>
  ...
          <td>
  </td>
 ... 
<script>

Neste caso o erro começa por ser a falta de fecho do elemento <tr> da linha 135 e da falta de indicação do atributo «type» na linha 155.

A linha 165 tem o segundo tipo de erro. Eventualmente estes scripts não deviam estar aqui.

Vou saltar alguns erros de tipo já anteriormente analisado.

 <a href="/PORTAL/pt/pesquisa?st=a&page=1&paged=1&ipp=5&set=portal&q=" id="mainB...

A utilização de & não devidamente codificados é a principal causa deste erro. Vejam o as observações sobre uso de e comercial em URLs.

Após corrigir esta linha o código fica com muito menos erros.

Na linha 204 há um erro de descuido, usar em duplicado o atributo altdeve ser excesso de zelo.

Nas linhas 235 e na 239 surge um novo valor para o atributo align, ...Cidadãos" align="AbsBottom" border="0" ....

Os restantes erros são semelhantes aos já analisados com a excepção dos gerados por scripts e por tabelas mal formadas. Donde provavelmente se tira que só se devem usar tabelas para apresentar dados tabulares ou como último recurso quando se tratar de disposição de elementos numa página.

Estas são pistas que podem reduzir alguns dos erros presentes. Não sei mas o CMS usado parece gerar demasiados erros.

Acessibilidade

Este site leva a acessibilidade para cegos e pesoas com dificuldade de visão a sério e isso nota-se. Já agora seria de recomendar à UMIC que fizesse uso das suas linhas de orientação para produção de sítios web

Este site mesmo assim não passa nos meus critérios como página aceitável de um organismo público deste tipo.

11 outubro, 2005

Guia de Marcação HTML

Guia de Marcação

Neste documento irão ser referidos elementos e atributos. É importante compreender a diferença, portanto veja a amostra de código que se segue:

<a href="index.php">Entrada</a>

O elemento base HTML é a neste caso. O atributo é qualquer informação adicional sobre o elemento dentro do par inicial < >, ou neste caso o valor de href.

Para ver um exemplo de utilização de qualquer elemento neste documento por favor espreite o código fonte.


Exemplos de Header

O cabeçalho (header) principal deste guia é um elemento h1. Por favor reserve h1 para títulos de páginas individuais. Quaisquer elementos do cabeçalho podem incluir ligações como apresentado no exemplo.

O cabeçalho secundário imediatamente acima é um elemento h2, que pode ser usado como meio de indicar um cabeçalho importante dentro da página. Podem ser usados mais do que um elementos destes numa página. Pense usar um h2 excepto se necessitar de um cabeçalho menos importante, um um sub-cabeçalho de um elemento cabeçalho h2 já existente. Qualquer que seja o grau do cabeçalho este pode incluir ligações como ilustrado no exemplo.

Cabeçalho de grau três

O cabeçalho acima é um elemento h3, o qual pode ser usado sem numa página como um cabeçalho que esteja debaixo da alçada de um elemento h2 na hierarquia de um documento. Pode ser usado mais do que um por página.

Cabeçalho de grau quatro

Todos os cabeçalhos abaixo do grau três seguem as linhas de orientação acima indicadas. Só usar cabeçalhos com graus mais baixos quando necessário.

Cabeçalho de grau cinco

Todos os cabeçalhos abaixo do grau três seguem as linhas de orientação acima indicadas. Só usar cabeçalhos com graus mais baixos quando necessário.

Cabeçalho de grau seis

Todos os cabeçalhos abaixo do grau três seguem as linhas de orientação acima indicadas. Só usar cabeçalhos com graus mais baixos quando necessário.


Parágrafos

Todos os parágrafos são embrulhados dentro de marcadores p. Além disso elementos p, podem ser embrulhados num elemento blockquote se o elemento p for de facto uma citação. Historicamente blockquote foi usado só para forçar recortes, mas isso actualmente é alcançado usando CSS. Reserve o uso de blockquote para citações. Eis um exemplo de uso correcto:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras euismod fringilla arcu. Integer posuere. Aliquam ipsum. Donec eget massa ac orci tempus euismod. Donec quis neque nec neque consequat sollicitudin. Donec commodo tempor nulla. Suspendisse venenatis. Ut ut leo. Nunc placerat urna at libero. Nunc suscipit lacus.

lipsum.com

Além disso, poderá querer referir-se ao citado, como no exemplo acima. (O método correcto envolve usar o atributo cite directamente como atributo do elemento blockquote, mas visto nenhum navegador usar esta informação, é útil especificá-lo também como elemento cite separado.)


Texto Em linha

Já deve ter reparado no texto monoespacejado neste guia. Há um certo número de elementos em linha em HTML que pode usar dentro de qualquer outro elemento, incluindo abbr, acronym, cite, code, del, em, ins, kbd, strong, and var.

abbr
Usado para texto abreviado, seja um acrónimo, iniciais ou outro. Geralmente é menos trabalho (suficientemente) útil marcar só a primeira ocorrência de uma abreviatura numa página e ignorar as restantes. Qualquer texto no atributo title irá aparecer quando o rato do utilizador passar por cima da abreviatura (embora isto não funcione no IE para Windows). Exemplo abreviauras e utilização: NASA, HTML, e LX.
acronym

Só usado para abreviaturas específicas. Tal como abbr, qualquer texto no atributo title irá aparecer quando rato passar por cima do acrónimo (contudo ao contrário de abbr, isto de facto funciona no IE para Windows.) De acordo com Mirriam Webster, acrónimos são:

...palavras (como NATO, radar [...] ) formadas com as letras iniciais de cada uma das sucessivas partes ou partes principais de um termo composto; e que uma abreviatura é (como FBI) formada por letras iniciais.

Se pensa que a diferença entre acronym e abbr é exóterica, tem provavelmente razão.

code

Usado para amostras de código de programa de computador. Útil para sítios orientados para a tecnologia, caso contrário pouco útil. Exemplo de código e utilização:

function obterGel() {
 echo $umSnackDelicioso;
}

Uso em linha: tal como noutro ponto deste documento elementos HTML como em ou code podem ser considerados código e marcados como tal.

cite
Usado para definir uma citação ou referência para outras fontes de informação. Exemplo de texto citado e uso: Pode ser encontrada mais informação em [ISO-0000]
del
Usado para texto apagado ou cancelado que deve manter-se na página por alguma razão. Visto a generalidade dos navegadores representarem este elemento como texto rasurado é preferível ao elemento s. O elemento del tem ainda um atributo datetime que permite incluir uma datação directamente no elemento. Exemplo de texto apagado e utilização: Ela comprou dois cinco pares de sapatos.
em
Usado para indicar texto enfatisado. Na maior parte dos casos desejará tornar itálico o texto (usando o elemento HTML i caso contrário) deve usar o elemento em Excepções a esta regra são tornar itálico títulos, palavras em línguas estrangeiras ou quando o itálico for para diferenciar em vez de enfatisar. Nestes outros casos não existe elemento HTML adequado, e assim um elemento i ou um span com uma class à medid poderá ser preferível. Exemplo de texto enfatisado e utilização: Tem que experimentar negitoro maki!
ins
Usado para inserir texto e contrapartida do elemento del. Tal como del, ins tem um atributo datetime que permite datar directamente o elemento. Exemplo de texto inserido e uso: Ela comprou dois cinco pares de sapatos.
kbd
Usado para texto que deve ser escrito pelo utilizador. útil principalmente para instruções de computador. Exemplo de texto a ser escrito no teclado e utilização: Por favor prima Enter para continuar.
strong
Usado para relaçar ainda mais do que com o elemento em. element. Na maior parte das situações onde deseja texto negrito (usando o elemento HTML b ) deve usar o elementoe strong em seu lugar. Excepções são enegrecer estilisticamente exemplos, primeiras ocorrências de nomes num artigo etc, onde o enegrecimento é usado para diferenciar em vez de enfatizar. Nestes casos não há elementos HTML adequados e assim usar o elemento b ou um elemento span com uma classe à medida poderá ser preferível. Exemplo de texto strong e utilização: Não ponha os dedos na tomada elétrica.
var
Useado para variáveis em porções de código de programa de computador. Útil em sítios orientados para as tecnologias de informação, caso contrário pouco útil. Exemplo de var e utilização: Adicionar 5 a $result e recalcular.

Listas

Depois há listas. ul indica uma lista não ordenada (ie. uma lista de itens que não exigem números ou uma lista com balas). ol indica uma lista ordenada, e estão disponíveis vários esquemas de numeração através de CSS (incluíndo 1,2,3... a,b,c... i,ii,iii... etc). Cada item dentro de ul ou ol exige estar rodeado por marcadores <li> e </li>, para indicar itens individuais dentro da lista (como é possível que já tenha percebido, li significa item de lista).

Além destes tipos de lista, dl é um outro tipo de lista uma lista de definições. Em vez de listar itens, o conteúdo de dl consiste em pares de dt (Termo a definir) e dd (Descrição da Definição). Embora possa ser chamada "lista de definição", dl pode ser aplicada noutros cenários onde uma relação de pai/filho seja aplicável. Pode ser usada para marcar diálogos com cada dt identificando o orador e cada dd contendo as suas palavras.

Tantek Çelic não gosta desta «solução» e prefer microformatos

Exemplo de listas e aplicações:

  • Esta é uma lista não ordenada/classificada.
  • Esta lista tem dois itens.
  1. Esta lista é uma lista ordenada.
  2. Ela tem dois elementos.
  3. Não, menti tem três elementos.
Isto é uma expressão/termo.
Esta é a definição do termo, vivendo ambos numa dl.
Isto é outro termo.
E também este tem aqui nesta linha a sua definição.
Isto é um termo que partilha a sua definição com o termo imediatamente abaixo.
Eis o termo a definir abaixo.
dt os termos devem estar por si sem dd, mas nesse caso eles partilham a descrições seguinte disponível dt. Não pode ter um dd sem um pai dt.

Como descobrir um pretendente a advogado dos «Web Standards»

Se houver uma correspondência encontrou um pretendente.

  • Fala da importância dos marcadores alt.
  • Reinvindica que <b> e <i> estão obsoletos.
  • Mas dizem-nos depreciados..
  • Usam <span style="font-style: italic;">, porque <i> tem a haver com a apresentação.
  • Querem que os programas usem <em> e <strong> quando o INTERFACE DE UTILIZADOR diz itálico e negrito.
  • Usam o marcador <cite> para texto citado.
  • Chateiam sobre marcadores em maísculas em HTML.
  • Afirmam que o XHTML 1.0 é mais semântico do que HTML 4.01.
  • Afirmam que o XHTML 1.0 é mais estruturado do que HTML 4.01.
  • Afirmam que o XHTML 1.0 tem menos a haver com a aparência do que o HTML 4.01.
  • Afirmam que o navegadores analisam o XHTML servido como text/html mais rápido do que analisam HTML.
  • Referem-se às outras vantagens do XHTML sem especificarem que vantagens são essas.
  • Usam documentos XHTML 1.0 Transitional com disposição criada por tabelas ao mesmo tempo de reinvindicam compatibilidade acrescida com dispositivos móveis graças ao XHTML.
  • Migram sítios de HTML 4.01 Transitional para XHTML 1.0 Transitional e mantêm-nos a serem servidos como text/html com todos os scripts em JavaScript antigos no lugar e julgam que os seus sítios são à prova do futuro.
  • Usam notação XML para elementos vazios em páginas que são suposto ser páginas HTML.
  • Chateiam por falta de doctype em documentos application/xhtml+xml ou SVG e apontam presunçosamente para o validator.w3.org.
  • Reinvindicam que todas as tabelas são o diabo personificado.
  • Advogam posicionamento absoluto com CSS baseado em pixels como substitutos das tabelas do diabo.
  • Mudam //EN no final do identificador público no doctype para o código da língua em que escrevem a página.
  • Omitem uma declaração de espaço de identificação (namespace) em documentos XHTML ou SVG e acham que está tudo bem pois os documentos são validados.
  • Servem documentos escritos com um vocabulário doméstico XML com transformações XSLT para navegadores HTML em vez de servirem HTML, porque o XML é mais semântico.

10 outubro, 2005

Rails e Validação XHTML

Validar (X)HTML em Rails

Quase todos os programadores que utilizam técnicas recentes, e entre estas, os testes unitários desejaram automatizar a possibilidade de validar os seus projectos. O que resulta em (X)HTML de um projecto em Rails pode facilmente ser validado pois em Julho de 2005 o Validator do W3C o tornou mais fácil ao permitir que fragmentos fossem lançados POSTed no seu serviço. Agora com uma simples asserção à medida, os testes funcionais podem assegurar-se que a sua marcação é e se mantém válida.

Basta adicionar isto ao seu test/test_helper.rb:

  def assert_valid_markup(markup=@response.body)
    require 'net/http'
    response = Net::HTTP.start('validator.w3.org') do |w3c|
      query = 'fragment=' + CGI.escape(markup) + '&output=xml'
      w3c.post2('/check', query)
    end
    assert_equal 'Valid', response['x-w3c-validator-status']
  end

E depois (dada uma acção designada por 'home') chamar a asserção a partir dos seus testes funcionais como em:

  def test_home
    get :home
    assert_valid_markup
  end

E pronto, a sua marcação passa a ser validada de cada vez que executar os testes, e se alguma coisa invalidar o resultado, vai sabê-lo de imediato.

assert_valid_markup() irá validar o conteúdo de @response.body (que recebe o seu valor pela linha get ); Pode ainda passar um argumento para verificar algo mais. Se desejar mais detalhes sobre erros de validação pode alterar a asserção de modo a ver response.body que é um ficheiro XML com informação sobre cada erro.

Comentários sobre Web Standards em Portugal II

Há já uns dias comecei a levar um dos meus projectos para a frente, quiz ter uma imagem do estado da Web Portuguesa em relação aos Web Standards.

Para meu grande espanto e horror fiquei com uma terrível sensação: as equipas/pessoas que desenvolveram os sítios que visitei não se devem importar nada com esses aspectos é como se de cada vez que comprassem uma lâmpada para as suas casas, terem de comprar um casquilho novo, uma chave (de fendas ou outra) nova um novo contrato de fornecimento de electricidade, etc pois nada seria standard como os seus sítios.

Depois um dos meus leitores o André Luís teve a amabilidade de fazer um comentátrio do género ninguém se preocupa com isso. Não sei se é verdade mas quase que parecia. Fui vez o site dele e tenho que admitir que além de estar conforme o básico, e até para além do básico, é visualmente apelativo e faz sentido.

Aproveitei ainda ir ao seu portofólio ver os seus trabalhos mais antigos e aí verfica-se que realmente ele fez uma evolução marcada, passou de sítios não conformes e com utilização de elementos numa situação aplicados noutra situação (exemplo table para disposição de conteúdos em vez de dados de tabelas) para um ambiente onde cumpre as regras.

Nas observações abaixo quanto às correções deve ser tido em conta que o André provavelmente deseja manter os seus trabalhos anteriores nesse estado até para quem lhe encomende trabalhos possa ver o que é que ele foi aprendendo ao longo do tempo. É um sinal de capacidade de aprendizagem e humildade (nós não nascemos iluminados).

  1. André Luís

    Valida como xhtml 1.1. Porreiro

    A fase dois também passa scripting e estilo segregados. A fase três passa: não há utilização de tabelas para coisas indevidas.

    Utilização de informação por assinatura. Porreio.

    Não gosto de classificações automáticas, a não ser como auxiliares. Gosto do teu site/blog pessoal.

  2. Feira de Maio

    Bem sei que o site que escolhi é de 2003 e talvez na altura não fosse incorrecto (se o João Craveiro não faz erros eu (nem tu) também não). No entanto até podias corrigir a situação pois não é particularmente grande e só tens 10 erros (que de facto são menos). Vê os resultados do validator.w3.org e verás que a maior parte são fáceis de corrigir. Já me tinha esquecido o site é o da feira. Como julgo que percebes, para mim o aspecto formal não é o mais importante mas se reparares mesmo após validares o site em questão resta-te o problema de teres usado uma tabela para posicionares as coisas. Lembra-te que a net não é um livro e talvez não seja de todo razoável querer ser uma espécie de Grande Irmão dos utilizadores. A segunda coisa que eu faria nesse site seria empregar só marcação semântica.

    Aqui então houve algo que não entendi, aqueles ícones não servem para nada a não ser decoração. Eu sou daqueles que acha que o design não é decoração, não gostei.

  3. Escola de Natação de Santarém

    5 erros na validação de framset com enconding 8859-1(?). Alguma razão especial para usar esta codificação?

    Não gostei logo que me fosse dito que necessita de um Plug-In (Flash). Deve na minha opinião verificar se o navegador tem determinada capacidade e, no caso de não ter, degradar em conformidade (dando mesmo a possibilidade de instalação a pedido).

    Então não seguiste uma construção normalizada. Tenho que admitir que não gosto de esquadrias mas quando se usam devem ser bem usadas.

Já agora a talho de foice as minhas esperanças quanto à aplicação de Web Standards no ensino superior português estão a decrescer a cada minuto. Ainda não tenho um relatório sobre o assunto mas estou quase a vomitar.

Não me digam que só nas autarquias vou encontrar algumas ilhas?

André Luis

Quiz comentar a ou minhas entradas sobre web standards em Portugal e disse:

...não vou abrir um blog soh para comentar.

Muita coisa vai mal em portugal. (olha, rimou) Falta coordenação nos defensores dos standards.. algo tem que ser feito a nível nacional para trazer a necessidade e o interesse do uso de standards aos clientes.. não às empresas de webdesign.

Quando os clientes começarem a conhecer os benefícios de certeza que alguns vão começar a pedir "quero um site daqueles bem feitos, com standards". Se eles agora sabem pedir em flash, qualquer dia sabem pedir em standards.

Já tinha referido tudo isto no blog do ( Joao Craveiro um dia destes... ;)

Realmente o João Craveiro foca estes aspectos, mas na minha modesta opinião sobre o assunto é mais perto do seguinte: quando vou ao médico espero que ele use as boas práticas profissionais da medecina, não espero ter que lhe dizer que as deve usar, o mesmo se deve passar na construção de sites web.

O problema que se pode levantar é eventualmente não ser possível repassar alguns custos para o cliente. Outro problema é as dúzias de programadores/designs de web que quase pagam para trabalhar.

O que é que pensam disto?

P.S.: Retirei os comentários pois só quase aparecia spam.

08 outubro, 2005

Novo Calvin e Hobbes

Para amantes do Calvin e do Hobbes

Saiu nos Estados Unidos um novo triplo album do Calvin com as tiras de 1985-95.

07 outubro, 2005

O Guia de viagem dos nossos visitantes

Navegação - O guia de viagens das nossas visitas

A navegação e os menús não são um assunto técnico. Não estão confinados ao mundo das Tecnologias de Informação, mas são usados na vida real. A navegação é um assunto de interacção humana. Os seres humanos com todos as suas nuances e problemas necessitam e usam-nos. A navegação bem sucedida importa-se com as necessidades dos visitantes, e não com a promoção de uma técnica ou da estrutura da organização. O que é que acharemos mais útil na nossa Junta de Freguesia: um índices das repartições ou uma lista de funcionários?

Exemplos da vida real - manter as coisas simples

O sucesso da navegação num dispositivo depende largamente de quão fácil é usado. Em qualquer momento os visitantes devem ser capazes de encontrar:

  • Onde estão
  • Onde podem encontrar outras coisas
  • Onde podem encontrar ajuda no caso de se perderem

Exemplos reais passam-se por exemplo nos elevadores e escadas nos centros comerciais.

  • À entrada do centro uma lista dos andares indica o que pode encontrar neles.
  • Muitos deles apresentam informação adicional como, casas de banho, extintores, rotas de evacuação, meios de acessibilidade para alcançar os restantes andares (elevadores, rampas para cadeiras de rodas, escadas rolantes).
  • Os melhores centros comerciais apresentam ainda sinais adicionais para mapas detalhados dos vários pisos.

Após subir uma escada rolante encontramos outro sinal, que descreve o que pode ser encontrado nesse piso e ponde se podem encontrar os quiosques de informações, telefones, casas de banho, etc.

Algumas vezes esses sinais são mapas, acompanhados de uma lista de todas as lojas disponíveis no piso. Normalmente do outro lado ficará uma lista de todos os pisos com indicações realçadas sobre o piso em que nos encontramos.

Este tipo de navegação funciona e os centros comerciais menos avançados tratam de copiar as boas práticas dos mais bem sucedidos. Esses centros comerciais são bem sucedidos e os lojistas também pois a navegação encaminha-lhes os visitantes.

Navegação de Website - Porquê torná-la mais complexa?

A beleza desta actuação é a sua simplicidade. Não esmagamos o visitante com opções mas damos-lhes o que necessitam num determinado ponto da sua visita. No caso de desejarem mais informação podem consultar os mapas detalhados dos pisos e encontrar o que desejam.

Eis algumas traduções entre o mundo real e um web site:

Exemplo vida real
Equivalente em web site
Lista de todos os pisos
Navegação principal
Lista de todos os pisos com informação do que se pode encontrar em cada um
Página inicial
Mapa detalhado dos pisos
Mapa do sítio
Mapa detalhado e lista do piso
Navegação secção
Informação sobre cadeiras de rodas e elevadores
Declaração de acessibilidade
Quiosques informativos
Contactos e FAQ

A verdadeira natureza da web e as máquinas de indexação/busca permitem aos visitantes entrarem nos nossos sítios em qualquer "piso" e com qualquer tecnologia.

Por isso é complicado usar uma navegação que precisa explicação ou que dependa de determinada tecnologia. Mesmo o teste da disponibilidade desta tecnologia na página inicial não significa que os visitantes não fiquem bloqueados numa página - podem vir de um marcador de livro, de uma ligação ou de uma lista de resultados de busca de um motor de busca.

A outra face da moeda do argumento do "manter as coisas simples" são os clientes: muitos deles gostam de navegação bem feita e levam e julgam o seu ambiente técnico como o padrão na web.

Os novos visitantes e a sua experiência

Descobir a diversidade de visitantes num centro comercial é muito fácil. Funcionários de lojas bem treinados, funcionários de retaguarda e seguranças podem aperceber-se das necessidades das pessoas:

  • ajuda especial, digamos uma cadeira de rodas,
  • permitir-lhe que levem o seu cão de guia,
  • tradução de etiquetas,
  • informação detalhada dos produtos,
  • orientação na selecção de um produto,
  • ajudar alguém a descansar e respirar melhor.

Na web não sabemos nada sobre os nossos visitantes.

Os nossos visitantes - pessoas de que dependemos para sobreviver, para lerem a nossa sageza ou tomarem parte nas nossas experiências - podem:

  • Terem dificuldades de visão e necessitarem de tamanhos de tipos de letra muito grandes, com fortes contrastes e navegação fácil de encontrar
  • Cegos que usem leitores de ecrã para lhes dizerem o que se passa
  • Não serem capazes de usar um rato de forma adequada
  • Com dificuldades para utilização de um teclado
  • Dependerem de acesso por um comutador (um pedal operado pelo pé, um sensor operado pelo piscar dos olhos, um capacete com extensão para primir teclas)
  • Dependente de reconhecimento vocal
  • Surdo ou com dificuldades auditivas
  • Algumas mais ou combinações das dificuldades acima descritas

Melhorias por capacidade ou por decisão

Podemos usar tecnologia para ler-mos alguns dos parâmetros do navegador contudo essa informação não nos ajuda muito:

  • A resolução do ecrã não equivale ao espaço disponível para o navegador - os utilizadores podem usar programas de ampliação ou um tamanho de tipo de letra grande, e não por sua opção mas porque precisam.
  • A disponibilidade de um plug-in não significa que o visitante possa tirar partido de um interface de utilizador rico dado por essa tecnologia, um utilizador cego pode ter o seu leitor de ecrã com Flash activado (pois é uma boa ferramenta para streams de áudio), mas terá dificuldade de usar o interface de pegar e arrastar do Flash via um leitor de ecrã.
  • A disponibilidade de scripting não significa que o agente utilizador (navegador) possa de facto reproduzir as alterações na página. Os nossos scripts podem esconder coisas, mas o utilizador pode não ser capaz de as voltar a descobrir
  • A língua apresentada pelo agente utilizador não quer dizer que o visitante fale essa língua, pode ser um computador da organização onde trabalhe ou um terminal público.

Interagimos com seres humanos não com a tecnologia, e assim a ideia de ser capaz de predizer o que se passa por meios tecnológicos está condenada à partida.

Sabemos o que devemos fazer - gostariamos de usar uma navegação fácil, e gastar o tempo adequado na disposição e nas funções de fundo e tornar o site bonito e fácil de manter.

Contudo, não o fazemos, em vez disso gastamos demasiado tempo a conceber e desenvolver uma implementação técnica da navegação e depois ficamos sem tempo nem orçamento quando é necessário limpar o código e escrever documentação de manutenção.

As razões são muitas:

  • Os nossos clientes viram navegação inacessível em sites dos concorrentes e gostaram dela
  • Os clientes não se importam ou não conhecem o impacto de navegação inacessível
  • Os programadores/designers (nós) não se importam ou não conhecem o impacto de navegação inacessível
  • A navegação inacessível dá a impressão de manutenção fácil (só um JavaScript incluido!)
  • É tentador reinventar a roda (houve um americano que o ano passado conseguir patenteá-la). Como programadores e designers uma das nossas linhas de orientação é fazer as coisas melhores. Com frequência falhamos o alvo.
  • Alguma navegação inacessível tem um alto benefício para o "utilizador médio" - seja ele quem for.

Esta última razão é aquela que nos deve fazer pensar. Se a navegação é muito utilizável e se facilita muito a alguns, porque não torná-la uma opção para esses a obterem?

A via rápida é a melhor?

Por exemplo a navegação de menús descendentes multinível é provavelmente a navegação existente que ajuda muito alguns.

Este tipo de navegação é muito boa quando:

  • Os visitantes têm um navegador decente ou JavaScript activado
  • Os visitantes têm um rato ou a navegação com o teclado está adequadamente disponível
  • Os visitantes têm espaço de ecrã à sua disposição suficiente - visto que rolar o conteúdo desfaz o menú.
  • Os visitantes têm coordenação mão/olhos adequada e podem ler tipos de letra com tamanhos pequenos.

Muitos pressupostos foram feitos. A tecnologia não pode ajudar na maior parte destes problemas. No campo de ampliarmos os tipo de letra pode um problema que podemos não reparar quando se desenvolve este tipo de navegação.

Os utilizadores de teclado terão que fazer tabulação ao longo das ligações de cada vez que carregem uma destas páginas

Deixar a escolha ao visitante

Visto não haver nenhum modo de predizer as capacidades dos visitantes, a opção mais fácil é deixar tal à sua escolha. O site obtem uma navegação fácil e lógica que só mostra as opções necessárias e que oferece uma checkbox ou um botão com a indicação de "navegação melhorada" com uma ligação "o que é que é isto" explicando do que se trata.

Uma vez escolhida, a opção é guardada num cookie ou no perfil do visitante e não há necessidade da voltar a tomar. Se a funcionalidade que necessitamos depende de uma tecnologia como o Flash ou scripting, o botão pode ser gerado via essa funcionalidade, e assim não aborrecer quem não tenha essa opção logo desde o início.

Linhas de orientação fundamentais para uma navegação acessível

Seguidamente apresento algumas linhas de orientação que o podem ajudar a determinar se a nossa navegação tem alguma probabilidade de ser acessível ou não. Sempre que tivermos de dizer não há um problema.

  • Se o scripting e os estilos não estiverem disponíveis
    • a navegação fica claramente visível e compreensível?
    • a secção actual é óbvia?
    • a quantidade de ligações disponíveis é fácil de manipular via teclado e são necessárias no contexto actual?
  • Se o scripting e os estilos estiverem disponíveis
    • a navegação ainda fica utilizável via teclado?
    • o visitante tem que tabular através de várias ligações invisíveis?
    • pode a navegação ser redimensionada no navegador sem sobreposição?
    • a navegação depende de um determinado espaço disponível?
  • Qualquer destas situações com as outras duas combinações(Scripting on / CSS off, e vice-versa)
  • Há contraste suficiente entre o fundo e aquilo que fica por cima da navegação?
  • Todas as ligações fazem sentido sem contexto (alguma da tecnologia de auxílio dá as ligações das páginas e os cabeçalhos como listas para facilitarem a navegação)?
  • Todas as ligações com o mesmo palavreado apontam para a mesma página?
  • Os nomes das ligações são fáceis de compreender?

Navegação como ferramenta

A navegação é um dos mais importantes componentes de um site. Claro que a parte mais importante é o próprio conteúdo. Se a nossa navegação prende a atenção dos visitantes e os destrai do conteúdo então falhou a sua finalidade. O conteúdo deve determinar a navegação, não ao contrário.

É fácil esquecer este facto, a navegação é uma das poucas coisas que nós os programadores e designers da web podemos brincar. É da nossa responsabilidade dizer ao cliente que o conteúdo é aquilo que as pessoas procuram, e nos visitam, e não pela navegação espectacular que exista. As melhores navegações são aquelas que não nos lembramos.