[comp.windows.x] Look and Feel? Or just Look?

barnett@grymoire.crd.ge.com (Bruce Barnett) (02/17/90)

Why do most people measure the "quality" of a window system on such
cosmetic features like 3-D buttons?

I have seen a lot of people on the net "judge" Motif vs. Open Look
mostly on the overall look of a UI, or else they select it because it
is what their vendor has supplied.

While I admit having a "sexy" UI is nice, but I haven't seen many people
compare OpenLook vs. Motif on non-religious issues.

Some say "Motif is like MS-Windows - therefore it is good."

I don't quite follow the argument. I think Mac and MS-Window users can
use both Motif and OpenLook without much effort. I would be interested
in some real studies that measure the learning curve of Motif vs.
OpenLook.

I have also seen a lot of people who are experienced in one window
system, use another for a few hours and then pass judgement.
These judgements tend to be biased and unfair.

Since I am not experienced in both Motif and OpenLook, I would like to
start a conversation concerning the real differences between the two.
(My goal is to learn more about both window system, and hopefully
learn more about the best features of both.)

Here are some questions to start some discussions?

	Is the UI easy to use? Does it require any documentation?
	Is it intutive?

	How easy is it to move and resize windows? 
	Is the mechanism intutive? Convenient?

	How easy it it to keep track of the keyboard focus?
	How easy is it to change the focus?

	Are there any mechanisms to help you keep track of
	the state (busy/idle/error) of each application?
	
	Is it easy to manage multiple tasks simultaneously?

	Is there any method used to group related windows?

	How easy is it to organize the window placement?
	Does the UI provide features for organizing your desktop?

	How convenient is the scrollbar?

	Does the UI support Selections well? How many types of
	selections? Is it intuitive?

	How well are choices (i.e. menus) presented to the
	user? What sequences of actions are needed to select
	menu items? How much screen real-estate does it require?
	Does this mechanism scale well? Can the menu system
	handle large choices well? (i.e. pick one option out of 100).
	How many actions does it take to make menu selections?
	Are there accelerators for these actions? Are they user definable?
	How quickly can the menu be browsed (assume no CPU delays).

	Is there a desktop metaphor? How complete is it?
	Drag and drop?

	Are there accelerators for common actions? Can you redefine them?

	Notices/Alerts - do they tell you which application caused the
	alert? What happens if two applications alert you at the
	same time?

Followups to comp.windows.misc - please.
And please, let's not get religious.	
--
-- 
Bruce G. Barnett	barnett@crd.ge.com	uunet!crdgw1!barnett

erik@sravd.sra.JUNET (Erik M. van der Poel) (02/18/90)

In article <5348@crdgw1.crd.ge.com> Bruce Barnett writes:

> I have seen a lot of people on the net "judge" Motif vs. Open Look
> mostly on the overall look of a UI, or else they select it because it
> is what their vendor has supplied.
> 
> ...
> 
> 	How convenient is the scrollbar?

Good question.

How many times have you had to check, very carefully, a large number
of lines of text, one by one? In such a situation:

    A. You want to scroll exactly one line at a time.

    B. If you accidentally go too far, you want to scroll back one line.

    C. Or you may want to scroll exactly one page at a time.

Now let's see how well some scrollbars meet these requirements. I
obviously don't know about all existing scrollbars, but here are some.
I expect that the NeWS people and others will follow up about
scrollbars that I do not mention.


X11R4 Athena scrollbar

 A. This scrollbar returns the position of the mouse relative to the end
    of the scrollbar when pointer button 1 or 3 is pressed. Xterm, for
    example, uses this distance to determine how much to scroll. So it is
    very difficult to find out where to position the mouse to scroll
    exactly one line. Of course, it is up to the application to decide
    what to do with the value returned by the scrollbar, but in any case,
    the appearance of the scrollbar does not make it immediately obvious
    to the user what needs to be done to scroll exactly one line.

 B. This scrollbar makes it easy to scroll up or down using pointer button
    1 or 3.

 C. It is difficult to scroll exactly one page (see above).


