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

13 novembro, 2005

Erros Comuns

Erros Comuns

Quando pertencemos a uma lista de correio tão específica como a CSS-D esperamos não ver a não ser por parte de principiantes (sem desprimor para eles, visto todos o termos sido e alguns assim se manterem), dizia que esperamos não ver código como este


.caixa {
   border: 1px solid black;
}

#azul {
   background-color: blue;
}

#encarnado{
   background-color: red;
}

Pois não será normal só haver um elemento azul e um elemento encarnado numa página, nem será normal dar nomes a class ou id que tenham a haver com o seu aspecto visual, mas sim nomes que tenham a haver com a sua funcionalidade.

Molly Holzschlag mencionou num artigo sobre como atribuía nomes a estes atributos estes atributos indicando no mesmoa livro/artigo as desvantagens de dar nomes de acordo com a apresentação.

12 novembro, 2005

Treehouse #2

Saiu o #2 do Treehouse

Neste número são incluídos textos de Ryan Campbell (código), Alex McClung (design), Nathan Smith (negócios), entrevistas com Peter-Paul Koch, Lisa McMillan, Josh Williams e críticas de livros "Foundations of Ajax", "Thinking with Type", "The World is Flat".

11 novembro, 2005

Tabelas ou Disposição CSS

Parece haver uma batalha a decorrer entre web designers sobre a utilização de tabelas em arranjos para a web. Os proponentes da utilização de tabelas normalmente referem-se à compatibilidade com os navegadores e à rapidez da concepção dos sites. Os oponentes acham que a utilização de tabelas para arranjos (disposição de elementos visuais) não é conforme os web strandards e a acessibilidade da web. Para se puder perceber como começou esta polémica necessitamos de relembrar a história do HTML e dos arranjos.

O controlo do estilo visual de uma página da web por tabelas nunca foi algo intencional por parte dos criadores do HTML. Na sua opinião só serviam para reproduzir dados com colunas e linhas. Não era um mecanismo para resolver necessidades relativas a arranjos mais elaborados, mas alguns web designers mais inventivos descobriram que podiam usar tabelas para criar arranjos nos quais tivessem mais controlo.

Desde essa altura os web designer têm vindo a usar (incorrectamente) regularmente a linguagem HTML, principalmente por necessidade. Contudo no final dos anos 90 o W3C introduziu as folhas de estilo em cascata (CSS). As CSS tornavam possível a aplicação de estilos a documentos HTML. Os navegadores rapidamente começaram a integrar suporte para as CSS, e os web designers começaram a aplicar estilos simples no seu HTML, como o tipo de letra, a cor, as cores do fundo e as imagens. Contudo o uso de arranjos CSS (em particular arranjos com colunas) não se espalhou até muito mais tarde.

Ao longo dos anos houve um movimento para "purificar" o modo de codificação dos websites. Num esforço de criação de web standards que dão uma abordagem lógica e que dão acessibilidade à web para leitores de texto, bots, dispositivos móveis e muito mais. Um novo padrão foi criado. Um padrão que anda à volta da utilização adequada de XHTML e CSS. O XHTML deve ser codificado de forma a oferecer uma estrutura lógica para o conteúdo enquanto o CSS deve ser usado para criar uma concepção gráfica única.

Há várias razões para que os web designers devamd deixar de usar tabelas para arranjos e adoptarem o uso de CSS para controlo dos arranjos:

  • Conformidade com os padrões de web do W3C
  • Todos os navegadores modernos suportam CSS para controlo de disposição (embora o IE necessite por vezes de remendos)
  • Se bem codificado, as CSS tornam alterações globais fáceis de aplicar
  • A implementação adequada de conteúdo em documentos XHTML, com o uso de CSS só para estilo e disposição ajuda a criar websites acessíveis para pessoas com certas incapacidades
  • As páginas podem ter muito menos código, tornamdo-as mais ligeiras de for usado XHTMl e CSS (com poucas excepções)
  • O principal argumento para continuar a usar tabelas vem dos maus hábitos e de alguma complacência. Normalmente diz-se que é mais fácil usar tabelas em especial pela necessidade de utilizar remendos/truques para uma reprodução adequada no IE, embora sendo verdadeira esta afirmação há um momento a partir do qual temos que começar a usar padrões para "obrigar" os produtores de navegadores a evoluírem.

