Frontaal.net

Zes tips voor gebruiksvriendelijke links

2009-05-05T06:24:52Z

Zonder links zou internet niet bestaan. Links zijn essentieel voor je website. Maar ook voor zoekmachines. En zeker voor bezoekers. En dan niet alleen links naar de website toe, maar ook links op de site zelf. Toch wordt er in de praktijk relatief weinig aandacht besteed aan de gebruiksvriendelijkheid en toegankelijkheid van links, terwijl een simpele verbetering soms een boost voor je site kan betekenen.

De tips in het kort:

Maak van elke link een echte link
Geef een link een beschrijvende tekst
Zorg dat duidelijk is wat een link is (en wat niet)
Maak onderscheid in onbezochte en bezochte links
Open links niet in een nieuw venster
Gebruik iconen om links te verhelderen

1. Maak van elke link een echte link

Wanneer je links hebt waar bezoekers javascript voor nodig hebben om erop te kunnen klikken, dan heb je onechte links. Meestal staat er iets dergelijks in als:

<a href="javascript:newwindow()">link</a>
<a href="#" onclick="javascript:popUp('http://www.example.com')">link</a>

Die link leidt nergens naartoe wanneer javascript uitstaat. Nou hebben de meeste mensen wel javascript aan, maar zoekmachines niet. Daarom kunnen veel sites met javascriptmenu’s een hoge score in zoekmachines bij voorbaat al vergeten; er valt voor een zoekmachine weinig te indexeren. Daarnaast blijven er altijd mensen die bijvoorbeeld vanwege bedrijfsveiligheid javascript niet aan hebben staan (ongeveer 5%). En zelfs voor je webstatistiekenpakket kan het een probleem zijn. Kortom, zorg dat elke link ook zonder javascript ergens naartoe leidt. (Alternatieve menu’s bouw je met CSS, zoals wordt uitgelegd in het Listutorial. Gevorderde alternatieven zijn de o.a. de Son of Suckerfish dropdowns of de UDM4.)

2. Geef een link een beschrijvende tekst

Uit onderzoek blijkt dat veel bezoekers pagina’s niet lezen, maar door de pagina scannen naar informatie. Bezoekers letten op kopjes, dikgedrukte woorden, lijsten/opsommingen, maar ook op links. Immers, links zijn veelal bedoeld om aan te geven dat je naar meer informatie kun navigeren.

Tot voor kort was één van de meestvoorkomende linkteksten: “klik hier”. Wanneer je weet dat mensen de pagina niet lezen, maar scannen naar woorden en zinsdelen die aangeven dat er bepaalde informatie volgt, dan wordt duidelijk dat ‘klik hier’ de bezoeker weinig zegt. Men moet dan alsnog de context lezen om te begrijpen waar de link naartoe leidt. Bovendien is de ‘klik hier’-zin tekstueel gezien veelal overbodig; het is vaak voldoende om een woord of zinsdeel uit de voorgaande zin te linken.

In bovenstaande afbeelding had men makkelijk kunnen volstaan door alles te verwijderen behalve de kopjes en vervolgens een link te maken van ‘Lenen via internet’ en ‘Muziek lenen’. Niet alleen is meteen duidelijk wat het onderwerp van de link is, de extra regels ‘klik hier voor meer informatie’ zijn ook nog duidelijk overbodig.

3. Zorg dat duidelijk is wat een link is (en wat niet)

Links zijn vaak onderstreept. Maar op sommige sites wordt daarnaast onderstreping gebruikt om tekstkopjes te maken, of om een bepaald tekstdeel nadruk te geven. Bij teksten op papier is onderstreping daar erg geschikt voor, maar op internet valt zo moeilijker te onderscheiden wat een link is en wat niet.

Voorbeeld:
Dit is onderstreepte tekst en dit is een link naar de homepage.

Onderstreep dus nooit in internetteksten, tenzij het een link is. Het W3C heeft niet voor niks het underline-element afgekeurd, zoals ook valt te lezen in mijn artikel over achterhaalde elementen.

Hoewel links dus vaak onderstreept zijn, kiezen sommige sites ervoor de onderstreping van links juist weg te halen. Dat maakt links moeilijker te herkennen. In dat geval is het belangrijk dat je links op andere manieren goed zichtbaar maakt, bijvoorbeeld door ze zowel een andere kleur mee te geven, als door ze dikgedrukt te maken. Let er dan wel goed op dat die links niet lijken op andere elementen in de tekst die geen links zijn.

4. Maak onderscheid in onbezochte en bezochte links

Zeker wanneer je een grote website hebt, is het handig als bezoekers ziet welke pagina’s ze al wel hebben bezocht en welke nog niet. Hoe frustrerend is het als je op een site naar informatie zoekt en je meerdere malen op dezelfde pagina terecht komt, terwijl je daar al bent geweest? Voorkom zulke ergernissen op je eigen site en geef bezochte links een ander kleurtje mee. Hiervoor gebruik je de link-pseudo-classes a:link en a:visited.

Je kunt je pagina nóg gebruiksvriendelijker maken door links op te lichten wanneer je muis er overheen gaat (a:hover), door links op te lichten als je met de tabknop erop staat (a:focus) en door links op te lichten wanneer je erop klikt (a:active). Tip: let in je CSS op de volgorde van de link-states.

5. Open links niet in een nieuw venster

Sites openen links in een nieuw venster meestal om twee redenen:

Om te voorkomen dat mensen je site verlaten.
Om de huidige pagina te houden, maar tegelijkertijd een aanvulling te tonen, zoals een extra uitleg, een vergroting van een foto, of een invulscherm.

Met name het eerste punt is een veelgehoorde reden om een nieuw venster te laten openen. En inderdaad zijn er veel mensen die een nieuw scherm op prijs stellen. Het blijkt echter dat er net zoveel mensen zijn die helemaal geen nieuw venster willen openen, of op z’n minst zelf de keus daarover willen hebben. Dus hoewel je de helft helpt, val je de andere helft er mee lastig. Mensen zelf laten kiezen voor een nieuw scherm is dan de beste optie. Bovendien is het maar de vraag of je mensen kwijt bent zodra je de link in hetzelfde venster opent. Raakt Google mensen kwijt doordat geen enkele link in een nieuw scherm wordt geopend?