Motif & HP(Xw) scrollbars

 A. The arrows at the ends of the scrollbar make it easy to scroll exactly
    one line.

 B. Since the arrows are at the ends of the scrollbar, the user must move
    the mouse all the way to the other end to scroll in the other
    direction.

 C. It is impossible to scroll exactly one page.


Open Look scrollbar

 A. The arrows in the elevator make it easy to scroll exactly one line.

 B. Though the arrows are close together, the user must still move the
    mouse to scroll in the other direction.

 C. It is easy to scroll exactly one page, once the user finds out that
    clicking beneath the elevator can be used for this purpose.


X10R4 xterm scrollbar (a classic)

 A. The up-and-down arrow button makes it easy to scroll exactly one line.

 B. Since the up arrow and down arrow are in one area, it is easy to
    scroll in either direction using mouse buttons 1 and 3.

 C. It is easy to scroll exactly one page, once the user finds out that
    the shift key is held down for this purpose.


I could go on and on about the user interface, and also about the
programmer's interface, but I think I'll stop here.

Just one last thing: I have hacked the Xw scrollbar to produce one
that meets all of my 3 requirements. I could send copies to anyone who
is interested.


Erik M. van der Poel                  erik@sra.co.jp             (Japan)
SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku   erik%sra.co.jp@uunet.uu.net  (USA)
Tokyo 102 Japan. TEL +81-3-234-2692   erik%sra.co.jp@mcvax.uucp (Europe)

don@CS.UMD.EDU (Don Hopkins) (02/18/90)

In article <5348@crdgw1.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
>Why do most people measure the "quality" of a window system on such
>cosmetic features like 3-D buttons?

I have been wondering about this too. Are 3-D buttons any easier to
use? Is the 3-D "look" a metaphore or an illusion? That is, does the
apparent third dimension effect the "feel" in any way at all? I think
the "feel" is much more important than the "look". I'm not saying the
"look" is unimportant, it has a lot of effect on people's first
impression, especially if they're just looking over somebody's
shoulder instead of driving the mouse themselves, but when it comes
down to using a real user interface day after day after day, problems
with the "feel" are going to bug you a lot more than problems with the
"look". You just can't convey the "feel" of a user interface in a
glossy marketing brochure, and the slick Madison Avenue types seem
much more concerned with getting the right "look" than worrying about
the "feel". 

Think of choosing a user interface like choosing a roommate or a
sexual partner you're going to have to live with for a long time.
What matters more to you -- look or feel?

>I have seen a lot of people on the net "judge" Motif vs. Open Look
>mostly on the overall look of a UI, or else they select it because it
>is what their vendor has supplied.

What amazes me are the people who used to hate Open Look, but now that
it's 3-D, they love it. Are their opinions based on anything other
than cosmetics? Has the "feel" changed at all? Have they used it, or
just looked at pictures of the screen?

>While I admit having a "sexy" UI is nice, but I haven't seen many people
>compare OpenLook vs. Motif on non-religious issues.

>Some say "Motif is like MS-Windows - therefore it is good."

>I don't quite follow the argument. I think Mac and MS-Window users can
>use both Motif and OpenLook without much effort. I would be interested
>in some real studies that measure the learning curve of Motif vs.
>OpenLook.

Me too!

>I have also seen a lot of people who are experienced in one window
>system, use another for a few hours and then pass judgement.
>These judgements tend to be biased and unfair.

>Since I am not experienced in both Motif and OpenLook, I would like to
>start a conversation concerning the real differences between the two.
>(My goal is to learn more about both window system, and hopefully
>learn more about the best features of both.)

