Linked by Thom Holwerda on Sun 18th Nov 2007 15:46 UTC
Graphics, User Interfaces This is the sixth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV | part V]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part VI, we focus on the dock.
Permalink for comment 285033
To read all comments associated with this story, please click here.
phoenix
Member since:
2005-07-11

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

Reply Parent Score: 3