<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.1.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Reacties op: Do-it-yourself Interfaces</title>
	<link>http://blog.finalist.com/2008/04/28/do-it-yourself-interfaces/</link>
	<description>Nederlandse blog over software ontwikkeling</description>
	<pubDate>Sun, 06 Jul 2008 19:27:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.1.3</generator>

	<item>
		<title>By: Auke van Leeuwen</title>
		<link>http://blog.finalist.com/2008/04/28/do-it-yourself-interfaces/#comment-18802</link>
		<author>Auke van Leeuwen</author>
		<pubDate>Mon, 28 Apr 2008 16:38:28 +0000</pubDate>
		<guid>http://blog.finalist.com/2008/04/28/do-it-yourself-interfaces/#comment-18802</guid>
					<description>Goed artikel en begrijp (tot op zekere hoogte misschien) het hele verhaal achter Gestalt ook wel. Maar de conclusie "kunnen direct toegepast worden ... met minimale inspanning" zie ik niet helemaal voor me. Hoe ga je daar practisch mee om dan? Het ontdekken van fouten in interfaces is vaak niet zo moeilijk: je gebruikt ze en na verloop van tijd ga je je ergens aan ergeren. Het probleem met het direct toepassen is dat je heel hard moet nadenken over wat mensen later misschen gaat irriteren *en* er ook nog een goede oplossing voor moet bedenken. 

Overigens gaat dat voornamelijk over punt 1 en 2. Punt 3 vind ik iets practischer.</description>
		<content:encoded><![CDATA[<p>Goed artikel en begrijp (tot op zekere hoogte misschien) het hele verhaal achter Gestalt ook wel. Maar de conclusie &#8220;kunnen direct toegepast worden &#8230; met minimale inspanning&#8221; zie ik niet helemaal voor me. Hoe ga je daar practisch mee om dan? Het ontdekken van fouten in interfaces is vaak niet zo moeilijk: je gebruikt ze en na verloop van tijd ga je je ergens aan ergeren. Het probleem met het direct toepassen is dat je heel hard moet nadenken over wat mensen later misschen gaat irriteren *en* er ook nog een goede oplossing voor moet bedenken. </p>
<p>Overigens gaat dat voornamelijk over punt 1 en 2. Punt 3 vind ik iets practischer.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Marco Plaisier</title>
		<link>http://blog.finalist.com/2008/04/28/do-it-yourself-interfaces/#comment-18855</link>
		<author>Marco Plaisier</author>
		<pubDate>Fri, 02 May 2008 07:25:01 +0000</pubDate>
		<guid>http://blog.finalist.com/2008/04/28/do-it-yourself-interfaces/#comment-18855</guid>
					<description>Laat ik vooropstellen dat dit hele simpele principes zijn die natuurlijk nooit een goed ontwerp kunnen vervangen. 

Laat ik een concreet voorbeeldje geven over het toepassen van Gestalt principes. Deze principes komen bijvoorbeeld erg van pas bij het opdelen van pagina's in logische groepen. In vrijwel alle enterprise software zitten een paar pagina's waar de gebruiker data kan invoeren; de primaire invoerschermen. Deze schermen zijn vaak directe weergaves van de tabellen uit de onderliggende database. Er zijn twee kenmerken:
1. Ieder data-element wordt weergegeven als label - input (button, checkbox, veld, etc.)
2. Meerdere data-elementen kunnen samen gegroepeerd worden (bijvoorbeeld tot klantgegevens of producteigenschappen)
Door nu de gestaltprincipes toe te passen op dit type schermen kun je aangeven welke elementen bij elkaar horen. Zet de data-elementen die bij klantgegevens horen dicht bij elkaar en zet de volgende groep er verder vanaf (Proximity). Houd de labels dicht bij het corresponderende input-element (ook Proximity). Het is nogal voor de hand liggend, maar het maakt een interface echt beter bruikbaar. 
Een voorbeeld Common Fate vind je in webapplicaties met frames. In een frame wordt het menu getoond en in een ander de 'content'. De content kan vaak scrollen, maar het menu niet. Dit maakt direct duidelijk wat bij elkaar hoort (dit wordt primair gedaan met behulp van kleurverschillen tussen het menu en de content en door de borders te tonen; het is maar een voorbeeld).</description>
		<content:encoded><![CDATA[<p>Laat ik vooropstellen dat dit hele simpele principes zijn die natuurlijk nooit een goed ontwerp kunnen vervangen. </p>
<p>Laat ik een concreet voorbeeldje geven over het toepassen van Gestalt principes. Deze principes komen bijvoorbeeld erg van pas bij het opdelen van pagina&#8217;s in logische groepen. In vrijwel alle enterprise software zitten een paar pagina&#8217;s waar de gebruiker data kan invoeren; de primaire invoerschermen. Deze schermen zijn vaak directe weergaves van de tabellen uit de onderliggende database. Er zijn twee kenmerken:<br />
1. Ieder data-element wordt weergegeven als label - input (button, checkbox, veld, etc.)<br />
2. Meerdere data-elementen kunnen samen gegroepeerd worden (bijvoorbeeld tot klantgegevens of producteigenschappen)<br />
Door nu de gestaltprincipes toe te passen op dit type schermen kun je aangeven welke elementen bij elkaar horen. Zet de data-elementen die bij klantgegevens horen dicht bij elkaar en zet de volgende groep er verder vanaf (Proximity). Houd de labels dicht bij het corresponderende input-element (ook Proximity). Het is nogal voor de hand liggend, maar het maakt een interface echt beter bruikbaar.<br />
Een voorbeeld Common Fate vind je in webapplicaties met frames. In een frame wordt het menu getoond en in een ander de &#8216;content&#8217;. De content kan vaak scrollen, maar het menu niet. Dit maakt direct duidelijk wat bij elkaar hoort (dit wordt primair gedaan met behulp van kleurverschillen tussen het menu en de content en door de borders te tonen; het is maar een voorbeeld).</p>
]]></content:encoded>
				</item>
</channel>
</rss>
