» direct naar zoek en menu

Tijdschrift voor webwerkers » Artikel #71

Gebruiksvriendelijke frames - Pleidooi voor vrijspraak

Ervaren webdesigners zijn tegen frames. Zoek op internet naar de voordelen van frames en je vindt enkel webpagina’s over de nadelen van frames. Jakob Nielsen kan het af met vier woorden: “Frames: just say no”. Frames zijn namelijk niet gebruiksvriendelijk.

Hoe komt het dan, dat klanten mij regelmatig expliciet vragen om frames te gebruiken? Zij willen het hoofdmenu van hun site op een vaste plek op het scherm. Begrijpelijk: zou jij er vrolijk van worden als in tekstverwerkers het menu uit beeld verdwijnt als je door het document bladert? Of dat de knoppen van je GSM niet meer te zien zijn na een lang telefoongesprek?

Vast menu

Een onderzoek van Bernard & Hull bevestigt deze voorkeur voor een vast menu. In onderstaande situatie verkozen achttien van de twintig respondenten de variant met frames.

Een website met het menu naast de tekst Een website met het menu in een apart frame

Een tweede voordeel van frames is dat de browser vaste paginaonderdelen maar een keer hoeft te downloaden en tonen. De bezoeker hoeft minder lang te wachten, wat zijn beleving natuurlijk ten goede komt.

Toch kleven er aan frames ook nadelen met betrekking tot toegankelijkheid, concept en presentatie. Voor elk bruikbaarheidsprobleem is er echter wel een oplossing. Laten we die eens gaan bekijken.

Voor de bouwer van een site hebben frames ook hun voor- en nadelen. Deze laat ik hier buiten beschouwing.

Nadelen voor de toegankelijkheid

Nadeel 1a. Er zijn browsers die geen frames ondersteunen. Denk aan braille- of spraakinterfaces, maar ook aan grafische browsers in handhelds.

Nadeel 1b. Zoekmachines kunnen websites met frames niet indexeren.

Al sinds de introductie van frames is er een oplossing voor deze twee problemen. In elke frameset definitie hoort een <noframes>-sectie te staan. Robots en browsers die geen frames ondersteunen zullen de inhoud van deze sectie laten ‘zien’. Aan de melding “Your browser does not support frames” hebben zowel gebruikers als zoekmachines geen boodschap. Het is veel effectiever als de <noframes>-sectie het navigatiemenu en alle informatie van de initiële pagina bevat.

Html schrijft daarnaast voor dat in het title-attribuut van het frame een betekenisvolle omschrijving gegeven moet worden, vanzelfsprekend in voor de bezoeker begrijpelijke taal. Er schijnen ook browsers te zijn die niet de title, maar de name weergeven. Het is een kleine moeite om de frames ook een informatieve naam te geven, dus liever ‘navigatie’ dan ‘left’.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html>
  <head>
    <title>naar voren » van kladblok tot factuur</title>
  </head>
  <frameset frameborder="0" cols="180,*">
    <frame src="menu.htm" name="navigatie" title="Het hoofdmenu" />
    <frame src="start.htm" name="inhoud" title="Artikelen over webdesign" />
    <noframes>
      <div>
        <a href="index.html">Home</a>
        <a href="artikel/">Archief</a>
      </div>
      <p>NAAR VOREN publiceert artikelen…</p>
    </noframes>
  </frameset>
</html>

Bij browsers die geen frames ondersteunen is het menu niet toegankelijk, omdat het in een apart html-document staat. Het is daarom handig om in alle pagina’s een <noframes>-sectie op te nemen met het hoofdmenu. Browsers die frames wèl ondersteunen zullen deze sectie negeren.

Voorgaande zijn nauwelijks problemen te noemen. Het is een kwestie van goede html schrijven. De echte problemen komen nu.

Frames doorbreken het paginaconcept

In het ontwerp van Tim Berners-Lee is de pagina de elementaire eenheid van informatie.

Frames doorbreken deze eenheid van informatie. Ze zijn daarin overigens niet uniek. Ook hyperlinks naar een anker binnen de pagina en veel interactieve flash-animaties passen niet in het paginaconcept. Door de volgende bijwerkingen kan de bezoeker op het verkeerde been gezet worden.

Nadeel 2a. In sommige browsers werken bookmarks niet volgens verwachting: de frameset met de initiële pagina’s wordt als bookmark opgeslagen, niet de pagina die de gebruiker op dat moment ziet.

Nadeel 2b. Als de bezoeker via een zoekmachine op een losse pagina belandt, die normaal in een frameset hoort, dan ontbreekt de navigatie.

Nadeel 2c. Het internetadres (de url) in de adresbalk verandert niet als de bezoeker naar andere pagina’s surft. Hij kan er daarom ook niet naar refereren. Om naar dezelfde informatie terug te keren moet iemand eerst naar de homepage en vervolgens weer een aantal hyperlinks volgen.

Al deze nadelen zijn met een simpel scriptje en een extra html-code in de <head>-sectie te omzeilen. Bovenstaande lap html (de frameset-pagina) wordt daarmee overbodig.
In de eerste regel van het script wordt getest of de pagina onderdeel is van een frameset. Zo niet, dan schrijft het script de frameset-definitie.

<script type="text/javascript">
if(parent.frames.length == 0){
document.write('<frameset frameborder="0" cols="180,*">'
+ '<frame src="menu.htm" name="navigatie" />'
+ '<frame src="' + window.location +'?" name="inhoud" />'
+ '</frameset>');
}
</script>

Het is praktisch om het script in een extern bestand te zetten, zodat het op een centrale plek te onderhouden is.
<script type="text/javascript" src="includes/frameset.js"></script>