Voor het tweede punt, het tonen van aanvullende info over de betreffende pagina, heeft men tegenwoordig methodes bedacht die als alternatief kunnen dienen voor het openen van een nieuw scherm. De informatie die je in het nieuwe scherm zou zetten, kun je bijvoorbeeld ook verwerken in je huidige pagina; je verbergt het met CSS en toont het slechts wanneer men erom vraagt. Een ander alternatief is om de ‘popup-pagina’ te openen binnen hetzelfde scherm met behulp van scripts zoals Lightbox2 of Thickbox. Is een nieuw scherm toch nodig, zorg dan in ieder geval dat de popuplink leidt naar een echte pagina (zie punt 1).

6. Gebruik iconen om links te verhelderen

Soms werkt het verhelderend om in één oogopslag te zien wat een link doet of waar het naartoe leidt. Op dit blog bijvoorbeeld gebruik ik een icoon om aan te geven dat een link naar een externe website leidt. Ik gebruik daarvoor attribuut-selectors.

Meer leesvoer

Webrichtlijnen: Links en navigatie
Usarchy: Nooit meer “Klik hier” en “Lees verder”
Usarchy: Usability mythe #2: open externe links in nieuw venster
UseIt: Top Ten Mistakes in Web Design
Dev.Opera: Accessible Context-sensitive Help with Unobtrusive DOM Scripting

Aanmelden bij zoekmachines is onzin

2008-12-11T20:34:16Z

Er zijn meerdere redenen waarom je geen tijd en zeker geen geld moet uitgeven aan het aanmelden bij zoekmachines. Aangezien Google in Nederland een marktaandeel van ruim 90% heeft (via: Edwords), zal bijna iedere Nederlander die zoekt, Google gebruiken. Hoogstens gebruikt men per ongeluk of uit nieuwsgierigheid een keertje MSN Live Search, Ilse, Vinden.nl of Yahoo!. Zodra iemand naar je linkt, vindt een zoekmachine je toch wel. Het is dan ook niet nodig om je site aan te melden bij zoekmachines, maakt linkbuilding-expert Wiep nog eens duidelijk in het artikel “Aanmelden bij zoekmachines? Geldklopperij!“.

Het artikel is geschreven naar aanleiding van websites die geld vragen om je aan te melden bij talloze zoekmachines. Aangezien niemand die zoekmachines gebruikt, heeft het natuurlijk totaal geen nut om je daar aan te melden, laat staan om er voor te betalen.

Het is overigens al jaren bekend dat aanmelden bij talloze zoekmachines een mythe is (artikel uit 2003), maar men trapt er nog steeds in. Zo’n aanmeldsite kan bijvoorbeeld een truc zijn om e-mailadressen te verzamelen. Je vindt de mythe dan ook vaak terug in top 10-lijstjes. Zelfs überzoekmachine Google geeft in haar Helpcentrum aan dat aanmelden bij allerlei zoekmachines nutteloos is.

Kortom, gevonden worden gaat vanzelf en gebeurt kosteloos; betaal in geen enkel geval om je aan te melden bij zoekmachines.

Frontaal.net vernieuwd: versie 2.0

2012-05-23T13:58:21Z

Onlangs heb ik dit blog voorzien van een verbeterde layout. De oude layout was eigenlijk een experiment met een donkere achtergrond, juist omdat websites met een donkere achtergrond weinig voorkomen. Het experiment vond ik slechts deels geslaagd; ik vond de layout niet leesbaar genoeg en en er moest meer aansluiting bij de rest van het internet komen. Dus om in de tijdgeest te blijven en met de woorden van Obama te spreken, het was tijd voor ‘change‘: Frontaal.net versie 2.0.

Oud versus nieuw in beeld
Leesbaarheid
Connecting people
Technische aspecten
Feedback?

Oud versus nieuw in beeld

Frontaal.net layout 2006
Frontaal.net layout 2009

Leesbaarheid

De grootste verandering is dat de kleurstelling is veranderd van een donkere achtergrond naar een lichte achtergrond. Dat maakte voor de leesbaarheid van de artikelteksten weinig uit, maar het was erg moeilijk om alle onderdelen van de website zo leesbaar te houden, zoals de codevoorbeelden (het zou betekenen dat ik het kleurgebruik in de code-highlighting compleet moet veranderen).
Verder is er qua layout weinig veranderd wanneer je een relatief klein scherm hebt, de opbouw is hetzelfde gebleven. In dat geval krijg je de oude tweekolomslayout, in een nieuw jasje.
Wanneer je een schermresolutie van 900 pixels breed of meer hebt, zul je zien dat er veel meer ruimte is gekomen voor de artikelteksten. Dat maakt de artikelen overzichtelijker. Daarnaast is nu een driekolomslayout, zodat je naast de links in de artikelen ook in de zijbalk nuttige links kunt vinden.

Connecting people

Hoewel in de artikelen op deze site talloze links naar andere sites staan, kan het natuurlijk nog beter. Wat volgens mij ontbrak, was een stukje actualiteit en meer verband met gerelateerde blogs. In de zijbalken is daarom ruimte ingeruimd voor links naar de meest actuele artikelen voor front-end webdevelopers, te vinden op de betere blogs.

Het stuk ‘Meer webdevelopment’ haalt de nieuwste artikeltitels via webfeed binnen.
Wanneer in de blogosfeer of nieuwsland iets voorbij komt wat een belangrijke ontwikkeling lijkt, schrijf ik er kort over in de nieuwe rubriek ‘Marginaal’.
Tot slot vind je sindskort ook de nieuwste vacatures voor front-end webdevelopers in de zijbalk.

Aangezien dit blog zich richt op mensen die nog niet zo lang bezig zijn met onderwerpen als tabelloze layouts, CSS, toegankelijkheid, hoop ik op deze manier dat bezoekers spelenderwijs andere goede blogs ontdekken. En de gevorderde sitebouwer komt zo wellicht op ideeën voor een carrièrestap.

Technische aspecten

Ik heb ervoor gekozen het grootste deel van de HTML en een stuk van mijn CSS niet zelf te schrijven, maar gebruik te maken van enkele frameworks, “een aantal standaardinstellingen (…) die voor iedere website opnieuw handig kunnen zijn” (uit: Naar Voren – CSS Frameworks).

HTML en CSS: Sandbox

