<?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: sneJ&#8217;s Law of Toolbars</title>
	<atom:link href="http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/feed/" rel="self" type="application/rss+xml" />
	<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/</link>
	<description>Little boxes made of words, by Jens Alfke</description>
	<lastBuildDate>Sun, 02 May 2010 05:43:47 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: ssp</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2934</link>
		<dc:creator>ssp</dc:creator>
		<pubDate>Sat, 14 Feb 2009 10:17:40 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2934</guid>
		<description>Jens — I do see your point, but I think that the inherently limited design of the standard Mac toolbar with its space constraints tells you that the setup is not made for arbitrary customisation. If you wanted people to have &#039;just the commands they need&#039; there, you&#039;d want to accomodate people who need a large number of commands as well. By design, OS X&#039;s toolbars come with a &#039;designer knows best&#039; attitude and should encourage the developer to choose wise subset of the commands.

If a user happens to want other commands in the toolbar, the Apple-typical &#039;tough luck!&#039; attitude will come to play. And, as Hendrik points out, that&#039;s probably not the worst thing since most non-technical users don&#039;t even seem to know that toolbars can be customised at all.

BTW, I am not sure the toolbar really is a convenience in all OS X applications, it just should be. Some features will work without the toolbar but aren&#039;t convenient at all (e.g. Find in Preview), others (e.g. Find Message in Mail) simply require the toolbar to be present.</description>
		<content:encoded><![CDATA[<p>Jens — I do see your point, but I think that the inherently limited design of the standard Mac toolbar with its space constraints tells you that the setup is not made for arbitrary customisation. If you wanted people to have &#8216;just the commands they need&#8217; there, you&#8217;d want to accomodate people who need a large number of commands as well. By design, OS X&#8217;s toolbars come with a &#8216;designer knows best&#8217; attitude and should encourage the developer to choose wise subset of the commands.</p>
<p>If a user happens to want other commands in the toolbar, the Apple-typical &#8216;tough luck!&#8217; attitude will come to play. And, as Hendrik points out, that&#8217;s probably not the worst thing since most non-technical users don&#8217;t even seem to know that toolbars can be customised at all.</p>
<p>BTW, I am not sure the toolbar really is a convenience in all OS X applications, it just should be. Some features will work without the toolbar but aren&#8217;t convenient at all (e.g. Find in Preview), others (e.g. Find Message in Mail) simply require the toolbar to be present.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hendrik</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2933</link>
		<dc:creator>Hendrik</dc:creator>
		<pubDate>Fri, 13 Feb 2009 22:01:42 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2933</guid>
		<description>PS: I wish one could preview or edit the comments here.</description>
		<content:encoded><![CDATA[<p>PS: I wish one could preview or edit the comments here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hendrik</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2932</link>
		<dc:creator>Hendrik</dc:creator>
		<pubDate>Fri, 13 Feb 2009 22:00:11 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2932</guid>
		<description>&lt;blockquote cite=&quot;My point was that everyone wants a different subset of commands in that fixed space ...&quot;&gt;

I wonder though how many percent of users typically customize the toolbar. My guess would be around 2%. Making those 2% happy is of course still important, but not important enough to spend big $$$ on tons of icons.&lt;/blockquote&gt;</description>
		<content:encoded><![CDATA[<blockquote cite="My point was that everyone wants a different subset of commands in that fixed space ...">
<p>I wonder though how many percent of users typically customize the toolbar. My guess would be around 2%. Making those 2% happy is of course still important, but not important enough to spend big $$$ on tons of icons.</p></blockquote>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jens Alfke</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2931</link>
		<dc:creator>Jens Alfke</dc:creator>
		<pubDate>Fri, 13 Feb 2009 21:42:35 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2931</guid>
		<description>ssp — No, I&#039;m not talking about having every command in the toolbar at once. The OS X toolbar UI is self-limiting that way, as it&#039;s a single row and there are only so many commands that will fit. I&#039;m fine with that. My point was that everyone wants a different subset of commands in that fixed space, and the customization UI in principle allows that, except that developers only toolbar-enable a subset of the commands, and it&#039;s not going to be the right subset for everyone.

As to your point about a toolbar being an additional convenience: That&#039;s correct, and I agree with that; I am talking about convenience in this post. Again, on OS X the toolbar is always a convenience because it&#039;s always possible to hide it, so all commands have to be reachable through the menu bar.</description>
		<content:encoded><![CDATA[<p>ssp — No, I&#8217;m not talking about having every command in the toolbar at once. The OS X toolbar UI is self-limiting that way, as it&#8217;s a single row and there are only so many commands that will fit. I&#8217;m fine with that. My point was that everyone wants a different subset of commands in that fixed space, and the customization UI in principle allows that, except that developers only toolbar-enable a subset of the commands, and it&#8217;s not going to be the right subset for everyone.</p>
<p>As to your point about a toolbar being an additional convenience: That&#8217;s correct, and I agree with that; I am talking about convenience in this post. Again, on OS X the toolbar is always a convenience because it&#8217;s always possible to hide it, so all commands have to be reachable through the menu bar.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jens Alfke</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2930</link>
		<dc:creator>Jens Alfke</dc:creator>
		<pubDate>Fri, 13 Feb 2009 21:38:39 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2930</guid>
		<description>aegidian — Toolbars are for commands that you use often enough to want a quick single-click UI shortcut for, but not so often that you&#039;ve memorized their command keys. The SCM commands in Xcode are a good example, for me — I wanted an easier way to get to them than pulling down the SCM menu, but I had no brain cells left for remembering any extra Xcode key commands.

Or also commands where you know the key equivalent but find a button more convenient. What sparked this post, actually, was wanting to put NetNewsWire&#039;s Next/Prev Tab commands in the toolbar. I can access them with Cmd-Shift-brackets, but when I&#039;m eating breakfast and holding my toast in one hand, those multi-modifier commands are awkward and I&#039;d rather just click a button.</description>
		<content:encoded><![CDATA[<p>aegidian — Toolbars are for commands that you use often enough to want a quick single-click UI shortcut for, but not so often that you&#8217;ve memorized their command keys. The SCM commands in Xcode are a good example, for me — I wanted an easier way to get to them than pulling down the SCM menu, but I had no brain cells left for remembering any extra Xcode key commands.</p>
<p>Or also commands where you know the key equivalent but find a button more convenient. What sparked this post, actually, was wanting to put NetNewsWire&#8217;s Next/Prev Tab commands in the toolbar. I can access them with Cmd-Shift-brackets, but when I&#8217;m eating breakfast and holding my toast in one hand, those multi-modifier commands are awkward and I&#8217;d rather just click a button.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ssp</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2929</link>
		<dc:creator>ssp</dc:creator>
		<pubDate>Fri, 13 Feb 2009 19:03:32 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2929</guid>
		<description>I guess the idea of creating a toolbar which covers all commands has already been executed. The result is called MS Office. Obviously once people can have all these commands in their toolbars, they start thinking they _need_ plenty of them as well. The result are screens 50% of which is covered in toolbars and users who just accept that even though it really gets in the way of their work. I have seen that plenty of times.

My guesses to your questions (all of which appear as number 1 in my Safari) would be: 1. Yes, those toolbars will look ugly and their icons will be useless. Countless Windows or Linux applications are a proof of that. 2. Validating toolbar items may take time, but my gut feeling is that this won&#039;t be a problem. 3. Yes, OS X&#039;s toolbar UI will not work for this. It&#039;s already a mess in applications like XCode (there is a scrollbar).

I think the whole argument looks at toolbars in the wrong way. To begin with they should be an additional convenience rather than the main GUI strategy. It may be harder to design apps in a way that they work well without a toolbar, but that extra thought will usually lead to a better design. Secondly they should represent the most common commands. Stuff like back / forward or delete and a few more come to mind. Save as EBCDIC – as amusing as it sounds – doesn&#039;t.</description>
		<content:encoded><![CDATA[<p>I guess the idea of creating a toolbar which covers all commands has already been executed. The result is called MS Office. Obviously once people can have all these commands in their toolbars, they start thinking they _need_ plenty of them as well. The result are screens 50% of which is covered in toolbars and users who just accept that even though it really gets in the way of their work. I have seen that plenty of times.</p>
<p>My guesses to your questions (all of which appear as number 1 in my Safari) would be: 1. Yes, those toolbars will look ugly and their icons will be useless. Countless Windows or Linux applications are a proof of that. 2. Validating toolbar items may take time, but my gut feeling is that this won&#8217;t be a problem. 3. Yes, OS X&#8217;s toolbar UI will not work for this. It&#8217;s already a mess in applications like XCode (there is a scrollbar).</p>
<p>I think the whole argument looks at toolbars in the wrong way. To begin with they should be an additional convenience rather than the main GUI strategy. It may be harder to design apps in a way that they work well without a toolbar, but that extra thought will usually lead to a better design. Secondly they should represent the most common commands. Stuff like back / forward or delete and a few more come to mind. Save as EBCDIC – as amusing as it sounds – doesn&#8217;t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Chestnykh</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2928</link>
		<dc:creator>Dmitry Chestnykh</dc:creator>
		<pubDate>Fri, 13 Feb 2009 18:35:02 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2928</guid>
		<description>It&#039;s a common belief that while everyone uses only a subset of an application’s features, everyone uses a different subset. But is it really [statistically] possible?</description>
		<content:encoded><![CDATA[<p>It&#8217;s a common belief that while everyone uses only a subset of an application’s features, everyone uses a different subset. But is it really [statistically] possible?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aegidian (LJ)</title>
		<link>http://jens.mooseyard.com/2009/02/snejs-law-of-toolbars/comment-page-1/#comment-2927</link>
		<dc:creator>aegidian (LJ)</dc:creator>
		<pubDate>Fri, 13 Feb 2009 18:20:47 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2009/02/snejs-law-of-toolbars/#comment-2927</guid>
		<description>I remain to be convinced that an OSX window toolbar differs greatly from the window based menus of Windows. Every command a user requires (at that moment) should be in the Application menus, but to repeat them all in the toolbar seems excessive.

So what is the toolbar for?</description>
		<content:encoded><![CDATA[<p>I remain to be convinced that an OSX window toolbar differs greatly from the window based menus of Windows. Every command a user requires (at that moment) should be in the Application menus, but to repeat them all in the toolbar seems excessive.</p>
<p>So what is the toolbar for?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
