Ao contrário da maioria dos especialistas, entre as quais Jakob Nielsen, um reputado crítico de web design, penso que as frames são uma técnica muito útil e, em certos casos, ainda sem alternativas competitivas.

Esta nota teria sido mais pertinente em 1998, numa época em que a maioria das páginas na Web eram construídas (codificadas) "à mão". Em finais de 2001, a maioria das páginas empresariais e institucionais - que já representam a larga maioria dos conteúdos disponíveis na Web - são construídas automaticamente a partir de bases de dados, eliminando boa parte da motivação para o uso de frames.

O uso de frames justificava-se como uma forma de atingir determinados objectivos a baixos custos e sem intervenções do lado do servidor onde estavam alojadas as páginas. A partir do momento em que a presença de uma entidade na Web justifica o investimento em software de geração automática de páginas e em servidores dedicados, as vantagens das frames reduzem-se, como se tenta ilustrar no gráfico abaixo, onde se cruza o orçamento disponível com as competências dos web designers:

Figura 1 - Interesse relativo do uso de frames

Os criadores mais inexperientes devem abster-se de usar frames pois não sabem evitar as armadilhas mais evidentes (cf. Jakob Nielsen). Noto com satisfação que a maioria dos sítios que usam frames já corrigiram estes erros de principiante.

A partir do momento em que o autor já tem conhecimentos médios mas ainda não tem orçamento, as frames tornam-se muito úteis, especialmente nos casos que veremos abaixo. Isto é indicado pelo pico maior na Figura 1. Para um nível de experiência médio, mas com um orçamento superior, torna-se compensador aprender tecnologias activas (CGI, ASP, PHP, etc.) que permitem criar páginas dinamicamente, reduzindo o interesse do uso de frames na generalidade dos casos.

Para os autores com boas competências de HTML, as frames continuam a ser interessantes em aplicações de nicho e só são substituíveis por enormes orçamentos. Estas aplicações estão representadas no segundo pico da Figura 1. Finalmente, há casos pontuais onde nenhum orçamento consegue substituir com vantagem o uso de frames.

Note-se que além do custo de criação e manutenção dos sítios há que considerar o custo de acesso, medido em tempo de espera e carregamento e, possivelmente, em bytes transmitidos. Ao aumentar a importância relativa do custo de utilização, o uso de frames pode tornar-se vantajoso, mesmo em casos em que o orçamento não constrangeria outras soluções.

Origem e compatibilidade das frames

As tags de <FRAME> e <FRAMESET> foram introduzidas com o browser Netscape Navigator 2.0. Os seus autores propuseram a inclusão das frames na especificação HTML 3.2 mas tal só viria a surgir nas especificaçãoes HTML 4.0. Todas as versões dos browsers Netscape posteriores as reconhecem bem como todos os Internet Explorer a partir da versão 3.0, inclusive.

As frames são reconhecidas pela esmagadora maioria dos browsers para computadores pessoais e para televisão. Contudo, encontrei já algumas versões de browsers para computadores de bolso (Personal Digital Assistant) que não reconhecem frames, bem como os browsers auditivos ou em formato de texto. Mais à frente apresentarei soluções que minimizam os problemas de compatibilidade, permitindo o acesso à informação aos utilizadores desses browsers.

Exemplos simples de utilização de frames

Começarei pela ilustração de casos de utilização simples de frames, acessíveis aos autores com conhecimentos médios de HTML (representando o maior pico do gráfico da Figura 1).

1. Uma barra de navegação sempre visível

Esta é a utilização mais antiga e mais frequente das frames. Quando as frames surgiram em 1995 (Netscape 2.0) muitas páginas HTML eram textos muito longos com algumas imagens. Ao fim de vários scrolls, era reconfortante ter sempre visível uma barra de navegação, normalmente do lado esquerdo.

Figura 2 - Frameset com duas frames

A barra de navegação contém os ponteiros (links) para os vários documentos e alguma informação de autoria (entidade responsável, logotipo, e-mail, morada e telefone, etc.).

