<?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"
	>
<channel>
	<title>Comments on: UI Design and Preferences</title>
	<atom:link href="http://www.symphonious.net/2007/06/26/ui-design-and-preferences/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/</link>
	<description>Living in a state of accord.</description>
	<pubDate>Wed, 03 Dec 2008 01:46:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: Adrian Sutton</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-95646</link>
		<dc:creator>Adrian Sutton</dc:creator>
		<pubDate>Sat, 30 Jun 2007 21:12:58 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-95646</guid>
		<description>Oops, there should have been a not in there - the change is making people less productive so it's providing no benefit for the frustration. However, sometimes it's good for people to have to go through a relearning period in order to be more effective or efficient and a UI designer should understand that trade off and make it when needed. If we never drastically changed our UIs we'd never move forward in computing (your web browser would by lynx, not Firefox) - if we enabled users to switch back to the old mode all the time, we'd be maintaining thousands and thousands of legacy options in our software and users wouldn't be taking advantage of the improvements we've added.

Software isn't the servant, software is the tool and tools require you to work in certain ways to get the best results. If the tool can be modified in such a way that it is a better tool then it should be modified, even if that requires some relearning.</description>
		<content:encoded><![CDATA[<p>Oops, there should have been a not in there - the change is making people less productive so it&#8217;s providing no benefit for the frustration. However, sometimes it&#8217;s good for people to have to go through a relearning period in order to be more effective or efficient and a UI designer should understand that trade off and make it when needed. If we never drastically changed our UIs we&#8217;d never move forward in computing (your web browser would by lynx, not Firefox) - if we enabled users to switch back to the old mode all the time, we&#8217;d be maintaining thousands and thousands of legacy options in our software and users wouldn&#8217;t be taking advantage of the improvements we&#8217;ve added.</p>
<p>Software isn&#8217;t the servant, software is the tool and tools require you to work in certain ways to get the best results. If the tool can be modified in such a way that it is a better tool then it should be modified, even if that requires some relearning.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RoUS</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-95607</link>
		<dc:creator>RoUS</dc:creator>
		<pubDate>Sat, 30 Jun 2007 14:51:25 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-95607</guid>
		<description>You identified my main issue right in your first line: "The rule is if you're going to force the user to change their behavior.."  Software has NO BUSINESS forcing the user to change its behaviour.  The software is the servant, not the master.

But I can agree with you on the messiness of preference dialogues.  So let me generalise it a bit more: Either don't violate the Principle of Least Astonishment by drastically changing the UI -- or, if you do, provide some way for the user to revert it to accustomed/preferred behaviour.  It doesn't need to be a preference dialogue.  As it happens, Derick Rethans showed me that there *is* a way to revert it, so my ire is considerably reduced.

And I don't understand your remark as stated: "Given the number of people who complain about this feature and the solid arguments for why having the button on the far right is more efficient, the change should have been made."  If there are arguments for keeping the button on the right, and lots of people complain about it being moved, why should the change have been made?  Or did you mean *less* efficient, and the feature being complained about was having the close button on the right?  Or that the change should *not* have been made?</description>
		<content:encoded><![CDATA[<p>You identified my main issue right in your first line: &#8220;The rule is if you&#8217;re going to force the user to change their behavior..&#8221;  Software has NO BUSINESS forcing the user to change its behaviour.  The software is the servant, not the master.</p>
<p>But I can agree with you on the messiness of preference dialogues.  So let me generalise it a bit more: Either don&#8217;t violate the Principle of Least Astonishment by drastically changing the UI &#8212; or, if you do, provide some way for the user to revert it to accustomed/preferred behaviour.  It doesn&#8217;t need to be a preference dialogue.  As it happens, Derick Rethans showed me that there *is* a way to revert it, so my ire is considerably reduced.</p>
<p>And I don&#8217;t understand your remark as stated: &#8220;Given the number of people who complain about this feature and the solid arguments for why having the button on the far right is more efficient, the change should have been made.&#8221;  If there are arguments for keeping the button on the right, and lots of people complain about it being moved, why should the change have been made?  Or did you mean *less* efficient, and the feature being complained about was having the close button on the right?  Or that the change should *not* have been made?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James C. McPherson</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94972</link>
		<dc:creator>James C. McPherson</dc:creator>
		<pubDate>Wed, 27 Jun 2007 13:51:10 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94972</guid>
		<description>My chief complaint with both firefox and thunderbird - starting with v1.5 - is that &lt;i&gt;somebody&lt;/i&gt; decided that it should be bloody difficult to actually have two running instances of either program. So if, like me, you rely on having two separate profiles (work via vpn, home), any attempt to just blithely startup a new instance will force the currently running instance to pop to the foreground.

You need to go and set MOZ_NO_REMOTE=1 before running firefox/thunderbird if you want to avoid this.

I do have a legitimate reason for needing two profiles and having both active: I run a host with a vpn connection to work, and a host which is on the ordinary internet. I want to keep my "at work" preferences, browsing history etc separate from my home preferences. 

Whoever decided that they knew better than me about what I might want to do with the mozilla suite is very, very wrong.</description>
		<content:encoded><![CDATA[<p>My chief complaint with both firefox and thunderbird - starting with v1.5 - is that <i>somebody</i> decided that it should be bloody difficult to actually have two running instances of either program. So if, like me, you rely on having two separate profiles (work via vpn, home), any attempt to just blithely startup a new instance will force the currently running instance to pop to the foreground.</p>
<p>You need to go and set MOZ_NO_REMOTE=1 before running firefox/thunderbird if you want to avoid this.</p>
<p>I do have a legitimate reason for needing two profiles and having both active: I run a host with a vpn connection to work, and a host which is on the ordinary internet. I want to keep my &#8220;at work&#8221; preferences, browsing history etc separate from my home preferences. </p>
<p>Whoever decided that they knew better than me about what I might want to do with the mozilla suite is very, very wrong.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94385</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 26 Jun 2007 10:29:04 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94385</guid>
		<description>Then they needed to find a way to actually please both camps - like putting the close button in both places. It's not simple to do, but noone ever said UI design was simple - that doesn't mean preferences are a solution, particularly since most users wouldn't think to go looking for the preference if they didn't like whatever way the default worked.</description>
		<content:encoded><![CDATA[<p>Then they needed to find a way to actually please both camps - like putting the close button in both places. It&#8217;s not simple to do, but noone ever said UI design was simple - that doesn&#8217;t mean preferences are a solution, particularly since most users wouldn&#8217;t think to go looking for the preference if they didn&#8217;t like whatever way the default worked.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Asbjørn Ulsberg</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94356</link>
		<dc:creator>Asbjørn Ulsberg</dc:creator>
		<pubDate>Tue, 26 Jun 2007 09:27:46 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94356</guid>
		<description>I agree that the UI shouldn't have been messed up. But I'm pretty sure that when they did, it was for a reason and that there's now a large number of people finding the new style better than the old one. The ones hating the new one aren't left much choice, though, since there isn't an option to switch back.</description>
		<content:encoded><![CDATA[<p>I agree that the UI shouldn&#8217;t have been messed up. But I&#8217;m pretty sure that when they did, it was for a reason and that there&#8217;s now a large number of people finding the new style better than the old one. The ones hating the new one aren&#8217;t left much choice, though, since there isn&#8217;t an option to switch back.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adrian Sutton</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94315</link>
		<dc:creator>Adrian Sutton</dc:creator>
		<pubDate>Tue, 26 Jun 2007 08:02:44 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94315</guid>
		<description>Asbjørn,
I think you slightly missed the point - you shouldn't mess up your UI in the first place. Given the number of people who complain about this feature and the solid arguments for why having the button on the far right is more efficient, the change should have been made.

More importantly, there isn't a need to pick one or the other in this case - you could have a permanent close button in the far right and a button on the tab that appears when you hover over it (it is more intuitive to have the close button on the tab when you only want to close one tab).

There's probably other creative solutions to the problem that would work better than either of those too, it's just a matter of taking the time to actually do the UI design work instead of just slapping in another preference and considering it solved.</description>
		<content:encoded><![CDATA[<p>Asbjørn,<br />
I think you slightly missed the point - you shouldn&#8217;t mess up your UI in the first place. Given the number of people who complain about this feature and the solid arguments for why having the button on the far right is more efficient, the change should have been made.</p>
<p>More importantly, there isn&#8217;t a need to pick one or the other in this case - you could have a permanent close button in the far right and a button on the tab that appears when you hover over it (it is more intuitive to have the close button on the tab when you only want to close one tab).</p>
<p>There&#8217;s probably other creative solutions to the problem that would work better than either of those too, it&#8217;s just a matter of taking the time to actually do the UI design work instead of just slapping in another preference and considering it solved.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Asbjørn Ulsberg</title>
		<link>http://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94306</link>
		<dc:creator>Asbjørn Ulsberg</dc:creator>
		<pubDate>Tue, 26 Jun 2007 07:38:44 +0000</pubDate>
		<guid isPermaLink="false">https://www.symphonious.net/2007/06/26/ui-design-and-preferences/#comment-94306</guid>
		<description>Although I agree that adding junk to a preference dialog isn't always a good solution, I agree with Ken in this particular case. Using Firefox as my primary browser is completely out of the question because of the way tabs work in 2.x. Not that it's likely I'll switch from Opera anyhoo, but every time I have to use Firefox, those close buttons and the tab behavior annoys me like a blood thirsty mosquito when I'm trying to sleep.</description>
		<content:encoded><![CDATA[<p>Although I agree that adding junk to a preference dialog isn&#8217;t always a good solution, I agree with Ken in this particular case. Using Firefox as my primary browser is completely out of the question because of the way tabs work in 2.x. Not that it&#8217;s likely I&#8217;ll switch from Opera anyhoo, but every time I have to use Firefox, those close buttons and the tab behavior annoys me like a blood thirsty mosquito when I&#8217;m trying to sleep.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