Sandbox is een thema voor WordPress dat niet meer is dan kale, goed opgebouwde (semantische) XHTML en wat CSS waarmee je een één-, twee- of driekolomslayout kunt produceren. Hoewel het wat overbodige elementen en classes bevat, vond ik het van doorslaggevender betekenis dat het thema is voorbereid op diverse ingebouwde mogelijkheden van WordPress. En van de XHTML maak ik server-side gewoon HTML.
Meer CSS: Blueprint

De zelfgeschreven CSS bevat een gedeelte dat afkomstig is van het Blueprint CSS-framework. Blueprint bestaat uit HTML- en CSS-templates bedoeld om snel een website op te zetten volgens het grid-principe: mooie layouts zijn altijd gebaseerd op een evenwichtige vlakverdeling in rijen en kolommen. Voor deze layout heb ik eigenlijk slechts de CSS-reset en de typografie gebruikt. Het grid-principe heb ik zonder het framework toegepast, om layoutgebaseerde classes in mijn template te voorkomen.

Feedback?

Bij de wijzigingen ben ik louter uitgegaan van wat ik zelf gebrekkig vond. Als je als bezoeker iets geweldig onhandig vindt, of vindt dat er misschien iets ontbreekt dat geweldig handig zou zijn, hoor ik graag van je via een reactie of een mailtje. Alvast bedankt!

Google publiceert handleiding zoekmachineoptimalisatie voor beginners

2009-09-29T23:08:26Z

Iedereen die een website heeft of eraan werkt, vraagt zich wel eens af hoe de site nog beter vindbaar kan worden in zoekmachines. Hoewel bij Google al heel wat informatie over het verbeteren van je website is te vinden, hebben ze nu ook een downloadbare SEO-beginnershandleiding gepubliceerd. In de 22 pagina’s tellende pdf lees je over de beginselen van het verbeteren van titels, metatags, URL’s, navigatie, content, links, afbeeldingen en hoe Google je daarbij kan helpen. Overigens kun je een deel van de tips ook terugvinden in mijn artikel over metatags.

Update 30 september 2009: de Google SEO-handleiding voor beginners is er nu ook in de officiële Nederlandse vertaling.

De zin en onzin van metatags

2009-10-12T12:04:10Z

Om maar met de deur in huis te vallen: veruit de meeste metatags zijn onzin. Het is veel nuttiger om je tijd te steken in metadata die wel belangrijk zijn; vergeet de rest van de metatags. Dat maakt metatag-generators ook overbodig. In dit artikel bespreek ik de meestgebruikte metadata. Daarbij geef ik aan welke daarvan wel of niet nuttig blijken. Ook geef ik alternatieven voor het gebruik van enkele bekende metatags.

Inhoud

Hoe het komt dat veel metatags onzin zijn
Welke metadata zijn wel nuttig?
Overige, veelgebruikte metadata
Samenvattend
Meer leesvoer

Hoe het komt dat veel metatags onzin zijn

Veel metatags stammen nog uit de jaren ’90 van de vorige eeuw, toen er veel zoekmachines werden opgezet en elke zoekmachine haar eigen metatags bedacht. Daardoor ontstond er een wildgroei aan metatags. Omdat veel metatags slechts nuttig waren voor één zoekmachine (de andere zoekmachines negeerden die informatie gewoon) en bovendien de meeste zoekmachines uit die tijd inmiddels al jaren niet meer in gebruik zijn, hebben veel metatags hun nut verloren (of simpelweg nooit gehad).

Daarnaast gebruikten veel sitebouwers de meeste metatags niet, of gingen ze er verkeerd mee om. Een bekend voorbeeld van dat laatste is het keywords-attribuut, dat jarenlang werd gebruikt om de meest onzinnige keywords te verbinden aan een webpagina, om maar bezoekers binnen te halen. Veruit de meeste zoekmachines negeren daarom al jaren het keywords-attribuut (~~alleen voor Yahoo! dient het nog een kleine functie~~ ook Yahoo negeert nu meta keywords).

Welke metadata zijn wel nuttig?

Aangezien de meeste metadata niet nuttig zijn, kan ik beter een lijstje maken met metadata die wel nuttig zijn, met een korte uitleg van het gebruik ervan.

Title

De titel van de pagina beschrijft in één kernachtige zin de inhoud van de pagina, ongeveer zoals de kop van een krantenartikel. Voorbeeld:

<title>De zin en onzin van metatags</title>

De title is geen zogenaamde ‘metatag’, maar is wel een uiterst belangrijk element in de head van je document, belangrijk voor bezoekers en zoekmachines (zie figuur 1). Gebruik voor elke pagina een unieke title (immers, als het goed is, is elke pagina uniek). Zorg dat de titel helder is en slaat op de paginatekst. En natuurlijk is belangrijk dat de tekst bezoekers binnenhaalt (door in te spelen op de informatiebehoefte). Is de titel vaag of nietszeggend, dan is de kans groot dat men liever een andere site bezoekt. Beperk de lengte van de title liefst tot 65 tekens. Gebruik geen decoratieve tekens in de title; die 65 tekens kun je beter gebruiken om bezoekers te informeren over de pagina.

Figuur 1: Wat voor site zou dit zijn? Een hippe clubavond? Een site over etiquette? Een kledingwinkel?

Description

De description geeft een korte samenvatting van de pagina. Voorbeeld:

<meta name="description" content="Welke metatags zijn nou nuttig en welke niet? Een artikel over de meestgebruikte, onnuttige metadata en de belangrijkste metatags die essentieel zijn.">

De tekst in deze ‘meta-description-tag’ is dezelfde tekst die zoekmachinegebruikers zien in het zoekresultatenscherm als de omschrijving van de gevonden pagina’s (zie figuur 2). De description behoort daarom geen opsomming van losse trefwoorden te bevatten en ook geen omschrijving die slaat op de gehele site, maar een bondige samenvatting of inleiding van de inhoud van de betreffende pagina. Ook hier geldt: is de omschrijving vaag of nietszeggend, dan is de kans groot dat men liever een andere site bezoekt. Ook de description is zeer belangrijk, met name voor bezoekers via zoekmachines. Aanbevolen lengte van een description is doorgaans één of twee zinnen.

Figuur 2: Zouden zowel de title en de description uniek zijn, dan kon je veel sneller zien waar de link naartoe leidt.

