<?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: I hate Macs</title>
	<atom:link href="http://brianwill.net/blog/2007/03/19/i-hate-macs/feed/" rel="self" type="application/rss+xml" />
	<link>http://brianwill.net/blog/2007/03/19/i-hate-macs/</link>
	<description></description>
	<lastBuildDate>Sun, 08 Apr 2012 22:34:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: DvS</title>
		<link>http://brianwill.net/blog/2007/03/19/i-hate-macs/comment-page-1/#comment-632</link>
		<dc:creator>DvS</dc:creator>
		<pubDate>Mon, 12 Nov 2007 21:56:57 +0000</pubDate>
		<guid isPermaLink="false">http://brianwill.net/blog/2007/03/19/i-hate-macs/#comment-632</guid>
		<description>Sounds like you&#039;ve got UI retardation.</description>
		<content:encoded><![CDATA[<p>Sounds like you&#8217;ve got UI retardation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Will</title>
		<link>http://brianwill.net/blog/2007/03/19/i-hate-macs/comment-page-1/#comment-629</link>
		<dc:creator>Brian Will</dc:creator>
		<pubDate>Mon, 06 Aug 2007 06:09:10 +0000</pubDate>
		<guid isPermaLink="false">http://brianwill.net/blog/2007/03/19/i-hate-macs/#comment-629</guid>
		<description>Thanks for the reply Nathan.

In my Portals design, I&#039;m not yet sure if file browsing is a privileged component or treated just as a regular program, so I didn&#039;t include it in my Portals mock-up. Still, I&#039;m quite confident I don&#039;t want to mix files and programs together in the Portals analog of the start menu. To me, that just seems like a band-aid over poor file browsing, and it&#039;s just another redundant mechanism. In contrast, the reason users don&#039;t go into the file browser to click on .exe files is because those files reside in program directories, the structures of which most users don&#039;t care to deal with or memorize. So you&#039;re right users generally want to deal only with their own directories rather than Windows, Program Files, and so forth. A user home directory is of course the Unix solution, but I&#039;ve never really liked this scheme as I always want to control which drive I&#039;m storing my files to, and often it feels inappropriate to file things under my name. If I store something, why should others have to think to look under my username?

A better kind of file browser is something I&#039;ve worked on in the past and actually written some of in Java. It combines search-based navigation with tabbed-browsing. Unlike other search-based files, it only indexed the file and directory names, not the contents. This is less sophisticated than what Google Desktop gives you, of course, but I think it&#039;s actually more desirable to only get directory/file name search results. So users could enter the query, say, &#039;dog&#039;, and get back a pulldown list of all paths to directories and files where the file or the last directory starts with  &#039;dog&#039;. Or you could enter &#039;dog cat&#039; and get back all paths containing both dog and cat while ending in a directory that starts either &#039;dog&#039; or &#039;cat&#039;. The idea was to eventually have this work more like tab completiong, but I didn&#039;t get around to that. Rather than have tabs, the user saw a list of the last several paths they selected. Users could click on the path to go back to that directory, or they could click on one of the parent directories in the path to go to that parent directory. So if you have the path &#039;c:/foo/bar/dog/&#039; in your path, you could click &#039;bar&#039; to navigate to &#039;c:/foo/bar/&#039;; the path wouldn&#039;t change except you&#039;d see the &#039;c:/foo/bar/&#039; portion highlighted; this way you could move back and forth between two related directories.

Anyway, your ideas do sound interesting, but I must say it&#039;s hard to follow just from a description (just like my example above must have been). If you want someone to take your interface ideas seriously, it&#039;s always best to produce some kind of visual mock-up. It doesn&#039;t have to be interactive. A few pictures go a long way.</description>
		<content:encoded><![CDATA[<p>Thanks for the reply Nathan.</p>
<p>In my Portals design, I&#8217;m not yet sure if file browsing is a privileged component or treated just as a regular program, so I didn&#8217;t include it in my Portals mock-up. Still, I&#8217;m quite confident I don&#8217;t want to mix files and programs together in the Portals analog of the start menu. To me, that just seems like a band-aid over poor file browsing, and it&#8217;s just another redundant mechanism. In contrast, the reason users don&#8217;t go into the file browser to click on .exe files is because those files reside in program directories, the structures of which most users don&#8217;t care to deal with or memorize. So you&#8217;re right users generally want to deal only with their own directories rather than Windows, Program Files, and so forth. A user home directory is of course the Unix solution, but I&#8217;ve never really liked this scheme as I always want to control which drive I&#8217;m storing my files to, and often it feels inappropriate to file things under my name. If I store something, why should others have to think to look under my username?</p>
<p>A better kind of file browser is something I&#8217;ve worked on in the past and actually written some of in Java. It combines search-based navigation with tabbed-browsing. Unlike other search-based files, it only indexed the file and directory names, not the contents. This is less sophisticated than what Google Desktop gives you, of course, but I think it&#8217;s actually more desirable to only get directory/file name search results. So users could enter the query, say, &#8216;dog&#8217;, and get back a pulldown list of all paths to directories and files where the file or the last directory starts with  &#8216;dog&#8217;. Or you could enter &#8216;dog cat&#8217; and get back all paths containing both dog and cat while ending in a directory that starts either &#8216;dog&#8217; or &#8216;cat&#8217;. The idea was to eventually have this work more like tab completiong, but I didn&#8217;t get around to that. Rather than have tabs, the user saw a list of the last several paths they selected. Users could click on the path to go back to that directory, or they could click on one of the parent directories in the path to go to that parent directory. So if you have the path &#8216;c:/foo/bar/dog/&#8217; in your path, you could click &#8216;bar&#8217; to navigate to &#8216;c:/foo/bar/&#8217;; the path wouldn&#8217;t change except you&#8217;d see the &#8216;c:/foo/bar/&#8217; portion highlighted; this way you could move back and forth between two related directories.</p>
<p>Anyway, your ideas do sound interesting, but I must say it&#8217;s hard to follow just from a description (just like my example above must have been). If you want someone to take your interface ideas seriously, it&#8217;s always best to produce some kind of visual mock-up. It doesn&#8217;t have to be interactive. A few pictures go a long way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nathan Spears</title>
		<link>http://brianwill.net/blog/2007/03/19/i-hate-macs/comment-page-1/#comment-631</link>
		<dc:creator>Nathan Spears</dc:creator>
		<pubDate>Sat, 04 Aug 2007 07:18:27 +0000</pubDate>
		<guid isPermaLink="false">http://brianwill.net/blog/2007/03/19/i-hate-macs/#comment-631</guid>
		<description>Astute observations.  I like your idea that no &#039;window&#039; should ever be less than maximized.  I have tonight discovered launchy, which has in two hours made me realize how useless the start menu and browsing hierarchically is, and TaskSwitchXP, which although not perfect is a big improvement over regular alt-tabbing.  After reading your posts on Macs and on Window Management, I want to bounce a couple ideas off of you.

First of all, I think we both agree that the idea of the desktop as it exists now is broken.  It doesn&#039;t necessarily need to be but when people can be lazy and save documents on it, then they will.  If you aren&#039;t saving documents on it, though, what is it good for?  Well, you can put shortcuts to programs or folders on it.  Isn&#039;t that what the Start Menu and Toolbars are for?  You can put widgets on it.  Isn&#039;t that what the system tray is for?  Basically (again as you state) there are too many ways to do the same thing which do not offer anything unique.  Pick one and go with it.

So.  What I think the desktop and Start Menu/toolbar offer are essentially all the same things, with one important exception - the toolbar is the only place you can select from among your open windows.  Of the time you spend interacting with the window management system, this is probably what you spend most of your time doing, which is why it&#039;s so annoying that the interface is so poor/slow.

So here finally are my ideas:

1.  Make the desktop a combination of the most useful features of Windows Task Manager, TaskSwitchXP, and the Start Menu.  A significant portion of desktop real estate would be a list of running applications, which can be grouped, switched to, terminated, etc, directly on the desktop.  These could be in a numbered list, allowing you to use a keyboard shortcut to type in the number.

2.  Make it easy to reach the desktop and obvious that this is where you now control things.  There could be an &#039;always on top&#039; button at the bottom of the screen for beginners, keyboard shortcut customizable.  Personally, I would like to throw my mouse to the bottom of the screen to show the desktop, or bottom left to auto switch back to the last app.  All configurable of course, but the default behavior should be almost as helpful as any customized behavior.

3.  Make (by default) every open program/folder its own &quot;desktop.&quot;  That is, it uses the entire screen (except for whatever button shows the desktop).  As you say, some people want you to believe that it&#039;s nice to have small windows artfully distributed across the desktop, but when is it actually helpful?  I like the way (for example) Pidgin looks, but I keep it minimized all the time so it doesn&#039;t even matter.  It shouldn&#039;t be designed to look good small - it should be designed to run full screen and take advantage of all the available desktop when it&#039;s being viewed.

4.  These &#039;desktops&#039; can be combined when necessary - ie you want to have two word documents side by side.  This solves your problem of having to click twice to bring them both back up.  You would be able to either combine running apps into one desktop, or specify when starting a new one which desktop it would join.  More on this in a second.

So this leaves a couple questions about how users begin running applications in the first place, and how they interact with files and such.  I propose that there be two hardlinks on the desktop - one to interact with programs, and the other to interact with user documents.  Basically the My Documents link that&#039;s currently on the desktop, and the Programs folder that&#039;s currently in the Start Menu.  However, these desktop links would be more akin to the easy sliding hierarchy of a toolbar folder than the annoying &quot;open each folder in the same window&quot; functionality of the current window system.  In addition, there should be a file browser with almost the exact same interface as Firefox - tabs for different folders, a favorites or quick links system, etc.  Basically whatever solutions we come up with to improve our internet browsing experience can be applied to our directory browsing experience as well.  The nested hierarchy view as a sole interface is ancient and horrible.  Probably this file browser I&#039;m describing is ubiquitous in linux and I haven&#039;t used it yet.

So users wouldn&#039;t be &quot;allowed&quot; to store their files anywhere outside of this My Documents folder (hopefully just Documents so we can have a spaceless path to root . . .).  In addition, it would be nice if programs would create folders intelligently for themselves inside this Documents folder.  For instance, let&#039;s say that Microsoft Word had been intelligently placed inside of a Office (not MS) subgroup in the Program Folders.  Then it&#039;s default folder for saving files would be Documents\Office\Word unless the user specifies differently.  Eclipse would use Documents\Programming\Eclipse\workspace, etc.

And thus you can guess at the nature of the Programs menu  - it basically looks like the default KDE start menu - applications divided into sensible subgroups.  The only difference is that every program on the computer would be listed there, because it is the only way for you to launch them.  Perhaps you left click on it for all programs, right click on it for favorites.  Once you get used to Launchy it&#039;s kind of irrelevant because you can type so much faster than you can use a mouse.

The last thing I can think of to allow on the desktop is widgets.  A clock, perhaps an IM widget.  Or perhaps not.  Maybe a good IM client uses transparency to good effect to show you new messages without interfering with your current focus.  Anyway there must be some things such that you do not want to have to perform an action to see the desktop, another action to see the thing (eg clock) then switch back to the former window.  So those things could get space on the desktop.  Perhaps there is a shortcut to show the desktop, then go right back to the window you were in.  Or maybe a key to make your current window temporarily transparent so you can see the desktop through it.  Amounts to the same thing I guess.

So to review: there are two branching links to programs and documents,  the TaskSwitchXP-like list of running apps (configurable of course for power users, ie processor usage, perhaps a separate section listing processes ala top), and any widgets configured to run on the desktop that don&#039;t imitate or duplicate the functions of the previous items, and have some good reason for being on the desktop.

What do you think?  I think this would actually work pretty well with many of the ideas from your portal system, although there is some overlap in the ideas about how to display running apps for selecting among them.

We agree on the fact that it should be easy and quick to switch between running applications.  All my ideas about keyboard shortcuts apply as easily to your system - eg you could have a key shortcut to show the menu and a numbered system for selecting among them.  As I look around I become more convinced that I haven&#039;t seen any of your ideas about what should actually be on the desktop instead of all the clutter that&#039;s there now.  I realize the desktop is an illusion - a de facto full screen window to give users a warm fuzzy that their computer is &#039;there&#039;, but I do think it&#039;s too valuable not to keep around and use it as well as possible.

Oh, something else I was going to add about program launching - let&#039;s say you click on the program menu and want to start a program in the same window as another running app.  So you drag it out of the program menu and onto the app you want it to share space with.  There&#039;s no reason to assume that dragging an app means trying to move it from folder to folder in the menu - in fact whenever I do this now it&#039;s by accident, so let&#039;s remove that possibility and put the move functionality somewhere else entirely - an &#039;edit menu&#039; somewhere.  There are probably other possibilities for dragging programs onto the desktop (which starts them running) that I can&#039;t see right now.  Maybe you&#039;ve got an applet such that when you drag an application onto it the applet asks for password and runs the app as root.

Man, you really got me typing.</description>
		<content:encoded><![CDATA[<p>Astute observations.  I like your idea that no &#8216;window&#8217; should ever be less than maximized.  I have tonight discovered launchy, which has in two hours made me realize how useless the start menu and browsing hierarchically is, and TaskSwitchXP, which although not perfect is a big improvement over regular alt-tabbing.  After reading your posts on Macs and on Window Management, I want to bounce a couple ideas off of you.</p>
<p>First of all, I think we both agree that the idea of the desktop as it exists now is broken.  It doesn&#8217;t necessarily need to be but when people can be lazy and save documents on it, then they will.  If you aren&#8217;t saving documents on it, though, what is it good for?  Well, you can put shortcuts to programs or folders on it.  Isn&#8217;t that what the Start Menu and Toolbars are for?  You can put widgets on it.  Isn&#8217;t that what the system tray is for?  Basically (again as you state) there are too many ways to do the same thing which do not offer anything unique.  Pick one and go with it.</p>
<p>So.  What I think the desktop and Start Menu/toolbar offer are essentially all the same things, with one important exception &#8211; the toolbar is the only place you can select from among your open windows.  Of the time you spend interacting with the window management system, this is probably what you spend most of your time doing, which is why it&#8217;s so annoying that the interface is so poor/slow.</p>
<p>So here finally are my ideas:</p>
<p>1.  Make the desktop a combination of the most useful features of Windows Task Manager, TaskSwitchXP, and the Start Menu.  A significant portion of desktop real estate would be a list of running applications, which can be grouped, switched to, terminated, etc, directly on the desktop.  These could be in a numbered list, allowing you to use a keyboard shortcut to type in the number.</p>
<p>2.  Make it easy to reach the desktop and obvious that this is where you now control things.  There could be an &#8216;always on top&#8217; button at the bottom of the screen for beginners, keyboard shortcut customizable.  Personally, I would like to throw my mouse to the bottom of the screen to show the desktop, or bottom left to auto switch back to the last app.  All configurable of course, but the default behavior should be almost as helpful as any customized behavior.</p>
<p>3.  Make (by default) every open program/folder its own &#8220;desktop.&#8221;  That is, it uses the entire screen (except for whatever button shows the desktop).  As you say, some people want you to believe that it&#8217;s nice to have small windows artfully distributed across the desktop, but when is it actually helpful?  I like the way (for example) Pidgin looks, but I keep it minimized all the time so it doesn&#8217;t even matter.  It shouldn&#8217;t be designed to look good small &#8211; it should be designed to run full screen and take advantage of all the available desktop when it&#8217;s being viewed.</p>
<p>4.  These &#8216;desktops&#8217; can be combined when necessary &#8211; ie you want to have two word documents side by side.  This solves your problem of having to click twice to bring them both back up.  You would be able to either combine running apps into one desktop, or specify when starting a new one which desktop it would join.  More on this in a second.</p>
<p>So this leaves a couple questions about how users begin running applications in the first place, and how they interact with files and such.  I propose that there be two hardlinks on the desktop &#8211; one to interact with programs, and the other to interact with user documents.  Basically the My Documents link that&#8217;s currently on the desktop, and the Programs folder that&#8217;s currently in the Start Menu.  However, these desktop links would be more akin to the easy sliding hierarchy of a toolbar folder than the annoying &#8220;open each folder in the same window&#8221; functionality of the current window system.  In addition, there should be a file browser with almost the exact same interface as Firefox &#8211; tabs for different folders, a favorites or quick links system, etc.  Basically whatever solutions we come up with to improve our internet browsing experience can be applied to our directory browsing experience as well.  The nested hierarchy view as a sole interface is ancient and horrible.  Probably this file browser I&#8217;m describing is ubiquitous in linux and I haven&#8217;t used it yet.</p>
<p>So users wouldn&#8217;t be &#8220;allowed&#8221; to store their files anywhere outside of this My Documents folder (hopefully just Documents so we can have a spaceless path to root . . .).  In addition, it would be nice if programs would create folders intelligently for themselves inside this Documents folder.  For instance, let&#8217;s say that Microsoft Word had been intelligently placed inside of a Office (not MS) subgroup in the Program Folders.  Then it&#8217;s default folder for saving files would be Documents\Office\Word unless the user specifies differently.  Eclipse would use Documents\Programming\Eclipse\workspace, etc.</p>
<p>And thus you can guess at the nature of the Programs menu  &#8211; it basically looks like the default KDE start menu &#8211; applications divided into sensible subgroups.  The only difference is that every program on the computer would be listed there, because it is the only way for you to launch them.  Perhaps you left click on it for all programs, right click on it for favorites.  Once you get used to Launchy it&#8217;s kind of irrelevant because you can type so much faster than you can use a mouse.</p>
<p>The last thing I can think of to allow on the desktop is widgets.  A clock, perhaps an IM widget.  Or perhaps not.  Maybe a good IM client uses transparency to good effect to show you new messages without interfering with your current focus.  Anyway there must be some things such that you do not want to have to perform an action to see the desktop, another action to see the thing (eg clock) then switch back to the former window.  So those things could get space on the desktop.  Perhaps there is a shortcut to show the desktop, then go right back to the window you were in.  Or maybe a key to make your current window temporarily transparent so you can see the desktop through it.  Amounts to the same thing I guess.</p>
<p>So to review: there are two branching links to programs and documents,  the TaskSwitchXP-like list of running apps (configurable of course for power users, ie processor usage, perhaps a separate section listing processes ala top), and any widgets configured to run on the desktop that don&#8217;t imitate or duplicate the functions of the previous items, and have some good reason for being on the desktop.</p>
<p>What do you think?  I think this would actually work pretty well with many of the ideas from your portal system, although there is some overlap in the ideas about how to display running apps for selecting among them.</p>
<p>We agree on the fact that it should be easy and quick to switch between running applications.  All my ideas about keyboard shortcuts apply as easily to your system &#8211; eg you could have a key shortcut to show the menu and a numbered system for selecting among them.  As I look around I become more convinced that I haven&#8217;t seen any of your ideas about what should actually be on the desktop instead of all the clutter that&#8217;s there now.  I realize the desktop is an illusion &#8211; a de facto full screen window to give users a warm fuzzy that their computer is &#8216;there&#8217;, but I do think it&#8217;s too valuable not to keep around and use it as well as possible.</p>
<p>Oh, something else I was going to add about program launching &#8211; let&#8217;s say you click on the program menu and want to start a program in the same window as another running app.  So you drag it out of the program menu and onto the app you want it to share space with.  There&#8217;s no reason to assume that dragging an app means trying to move it from folder to folder in the menu &#8211; in fact whenever I do this now it&#8217;s by accident, so let&#8217;s remove that possibility and put the move functionality somewhere else entirely &#8211; an &#8216;edit menu&#8217; somewhere.  There are probably other possibilities for dragging programs onto the desktop (which starts them running) that I can&#8217;t see right now.  Maybe you&#8217;ve got an applet such that when you drag an application onto it the applet asks for password and runs the app as root.</p>
<p>Man, you really got me typing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: brian will . net &#187; Portals: window management for those who hate window management (mockups in Javascript)</title>
		<link>http://brianwill.net/blog/2007/03/19/i-hate-macs/comment-page-1/#comment-630</link>
		<dc:creator>brian will . net &#187; Portals: window management for those who hate window management (mockups in Javascript)</dc:creator>
		<pubDate>Wed, 18 Jul 2007 05:54:17 +0000</pubDate>
		<guid isPermaLink="false">http://brianwill.net/blog/2007/03/19/i-hate-macs/#comment-630</guid>
		<description>[...] major design goal of my desktop UI design, which I&#8217;m calling &#8216;Portals&#8217;. Back in this post in March, I promised to present the Portals design, but I never quite finished the mockup demos in [...]</description>
		<content:encoded><![CDATA[<p>[...] major design goal of my desktop UI design, which I&#8217;m calling &#8216;Portals&#8217;. Back in this post in March, I promised to present the Portals design, but I never quite finished the mockup demos in [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Salsbury</title>
		<link>http://brianwill.net/blog/2007/03/19/i-hate-macs/comment-page-1/#comment-628</link>
		<dc:creator>Michael Salsbury</dc:creator>
		<pubDate>Tue, 20 Mar 2007 13:40:31 +0000</pubDate>
		<guid isPermaLink="false">http://brianwill.net/blog/2007/03/19/i-hate-macs/#comment-628</guid>
		<description>Great post.  I agree with just about everything you&#039;ve said here.  GUIs are definitely more disoverable then CLIs.  Advanced features should always be available but hidden from novices.  Users definitely should be made, beyond a certain point, to understand how the system works and not coddled by the OS to think it&#039;s all magical.  Icon view IS stupid, especially as the default setting, which it is in OS X.

I think I disagree with you on the desktop not being a place to keep files and folders.  While it does tend to get cluttered that way, it&#039;s also a useful way to quickly get at files you need frequently or use at the moment.  Microsoft took a step in the right direction with removing unused icons off the desktop automatically, but I do agree that there is probably a better way to handle this.

I&#039;ll be looking forward to your next installment.</description>
		<content:encoded><![CDATA[<p>Great post.  I agree with just about everything you&#8217;ve said here.  GUIs are definitely more disoverable then CLIs.  Advanced features should always be available but hidden from novices.  Users definitely should be made, beyond a certain point, to understand how the system works and not coddled by the OS to think it&#8217;s all magical.  Icon view IS stupid, especially as the default setting, which it is in OS X.</p>
<p>I think I disagree with you on the desktop not being a place to keep files and folders.  While it does tend to get cluttered that way, it&#8217;s also a useful way to quickly get at files you need frequently or use at the moment.  Microsoft took a step in the right direction with removing unused icons off the desktop automatically, but I do agree that there is probably a better way to handle this.</p>
<p>I&#8217;ll be looking forward to your next installment.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

