Re: [gtk-list] Widget user interface comments

[Kenneth Albanowski <kjahds kjahds com>]

On Fri, 11 Sep 1998, Michael Babcock wrote:

> Here's a list of ways I think Gtk widgets can be improved from a
> user's point of view.  This is with Gtk 1.0.5.
> 
> Button
> ------
> 
> When you press in a button, a black line is drawn inside the top and
> left edge of the button. To my eye this looks sloppy and out of place
> though I can't explain exactly why, or exactly how the appearance
> should be. In general, Gtk widgets look better than most Unix widgets,
> though I do worry a little that Rasterman and themes et al are more 
> concerned with "look" than with "feel".

The black line forms part of a deeper reverse shadow, thus conveying
"depressed" (so to speak ;-). I'll agree the effect looks slightly odd in
conjunction with the line surrounding the focused button. Nonetheless, the
general effect seems satisfactory, and certainly better then some other
widget sets. (If it ain't broke...)

As for the themes issue, I expect it won't be a problem if we more or less
ignore them (nothing personal, Carsten) and get on with making plain Gtk+
as decent as possible. Themes can simply follow our good example.

(And as for the general principle of themes, note that Kaliedescope for
the Mac, and its antecedents, not only provides a theme mechanism that
works very well and is widely used, but in fact provided "better" widgets
for MacOS some time before it itself supported them. Given this evidence,
I'd say that themes certainly do not need to be harmful.) 

(I'd also suggest that proper attention to contrast and gamma will make
themes, and pixmaps, a heck of a lot more useful...)

> Entry
> -----
> 
> Although you can doubleclick to select a word, you can't
> doubleclick-drag to select multiple words a word at a time. 
> 
> When you have something selected, perhaps pressing the left arrow key
> should move the cursor to the left of the selection, and the right
> arrow key to the right of the selection, rather than just moving the
> previously invisible cursor left or right inside the selection. I'm
> not sure about this one, but it would be something to try. I vaguely
> remember Windows doing this but don't have access to a contaminated
> machine to check.

Yes, it seems that the selection area effectively acts as a
larger cursor.

> Scrollbar / Slider
> ------------------
> 
> Clicking the down arrow or pagedown area  of a scrollbar should wait a
> bit after the first scroll before continuously moving while the mouse
> button is held down. It is too hard to scroll just one line.
> 
> The middle mouse click correctly causes a jumps to the selected position
> on
> the scrollbar, but you can't click-drag the middle mouse button
> around. You have to click the middle button once, and then
> explicitly grab the handle to drag. I use the middle drag feature
> all the time in Motif apps and it is disconcerting when it doesn't
> work in Gtk apps.

There's also the widget-drag concept of Tcl, which uses the middle button
inside the widget itself as proportional scrolling tool. I'm not sure the
result is easily used, but it is occasionaly useful, and occasionally
annoying in its absence. (One problem is that it isn't universal. There
will often be composite Tcl widgets that don't respect the scrolling
behaviour. A universal scrolling approach in Gtk+ would be very smart.) 

> I think scrollbars should by default be wider. I know we're following
> Motif, but I think new users find them too small.

I realize this isn't quite the right forum, but scrollbars are really a
Bad Idea (in the opinion of just about everybody who's written on the
subject), and better suggestions would be welcome. (Wheel'd mice aren't
bad, but don't have any notion of locality. And I don't think there is any
X support for the pointer'd mouse yet, which still doesn't have any
locality.) 

> Menus
> -----
> 
> This one might be controversial. While I do like the menu items
> highlighting when the mouse moves over them, I don't think submenus
> should automatically pop up without a click (obviously, if you drag the
> mouse to use menus, they will have to). The problem is that its too hard
> to "thread the needle" by moving the mouse pointer horizontally to the
> right to the submenu without moving it up or down to make the menu
> disappear. Another solution (Apple approach) is to have a little delay
> before the menu disappears after you move off the item, although I worry
> about the interface feeling sluggish. 

Actually, Apple doesn't do it this way, _Microsoft_ does. Apple instead
uses Magic. Specifically, as far as I can tell, the menu looks at your
mouse pointer, and de-selects the submenu if you aren't moving directly
towards the submenu. Yes, the Microsoft approach feels sluggish.

(And don't get me started on that damned "Start" menu. Using n'th nested
submenus, the single worst UI feature in the standard cannon, as the
primary interface feature... <shudder>. "Thread the needle", 'struth.)

> When a menu is displayed, clicking on the title again should make it
> disappear.

This is getting too fancy. Menus should be _simple_, and not have surprise
interaction modes.

Note that OS/2 sort of did what you were describing, by having two sorts
of submenus: the same sort as Gtk, and a different type where you could
also choose the "parent" entry directly, the usual notion being that the
parent entry was the default, and that if you wanted variants, you could
drill down to the submenu, by either (I forget which) moving the mouse
over the arrow (which looked a bit like a button), or clicking on the
arrow/button.

> Radio, Check Button
> --------------------
> 
> I have seen new users confused about which visual state means on
> versus off. We all are familiar with the Motif look, but I think
> perhaps by default, when check and radio buttons are "in" they should
> draw a mark in black inside to make it obvious.

I find this look incredibly bad. (Mostly I notice it when I'm filling out
some web form, and am unchecking the "I want to receive mail" button --
and it takes me a second to work out whether the check button in the
Netscape form is "in" or "out". Intuitively, I know which is which, but
I'm actually thinking about it, I have to work it out from first
principles. This is not good in a GUI element.) 

The usual approach is check marks in boxes (for the check boxes) and dots
in circles (for the radio buttons). What can I say, it works, and it isn't
too confusing. (But them comes the localization issues of check mark vs. 
'x', vs etc.)

> Tree
> ----
> 
> Personally I think the Mac look, with the left or down triangle and no
> dotted lines looks much cleaner than the windows look implemented in
> Gtk, with the + and - and the lines connecting everything. I think you
> can change this is your program (haven't checked though) but I'm
> talking about default experience from a user point of view, not what a
> developer can do.

It's called a "disclosure triangle", and yes the look is nicer, and,
incidentally, the little animation (of the triangle rotating through 90
degrees) seems to help just a little in using the Tree control. (The
problem, IMO, is that the Tree principle really doesn't work too well,
since the parent and siblings very easily get lost up at the top of the
control. By animating the disclosure triangle, you get a chance to see
just where you clicked, and some idea of what is going to happen in the
next split second -- which is important, because the next action will be
to hide or show a branch, which can completely alter the contents of the
Tree widget, thus tending to make you lose your place.) Microsoft, in
their wisdom, added "sliding" effects to their tree widget in recent
versions, which again seems to help a little, but also is often jarring,
and doesn't look right in all situations.

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)