Robots

Met de ‘meta-robots-tag’ geef je aan of een pagina geïndexeerd (index/noindex) en/of de links erin gevolgd moet worden (follow/nofollow). Voorbeeld:

<meta name="robots" content="noindex, follow">

Standaard neemt een zoekmachine aan dat elke webpagina op ‘index, follow‘ staat ingesteld (dat hoef je dus niet extra aan te geven), tenzij expliciet aangegeven dat het niet geïndexeerd of gevolgd moet worden. Het gebruik van de meta-Robots-tag is essentieel wanneer de pagina gevoelige en/of persoonlijke gegevens bevat. Ook kun je hiermee aangeven of een kopie van de pagina in de cache van een zoekmachine mag belanden (content="noarchive"). Een relatief nieuwe functie van de meta-robots-tag is dat je kunt aangeven of Google de omschrijving van je site moet weergeven zoals die bij DMOZ bekend is, of dat jouw eigen description wordt gebruikt (content="noodp").

Figuur 3: Wanneer je website in DMOZ staat vermeld, krijgt je site de omschrijving die bij DMOZ bekend staat, tenzij je een eigen meta-description schrijft en de noodp-waarde gebruikt.

Overige, veelgebruikte metadata

Content-type

Met content-type wordt o.a. aangegeven welke karaktercodering gebruikt wordt (bijvoorbeeld ISO-8859-1). Voorbeeld:

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">

Voor Netscape 4.7x en ouder was het belangrijk dat content-type de eerste regel in je head was. Aangezien die browser niet meer wordt gebruikt, is de plek van content-type niet meer van belang. Sterker nog, het is beter om het content-type via de server te regelen. In dat geval kun je die metatag helemaal uit je pagina verwijderen. Of je het nou via de server regelt of via je pagina, zorg in ieder geval dat je de UTF-8-karakterset gebruikt. Lees meer daarover in Anne van Kesterens artikel over UTF-8. Een kleine waarschuwing vooraf: let er bij bestaande websites wel op dat dit veel meer inhoudt dan ‘even’ ISO-8859-1 veranderen in UTF-8; je moet namelijk ook vreemde tekens in bestaande pagina’s handmatig omzetten en/of je database converteren…

Pragma en expires

Deze gebruikt men vaak om aan te geven dat een pagina niet door browsers gecached moet worden. Voorbeeld:

<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="expires" content="Thu, 26 Feb 1998 01:00:00 GMT">

Net als content-type kun je ook dit beter via de server regelen.

Revisit-after

Deze wordt gebruikt om aan te geven hoe vaak een zoekmachine langs moet komen. Voorbeeld:

<meta name="revisit-after" content="7 days">

In de praktijk is revisit-after compleet nutteloos, want zoekmachines bepalen helemaal zelf wanneer ze langskomen; ze negeren deze metadata. Wil je toch enige invloed hierop uitoefenen, dan is het gebruik van een XML-sitemap nauwelijks een beter idee, want ook hier geldt dat zoekmachines uiteindelijk zelf bepalen hoe vaak ze langskomen.

Copyright

Hiermee geef je aan wanneer de pagina is gemaakt en bij wie het auteursrecht ligt. Voorbeeld:

<meta name="author" content="roger">

Het is mij na enige research niet duidelijk of deze metatag nut heeft. Zorg in ieder geval dat je de copyright aanduidt in de paginatekst (bijvoorbeeld ‘© 2007 Frontaal.net’ in de footer) en/of gebruik een logo van Creative Commons (tenzij dat niet belangrijk voor je is).

Refresh

Dit is een veelgebruikt trucje om bezoekers door te sturen naar een andere pagina. Voorbeeld:

<meta http-equiv="refresh" content="10; url=http://frontaal.net">

Niet alleen is het onvriendelijk voor sommige bezoekers (niet iedereen heeft even snel door dat ze worden doorgestuurd), door het vele misbruik ervan stellen zoekmachines het ook niet op prijs. Beter is om ook dit via de server te regelen (verplaatste pagina’s verwijzen met een status 301-errorcode, verwijderde pagina’s met een 410-errorcode).

Figuur 4: Vaak word je al doorgestuurd voordat je de tekst hebt kunnen lezen, zoals bij dit screenshot het geval was. (Screenshot alsnog genomen door meta-redirects uit te schakelen.)

Samenvattend

De enige metadata die belangrijk zijn voor je webpagina, zijn description en robots. Daarnaast is de title erg belangrijk.
Het aangeven van de karakterencodering, preventie van het gebruik van de browsercache en aangeven van verwijderde of verplaatste pagina’s regel je het beste via de server.
De rest van de metadata kun je gewoon weglaten: zonde van je tijd.

Het beste is om te zorgen dat elke pagina een passende en unieke titel en omschrijving krijgt. Alleen daarmee help je bezoekers en zoekmachines.

Welke metadata vind jij wel of niet nuttig en waarom?

Meer leesvoer

Het meta-element
Web authoring statistics: metadata (onderzoek van Google naar het gebruik van metadata)
De meta-description: onderschatte factor in SEO
Beginner’s Guide – Critical Components of Optimizing a Site

Update 28 januari 2008: suggesties van Ramon toegevoegd
Update 12 oktober 2009: tekst aangepast, Yahoo negeert nu ook de meta-keywords, net als Google.

Check je website met handige tools

2010-07-25T23:34:07Z

Voor een website is het belangrijk dat hij goed werkt voor zoveel mogelijk mensen: elke bezoeker telt. Natuurlijk gebruiken de meeste mensen Internet Explorer (IE), maar als je site alleen werkt in IE, dan loop je (meer dan) 15% van je bezoekers mis. Check je website daarom in verschillende browsers en zorg ook dat hij toegankelijk is voor mensen met alternatieve manieren van internetsurfen, door toegankelijkheidstoetsen te gebruiken. Er zijn online gelukkig veel gratis tools voor te vinden.

Inhoud

Check je code
Check in verschillende browsers
Check je site op toegankelijkheid
Check op laadtijd
Check je site m.b.v. browsertoolbars of -extensies
Tot slot

Check je code

Fouten in je (X)HTML en CSS kunnen er voor zorgen dat je site er niet uitziet zoals je had bedoeld. Gebruik daarom een correct doctype en haal je code door een codechecker.