No limite, este modelo foi usado para indicar as várias secções dentro de um único documento. Creio que esta utilização é negativa, pois dificulta o acesso à página de conteúdo ao ocultar o endereço e aumenta o número de ligações ao servidor - uma por cada ligação - sem vantagens significativas. É preferível o sistema de índice na própria página como uso nesta nota.

2. Uma barra de navegação independente das páginas de conteúdos

Quando um sítio na Web é criado e mantido por várias pessoas com experiência limitada e ainda menores recursos (tempo e orçamento), é por vezes difícil garantir que todos usem um mesmo template (modelo) de página e que as barras de navegação das páginas já publicadas são actualizadas à medida que o sítio evolui. Nestes casos, uma solução eficaz, garantindo a continuidade da navegação com um esforço (custo) mínimo, é incluir em cada página um ponteiro (link) para a página de entrada (homepage) e uma barra de navegação apresentada numa frame separada.

O desenho das páginas do sítio será semelhante ao da Figura 2, podendo variar a posição da barra de navegação. Entre 1997 e 1999 foram populares alguns esquemas de frames (framesets) mais complexos, com várias barras de navegação, frames com informação de copyright no rodapé, hierarquias de frames em vários níveis, além de inúmeras variações. Contudo, à medida que o design web se foi institucionalizando, a maioria dos sítios convergiu para modelos mais simples e mais universais (no sentido de serem acessíveis pelo maior número de pessoas). Hoje o esquema de frames mais frequente é o original (Figura 2): duas frames, navegação à esquerda e conteúdo à direita.

Porque preferi um esquema diferente ?
O esquema tradicional é muito bom quando se acede a um sítio pela primeira vez, pois dá um grande destaque à navegação à custa da ocupação de uma fracção importante da área disponível, mas nas minhas páginas optei por pôr a barra de navegação numa frame em baixo. 
A versão de 2000 das minhas páginas foi criada de forma a que uma mesma página fosse acessível com ou sem frames, com alterações mínimas na funcionalidade. Por isso pareceu-me estultícia desperdiçar tanto espaço com a barra de navegação. Além do mais, julgo que a barra de navegação deverá surgir no fim de página, para que o leitor só seja chamado a decidir para onde vai, depois de ler a página que preparei para ele. 
Ao abrir uma destas páginas com frames a barra de navegação surge no fundo do ecrán, numa frame própria; se se abrir a página principal numa nova janela - sem frames, portanto - surge no fundo do documento uma barra de navegação escrita com JavaScript. Caso o leitor não use JavaScript, pode usar o ícone no topo superior esquerdo da página, que se vem tornando a localização esperada da ligação à homepage.

A solução de duas frames indicada na Figura 2 é também muito eficaz no caso de páginas curtas e/ou sistemas de navegação complicados, de que são exemplo os menus de navegação multí-nível.

Quando a razão entre a informação e a navegação é pequena (medida em número de bytes a transmitir) torna-se muito ineficiente enviar a cada página uma nova barra de navegação. Aumenta-se o tempo de espera do utilizador e o custo (telefone ou largura de banda). Nestes casos, é preferível enviar a barra de navegação uma única vez e apresentá-la numa frame própria e enviar as páginas de informação noutra frame. Um exemplo clássico deste tipo de páginas são os fóruns, onde os utilizadores contribuem com perguntas e respostas curtas. Sem frames, a informação nova representará em média uma pequena parcela (tipicamente inferior a 10%) do número de bytes transmitidos. Com frames, a informação é nova claramente preponderante e pode chegar aos 90% do total de bytes transmitidos.

3. Acesso simultâneo a dois documentos

Para comparar dois documentos ou para usar um documento em apoio de outro é muito eficaz usar frames. Dois exemplos clássicos desta utilização são a análise de textos e os dicionários.
No primeiro caso, é possível ler um texto e o seu comentário, ou a sua tradução, num mesmo écran, mesmo que o comentador não possa manipular o texto original. Neste caso, o comentador cria um frameset contendo numa frame o texto original, disponibilizado por uma entidade externa, e noutra frame o seu comentário, ou tradução. Se o comentador (ou tradutor) puder manipular uma cópia do documento original, abrem-se novas possibilidades pois é possível sincronizar os dois documentos, garantindo que os comentários referentes a um parágrafo aparecem junto a esse parágrafo no texto original.