I have used and customized NeWS 1.1 a whole lot and used Open Look in
X11/NeWS. I've used SunView and the Macintosh a lot, and NeXT a little
bit, as well as X10 uwm which I modified to do pie menus, Xerox Star
(and Viewpoint), and LMI and Symbolics Lisp Machines. I have not used
Motif, because it's proprietary, and I can't afford it or convince
anybody to pay for it.

>Here are some questions to start some discussions?

>	Is the UI easy to use? Does it require any documentation?
>	Is it intutive?

Is it self documenting? Open Look has a "help" key that pops up a
magnifying glass window explaining how to use the control under the
cursor. The Lisp Machine has a status line at the bottom of the screen
that always tells what the mouse buttons and shift keys will do
wherever the mouse is pointing -- I like that a whole lot, other user
interfaces should have such a feature.

>	How easy is it to move and resize windows? 
>	Is the mechanism intutive? Convenient?

Motif has resize corners and resize edges. Open Look only has resize
corners.

One problem with Motif is that the entire window edge stretches the
window, and someone who uses Motif regularly tells me that they often
accidentally stretch their window edges when they only meant to move
the window. It's annoying when you try to move an 80 column xterm, and
end up with a 74 column xterm in the same place. It's hard to get it
back to exactly 80 columns. 

One problem with Open Look is that you can't stretch just one edge at
a time (to change just the height or width of a window), because
stretching a corner changes *two* edges. I use Open Look, and I find
the lack of edge stretch controls annoying. Stretching an edge is
something I want to do pretty often. Fortunatly, the NeWS toolkit
implementation of Open Look in X11/NeWS is easy to modify, so I fixed
it.  Now the modified version of Open Look I am using has stretch tabs
(not the entire edge like Motif, just a tab in the middle of the
edge), and I like it much better.

This brings up another issue that I think is more important than the
look: how easy is it to customize a particular toolkit? If it's easy
to customize, then you can improve the look and fix the feel.  Most
people may not be up to hacking the look and feel of their toolkit,
but if somebody makes some improvements and decides to put them in the
public domain for anyone to use (as I have done), how easy is it to
incorporate those changes into your user interface? In the case of the
NeWS toolkit Open Look, it's trivial.

And that brings up yet another issue: how many different toolkits
implement a particular look and feel? I know of three toolkits
implementing Open Look: the NeWS Toolkit, XView, and AT&T's X-Toolkit
based Open Look. I only know of one implementation of Motif: OSF's,
based on the X-Toolkit. I don't know what the Solbourn toolkit is
based on, but it implements both Motif and Open Look. 

>	How easy it it to keep track of the keyboard focus?
>	How easy is it to change the focus?

Can you choose between click-to-type and focus-follows-cursor, or are
you forced to live with one or the other? Open Look (at least the NeWS
toolkit and XView implementations that I know of) allows you to decide
which policy to use. I have not been able to figure out how to change
the NeXT user interface to use focus-follows-cursor, so unless anybody
can tell me how, I will assume that it forces you to use
click-to-type.  Personally I despise click-to-type. Yes it's a
religious issue, but I am pro-choice, I don't think things like that
should be decided in advance for you.

>	Are there any mechanisms to help you keep track of
>	the state (busy/idle/error) of each application?

Open Look dims the title bar to show that a window is busy.

>	Is it easy to manage multiple tasks simultaneously?

I think it's easier to manage multiple tasks simultaneously using the
focus-follows-cursor keyboard input distribution policy, because you
don't have to click on a window (bringing it to the top in the case of
the NeXT and the Mac) to type into it. The notion of one "current"
window is not compatible with multitasking. I think that clicking in a
window should perform the same action whether it's the "current"
window or not. When using the NeXT and the Mac, it annoys me when I go
to press a button in a window that is not the "current" window, and
nothing happens except that the window comes up to the top. Maybe I
wanted the window to stay underneath. Maybe the window covers up
another window I wanted to see, when all I wanted to do was press the
button and go use another window (like the one that was just covered
up). All I can do is grind my teeth while waiting for the windows to
repaint.

