<?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: 48 Hours</title>
	<atom:link href="http://nslog.com/2004/02/21/48_hours/feed" rel="self" type="application/rss+xml" />
	<link>http://nslog.com/2004/02/21/48_hours</link>
	<description>The Weblog of Erik J. Barzeski</description>
	<lastBuildDate>Tue, 07 Feb 2012 16:40:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: mpt</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7690</link>
		<dc:creator>mpt</dc:creator>
		<pubDate>Wed, 08 Sep 2004 07:37:26 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7690</guid>
		<description>Er, right. Meanwhile, in the real world, I stopped devoting all my spare time to Mozilla when they stopped producing browsers for Mac OS 9, the only OS I was running at the time. It&#039;s amusing to think that the powers that be abandoned Mac OS 9 support &lt;em&gt;because&lt;/em&gt; I was using Mac OS 9, but I don&#039;t think that&#039;s very likely.
</description>
		<content:encoded><![CDATA[<p>Er, right. Meanwhile, in the real world, I stopped devoting all my spare time to Mozilla when they stopped producing browsers for Mac OS 9, the only OS I was running at the time. It's amusing to think that the powers that be abandoned Mac OS 9 support <em>because</em> I was using Mac OS 9, but I don't think that's very likely.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jackie</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7689</link>
		<dc:creator>Jackie</dc:creator>
		<pubDate>Fri, 27 Feb 2004 16:50:26 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7689</guid>
		<description>MPT has been a whiny little sod ever since he was effectively frozen out of the Mozilla UI community for being a ... well, whiny little sod.</description>
		<content:encoded><![CDATA[<p>MPT has been a whiny little sod ever since he was effectively frozen out of the Mozilla UI community for being a ... well, whiny little sod.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7688</link>
		<dc:creator>David</dc:creator>
		<pubDate>Fri, 27 Feb 2004 05:29:47 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7688</guid>
		<description>Ah, the old single-click-selects-the-entire-URL &quot;feature&quot;. That used to annoy me to no end. If I want to select the whole URL I&#039;m &lt;em&gt;not&lt;/em&gt; going to single-click, period.



Also, I find OS X&#039;s scroll-bar thumb &quot;ribbing&quot; to be kind of ugly (regardless of how it moves, which I don&#039;t happen to understand). I wonder if it was originally unintentional; someone took a smoothly-shaded aqua blob and repeated the middle segment, which wasn&#039;t uniform, and the ribbing was born. It&#039;s pretty subtle.</description>
		<content:encoded><![CDATA[<p>Ah, the old single-click-selects-the-entire-URL "feature". That used to annoy me to no end. If I want to select the whole URL I'm <em>not</em> going to single-click, period.</p>
<p>Also, I find OS X's scroll-bar thumb "ribbing" to be kind of ugly (regardless of how it moves, which I don't happen to understand). I wonder if it was originally unintentional; someone took a smoothly-shaded aqua blob and repeated the middle segment, which wasn't uniform, and the ribbing was born. It's pretty subtle.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon H</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7687</link>
		<dc:creator>Jon H</dc:creator>
		<pubDate>Tue, 24 Feb 2004 18:39:33 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7687</guid>
		<description>&quot;16. It is easy for important controls â€” such as a window&#039;s scrollbar buttons and resize handle â€” to become unclickable because they are stuck under the Dock. The Dock cannot be hidden temporarily, but even if it could, that would only be a workaround, not a solution.&quot;



I found this to be a problem when I had the Dock on the right side of the screen. I suppose it would also be a problem if it were at bottom, but I&#039;ve never spent much time like that. It&#039;s easy to move a window over, then later go to scroll and end up dragging a Dock icon.



I think you&#039;re less likely to have similar problems if the window hangs off the edge of the screen, because you can&#039;t see the inaccessible widgets. You *can* see the widgets through the Dock, more or less.



The NeXT Dock could be toggled to a mode where it didn&#039;t float above all other windows. A single click on a Dock icon would bring the Dock to the top, but a window could be dragged over it when desired.



I prefer that model. Having the Dock float above all windows eats screen space without really buying any functionality.</description>
		<content:encoded><![CDATA[<p>"16. It is easy for important controls â€” such as a window's scrollbar buttons and resize handle â€” to become unclickable because they are stuck under the Dock. The Dock cannot be hidden temporarily, but even if it could, that would only be a workaround, not a solution."</p>
<p>I found this to be a problem when I had the Dock on the right side of the screen. I suppose it would also be a problem if it were at bottom, but I've never spent much time like that. It's easy to move a window over, then later go to scroll and end up dragging a Dock icon.</p>
<p>I think you're less likely to have similar problems if the window hangs off the edge of the screen, because you can't see the inaccessible widgets. You *can* see the widgets through the Dock, more or less.</p>
<p>The NeXT Dock could be toggled to a mode where it didn't float above all other windows. A single click on a Dock icon would bring the Dock to the top, but a window could be dragged over it when desired.</p>
<p>I prefer that model. Having the Dock float above all windows eats screen space without really buying any functionality.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ozy</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7686</link>
		<dc:creator>Ozy</dc:creator>
		<pubDate>Mon, 23 Feb 2004 22:07:43 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7686</guid>
		<description>&lt;blockquote&gt;Hey look, a bandwagon! Let&#039;s get on! This one bothers everyone and goes without saying, practically. Then again, any list that didn&#039;t have this one wouldn&#039;t be a very serious list.&lt;/blockquote&gt;



I find that this distinction makes quite good sense. First off, both aqua and brushed metal look pretty, though one looks better in some situations then the other. But due to the mix windows from different applications are easily recognized. It makes windows even more unique in appearance then by content and layout alone, which is nice.



Some might argue that the value in adding an extra way to recognize windows from application more quickly is not necessary and that sticking to one design makes the desktop look less crowded and more consistent. But because (and especially with Panther) both the aqua and brushed metal designs look pretty and even together they look pretty good, I find that this extra distinction between programs is nice.



Still using brushed metal at will is not a very good idea, some consistency would be nice, but I guess Apple has it just about right. Though different tastes means different opinions ...</description>
		<content:encoded><![CDATA[<blockquote><p>Hey look, a bandwagon! Let's get on! This one bothers everyone and goes without saying, practically. Then again, any list that didn't have this one wouldn't be a very serious list.</p>
</blockquote>
<p>I find that this distinction makes quite good sense. First off, both aqua and brushed metal look pretty, though one looks better in some situations then the other. But due to the mix windows from different applications are easily recognized. It makes windows even more unique in appearance then by content and layout alone, which is nice.</p>
<p>Some might argue that the value in adding an extra way to recognize windows from application more quickly is not necessary and that sticking to one design makes the desktop look less crowded and more consistent. But because (and especially with Panther) both the aqua and brushed metal designs look pretty and even together they look pretty good, I find that this extra distinction between programs is nice.</p>
<p>Still using brushed metal at will is not a very good idea, some consistency would be nice, but I guess Apple has it just about right. Though different tastes means different opinions ...</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: andy</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7685</link>
		<dc:creator>andy</dc:creator>
		<pubDate>Mon, 23 Feb 2004 11:55:55 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7685</guid>
		<description>doh, should have read the article :)</description>
		<content:encoded><![CDATA[<p>doh, should have read the article <img src='http://nslog.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: andy</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7684</link>
		<dc:creator>andy</dc:creator>
		<pubDate>Mon, 23 Feb 2004 11:54:55 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7684</guid>
		<description>Bob: That rule has changed in Mac OS X. The new one is &quot;use an ellipsis if the command needs more information to be executed&quot;, which is a question of interpretation on the preferences menu item.

&quot;Do it like Finder&quot; might be a good idea, which has an ellipsis on preferences, but not on the about-item.</description>
		<content:encoded><![CDATA[<p>Bob: That rule has changed in Mac OS X. The new one is "use an ellipsis if the command needs more information to be executed", which is a question of interpretation on the preferences menu item.</p>
<p>"Do it like Finder" might be a good idea, which has an ellipsis on preferences, but not on the about-item.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7683</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Mon, 23 Feb 2004 04:47:07 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7683</guid>
		<description>What about the preferences menu item? That has an ellipsis and it is just displaying a window. Used to be under OS 9 that any menu item that caused a window to be shown had an ellipsis. Check out the about menu item (OS 9 remember) for an example.</description>
		<content:encoded><![CDATA[<p>What about the preferences menu item? That has an ellipsis and it is just displaying a window. Used to be under OS 9 that any menu item that caused a window to be shown had an ellipsis. Check out the about menu item (OS 9 remember) for an example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Caleb Jaffa</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7682</link>
		<dc:creator>Caleb Jaffa</dc:creator>
		<pubDate>Sun, 22 Feb 2004 19:30:15 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7682</guid>
		<description>I personally don&#039;t have a problem with the mix of metal and aqua apps.  It doesn&#039;t even bother me that hiding the sidebar in Finder apps changes it back and forth.  If it really bothered me there is a haxie available to take care of it.  Personally I find a little variety to be nice.  I&#039;ve &#039;h4x0red&#039; the nibs for Safari before to remove the brushed metal appearance, and though it might just be familiarity, I didn&#039;t like it as well.  The darker (metal) window works better in some cases than a lighter (aqua) window for presentation purposes.</description>
		<content:encoded><![CDATA[<p>I personally don't have a problem with the mix of metal and aqua apps.  It doesn't even bother me that hiding the sidebar in Finder apps changes it back and forth.  If it really bothered me there is a haxie available to take care of it.  Personally I find a little variety to be nice.  I've 'h4x0red' the nibs for Safari before to remove the brushed metal appearance, and though it might just be familiarity, I didn't like it as well.  The darker (metal) window works better in some cases than a lighter (aqua) window for presentation purposes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Nanian</title>
		<link>http://nslog.com/2004/02/21/48_hours#comment-7681</link>
		<dc:creator>Dave Nanian</dc:creator>
		<pubDate>Sat, 21 Feb 2004 23:35:05 +0000</pubDate>
		<guid isPermaLink="false">http://nslog.com/2004/02/21/48_hours/#comment-7681</guid>
		<description>&lt;blockquote&gt;16. It is easy for important controls - such as a window&#039;s scrollbar buttons and resize handle - to become unclickable because they are stuck under the Dock. The Dock cannot be hidden temporarily, but even if it could, that would only be a workaround, not a solution.&lt;/blockquote&gt;



Yeah, it&#039;s easy for them to be unclickable when they fall offscreen, too. I have a modest proposal: no windows should be allowed to overlap or move offscreen, ever! That&#039;ll solve this problem, and similar ones where any &quot;on top&quot; panel, pane, dialog or sheet overlaps a control.



(sigh)</description>
		<content:encoded><![CDATA[<blockquote><p>16. It is easy for important controls - such as a window's scrollbar buttons and resize handle - to become unclickable because they are stuck under the Dock. The Dock cannot be hidden temporarily, but even if it could, that would only be a workaround, not a solution.</p>
</blockquote>
<p>Yeah, it's easy for them to be unclickable when they fall offscreen, too. I have a modest proposal: no windows should be allowed to overlap or move offscreen, ever! That'll solve this problem, and similar ones where any "on top" panel, pane, dialog or sheet overlaps a control.</p>
<p>(sigh)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

