OB3 important missing human-interface feature!

Clay Barnes clay.barnes at gmail.com
Thu Jun 15 06:45:46 EDT 2006


Well, depending on your interest in user-interface theory, it is
either a good or a bad thing that my 1200+ word (first half) treatise
on OB3-related human-interface design was totally hosed.  I'm pretty
upset, but C'est la vie.  I'll compose such things in seperate
files and just copy into mutt next time.

Let's start by assuming you have just read thousands of words on why
keyboards are a fundamentally better means of interacting with a
properly-designed window-manager (than a mouse), and that my arguments
were so brilliant and insightful that you wouldn't question my opinion.
I'll do my best to earn it, have no fear, but for now, I'll just give
the abbreviated spiel.

There are a very limited number of reasons that a user moves or resizes
a window: 1) make more space inside an application, 2) make space for
another application, 3) reveal another application, 4) (less common)
make less space for an application to overcome bad UI design that makes
a large space to sparce 5) (very rarely) a few misc. reasons that are
not relevant for the vast majority of users with any frequency.
To this end, designs like ratpoion, wmii, ion3, and the like are close
to optimal, but suffer serious the serious flaw of *requiring* maximal
effeciency of space use (which is often not preferred or comfortable
for end-users).

Now, to address the need for a window manager to permit the maximum
effeciency of operation, there is a single, very accutely missing
feature (and no, it's not a tile windows command---though it would be
helpful, it's not nearly as critical):  resize window to next edge.  The
command takes the specified edge of the active application and moves it
to be adjcent to the first edge it finds, either screen edge or
application edge.  This addresses the increase application size concern,
in that now a user can create a window, move it (using rough, large
increment skips mapped to four keys on the keyboard), and in a few
keystrokes (usually 4) fill exactly the desired space.

This brings to mind a serious flaw in the resize system:  it only works
with the south and east edges, which can be overcome with a move+resize,
but that fails to work with windows that resize by characters (terminals
and many plain-text editors like gvim (and xemacs?)).

I've a lot more detail to add, but It's about 4am here, and the car
needs to be taken to the shop at 7ish.

Incidentally, if I sounded cocky, I was just being flippant, and my
apologies.  Excuse the quality of writing and spelling, too.

--Clay



More information about the openbox mailing list