<?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>IT Solutions Blog &#187; Design Guidelines</title>
	<atom:link href="http://www.michaelgaigg.com/blog/category/design-guidelines/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.michaelgaigg.com/blog</link>
	<description>Web Design Guidelines and Tips</description>
	<lastBuildDate>Fri, 30 Jul 2010 03:10:55 +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>Design Guidelines: Print Stylesheet</title>
		<link>http://www.michaelgaigg.com/blog/2009/09/08/design-guidelines-print-stylesheet/</link>
		<comments>http://www.michaelgaigg.com/blog/2009/09/08/design-guidelines-print-stylesheet/#comments</comments>
		<pubDate>Tue, 08 Sep 2009 20:34:30 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[code sample]]></category>
		<category><![CDATA[contrast]]></category>
		<category><![CDATA[coyier]]></category>
		<category><![CDATA[cross-browser]]></category>
		<category><![CDATA[css]]></category>
		<category><![CDATA[design guideline]]></category>
		<category><![CDATA[eric meyer]]></category>
		<category><![CDATA[hardcopy]]></category>
		<category><![CDATA[legible]]></category>
		<category><![CDATA[multiple ie]]></category>
		<category><![CDATA[print]]></category>
		<category><![CDATA[stylesheet]]></category>
		<category><![CDATA[walsh]]></category>
		<category><![CDATA[webcredible]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=480</guid>
		<description><![CDATA[One of the most elegant techniques in web design is the use of a print stylesheet to control the style of a webpage on a hardcopy. Being so easy and cheap it is by far the most undervalued technique out there. 
Often overseen bonuses are 
<ul>
<li><strong>adding copyright statements or thank you notes</strong>, </li>
<li>controlling which elements should not be seen (remove menu, commercials,...) and </li>
<li>in general <strong>ensure that the printed page is legible</strong> (contrast especially for links, fonts, ...).</li>
</ul>

<img src="http://www.michaelgaigg.com/blog/wp-content/uploads/2009/09/print-stylesheet.jpg" alt="Results of applying a print stylesheet to the page" title="Results of applying a print stylesheet to the page" width="500" height="359" class="frame" />

<h2>Design Guideline for a Print Stylesheet</h2>

<ol>
<li>Make page legible
<ul>
<li>Use serif font family (e.g. Georgia)</li>
<li>Use points (e.g. 12pt)</li>
<li>Ensure good contrast (e.g. color: #000; background: #FFF)</li>
</ul>
</li>
<li>Maximize paper use (e.g. width: 100%)</li>
<li>Hide elements not relevant to print (e.g. display: none)</li>
<li>Add content relevant to print (e.g. spell out links, thank you note)</li>
<li>Use correct markup to reduce amount of styling (e.g. h1, h2,...)</li>
</ol>

<h2>How it works</h2>
Embed an extra stylesheet designed for print media into the page. 

<code class="html">&#60;link rel="stylesheet" type="text/css" media="print" href="print.css" /&#62;
</code>

This stylesheet takes effect when a user invokes the print function of the browser and overrules style elements in other stylesheets on the page.

Then either provide a button or link that triggers a javascript function to print the page or have the user go through the browser's menu, even print preview would show you the expected layout already.

<code class="html">&#60;a href="#" onclick="window.print();return false;"&#62;Print page&#60;/a&#62;
</code>

I know, evil javascript, but hey, if turned on it works cross-browser (except IE6 with <a href="http://tredosoft.com/Multiple_IE">multiple IE versions</a> installed).

<h2>Code sample</h2>
I recognize that many samples can be found on the web but I also found them incomplete in many cases. I don't claim to be compete myself, but I really like with what I came up with and most of all <strong>would like to hear your comments and feedback</strong> or even better references or links where you applied it to.

<a href="http://www.michaelgaigg.com/blog/download/print_stylesheet.zip">Download sample code</a>

<h3>index.htm</h3>
<code class="html">&#60;html&#62;
&#60;head&#62;
&#60;style type="text/css" media="all"&#62;
   @import "main.css";
&#60;/style&#62;
&#60;link rel="stylesheet" type="text/css" media="print" href="print.css" /&#62;
&#60;/head&#62;
&#60;body&#62;
&#60;div id="wrapper"&#62;
	&#60;div id="statement"&#62;Legal statement and thank you note.&#60;/div&#62;
	&#60;div id="header"&#62;Header&#60;/div&#62;
	&#60;div id="content"&#62;Content plus &#60;a href="http://link.com/"&#62;Link&#60;/a&#62;&#60;/div&#62;
	&#60;div id="footer"&#62;Footer&#60;/div&#62;
&#60;/div&#62;
&#60;/body&#62;
&#60;/html&#62;
</code>

<h3>main.css</h3>
<code class="css">
/**
 Elements 
 */
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-weight: inherit;
	font-style: inherit;
	font-size: 100%;
	font-family: inherit;
	vertical-align: baseline;
}
/* remember to define focus styles! */
:focus {
	outline: 0;
}
body {
	line-height: 1;
	color: black;
	background: white;
	font-family: Arial, Helvetica, sans-serif;
}
ol, ul {
	list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
	border-collapse: separate;
	border-spacing: 0;
}
caption, th, td {
	text-align: left;
	font-weight: normal;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: "";
}
blockquote, q {
	quotes: "" "";
}
/**
 Classes 
 */
/** 
 IDs 
 */
#wrapper {
	background: #FFFFFF none repeat scroll 0%;
	margin: 0pt auto;
	width: 600px;
}
#header {
	border: 1px solid #CCC;
	margin: 5px;
	padding: 5px;
}
#content {
	border: 1px solid #CCC;
	background: #EEE;
	margin: 5px;
	padding: 5px;
	height: 200px;
}
#footer {
	border: 1px solid #CCC;
	margin: 5px;
	padding: 5px;
}
a:link, a:visited {
	border-bottom:1px dotted;
	color:#AE4F0C;
	font-weight:bold;
	text-decoration:none;
}
a:visited {
	color:#333333;
}
a:hover, a:focus {
	border-bottom-style:solid;
	color:#D03900;
}
a:focus {
	/*background:#FFFFCC none repeat scroll 0%;*/
}
#statement {
	display: none;
}
</code>