Figura 3 - Comparando dois textos

No caso dos dicionários especializados ou glossários a aplicação faz-se da forma seguinte: o autor de um texto criará numa página separada um glossário onde incluirá a definição das palavras ou expressões relevantes. O documento principal é apresentado numa frame maior (ver Figura 4). Ao longo do texto, o autor indicará com uma ligação (link) todos os termos que constarem do glossário. Sempre que o leitor tiver uma dúvida sobre um desses termos, activa a ligação (clicando sobre a palavra, por exemplo), surgindo a definição na frame inferior.

Figura 4 - Usando um glossário

4. Exemplo: uma pequena empresa de pesca (ou uma escola)

A possibilidade de comparar dois ou mais documentos na mesma janela permite conceber formas intuitivas e eloquentes de apresentar informação. Tal como um gráfico consegue traduzir a informação de um texto ou de uma tabela de forma imediata e clarividente, a apresentação simultânea de múltiplos documentos torna evidentes alguns aspectos da informação enquanto revela aspectos antes obscuros.

Por exemplo, imagine-se uma pequena empresa de pesca (ou uma escola). Recorrendo a uma estrutura do tipo da Figura 3 é possível apresentar um tipo de dados numa das frames enquanto se apresentam dados comparativos na outra. Torna-se imediato seguir as capturas das várias espécies de pescado para meses homólogos em anos diferentes (ou as notas de uma turma a cada disciplina nos vários períodos lectivos), comparar o desempenho dos vários barcos (ou das várias turmas), analisar as capturas por espécie (ou as classificações por disciplina), etc..

Para obter estes resultados basta registar as tabelas e gerar os gráficos para as várias variáveis, guardá-los em páginas HTML clássicas e chamá-las manualmente.

Tudo isto é feito sem JavaScript, sem bases de dados, sem CGI e pode ser realizado por pessoas com competências médias de HTML. Se os autores tiverem conhecimentos sólidos de JavaScript, podem automatizar algumas tarefas e tornar a apresentação mais agradável, mas ainda assim, trata-se da mesma informação guardada num servidor estático.

Finalmente, se os recursos humanos e financeiros possibilitarem soluções activas, os dados são armazenados numa base de dados e as páginas são criadas por medida a partir de queries (perguntas, métodos). Esta solução torna obsoleto o uso de frames , msa dificilmente estará ao alcance de uma pequena empresa (ou de uma escola).

Mais uma vez se ilustra que o interesse potencial das frames depende sobretudo das competências dos autores e dos recursos disponíveis para a criação dos sítios na Internet e/ou intranets.

Erros típicos no uso de frames

Até 1998, a comunidade de internautas era formada sobretudo por utilizadores especialistas, mormente universitários e militares, que aprenderam a usar extensivamente as potencialidades dos browsers. Estes utilizadores compreendem a tecnologia subjacente e sabem reagir quando acontece algo fora do comum. Sabem igualmente tirar partido dos browsers, abrindo ligações (links) em novas janelas, adaptando o tamanho das janelas (resize), abrindo frames em janelas separadas, trocando os esquemas de cores e fontes (style sheets), etc.. Embora estes utilizadores frustrem frequentemente o objectivo dos web designers , em contrapartida são muito tolerantes a falhas.

A partir dessa data, a vulgarização da Web trouxe para a comunidade dos internautas uma maioria de pessoas alheia à tecnologia da Web. Por um lado, estes visitantes são mais dóceis, no sentido em que fazem menos experiências e se acomodam mais facilmente às exigências dos web designers, por outro, ficam confundidos quando algo corre mal. Foi nesta data que se generalizou a mensagem:

Site optimizado para resolução X * Y, com o browser Alfa Beta.

Quem não cumprisse as especificações, era enviado para o sítio da empresa criadora do browser requerido para fazer o download da última versão, ou era porventura convidado a comprar um novo monitor, e o problema considerava-se resolvido!

Infelizmente a realidade nem sempre se adapta às exigências dos web designers e muitos utilizadores continuam a aceder à Web com sistemas antigos, limitados e diferentes dos requeridos.

No início, houve problemas com a deficiente implementação das frames, que hoje estão resolvidos na maior parte das plataformas. Sobram algumas plataformas que simplesmente não implementam as frames.

Como as frames violam o paradigma dos documentos formatados em páginas ligadas, qualquer erro no uso das frames pode dificultar, senão impedir, o acesso aos sítios por parte dos visitantes menos experimentados ou com recursos informáticos mais modestos. Indico abaixo quais os erros mais graves e mais frequentes e apresento sugestões para os evitar.

1. Assumir o uso de frames

Este é o erro mais comum. Se o web designer partir do princípio que o todos os visitantes visualizam a página com frames e não incluir menus de navegação nas páginas de conteúdo, os utilizadores sentir-se-ão perdidos se acederem ao sítio por uma das páginas de conteúdo. Isso sucede sobretudo quando o visitante é encaminhado por um motor de busca mas também a partir de uma página impressa ou uma indicação de um amigo, entre outros.

Quando se usa uma frame como menu (ou barra) de navegação deve sempre incluir-se um menu de navegação em cada documento, bem como uma ligação à página de entrada (homepage). O ideal seria que este menu fosse idêntico ao da frame, mas um menu com as secções principais é aceitável.

Quando se usam frames para relacionar documentos deve-se indicar no cabeçalho ou no rodapé que existem outros documentos associados, sugerindo o uso do frameset ou, em alternativa, janelas múltiplas com nomes diferentes. Esta opção é automática: se existir um frameset com as frames nomeadas, elas são usadas, caso contrário, as frames são transformadas em janelas autónomas, perdendo-se a formatação gráfica numa janela única.

2. Obrigar ao uso de frames

Este erro é ainda pior do que o anterior.

De acordo com a vontade dos seus criadores, há sítios que só podem ser percorridos com frames. Este efeito pode ser obtido de duas maneiras: ou usando JavaScript para detectar a ausência de frames e forçar o carregamento automático do frameset ou omitindo quaisquer meios de navegação que obriguem o utilizador a procurar a página de entrada (homepage) e a partir daí carregar o frameset com a frame de navegação. Se não user frames, o utilizador obtém páginas incompreensíveis e/ou erros de JavaScript.

Há browsers que não implementam frames, há utilizadores que não gostam de frames e há écrans demasiado pequenos para o uso confortável de frames. Por isso, é inaceitável obrigar os utilizadores ao uso de frames. A solução é não utilizar estes esquemas que forçam o utilizador contra a sua vontade. Admito, uma excepção, contudo - talvez porque a utilize nas minhas páginas :-)

Em alguns sítios onde o aspecto gráfico é primordial (albuns de fotografias, jogos, exposições virtuais) julgo ser aceitável requerer o uso de frames para criar um efeito cénico ou visual, tal como faço na lanterna em DHTML (neste exemplo seria possível não usar frames mas o código resultaria mais complexo e de resultados imprevisíveis em algumas plataformas/browsers). No álbum de fotografias da Bélgica (Bienvenue em Belgique) forço mesmo o uso de frames, pois caso contrário perderia o efeito visual dos menus suprimíveis.

3. Usar frames com SCROLL=NO ou RESIZE=NO

É comummente aceite pelos web designers que os elementos mais feios de um frameset são as barras de scroll. Acresce que muitas das aplicações das frames pressupõem um ajuste rigoroso entre frames (acertado ao pixel) e transições invisíveis entre frames.