>	Is there any method used to group related windows?

Open Look allows you to select multiple windows and move them. It does
not have any provision for keeping then in a group after they are
deselected, though. Also, you can't do many other things to a group of
selected windows, like close them to icons, or destroy them. I can't
think of any reason why not, even though I want to do things like that
pretty often. An Open Look frame can have related sub-frames that the
applications has opened, that close when the application's main frame
closes, but the user has no control over that super/sub grouping of
windows, it's up to the application. Open Look frames have pin-up
menus. But a pinned up menu only effects the window that it was popped
up from. For example, if you have 5 frames, you can pin up 5 frame
menus all exactly the same except that they each effect different
windows. There is no way to pin up one frame menu that you can use to
control any frame. I would like to be able to point a pinned up frame
menu at another frame, perhaps by "dragging and dropping" a doo-dad
(maybe the pin?) from the menu to the frame I want it to effect. So I
could always have my one frame managment menu pinned up at one edge of
the screen, and use it to control any frame on the screen.

>	How easy is it to organize the window placement?
>	Does the UI provide features for organizing your desktop?

Snap dragging would be useful. Open Look windows stick to the edge of
the screen until you push them far enough over the edge. This is very
convenient for lining up windows with the screen edge, but I would
like for them to also stick to each other's edges, so I can easily
keep them from overlapping and line them up nicely.

>	How convenient is the scrollbar?

I like the way Open Look scroll bars work. They take up a bit too much
space on the screen for my tastes, and I'd like to be able to move
them to either edge of the window, though. 

>	Does the UI support Selections well? How many types of
>	selections? Is it intuitive?

The selection mechanism in the NeWS Toolkit in X11/NeWS is very
general. The user interface is independant from the application
interface, so you can implement various styles (point&adjust like Open
Look, or point&wipe like Mac) without changing the application. This
is a toolkit issue, not an Open Look issue, though.

>	How well are choices (i.e. menus) presented to the
>	user? What sequences of actions are needed to select
>	menu items? How much screen real-estate does it require?

Earlier versions of Open Look had rounded rectangle borders around
each menu item, to make them look like buttons. I thought it was a
real waste of screen real estate, and made the menus gigantic. Most
people aren't so stupid that they need menu items to look exactly like
buttons to keep from becoming confused. Fortunatly they fixed that. 

Open Look has something called a button stack, which is a (control
panel) button that you can press the (mouse) Menu button over to pop
up a menu of selections. The menu has a default selection, which is
shown with a rounded rectangle around it.  You can select any of the
items in the menu, or change the default by holding down the control
key. The (control panel) button stack's label shows the label of the
default menu selection, which you can select by simply pressing the
(mouse) Point button over the (control panel) button, without popping
up the menu. You can also pin up the menu, and select any of its items
multiple times without dismissing the menu.  The silly thing is that
the default selection of a pinned up menu is still displayed in a
rounded rectangle, which is no help at all, since the menu's on the
screen anyway, and selecting a pinned up menu default is no different
than selecting any of the other items, so it's just confusing to
distinguish the default selection of a pinned up menu.

>	Does this mechanism scale well? Can the menu system
>	handle large choices well? (i.e. pick one option out of 100).
>	How many actions does it take to make menu selections?
>	Are there accelerators for these actions? Are they user definable?
>	How quickly can the menu be browsed (assume no CPU delays).

Open Look has menus with scroll bars (like selection lists). I don't
think you get them automatically when there are a lot of items in the
menu, though.

>	Is there a desktop metaphor? How complete is it?
>	Drag and drop?

I like Open Look's "drag and drop" style of user interface very much.
The nice thing about it is that a "drag and drop" transaction conveys
a lot of usable information -- there are several degrees of freedom.
You press the button down over an object to pick it up, drag the
object to some other place on the screen, and release the button to
drop it. The thing you press the button over gets to decide what it is
you pick up (a window frame, a file icon, a piece of text), and the
thing you release the button over gets to decide what to do with the
thing dropped on it (a printer, a garbage can, a text input field, the
root background).  It can look at the *type* of the object dropped on
it and react appropriatly. (This is intimately involved with the
selection mechanism.)

