Welkom bij TheHotSeat, pseudoniem voor een Gentse freelance webontwikkelaar. Maar bovenal een blog over webdesign, webontwikkeling en (digitale) vormgeving
De Helvetica’s van het internet
29 mei 2009•Arial, Verdana en Georgia: het zijn de Helvetica’s van het internet. Overgebruikt, onopvallend en leeggezogen van elke connotatie. Waarom vallen webdesigners altijd terug op deze 3 klassieke lettertypes? Het antwoord is helemaal niet spannend: het zijn de enige fonts die op nagenoeg elke computer geïnstalleerd zijn. En dus is de kans enorm groot dat jij ook deze tekst in Arial ziet, en de titels in Georgia.
Maar als we de aankondiging op de nieuwe Typekit website mogen geloven, dan staan we aan de vooravond van een typografische webrevolutie. Typekit, een online fontbibliotheek, zal het technisch en legaal mogelijk maken om als ontwerper webteksten in een arsenaal aan kwaliteitslettertypes te zetten. De bezoeker krijgt dan steevast het juiste lettertype te zien. Hoe het allemaal in zijn werk zal gaan, kan je lezen op de Typekit blog.
Hoera! Eindelijk zullen ook websites net als boeken, tijdschriften en affiches in prachtige letters verschijnen. Niet via onhandige javascript- of flashtrucjes, maar dankzij het eenvoudige @font-face css-principe. Ik kijk uit naar zoveel moois. Lettervormen die iets vertellen over de inhoud van de website, die een gevoel kunnen versterken en die bijdragen tot een betere ervaring van het internet.
Alleen vrees ik ook de keerzijde van de medaille. Hoelang zal de experimentale fase duren waarin blogs en websites van hobbyisten in de meest onleesbare lettertypes gezet zullen worden? Een Impact voor leestekst en een goedgekozen Comic Sans – dat is toch schoon meneer – voor de invulvelden?
Hoewel Arial, Verdana en Georgia al lang niet meer tot de verbeelding spreken, één ding moeten we ze wel toegeven: ze zijn verdomd goed leesbaar op schermen. Ze leggen de nadruk op de tekst en de inhoud en daar gaat het in de meeste gevallen om.
Het wordt een uitdaging voor iedereen om op een goede manier met de nieuwe mogelijkheden om te gaan. Komt er ooit een dag waarop we met weemoed terugblikken op het oude driefontsinternet?
Categorieën: Ontwerp, Typografie, Opinies, Webomgeving,
Over titels en witruimte
3 mei 2009•Op het web is het vaak wat behelpen wanneer het op typografie aankomt. Letters en teksten worden door de verschillende browsers en platformen anders weergegeven. En zowat elke tekst is dan nog eens vrij updatebaar door de webmaster. Als ontwerper is het dan ook moeilijk om webtekst voor elke eindgebruiker met zekerheid mooi vorm te geven.
Neem nu even de titel van dit heel eenvoudig ontwerp voor een nieuwspagina:
De titel ziet er goed uit. Maar wat als een klant via het contentmanagementsysteem van zijn site een langere titel ingeeft? Dan kan er wel eens een typografisch probleempje optreden:
Zoals je ziet verschuift het laatste woord van de titel naar een nieuwe regel. Omdat dat laatste woord heel kort is, bestaat die regel uit teveel witruimte. De titel staat daardoor helemaal niet meer mooi en is minder makkelijk te lezen.
Een oplossing
Shaun Inman schreef al in 2006 een makkelijk te implementeren php-functie die het probleem gedeeltelijk oplost door een harde spatie (non-breaking space) tussen de laatste twee woorden van de titel te plaatsen. Die zorgt er voor dat die twee altijd op dezelfde regel blijven. Het resultaat zie je hieronder:
Ongetwijfeld veel beter. Alleen kan het in bepaalde gevallen ook minder goede resultaten opleveren. Als het laatste woord lang genoeg is zoals in het voorbeeld hieronder, dan is het soms niet nodig om de harde spatie te gebruiken die je in het voorbeeld ziet toegepast:
Uiteraard is die laatste titel niet per sé slecht gezet, maar ik hou niet zo van de vele witruimte op beide regels. Ook de volgende situaties komen wel eens voor:
In dit laatste voorbeeld is de tweede regel langer dan de eerste regel en dat is natuurlijk best helemaal te vermijden: het lijken twee titels te zijn, of een titel en een onderschrift.
Een aanpassing
Eén van mijn laatste projecten was het ontwerpen en ontwikkelen van een nieuwswebsite waar dagelijks meerdere artikels gepost worden. Omdat ik vrij veel met een van de bovenstaande titelproblemen te kampen had, heb ik een kleine en eenvoudige aanpassing aan Inmans php-functie toegevoegd.
Ze laat me toe om een parameter op te geven: bestaat het laatste woord uit minder dan x-aantal tekens dan wordt er automatisch een harde spatie tussen het laatste en het voorlaatste woord geplaatst. Is het laatste woord een lang woord dan kan het dus eventueel alleen op de laatste regel staan.
Ik heb het gevoel dat dit in de meeste gevallen een mooier gezette titel oplevert. Het aantal tekens kan ik hoger instellen wanneer de kop veel ruimte in de breedte inneemt en lager wanneer de titel in een smalle ruimte gezet is.
Wil je het zelf eens proberen op je website? Download gerust de php-functie of de ExpressionEngine plugin. Extra suggesties of aanpassingen zijn trouwens meer dan welkom.
Categorieën: ExpressionEngine, Ontwerp, Typografie, Opinies,
Websites testen in Internet Explorer 6, 7 en 8
20 mar 2009•Gisteren heeft Microsoft versie 8 van Internet Explorer uitgebracht. Het zal dan ook niet zo heel erg lang meer duren vooraleer een groot deel van de surfers overschakelt naar IE8. En dat is goed nieuws uiteraard. De browser gaat een pak beter om met de huidige webstandaarden dan elke vorige versie.
Maar elke medaille heeft een keerzijde, vooral voor een webdesigner dan. Elke browser heeft zo zijn eigen kuren en elke versie durft wel eens een webpagina op een andere manier weergeven. Een websiteontwerp dat er perfect uitziet in IE7 kan er totaal verdraaid uitzien op IE6.
En je mag er natuurlijk helemaal zeker van zijn dat niet iedereen met de laatste nieuwe versie van Internet Explorer zal surfen. Op Windows surfen heel wat mensen nog met IE6 en IE7. Maar een groot deel van de Windowsgebruikers gebruikt ook Firefox, Chrome, Safari of Opera als standaard browser. En dan hebben we het nog niet over Macintoshgebruikers gehad: weer andere browsers in een andere omgeving.
Websites testen in verschillende browsers
Als ik als webdesigner een website ontwerp dan is het dus noodzakelijk dat ik die website kan zien zoals de gebruikers die gaan zien en beleven. Er gaat dus heel wat testwerk aan vooraf op de verschillende browsers en systemen. Zelf werk ik op een Mac waarop Safari, Firefox en Opera is geïnstalleerd. Elke website wordt uitvoerig geoptimaliseerd voor deze browsers. Daarnaast heb ik Parallels Desktop geïnstalleerd dat me toelaat om Windows XP te draaien op dezelfde computer. Zo kan ik mijn websites gelukkig ook testen en optimaliseren voor Windowsgebruikers. En dat zowel in Chrome, Firefox, Opera, Safari en Internet Explorer.
Multiple IE
Alleen laat Microsoft je niet zomaar toe om de verschillende versies van Internet Explorer naast elkaar te gaan installeren. Als je dus IE8 installeert, dan zal je IE7 nergens meer terugvinden. Maar via een programmaatje genaamd Multiple IE lukt het wél. Ik draaide er vroeger al Internet Explorer 6 en 7 mee naast elkaar, maar nu lukt het dus ook voor IE8. Hier is wat ik daarvoor heb ondernomen:
- Installeer Multiple IE en daarmee meteen Internet Explorer 6 (en elke vroegere versie als je dat wil).
- Open IE7, download en installeer IE8. Internet Explorer 7 is nu automatisch van je computer verwijderd. Maar dankzij Multiple IE zou IE6 nog altijd beschikbaar moeten zijn.
- Download en installeer de standalone versie van IE7.
Internet Explorer 6, 7 en 8 naast elkaar!
Multiple IE zorgt er nu voor dat je zonder problemen Internet Explorer 6, 7 en 8 naast elkaar kan draaien. Dat is uitstekend nieuws voor iedereen die websites maakt natuurlijk. Je kan je klant een website voorschotelen die er goed zal uitzien voor elke gebruiker, ongeacht het systeem en de browser waarmee die gebruiker surft.
Categorieën: Webomgeving,
Een kleine suggestie voor Safari 4
11 mar 2009•Apple heeft vorige week een publieke bètaversie van Safari 4 op de wereld losgelaten. En dus veert de wereld van webdesigners, vormgevers en Macgebruikers even op.
Onderwerp van discussie is vooral de vernieuwde plaatsing van de tabs zoals je in de screenshot hieronder kan zien. Maar daar ga ik het niet over hebben gezien er al voldoende inkt over is gevloeid.
Wachtwoordbeheer
Ik wil wel even een ander onderdeel van de browser uitlichten: dat van het wachtwoordbeheer. Als je net als mezelf door de jaren heen al heel wat online identiteiten hebt verzameld, dan is het een zegen wanneer de browser die gebruikersnaam-wachtwoordcombinatie voor je bijhoudt. Maar de manier waarop Safari dat doet stoort me een beetje.
Stel je het volgende voor: je surft naar een forum waar je een nieuw onderwerp wil starten. Aanmelden is daarvoor noodzakelijk maar het forum heb je al een tijdje niet meer bezocht en dus is het even gissen naar de gebruikersnaam en het wachtwoord waarmee je je indertijd op deze website registreerde.
Je vult in wat je denkt dat juist is en klikt op de Inloggen knop. Hierop stelt Safari je voor je gebruikersnaam-wachtwoordcombinatie te bewaren. Op zich behulpzaam natuurlijk, alleen weet je niet of je ingevulde gegevens wel correct zijn. Safari heeft nu eenmaal de vervelende eigenschap om het loginverzoek pas te verzenden nadat je een antwoord hebt gegeven op zijn prangende vraag. Nu zijn er twee mogelijke verwenselijke scenario’s:
1. Je twijfelt en kiest voor Niet bewaren
Het loginverzoek wordt verzonden naar de website. Je kan inloggen dus de gegevens blijken correct te zijn. Uitstekend nieuws. Alleen heeft Safari je logingegevens uiteraard niet bewaard. Bij het volgende forumbezoek word je dus met hetzelfde probleem geconfronteerd.
2. Je twijfelt maar kiest toch voor Bewaren
Het loginverzoek wordt verzonden maar blijkt fout te zijn. Vervelend want als je wegsurft dan houdt Safari nu wel de foutieve logingegevens bij. Als je volgende week opnieuw op deze website terechtkomt dan staat daar mooi de verkeerde gebruikersnaam-paswoordcombinatie ingevuld voor je.
Toegegeven: je kan die bewaarde gegevens wissen of aanpassen via het voorkeurenmenu van Safari, maar wie houdt zich daar echt mee bezig?
Firefox
De meest elegante oplossing bestaat al een tijdje in Firefox: wanneer je op de Inloggen knop drukt dan wordt het loginverzoek meteen verzonden naar de website. Ondertussen verschijnt bovenaan een balkje dat je vraagt of je de zopas ingevoerde gebruikersnaam-wachtwoordcombinatie wil bewaren.
Als het inloggen succesvol blijkt dan kan je gewoon op Onthouden klikken. En anders klik je op Nooit voor deze website of Niet nu natuurlijk. Eenvoudig maar duidelijk én gebruiksvriendelijk.
Laten dat nu net twee begrippen zijn die Safari hoog in het vaandel draagt.
Categorieën: Opinies, Webomgeving,
Waarschuw je Internet Explorer 6 gebruikers
22 feb 2009•Een groeiend aantal drukbezochte Noorse websites raadt sinds kort alle Internet Explorer 6 gebruikers aan te upgraden naar een moderne browser. Ze doen dat via een duidelijke waarschuwing die enkel die — weliswaar slinkende — groep gebruikers treft.
Now we’re talking! Internet Explorer 6 kwam op de markt in augustus 2001. In internettermen is dat een eeuwigheid geleden. De browser is hopeloos verouderd, maakt gebruikers kwetsbaar voor allerhande digitale rotzooi en neemt een serieus loopje met webstandaarden. Het web zonder IE6 zou om vele redenen een betere plaats zijn.
Vandaar een oproep aan mijn collega webdesigners: laat ons de Belgische Internet Explorer 6 gebruikers van hetzelfde laken een pak geven via een upgradeboodschap op zoveel mogelijk Belgische websites. Upgraden naar een nieuwere versie van hun browser kunnen ze gratis en ze hebben er alleen maar gewin mee.
Code voor een upgradeboodschap
Hoe toon je een boodschap enkel aan gebruikers van IE6 of lager? Het kan eenvoudig via een zogenaamde conditional comment. Alles wat tussen de code in vierkante haken staat is alleen voor het oog van die surfers zichtbaar:
<!--[if lte IE 6]>
<div id="ie6waarschuwing">
<h4>Een belangrijke waarschuwing</h4>
<p>Je gebruikt momenteel een erg oud programma (of <em>browser</em>) om deze website te bezoeken.
Het is voor je eigen veiligheid en gebruiksgemak raadzaam je browser te upgraden of een nieuwe browser te installeren.
De laatste nieuwe versie van Internet Explorer kan je gratis installeren via <a href="http://www.microsoft.com/windows/downloads/ie/getitnow.mspx">deze pagina op de Microsoft website</a>.
Daarnaast kan je er ook voor opteren een gratis en uitstekend alternatief voor Internet Explorer te installeren: <a href="http://www.mozilla.com/firefox/">Firefox</a>, <a href="http://www.opera.com/">Opera</a> of <a href="http://www.apple.com/safari/">Safari</a> bijvoorbeeld. Zeker doen!</p>
</div>
<![endif]-->
Zoals je ziet werd het blokje code in een div geplaatst en daardoor is het makkelijk vorm te geven via css.
Verspreid de boodschap!
Hoe meer sites zo’n boodschap laten zien hoe hoger het effect natuurlijk. Dus bloggers start het bloggen, twitteraars start het twitteren en ontwikkelaars start het coderen. Via Wolfr’s oorspronkelijke Goodbye IE6 blogpost kwamen we te weten dat webdesigners en/of bloggers Netlash, Lensco.be, Audience, MouseOver, Norio, Cubus en Ardville alvast meedoen. Hopelijk breidt de lijst snel uit. Laat zeker iets weten als je mee doet!
En euh… ben je zelf één van die 20% surfende Belgen die in een hoekje achter een kamerplant wel eens durft te surfen met een archaïsche browser uit het stenen internettijdperk? Dan weet je wat je te doen staat: hier is de link met upgradeinformatie. Of je kan natuurlijk één van de vele gratis en uitstekende alternatieven uitproberen.
Categorieën: Opinies, Webomgeving,
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,
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