(X)HTML check je in de W3C-markupvalidator
CSS check je in de W3C-CSS-validator

Overigens betekent gevalideerde (X)HTML-code niet per definitie dat je kwalitatief goede code hebt; het betekent slechts dat je pagina aan bepaalde voorwaarden voldoet.

Check in verschillende browsers

De ene browser is de andere niet. Met name IE5.x en IE6 bevatten gigantisch veel CSS-bugs, waardoor het misleidend kan zijn wat je in die browsers te zien krijgt. Als je een site in een moderne browser als Safari, Opera of Firefox bekijkt, dan krijg je een realistischer beeld van je site. Het is dan ook aan te raden om altijd eerst te testen in deze browsers voordat je het test in IE. Bugs in IE kun je altijd nog achteraf aanpakken. Vergeet niet in meerdere versies van IE te testen.

Download Opera
Download Safari (ook voor Windows)
Download Firefox
Download Google Chrome
Download verschillende versies van IE
Download een officiële standalone IE6, IE7 of IE8
Evolt browserarchief (van Mosaic tot Flock, het is er allemaal)

En je kunt natuurlijk Linux en één van de vele browsers voor Linux installeren.

Daarnaast kun je online screenshots laten maken van je site , die gemaakt zijn door verschillende browsers:

Browsershots (diverse browsers)
Netrenderer (IE5.5 t/m IE8)
Browsrcamp (Safari)

Check je site op toegankelijkheid

Na het checken van je code en het checken in verschillende browsers kun je ook nog testen of je site toegankelijk is voor mensen die op een alternatieve manier op internet surfen. Dat hoeven overigens niet eens gehandicapten te zijn, dat kunnen ook mensen zijn die surfen zonder keyboard, mensen met een PDA of mensen met slechtere ogen (ouderen). De laatste twee groepen zullen de komende jaren alleen maar groeien, wat de toegankelijkheid alleen maar belangrijker maakt.

Webrichtlijnen quickscan
Opera Mini simulator (PDA-simulator; vereist Java)
W3C tekstbrowser-simulator

Check op laadtijd

Een laatste check is om te kijken hoe snel je site laadt. Hoewel een groot aantal mensen inmiddels een breedbandaansluiting heeft, is er duidelijk nog steeds een groot deel dat geen breedbandverbinding heeft. Daarnaast blijven internetters ongeduldig, hoe snel de verbinding ook moge zijn. Dus hoe sneller je site laadt, hoe prettiger voor de bezoeker.

Pingdom Tools: Full page test (laadtijd meten)
Web Page Analyzer (op welke punten kun je de laadtijd verkorten)
HTTP-compressiechecker (hoeveel het scheelt wanneer je compressie toepast op webpagina’s)

Check je site m.b.v. browsertoolbars of -extensies

Zoals je ziet, is het nogal veel checken. Tenminste, als je het goed wilt doen. Wanneer je werkt volgens webstandaarden, zul je merken dat het zich gelukkig veelal beperkt tot kleine wijzigingen (veelal wijzigingen voor IE). Om het checken makkelijker te maken, zijn er diverse toolbars te installeren. Zo kun je met een druk op de knop je pagina checken.

IE Developer Toolbar (toolbar voor IE6 en IE7)
Firefox Web Developer Toolbar
Firefox Firebug development tools
Site check bookmarklet (één bookmarklet, meerdere checks)

Diverse browsers hebben tegenwoordig ook handige, ingebouwde toolbars om je website te checken:

Opera 10+ bevat Opera Dragonfly, de opvolger van Opera developer tools
Safari 4+ bevat Safari web developer tools
IE8 bevat de IE developer toolbar

Tot slot

Mocht je aanvullingen, verbeteringen, suggesties, etc. hebben voor deze lijst met tools, laat het me weten! (Het is overigens niet mijn bedoeling om een zo compleet mogelijke lijst te maken, maar slechts een handige lijst.) Welke tools gebruik jij?

Aanvullende artikelen

Why we won’t help you (Engels artikel waarom codevalidatie belangrijk is)
Publiceren? Eerst valideren! (Nederlands artikel waarom validatie belangrijk is, plus extra uitleg over validatietools)
Evaluation, testing, and tools (artikelen over testen voor toegankelijkheid)

Update 19 maart 2008: Safari uit beta-fase, dus informatie aangepast.
Update 29 november 2008: nieuwe browser Google Chrome toegevoegd.
Update 25 maart 2009: info over IE8 aangevuld.
Update 4 augustus 2009: link toegevoegd met extra achtergrondinformatie over validatie.
Update 10 december 2009: ingebouwde webdevelopertools aangevuld.

Nederlandse vertaling WP Database Backup 2.1.2

2008-12-20T19:39:56Z

Voor het bouwen van websites zet ik vaak WordPress in als cms. Voor de toekomstige beheerders van die sites is het dan wel zo handig dat alle functies van het cms in begrijpelijke taal zijn. Vandaar dat ik de gebruikte uitbreidingen van WordPress (plugins) vertaal in het Nederlands.

Recentelijk heb ik de 2.1.2-versie van WordPress Database Backup vertaald. Deze is nu verkrijgbaar via de officiële website van de plugin, of via mijn nieuwe pagina voor vertalingen van WordPressplugins. Daar zul je de komende tijd nieuwe downloads aantreffen.

Doctype: welke moet ik kiezen?

2011-01-04T13:01:17Z

Een doctype behoort tot de basis van een webpagina. Hoewel een doctype essentieel is voor een voorspelbare weergave van je webpagina, wordt deze door veel mensen niet of verkeerd gebruikt. In deel 1 over doctype lees je wat je aan een doctype hebt; in deel 2 over doctype: welk doctype moet ik kiezen?

De valide `doctype`s

Als je de broncodes van websites bekijkt, zijn er talloze doctypes in de omloop. De lijst met valide doctypes is echter beperkt. Voor webpagina’s komt het in de praktijk neer op de volgende doctypes:

Drie HTML 4.01 doctypes (Transitional, Strict, Frameset).
Drie XHTML 1.0 doctypes (Transitional, Strict, Frameset).
Eén XHTML 1.1 doctype.

De afvallers

