To read all comments associated with this story, please click here.
Sorry if it seems like an attack, but I have something to say on virtually every point you bring up
Something to keep in mind about the notoriously awful clippy, is that it was the implementation, not the idea that blew.
First off, there was a 10 second animation before and after EVERY event. That is an eternity when it comes to UI elements. Secondly, it was a large floating element that was constantly obscuring some element you wanted to access. Thirdly, it was next to impossible to get rid of, every time you thought you did, it just came back.
All that being said, a contextual help area that is constantly being updated based on what the user is doing is a fantastic idea. The horrible implementation in Office has unfortunately soured people to it. If someone could come with an implementation similar to tooltips (there when you want it, invisible if you dont need it), IMHO it could be a fantastic way of doing inline help.
The problem with hiding the dock (or panels of any sort on other operating systems) is that the trigger area for showing it is WAY to large. If (for example), the trigger was in the lower left hand corner, and as soon as your mouse hit it, the dock would expand out, anchored from the left side of the screen, you would get the desired functionality, while very rarely triggering it accidentally. When the bottom five pixels of the entire monitor triggers the show operation, you will trigger it accidentally far more often then on purpose.
As for it taking space, as can be seen from the Fitts' Law article, the larger the hit area, the easier it is to aquire the target. 4x4 icons may be really pro, but it is exponentially easier to hit 16x16. It really comes down to a tradeoff between work area chewed up, and difficulty in hitting the target. I am a big fan of the quicklaunch in windows (I hate, hate, hate the start menu, and always have), but even with that I will semi-regularily launch the wrong app by mistake, due to the small size of the icons.
All that being said, a contextual help area that is constantly being updated based on what the user is doing is a fantastic idea. The horrible implementation in Office has unfortunately soured people to it. If someone could come with an implementation similar to tooltips (there when you want it, invisible if you dont need it), IMHO it could be a fantastic way of doing inline help.
Newer versions of Word, most versions of WordPerfect since 8 or 9, and a few KDE apps do this. They put a ~2" column along one side of the screen (right for Word, left for WordPerfect). This area is used for displaying contect-sensitive help links, useful hints, and similar stuff. On low-resolution setups (< 1024x768) it's more annoying than anything as it takes up ~ 33% of the horizontal screen space. But on higher resolution setups, it's not that bad.
The WordPerfect implementation is a lot nicer than the Word implementation. It's actually useful. Especially when it's part of their wizards or perfectexpert projects or whatever they call it.
The problem with hiding the dock (or panels of any sort on other operating systems) is that the trigger area for showing it is WAY to large. If (for example), the trigger was in the lower left hand corner, and as soon as your mouse hit it, the dock would expand out, anchored from the left side of the screen, you would get the desired functionality, while very rarely triggering it accidentally. When the bottom five pixels of the entire monitor triggers the show operation, you will trigger it accidentally far more often then on purpose.
Not sure about GNOME or XFce, but the KDE external taskbar and kpanel can be configured like that. Enable the left or right hide buttons and auto-hide. 3 seconds (or so) after your mouse leaves the panel, it will zip off to the side appearing as thin bar with an arrow down in one corner. Pop the mouse down to that corner and click to bring it back.
Personally, I can't stand the dock concept, and prefer to put a taskbar at the bottom of the screen that only shows running apps. And an app launcher at the top of the screen with just the apps menu, some quick launch shortcuts, the system tray, and clock. Set to auto-hide. Since it's only used to launch apps, it doesn't need to be visible all the time. And since the taskbar only shows running tasks, it doesn't need to be very tall (32px is plenty). It's a beautiful setup in KDE; GNOME and XFce are a little more difficult to get working right, but once it's configured, it works the same.
Separate running apps from non-running shortcuts/repositories/launchers/etc. Only show the info that is needed. Hide everything else until it's needed.
Edit: Why doesn't the quote feature [ q ][ /q ] work on the the v4 setup???
Edited 2007-11-18 22:08 UTC
Well, my comment about MS Clippy help app may not have been a very good one anyway, as it is not so much related to the subject here. My point in mentioning it was only to give some kind of an example about looks vs. real usability. So putting emphasis on aesthetics does not always improve usability.
"4x4 icons may be really pro, but it is exponentially easier to hit 16x16."
Of course you're right about that. And there's absolutely nothing pro about too tiny 4x4 icons IMHO... ;-) Anyway, in Gnome I make my top and bottom panels 21 pixels high (possible with certain fonts like Free Sans) which is plenty enough in order for them to remain both clear to see, easy to use, and narrow enough so that they take minimum amount of space and can contain maximum amount of shortcuts or applets if I prefer to have them there.
"I am a big fan of the quicklaunch in windows (I hate, hate, hate the start menu, and always have)"
But start menus are - for a very good reason - found in almost all desktop environments. You tell that you hate them but fail to explain why? Care to elaborate?
I still wait to see a better way than a handy start menu to show, browse and get access to all the available applications? A start menu - of some sorts - seems like a necessity as far as I can tell. Running commands would be another way to browse, find and open apps - but not very newbie-friendly. The place where the start menu is located or can be opened is not essential. Some window managers have a "start menu" that can be opened by right-clicking the desktop background, but that is still the same start menu, and is also more difficult to reach if the desktop background is hidden under open windows.
Still about docks in general:
Mac OS X dock (and maybe many of its "copies" too) looks really nice. In aesthetics Mac OS X may be a clear winner. But what comes to functionality I prefer the old though maybe a bit dull looking taskbar. Not only does taskbar take much less desktop space but textual shortcuts of the taskbar show much more clearly than mere graphical icons what each shortcut represents. If you have, say, 10 open folders, and you can see only 10 similar looking folder icons side by side on the dock, which is which?
Mac OS X dock has some really nice features, though, like docklings and the availability of extended menus that control applications without making them visible on screen - but that could be implemented with a taskbars too.
Edited 2007-11-18 23:50 UTC





Member since:
2005-07-08
One problem related to pretty looking docks, huge wide panels & other supposedly helpful desktop desktop accessories (a bit like the notorious MS Office paper clip assistant) is that (especially if they are meant to look nice and pretty with big icons etc.) such apps tend to take quite a lot of desktop space and eat a lot of system resources that might be more useful for actual applications. Ok, maybe you can hide the dock when you don't want to see it, but often that may be rather troublesome too. Personally I tend to prefer very narrow panels with essential shortcuts that are always visible but do not distract or take much desktop space away from actual apps that I want to use.
An off-topic joke related to the article image: http://www.osnews.com/img/18941/arthur.gif
See, Ubuntu is not the first desktop environment that has preferred orange and other warm colors instead of blue and gray...
Edited 2007-11-18 19:28 UTC