>	Are there accelerators for common actions? Can you redefine them?

Open Look has function keys to perform various window managment
functions, but not all of them. (How can you stretch, resize, or move
a window from the keyboard alone? Arrow keys?)

>	Notices/Alerts - do they tell you which application caused the
>	alert? What happens if two applications alert you at the
>	same time?

Open Look frames can have text fields on the bottom edge of the frame
for displaying notices or status information. An Open Look application
can pop up a notification window that points to the place the cursor
was when the notification happened. The cursor is positioned over the
default button that usually makes the notice go away and puts the
cursor back where it was. I think a notfication window locks out other
notifications until dismissed.

>Followups to comp.windows.misc - please.
>And please, let's not get religious.	

Oops. Sorry about that, chief.

>Bruce G. Barnett	barnett@crd.ge.com	uunet!crdgw1!barnett

	-Don Hopkins
	 don@brillig.umd.edu

gary@CTC.CONTEL.COM (Gary Bisaga x4219) (02/19/90)

In <1463@sragwa.sra.co.jp>, Erik M. van der Poel writes:

	X10R4 xterm scrollbar (a classic)

	 A. The up-and-down arrow button makes it easy to scroll exactly one line.

	 B. Since the up arrow and down arrow are in one area, it is easy to
	    scroll in either direction using mouse buttons 1 and 3.

	 C. It is easy to scroll exactly one page, once the user finds out that
	    the shift key is held down for this purpose.

Perhaps, but I used SunView scrollbars for awhile (as well as, now, the Athena
ones) and, personally, I never can remember whether the left mouse button goes
UP or DOWN.  I found it difficult even to ascertain that I was moving in the
right direction, even though the text itself was scrolling.

I find the Open Look scrollbar to be very convenient; the fact that the up and
down arrows are a short distance apart (about 1/2 inch on my display) is not much
of a problem.  (To me, they're also aesthetically attractive; no "cute"
pseudo-3D-ness that makes for good marketing acceptance but no effect [positive,
anyway] on the interface usefulness :-)

Gary Bisaga (gary@ctc.contel.com)

ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (02/21/90)

> Why do most people measure the "quality" of a window system on such
> cosmetic features like 3-D buttons?

They don't.

> Some say "Motif is like MS-Windows - therefore it is good."
> 
> I don't quite follow the argument. I think Mac and MS-Window users can
> use both Motif and OpenLook without much effort. I would be interested
> in some real studies that measure the learning curve of Motif vs.
> OpenLook.

I would to, but the strength of the argument doesn't rely upon the
outcome of such a study.  There is a great deal of growth predicted in
the business un*x market.  The users in that market are very likely to
already know MS-Windows.  Moving a user from MS-Windows to OSF/Motif is
much easier than from MS-Windows to OpenLook.

> I have also seen a lot of people who are experienced in one window
> system, use another for a few hours and then pass judgement.

Yup.

> These judgements tend to be biased and unfair.

Your mother did you a terrible misservice if she taught you that life
would be fair.  ;-)

It is precisely because of this natural bias that Motif chose the
MS-Windows style of interaction.  We are going to be selling more and
more to people used-to/familiar-with MS-Windows and they are more
likely to respond favorably to something they already know.

-----------------------------------------------------------------------
Benjamin Ellsworth      | ben@cv.hp.com                | INTERNET
Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP
1000 N.E. Circle        | (USA) (503) 750-4980         | FAX
Corvallis, OR 97330     | (USA) (503) 757-2000         | VOICE
-----------------------------------------------------------------------
                     All relevant disclaimers apply.
-----------------------------------------------------------------------