18
Jun 10
publicado por andr3, às 16:55 | comentar |

Nos últimos anos tornou-se cada vez mais frequente encontrarmos com pequenos controlos na web que são enriquecidos com a magia do JavaScript.

Sejam eles tabs (abas em Português), paginações, votações, etc., o que interessa é que o controlo "quebra" o conceito de hiperligação (link) do hipertexto. Como conceito, os links servem para interligar hiper-documentos em que cada link refere um outro documento através do seu URL.

Ora, uma vez que o AJAX permite carregamento de conteúdo sem refrescar toda a página, esta é uma técnica perfeita para mostrar grandes quantidades de conteúdo que não são necessariamente acedidos em todas as visitas.

Exemplo do link Todo o SAPO na Homepage do SAPO

Evitar barreiras desnecessárias

Existem imensas formas de programar o comportamento do exemplo mostrado.

  1. <a href="#" onclick="mostrarTodoOSapo();">Todo o SAPO</a>

    O browser executa a função de JavaScript e segue o href, provocando às vezes um scroll para o topo. Sem JavaScript, nada acontece ao clicar/activar o link.

  2. <a id="todo-o-sapo" href="#">Todo o SAPO</a> e num ficheiro à parte de JavaScript $('todo-o-sapo').onclick = function (){ mostrarTodoOSapo(); return false;};

    O browser executa a função de JavaScript e não segue o href. Sem JavaScript, nada acontece ao clicar/activar o link.

  3. <a id="todo-o-sapo" href="/todo-o-sapo">Todo o SAPO</a> e num ficheiro à parte de JavaScript $('todo-o-sapo').onclick = function (){ mostrarTodoOSapo(); return false;};

    O browser executa a função de JavaScript e não segue o href. Sem JavaScript, o browser segue normalmente o href, logo que o documento servido nesse URL deve imitar a função desempenhada por JavaScript.

Neste último ponto, estamos a falar duma questão de acessibilidade visto que se trata de permitir acesso ao conteúdo. No entanto, ao resolver este problema estamos também a melhorar a usabilidade do link uma vez que passamos a permitir também que o utilizador opte por abrir o link numa nova Janela ou tab (opção "Abrir link numa nova Janela" do menu contextual).

Esta solução tem o custo de ter de desenvolver uma versão server-side da funcionalidade mas muitas vezes isso é bastante simples e justifica o investimento.

Exemplo prático

Quando desenvolvemos o sistema de tabs da Homepage do SAPO, tivemos todos estes cuidados. Para além disso, era crucial que o utilizador pudesse usar o endereço do browser para partilhar o link para determinada parte da homepage.

Assim sendo, adoptámos a seguinte estratégia...

location.hash = '/'+lnk.getAttribute('href');
//exemplo: http://www.sapo.pt/noticias => http://www.sapo.pt/#/noticias

Os links que tiveram esta atenção foram:

No entanto, não conseguimos resolver um cenário.

  1. Utilizador com javascript, partilha o endereço do browser: http://www.sapo.pt/#/noticias/tecnologia
  2. Utilizador sem javascript segue este link e vê a aba por omissão aberta e não a de tecnologia.

Nesta situação, não conseguimos que o link partilhado seja outro sem provocar um recarregamento da página. Também não conseguimos que o link partilhado funcione sem javascript porque a parte do endereço chamada "Hash" não é enviada para o servidor.

Se tiverem algumas ideias, deixem nos comentários em baixo.

Mais pormenores

Se ainda assim quiserem ler sobre esta técnica, normalmente apelidada de JavaScript Não-Obstructivo (Unobtrusive JavaScript), podem consultar os slides publicados em Abril de 2009 no Blog do Developers: JavaScript done right.

12 comentários:
De Rui Lopes a 18 de Junho de 2010 às 18:18
"html - head - noscript - meta content refresh" a apontar para a página sem o hash.

é um mega-hack, mas deve funcionar...
De andr3 a 21 de Junho de 2010 às 12:10
Mega-hack indeed! Mas acabei de experimentar numa página dummy e o redirect só funcionou quando o javascript estava mesmo desactivado! :-O

Vamos fazer mais testes para garantir que funciona bem em todos os browsers.

Obrigado Rui! Sim, é feio, mas funciona! :-)
De Paulo Pereira a 19 de Junho de 2010 às 18:44
Talvez dê com o mod_rewrite do Apache.

RewriteRule ^#/(.*)$ /$1


Esta regra não se podia aplicar desta forma porque afectaria todos os URLs com hashes e só é pretendido que isso aconteça para alguns, mas serve de exemplo para o comportamento que se pretende.

Desta forma, http://sapo.pt/#/noticias é o mesmo que http://sapo.pt/noticias, para quem tenha ou não tenha JavaScript ligado. Não tenho a certeza absolute se é possível capturar URLs com a hash através do mod_rewrite.