09 novembro, 2005

ALA - 207

A List Apart 207

Saiu o número 207 da A List Apart, para pessoas que constroiem sítios na web. Neste número são apresentadas consequências inesperadas - tanto positivas como negativas - da concepção de interface comum e de selecção de opções de acessibilidade.

Andy Hagans diz-nos não ser coincidência que os motores de busca gostem de sítios da web altamente acessíveis. Ao concebermos sítios acessíveis, estamos já a usar uma técnica de optimização para motor de busca. Hagans explica ainda outra razão para ter em conta a acessibilidade.

Nick Usborne, pergunta-nos se testamos as nossas concepções? Se não, Nick Usborne, gostaria que nos responsabilizassemos pelas opções de concepção e um efeito quantificável que tais opções podem ter nos sítios web e nos negócios.

O artigo repescado é de Kevin Potts e trata de conselhos sobre a criação de um negócio evitando os erros cometidos por ele.

04 novembro, 2005

A colheita do dia

Se ontém foi um dia de boa colheita, na minha opinião, hoje parece que não está pior

4 de Novembro de 2004

Dulce Pontes em Stanford

7 de Outubro de 2005

Google Advertising Patents for Behavioral Targeting, Personalization and Profiling

3 de Novembro de 2005

Google Patent : Organic Results Ranked by User Profiling

Sem data inicial

Um interessante projecto de investigação

Sem data inicial

Direitos fundamentais

AJAX-VI

Galeria de Imagens

No sítio DHTML Nirvana colocaram um Guia Ajax que usa ajax para se ir carregando (com um pouco de pisca pisca em alguns navegadores!). O guia começa com os fundamentos das técnicas Ajax e, gradualmente, à medida que as páginas são voltadas, vai caminhando para coisas mais complexas terminando numa galeria de imagens.

AJAX-V

Lista de Tarefas com XForms

Eric Bruchez da Orbeon criou uma aplicação de Lista de Tarefas. Implementa um interface de utilizador dinâmico totalmente criado em XForms, sobre um motor OPS XForms.

Este exemplo ilustra muitas das características do XForms tais como:

  • xforms:repeat aninhados
  • Uso de "relevant" para reprodução condicional de controles
  • Escrita que permite formatação automática de datas
  • Uso de xforms:submission com "instance="replace", aqui para chamar um serviço capaz de formatar um documento XML em HTML
  • Uso de instâncias múltiplas
  • Uso de xforms:setfocus e xforms:setindex

Pode analizar a aplicação: Lista de Tarefas.

Pode ver o código original da aplicação: código original de Lista de Tarefas.

AJAX-IV

Struts

Struts é o avô das infraestruturas Java para web e embora tenha deixado de estar na moda como as infraestruturas JavaServer Faces, WebWork, Tapestry, ... ainda há muita gente a escrever aplicações com Struts.

Paul Browne escreveu um artigo de introdução chamado "Sprinkle Some AJAX Magic in Your Struts Web Application."

O artigo foca o lado do cliente ajax, em vez da integração com Struts.

Concepção da sua Aplicação Ajax

Paul Browne