Wanneer je geen frames gebruikt, vallen er al weer twee af uit de lijst. Frames zijn namelijk niet aan te raden. Een Transitional doctype wordt gebruikt voor sites in een overgangsfase, bijvoorbeeld voor sites die een contentmanagementsysteem gebruiken dat verouderde HTML levert. Overstappen op een Strict-doctype kan in zulke gevallen ongewenste bijwerkingen in browserweergave hebben. Nieuwe sites hebben dit probleem niet. Daar zou je dan ook geen Transitional-doctype moeten gebruiken. In veruit de meeste gevallen zijn er dan ook geen goede redenen meer om een Transitional doctype te blijven kiezen. Daarmee houden we de volgende doctypes over:

Eén HTML 4.01 doctype (Strict).
Eén XHTML 1.0 doctype (Strict).
Eén XHTML 1.1 doctype.

Wil je dat bezoekers met Internet Explorer (IE) jouw pagina’s nog steeds kunnen bekijken, dan kun je ook XHTML 1.1 vergeten; IE kan niet met (correct geserveerde) XHTML 1.1-pagina’s omgaan. Dit is ook het geval bij XHTML 1.0, maar daar is incorrect serveren nog toegestaan. Dan blijven er nog twee doctypes over:

HTML 4.01:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML 1.0:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Rest de vraag: kies ik HTML of XHTML?

HTML of XHTML?

XHTML is nieuwer dan HTML en nieuwer is beter, toch? Dat valt te betwijfelen. Tussen 2003 en 2005 zijn veel websites inderdaad overgestapt op XHTML, maar daar begint men op terug te komen. Belangrijkste kritiekpunt is dat de meest gebruikte browser, IE, zelfs in versie 7 en versie 8 niet goed omgaat met XHTML. Sterker nog, als je IE XHTML voorlegt zoals XHTML bedoeld is, dan zie je een leeg scherm. Een mogelijke oplossing is om – in ieder geval voor IE – XHTML te serveren als HTML. Wanneer de server een IE-browser tegenkomt, dan geeft hij XHTML in een HTML-jasje mee; aan alle andere browsers levert hij échte XHTML. Dat kan echter ook weer problemen met zich meebrengen.

Sommigen vinden dat momenteel het serveren van XHTML geen nut heeft, aangezien 85% van de internetters met IE surft en het daarom in 85% van de gevallen niet werkt, zeker de komende jaren. Zij vinden dat je daarom beter een doctype kunt gebruiken waar alle browsers mee overweg kunnen, namelijk HTML 4.01 Strict. Anderen vinden dat je waar mogelijk XHTML zou moeten gebruiken (dus voor alle andere browsers behalve IE), bijvoorbeeld om vooruitgang op het web te voorspoedigen. Ook biedt XHTML uitbreidingsmogelijkheden; echter, voor veruit de meeste sitebouwers zullen die mogelijkheden van geen nut zijn. De keuze tussen HTML en XHTML komt dus eigenlijk neer op een persoonlijke voorkeur.

Conclusie

Van de talloze doctypes die je kunt vinden op internet, zijn er momenteel bij het bouwen van een nieuwe website meestal maar twee relevant: HTML 4.01 Strict en XHTML 1.0 Strict. Gezien de verwaarloosbare meerwaarde en het ontbreken van correcte XHTML-ondersteuning door IE ligt voor mij persoonlijk voor de hand om te kiezen voor HTML 4.01 Strict. Welke van de twee je ook kiest, het houden aan de specificaties van deze doctypes draagt bij aan de toegankelijkheid en vindbaarheid van je site en aan de overzichtelijkheid en duurzaamheid van de markup. Maar bovenal zorgt een correct doctype voor minder problemen met je layout. En wie wil er nou niet minder sitebouwproblemen?

Achterhaalde HTML-elementen, deel 1

2009-01-02T06:32:50Z

In de HTML-specificaties zijn in de loop der tijd diverse elementen afgekeurd. Door het gebruik van achterhaalde bronnen zie je tegenwoordig op internet helaas nog veel afgekeurde elementen terug. Ook hebben sommigen nog elementen in gebruik die helemaal nooit zijn goedgekeurd. Welke elementen worden afgeraden en wat zijn de alternatieven? In deel 1: afgekeurde elementen met CSS-alternatieven.

Inhoud

Gebruik CSS voor layout en (tekst)opmaak
Welke elementen zijn afgekeurd?
- Center
- Font
- U
Wordt vervolgd

Gebruik CSS voor layout en (tekst)opmaak

Een internetpagina bestaat vaak uit plaatjes, geluid of andere multimediale elementen (objecten), tekst, scripts, opmaak en een taal die het allemaal aan elkaar verbindt (markup). Deze taal is meestal HTML of XHTML. Hoewel (X)HTML ook gebruikt kan worden om de opmaak van de pagina te regelen, bestaat er sinds 1996 een taal die nadrukkelijk bedoeld is om de opmaak van internetpagina’s te regelen: Cacading Style Sheets, kortweg CSS. Door nalatigheid van browserfabrikanten heeft het nog jaren geduurd voordat CSS goed gebruikt kon worden, maar daar is anno 2006 geen excuus meer voor: iedereen heeft tegenwoordig een browser die met CSS om kan gaan (tenzij je met speciale soft- of hardware op internet surft). Het W3C, het instituut dat de HTML-specificaties maakt, heeft dan ook besloten om elementen te schrappen (‘deprecated‘) die door CSS geregeld kunnen (en zouden moeten) worden.

Welke elementen zijn afgekeurd?

De afgekeurde elementen zijn applet, basefont, center, dir, font, isindex, menu, s, strike en u. Hiervan bespreek ik de meestgebruikte.

`Center`

center wordt gebruikt om elementen horizontaal te centreren. HTML is echter niet bedoeld voor layoutdoeleinden, daar is CSS voor. Horizontaal centeren doe je in CSS met margin. Heb je een div in de body, dan centreer je de div binnen body als volgt:

 div {margin: 0 auto}

Vergeet de div niet een bepaalde breedte mee te geven; iets centreren dat een onbekende breedte heeft, is namelijk niet te centreren. In het voorbeeld van horizontaal centreren met margins centreer ik een div van 400 pixels.

