To Jason:
Always on top is inefficient if it potentially interferes with
another application's workspace. You also can't assume that the
application always on top is on a side of the screen. Also, having the
system automatically go to full screen when there are no windows in the
task bar is also naive. Imagine the scenario, "GAIM goes full screen".
Ugly ugly ugly...
The visual habit that is developed to opt to the right side of the
screen for a side-application is created by a comfort level we have with
the mouse. I would assume that you are right-handed. As for people who
are right handed, it is easiest to move the mouse away from you instead
of towards you, opting you to initially start using the right side of
the screen. When there is more than one side-app, the left side of the
screen is generally used as opposed to lining up next to the other
side-app. This is because we would like to focus on the center of the
screen rather than the sides. Our eyes have a tendency to be attracted
to light, having our center of focus decentralized would cause us to
catch the space that is next to our monitors which would cause us to
feel awkward when trying to give it our attention (our monitors do not
emit light outside of their screens). The side-app we give the most
significance too will probably take the right side of the screen.
These techniques of organizing for users are common for
multitasking. Several applications have been built to be side-apps, and
the way we organize our desktop environment using them removes usability
of some of its features. The most obvious one is the maximize feature.
If you maximize your central task window, you will cover your side task
window.
There are also difficulties in optimizing space allocation of a side
task. Namely, overshooting the screen and optimizing space-allocation
(taking up the entire side of the screen).
Certain features such as snapping have been developed in certain
Windows applications (ex. Winamp, Trillian) to overcome this problem of
ease of space allocation. You can also see it used internally in
programs such as Adobe Photoshop. If applied to all applications,
however, snapping could become frustrating. It has uses in
side-applications docking to the side of the screen and smaller windows
attaching to each other.
Snapping to the border of the screen should make the space taken by
the side-app ignored by maximizing another application. If someone's
trying to get away from your addicting side-tasks temporarily, they
might want to use the full screen. This problem is already answered by
having multiple workspaces (thank god).
It is my opinion that side-docking (this may include top/bottom) and
maximizing within side-apps should be developed. The problem has been
stated, now how would we go about solving it?
Brainstorm
-snap-to-edge while moving+resizing window (like trillian or winamp)
-individual dock-to-left, dock-to-right, etc. buttons on windows
-a docking function that is activated by some sort of mouse and/or
keyboard activity, or some button, and while holding the left mouse
button down, a side for docking is determined by the mouses location
relative to a static point. (This idea came after the prior two, but
before I started writing. In my opinion this outdoes the prior two).
So what I've discussed for this have been the desired functionality
(specialization for side-applications), brainstorm of interactions to
use desired functionality, and quite limited consequences of desired
functionality.
The most important part of this message is that we recognize the
side-application vs. maximize functionality problem. The new question
is, how do we solve this problem?
I bet you thought that was the only issue I was going to discuss.
Actually, I'm going to discuss every issue that can e discussed.
Users usually end up clustering smaller windows outside of
side-applications together. The problem is that each window is treated
independently. Wouldn't it be nice if you could cluster a set of small
windows and treat them as one window, or be able to minimize or view
them all at the same time? With tabbed applications I'm running into
this problem less often, but separate smaller windows are still good for
comparison purposes.
What's most important about this is that we identify a tendency of
group-dependency (users like clustering them) for smaller windows.
_______________________________________________
Usability mailing list
Usability@gnome.org
http://mail.gnome.org/mailman/listinfo/usability