O rascunho do JavaScript acima pode aceitar o modo de utilização do Struts na maior parte das aplicações incluindo aquelas que são muito mais complexas do que a do nosso exemplo (muito simples). Contudo pode achar que os pontos seguintes podem tornar mais fácil escrever e usar o seu código:

  • Para evitar código duplicado, podemos frequentemente usar a mesma "Struts Action" e o JSP para o pedido inicial (isto é mostrar a totalidade da página) e o AJAX (actualizar parte da página and JSP for the initial request (i.e., show full page) and the AJAX (update part of page) requests.
  • Na classe comum (controlador), decidir que secções da página JSP (todo o JSP ou só parte dele) necessita de ser enviada ao navegador. Ao estabelecer indicadores seja na sessão do servidor web ou ActionForm, a página JSP sabe que secções necessitam de ser reproduzidas.
  • No JSP, usar marcadores Struts ou JSTL para decidir se necessita de reproduzir uma secção HTML ou não. Pode descarregar uma versão deste projecto já com capacidade Ajax aqui: struts-Ajax.zip

AJAX-III

Ajax

Monitorização para usabilidade usando técnicas Ajax

Eric Pascarello recentemente escreveu uma entrada sobre a utilização de técnicas Ajax para monitorização de acções de utilizador para captura/registo de erros. O aspecto básico é que vai contra a corrente normal de que o ajax pode ser usado para praticar o mal "espiar o utilizador" usando o ajax para registar todas as acções do utilizador para poder testar em profundidade quando este visita uma página para testar e detectar erros. Eric está a desenvolver uma ferramenta para reter a totalidade das acções do utilizador, registá-las e potencialmente efectuar uma reprodução das mesmas para ver onde ocorrem erros. Isto pode ajudar a evitar o problema de algué dizer "Não me lembro a aplicação simplesmente rebentou!"

Pode ser uma ferramenta para o laboratório de usabilidade do pobrezinho . Se puder reproduzir a interacção do utilizador com a página, pode observar exactamente onde e o que é que ele clicou e onde é que a sua aplicação funciona e onde é que não. Uma ferramenta deste tipo não deve ser de desenvolvimento simples mas pode ajudar nos testes e monitorização de aplicações Ajax

03 novembro, 2005

Que dia

Que dia

netvibes.com start.com live.com Maps Yahoo Infraestruturas AJAX Open Source com Suporte para Serverside Java eHub
Microsoft contra o Vale da Sílica
Produto Concorrência
Windows LiveYahoo,Google, AOL,Salesforce.com, Zimbra
Office LiveGoogle, 37Signals
Live MessengerSkype-eBay, Friendster, Plaxo, AIM, Google Talk, Yahoo, Google (Sidebar), Apple
Microsoft GadgetsWidgets
Microsoft MapsGoogle, Yahoo, Mapquest*, etc

O único que se pode usar cá mas de facto não tendo interface tão moderno quanto os outros.

AJAX-II

AJAX

Parece que os desktop virtuais estão novamente na moda. Live.com, start.com , netvibes.com, protopage.com, etc...

Visualmente são quase todos funcionais (no caso das entradas da microsoft só parcialmente e num caso não em firefox) e agradáveis. Podemos em todos eles arrastar, largar, adicionar e apagar novas "secções". No caso do protopage e do netvibes a funcionalidade é custumizável e persistente (mantendo-se para as sessões seguintes).

Por enquanto as aplicações são limitadas no caso da protopage a notas (substitutos electrónicos dos post-it), listas de tarefas a executar, ligações favoritas e buscas rápidas, nas ofertas da microsoft podemos ainda assinar notícias, ver a metereologia (inclui Lisboa e outras localidades aqui à volta) e por exemplo embeber o nosso correio (hotmail ou live).

Construção de acessibilidade universal

Construção de acessibilidade universal e lista de verificação

Esta secção trata de assegurar que um website do governo (UK) é desenvolvido para servir a maior audiência possível usando o mais alargado número de sistemas (plataformas de hardware e software) e que as necessidades dos utilizadores com incapacidades são levadas em linha de conta.

Não podemos contar que os nossos utilizadores tenham tecnologia padronizada, assim, para assegurar o acesso à nossa informação na web o ónus está do lado dos nossos administradores da web para levar a mensagem para benefício de todos.

É muito importante que a organização do seu sítio da web seja centrado no utilizador e usável desde o início mas mantenha o nível de acessibilidade e usabilidade ao longo da sua existência.

Utilize cada um dos pontos de verificação para assegurar que as suas páginas de web estão conformes estas directrizes.

Diretrizes Nucleares

    Lista de Verificação
  • Mantenha as páginas simples
  • Seja consistente ao longo de todo o website
  • Utilize o HTML como formato de informação por omissão
  • Não devem ser usados métodos específicos de um navegador num website
  • Usar um mínimo de imagem - usar imagens de pequenas dimensões se possível
  • Não dependa da cor para transmitir informação
  • A cor do texto deve contrastar sempre com a cor do fundo
  • Use HTML para estruturar o documento, não aplique estilo
  • Use Folhas de Estilo em Cascata para formatar e dar estilo aos elementos fundamentais do website
  • Os tamanhos dos tipos (de letra fonts) devem ser possíveis de alteração pelo utilizador final - não os defina de forma absoluta
  • Qualquer cor deve ser passível de alteração pelo utilizador final
  • Todas as imagens importantes devem ter um atributo "alt" e descrição
  • As descrições do atributo "alt" devem ter significado
  • Uma barra de navegação, em texto, deve ser usada ao mesmo tempo que um "salto à navegação"
  • Devem ser fornecidos métodos alternativos de navegação para quem não possa usar um dispositivo de orientação
  • Se usados imagemaps então têm que ser no formato do lado do cliente
  • Deve ser dada uma alternativa em texto se forem usados imagemaps
  • É obrigatório fornecer uma versão alternativa em texto de qualquer informação fornecida em formato áudio ou vídeo
  • Qualquer informação que seja fornecida que exija um plug-in deve também ser fornecida em HTML
  • Todas as páginas devem estar conformes o padrão WAI nível A
  • Os logos WAI apropriados devem ser apresentados na página de entrada de uma organização para ilustração da conformidade com as recomendações W3C

Sumário

Existe um mito que o desenvolvimento de websites acessíveis e de páginas inclusivas seja caro, que tenham que ser chatas e aborrecidas, que tenham de ser escritas para o menor denominador comum - tal não é verdade! Também não é verdade que os utilizadores tenham que ver uma página web da forma que um designer a pensou. Com a proliferação de navegadores, tamanhos de ecrãs, profundidades de cor e outras preferências do utilizador não é possível frequentemente que uma página seja vista da mesma forma por todos.

O que é importante é que os utilizadores devem poder ver uma página da forma que desejem ver com o que equipamento que tenham disponível e evitar más experiências que resultem em redução de visitas repetidas.

A integração da acessibilidade no processo de desenvolvimento de websites cria websites de forma eficiente que trabalham correctamente para o maior número de pessoas na maior parte das situações - isto significa mais utilizadores. O desafio aos responsáveis pelo desenvolvimento de web é a criação de páginas que sejam simultaneamente visualmente apelativas e completamente acessíveis para um espectro de utilizadores alargado.

Estamos a entrar num mundo em que gerir um número diferente de versões do mesmo conteúdo se irá torna num padrão. Irá provavelmente fornecer conteúdo diferente a meios diferentes tais como dispositivos móveis. Irá provavlemente conceber e escrever conteúdo de forma a comunicar com diferentes audiencias também. O advento da banda larga significa que o conteúdo multimédia se irá tornar cada vez mais apropriado.

Igualmente, para tornar um website inclusivo, há necessidade de existirem alternativas para suportar pessoas e sistemas com capacidades diferentes. Não se trata só de pessoas com incapacidades. Alguns sistemas corporativos estão protegidos com firewall para extrair conteúdo activo. A acessibilidade é também algo quando se comunica com uma audiência de negócios.

  • Se forem usados frames, é necessário usar um elemento noframes e cada frame dentro do frameset deve ter um título.
  • Os scripts e as applets devem ser complementadas por um elemento noscript para aqueles utilizadores que acedam com navegadores com scripting indisponível ou com firewalls que o bloqueiem.
  • é necessário fornecer equivalentes textuais, ou transcrições a elementos não textuais - multimédia ou informação apresentadas de forma gráfica
  • Páginas alternativas textuais devem ser raramente necessárias e não são consideradas boas práticas. Se forem usadas páginas só de texto então o seu conteúdo:
    • Deve ser tão completo e amplo quando a de conteúdo gráfico
    • Deve ser actualizada em simultâneo
  • A cor não deve ser usada como única forma de transmitir informação
  • Navegação - os utilizadores invisuais devem ter meios alternativos de interação com menus, barras de ferramentas e elevadores, ligações etc

Web Standards em Portugual

Web Standards em Portugal

Por vezes sou um chato em relação à utilização de web standards e da importância dessa utilização. Não me preocupo só com os aspectos formais da questão mas preocupa-me a utilização por exemplo de html (ou xhtml) que não esteja conforme os standard.

O problema é que normalmente a uma má (lei-a-se não conforme os standards) utilização de elementos e/ou atributos no html sucede uma má experiência de utilização por parte dos utilizadores do sítio.

Dizendo de outra forma validar html e/ou css não deve ser um fim mas um meio para alcançar algo. Isto não significa que não possa haver situações onde não haja validação. Agora coisas básicas como um charset mal indicado, um DOCTYPE mal indicado não são aceitáveis.

Por exemplo quando se quer massificar a utilização das declarações electrónicas no ministério das finanças devia ter-se em conta que nem toda gente tem instalado JAVA no seu computador, nem todas as pessoas chegam à página das declarações da mesma forma. A necessidade de scripting aparece como uma mensagem ao visitante "o seu navegador não tem capacidade de scripting ou esta está desactivada". O que devia suceder era haver conteúdo alternativo em seu lugar e não isto (mas é melhor que o caso que me trás hoje aqui). Ao dificultar a um certo número de pessoas a usabilidade do sítio está-se de facto a fomentar a sua não utilização. Se um dia for obrigatória a entrega de todas as declarações por via electrónica espero que se lembrem de todos e não façam como a FEMA nos EUA que usou formulários que só podiam se preenchidos no IE para pessoas que pedissem ajuda na sequência do Katrina.

Se o computador estiver por detrás de uma firewall, que extirpe elementos activos, podem mesmo não ter acesso a nenhum dos conteúdos activos existentes nesta página e não há uma degradação que seja aceitável.

O Ministério da Saúde

O ministério da saúde está agora a construir a sua nova presença na Web, não faço ideia se têm nesta nova versão este tipo de coisas em mente. Espero que não usem a técnica no sítio da Direcção Geral de Saúde, sem javascript, página em branco.

O respectivo construtor masterlink.pt parece ter muito cuidado com o aspecto gráfico esquecendo que a concepção de páginas web ultrapassa em muito o aspecto. Esta estratégia provoca problemas para quem necessitar ampliar o texto, mesmo que tenha o JavaScript activo.

Ou seja o código até pode ser de 1ª água (não sei porque não o verifiquei ainda) mas se verificarem as regras de acessibilidade e usabilidade (quem não tem acesso nem sequer pode usar) é dito que no caso de um conteúdo importante ser obtido com um script se deve fornecer uma alternativa (noscript). Parece-me que o conteúdo (todo neste caso) do sítio é a sua razão de existência, pelo que não me passa sequer pela cabeça que se fez um sítio para só ser visto com JavaScript activo. Por acaso adoraria ser mosca.

Realmente o sítio da Direcção geral é um sítio com frames (gerados pelo JavaScript). Não entendo que razão possa levar uma entidade pública a criar/deixar criar um sítio deste género. Mas deve haver alguma que não seja pura incompetência do dono ou excesso de zelo na obfuscação do conteúdo.

Já repararam que uma das regras básicas de construções de sítios governamentais numa série de países a primeira coisa que têm é uma exigência de simplicidade...como podem ler nesta minha tradução apressada: construção de acessibilidade universal do sítio do governo de sua majestade.

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;