Welkom bij TheHotSeat, pseudoniem voor een Gentse freelance webontwikkelaar. Maar bovenal een blog over webdesign, webontwikkeling en (digitale) vormgeving
Het schuifregister: de scrollbar als leidraad
13 jan 2009•Elke dag opnieuw word ik via mijn RSS-lezer overstelpt door interessante artikels en blogs op het internet. De meeste daarvan skim ik heel snel en oppervlakkig. Maar als ik een artikel echt aandachtig wil lezen, dan maakt mijn oog eerst even een snelle sprong naar de schuifbalk. Die geeft me een idee over de lengte van het artikel. Het is de lengte van de tekst en mijn beschikbare vrije tijd die me helpen beslissen of ik het artikel meteen ga lezen of zal bookmarken onder ‘interessant’ om er later op terug te komen.
Geen goede waardemeter
Maar uit de hoogte van de schuifbalk is niet altijd even makkelijk af te leiden uit hoeveel tekst een blogpost bestaat. Een schuifbalk laat je scrollen tot het einde van een webpagina en dat is doorgaans een stukje verder dan het einde van de blogpost. Denk maar aan die blogs waar lezersreacties te zien zijn onderaan elke blogpost. Hoe meer reacties, hoe onjuister de verhouding tussen de lengte van de blogpost en de hoogte van de scrollbar.
Een schuifbalk moet schuiven
De schuifbalk is dus op zich geen goede waardemeter voor de lengte van de tekst. Geen verwijt aan het adres van de scrollbalk natuurlijk want die is in de eerste plaats ontworpen om te scrollen, en daar is ze ook verdomd goed in. In het licht van gebruiksvriendelijkheid en goed ontwerp zou het trouwens verkeerd zijn om de schuifbalk andere functies te gaan toedichten. Dat zou enkel leiden tot verwarring.
Mag het iets meer zijn?
Maar dat wil niet zeggen dat we haar huidige vorm en functie niet mogen versterken. In de Chrome browser heeft Google een vernuftig idee geïmplementeerd: als je een zoekactie start dan toont Chrome je aan de hand van markeringen in zijn schuifbalk waar die zoekterm voorkomt op de huidige pagina.
Het werkt verbazend intuïtief en de schuifbalk wordt er zeker niet minder gebruiksvriendelijk op. De gele streepjes versterken enkel de oorspronkelijke functie van de schuifbalk: navigeren naar een onzichtbaar stuk van de huidige webpagina. Waar je vroeger in het ongewisse verschoof, weet je nu perfect waar je het balkje naar toe moet schuiven.
Webdesigners
Als webdesigners hebben we natuurlijk - en gelukkig maar - geen controle over de schuifbalk zelf, maar Google Chrome heeft me wel aan het denken gezet. Ik ben heus niet de enige die graag het overzicht behoudt wanneer ik op een website kom en ik kan me inbeelden dat veel mensen gebruik maken van de schuifbalk om te zien hoe lang een tekst is vooraleer ze die beginnen te lezen. Of om snel een overzicht te krijgen van de volledige webpagina.
Digitaal duimregister
Misschien kunnen we net naast de schuifbalk markeringen aanbrengen die aanduiden waar zich de kernelementen van een webpagina bevinden: de blogpost en de reacties, of de hoofdstukken van een verhaal. Hieronder vind je een hele eenvoudige schets van het idee - een soort van online duimregister.
Door de schuifbalk te verplaatsen naar de markeringen kom je meteen op het juiste stuk van de webpagina terecht. De markeringen zelf zijn uiteraard altijd onbeweeglijk en zichtbaar, het maakt niet uit of je je bovenaan of onderaan de webpagina bevindt.
Over de technische uitwerking heb ik nog niet nagedacht maar als het mogelijk is, dan zal dat waarschijnlijk via een combinatie van absolute positionering en javascript zijn. Ik ben er wel van overtuigd dat dit schuifregister een hulp kan zijn voor vele online lezers. Vooral zij die op zoek zijn naar het soort van overzicht dat van nature wel vaker aanwezig is in de traditionele gedrukte media: boeken, kranten en tijdschriften.
Categorieën: Ontwerp, Opinies, Webomgeving,
Hoe kunnen we online identiteitscontrole gebruiksvriendelijker maken?
17 dec 2008•Het online amalgaam van registratie en identiteitscontrole is sinds jaar en dag één grote knoeiboel. Elke website heeft zijn eigen variant op het systeem van persoonlijke identificatie en het aantal gebruikersnamen en wachtwoorden dat ik ondertussen moet onthouden is niet meer op de handen van een gemiddeld Belgisch gezin te tellen. Toen ik enkele weken terug een doordeweekse internetgebruiker versuft zag kijken naar haar scherm tijdens het registreren voor een Gmail e-mailadres kreeg ik alleen maar een bevestiging van het gevoel van verwarring.
Hoe kunnen we online identiteitscontrole gebruiksvriendelijker maken?
De situatie nu
Elke website volgt momenteel een eigen logica, de één al gestroomlijnder dan de ander. Die verschillen tussen websites onderling maken het er natuurlijk niet makkelijker op. De ene site laat je een herinneringsvraag invullen, de andere verwacht dat je klikt op een activeringslink in een e-mail, weer andere laten je inloggen via je e-mailadres en nog andere verwachten gewoon een gebruikersnaam en wachtwoord…
Gelukkig snellen de browsers ons te hulp tijdens het inloggen. Ze gaan heel vaak de gebruikersnaam en het wachtwoord per website gaan opslaan. En als de browser die onthoudt dan hoef ik het niet meer te doen! Dat is handig.
OpenID: een stap in de goeie richting
Enkele jaren geleden is OpenID in het leven geroepen. Dat was een grote stap voorwaarts want je hoeft nu maar 1 gebruikersnaam en wachtwoord meer te onthouden waarmee je inlogt in je OpenID identiteit. En met die OpenID identiteit kan je je dan aanmelden op alle websites die OpenID ondersteunen. Eén gebruikersnaam en wachtwoord voor heel veel websites dus.
Het nadeel is de vaak onduidelijke doorverwijzing van de website waar je wil inloggen naar de OpenID website. Het haalt je ook een beetje weg uit de navigatielogica en algemene look and feel van de website waarop je wil inloggen en kan in die zin verwarrend werken. En hoewel de lijst dag na dag groeit, zijn er nog altijd niet zoveel websites die OpenID ondersteunen.
Je identiteit koppelen aan de browser?
Waarom hangen we dan geen identiteit vast aan een browsersessie? Via een knop in de browser kan je jezelf aanmelden en sites kunnen dan gebruik maken van die browseridentiteit als je ze de toestemming geeft. Een simpele ‘Log in’ knop is dan voldoende op websites. Die knop stuurt een signaal naar de browser die reageert met de vraag of je je identiteit wil gebruiken op deze website. Jij geeft dan je toestemming waarop de browser de nodige informatie uit je browserprofiel doorstuurt naar de site.
Het voordeel: je beheert je profiel centraal op 1 plaats (lokaal op je computer of op een server zoals die van OpenID). Je hoeft dus geen 30 sites af te lopen wanneer je e-mailadres wijzigt. Maar ook aanmelden en registeren gebeurt altijd op dezelfde manier: via de browser. Het lijkt me een eenvoudig maar perfect realiseerbaar idee dat het proces van online identiteitscontrole toch een pak gestroomlijnder kan maken. Of stel ik het me een beetje te simplistisch voor?
Update: de Flock browser blijkt sinds kort via een extensie de mogelijkheid aan te bieden om via de browser zelf in te loggen op je OpenID identiteit. Die identiteit kan je dan gebruiken op alle sites die OpenID ondersteunen (zonder dat je dus doorverwezen wordt naar de site van je OpenID provider). Hoewel de grafische gebruikersinterface van de Flock extensie er nogal onhandig uitziet (Check deze video op de Flock blog maar even), is dit natuurlijk wel een hele grote stap in de goede richting.
Categorieën: Opinies, Webomgeving,
Een handvol uitstekende concertposters
8 dec 2008•Aesthetic Apparatus is al jarenlang een van mijn favorieten wanneer het op vormgeving, typografie en zeefdrukwerk aankomt. Vooral tussen hun concertposters zitten enkele pareltjes.
Nu hebben ze blijkbaar ook een reeks gigantisch grote affiches ontworpen voor het Belgische Stella Artois. De affiches werden opgehangen in de Londense metro. Hier is een voorsmaakje.
Tientallen meer voorbeelden van affiches en ander grafisch werk vind je op de website van het Amerikaanse Aesthetic Apparatus. Ongetwijfeld een grote inspiratiebron voor velen.
Categorieën: Ontwerp, Typografie,
Zend Framework en jQuery formuliervalidering
2 dec 2008•Hoewel ik voldoende vertrouwd ben met php en javascript, voel ik me in de eerste plaats een ontwerper. Dat is ongetwijfeld de reden waarom ik zo hou van frameworks want als ik toch de programmeerkant opga dan laten ze me toe om snel robuuste code te schrijven. Sinds enkele maanden ben ik voor een klant intensief bezig met het Zend Framework voor php en jQuery voor javascript.
Het project waaraan ik werk maakt uitvoerig gebruik van HTML-formulieren (via Zend_Form) en dus is het valideren van de gegevens die een eindgebruiker invult een noodzaak. Een voorbeeldje van formuliervalidering vind je hieronder. Als de gebruiker op de ‘Aanmelden’ knop klikt zonder een paswoord in te vullen, dan wordt het formulier niet verzonden maar verschijnt er een boodschap op het scherm. Het paswoordveld is immers verplicht in te vullen.
Het Zend Framework zorgt voor goede validering aan de serverkant, maar ik twijfelde over hoe ik de validering zou aanpakken aan de clientkant.
Javascript en php
De meest voor de hand liggende oplossing is natuurlijk het schrijven van javascriptfuncties die de formuliervalidering aan de clientkant voor hun rekening nemen. Maar ik hou er niet van om twee keer code te schrijven met hetzelfde einddoel: één keer in php en één keer in javascript. In een project dat in de maanden na lancering ongetwijfeld nog heel wat aanpassingen zal ondergaan lijkt het me niet aangewezen om telkens zowel de php-code als de javascriptcode te moeten wijzigen wanneer er iets verandert aan een formulier.
Laat Zend_Form de validering maar doen!
Ik heb er dan maar voor gekozen om alles wat betreft formuliervalidering te laten afhandelen door het Zend Framework. Dankzij een jQuery ajax oproep naar de Zend_Form isValidPartial() functie ben ik toch in staat om een gebruiksvriendelijke en snelle validering per formulierveld op het scherm van de gebruiker te tonen.
In de indexAction() van mijn controller regelt het onderstaande stukje code de server-side validering. Niets nieuws voor wie ooit al eens Zend_Form heeft gebruikt. De isValid() functie checkt de input en geeft een foutmelding weer op het scherm van de gebruiker als die ongeldige gegevens in het formulier heeft ingebracht. Pas wanneer alle input geldig is wordt het formulier echt verzonden en de database geüpdatet.
if($this->_request->isPost()) {
$formData = $this->_request->getPost();
if($form->isValid($formData)) {
//update database
} else {
$form->populate($formData);
}
}
Het nadeel van bovenstaande code is dat de validering pas gebeurt nadat het formulier wordt verzonden. De gebruiker moet dus wachten op een paginavernieuwing alvorens te weten of zijn ingevulde gegevens geldig of ongeldig waren. ‘So nineties!’, hoor ik je roepen. Dat komt inderdaad niet overeen met de snelle responstijd die een gebruiker vandaag verwacht van een webapplicatie.
jQuery to the rescue!
jQuery zal er voor zorgen dat de ingevulde gegevens van elk veld gevalideerd worden op de server net na het invullen van het veld via een Ajax oproep. Zo weet de gebruiker meteen of het veld goed ingevuld is of niet, en dat zonder te moeten wachten op een paginavernieuwing.
jQuery roept daarvoor telkens een tweede action aan in mijn Zend Framework controller. Ik heb die validateformpartial genoemd:
public function validateformpartialAction() {
if($this->_request->isPost()) {
$formData = $this->_request->getPost();
if($form->isValidPartial($formData)) {
//update database
$this->view->result = true;
} else {
//geeft foutief ingevulde velden weer met hun foutmelding
$this->view->messages = $form->getMessages();
$this->view->result = false;
}
}
}
Het verschil zit in de aangeroepen functie: isValidPartial() laat toe om enkel het doorgegeven stukje formdata te valideren. Heb je dus een formulier dat uit 5 velden bestaat en je wil maar 1 veld valideren dan kan dat via isValidPartial(). getMessages() geeft de fouten weer per veld. (Meer informatie over getMessages vind je in de Zend Framework handleiding.)
Belangrijk is wel dat je via je javascript functie enkel json (of xml) terugkrijgt van die Zend Framework action. Je moet dus Zend_Layout en Zend_View uitschakelen voor die ene action. Dat kan makkelijk in de initAction() van je controller dankzij de AjaxContext helper:
$ajaxContext = $this->_helper->getHelper('AjaxContext');
$ajaxContext->addActionContext('validateformpartial','json')->initContext();
Alles wat je in de validateformpartialAction() als variabele aan de view meegeeft (via $this->view->variableName) wordt dan meteen door die functie als json geretourneerd. Dat maakt het makkelijk om die variabelen in jQuery op te vangen en er iets mee te doen. Zo kan je bijvoorbeeld via jQuery per veld tonen welke fout de gebruiker gemaakt heeft tijdens het invullen van het formulier.
Ter vervollediging is hier de jQuery ajax functie die de waarde van het ingevulde formulierveld doorstuurt naar de validateformpartialAction van daarnet uit de Zend Framework controller:
$.ajax({
type: "POST",
//dataString is een string in dit formaat: &naam=johnny&beroep=bouwvakker
//je geeft dus de value van alle ingevulde formuliervelden die je wil valideren mee
data: $dataString,
//baseUrl bevat het pad naar je webapplicatie
url: baseUrl + "/controllernaam/validateformpartial",
dataType: "json",
//showSpinner toont een grafisch element dat de gebruiker er op wijst dat er iets aan het gebeuren is
beforeSend: function(){ showSpinner(); },
//handleResponse verwerkt de teruggekregen json data en toont de gebruiker het resultaat van de validering
//hideSpinner() verbergt het grafische element
success: function(json){ handleResponse(json); hideSpinner(); },
});
That’s it. Door de vele requests naar de server is het misschien niet de meest aangewezen manier om formuliervalidering te doen voor grootschalige webapplicaties, maar voor het project waar ik aan werk is het zeker voldoende. Het systeem zal zelfs op hoogdagen nooit door meer dan 100 gebruikers tegelijk gebruikt worden.
Het grote voordeel is dat de formvalidering overgelaten wordt aan Zend_Form. Eén regeltje wijzigen in je Form class is dus voldoende om zowel je formulier, de ajaxvalidering als de php validering up-to-date te brengen. Geen dubbel javascript valideringswerk dus. Het maakt mijn applicatie een stuk makkelijker te onderhouden.
Categorieën: Ontwikkeling, jQuery, PHP, Zend Framework,
Een masker per slimme filter in Photoshop
25 nov 2008•Photoshop CS3 maakt 1 filtermasker aan per slim object, ongeacht het aantal filters dat je er op toepast. In deze blogpost demonstreer ik een techniek die je toelaat om een filtermasker te creëren per filter. En dat zonder lagen te hoeven kopiëren of samenvoegen. Het voordeel is grandioos: nu kan je filters toepassen met de flexibiliteit van aanpassingslagen.
Het probleem
Eerst even een schets van het probleem aan de hand van een foto die ik nam op een zomeravond in Québec:
Omdat ik vond dat de keien vooraan teveel aandacht opeisten, heb ik ze onscherp gemaakt. Zo creërde ik ook meteen een groter gevoel van scherptediepte.
Het onscherp maken deed ik vrij eenvoudig via de filter Gaussiaans vervagen (Eng: Gaussian blur). En door die als een slimme filter toe te passen kan ik ten allen tijde terugkeren naar mijn oorspronkelijke scherpe keien, mocht ik me achteraf bedenken. Tegelijk kan ik met zwart op het filtermasker schilderen boven het huisje, de berg en de wolken om die delen van mijn foto perfect scherp te houden.
Uitstekend dus! De lagenpalet van mijn foto zie je hieronder. Let op het filtermasker; het zwarte stuk zorgt er voor dat de filter Gaussiaans vervagen niet zichtbaar is op die plaats van de foto.
Ik hou van het contrast tussen het warme kunstlicht en de koele tinten van de omgeving. Om de aandacht van de kijker nog meer op dat kleurenspel te richten wilde ik graag een vignet aan de foto toevoegen. Dat is een vrij populair effect dat de hoeken van de foto donkerder maakt.
Een vignettering kan je snel verkrijgen via het menu ‘Filter > Vervorm > Lenscorrectie’ (‘Filter > Distort > Lens correction’). Alleen zit ik nu natuurlijk met het probleem dat het filtermasker van daarnet niet alleen de vervagingsfilter bovenaan onzichtbaar maakt, maar ook het vignet. De afbeelding hieronder toont wat er aan de hand is:
Zoals je ziet creërt Photoshop 1 filtermasker per slim object en niet per slimme filter. In het ongewenste resultaat zie je enkel een vignet in de onderste hoeken van de foto:
De oplossing
Er is gelukkig een mouw aan te passen. Volg deze werkwijze als je meerdere slimme filters wil toepassen, elk met hun eigen filtermasker:
Stap 1: Pas je eerste filter toe
Zet je laag om naar een slim object en pas je eerste filter toe. In mijn bovenstaande voorbeeld is dat de filter Gaussiaans vervagen. Gebruik het filtermasker indien nodig.
Stap 2: Dubbelklik op het slim object in de lagenpalet
Photoshop opent nu het referentiebestand waarnaar het slim object verwijst.
Stap 3: Zet de laag van dat referentiebestand om naar een slim object
Dat kan via ‘Laag > Slimme objecten > Omzetten in slim object’ (‘Layer > Smart objects > Convert to smart object’). Je werkt nu dus met een slim object in een slim object!
Stap 4: Pas je tweede filter toe op dit slim object
In het geval van mijn voorbeeld is dat de vignettering. Indien nodig kan je het filtermasker gebruiken om ook deze filter lokaal onzichtbaar te maken.
Stap 5: Bewaar en sluit het referentiebestand
Je zal zien dat je bewerking hierna ook doorgevoerd wordt in het oorspronkelijke bronbestand. En de tweede filter is niet meer onderhevig aan het filtermasker van de eerste filter. In mijn voorbeeld levert dat zoals je hieronder ziet een echt vignet op. De vier hoeken zijn nu donkerder:
Je kan de bovenstaande stappen indien nodig enkele keren herhalen om meerdere slimme filters toe te passen, elk met hun eigen filtermasker. De truck bestaat er dus gewoon uit om telkens een slim object binnenin een slim object te gaan maken. Het lijkt in het begin wat ingewikkeld maar laat je zeker niet afschrikken, het is helemaal niet zo moeilijk als het lijkt.
één klein nadeel misschien
Het nadeel aan de bovenstaande werkwijze is dat het niet evident is om ook nog maanden later te weten wat er juist met de foto is gebeurd. Dan moet je er aan denken te dubbelklikken op het slimme object in de lagenpalet om dan in het referentiebestand te zien dat er ook nog een tweede filter is toegepast op de foto. Maar je zou natuurlijk de naamgeving van het slim object zo kunnen aanpassen dat je weet dat er een tweede slim object in vervat zit. Ik denk dan aan iets als ‘foto huis SO in SO’.
En in Photoshop CS4?
Ik heb de kans nog niet gekregen om Photoshop CS4 uit te testen omdat ik wacht om mijn geld boven te halen tot de Nederlandstalige versie op de markt komt. Ik weet dan ook niet of Photoshop CS4 standaard een filtermasker per slimme filter aanmaakt (laat zeker iets weten als jij het al eens hebt kunnen testen! Update: Viero laat in een reactie weten dat ook CS4 geen masker per filter aanmaakt!). Maar als dat niet zo is, dan kan je ook in CS4 ongetwijfeld gebruik maken van deze techniek.
Gebruik je zelf een andere manier om een filtermasker te bekomen per slimme filter of heb je bemerkingen bij deze werkwijze? Dan hoor ik het uiteraard heel graag van je!
Categorieën: Photoshop,
Waarom ik koos voor ExpressionEngine als cms voor mezelf en mijn klanten
10 nov 2008•In een vorige blogpost had ik het over de reden waarom ik destijds gestopt ben met het ontwikkelen van mijn eigen handgecodeerd contentmanagementsysteem (cms) voor klanten. Vandaag wil ik je vertellen waarom ik uiteindelijk voor ExpressonEngine heb gekozen als vervangend cms.
Ontwerpen in alle vrijheid
ExpressionEngine laat me websites ontwerpen in alle vrijheid. Het systeem is zo flexibel dat het me de vrijheid geeft te ontwerpen en coderen op exact dezelfde manier waarop ik het altijd al heb gedaan. En dat is heel belangrijk voor mij. Pas wanneer de front-end perfect werkt zoals ik het wil, begin ik met de implementatie van ExpressionEngine als back-end. Het cms legt me dankzij het ingenieuze gebruik van templates, velden en tags geen enkele beperking op op het vlak van vormgeving of technische functionaliteit.
Krachtig genoeg voor de meeste websites
ExpressionEngine is heel krachtig en aanpasbaar zodat 95% van de websites die ik ontwikkel uitgewerkt kunnen worden met ExpressionEngine als back-end. Geen enkele websitestructuur bleek tot nu toe niet te passen in het EE plaatje. Daarenboven laat ExpressionEngine me toe om veel sneller de meestgevraagde websitefuncties (ik denk aan contactformulieren, weblogs of fotogalerijen) aan mijn klanten aan te bieden, én is het uiterst zoekmachinevriendelijk.
Eenvoudig aan te leren
ExpressionEngine werkt heel intuïtief en was voor mezelf heel eenvoudig om aan te leren. Ik lieg niet wanneer ik je vertel dat ik in één dag in staat was om een eenvoudige bestaande website gebruiksklaar en updatebaar te maken via ExpressionEngine. Hoewel de broncode van EE vrij beschikbaar en aanpasbaar is, is het cms niet gratis te gebruiken in een commerciële omgeving. Dat hoeft in mijn ogen niet meteen een nadeel te zijn: als wederdienst kan je rekenen op hun uitstekende uitgebreide documentatie en de technische ondersteuning die je als EE klant krijgt is tot nu toe ongelooflijk snel en to the point gebleken.
Gebruiksvriendelijk voor mijn klanten
Op het eerste zicht leek de back-end mij klantonvriendelijk en dat is en was dan ook het grootste minpunt aan Expression Engine. Het is vaak wat zoeken naar de meest banale opties en onderdelen. Maar gelukkig kan je het cms vrij goed aanpassen via een uitgebreid rechtensysteem zodat mijn klanten toch op een overzichtelijke en duidelijke manier hun weg vinden in het updategedeelte van hun websites. Dit is essentieel in mijn ogen. Ik wilde een cms dat ook voor computerleken eenvoudig te gebruiken is.
Ik kan nog een tijdje doorgaan maar de bovenstaande punten zijn voor mij de meest belangrijke. Ter informatie geef ik je nog een lijstje mee van andere contentmanagementsystemen die ik meer of minder uitgebreid heb getest: CMS Made Simple, Modx, Wordpress, Joomla!, Textpattern, Plone en Drupal. Om één of meerdere van bovenstaande redenen hebben deze het echter niet gehaald.
Categorieën: ExpressionEngine, Opinies, Webomgeving,
Zwarte tekst op een witte achtergrond
2 nov 2008•Als je even snel honderden jaren boekdrukkunst en typografie overloopt, dan merk je gauw dat het gros van de gedrukte boeken bestaat uit zwarte tekst op wit papier. Dat duidelijke contrast tussen de letterkleur en de achtergrondkleur zorgt er natuurlijk voor dat we aangenaam kunnen lezen.
Ook de letterkleur van tekst die op schermen gelezen wordt, contrasteert best sterk met de achtergrondkleur om makkelijk leesbaar te zijn. Maar is zwarte tekst op een witte achtergrond ook hier de heilige graal? Mogen we met andere woorden deze typografische waarheid van honderden jaren boekdrukkunst zomaar overnemen op het web? Als we de websites van het gros van de Belgische kranten bekijken, dan lijkt dat zo te zijn.
DE PROEF OP DE SOM
Maar laat ons toch maar even op onderzoek uitgaan. Hier vind je een webpagina waarop tweemaal dezelfde tekst te lezen is. Aan de linkerkant zie je zwarte tekst (#000 voor de techneuten onder ons) op een witte achtergrond, aan de rechterkant donkergrijze tekst (#444) op een witte achtergrond. Welke vind jij het aangenaamst lezen?
Mijn gevoel neigt alvast naar de rechterkant. In het linker stuk lijkt het contrast tussen letter en achtergrond té drastisch. De rechter tekst staat zachter en leest naar mijn mening een stuk comfortabeler.
WAAR ZIT DAN HET VERSCHIL?
Wat in de wereld van drukwerk een bewezen waarheid is, lijkt op het web niet te werken. Een wit blad papier kan je nu eenmaal niet vergelijken met een wit vlak op een computerscherm. Als je even de gordijnen dicht doet en het licht uitlaat dan snap je wel wat ik bedoel: een scherm straalt licht uit; opdringerig licht.
Dat licht zorgt er voor dat het contrast tussen schermwit en schermzwart groter is dan dat tussen papierwit en drukzwart. En téveel contrast blijkt de leesbaarheid niet te bevorderen.
Conclusie
Webteksten laten we best niet té fel laten contrasteren met de achtergrond. We kiezen dus beter voor grijs-wit ten nadele van zwart-wit. Uiteraard werkt om het even welke andere kleurcombinatie die een aanvaardbaar contrast oplevert even goed. Hier zijn enkele goede online voorbeelden in verschillende kleurcombinaties. Ook eervolle vermeldingen voor onder andere deze Belgische dagbladen: De TIjd, Het Belang Van Limburg en Le Soir.
Niet geheel terzijde: alles hangt natuurlijk in grote mate af van de lichtomstandigheden van zowel het scherm (de meeste schermen kan je dimmen) als de omgeving. Als de zon op je scherm invalt, dan lijkt een zwart-wit scenario altijd beter leesbaar dan wanneer je in het donker op je computerscherm staart.
Wat vertelt jouw gevoel en je persoonlijke leeservaring op het web over deze typografische kwestie? Ik hoor graag je mening.
Categorieën: Ontwerp, Typografie, Opinies, Webomgeving,
Over 
TheHotSeat is Thomas Byttebier, freelance webontwikkelaar en grafisch ontwerper.
Op deze website blog ik over alles wat met webdesign en digitale vormgeving te maken heeft. Meer informatie over mij.
RSS Feed TheHotSeatLaatste blog posts
- Upgraden naar ExpressionEngine 2.0
- Hoe het ontwerp van Transistor tot stand kwam
- Transistor: radio op de iPhone
- Over HTML5
- Scrollen in het oneindige
Laatste reacties
- Hendrik op Upgraden naar ExpressionEngine…
- Thomas Byttebier op Hoe het ontwerp van Transistor…
- Thomas Byttebier op Upgraden naar ExpressionEngine…
- Kevin op Upgraden naar ExpressionEngine…
- Frederik Severijns op Hoe het ontwerp van Transistor…
Categorieën
Alle • ExpressionEngine • iPhone • Transistor • Marketing • SEO • Ontwerp • Typografie • Ontwikkeling • jQuery • PHP • Zend Framework • Opinies • Overige • Photoshop • Webomgeving