Outra ponto que reparei: como há dois painéis de tabs, a hash só guarda o último que foi clicado. Não seria bom guardar ambos?
De andr3 a 21 de Junho de 2010 às 12:16
Paulo,

O fragment identifier não é enviado para o servidor pelo browser... logo não é possível tomares decisões server-side tendo isto em conta.

Por isso é que o :target no CSS é útil para alterar aspecto do fragmento seleccionado. Tudo acontece no browser.


Quanto à questão das duas tabs.. bem apontado. Foi um ponto que considerámos e depois acabámos por apenas "memorizar" o último estado para não poluir demasiado o endereço. Porque depois começamos a guardar o estado de tudo na homepage: noticias, destaques, tab da pesquisa, widgets abertas, etc.

Assim se quiseres partilhar, por exemplo, um link para o radar podes:
http://www.sapo.pt/destaques/radar#destaques

o fragment identifier faz match a um id existente na página e o browser faz scroll. :)

Isso foi outro debate... se devíamos forçar o scroll via javascript no caso do "alvo" estar abaixo da linha de água... Qual é a tua/vossa opinião no caso:
http://www.sapo.pt/#/destaques/cinema
?
De Rui Lopes a 21 de Junho de 2010 às 13:13
Eu faria o scroll... é o comportamento esperado pelos utilizadores quando há um hash.
De andr3 a 21 de Junho de 2010 às 15:28
Hmmm.. certo!

Mas e não achas confuso/não-coerente que uns endereços façam scroll e outros não?
De Rui Lopes a 22 de Junho de 2010 às 12:09
Teoricamente todos deveriam fazer scroll, mas a resposta adequada depende muito das espectativas da audiência. I.e., façam testes de usab :)
De mwm a 19 de Junho de 2010 às 21:13
Também adoptei o método de guardar o "estado" no path do url com # depois de ler este livro » http://bulletproofajax.com/ que tem bastantes exemplo de acessibilidade para sites acedidos com e sem Javascript.

Acredito, no entanto, que o número de pedidos de páginas ao SAPO que são clientes sem Javascript deve ser < 1%.

Não tenho a certeza se é possível saber se o cliente tem javascript no pedido da página ou se só depois desta chegar ao cliente.
Se der, é mudar o esquema do path de "#/noticias/..." para algo para o servidor interpretar e devolver (ou ignorar se o cliente tiver Javascript) como "?#noticias/...".
Se não der, deve ser possível acrescentar um header refresh ao detectar uma tag .
De andr3 a 21 de Junho de 2010 às 12:24
Obrigado pela ajuda! De facto a sugestão é similiar à do Rui Lopes... que a funcionar em todos os browsers será implementada. ;)

Bela leitura! O Jeremy tem sido um dos principais impulsionadores destas técnicas... é grande apologista do Hijax (ou seja, desenvolver com Ajax em mente mas só implementá-lo depois de ter uma versão não dependente de JS a funcionar).

De facto, uma das coisas que não implementámos foi a história. Ser possível fazer Back/Forward no browser e "navegar" nos estados já percorridos. Fica para um futuro post. ;)
De mwm a 21 de Junho de 2010 às 17:15
O que reparo é que o sistema não salta para a tab certa que vem no path.

Por exemplo se abrirmos o browser e entrarmos em "http://www.sapo.pt/#/noticias/vida", vamos directos à tab "destaques" ou então à última que estava gravada no cookie.
De andr3 a 21 de Junho de 2010 às 15:26
Uma coisa que não respondi há pouco... a questão dos 1% sem javascript.

Isso é um mito... repara, existem uma série de condições para que um user-agent não tenha suporte para javascript:

- é crawler de motor de busca (conta à mesma como visita);
- utilizador numa empresa corporativa com restrições e sem privilégios para ligar o JS;
- utilizador (avançado) consciente dos perigos de XSS e CSRF, com extensões tipo NoScript instalados;
- telemóveis com js off (por serem antigos, para poupar bateria, etc)..

Assim sendo, creio que serão bem mais que 1%. No entanto, estamos a pensar em correr uns testes para verificarmos isso com certeza. Depois partilhamos aqui no blog. ;)
De mwm a 21 de Junho de 2010 às 17:11
Hmm pois. Não me lembrei dos crawlers. Devem aumentar substancialmente essa %.

Comentar post

Autores
Pesquisar
 
Posts recentes

Processo de criação do ME...

Testes de Usabilidade no ...

MEO Interactivo

Banco de Padrões de Desig...

dConstruct 2010

JavaScript não deve compr...

Acessibilidade no SAPO

Slides da UX LX - 2010

"Mostrar password" consid...

UX - O Regresso

Arquivo

Fevereiro 2012

Setembro 2010

Julho 2010

Junho 2010

Maio 2010

Setembro 2009

Julho 2009

Junho 2009

Maio 2009

Categorias

todas as tags

Subscrever feeds