Het kan voorkomen dat je site dan nog steeds niet gecentreerd is. Een mogelijke oorzaak kan zijn, dat je de site bekijkt IE5, maar die gebruikt tegenwoordig niemand meer. Een meer plausibele verklaring is dat je geen valide doctype gebruikt. Wanneer je met CSS werkt, is een correct doctype essentieel. Lees elders op deze site over het nut van een doctype en welk doctype je dan zou moeten kiezen.

`Font`

font wordt gebruikt om de tekstopmaak te regelen. Zoals je wellicht zelf al gemerkt hebt, komt als je niet oplet na verloop van tijd je document vol te staan met font-elementen. Da’s niet overzichtelijk, niet handig om te onderhouden en bovendien achterhaald. CSS to the rescue.

Wil je alle alinea’s in Arial, dan regel je dat als volgt:

 p {font-family: Arial, sans-serif}

Ik heb een voorbeeld gemaakt waarin alle alinea’s in Arial worden weergegeven en alle andere elementen in het standaardfont van je browser (meestal Times New Roman).

`U`

u staat voor underline, het onderstrepen van elementen. Dit is met CSS te regelen via text-decoration: underline, maar ook dat is niet aan te raden. Het onderstrepen van elementen die geen links zijn, schept op internet namelijk veel verwarring onder websitebezoekers. Men denkt dan vaak ten onrechte dat er op te klikken valt. Onderstreep dus nooit tekst die geen link is!

Wordt vervolgd

In deel 2 ga ik verder in op elementen die niet zijn afgekeurd, maar waar wel een beter alternatief voor is. Ook behandel ik elementen die je wel eens tegenkomt, maar nooit tot de specificaties hebben behoord.

Je kunt meer lezen over overbodige metatags in het artikel De zin en onzin van metatags.

Wijziging 28 januari 2008: IE5-specifieke CSS verwijderd, aangezien er niet meer met IE5 wordt gesurft.

De splashpagina: handig! Of toch niet?

2012-01-17T23:05:36Z

Een splashpagina is een pagina van een website die bedoeld is als binnenkomstpagina. Meestal vind je daar een groot logo van de website, al dan niet verwerkt in een flitsend introfilmpje. Vaak wordt de splashpagina gebruikt om gebruikers te laten kiezen uit een taal, schermgrootte, of mogen ze naar wens een ‘gewone’ of een ‘superdeluxe’ versie van de website bekijken. Een splashpagina wordt dus meestal gebruikt:

Voorbeeld van een splashpagina

Om duidelijk te maken wat voor website het is;
Om een goede indruk achter te laten;
Om gebruikers keuzevrijheid te gunnen.

Allemaal erg begrijpelijke redenen, immers, bezoekers willen graag weten of ze op de goede site zijn; je wilt ook graag dat je bezoekers behoudt, door een goede indruk achter te laten; en bezoekers houden graag zelf de touwtjes in handen, dus bezoekers laten kiezen is ideaal. Toch?

De vraag is of daar een splashpagina voor nodig is. Vaak kan informatie en een goede indruk prima overgebracht worden zonder extra beginpagina. En zou het niet nog mooier zijn om bezoekers al voor te leggen waar men naar zoekt, in plaats van hen in een extra tussenstap een vraag voor te leggen?

Inhoud

Nadelen van een splashpagina
Ja, allemaal leuk en aardig, maar mijn flitsende intro dan?
Maar als ik het intro alleen bij het eerste bezoek toon?
Hoe maak ik dan duidelijk wat voor website het is?
Maar hoe laat ik gebruikers dan een taal/schermgrootte/websiteversie kiezen?
Conclusie
Extra leesvoer

Nadelen van een splashpagina

Er blijken veel nadelen te zitten aan een splashpagina:

De site met de splashpagina is moeilijk vindbaar; concurrenten zijn wel te vinden.

In de weg. Er zijn nauwelijks bezoekers die een splashpagina bekijken, want er staat nauwelijks informatie. En mocht er een animatie of filmpje staan, dan klikt men ook weg: internetters zijn ongeduldig. Vergelijk het met de ingang van een winkel waar je bij elk bezoek eerst verplicht langs een groot spandoek moet om bij de deur te komen. Of verplicht naar het optreden van steeds dezelfde clown moet kijken voordat je naar binnen mag.
Extra moeite. Makkelijk te bagatelliseren, maar een splashpagina betekent een extra muisklik voor bezoekers. Extra moeite is drempelverhogend. En elke drempel maakt de kans groter dat men vertrekt.
Extra laadtijd. Met name een groot logo of een animatie betekent extra laadtijd voor bezoekers. Extra laadtijd is drempelverhogend. Elke drempel maakt de kans groter dat men vertrekt.
Extra onderhoud. Wanneer men op de splashpagina uit meerdere versies van je website kan kiezen, betekent het ook dat je meerdere versies van je website moet onderhouden.
Extra bandbreedte. Extra laadtijd betekent vaak ook extra bandbreedteverbruik voor je website. Dat kan extra kosten met zich meebrengen.
Slechter vindbaar. En last but not least, omdat er nauwelijks informatie (trefwoorden) en links op een splashpagina staan, krijgt deze pagina een lage score in zoekmachines. Met een splashpagina zul je slechter vindbaar zijn dan zonder splashpagina. Dit valt al een aantal jaren niet meer op te lossen door trucs zoals het toevoegen van trefwoorden. Sterker nog, pagina’s waarop trucs worden toegepast, kunnen zonder pardon uit de index van de zoekmachine worden gegooid, zoals ook grote bedrijven als Ohra is gebeurd.

Ja, allemaal leuk en aardig, maar mijn flitsende intro dan?

Een goede indruk achterlaten is niet afhankelijk van een flitsende splashpagina. Je intro kan best geweldig zijn, maar aangezien de meeste internetters ongeduldig zijn, zijn ze ook weer snel weg. Daar gaat die mooie indruk. Een goede indruk achterlaten doe je wél door een overzichtelijke en makkelijk te gebruiken site te bouwen. En, belangrijker nog, door duidelijk te maken wat voor site het is en door zaken te bieden die de bezoeker wenst.

Als je ondanks alle tegenargumenten nog steeds een intro wilt tonen, dan kun je m.b.v. een cookie ervoor zorgen dat vaste bezoekers het intro overslaan. Echter, als de beveiligingsinstellingen van sommige vaste bezoekers zo zijn ingesteld dat ze geen cookies accepteren of dat cookies na het surfen worden weggegooid, zullen die vaste bezoekers bij elk bezoek alsnog iedere keer jouw intro zien. Dus iedere keer laden, iedere keer ‘skip intro’ klikken…