<h3>print.css</h3>
<code class="css">
body {
	font-family: Georgia, serif;
	background: #FFF;
	color: #000;
	font-size: 12pt;
}
#wrapper, #content {
	width: auto;
	height: auto;
	margin: 0 5%;
	padding: 0;
	border: 0;
	float: none !important;
	color: #000;
	background: transparent none;
}
#content {
	margin: 10px;
}
#header, #menu, #sidebar, #footer, .noprint {
	display: none;
}
#statement {
	display: block;
	border: 1px solid #666;
	padding: 10px;
}
a:link, a:visited {
	color: #781351;
	background: transparent;
	text-decoration: underline;
}
a:link:after, a:visited:after {
	content: " [" attr(href) "] ";
}
</code>

<strong>References:</strong>
<ul>
	<li>Coyier, C. (2008, 3 3). CSS-Tricks Finally Gets A Print Stylesheet. Retrieved 9 1, 2009, from CSS Tricks: <a href="http://css-tricks.com/css-tricks-finally-gets-a-print-stylesheet/">http://css-tricks.com/css-tricks-finally-gets-a-print-stylesheet/</a></li>
	<li>Meyer, E. (2002, 5 10). CSS Design: Going to Print. Retrieved 9 1, 2009, from A List Apart: <a href="http://www.alistapart.com/articles/goingtoprint/">http://www.alistapart.com/articles/goingtoprint/</a></li>