Om er voor te zorgen dat de url overeenkomt met de pagina die de browser toont, moet een gelinkte pagina niet in een frame, maar in het hele venster geladen worden. Je bereikt dit met de volgende regel in de <head>-sectie.
<base target="_top" />
Het scriptje zorgt er weer voor dat ook het navigatieframe getoond wordt.

Ter illustratie van voorgaande oplossing heb ik een Quick Reference omgebouwd. Browsers die geen frames of geen JavaScript ondersteunen negeren het script en tonen gewoon de inhoud van de pagina. Met de browser Opera kun je de werking goed bekijken door de ondersteuning voor frames en/of JavaScript uit te zetten.

De demo in een browser die frames ondersteunt
Dezelfde demo als frames niet ondersteund worden

Nadeel 3. Bij afdrukken is het niet eenduidig welk frame op papier zal verschijnen.

De gangbare browsers drukken standaard het actieve frame af. Het is voor een surfer lang niet altijd duidelijk wat het actieve frame is. Hoewel het afdrukken meestal goed gaat, kan ik je geen sluitende oplossing geven. Wel nog een tip voor als je een knop ‘Afdrukken’ in het navigatieframe wil zetten. Met de volgende code zorg je er voor dat het inhoudframe de focus krijgt en naar de printer gestuurd wordt:
onclick="parent.frames.inhoud.focus(); window.print();"

Problemen met de presentatie

Nadeel 4. Een lay-out met frames is niet flexibel genoeg voor kleine schermen.

Deze klacht slaat eigenlijk niet op frames maar op starre designs. Door de breedte en hoogte van frames in percentages op te geven kan de lay-out zich aanpassen aan de schermresolutie. Met frames heb je zelfs meer mogelijkheden dan met een tabel: je kan absolute en relatieve afmetingen combineren. Onderstaande voorbeeld resulteert in drie kolommen. De middelste heeft een breedte van 400 pixels (wat gemiddeld een prettige breedte is voor een tekstkolom). De resterende ruimte wordt over de eerste en derde kolom verdeeld in de verhouding 1:3, ofwel 25%:75%.
<frameset cols="1*,400,3*">...</frameset>

Nadeel 5. Bij gebruik van frames kan meer dan één schuifbalk verschijnen.

Meer dan één schuifbalk is onhandig in het gebruik en verspilt schermruimte. Het heeft mijn voorkeur om de schuifbalk in het navigatieframe uit te zetten.
<frame src="menu.htm" name="navigatie" scrolling="no" />

Op kleine schermen kan een deel van de tekst nu onbereikbaar zijn. Met een slim ontwerp kun je de schade beperken. Ontwerpen is per definitie het oplossen van tegenstrijdige eisen; frames veranderen daar niets aan.

Zijn frames standards compliant?

Frames zijn onderdeel van HTML 4.01 en XHTML 1.0. In de voorstellen die er liggen voor XHTML 2 maken frames geen deel uit van de basismodule. Er wordt daarnaast echter gewerkt aan een speciale module voor frames, XFrames genaamd. Het XFrames-voorstel beoogt het paginaconcept te herstellen door alle delen van een frameset in de url te verwerken. Een voorbeeld zou kunnen zijn:
http://example.org/index.html#frames(navi=navigatie.html,content=home.html)

XFrames zitten nog in het Working Draft stadium. Het zal nog jaren duren voordat de gemiddelde internetter een browser gebruikt die XFrames ondersteunt.

CSS als alternatief

Frames definiëren de presentatie; een rol die tegenwoordig aan stylesheets (CSS) toebehoort. Theoretisch kan het fixeren van een menu ook met CSS. Je kan het menu op een vaste positie in het browservenster zetten met de stijldeclaratie position: fixed.

Helaas, helaas. Geen enkele Windowsversie van Internet Explorer ondersteunt de waarde fixed. Vanwege het overheersende marktaandeel van deze browser is position: fixed in de praktijk geen alternatief.

In een demo heb ik een oplossing voor Internet Explorer uitgewerkt. Ik plaats alle content in een div met als stijldeclaratie:
height: 100%; width: 100%; overflow: auto;
De content scrollt nu binnen deze rechthoek die als viewport fungeert. In een tweede div, die absoluut gepositioneerd is, staat het menu. Dit menu maakt geen deel uit van de eerste div en zal niet met de content meescrollen.

Schermafdruk van www.coornhertstraat.nl

Deze oplossing heeft weer rare bijwerkingen in Netscape en Opera. Eric Bednarz combineert beide werelden met behulp van een aantal css-hacks tot een goedwerkende oplossing. Toch houd ik frames nog even in mijn gereedschapskistje, gezien de bezwaren van dit soort hacks.

Dus...

Frames zijn het overwegen waard, als je uit oogpunt van gebruiksvriendelijkheid het menu op een vaste plek in de browser wil hebben. De slechte naam die frames met zich meedragen, lijkt me niet terecht als je met een beetje vakmanschap en eventueel vijf regels script alle problemen kan oplossen. Lees voor gebruik de bijsluiter, dat komt de gebruiksvriendelijkheid méér tegemoet dan Jakob Nielsen’s credo “just say no”.

Auteur

Yohan Creemers

is oprichter van ontwerpbureau Ylab.

In de visie van Ylab moeten nieuwe media gebruiksvriendelijk, creatief en helder zijn.

Met dank aan Ivo Weevers en Peter-Paul Koch

Publicatiedatum: 10 december 2003

Let op

Naar Voren is op 18 juli 2010 gestopt met publiceren. De artikelen staan als een soort archief online. Het kan dus zijn dat de informatie verouderd is en dat er inmiddels veel betere of makkelijkere manieren zijn om je doel te bereiken.

Copyright © 2002-2022 » NAAR VOREN en de auteurs