Para atingir estes objectivos, muitos são os web designers que incluem a especificação SCROLL=NO e/ou RESIZE=NO nos seus framesets. Para os utilizadores com monitores de reduzidas dimensões esta especificação pode impedir o acesso a elementos essenciais das páginas HTML. Para ultrapassar este problema basta abrir a frame numa nova janela mas a maioria dos utilizadores que o enfrentam não sabem fazê-lo.

Cabe ao web designer experimentar o seu trabalho em várias plataformas e vários browsers, com ênfase nos monitores pequenos, tendo o cuidado de verificar que nenhum elemento essencial fica oculto. Por outro lado deve também garantir que as frames auxiliares (navegação, glossário, etc..) ocupam apenas o espaço indispensável, deixando para as frames principais o máximo de espaço para maior conforto de leitura.

Minimizando as limitações das frames

Cientes dos riscos potenciais das frames, os seus criadores incluiram a tag <NOFRAMES> para permitir a compatibilidade com os browsers que não implementem frames. Curiosamente, os principais browsers (Netscape Navigator e Internet Explorer) não contemplam a opção de recusar as frames.

A primeira solução para ultrapassar às limitações das frames seria criar em todas as páginas uma versão sem frames, usando <NOFRAMES>. Esta solução é um disparate, pois duplica o tamanho das páginas sem aumentar a informação.

A segunda solução seria criar um sítio alternativo sem frames, acessível a partir da primeira página onde estaria explicitamente indicado (como faço nas minhas páginas de 2000) ou implicitamente indicado entre tags <NOFRAMES>. Esta solução também me parece actualmente pouco útil pois o âmbito de maior interesse das frames reside nos sítios de pequenos recursos (humanos e orçamentais).

A terceira solução seria implementar as medidas mitigadoras propostas acima.

Além das soluções alternativas às frames, há problemas com a própria implementação das frames que modificam e dificultam a operação dos browsers.

A impressão era uma das limitações das frames, entretanto resolvida pelos criadores dos principais browsers. Hoje já é possível imprimir as frames em folhas separadas ou imprimir um frameset completo numa única folha. Infelizmente, há ainda muitos utilizadores que não conhecem as várias possibilidades e outros que não reconhecem quando estão na presença de frames, o que dá origem a resultados inesperados e incompreendidos.

Outro problema das frames, este ainda por resolver completamente, é a definição de bookmarks (favorites). Quando um utilizador pretende guardar um endereço (URL), pretende que a página com o frameset lhe apareça exactamente igual quando voltar a este endereço, isto é, deseja que cada uma das frames seja aquela que se lhe apresentara anteriormente. No entanto, tal não sucede na maioria dos casos.

O endereço que aparece disponível para guardar é o da entrada do sítio ou de um frameset no estado inicial. Aliás, alguns web designers preferem esta solução, forçando os utilizadores a re-entrarem pela "porta principal" do sítio a cada nova visita.

Em alguns casos simples - por exemplo, quando só há uma frame de conteúdo e outra para navegação - o utilizador pode ultrapassar facilmente este problema abrindo a frame de conteúdo numa nova janela e guardando esse endereço.

É também possível aos web designers tornear este problema com JavaScript, inscrevendo no endereço as variáveis que indiquem o conteúdo de cada uma das frames. Todavia, este processo não funciona sem JavaScript, torna o endereço ininteligível e exige uma codificação aturada do frameset e de cada uma das páginas.

Ainda outro problema das frames, que atormenta os web designers desde o início: como mudar duas ou mais frames simultaneamente? A solução está encontrada desde 1997 e passa de novo pela codificação com JavaScript.

Usando <A HREF="javascript:funcao()"> é possível acrescentar código que mude todas as frames com um "clique" (tendo o cuidado de deixar para o fim a frame activa, ou passando o código para o frameset). Mas esta solução inibe totalmente a funcionalidade do sítio para browsers sem JavaScript activo. Outra solução, compatível com browsers sem JavaScript e mais amiga dos motores de busca, é mudar a frame activa com um URL normal e as demais frames com um evento: <A HREF="nova_pagina.html" onClick="funcao()">. Neste caso, o evento é tratado primeiro e se a função retornar "true" o browser muda o endereço da frame activa para nova_pagina.html.

