barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/20/89)
Followup to comp.windows.misc. please. In article <6594@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise >drop it to back. I HATE this in window systems that have this "feature". I set up the windows the way that I like, and some window system keeps moving my windows around when I don't want to. Example: I want to look at a large window 'cause it has a manual page, data or source, but do work in a smaller window on top of the first. Then I want to select something in the "back" window and move/copy/paste it in front. BANG! my small window goes away. Grr! This is a real pain when the small window is completely covered over by the large window, and both windows are on top of a dozen other windows. It might take me a dozen actions to undo the changes of this "helpfull feature". When I set up my windows, I don't want them changed! But, you ask, how do you change this? >What does 'selecting' a border usually do? Bingo! A lot of window systems use clicks on the border of a window to specify window-manager actions. These clicks can therefore be used to change window hierarchy, iconify state, move or resize windows, or pop up the menus that all window-based applications have. But inside the window, you can make that program use any sort of chord like Shift-Meta-Control-DoubleClick left, middle and right mouse buttons. I have that chord defined to update the database in my Watch! Well, not really. Maybe next week. :-) -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
peter@ficc.uu.net (Peter da Silva) (10/24/89)
I said, with respect to depth gadgets: > >Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise > >drop it to back. In article <3400@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > Example: I want to look at a large window 'cause it has a manual page, > data or source, but do work in a smaller window on top of the first. > Then I want to select something in the "back" window and > move/copy/paste it in front. BANG! my small window goes away. Grr! I agree. That's a total botch. That's why I didn't suggest it. I was talking about how to overload to-front/to-back on a single gadget, so you don't have to have two depth-arranging thingies. > >What does 'selecting' a border usually do? > Bingo! > A lot of window systems use clicks on the border of a window to > specify window-manager actions. And of course the border is just a *fine* depth/resize gadget. Go back and re-read the article I was following up to. > But inside the window, you can make that program use any sort of > chord like > Shift-Meta-Control-DoubleClick left, middle and right mouse buttons. Noooooo! chording/double-clicks/etc are a kludge. One button -> one action. If you want to do something more complex, use a menu or a poke point. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "I feared that the committee would decide to go with their previous 'U` decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/25/89)
In article <6647@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >I agree. That's a total botch. That's why I didn't suggest it. Sorry for the mis-understanding. Terminology can be confusing, especially when each of us understand our window system so clearly! :-) >> But inside the window, you can make that program use any sort of >> chord like >> Shift-Meta-Control-DoubleClick left, middle and right mouse buttons. > >Noooooo! > >chording/double-clicks/etc are a kludge. One button -> one action. If you >want to do something more complex, use a menu or a poke point. Nooooooo! First of all, I want a window system that allows me to customize the HECK out of it. I want to be as efficient as possible. Also, as I have stated before, The use of such complex bindings should be as accelerators - unnecessary for the new user, but available for the power user. If such accelerators are there and you don't want to define/use them, fine! But if I want to do this, I should have the ability to make myself more efficient. I must admit that I don't often do this. There are lots of key combinations in emacs that I have not memorized yet, and I have been using emacs for two years. But that is beside the point. Next year I will use them. Here are some specific examples of complex actions bound to chords that I do not consider a "kludge". 1) I have the ability to point to any spot in my window and with a Control-Meta Left click, I can execute a keyboard macro at the spot I am pointing too. I don't want a menu. (I don't know what a "poke point" is.) I just want to (doit) at the exact point I am pointing too. Any other method would slow me down. Why on earth would I want a menu for such an action? 2) Many mouse based editors support single clicks to select a character, and multiple clicks to select words, sentences, paragraphs or entire documents. This is a great timesaver! I don't have to use it, but since it's there, I use it all the time and miss it when it's not available. As an example, if I wanted to include an entire file in another document, and I had a viewing window open on that file, I routinely do a secondary paste, which is accomplished by a) Holding down the paste button b) Moving the mouse to the other window with the text to be included It can be ANYWHERE inside the window. c) Click the mouse 4 times to select the entire document d) Release the paste button. In the window system I am using now, two clicks selects text in word mode, three clicks is line mode and four clicks is the entire document. If instead I wanted to select just a few paragraphs, I would use three clicks to select the first line and a single click on the last line. The clicks can be anywhere on that line, so I can quickly select lines without precisely positioning the mouse. This is very easy to learn AND fast in execution. It is also consistent. The more clicks you use the larger the unit of selection. Also - when you do a multiple click, the position of the insert point is rounded to the nearest unit. So if I triple click on a line, the text insertion will be either the beginning or the end of the line, depending on which end I was closest too. Some window system have no way to efficiently select blocks of text or to position the insertion point at even unit boundries. Using chords/multiple-clicks allows the power user to quickly and accurately perform the desired function. Multiple clicks are also the second easiest thing to do with a mouse. Any other action, like poping up a menu, really slows down the user (With the exception of Don Hopkins Pie Menus, which can be selected before the menu appears. You can even select an item from a nested menu before it appears!) I could go on and on. I hope I have made my point. I just had a flashback. I remember a conversation I had a year ago when someone was arguing that there was no need for more than one mouse button. My argument defending multiple mouse buttons is very similar to my defending chords and multiple clicks. Yes! you can get by with a single mouse button. Yes you can get by without double-clicks and keyboard-click combinations. But just because YOU may not want to use them doesn't mean they are a "kludge". I will agree that some systems are a kludge. But certainly not ALL. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
peter@ficc.uu.net (Peter da Silva) (10/26/89)
I said: > >chording/double-clicks/etc are a kludge. One button -> one action. If you > >want to do something more complex, use a menu or a poke point. In article <3581@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > First of all, I want a window system that allows me to > customize the HECK out of it. I want to be as efficient as possible. Ah, another misunderstanding. I'm not talking about user-defined short-cuts. I'm talking about the normal dumb-new-user-on-new-account mode. Sure, let people customise the window system all they want. But an application should, by default, conform to a simple convention that doesn't involve double-clicking, shift-clicking, chording, and so on. > Also, as I have stated before, The use of such complex bindings > should be as accelerators - unnecessary for the new user, but > available for the power user. Like I said, another misunderstanding. > (I don't know what a "poke point" is.) SCADA industry terminology for an active area on the screen, like a close icon on a window border. > 2) Many mouse based editors support single clicks to select a character, > and multiple clicks to select words, sentences, paragraphs or entire documents. This doesn't have to be handled with timing, though. I use such a tool, and it works by seeing, on each click, whether you're still on the same character. If so it cycles the scope. [lots of shortcut examples deleted] > Any other action, like poping up a menu, really slows down the user > (With the exception of Don Hopkins Pie Menus, which can be selected before the > menu appears. You can even select an item from a nested menu before it appears!) I've heard of these. They sound cool. That's an implementation detail, then. On the Amiga, for instance, the menus don't go through the layers system: the screen is frozen while the menu is up, but because it's so fast the screen isn't frozen for very long. Summary: let the user do whatever she wants, but don't require him to learn any more than select/perform/menu. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/26/89)
In article <6685@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >I said: >But an application should, by default, conform to a simple convention >that doesn't involve double-clicking, shift-clicking, chording, and so >on. YES!! We're not arguing. We're just trying to talk the same language! >> Any other action, like poping up a menu, really slows down the user >> (With the exception of Don Hopkins Pie Menus, which can be selected before the >> menu appears. You can even select an item from a nested menu before it appears!) > >I've heard of these. They sound cool. Don is a very cool dude. For people how haven't seen them in action, Pie Menus allow you to select an action by moving the mouse to the proper up/down/left/right pie slice. You can select an item without waiting for the menu to appear, because you move in a direction that is consistant. If you move to a slice, and click again, you can go to the next menu before the first one appears. This can be nested so that you can click ahead several menus. The best part is when you are able to click ahead, Don's software shows a round gray circle with a slice removed - the one item you selected. It sort of looks like a PacMan. He was thinking of a way to keep count of the number of times you can select a menu before it appears, so that at the end of the day you can compare PacMan scores! :-) -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
drforsey@watcgl.waterloo.edu (David Forsey) (11/04/89)
>For people how haven't seen them in action, Pie Menus allow you to >select an action by moving the mouse to the proper up/down/left/right >pie slice. You can select an item without waiting for the menu to appear, >because you move in a direction that is consistant. > >If you move to a slice, and click again, you can go to the next menu >before the first one appears. This can be nested so that you can click >ahead several menus. Just as a note, the "click-ahead" technique on radial selection menus was used by Terry Higgins at the National Film Board in Montreal. He demo'd production level cel-animation software with these menus at SIGGRAPH'87. I believe Don Hopkins was already working on his pies at that point, though had not yet published. Certainly Ben Schneiderman saw the menus, and talked with Terry at length at that time about the click-ahead scheme. Once you use 'em, you never go back. Linear menus are just too much of a pain. I don't even read the menu items any more - 80% of my selections are done through muscle memory, especially when using a scheme where you don't have to click on a menu item to get to a sub-menu. Clicking just slows you down, even with click-ahead. Dave Forsey Computer Graphics Laboratory University of Waterloo.
msc@ramoth.esd.sgi.com (Mark Callow) (11/07/89)
In article <12164@watcgl.waterloo.edu>, drforsey@watcgl.waterloo.edu (David Forsey) writes: > Just as a note, the "click-ahead" technique on radial selection > menus was used by Terry Higgins at the National Film Board in > Montreal. He demo'd production level cel-animation software with these > menus at SIGGRAPH'87. I believe Don Hopkins was already working on his pies > at that point, though had not yet published. Certainly Ben Schneiderman > saw the menus, and talked with Terry at length at that time about the > click-ahead scheme. Terry had already demonstrated the same software 3 months earlier at SIGCHI in Toronto. I believe he came up with the idea before Don. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."