<li>Walsh, D. (2008, 2 27). Optimize Your Links For Print Using CSS — Show The URL. Retrieved 9 1, 2009, from david walsh blog: <a href="http://davidwalsh.name/optimize-your-links-for-print-using-css-show-url">http://davidwalsh.name/optimize-your-links-for-print-using-css-show-url</a></li>
<li>webcredible. (2007, 9). Print stylesheet - the definitive guide. Retrieved 9 1, 2009, from webcredible: <a href="http://www.webcredible.co.uk/user-friendly-resources/css/print-stylesheet.shtml">http://www.webcredible.co.uk/user-friendly-resources/css/print-stylesheet.shtml</a></li>
</ul>]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2009/09/08/design-guidelines-print-stylesheet/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Transactional Email</title>
		<link>http://www.michaelgaigg.com/blog/2009/06/30/design-guidelines-transactional-email/</link>
		<comments>http://www.michaelgaigg.com/blog/2009/06/30/design-guidelines-transactional-email/#comments</comments>
		<pubDate>Tue, 30 Jun 2009 19:02:01 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[confirmation messages]]></category>
		<category><![CDATA[email]]></category>
		<category><![CDATA[jacob nielsen]]></category>
		<category><![CDATA[recognizable]]></category>
		<category><![CDATA[relevant]]></category>
		<category><![CDATA[reputation]]></category>
		<category><![CDATA[spam]]></category>
		<category><![CDATA[transactional email]]></category>
		<category><![CDATA[user confidence]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=424</guid>
		<description><![CDATA[<img src="http://www.michaelgaigg.com/blog/wp-content/uploads/2009/06/email.jpg" alt="Feedback request to change my address" title="Feedback request to change my address" width="300" height="124" class="size-full wp-image-426" />
I usually try to balance positive and negative critique, but sometimes - and especially when I see really bad things - I just cannot help but mention it here as well. Latest 'incident' was a harmless email to my local government body with the intent to <strong>change my address</strong>. 

<h2>Optimize your webpage to avoid emails</h2>
The reason I sent the email in the first place was that I couldn't find any form or document that would allow me to change my address online.

So, I tried to locate a tab or menu entry called 'contact' or similar (no luck), checked the footer (no luck) and eventually found the complete address with generic email (chief-on-duty@government) next to the logo - which showed me once more that users tend to look for certain <strong>elements in common places rather than even prominent locations</strong>.
Anyway, I figured this email address would do it and I shot my note to change my address. Here is the (automated) response:

<blockquote>Dear mail sender! The employee you have selected is out of office and can be reached again on June 29th, inquires will not be processed.</blockquote>

Wow, now what? Should I send my message again in two days (which I probably will)? Can I trust these guys to fix my address at all? Seems like there is no organization behind it. I have no chance to stop by because I'm out of the country but maybe I need to pick up the phone and call instead, how annoying. No big deal for a simple change of address but this slip can <strong>potentially damage your image and seriously reduce trust</strong> for other sorts of inquires, right?

Update: Today I received a very nice and personal response telling me that my address was updated. I will in return send a nice and personal note pointing out above issues. Let's hope for the best.

But now, here are the

<h2>Design Guidelines for transactional email</h2>

<ol>
<li>Avoid being mistaken for spam.</li>
<li>Enhance company’s reputation and increase users’ confidence.</li>
<li>Be precise and answer all relevant questions.</li>
<li>Provide recognizable brand name in ‘From’ field.</li>
<li>Add clearly distinguishable transaction to ‘From’ field.</li>
<li>Keep ‘From’ field shorter than 20 characters.</li>
<li>Explicitely relate ‘Subject’ field to a customer-initiated transaction.</li>
<li>Avoid unnecessary message sequences (e.g. transaction confirmation + shipping confirmation; order summary not necessary anymore).</li>
<li>Start the ‘Content’ with the information that matters most.</li>
</ol>

<h2>Solution to my inquiry above</h2>
First of all, unless the whole department was moved, closed or is on vacation I would not expect a vacation response mail for an email sent to a generic address. Secondly, automated responses are ok if they state that a human response will follow promptly, usually within 24 hours.

What would have been a better response? Maybe: "Thank you, your inquiry has been received and will be processed by our team within the next couple of days. You will be notified once your request is processed or if we have further questions." And then some more specific information like contact names with alternative email and/or telephone numbers could follow. Maybe even some links that answer common questions or point the requester to common documents, be creative.

<h2>What are your experiences with transactional email?</h2>
How do you handle transactional email on your company webpage? What are your experiences? Any lessons learned (the hard way)?

<h2>References</h2>
<ul>
	<li>Nielsen, J.; Transactional Email and Confirmation Messages; <a href="http://www.useit.com/alertbox/confirmation-email.html" target="_blank">http://www.useit.com/alertbox/confirmation-email.html</a></li>
</ul>]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2009/06/30/design-guidelines-transactional-email/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Error Messages</title>
		<link>http://www.michaelgaigg.com/blog/2009/04/10/design-guidelines-error-messages/</link>
		<comments>http://www.michaelgaigg.com/blog/2009/04/10/design-guidelines-error-messages/#comments</comments>
		<pubDate>Fri, 10 Apr 2009 19:16:46 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[cingular]]></category>
		<category><![CDATA[constructive]]></category>
		<category><![CDATA[did you mean]]></category>
		<category><![CDATA[error]]></category>
		<category><![CDATA[error messages]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[polite]]></category>
		<category><![CDATA[precise]]></category>
		<category><![CDATA[visible]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=387</guid>
		<description><![CDATA[Just some weeks ago I wrote about <a href="http://www.michaelgaigg.com/blog/2009/03/design-guidelines-404-error-pages/">Design Guidelines for 404 Pages</a>. Closely related are Error Messages in general, and believe me, they <strong>will save your life</strong>. That's why you need to get them right!

<h2>Why bad error message can hurt your company</h2>

Error messages are like saying "You are stupid", or "Come on old fart, you still don't get it?" - and that's bad, it's almost like constantly telling your kid "No, no, no". Be <strong>preventive</strong>, <strong>defensive</strong> and avoid Design Bloopers like the the one at <a href="http://www.wireless.att.com/cell-phone-service/welcome/" target="_blank">Cingular</a>: Having tried to log into my account the following error message appears "My Account is Currently Closed". Can you imagine the horror that bubbles up and the thoughts of who to call (but how?)? As it turns out Cingular was just maintaining their server and the only flawed thing was the error message. Is it possible to measure how much this little flaw will hurt the company?

<img src="http://www.michaelgaigg.com/blog/wp-content/uploads/2009/04/misleading-dashboard-error-message.jpg" alt="Misleading and almost terrifying error message at Cingular" title="misleading dashboard error message" class="frame" />

<h2>Defensive Web Design</h2>

<img src="http://www.michaelgaigg.com/blog/wp-content/uploads/2009/04/google-prevent-error-messag.jpg" alt="Prevent error messages whenever possible; e.g. &#34;did you mean&#34; at google.com" title="google-prevent-error-message" width="268" height="137" class="size-full wp-image-389" />

The beauty of usability design is to think of ways to prevent showing error messages at the first place. The most prominent example is probably <a href="http://www.google.com">Google</a>. Have you ever seen an error message on Google? How great is the "Did you mean:" function... I even use it day by day as a spell checker, like I use google images to visualize words I didn't know (do you know what a <a href="http://images.google.com/images?hl=en&#038;safe=active&#038;um=1&#038;newwindow=1&#038;sa=1&#038;q=vicuna&#038;aq=f&#038;oq=">vicuna </a>is?).

<h2>Design Guidelines: Error Messages</h2>

<ol>
<li><strong>Avoid</strong> error messages if possible.</li>
<li>Explicit indication that something has gone wrong</li>
<li><strong>Human-readable</strong> language</li>
<li><strong>Polite phrasing</strong> without blaming the user or imply that user is stupid or is doing something wrong</li>
<li><strong>Precise</strong> descriptions of exact problems</li>
<li><strong>Constructive</strong> advice on how to fix the problem</li>
<li>Visible and highly <strong>noticeable</strong>, both in terms of message itself and how it indicates which dialogue element users must repair</li>
<li>Preserve as much of the user’s work as possible</li>
<li>Reduce the work of correcting the error (e.g. list of possibilities)</li>
<li>Hypertext links may be used to connect a concise error message to a page with additional background information or explanation of the problem.</li>
</ol>

<h2>Did you ever encounter a 'special' error message?</h2>
Send me a screenshot and/or tell me the story behind it. ]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2009/04/10/design-guidelines-error-messages/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: 404 Error Pages</title>
		<link>http://www.michaelgaigg.com/blog/2009/03/09/design-guidelines-404-error-pages/</link>
		<comments>http://www.michaelgaigg.com/blog/2009/03/09/design-guidelines-404-error-pages/#comments</comments>
		<pubDate>Mon, 09 Mar 2009 17:25:15 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[404]]></category>
		<category><![CDATA[broken link]]></category>
		<category><![CDATA[custom]]></category>
		<category><![CDATA[error]]></category>
		<category><![CDATA[guidelines]]></category>
		<category><![CDATA[mistyped url]]></category>
		<category><![CDATA[page]]></category>
		<category><![CDATA[request]]></category>
		<category><![CDATA[response code]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=335</guid>
		<description><![CDATA[<img src="http://www.michaelgaigg.com/blog/wp-content/uploads/2009/03/404.jpg" alt="404 error" title="404 error" width="344" height="194" />

The 404 or Not Found error message is an <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes" target="_blank">HTTP standard response code</a> indicating that the client was able to communicate with the server but either the server could not find what was requested, or it was configured not to fulfill the request and did not reveal the reason why.

<h2>Possible Reasons</h2>

Possible reasons for 404 error pages can be
<ul>
	<li>click on a broken link</li>
	<li>the page has been deleted</li>
	<li>mistyped URL</li>
</ul>
Depending on your internet service provider (ISP) the standard 404 page can vary greatly in terms of visual display and information on the error itself. In order to not loose visitors it's strongly suggested to create a custom 404 page. A <a href="http://www.alistapart.com/articles/amoreuseful404" target="_blank">good custom 404 page</a> will <strong>help people find the information</strong> they're looking for, as well as <strong>providing other helpful content</strong> and encouraging them to explore your site further.
<h2>Design Guidelines for 404 Pages</h2>

A good 404 error page conveys a right message and leads the visitor to where he intends to go:

<ol>
	<li>Tell visitors clearly that the page they're looking for can't be found.</li>
	<li>Use language that is easy to understand, non-technical, friendly and inviting.</li>
<li>Display an error message that explains what could have gone wrong</li>
	<li>Offer means to recover (e.g. list site's naming conventions, spell check functionality, most common proplems).</li>
<li>Offer links to other important links of the site (e.g. most popular, homepage, FAQ).</li>
	<li>Provide a way for users to report a broken link (easy form, email the webmaster)</li>
	<li>Do not display ads.</li>
<li>Avoid redirection of 301 and 302.</li>
</ol>

<h2>Other Considerations</h2>
No matter <a href="http://www.hongkiat.com/blog/49-nice-and-creative-error-404-pages/" target="_blank">how beautiful and useful your custom 404 page</a>, you probably don't want it to appear in Google search results. In order to prevent 404 pages from being indexed by Google and other search engines, make sure that your webserver returns an actual 404 HTTP status code when a missing page is requested.

<h2>Got a nice 404 page?</h2>

Send me screenshots of your 404 error pages - I'd love to see them!]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2009/03/09/design-guidelines-404-error-pages/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Radio Buttons versus Checkboxes</title>
		<link>http://www.michaelgaigg.com/blog/2009/02/23/design-guidelines-radio-buttons-versus-checkboxes/</link>
		<comments>http://www.michaelgaigg.com/blog/2009/02/23/design-guidelines-radio-buttons-versus-checkboxes/#comments</comments>
		<pubDate>Mon, 23 Feb 2009 17:11:05 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[accesskey]]></category>
		<category><![CDATA[checkbox]]></category>
		<category><![CDATA[code sample]]></category>
		<category><![CDATA[guidelines]]></category>
		<category><![CDATA[label]]></category>
		<category><![CDATA[radio button]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=302</guid>
		<description><![CDATA[<img class="size-full wp-image-309" title="Design guidelines for checkboxes versus Radio buttons" src="http://www.michaelgaigg.com/blog/wp-content/uploads/2009/02/design-guidelines-checkbox.jpg" alt="Design guidelines for checkboxes" width="200" height="143" />

Users hate formulars, it is work to them. Filling out forms on the web is no different, that's why getting web form design right is difficult, even simple forms can be challenging.

A good start is using the correct form element, or in the words of this blog entry <strong>to know when to use Radio Buttons versus Checkboxes</strong>:]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2009/02/23/design-guidelines-radio-buttons-versus-checkboxes/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Breadcrumbs</title>
		<link>http://www.michaelgaigg.com/blog/2008/12/10/design-guidelines-breadcrumbs/</link>
		<comments>http://www.michaelgaigg.com/blog/2008/12/10/design-guidelines-breadcrumbs/#comments</comments>
		<pubDate>Wed, 10 Dec 2008 07:04:45 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[breadcrumbs]]></category>
		<category><![CDATA[brothers grimm]]></category>
		<category><![CDATA[current page]]></category>
		<category><![CDATA[example]]></category>
		<category><![CDATA[hansel and gretel]]></category>
		<category><![CDATA[hierarcy]]></category>
		<category><![CDATA[home]]></category>
		<category><![CDATA[horizontally]]></category>
		<category><![CDATA[implementation]]></category>
		<category><![CDATA[level]]></category>
		<category><![CDATA[pattern]]></category>
		<category><![CDATA[separator]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=208</guid>
		<description><![CDATA[Nobody wants to get eaten by a wicked witch and neither do Hansel and Gretel in the tale <a href="http://en.wikipedia.org/wiki/Hansel_and_Gretel" target="_blank">Hänsel und Gretel by the Brothers Grimm</a>. That's why the kids, as they are taken into the forest, leave little breadcrumbs behind so they can find their way home. I love the story (especially when the witch climbs into the oven to be baked) and the fact that Hansel and Gretel find their way home and see that the evil stepmother has died and everybody can live happily ever after.

Even though the metaphor of Hansel and Gretel is probably the origin of the term Breadcrumbs it is flawed because breadcrumbs do not represent the actual path the user has taken to any given page, but instead the optimal path from the homepage to the current page in the hierarchy.

Fairytale aside, here is how Breadcrumbs should be designed and implemented: <a href="http://www.michaelgaigg.com/blog/2008/12/design-guidelines-breadcrumbsdesign-guidelines-breadcrumbs/">Read complete blog entry</a>]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2008/12/10/design-guidelines-breadcrumbs/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: &#8216;About Us&#8217; Page</title>
		<link>http://www.michaelgaigg.com/blog/2008/11/14/design-guidelines-about-us-page/</link>
		<comments>http://www.michaelgaigg.com/blog/2008/11/14/design-guidelines-about-us-page/#comments</comments>
		<pubDate>Sat, 15 Nov 2008 03:53:03 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[about]]></category>
		<category><![CDATA[about us]]></category>
		<category><![CDATA[address]]></category>
		<category><![CDATA[credibility]]></category>
		<category><![CDATA[design guideline]]></category>
		<category><![CDATA[details]]></category>
		<category><![CDATA[fact sheet]]></category>
		<category><![CDATA[homepage]]></category>
		<category><![CDATA[inverted pyramid]]></category>
		<category><![CDATA[jacob nielsen]]></category>
		<category><![CDATA[link]]></category>
		<category><![CDATA[summary]]></category>
		<category><![CDATA[tagline]]></category>
		<category><![CDATA[trust]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=163</guid>
		<description><![CDATA[There are many reasons for improving the usability of your 'About Us' page. Unfortunately many companies, especially bigger and well-known companies, tend to underestimate the value that comes from a well-designed 'About Us' page or simply assume that there is no need to explain themselves to their users.

The 'About Us' page helps to establish and re-enforce <strong>Trust and Credibility</strong>. Users of different backgrounds may need to know <strong>who is behind the content or service</strong>. Should I invest in this company? Apply for a job? Write an article about their service? Order a product?

The best news over all is: a simple link on your homepage is <strong>cheap and easy</strong> and the benefits of a clean and well-structured 'About Us' page outweigh many times the effort of creating it.]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2008/11/14/design-guidelines-about-us-page/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Pagination</title>
		<link>http://www.michaelgaigg.com/blog/2008/11/06/design-guidelines-pagination/</link>
		<comments>http://www.michaelgaigg.com/blog/2008/11/06/design-guidelines-pagination/#comments</comments>
		<pubDate>Fri, 07 Nov 2008 03:20:29 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[affordance]]></category>
		<category><![CDATA[code sample]]></category>
		<category><![CDATA[creative]]></category>
		<category><![CDATA[css]]></category>
		<category><![CDATA[design guideline]]></category>
		<category><![CDATA[example]]></category>
		<category><![CDATA[gallery]]></category>
		<category><![CDATA[html]]></category>
		<category><![CDATA[navigation]]></category>
		<category><![CDATA[pagination]]></category>
		<category><![CDATA[rules]]></category>
		<category><![CDATA[template]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[user-friendly]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=115</guid>
		<description><![CDATA[One thing I hear from visual designers over and over again: 'Those Usability guys destroy our creative possibilities'. While I understand the desire to live in complete design heaven I want to strongly emphasize the need for a <strong>usable design heaven</strong>. Every thing in this world has a certain affordance, i.e. it affords to do something which we need to design for. A chair for example affords to be seated on, designers are therefore constrained to design chairs in a way that supports the human body while sitting. Now, does that restrict creativity in chair design? Without doubt NO, numerous examples show that thousands of different chairs exist but all have one common goal: <strong>to support the task on hand</strong> - which is seating a person!]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2008/11/06/design-guidelines-pagination/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Content</title>
		<link>http://www.michaelgaigg.com/blog/2008/10/20/design-guidelines-content/</link>
		<comments>http://www.michaelgaigg.com/blog/2008/10/20/design-guidelines-content/#comments</comments>
		<pubDate>Mon, 20 Oct 2008 19:09:17 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[active voice]]></category>
		<category><![CDATA[bulleted lists]]></category>
		<category><![CDATA[content]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[design guideline]]></category>
		<category><![CDATA[essence]]></category>
		<category><![CDATA[evolution of language]]></category>
		<category><![CDATA[google trends]]></category>
		<category><![CDATA[guideline]]></category>
		<category><![CDATA[information scent]]></category>
		<category><![CDATA[inverted pyramid]]></category>
		<category><![CDATA[jacob nielsen]]></category>
		<category><![CDATA[message]]></category>
		<category><![CDATA[scannable text]]></category>
		<category><![CDATA[trends]]></category>
		<category><![CDATA[word count]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=50</guid>
		<description><![CDATA[When writing content for the web it is essential to <strong>speak the language of your users</strong>. Become a word detective, use google trends. Words are the basic elements of links, get them precicely right to provide strong information scent. Identify trends, don't invent them. Look at the evolution of language.

Stop 'waving' on your webpage. Get to the essence of the message! Always remember that the <strong>user is in charge</strong>, the user is impatient, nasty, demanding, in a hurry and in control to spend its time somewhere else. Online marketing is about giving attention (versus offline marketing is about getting attention).
]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2008/10/20/design-guidelines-content/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Design Guidelines: Links</title>
		<link>http://www.michaelgaigg.com/blog/2008/10/15/design-guidelines-links/</link>
		<comments>http://www.michaelgaigg.com/blog/2008/10/15/design-guidelines-links/#comments</comments>
		<pubDate>Wed, 15 Oct 2008 20:21:01 +0000</pubDate>
		<dc:creator>Michael Gaigg</dc:creator>
				<category><![CDATA[Design Guidelines]]></category>
		<category><![CDATA[alertbox]]></category>
		<category><![CDATA[blue]]></category>
		<category><![CDATA[color]]></category>
		<category><![CDATA[command links]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[font style]]></category>
		<category><![CDATA[gerry mcgovern]]></category>
		<category><![CDATA[guideline]]></category>
		<category><![CDATA[jacob nielsen]]></category>
		<category><![CDATA[menu]]></category>
		<category><![CDATA[navigation]]></category>
		<category><![CDATA[separator]]></category>
		<category><![CDATA[spacing]]></category>
		<category><![CDATA[target]]></category>
		<category><![CDATA[underline]]></category>
		<category><![CDATA[Useful Links]]></category>
		<category><![CDATA[visited]]></category>
		<category><![CDATA[visualizing links]]></category>
		<category><![CDATA[Web Design]]></category>

		<guid isPermaLink="false">http://www.michaelgaigg.com/blog/?p=44</guid>
		<description><![CDATA[<h2>Design Guidelines for Links</h2>
<ol>
<li>Color and underline link text (exceptions include lists of links like a navigation menu)</li>
<li>Reserve underlining for links (do not underline text that is not a link)</li>
<li>Use different colors for visited and unvisited links (e.g. shades of blue)</li>
<li>Avoid using color for text unless it is a link and never use blue for non-text links (even if your links are not blue)</li>
<li>Avoid changing the font style on mouse over</li>
<li>Avoid tiny text for links</li>
<li>Use appropriate spacing between links or use a clear separator</li>
<li>Use links primarily for navigation between pages</li>
<li>Link text must be describe the target as short and precise as possible AND hold this promise!</li>
</ol>
]]></description>
		<wfw:commentRss>http://www.michaelgaigg.com/blog/2008/10/15/design-guidelines-links/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