O último problema das frames que quero apresentar é o problema do botão de back (retroceder). Este botão é uma das funções mais usadas num browser e nele se baseia parte da confiança que os utilizadores usam para navegar na Net: não há riscos em seguir uma ligação (link) pois carregando em back (retroceder), é sempre possível voltar à página anterior.

O botão de back permite reconstruir a história linear da sessão de navegação. A introdução de frames quebra o percurso linear ao lançar vários caminhos divergentes. Para este problema não há soluções elegantes. A melhor forma de voltar atrás é consultar a história da sessão numa janela própria e identificar a página já visitada que corresponde ao ponto onde se deseja regressar.

Utilização avançada de frames

Além das utilizações atrás descrita para as frames, outras há que abrem novas possibilidades e que são ainda impossíveis de realizar sem frames ou, quando o são, requerem sítios activos e orçamentos muito maiores.

Estas aplicações recorrem na sua maioria ao JavaScript e destinam-se aos web designers com bons conhecimentos de programação e alguma experiência. Por outro lado, são sítios menos convencionais - de nicho, diria - e podem confundir alguns utilizadores principiantes ou aqueles que usam browsers sem frames. O seu uso deve ser prudente e em alguns casos acompanhado de uma página mais simples que explica a funcionalidade implementada e justifica a necessidade do uso de frames.

1. Comparação de múltiplos documentos

Esta aplicação já foi brevemente aflorada atrás: se se compararem dois documentos usando frames e JavaScript, é possível mantê-los sincronizados, isto é, quando se segue um link numa das frames, a frame do documento de comparação é também actualizada mantendo o paralelismo.

Este efeito pode ser obtido com event handlers, usando onScroll e onClick. Numa versão mais simples pode ser feito usando anchors nos dois documentos, <A NAME="paragrafo6"></A>, e usando simples funções de JavaScript para mudar as duas frames sincronamente, recorrendo a JavaScript: <A HREF="#paragrafo6" onClick="sincroniza('paragrafo6')">. Neste exemplo, o link actualizaria a frame activa após o código da função sincroniza()ter actualizado o conteúdo da(s) outra(s) frame(s) de comparação.

2. Efeitos visuais

Neste campo, costuma dizer-se que o limite é a imaginação.

Uma das aplicações mais simples é enquadrar uma frame funcional por quatro frames não funcionais. Este efeito reproduz um palco teatral e permite exibir uma frame de tamanho fixo centrada em écrans de dimensão variável. Esta técnica é de uso generalizado. Nas minhas páginas, uso-a na lanterna em DHTML e também no álbum de fotografias Bienvenue em Belgique.

Além desta forma, é possível criar inúmeras aplicações, alterando o tamanho das frames com o ponteiro (cursor do rato) ou por JavaScript, jogando com framesets em cascata (nested frames) ou criando novas páginas em resultado de código JavaScript. As hipóteses estão condicionadas apenas por quatro regras:

1. as frames são apresentadas da esquerda para a direita e de cima para baixo,
2. quando uma frame não cabe no espaço disponível, a apresentação depende do parâmetro de SCROLL.
3. a complexidade dos framesets (em especial nested frames) podem levar os browsers ao limite,
4. o prazer de fazer "malabarismos" com as frames não deve sobrepôr-se à funcionalidade pretendida. O interesse do utilizador é o fim último a manter sempre presente.

Um exemplo básico deste princípio é apresentado no exemplo das cortinas de correr. As duas frames podem ser deslizadas na horizontal, revelando uma terceira frame por trás.

Um exemplo mais elaborado, combina um enquadramento com frames não funcionais com uma frame central funcional; esta última encerra um segundo frameset, onde se pode fazer um puzzle com dois pavões. Este segundo exemplo requer uma janela de dimensão superior a 640x480 pixels.

Estes dois exemplos não usam JavaScript e ilustram as potencialidades de um uso criativo e experiente das frames.

