<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Searching for the HIG&#8217;s Boson</title>
	<atom:link href="http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/feed" rel="self" type="application/rss+xml" />
	<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson</link>
	<description>The official blog of DayTime Software</description>
	<lastBuildDate>Wed, 03 Jun 2009 02:00:44 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Semi-Blog &#187; Blog Archive &#187; Apple Human Interface Guidelines Still Controversial</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-18</link>
		<dc:creator>Semi-Blog &#187; Blog Archive &#187; Apple Human Interface Guidelines Still Controversial</dc:creator>
		<pubDate>Tue, 03 Jul 2007 19:55:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-18</guid>
		<description>[...] from iTunes 7. And so the now infamous Apple Human Interface Guidelines (HIG) controversy continues:Searching for the HIG&#8217;s Bosun, at Daydream Blog  I&#8217;m learning that some of the things that I&#8217;ve always stood behind [...]</description>
		<content:encoded><![CDATA[<p>[...] from iTunes 7. And so the now infamous Apple Human Interface Guidelines (HIG) controversy continues:Searching for the HIG&#8217;s Bosun, at Daydream Blog  I&#8217;m learning that some of the things that I&#8217;ve always stood behind [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Infovore &#187; links for 2007-07-01</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-17</link>
		<dc:creator>Infovore &#187; links for 2007-07-01</dc:creator>
		<pubDate>Mon, 02 Jul 2007 07:53:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-17</guid>
		<description>[...] The Daydream Blog » Blog Archive » Searching for the HIG&#8217;s Boson Some nice, insightful commentary on the relevance of Apple&#8217;s Human Interface Guidelines in 2007. Good stuff, for anyone interested in interface design. (tags: mac os ui interface interaction design usability) [...]</description>
		<content:encoded><![CDATA[<p>[...] The Daydream Blog » Blog Archive » Searching for the HIG&#8217;s Boson Some nice, insightful commentary on the relevance of Apple&#8217;s Human Interface Guidelines in 2007. Good stuff, for anyone interested in interface design. (tags: mac os ui interface interaction design usability) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Cunningham</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-16</link>
		<dc:creator>Chris Cunningham</dc:creator>
		<pubDate>Sun, 01 Jul 2007 20:46:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-16</guid>
		<description>In paragraph 3 you mean &lt;i&gt;flouting&lt;/i&gt;. To flaunt something is to show it off. To flagrantly ignore something is to flout it.

 - Chrie</description>
		<content:encoded><![CDATA[<p>In paragraph 3 you mean <i>flouting</i>. To flaunt something is to show it off. To flagrantly ignore something is to flout it.</p>
<p> &#8211; Chrie</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: LKM</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-15</link>
		<dc:creator>LKM</dc:creator>
		<pubDate>Fri, 29 Jun 2007 11:08:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-15</guid>
		<description>Consistency means more than just &quot;looking the same.&quot; It also means that things that look similar should *behave* the same. For example, both Safari and the Finder have a &quot;back&quot; button which looks exactly the same. Consistent, right? No. It *behaves* inconsistently. Try this: Put a Finder window in the background and click its back button. The finder becomes active, but doesn&#039;t go back. Now try the same with Safari: The window becomes active, *and* the back button is triggered. It&#039;s an inconsisten behaviour, and it&#039;s one of the little things that make you uncomfortable because it your computer behaves a little bit different than how you think it should. It also makes you scared. If I click on this window, will something happen?

(This is admittedly a somewhat bad example because Safari and the Finder at least *show* you that one back button is active and the other isn&#039;t, but it&#039;s the first example that occured to me)

This is where consistency is important. Looks don&#039;t really matter too much. It doesn&#039;t matter whether your back button is a green arrow like in some versions of Firefox, or a black button with an arrow like in Safari and the Finder. What matters is that all back buttons behave the same so the user can get used to a behaviour, and trust that his actions always lead to the same reactions from the computer.</description>
		<content:encoded><![CDATA[<p>Consistency means more than just &#8220;looking the same.&#8221; It also means that things that look similar should *behave* the same. For example, both Safari and the Finder have a &#8220;back&#8221; button which looks exactly the same. Consistent, right? No. It *behaves* inconsistently. Try this: Put a Finder window in the background and click its back button. The finder becomes active, but doesn&#8217;t go back. Now try the same with Safari: The window becomes active, *and* the back button is triggered. It&#8217;s an inconsisten behaviour, and it&#8217;s one of the little things that make you uncomfortable because it your computer behaves a little bit different than how you think it should. It also makes you scared. If I click on this window, will something happen?</p>
<p>(This is admittedly a somewhat bad example because Safari and the Finder at least *show* you that one back button is active and the other isn&#8217;t, but it&#8217;s the first example that occured to me)</p>
<p>This is where consistency is important. Looks don&#8217;t really matter too much. It doesn&#8217;t matter whether your back button is a green arrow like in some versions of Firefox, or a black button with an arrow like in Safari and the Finder. What matters is that all back buttons behave the same so the user can get used to a behaviour, and trust that his actions always lead to the same reactions from the computer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sanjay Samani</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-14</link>
		<dc:creator>Sanjay Samani</dc:creator>
		<pubDate>Fri, 29 Jun 2007 10:30:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-14</guid>
		<description>There have been several mentions about scroll bars in the comments.  Again I would argue that the difference in look of scroll bars between Windows &amp; Mac and between Aqua and iTunes 7 does not detract from their usability.

Creating a new theme for an application to reflect its metaphor is not going to trip users up.  iTunes 7 is just ugly, not less usable as the user interaction is unchanged.

However there are issues with custom controls in terms of changing their behaviour (such as brushed metal window dragging) that can cause issues.  I think I may post another entry rather than just a comment on that though so I can give it some thought.</description>
		<content:encoded><![CDATA[<p>There have been several mentions about scroll bars in the comments.  Again I would argue that the difference in look of scroll bars between Windows &#038; Mac and between Aqua and iTunes 7 does not detract from their usability.</p>
<p>Creating a new theme for an application to reflect its metaphor is not going to trip users up.  iTunes 7 is just ugly, not less usable as the user interaction is unchanged.</p>
<p>However there are issues with custom controls in terms of changing their behaviour (such as brushed metal window dragging) that can cause issues.  I think I may post another entry rather than just a comment on that though so I can give it some thought.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sanjay Samani</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-13</link>
		<dc:creator>Sanjay Samani</dc:creator>
		<pubDate>Fri, 29 Jun 2007 10:25:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-13</guid>
		<description>Re: Travis Butler&#039;s comments

Travis, thanks for your comments.  I would argue that smart phones, VCR&#039;s and blinking clocks are examples of poor user interaction design and not a lack of consistency.

The two stalk Ford is a good example for consistency.  We used to have two cars at one point, each with two stalks but the controls were reversed.  However with cruise control, telephone controls and radio controls being incorporated into the steering wheel show if we are too rigid we can stifle innovation.  These changes make a compromise between consistency and proximity for the sake of improved safety.  The look of those stalks varying from car to car is not an issue.  Their relative layout can be an issue.  The iPhoto search box being in the bottom right rather than top right can make you pause in your workflow.  However absolute placement for specific controls within a window are not covered by the HIG.</description>
		<content:encoded><![CDATA[<p>Re: Travis Butler&#8217;s comments</p>
<p>Travis, thanks for your comments.  I would argue that smart phones, VCR&#8217;s and blinking clocks are examples of poor user interaction design and not a lack of consistency.</p>
<p>The two stalk Ford is a good example for consistency.  We used to have two cars at one point, each with two stalks but the controls were reversed.  However with cruise control, telephone controls and radio controls being incorporated into the steering wheel show if we are too rigid we can stifle innovation.  These changes make a compromise between consistency and proximity for the sake of improved safety.  The look of those stalks varying from car to car is not an issue.  Their relative layout can be an issue.  The iPhoto search box being in the bottom right rather than top right can make you pause in your workflow.  However absolute placement for specific controls within a window are not covered by the HIG.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fred Hamranhansenhansen</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-12</link>
		<dc:creator>Fred Hamranhansenhansen</dc:creator>
		<pubDate>Fri, 29 Jun 2007 06:03:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-12</guid>
		<description>The HIG guidelines only apply to office work. They are a relic that should be enjoyed in that context. It&#039;s beautiful literature, very thought-provoking, technically and culturally significant. The best thing to learn from it is user-centric design, putting yourself into the soft bunny slippers of a user of your app and making the app speak the user&#039;s language, not vice versa.

The interface guidelines that Logic Pro follows are those from the music and audio studio, not the computer. You control Logic Pro with musical instruments and mixing controllers (banks of programmable knobs and sliders and buttons, transport controls, jog wheel, etc) not a mouse. The interface conventions of music and audio predate the personal computer entirely. I learned audio mixing in the 1970&#039;s before I was 10 years old, it works the same in the current version of Logic Pro.</description>
		<content:encoded><![CDATA[<p>The HIG guidelines only apply to office work. They are a relic that should be enjoyed in that context. It&#8217;s beautiful literature, very thought-provoking, technically and culturally significant. The best thing to learn from it is user-centric design, putting yourself into the soft bunny slippers of a user of your app and making the app speak the user&#8217;s language, not vice versa.</p>
<p>The interface guidelines that Logic Pro follows are those from the music and audio studio, not the computer. You control Logic Pro with musical instruments and mixing controllers (banks of programmable knobs and sliders and buttons, transport controls, jog wheel, etc) not a mouse. The interface conventions of music and audio predate the personal computer entirely. I learned audio mixing in the 1970&#8217;s before I was 10 years old, it works the same in the current version of Logic Pro.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fred</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-11</link>
		<dc:creator>Fred</dc:creator>
		<pubDate>Fri, 29 Jun 2007 04:56:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-11</guid>
		<description>&gt;The last time I saw a long strip on the side of my screen with 
&gt;a rectangle and two arrows, I dragged it up and down to see 
&gt;different parts of my document. The next time I encounter a 
&gt;scroll bar, I’ll do the same thing. If scroll bars were not 
&gt;generally consistent in appearance and function, I would have &gt;a difficult time to

I regularly get tripped up by clever Flash(TM) designers who decide to redesign the scroll bar. For whatever reason, Flash makes it easy to design scroll bars that are NOT consistent in appearance. I for one find random triangle-like objects floating in vague proximity to possibly truncated text with no vertical throughline unintuitive. Yet these opaque every-Flash-app-makes-you-relearn-navigation approaches seem to proliferate...</description>
		<content:encoded><![CDATA[<p>&gt;The last time I saw a long strip on the side of my screen with<br />
&gt;a rectangle and two arrows, I dragged it up and down to see<br />
&gt;different parts of my document. The next time I encounter a<br />
&gt;scroll bar, I’ll do the same thing. If scroll bars were not<br />
&gt;generally consistent in appearance and function, I would have &gt;a difficult time to</p>
<p>I regularly get tripped up by clever Flash(TM) designers who decide to redesign the scroll bar. For whatever reason, Flash makes it easy to design scroll bars that are NOT consistent in appearance. I for one find random triangle-like objects floating in vague proximity to possibly truncated text with no vertical throughline unintuitive. Yet these opaque every-Flash-app-makes-you-relearn-navigation approaches seem to proliferate&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Kerr &#124; links for 2007-06-29</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-10</link>
		<dc:creator>Brian Kerr &#124; links for 2007-06-29</dc:creator>
		<pubDate>Fri, 29 Jun 2007 04:23:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-10</guid>
		<description>[...] The Daydream Blog &#124; Searching for the HIG&#8217;s Boson (tags: apple mac metaphors-and-other-failures party-like-it&#8217;s-1984 hig human interface guidelines) [...]</description>
		<content:encoded><![CDATA[<p>[...] The Daydream Blog | Searching for the HIG&#8217;s Boson (tags: apple mac metaphors-and-other-failures party-like-it&#8217;s-1984 hig human interface guidelines) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel Bernstein</title>
		<link>http://www.daytimesoftware.com/blog/2007/06/searching-for-the-higs-boson/comment-page-1#comment-9</link>
		<dc:creator>Joel Bernstein</dc:creator>
		<pubDate>Fri, 29 Jun 2007 03:38:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.daytimesoftware.com/blog/?p=6#comment-9</guid>
		<description>I fully agree that metaphors need only be consistent to the subject they&#039;re referencing, not to each other. Unfortunately, the vast majority of user interaction is idiomatic, simply because most computing tasks have no real-world equivalent.

Even the most basic metaphors have some idiomatic component. On the surface, my computer&#039;s Trash Can is a metaphor for the trash can I have in my house. However, while rummaging through my real-world garbage to find the half-eaten tuna sandwich I threw out last week is generally discouraged, on my computer that&#039;s the entire point. I can cut and paste pictures and news clippings in real life, but I can&#039;t paste 25 copies without a trip to Kinkos.

These subtle differences are impossible to infer from the metaphor itself; they must be learned through experience and applied idiomatically. This is perfectly fine. Human beings are remarkably good at idiomatic thought, so good that most of the time, we take it for granted.

Idiomatic reasoning is deeply rooted in the principle of consistency. The last time I saw a long strip on the side of my screen with a rectangle and two arrows, I dragged it up and down to see different parts of my document. The next time I encounter a scroll bar, I&#039;ll do the same thing. If scroll bars were not generally consistent in appearance and function, I would have a difficult time to 

Now, you are absolutely correct that purely *visual* consistency is becoming less important, and Chris Ryland pinpoints the source of the change: the web. 

Buttons on the internet look like all sorts of things, while still maintaining some consistent platonic quality of &quot;buttonness&quot;. Having been immunized by the mess of visual cues on the web, most users these days can spot that buttonness, even if the button doesn&#039;t look 100% identical to the ones they encountered yesterday.

This doesn&#039;t mean that *design* consistency is passé, just that appearances don&#039;t need to be absolutely identical in order to maintain high levels of idiom recognition. Even though some Mac applications were Aqua, and some were Brushed Metal, they were designed pretty much the same way. Nobody panicked the first time they saw a brushed metal button and it didn&#039;t look exactly like the aqua buttons they were used to. They clicked on it, it behaved exactly like the buttons they were used to, and they unconsciously filed away another data point for the next time they encounter an odd-shaped button.

The people still whining about visual consistency on the Mac are either treating outdated UI guidelines as though they were holy gospel, or they&#039;re trying to hide their purely aesthetic complaints behind the usability banner to gain public support. To be honest, I don&#039;t have much sympathy for them either way.</description>
		<content:encoded><![CDATA[<p>I fully agree that metaphors need only be consistent to the subject they&#8217;re referencing, not to each other. Unfortunately, the vast majority of user interaction is idiomatic, simply because most computing tasks have no real-world equivalent.</p>
<p>Even the most basic metaphors have some idiomatic component. On the surface, my computer&#8217;s Trash Can is a metaphor for the trash can I have in my house. However, while rummaging through my real-world garbage to find the half-eaten tuna sandwich I threw out last week is generally discouraged, on my computer that&#8217;s the entire point. I can cut and paste pictures and news clippings in real life, but I can&#8217;t paste 25 copies without a trip to Kinkos.</p>
<p>These subtle differences are impossible to infer from the metaphor itself; they must be learned through experience and applied idiomatically. This is perfectly fine. Human beings are remarkably good at idiomatic thought, so good that most of the time, we take it for granted.</p>
<p>Idiomatic reasoning is deeply rooted in the principle of consistency. The last time I saw a long strip on the side of my screen with a rectangle and two arrows, I dragged it up and down to see different parts of my document. The next time I encounter a scroll bar, I&#8217;ll do the same thing. If scroll bars were not generally consistent in appearance and function, I would have a difficult time to </p>
<p>Now, you are absolutely correct that purely *visual* consistency is becoming less important, and Chris Ryland pinpoints the source of the change: the web. </p>
<p>Buttons on the internet look like all sorts of things, while still maintaining some consistent platonic quality of &#8220;buttonness&#8221;. Having been immunized by the mess of visual cues on the web, most users these days can spot that buttonness, even if the button doesn&#8217;t look 100% identical to the ones they encountered yesterday.</p>
<p>This doesn&#8217;t mean that *design* consistency is passé, just that appearances don&#8217;t need to be absolutely identical in order to maintain high levels of idiom recognition. Even though some Mac applications were Aqua, and some were Brushed Metal, they were designed pretty much the same way. Nobody panicked the first time they saw a brushed metal button and it didn&#8217;t look exactly like the aqua buttons they were used to. They clicked on it, it behaved exactly like the buttons they were used to, and they unconsciously filed away another data point for the next time they encounter an odd-shaped button.</p>
<p>The people still whining about visual consistency on the Mac are either treating outdated UI guidelines as though they were holy gospel, or they&#8217;re trying to hide their purely aesthetic complaints behind the usability banner to gain public support. To be honest, I don&#8217;t have much sympathy for them either way.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
