Welkom bij TheHotSeat, pseudoniem voor een Gentse freelance webontwikkelaar. Maar bovenal een blog over webdesign, webontwikkeling en (digitale) vormgeving
Over resolutie en het web
10 feb 2009•“Foto’s voor het web bewaar je best op 72 ppi.” Het is één van de meest hardnekkige fabeltjes uit de digitale beeldbewerking. Nochtans is de waarheid heel eenvoudig: wil je een foto op een website plaatsen? Dan speelt de resolutie geen enkele rol.
Van digitale naar afgedrukte beelden: resolutie
Een digitale foto is opgebouwd uit pixels. Het aantal is onbegrensd: sommige bestaan uit nauwelijks 100 pixels en andere uit meer dan 10 miljoen. Zolang een foto digitaal bestaat, dan wordt de grootte ervan uitgedrukt in pixels. Zo kan een beeld bijvoorbeeld uit 800 pixels in de breedte en 600 pixels in de hoogte bestaan. In totaal bestaat die foto dan uit (800 x 600 =) 4800 pixels.
Maar wat als we willen printen? Als je een afgedrukte foto in een krant ziet staan, dan druk je de grootte niet meer uit in pixels maar in centimeter. Er moet dus net voor het afdrukken ergens een omrekening gebeuren van pixels (het digitale beeld) naar centimeter (het afgedrukte beeld).
De omrekening is op zich eenvoudig. Onze computer zal gewoon aan onze printer meegeven hoeveel pixels die per centimeter moet afdrukken. Het is die waarde — het aantal afgedrukte pixels per centimeter — die ‘resolutie’ wordt genoemd. Alleen wordt ze niet uitgedrukt in pixels per centimeter maar in pixels per inch (afgekort ppi). Maar als je weet dat 1 inch gelijk is aan 2,54 centimeter dan is de omrekening snel gebeurd.
Websites bekijk je op schermen
Laat het dus duidelijk zijn dat resolutie enkel belangrijk is wanneer je een digitaal beeld (pixels) wil omzetten naar een afgedrukt beeld (centimeter of inch). Websites zijn niet bedoeld om afgeprint te worden maar wel om op een scherm bekeken te worden. En of dat nu een gsm-, computer-, iPod- of iPhonescherm is: schermen geven pixels weer. Als we de regel in acht nemen dan kan je trouwens stellen dat 1 afbeeldingspixel overeenkomt met 1 schermpixel. Resolutie speelt dus geen enkele rol wanneer je een foto op een website wil plaatsen.
Is je website 1000 pixels breed en wil je dat je foto de helft van de breedte van je website in beslag neemt, dan zorg je er voor dat je foto 500 pixels breed is. Simple as that. Of de resolutie van die foto nu 300 ppi, 72 ppi of zelfs 1000 ppi bedraagt maakt helemaal niet uit.
Maar wat met de bestandsgrootte?
Nog zo’n fabeltje. Een hogeresolutiefoto zou meer plaats innemen op je harde schijf dan een lageresolutiefoto. Maar dat is helemaal niet waar. Als de pixelafmetingen van beide foto’s dezelfde zijn, dan blijft de bestandsgrootte van beide foto’s ook even groot. Logisch, want in beide gevallen moeten evenveel pixels bewaard worden. En de foto’s worden ook even groot op je scherm getoond want ze nemen telkens 500 pixels in de breedte in beslag.
Test het maar even uit. De foto’s hieronder zijn beide even groot. De resolutie van de ene foto is ingesteld op 1000 ppi en die van de andere op 1 ppi. Zie je een verschil? Bewaar ze alletwee maar eens op je harde schijf. Zie je een verschil in bestandsgrootte? Het antwoord is twee maal negatief!
Is er dan helemaal geen verschil?
Als je beide foto’s zou opslaan op je harde schijf en dan afprinten, dan ga je natuurlijk wel een verschil in afdrukgrootte zien. Want de resolutie bepaalt de afdrukgrootte: bij de ene wordt er maar 1 pixel per inch afgedrukt, bij de andere worden er 1000 pixels per inch afgedrukt. De eerste zal dus 1000 keer groter afgedrukt worden dan de andere. Maar de afdrukkwaliteit zal dan ook wel erbarmelijk zijn: in theorie zal je de pixels zien als grote vierkanten van 1 inch hoog en breed.
Slotsom
Maak je foto’s klaar om op een scherm te tonen dan speelt de resolutie geen enkele rol! Resolutie bepaalt enkel de afdrukgrootte van een foto. En bijgevolg ook de afdrukkwaliteit. Wat wél telt zijn de pixelafmetingen van de foto. Die bepalen hoe groot de foto op je scherm getoond wordt.
Categorieën: Photoshop, Webomgeving,
Een dynamisch schuifregister in code
28 jan 2009•In een vorige blogpost kon je lezen over het hoe en waarom van een schuifregister. In dit artikel vatten we de koe bij de horens en gebruiken we CSS en jQuery om een dynamisch schuifregister te maken. Voor wie op hete kolen zit: dit is het resultaat en hier vind je een iets stijlvollere variant.
In den beginne was er HTML
We starten met een eenvoudige htmlpagina: een artikel met daaronder lezersreacties. Als je de bron van die webpagina bekijkt, dan zie je dat ik de plaatsen waarnaar het register moet verwijzen heb aangeduid met een id en een class. In dit geval gaat het om twee h1-tags, maar je zou evengoed een combinatie van andere htmltags kunnen gebruiken:
<h1 id="artikel" class="registerknop">Zwart gat</h1>
<h1 id="reacties" class="registerknop">Reacties</h1>
jQuery maakt het wat pittiger
jQuery maakt voor elk element met de class ‘registerknop’ een aanduiding in het schuifregister. Hoe dat in zijn werk gaat kan je hieronder meevolgen. Tussen de code vind je heel wat uitleg, maar ook straks kom ik er nog even op terug.
$(document).ready(function(){
//bereken de paginahoogte
var pageHeight = $('body').height();
//bereken de hoogte van het browservenster
var windowHeight = $(window).height();
//lengte schuifbalk tov de paginahoogte
//de pijltjes van de scrollbar nemen ongeveer 41 pixels in beslag
var scrollBreuk = (windowHeight-41)/pageHeight;
//voor elk element dat de class registerknop meekreeg
$('.registerknop').each(function(i) {
//als het het eerste element betreft
if(i == 0) {
//maak een htmllijst aan
$('body').prepend('<ul id="schuifregister"></ul>');
}
//wat is de id van dit element
var id = $(this).attr('id');
//de positie van dit element vanaf de top van de pagina
var yPos = $(this).offset().top;
//waar de schuifbalk moet zijn om het element te zien
//Math.round zorgt voor een afgerond getal zonder decimalen
//de +3 zorgt voor een net iets hogere scrollbarpositie op Mac (is mooier)
var scrollPos = Math.round(yPos * scrollBreuk) + 3;
//voeg een list item aan de lijst toe voor het huidige element
//accesskey is de eerste letter van de id
$('#schuifregister').append('<li><a accesskey="' + id[0] + '" href="#' + id + '">' + id + '</a></li>');
//plaats het nieuwste list item op de juiste schuifbalkpositie
$('#schuifregister li:last-child').css('top', scrollPos + 'px');
});
});
Zoals je kan zien zoeken we eerst de hoogte van de schuifbalk ten opzichte van de browservensterhoogte. We trekken 41 pixels af van de hoogte van het browservenster omdat dat de ruimte is die de pijltjes van de schuifbalk zelf innemen op een Mac:
Die ingenomen hoogte varieert trouwens een beetje op Windows én de plaatsing is anders. Om goed te zijn zou je die waarde (41) dus moeten laten afhangen van het besturingssysteem van de gebruiker, maar zover heb ik het in dit voorbeeld niet gedreven. (Het kan dus zijn dat dit schuifregister niet helemaal accuraat werkt op Windows computers!)
Soit, terug naar het stukje code van hierboven: nadat we enkele vaste waarden in variabelen hebben opgeslagen, gaat het script op zoek naar elk html element met registerknop als class. Als zo’n element gevonden wordt dan wordt een htmllijst aangemaakt (ul) waarin per registerknop een list item (li) verschijnt. De htmllijst is makkelijk vorm te geven met CSS en kan ontelbaar veel list items bevatten. Zoals je kan zien in het stukje code kan je het schuifregister ook via accesskeys bedienen. (De code hiervoor is weliswaar niet waterdicht.)
De plaatsing van elk list item wordt in het voorlaatste regeltje code afgehandeld.
Plaatsing en vormgeving met CSS
Hoewel we jQuery gebruiken om de plaatsing van elk list item via CSS in te stellen, is de belangrijkste opmaak toch wel apart in een stylesheet terug te vinden. De CSS die nodig is om het schuifregister vorm te geven heb ik telkens in de head sectie van de htmlpagina geplaatst:
ul#schuifregister {
list-style: none;
}
ul#schuifregister li {
position: fixed;
font-size: .9em;
right: 0;
background: url(pijl.png) no-repeat center right;
padding-right: 15px;
text-transform: capitalize;
}
Het meest opmerkelijke stukje is hier het instellen van de fixed position. Hierdoor blijft elk list item mooi in positie staan als de schuifbalk schuift.
De andere CSS-code die ik in een externe stylesheet heb geplaatst is niet zo belangrijk voor het schuifregister op zich maar zorgt voor de opmaak van de rest van de pagina-elementen. We mogen onszelf nu trouwens wel al eens op de borst kloppen: dit is ons resultaat.
Meeschalen met het browservenster
Het komt aardig in de buurt maar mist nog iets: als de gebruiker het browservenster kleiner of groter maakt, dan klopt de aanduiding van het schuifregister niet meer. Maar met behulp van een vleugje jQuery kunnen we dit makkelijk oplossen: we gieten onze code in een functie toonRegister() die we uitvoeren wanneer het venster geschaald wordt.
Belangrijk is dat we hierbij telkens eerst het schuifregister ook verwijderen om na verloop van tijd geen honderden schuifregisters te zien. Ik schreef hier de welluidende functie verbergRegister() voor:
$(document).ready(function(){
//voer de functie toonRegister() uit als de pagina geladen is
toonRegister();
//als het browservenster geschaald wordt
$(window).resize(function(){
verbergRegister();
toonRegister();
});
//de code van hierboven in een functie gestopt
function toonRegister() {
var pageHeight = $('body').height();
var windowHeight = $(window).height();
var scrollBreuk = (windowHeight-41)/pageHeight;
(...)
}
function verbergRegister() {
//verwijder de htmllijst en hiermee het volledige schuifregister
$('#schuifregister').remove();
}
});
Dit is het resultaat. Schaal gerust je browservenster eens door de rechterbenedenhoek vast te nemen en te verslepen. Je zal zien dat de plaatsing van de aanduidingen in het schuifregister telkens mee aangepast wordt aan de nieuwe afmetingen van het venster. Nice!
Een vleugje finesse
Eigen aan blogs en dynamische websites is dat je als ontwerper niet kan voorzien hoe lang de teksten zullen zijn die je klant op zijn website plaatst. Nu lijkt het een beetje onnozel om een schuifregister te hebben op een pagina waar niet gescrold moet worden (deze bijvoorbeeld). Wat meer is: de aanduidingen zijn niet meer helemaal juist. Daarom heb ik nog een bijkomende controle toegevoegd in het stukje javascriptcode die er voor zorgt dat het schuifregister niet getoond wordt wanneer alle belangrijke elementen duidelijk zichtbaar zijn op de pagina:
function toonRegister() {
(...)
//als alles mooi zichtbaar is dan moet er geen schuifregister te zien zijn
if($('.registerknop:last').offset().top > windowHeight) {
$('.registerknop').each(function(i) {
(...)
});
}
Het resultaat
Dit is het resultaat van het experiment. Bekijk ook deze iets stijlvollere variant. In de broncode vind je nog eens alle code op een rijtje.
Het is een makkelijk aanpasbaar en stijlbaar schuifregister geworden. De gebruiker kan bovendien heel snel doorheen de pagina navigeren met behulp van accesskeys.
Ik ben benieuwd naar jullie bevindingen. Vind je zo’n schuifregister duidelijk en gebruiksvriendelijk? Of denk je dat het net verwarrend werkt?
Categorieën: Ontwerp, Ontwikkeling, jQuery, Webomgeving,
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,
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,
Suf surfen op zondag
19 okt 2008•Heb web spuwt een onafgebroken stroom van informatie onze kant uit. Vaak is het pompen of verzuipen. Hier is een korte selectie van wat ik in de afgelopen week hoogst interessant vond.
Online productvideo’s
Vooreerst even als aanvulling op mijn post over online productvideo’s: Soundcloud heeft naast een mooi logo ook een mooie productvideo online gezet. Je kan het filmpje niet missen op hun homepage. De video van Silverback (onderaan de pagina) lijkt dan weer een stuk minder interessant. De video duurt te lang en is helemaal niet to the point.
Verder over video
Eric Velleman van Accessbility heeft het in dit artikel over hoe je video op een toegankelijke manier op je website kan plaatsen. Helemaal bovenaan het artikel kan je een voorbeeldvideo zien van de Nederlandse spoorwegmaatschappij NS, inclusief captions en audiobeschrijving voor blinden en doven. (Via)
Ode aan Josef Müller-Brockmann
Via Wilson Miners blog kwam ik terecht op een Flickr set met posters van de uitstekende Zwitserse ontwerper Josef Müller-Brockmann. Gewapend met Helvetica, eenvoudige vormen en een bijzonder goed oog voor evenwicht en spatiëring was Müller-Brockmann één van de voorvechters van een gridgebruik in de grafische vormgeving.
Wat als je sterft?
Josef Müller-Brockmann overleed helaas in de vorige eeuw. En over doden gesproken: Tech Rader heeft in de afgelopen week een opmerkelijk artikel online geplaatst (in het Engels weliswaar). Het geeft antwoorden op de vraag wat er gebeurt met je ‘online profiel’ als je sterft. Waar gaan je websiteprofielen, blogcommentaren, websites en foto’s naar toe?
Rotis FF
Sander Baumann breide dinsdag een vervolg aan zijn interessante Font Series, een reeks blogposts waarin de specialist in bewegwijzering foto’s post van gevonden typografie. Deze keer laat Baumann foto’s zien van de Rotis Font Family. Een aanrader.
Categorieën: 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