3. Armazenamento de variáveis

O armazenamento de variáveis é um dos principais problemas da criação de sítios complexos e que guardem memória das actividades passadas.

Na primeira década da Web, quatro tipos de soluções diferentes foram encontradas:

1. Armazenar a informação no servidor. Esta é a solução mais antiga mas exige um servidor de maior capacidade para gerir as operações extra. Além disso, obriga a um fluxo intenso de mensagens entre o browser do utilizador e o servidor o que atrasa a ligação e por vezes obriga a soluções desconfortáveis, em que o utilizador tem de dar amíude o seu acordo ao envio de dados.
   As primeiras tecnologias recorriam a páginas estáticas de HTML e scripts CGI que completavam algumas páginas ou efectuavam outras operações.
2. Armazenar a informação no cliente, usando um cookie. Um cookie é uma cadeia de caracteres (string) que se pode armazenar no computador do cliente. É a excepção ao protocolo HTTP pois permite ler e escrever na máquina do utilizador. Tem uma série de restrições: um limite máximo de 4000 caracteres, um máximo de dez cookies por domínio, não se pode ler os cookies dos outros domínios, etc..
   Apesar de serem quase sempre inofensivos, os cookies granjearam má fama pelo abuso que deles fizeram alguns sítios comerciais e também porque constituiam a excepção ao anonimato da Web, o que atraiu uma oposição empenhada e ruidosa. Por isso, há hoje sítios que se gabam de ser cookie free, há portais que prometem permitir navegar pela Web sem que os cookies identifiquem a nossa máquina e hoje quase todos os browsers (Netscape Navigator e Internet Explorer incluídos) têm opções para gerir a aceitaçãos de cookies.