Kortom, er zijn simpelweg teveel argumenten om géén splashpagina te gebruiken. Duidelijk maken waar je site over gaat, gaat zelfs een stuk beter zónder splashpagina.

Hoe maak ik dan duidelijk wat voor website het is?

Enkele ideeën:

Toon op elke pagina een duidelijk logo en/of titel.
Geef op de homepage een duidelijke maar korte omschrijving waar de website over gaat, of gebruik een tagline.
Lever links naar pagina’s op je site die meer informatie bieden.

Maar hoe laat ik gebruikers dan een taal/schermgrootte/websiteversie kiezen?

Bezoekers laten kiezen is vaak helemaal niet nodig, omdat in de praktijk blijkt dat bezoekersgedrag goed voorspelbaar is en je dus bij de bouw al rekening mee kunt houden met wat bezoekers willen.

Het kiezen van een schermgrootte

Aangezien nagenoeg elke computergebruiker surft met een schermresolutie van 1024×768 of groter (ca. 95%), is één van de meest gebruikte breedtes van een website ongeveer 960-990 pixels. Zo is de site met veruit de meeste schermgroottes ¹ goed te bekijken, ook op de minilaptops of netbooks die tegenwoordig ‘in’ zijn. Wil je dat de site meer ruimte inneemt bij grotere resoluties, dan kun je kiezen voor een layout die zich aanpast aan de beschikbare grootte op het scherm, de zogenoemde fluid of liquid layouts. Zo val je de bezoeker niet lastig met vragen over schermgrootte.

Let op dat ik het het hierboven had over de schermresolutie van computergebruikers; er zijn tegenwoordig ook steeds meer mensen die surfen op hun iPhone of ander mobieltje met internet. Mobiele internetters maken gebruik van een tragere verbinding en een veel kleiner scherm. Voor hen is het prettig als je een manier biedt die verder gaat dan een smallere website. Je kunt denken aan een speciale site voor mobiele browsers (zoals bijvoorbeeld Tweakers heeft gedaan met Tweakers.mobi), of een vergelijkbare functionaliteit waarbij je jouw site laat omzetten naar een versie geschikt voor mobieltjes.

Het kiezen van een taal

Dit kun je afvangen door met behulp van serverside scripting te kijken in wat voor taal de browser van bezoekers staat afgesteld en aan de hand daarvan de website in de juiste taal voor te leggen. Dan krijgt men zonder enige moeite te doen de taal die men wenst. Ook kun je de taalkeuze deel laten uitmaken van een vaste keuze op de pagina’s van je website. Dan kan men op ieder moment switchen en is men niet afhankelijk van binnenkomst via de voorpagina.

Luxe versie vs. HTML

Bezoekers gaan in het overgrote deel van de gevallen voor de versie die de content biedt die ze zoeken. Bewegende animaties of filmpjes om je site op te fleuren zijn van ondergeschikt belang. Sterker nog, na het één of twee keer gezien te hebben, gaat het irriteren en wil men liever een versie zonder fancy animaties. Richt je dus vooral op heldere, boeiende content. Waarom zou je de moeite van het bouwen van twee websites (een luxe versie en een gewone versie) niet steken in het bouwen van één geweldige website?

Conclusie

Uiteindelijk gaat het bezoekers slechts om het makkelijk en snel vinden van de juiste informatie. Een splashpagina levert extra laadtijd, extra klikken, teveel keuze, weinig info en slechte vindbaarheid, dus draagt daar niet aan bij.

Wel ben ik benieuwd of er nog andere argumenten zijn vóór een splashpagina?

Extra leesvoer

Sink the splash pages (invalshoek: snellere website)
How to convince a client they don’t need a splash page (invalshoek: zoekmachineoptimalisatie)
Top Ten Guidelines for Homepage Usability (invalshoek: gebruiksvriendelijkheid)

Update 18 april 2009: extra links en info over cookies toegevoegd

Frontaal.net

Zes tips voor gebruiksvriendelijke links

1. Maak van elke link een echte link

2. Geef een link een beschrijvende tekst

3. Zorg dat duidelijk is wat een link is (en wat niet)

4. Maak onderscheid in onbezochte en bezochte links

5. Open links niet in een nieuw venster

6. Gebruik iconen om links te verhelderen

Meer leesvoer

Aanmelden bij zoekmachines is onzin

Frontaal.net vernieuwd: versie 2.0

Oud versus nieuw in beeld

Leesbaarheid

Connecting people

Technische aspecten

HTML en CSS: Sandbox

Meer CSS: Blueprint

Feedback?

Google publiceert handleiding zoekmachineoptimalisatie voor beginners

De zin en onzin van metatags

Inhoud

Hoe het komt dat veel metatags onzin zijn

Welke metadata zijn wel nuttig?

Overige, veelgebruikte metadata

Samenvattend

Meer leesvoer

Check je website met handige tools

Inhoud

Check je code

Check in verschillende browsers

Check je site op toegankelijkheid

Check op laadtijd

Check je site m.b.v. browsertoolbars of -extensies

Tot slot

Aanvullende artikelen

Nederlandse vertaling WP Database Backup 2.1.2

Doctype: welke moet ik kiezen?

Inhoud

De valide doctypes

De afvallers

HTML of XHTML?

Conclusie

Achterhaalde HTML-elementen, deel 1

Inhoud

Gebruik CSS voor layout en (tekst)opmaak

Welke elementen zijn afgekeurd?

Center

Font

U

Wordt vervolgd

De splashpagina: handig! Of toch niet?

Inhoud

Nadelen van een splashpagina

Ja, allemaal leuk en aardig, maar mijn flitsende intro dan?

Maar als ik het intro alleen bij het eerste bezoek toon?

Hoe maak ik dan duidelijk wat voor website het is?

Maar hoe laat ik gebruikers dan een taal/schermgrootte/websiteversie kiezen?

Het kiezen van een schermgrootte

Het kiezen van een taal

Luxe versie vs. HTML

Conclusie

Extra leesvoer

De valide `doctype`s

`Center`

`Font`

`U`