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
toml@ninja.Solbourne.COM (Tom LaStrange) (02/18/90)
I'll bite, even with my limited knowledge of Motif.
Is the UI easy to use? Does it require any documentation?
Is it intutive?
I think both are fairly easy to use but I'll tell you what I HATE about
Motif. I can never figure out which mouse button to press to pop up
a menu. If the mouse is in the menu bar or in the upper-left button of
the mwm deocration, it's mouse button one. If you are anyplace else
in the mwm decoration, it's button 2. At the OSF/Motif tutorial at the
X Conference I learned that pop-up menus should come up on button 3.
Open Look says that button 3 is the menu button. If an application has
a menu, it will com up on button 3. In this case I prefer the consitancy
of the Open Look interface.
How easy is it to move and resize windows?
Is the mechanism intutive? Convenient?
Both window manager provide resize corners in their decorations, so it's easy.
How easy it it to keep track of the keyboard focus?
How easy is it to change the focus?
By default both have click-to-type.
Are there any mechanisms to help you keep track of
the state (busy/idle/error) of each application?
I don't know about motif but Open Look clients can set a property on their
top level window informing the window manager that the application is busy.
The window manager can alter the deocration somehow to reflect this. This
of course is one of those private ICCCM protocol extensions.
Is it easy to manage multiple tasks simultaneously?
?
Is there any method used to group related windows?
Once again, I don't know about motif, but the Open Look spec says that
you can group windows by outlining them on with a rubber band rectangle
on the root window. I know olwm/R4 allows this. I think the only thing
you can do after grouping them is move them, but I may be wrong. Both
interfaces do limited grouping of applications and their transient 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?
Once, again, Open Look specifies a private ICCCM extension protocol to
implement this. I don't know about motif.
Are there accelerators for common actions? Can you redefine them?
I think this is really where Motif shines. Anything that can be done from
the mouse can be done from the keyboard. I'm not sure if they can be
redefined.
Sorry if I sounded too religious
--
Tom LaStrange
Solbourne Computer Inc. ARPA: toml@Solbourne.COM
1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml
Longmont, CO 80501don@brillig.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
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)
dbrooks@osf.osf.org (David Brooks) (02/19/90)
In article <22607@mimsy.umd.edu> don@brillig.umd.edu (Don Hopkins) writes: > >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. > On a point of, possibily excruciating, detail about mwm: 1. If you realize you've done this without letting go of the mouse button, you can just hit the escape key to cancel a resize (or move) operation. 2. It's actually quite easy to get back to 80 columns, if you have the resize feedback turned on. It gives you the current target size, in character increments if the application has hinted right. 3. You can turn off the resize handles: in .Xdefaults globally or by client, or from the client programmatically. You can still initiate the occasional resize by a single keystroke. -- David Brooks dbrooks@osf.org Open Software Foundation uunet!osf.org!dbrooks
montnaro@spyder.crd.ge.com (Skip Montanaro) (02/19/90)
don@CS.UMD.EDU (Don Hopkins) writes: barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > 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. Xrooms may provide some of the extra functionality you desire. I've only played around with it a bit, but it allows you to group related windows together into "rooms". Opening a room closes the windows associated with the current room to icons and opens the icons associated with the new room. Some windows (e.g., console xterm or emacs session) can be marked as always open. I believe a window can be in more than one room. One minor functional problem with xrooms is that if a window is not open in the current room, it is displayed as an icon. Individual window icons become pretty useless with (semi-)strict adherence to the room paradigm. (The xrooms window has a little button for each user-defined room.) You can get by most of this problem by stacking all icons together and under the xrooms window (which is by default always open). -- Skip (montanaro@crdgw1.ge.com)
gaf@uucs1.UUCP (gaf) (02/19/90)
In article <1463@sragwa.sra.co.jp> erik@sra.co.jp (Erik M. van der Poel) writes: [ Questionable statements about Motif's abilities deleted, except this one...] > C. It is impossible to scroll exactly one page. Gee, my applications will be very surprised to hear this. They still think that clicking on the space above or below the elevator moves the text forward or backward exactly one page, where a page is however many lines of text the box currently holds. I'd better not tell them. Wouldn't want them to suddenly stop working. -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
erik@sravd.sra.JUNET (Erik M. van der Poel) (02/19/90)
In article <247@uucs1.UUCP> gaf@uucs1.UUCP () writes: |In article <1463@sragwa.sra.co.jp> I write: | |[ Questionable statements about Motif's abilities deleted, except this one...] | |> C. It is impossible to scroll exactly one page. | |Gee, my applications will be very surprised to hear this. They still think |that clicking on the space above or below the elevator moves the text forward |or backward exactly one page, where a page is however many lines of text the |box currently holds. Well, the fact that I didn't know about this just goes to show how non-intuitive Motif's scrollbar is. :-( 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)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (02/19/90)
In article <22607@mimsy.umd.edu>, don@brillig (Don Hopkins) writes: >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. Does this mean that when you want to move a Motif window, you must grab the top border, instead of any one? The Mac's make you grab the top border, which is a real pain when the top border is covered. What required one drag in OpenLook requires on a Mac: Click on portion of window to make the top border visible. Move the mouse cursor to the top border. Drag the window to the new location Click on the original window to make it the one on top. >> Does the UI provide features for organizing your desktop? > >Snap dragging would be useful. What is snap-dragging? >Open Look has something called a button stack [..] >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. The default selection is useful if you want to just click on the button stack instead of bringing up a menu. If you had a large pull-right menu that allows you to pick a font or whatevern, you can hold the selection button down and preview the choice without calling up the menu. If you like the default, you release the mouse button. If you don't - you drag the mouse cursor away from the button. I don't like to use pin-up menus all of the time. Some tools can have 4 or more pin-up menus at once. This does take up real-estate. And compicates things when you move windows to the top or bottom. What happens to the pin-up menus? Do they stay on top? Are they connected to the parent window? One of the problems with OpenLook is that they have not specified how to define a keyboard equivalent to the menu choices. >>And please, let's not get religious. > >Oops. Sorry about that, chief. Always glad to read from "The Book of Don". -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
peter@ficc.uu.net (Peter da Silva) (02/20/90)
> Well, the fact that I didn't know [that clicking above or below the knob > moves up or down a page] just goes to show how non-intuitive Motif's > scrollbar is. :-( And the fact that I didn't know that the barely discernible color difference on the cable shows the proportion visible just goes to show just how non intuitive Open Look's scrollbar is. :-> Seriously, you can't expect to magically glark *everything* right off. You had to learn how to point and click, didn't you. I know, one day we'll have a direct cerebral interface and this business of learning a few rules about a UI will go by the wayside. We'll just know it all intuitively, just the way we know the real world. Yes, that statement is sarcastic. As a daddy I know all to well how the real world isn't always intuitive... -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
barnett@crdgw1.crd.ge.com (Bruce Barnett) (02/20/90)
In article <1464@sragwa.sra.co.jp>, erik@sravd (Erik M. van der Poel) writes: >In article <247@uucs1.UUCP> gaf@uucs1.UUCP () writes: > >|Gee, my applications will be very surprised to hear this. They still think >|that clicking on the space above or below the elevator moves the text forward >|or backward exactly one page, where a page is however many lines of text the >|box currently holds. > >Well, the fact that I didn't know about this just goes to show how >non-intuitive Motif's scrollbar is. :-( I don't think this is a fair comment, because unless I misunderstand, OpenLook has the exact same model for paging forward/backward pages. So does the Mac. An example of a non-intutive scrollbar was the one on SunView, which used all three mouse buttons, and a button modified with a shift key to move back a page. To be honest, I am impressed with the OpenLook scrollbar. Look at all of the operations it supports with a single click: Go to beginning Go to end Move up/down one "line" May be repeated without moving the mouse Button may be held down to scroll. Move up/down one "page" May be immediately repeated without moving the mouse Button may be held down to scroll by pages Can drag box to "absolute" location. Also, IMHO, all of these operations are intuitive, and only require the mouse selector button. The mouse select button is also used to split the object into two or more views. This is done by dragging the top (or bottom) anchor towards the middle of the scrollbar. Considering how often I want to look at a history log and type something new in, or how often I split a buffer in GNUemacs, it's a feature I miss in other implementations. OpenLook also suppports pop-up menus in the scrollbar region, which can be used to handle more advanced methods of accessing views. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
erik@sravd.sra.JUNET (Erik M. van der Poel) (02/21/90)
In article <5379@crdgw1.crd.ge.com> Bruce Barnett writes: > In article <1464@sragwa.sra.co.jp>, Erik M. van der Poel writes: > > >Well, the fact that I didn't know about this just goes to show how > >non-intuitive Motif's scrollbar is. :-( > > I don't think this is a fair comment, because unless I misunderstand, > OpenLook has the exact same model for paging forward/backward pages. My comment was not intended to compare the Motif and Open Look scrollbars. Have you read my previous article <1463@sragwa.sra.co.jp>? In that article I implied that even the Open Look scrollbar's paging is non-intuitive. My modified Xw scrollbar has one area with two arrows, to go up or down one line using the left and right mouse buttons, and it has one area with a page symbol, which also responds to left and right mouse buttons. The third area is just an ordinary slider. The page area is intuitive, because the user can *see* that it is a page. Some people don't like having to use two mouse buttons to change the direction of scrolling. Fair enough, everyone has different tastes, right? But the reason that *I* like it is because I once caught myself trying to change the scrolling direction in an Xw scrollbar by hitting the other side of the mouse. This reflex action comes from the fact that the X10R4 xterm scrollbar worked that way. In "Window Systems Should Be Transparent" (Usenix Computing Systems, Summer 1988), Rob Pike writes that "typing backspace becomes second nature" for keyboard operators who correct mistakes, and "that people do so subconsciously. That is the mark of a successful interface." Rob Pike writes about lots of other things too, such as visual cues. I think that his paper is a must for anyone interested in user interfaces. 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)
nazgul@alphalpha.com (Kee Hinckley) (02/21/90)
In article <1990Feb17.223729.21903@Solbourne.COM> toml@ninja.Solbourne.COM (Tom LaStrange) writes: >the mwm deocration, it's mouse button one. If you are anyplace else >in the mwm decoration, it's button 2. At the OSF/Motif tutorial at the >X Conference I learned that pop-up menus should come up on button 3. I agree that the M1 vs. M3 distinction is strange (M1 selects, M3 is the menu button), a selection on a Cascade Button results in a menu, thus the confusion. However the 2 vs. 3 problem is probably historical, early versions had M2 as the menu button. > the state (busy/idle/error) of each application? > >I don't know about motif but Open Look clients can set a property on their Motif specifies a standard "working" dialog box. > Is there a desktop metaphor? How complete is it? > Drag and drop? Motif explicitly did not specify a desktop metaphor because the OSF membership thought that there would be plenty of 3rd parties competing in that area and the market should have a chance to make some choices first. OL's connections between the toolkit and the desktop manager are nice, but it's not clear to me how an app can get the user to select a file if you aren't running OL's desktop manager (and personally, I'd rather run Looking Glass). >I think this is really where Motif shines. Anything that can be done from >the mouse can be done from the keyboard. I'm not sure if they can be >redefined. Depends on the app, yunless they hardwire them you should be able to use the standard app-defaults mechanisms. ---- In-Reply-To: barnett@crdgw1.crd.ge.com (Bruce Barnett) > >Does this mean that when you want to move a Motif window, you must >grab the top border, instead of any one? The Mac's make you grab the >top border, which is a real pain when the top border is covered. No. The window manager allows you to define the mapping and menus that go with any key. 'Alt-M1' (at least in my defs, and I think it's standard) lets you drag the window when the mouse is anywhere over it. ---- In-Reply-To: don@brillig.umd.edu (Don Hopkins) >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 I think 3D (beveled actually) is a little easier for people to initially use because it's a more real-life metaphor. After that though, there probably isn't a big difference. I agree on the difference between look and feel though, in fact that is a distinction made very clear by Motif, where the feel is a mandated part of the style, but look is optional. Note that a "3D" Open Look on the other hand, is no longer Open Look, because it violates the pixel by pixel discriptions in the Open Look Style Guide. >>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 agree on the need for studies, but my experience just switching between Mac apps which differ in things like commands to print, commands to align, commands to... says that those things can be at the least very annoying, and at most dangerous. >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. Solbourne, from what I saw, does not yet do a Motif compliant toolkit Frankly I'm *glad* there's only one Motif toolkit. Sure it's nice to be able to experiment with different approaches, particularly in an academic environment, but I need to get product out there. I don't want to have to port a toolkit everywhere I go, I want to find it there waiting for me, and supported by the vendor. Show me an Open Look toolkit for which you can say that across >50% of the vendors. >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 Ditto Motif. -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | BBS: 617/641-3722 | | Arlington, MA 02174 | Dumb fax, dial number, | | | nazgul@alphalpha.com | wait for ring, press 3. | BBS line is still dead | +-----------------------------------------------------------------------------+
schoeller@4gl.enet.dec.com (Dick Schoeller) (02/22/90)
In general, I agree with your scroll bar assessment (esp. the Athena scrollbar, blech). However, on the Motif scrollbar you missed something. > C. It is impossible to scroll exactly one page. If you click above or below the slider (and not in an arrow) the scrollbar should move 1 page in that direction. It is up to the application (or possibly the user with .Xdefaults) to set the page increment (ie: a page move may only be half of the window rather than the whole). Dick Schoeller | schoeller@4gl.enet.dec.com Digital Equipment Corporation | 603-881-2965 110 Spit Brook Rd., ZKO2-3/R56 | "Either Judaism has something to say to the Nashua, NH 03062-2642 | world or it has nothing to say to Jews." | - Dennis Prager
toml@ninja.Solbourne.COM (Tom LaStrange) (02/22/90)
> I think 3D (beveled actually) is a little easier for people to initially use > because it's a more real-life metaphor. After that though, there probably > isn't a big difference. I agree on the difference between look and feel > though, in fact that is a distinction made very clear by Motif, where > the feel is a mandated part of the style, but look is optional. Note > that a "3D" Open Look on the other hand, is no longer Open Look, because > it violates the pixel by pixel discriptions in the Open Look Style Guide. What? I have in front of me a copy of the "OPEN LOOK Graphical User Interface Function Specification, Release 1.0" dated May 1, 1989. If you go to page B-90, you will see specifications for what 3D Open Look is supposed to look like. If you also look at the book published by Addison Wesley of the same title, chapter 9 is called "Color and Three-Dimensional Design." So yes, the 3D Open Look does not follow the pixel specifications for monochrome Open Look, it follows the specifications for 3D Open Look. I like having the two specifications, <religion on> I personally think motif looses the appearance race in monochrome <religion off>. > Solbourne, from what I saw, does not yet do a Motif compliant toolkit > Frankly I'm *glad* there's only one Motif toolkit. Sure it's nice > to be able to experiment with different approaches, particularly in > an academic environment, but I need to get product out there. I don't > want to have to port a toolkit everywhere I go, I want to find it there > waiting for me, and supported by the vendor. Show me an Open Look > toolkit for which you can say that across >50% of the vendors. What is a Motif compliant toolkit? OSF has no certification process for toolkits. We've asked. Unless they've changed something in the past month or two, all they have is a certification process for applications. There are no Motif compliant toolkits, not even the one shipped by OSF, only applications. Solbourne's toolkit allows you to write Motif compliant applications, I have the checklist here, it's not that difficult. Certainly you can take OI and write a non Motif compliant application but you can do the same with the Motif toolkit. The hard part is, how to write an application that conforms to BOTH the Motif and Open Look style guides, they're not that much different, but enough to make it a pain in the butt. This is an area where AT&T and OSF are going to have to start talking if this look-and-feel war is ever going to merge. You didn't think you were going to ask about Look-and-Feel opinions and not get a little bit of religion did you? :-) -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
barnett@crdgw1.crd.ge.com (Bruce Barnett) (02/22/90)
>Note >that a "3D" Open Look on the other hand, is no longer Open Look, because >it violates the pixel by pixel discriptions in the Open Look Style Guide. My, you speak wich such authority! :-) I have a copy of the Functional Specification, dated August 31, 1989, and it gives examples of the 3-D look. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
sandy@scooby.cs.umass.edu (Sandy Wise) (02/23/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? And don@brillig.umd.edu writes in reply: 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". The 3d look folks will claim that 3d presentation is in fact easier to use based on the semantic feedback provided. A control is evident because it "sticks out" of the work surface. Of course, in Motif, separators are 3d - I guess this is to keep the "look" consistent at the price of the "feel." This does raise an interesting question about how to resolve such conflicts. I suspect it has been resolved in the favor of "look" not because any thought was given to it, but rather that a nice "look" sells product... What amazes me are the people who used to hate Open Look, but now that it's 3-D, they love it. The one part of an interface's "look" that obviously affects the user is that it be unabtrusive. I have not seen OL3d, and have not used OL at all, but looking at the color and B&W screenshots I will note, that the color OL is much less intrusive that the B&W ones. My initial reaction to B&W OL is "it's ugly". Of course, I recall a thread in which Motif was called "Art Deco" and while I like deco, and resent it being used as an insult ;-) I am reminded about the old adage of where beauty lies... > 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. Motif skirts the magnifying glass through the help menu item, and a help button on dialog boxes. I have yet to see anyone provide status line stuff. The LM, Explorer, and other lisp enviroments offer it... I suspect this is an example of the comparative maturity of the interfaces... This brings up another issue that I think is more important than the look: how easy is it to customize a particular toolkit? And of course, the flip side - if you support interface customization, what happens to the grand dream of standardization... > 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? Motif separates focus and raise into two issues. I also hate click to type, and use focus-follows-pointer but not auto-raise. > 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. The only notification that Motif provides is the "busy cursor" when in the window. The OL spec points out the problems with this approach. > 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. I don't like objects to warp the pointer, which the scrollbars do, but this is personal taste. The OL scrollbars have an interesting feature in the ability to split viewports. I do have some questions though - if a viewport has both H and V scrollbars, how is screen real estate allocated to make room for the scroll bar? And more important - how are menu actions associated with viewports? If you have click to type - you can set focus, but for focus-follows-pointer this is not clear to me... > Are there accelerators for common actions? Can you redefine them? Motif is very good about this. Everything is supposed to have an keyboard equivalent, and they are supposed to be defined in the configuration files. > Notices/Alerts - do they tell you which application caused the > alert? What happens if two applications alert you at the > same time? Motif associates modal dialogues with the application, so you can use another app. Also, the dialogues are defined to be always within the borders and above the application. This is not as visually informative as the "zoom" effect used by OL, but also saves real estate. -- WISE@cs.umass.EDU Arxin@UMass.BITNET Alexander Erskine Wise Software Development Laboratory Disclaimer: The opinions above are ficticious, any similarity to opinions living or dead is completely co-incidental.