3. Criar sítios activos. Esta é a solução usada pelos produtores de grandes sítios. Como todas as páginas resultam da extracção de informação de uma base de dados, basta guardar na base de dados as informações do utilizador relevantes. Há algumas restrições legais - por exemplo nos EUA e na UE não é possível guardar números de cartão de crédito - mas o sistema funciona bem desde que o utilizador se identifique no início das operações personalizadas e isso pode ser feito por um login (registo) com username (nome) e password (palavra-passe) ou através de um cookie.
4. Passar a informação no URL. Esta solução é bastante corrente e por vezes combina-se com a anterior. Pode passar-se uma pequena quantidade de informação no campo de search do URL (a string que aparece a seguir a "?") desde que a página de destino inclua código JavaScript para interpretar este código.
   Esta solução tem algumas limitações, a primeira das quais é a extensão dos dados a passar. Além disso, se o utilizador marcar essa página (bookmark ou favorite, quando regressar ao sítio regressará à configuração usada na sessão anterior. No caso de um jogo, por exemplo, isso seria um inconveniente.
   Uso esta solução no meu álbum de fotografias Bienvenue em Belgique para transmitir o nome da página ao frameset e forçar o carregamento de mesmo: se o utilizador aceder ao sítio sem frames, então regressa à página de entrada onde se carrega o frameset que surge imediatamente na secção pretendida.

Além destas quatro soluções, é possível guardar informações no frameset. Estas aplicações dirigem-se aos dados a guardar dentro de uma sessão, tal como se passa informação no URL. Não fica guardado no disco, não obriga a ligações extra ao servidor e não exige um servidor especial ou uma tecnologia activa.

Como funciona? Em cada frame, as variáveis da própria página podem ser acedidas por document.nome_da_variavel.value. Do mesmo modo as variáveis da frame superior (que num caso simples será o frameset) serão acedidas por document.parent.nome_da_variavel.value. Também é possível aceder às variáveis de outras frames fazendo document.parent.nome_da_frame.nome_da_variavel.value. Deste modo é possível comunicar entre frames e passar informação entre páginas sem que o utilizador seja perturbado.

Usei esta opção na versão de 1999 do sítio do Laboratório de Robótica Móvel. O utilizador entra no sítio por um frameset, com barra de navegação à esquerda. Nesta barra, o utilizador pode escolher entre os três idiomas disponíveis: Português, Inglês e Francês. As páginas principais estão nos três idiomas mas como o sítio é mantido por diversas pessoas, nem todas as páginas estão repetidas nos três idiomas. Aliás, a página das publicações que é a página mais importante e uma das mais citadas e visitadas é única com navegação trilingue.

Quando um utilizador acede a uma página que existe no seu idioma por omissão, recebe a página nesse idioma. Se não existir essa versão, recebe a página num idioma mais genérico (normalmente o inglês). Se continuar a navegar pelas páginas num idioma estranho mas chegar a uma página que existe no seu idioma de omissão, então o browser reencaminha-o automaticamente para essa versão.

Além desta utilização um pouco elaborada, esta técnica serve para guardar variáveis secretas de jogos, resultados e outras informações que não desejamos que sejam "arranjadas" pelo utilizador. Servem também para guardar as preferências dos utilizadores e escolha anteriores (por exemplo ler um artigo completo ou apenas o resumo, a distância percorrida num percurso com várias etapas, etc.).

São aplicações simples mas que expandem a capacidade do HTML ao tornar possível a comunicação transparente e imediata entre páginas diferentes.

4. Hierarquização da informação

A utilização hierárquica de frames é uma ideia conceptual que nunca vi implementada a fundo num sítio "a sério". Trata-se do seguinte: ao contrário de um jornal ou uma televisão em que a extensão do espaço de visualização é conhecida a priori, numa página web, o espaço varia muito entre utilizadores. Além do mais, é razoável postular que os utilizadores com maiores espaços de visualização dispõem de maior largura de banda (os computadores maiores estão nas mesas, ligados a redes locais ou a cable modems enquanto os pequenos portáteis, telemóveis e handhelds dependem de uma ligação mais lenta ou mais cara.

Baseado neste princípio, é possível criar páginas em que a primeira frame seja vista por todos, a segunda seja vista na maioria dos terminais e as seguintes seráo vistas apenas naqueles que têm espaço (e largura de banda) para isso. No caso da homepage de um jornal electrónico, a primeira frame conteria os cabeçalhos das notícias, a segunda os leads e os primeiros parágrafos do corpo e a terceira conteria fotografias, ilustrações, secções de valor acrescentado, etc..

Para reduzir o esforço de download, usar-se-ia JavaScript para medir o tamanho da janela e a classe de cada utilizador seria guardada no frameset. A cada novo link, bastaria consultar este valor para saber quanta informação se deve descarregar do servidor e onde se deve apresentá-la.

Testei com sucesso uma versão incipiente deste princípio nas minhas páginas de 2000: nas páginas de Portugal e de fotografia, a frame do lado direito está vazia para resoluções inferiores a 1024x768. Para resoluções superiores, estas páginas oferecem um "extra": um poema de António Gedeão e uma fotografia do Elevador de Santa Justa em Lisboa, respectivamente. Se puder, experimente aceder a esssas páginas, primeiro com uma janela pequena e depois maximizando o tamanho da janela.

Conclusões

As frames foram uma promessa que nunca se cumpriu. Não por causa das suas limitações e inconvenientes que com o tempo foram minimizados, mas porque deixaram de ser necessárias à maioria das aplicações quando se generalizaram os sítios activos em que as páginas são criadas por medida.

Hoje são algo de marginal na cultura da Web e por isso são olhadas com desconfiança. Todavia, mantém o seu interesse em aplicações específicas e podem mesmo ser a solução com melhor relação custo/benefício. Infelizmente, a massificação das ferramentas e das equipas de produção de sítios leva a que as soluções óptimas criadas por medida sejam substituídas por soluções genéricas adaptadas à pressa e que se revelam por vezes mais caras, mas que têm a vantagem de ser exactamente iguais às que foram feitas antes e às que serão feitas depois. E é sabido que a novidade e a criatividade acarretam custos, mas também oferecem novos horizontes.

Dezembro 2001 a Junho de 2002.

Referências