<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Sitestone &#187; webdesign</title>
	<atom:link href="http://www.sitestone.nl/category/weblog/webdesign/feed" rel="self" type="application/rss+xml" />
	<link>http://www.sitestone.nl</link>
	<description>Webdesign and webdevelopment</description>
	<lastBuildDate>Sat, 05 Dec 2009 07:55:12 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Interactief is een betekenisloze term</title>
		<link>http://www.sitestone.nl/weblog/webdesign/2008/06/04/interactief-is-een-betekenisloze-term</link>
		<comments>http://www.sitestone.nl/weblog/webdesign/2008/06/04/interactief-is-een-betekenisloze-term#comments</comments>
		<pubDate>Wed, 04 Jun 2008 14:19:04 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[Interaction Design]]></category>
		<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/?p=139</guid>
		<description><![CDATA[Gerry McGovern schrijft op zijn site een interessant stuk waarin hij uitlegt waarom je website &#8220;interactiever&#8221; maken niet de juiste strategie is. Zijn belangrijkste argument: de term interctief is in de context van een website betekenisloos. Een website is per definitie al interactief, omdat je als bezoeker actief rondklikt op en tussen websites. Bovendien gaat [...]]]></description>
			<content:encoded><![CDATA[<p>Gerry McGovern schrijft op zijn site een <a href="http://giraffeforum.com/wordpress/2008/05/25/interactive-is-a-meaningless-word/">interessant stuk</a> waarin hij uitlegt waarom je website &#8220;interactiever&#8221; maken niet de juiste strategie is. Zijn belangrijkste argument: de term interctief is in de context van een website betekenisloos. Een website is per definitie al interactief, omdat je als bezoeker actief rondklikt op en tussen websites.</p>
<p>Bovendien gaat het bezoekers van je website niet om interactie, maar om het zo snel mogelijk bereiken van hun doel. Hoe eerder dat doel bereikt is, hoe beter. En dat terwijl het succes van een site vaak gemeten wordt aan de hand van de tijd die mensen er doorbrengen. Hoe langer hoe beter. Maar dat is dus eerder ongekeerd.</p>
<blockquote cite="http://giraffeforum.com/wordpress/2008/05/25/interactive-is-a-meaningless-word/"><p>Making your websites more interactive is a meaningless strategy. Make your website more useful instead.</p></blockquote>
<p>Zijn stuk is natuurlijk bewust wat provocerend opgeschreven, zo zwart wit als hij het stelt is het niet. Maar de volgende keer dat iemand van marketing roept dat de site &#8220;lekker interactief&#8221; moet worden, is het wellicht wel raadzaam het advies van Gerry in je achterhoofd te houden. </p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/webdesign/2008/06/04/interactief-is-een-betekenisloze-term/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Waarom je nog geen Ajax moet gebruiken</title>
		<link>http://www.sitestone.nl/weblog/2008/04/26/waarom-je-nog-geen-ajax-moet-gebruiken</link>
		<comments>http://www.sitestone.nl/weblog/2008/04/26/waarom-je-nog-geen-ajax-moet-gebruiken#comments</comments>
		<pubDate>Sat, 26 Apr 2008 17:01:22 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[Toegankelijkheid]]></category>
		<category><![CDATA[Webstandaarden]]></category>
		<category><![CDATA[webdesign]]></category>
		<category><![CDATA[weblog]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/?p=138</guid>
		<description><![CDATA[Dat de hype van Web 2.0 &#8211; wat dat ook precies moge zijn &#8211; nog niet voorbij is, mag duidelijk zijn. Sterker nog, die trein raast snel voort en op zijn weg wordt alles wat in de weg staat verpulverd en opzij geschoven. We weten allemaal dat een stuurloze trein die eenmaal op stoom is [...]]]></description>
			<content:encoded><![CDATA[<p>Dat de hype van Web 2.0 &#8211; wat dat ook precies moge zijn &#8211; nog niet voorbij is, mag duidelijk zijn. Sterker nog, die trein raast snel voort en op zijn weg wordt alles wat in de weg staat verpulverd en opzij geschoven. We weten allemaal dat een stuurloze trein die eenmaal op stoom is niet of nauwelijks te stoppen is. </p>
<p>Een specifiek onderdeel van de trend is het gebruik van Ajax. Die term is in het leven geroepen door Jesse James Garrett, al weer een paar jaar geleden in <a href="http://adaptivepath.com/ideas/essays/archives/000385.php">dit artikel</a>. In feite was Ajax geen compleet nieuwe technologie, maar de toenemende bekendheid ermee en vooral ook de ontwikkeling van betere browsers hebben er voor gezorgd dat het gebruik van Ajax enorm toegenomen is.</p>
<p>Net als met veel andere <em>nieuwe</em> dingen, wil iedereen het hebben. Maakt niet uit of het echt nodig is. Alle bijkomende problemen worden niet gezien of genegeerd. E&#233;n zo&#8217;n probleem is toegankelijkheid. Want het gebruik van Ajax kan misschien wel voor meer gebruiksgemak van websites en web applicaties zorgen, dat de toegankelijkheid van sites er vaak onder lijdt is zeker.</p>
<p>In feite komt het er vaak op neer dat je pech hebt als je geen goed zichtsvermogen hebt, geen muis gebruikt, geen goede motoriek hebt of geen javascript ondersteuning hebt. James Edwards maakt zich daar &#8211; terecht &#8211; boos over en dat zet hij mooi neer in het artikel <a href="http://dev.opera.com/articles/view/stop-using-ajax/">Stop using Ajax</a> op de site van Opera Developer community. Zijn belangrijkste punten:</p>
<blockquote cite="http://dev.opera.com/articles/view/stop-using-ajax/"><p>In summary, these are my points:</p>
<p>   1. I&#8217;m not saying Ajax is bad, I&#8217;m saying it&#8217;s immature<br />
   2. I&#8217;m not saying never use Ajax, I&#8217;m saying don&#8217;t use it for the sake of it, and try to avoid it for now, instead sticking to accessible alternatives</p>
<p>When Ajax comes of age I&#8217;ll be cheering as loudly as anyone. And I&#8217;ll be working towards that goal and looking for solutions myself. But until that day comes, I intend to stick to proven, standards-based and accessible tools &#8211; not sketchy, proprietary and inaccessible toys. </p></blockquote>
<p>Kortom, Ajax is nog volop in ontwikkeling en laten we de technologie vooral niet gebruiken omdat het zo hip en nieuw is. Verlies de toegankelijkheid van je sites niet uit het oog. Laten we niet vergeten dat het oorspronkelijke idee van het web juist was universele toegankelijkheid te bieden, onafhankelijk van welke browser of welk apparaat dan ook. </p>
<p>Er zijn gelukkig mensen die het belangrijk vinden dat een website of webapplicatie zo toegankelijk mogelijk gebouwd wordt. Helaas staan daar tegenover diegenen die er weinig van begrepen hebben of zelfs totaal geen belang aan toegankelijkheid hechten. Om &#233;&#233;n van de reacties op het artikel te citeren:</p>
<blockquote><p>
It is not financially responsible to engineer your entire system just to accommodate a few cripples.<br />
..<br />
Do.Not.Care<br />
..<br />
To put it more clear, accessibility isn&#8217;t a problem, being blind, deaf, or armless is.
</p></blockquote>
<p>Naast het feit dat diegene die dit zegt kennelijk niet begrijpt waar het om gaat bij toegankelijkheid, is het feit dat het hem niets kan schelen dat bepaalde groepen uitgesloten worden toch ook wel triest te noemen.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/2008/04/26/waarom-je-nog-geen-ajax-moet-gebruiken/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Microformats</title>
		<link>http://www.sitestone.nl/weblog/webdesign/2008/03/26/microformats</link>
		<comments>http://www.sitestone.nl/weblog/webdesign/2008/03/26/microformats#comments</comments>
		<pubDate>Wed, 26 Mar 2008 08:20:16 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[Internet]]></category>
		<category><![CDATA[Toegankelijkheid]]></category>
		<category><![CDATA[webdesign]]></category>
		<category><![CDATA[microformats]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/webdesign/2008/03/26/microformats</guid>
		<description><![CDATA[Microformats zijn kleine stukjes code die het makkelijker moeten maken om bepaalde gegevens op websites leesbaar en uitwisselbaar te maken. Voor mens en machine. Denk aan contactgegevens op een website. Of de gegevens in een kalender. Gegevens die je &#8211; vaak &#8211; makkelijk uitwissselbaar wilt maken. Alhoewel ze op dit moment nog niet veel gebruikt [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://nl.wikipedia.org/wiki/Microformat">Microformats</a> zijn kleine stukjes code die het makkelijker moeten maken om bepaalde gegevens op websites leesbaar en uitwisselbaar te maken. Voor mens en machine. Denk aan contactgegevens op een website. Of de gegevens in een kalender. Gegevens die je &#8211; vaak &#8211; makkelijk uitwissselbaar wilt maken.</p>
<p>Alhoewel ze op dit moment nog niet veel gebruikt worden, zal dat in de toekomst zeker veranderen.</p>
<p>Naarvoren heeft recent <a href="http://naarvoren.nl/artikel/microformats/">een artikel</a> over Microformats gepubliceerd. Verder is hier nog een lijst met zo&#8217;n <a href="http://www.virtualhosting.com/blog/2008/microformats-university-100-articles-and-resources/">100 informatiebronnen over microformats</a> te vinden. Tot slot is er nog de website van microformats zelf, <a href="http://microformats.org/">microformats.org</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/webdesign/2008/03/26/microformats/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Breadcrumbs</title>
		<link>http://www.sitestone.nl/weblog/usability/2007/05/09/breadcrumbs</link>
		<comments>http://www.sitestone.nl/weblog/usability/2007/05/09/breadcrumbs#comments</comments>
		<pubDate>Wed, 09 May 2007 18:37:41 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[User Interface Design]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/usability/2007/05/09/breadcrumbs</guid>
		<description><![CDATA[Een al heel lang bestaand fenomeen, maar volgens usability guru Jakob Nielsen steeds belangrijker voor website gebruikers: de breadcrumbs. 
]]></description>
			<content:encoded><![CDATA[<p>Een al heel lang bestaand fenomeen, maar volgens usability guru Jakob Nielsen steeds belangrijker voor website gebruikers: <a href="http://www.useit.com/alertbox/breadcrumbs.html">de breadcrumbs</a>. </p>
<blockquote><p>Breadcrumbs gebruiken een enkele lijn tekst om de lokatie van de pagina in de site hierarchie te tonen. Alhoewel secundair, is deze navigatietechniek in steeds grotere mate nuttig voor gebruikers <cite>Jakob Nielsen</cite></p></blockquote>
<p>Toeval wil dat ik net op de <em>re-align</em> van deze website deze broodkruimeltjes toegevoegd heb. Voor een relatief kleine website als deze zal het nut beperkt zijn. Maar, zoals Jakob ook aangeeft, er zijn eigenlijk geen nadelen aan het invoegen van de breadcrumbs. De ruimte die ze innemen is zo beperkt, dat er ook grafisch gezien weinig bezwaren zijn. </p>
<p>Kortom: toevoegen aan je site! Belangrijk is daarbij wel dat de structuur van je site al goed in elkaar zit. Dus produkten > meubels > stoelen is logisch en bruikbaar voor een gebruiker. Home > site > items > id4 niet. </p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/usability/2007/05/09/breadcrumbs/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Flash wel de moeite waard?</title>
		<link>http://www.sitestone.nl/weblog/webdesign/2007/04/23/flash-wel-de-moeite-waard</link>
		<comments>http://www.sitestone.nl/weblog/webdesign/2007/04/23/flash-wel-de-moeite-waard#comments</comments>
		<pubDate>Mon, 23 Apr 2007 16:06:17 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/webdesign/2007/04/23/flash-wel-de-moeite-waard</guid>
		<description><![CDATA[Een grote flash-banner vervangen door een gewoon banner plaatje met een paar links erin zorgde er voor dat het aantal mensen dat gelijk de homepage verliet met 28% daalde. ]]></description>
			<content:encoded><![CDATA[<p>Een grote flash-banner vervangen door een gewoon banner plaatje met een paar links erin zorgde er voor dat het aantal mensen dat gelijk de homepage verliet met 28% daalde, volgens <a href="http://www.grokdotcom.com/2007/04/05/is-it-worth-it-to-flash-your-customers/">grokdotcom</a>. Ik heb het rapport niet onder ogen gehad, maar de resultaten zijn wel interessant. </p>
<p>Wat wel interessant zou zijn om te weten is hoe klein en onopvallend je een Flash banner moet maken voordat die geen negatieve invloed meer heeft &#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/webdesign/2007/04/23/flash-wel-de-moeite-waard/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Waarom Flash?</title>
		<link>http://www.sitestone.nl/weblog/webdesign/2007/04/12/waarom-flash</link>
		<comments>http://www.sitestone.nl/weblog/webdesign/2007/04/12/waarom-flash#comments</comments>
		<pubDate>Thu, 12 Apr 2007 06:53:18 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/webdesign/2007/04/12/waarom-flash</guid>
		<description><![CDATA[Waarom sommige sites compleet in Flash gebouwd worden is me een raadsel. Hoe creatief het er ook uit ziet, hoe mooi de animaties ook zijn, voor de meeste websites werkt het gewoon niet. ]]></description>
			<content:encoded><![CDATA[<p>Waarom sommige sites compleet in Flash gebouwd worden is me een raadsel. Hoe creatief het er ook uit ziet, hoe mooi de animaties ook zijn, voor de meeste websites werkt het gewoon niet. </p>
<p>Een website bezoek ik met een doel. Ik wil wat specifieke informatie hebben of ben gewoon geinteresseerd in een onderwerp. Ik arriveer op de site en het eerste en enige wat ik te zien krijg is een tellertje of animatie die aangeeft dat het laden is begonnen. Of de boodschap die meldt dat ik alleen verder kan als ik plugin X en browser Y heb.</p>
<p>Nog erger is als er direct muziek begint te spelen. Met een beetje geluk is m&#8217;n internetverbinding snel genoeg, hebben ze de laadtijd beperkt gehouden en zie ik gelijk iets verschijnen. Als het een intro is en ze zijn vooruitdenkend geweest is er een mooi &#8220;skip intro&#8221; linkje waar ik dankbaar gebruik van maak. </p>
<p>Ben ik eindelijk zover dat ik de hoofdpagina te zien krijgt, begint het ontrafelen van de zo creatief bedachte navigatie. Rara, wat zouden de menuknopjes zijn? Met een beetje geluk gaan er niet al te veel dingen bewegen (&#8220;animeren&#8221;) als ik over de knopjes heen ga met m&#8217;n muis en kan ik redelijk vlot verder.</p>
<p>Als ik pech heb moet ik ook wachten op het laden van de volgende pagina. Of ik vervolgens wat nuttige informatie weet te vinden is de vraag. Als ze erg hun best gedaan heb is er nog wel wat tekst te zien, anders een paar animaties of filmpjes. Als ik al zover ben gekomen is het nu toch echt het moment dat ik afhaak en op zoek ga naar een andere site over het onderwerp.</p>
<p>Een voorbeeld? Neem nou de site over <a href="http://www.mulhollanddrive.com/" rel="nofollow">Mulhollanddrive</a>. Ik wilde alleen maar wat meer weten over de film, de regisseur en zijn andere films. Volgende keer maar gelijk naar het artikel op <a href="http://nl.wikipedia.org/wiki/David_Lynch">wikipedia</a>.  O ja, ik weet niet wat die twee popups waren op de site van Mulhollanddrive, maar laat die voortaan ook maar achterwege.</p>
<p><strong>Update 10 mei</strong>: Jared Spool ergert zich ook aan Flash splash pages. Hij geeft een <a href="http://www.uie.com/brainsparks/2007/05/09/the-doors-of-course/">mooi voorbeeld</a> van hoe het niet moet.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/webdesign/2007/04/12/waarom-flash/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Regels voor webdesigners</title>
		<link>http://www.sitestone.nl/weblog/webdesign/2007/04/04/regels-voor-webdesigners</link>
		<comments>http://www.sitestone.nl/weblog/webdesign/2007/04/04/regels-voor-webdesigners#comments</comments>
		<pubDate>Wed, 04 Apr 2007 08:04:56 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/webdesign/2007/04/04/regels-voor-webdesigners</guid>
		<description><![CDATA[Wat moet je vooral <strong>niet</strong> doen als je een website bouwt en je wilt ook nog geld kunnen verdienen met die website?]]></description>
			<content:encoded><![CDATA[<p>Wat moet je vooral <strong>niet</strong> doen als je een website bouwt en je wilt ook nog geld kunnen verdienen met die website? Josiah Cole beschrijft het perfect in zijn post <a href="http://www.josiahcole.com/2007/02/14/a-webmasters-19-commandments/">19 Things NOT To Do When Building a Website</a> (engels). Erg leuk ook.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/webdesign/2007/04/04/regels-voor-webdesigners/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Wat maakt een interface gebruiksvriendelijk?</title>
		<link>http://www.sitestone.nl/weblog/usability/2007/03/24/wat-maakt-een-interface-gebruiksvriendelijk</link>
		<comments>http://www.sitestone.nl/weblog/usability/2007/03/24/wat-maakt-een-interface-gebruiksvriendelijk#comments</comments>
		<pubDate>Sat, 24 Mar 2007 09:38:11 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[usability]]></category>
		<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/usability/2007/03/24/wat-maakt-een-interface-gebruiksvriendelijk</guid>
		<description><![CDATA[Tantek Çelik’s beschrijft een aantal hypothesen over Interface Design in zijn “Three Hypotheses of Human Interface Design”. Met deze stellingen legt hij uit waarom de ene interface gebruiksvriendelijker is dan de andere.]]></description>
			<content:encoded><![CDATA[<p>Tantek Çelik’s beschrijft een aantal hypothesen over Interface Design in zijn “<a href="http://tantek.com/log/2007/02.html#d19t1813">Three Hypotheses of Human Interface Design</a>”. Met deze stellingen legt hij uit waarom de ene interface gebruiksvriendelijker is dan de andere. Hij noemt het nadrukkelijk stellingen in plaats van wetten, omdat de harde wetenschappelijk onderbouwing nog ontbreekt.</p>
<p>Desondanks zijn het een aantal goede punten die hij maakt, en is zijn artikel het lezen waard voor ieder die iets te maken heeft met Human Interface Design.<br />
<span id="more-76"></span></p>
<h3>Stelling 1: De cognitieve belasting is proportioneel aan het aantal kliks/toetsaanslagen/bewegingen</h3>
<p>Heel eenvoudig gezegd: hoe meer kliks, toetsaanslagen of bewegingen nodig is om een bepaalde taak uit te voeren, hoe belastender die is. En ook al is een taak helemaal niet zo ingewikkeld, elke vermindering van het aantal benodigde stappen maakt de taak prettiger om uit te voeren. <a href="weblog/usability/2007/02/01/hou-web-formulieren-kort?phpMyAdmin=6eQ-lwYdbL68I5tCp11Abp89JPb">Hou formulieren zo kort mogelijk</a>, daar komt het op neer.</p>
<h3>Stelling 2: De cognitieve belasting van een interface is proportioneel aan de traagheid van de interface</h3>
<p>Deze stelling draait om de snelheid waarmee een systeem of interface reageert op handelingen van de gebruiker. Mensen hebben een beperkte aandachtsspanne en hoe langer iemand moet wachten, hoe &#8220;zwaarder&#8221; de taak wordt.</p>
<p>Wat ook mee speelt is dat het voor een gebruiker prettiger aanvoelt als <em>hij</em> degene is die het tempo bepaalt, en niet het programma.</p>
<h3>Stelling 3: De gebruiksvriendelijkheid van een interface is omgekeerd gerelateerd aan de cognitieve belasting ervan</h3>
<p>Deze stelling bouwt voort op de vorige twee en verklaart waarom de cognitieve belasting van een interface de gebruiksvriendelijkheid ervan bepaalt. Hoe lager de cognitieve belasting van een interface, hoe meer gebruikers die zullen gebruiken en hoe vaker.</p>
<h3>Conclusies</h3>
<p>Zijn conclusies zijn helder. Misschien op het eerste gezicht voor de hand liggend, maar zolang er nog genoeg software- of webinterfaces ontworpen worden die zich niet aan die regels houden, kan het geen kwaad ze nog eens te benadrukken.</p>
<ul>
<li>Minimaliseer het aantal tekst velden tot het absolute minimum.</li>
<li>Minimaliseer het benodigde aantal kliks/toetsaanslagen/bewegingen om een taak uit te voeren.</li>
<li>Maak je interface zo &#8220;vlot/reactief&#8221; mogelijk. Dus minimaliseer de tijd dat een gebruiker moet wachten na elke actie van hem of haar.</li>
</ul>
<p><strong>Bron:</strong> <a href="http://tantek.com/log/2007/02.html#d19t1813">Three hypotheses of Human Interface Design, Tantek Çelik</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/usability/2007/03/24/wat-maakt-een-interface-gebruiksvriendelijk/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Scrollen niet langer een probleem</title>
		<link>http://www.sitestone.nl/weblog/usability/2006/12/28/scrollen-niet-langer-een-probleem</link>
		<comments>http://www.sitestone.nl/weblog/usability/2006/12/28/scrollen-niet-langer-een-probleem#comments</comments>
		<pubDate>Thu, 28 Dec 2006 16:11:03 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[usability]]></category>
		<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/usability/2006/12/28/scrollen-niet-langer-een-probleem</guid>
		<description><![CDATA[Onderzoek van Clicktale laat zien dat het grootste deel van de webdesigners webpagina's ontwerpen waar je op moet scrollen, dat het grootste deel van de bezoekers scrollt en dat een aanzienlijk deel daarvan helemaal naar beneden scrollt. ]]></description>
			<content:encoded><![CDATA[<p><a href="http://blog.clicktale.com/?p=19">Onderzoek van Clicktale</a> laat zien dat het grootste deel van de webdesigners webpagina&#8217;s ontwerpen waar je op moet scrollen, dat het grootste deel van de bezoekers scrollt en dat een aanzienlijk deel daarvan helemaal naar beneden scrollt. </p>
<p>Of je wel of niet pagina&#8217;s moet ontwerpen waarbij bezoekers moeten scrollen is al lange tijd onderwerp van discussie. Vaak wordt als argument t&#233;gen scrollen aangevoerd dat bezoekers van een website meestal niet scrollen en dat alle inhoud onderaan dus niet of nauwelijks aandacht krijgt. </p>
<p>Uit dit onderzoek blijkt echter dat 22% van de bezoekers tot helemaal onderaan scrolde. En dat was onafhankelijk van de lengte van de pagina. Dat geeft toch duidelijk aan dat het argument dat de onderkant van een lange pagina &#8216;toch niet gezien wordt&#8217; niet stand houdt. </p>
<h3>De vouw van de pagina</h3>
<p>Natuurlijk is het zo dat de inhoud boven de vouw van de pagina (het gedeelte wat direct zichtbaar is zonder scrollen) de meeste aandacht krijgt. Maar een volgende vraag is waar die vouw zich bevindt. Ook dat werd in dit onderzoek bekeken. </p>
<p>De resultaten geven aan dat de meest gebruikte hoogtes voor die vouw rond een drietal pieken liggen: 430, 600 en 860 pixels. Dat zijn precies de hoogtes die overeenkomen met beeldschermresoluties van 800&#215;600, 1024&#215;768 en 1280&#215;1024 pixels, na aftrek van wat ruimte voor de menubalken van de browser en het systeem. </p>
<p>De spreiding is erg groot. Nog geen 10% zit op 600 tot 610 pixels. Dat betekent dus eigenlijk dat je kunt ontwerpen wat je wilt, maar dat je voor niemand de exacte lokatie van de vouw kunt bepalen.</p>
<h3>Conclusies</h3>
<p>De conclusie die uit dit onderzoek te halen is, is dat het weinig zin heeft een webpagina te ontwerpen voor een bepaalde schermhoogte omdat er geen standaard hoogte is. Als er wel een scrolbar ontstaat is dat niet zo erg omdat gebruikers vaak wel zullen scrollen om de rest van de pagina te bekijken, al is het maar vluchtig. </p>
<p>Wat belangrijker lijkt, is de bezoeker een overzichtelijke pagina voor te schotelen, waarbij<br />
a) het duidelijk is dat er meer inhoud te zien is en<br />
b) die inhoud in duidelijke secties verdeeld is en daarmee makkelijk scanbaar is.</p>
<p>Natuurlijk is dit slechts een enkel onderzoek met een beperkte steekproef, maar desondanks zijn het interessante resultaten. In het <a href="http://blog.clicktale.com/?p=19">artikel</a> op de site van Clicktale is het onderzoek uitgebreider beschreven.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/usability/2006/12/28/scrollen-niet-langer-een-probleem/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Grootste webdesign blunders</title>
		<link>http://www.sitestone.nl/weblog/usability/2006/12/09/grootste-webdesign-blunders</link>
		<comments>http://www.sitestone.nl/weblog/usability/2006/12/09/grootste-webdesign-blunders#comments</comments>
		<pubDate>Sat, 09 Dec 2006 15:49:16 +0000</pubDate>
		<dc:creator>Matthijs Abeelen</dc:creator>
				<category><![CDATA[usability]]></category>
		<category><![CDATA[webdesign]]></category>

		<guid isPermaLink="false">http://www.sitestone.nl/weblog/usability/2006/12/09/grootste-webdesign-blunders</guid>
		<description><![CDATA[Vincent Flanders heeft de grootste website blunders van 1995-2015 op een rij gezet in zijn artikel <a href="http://www.webpagesthatsuck.com/biggest-mistakes-in-web-design-1995-2015.html">Biggest Mistakes in Web Design 1995-2015</a>.]]></description>
			<content:encoded><![CDATA[<p>Vincent Flanders heeft de grootste website design blunders op een rij gezet in zijn artikel <a href="http://www.webpagesthatsuck.com/biggest-mistakes-in-web-design-1995-2015.html">Biggest Mistakes in Web Design 1995-2015</a>.</p>
<p>Volgens hem zijn de grootste fouten die gemaakt worden bij het maken van een website:</p>
<ol>
<li>Geloven dat mensen om jou of je website geven</li>
<li>Het doel van de site is niet binnen 4 seconden duidelijk</li>
<li>Heilig geloof in webstandaarden</li>
<li>Design elementen gebruiken die je bezoekers in de weg zitten</li>
<li>Slechte navigatie</li>
<li>verborgen navigatie</li>
<li>Denken dat je website je complete marketingstrategie is</li>
<li>Je site bevat geen waardevolle informatie</li>
<li>Het doel van tekst vergeten</li>
<li>Te veel materiaal op een pagina</li>
<li>Webdesign verwarren met een magische truc</li>
<li>Flash misbruiken</li>
<li>Plaatjes verkeerd gebruiken</li>
<li>Je site met Frontpage maken</li>
</ol>
<p>Lees de toelichting en bekijk de voorbeelden in het <a href="http://www.webpagesthatsuck.com/biggest-mistakes-in-web-design-1995-2015.html">artikel</a>. Al is zo&#8217;n lijstje natuurlijk vrij arbitrair, op de meeste punten heeft hij wel gelijk!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sitestone.nl/weblog/usability/2006/12/09/grootste-webdesign-blunders/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
