chuqui@nsc.UUCP (Chuq Von Rospach) (09/18/85)
I've been a couple of design issues through my head the last few days, and
I've come up with what I think might be a reasonable extension to the
standard mac user interface. I wanted to drop it onto the net and see what
people thought about it before I started building a design with it in mind,
though, in case there is a problem I haven't thought of.
There seem to be certain cases where it would be nice to be able to get to
a command, usually something that would be a repetetive operation, quickly.
Things like next/previous page in MacWrite or next/previous record in a
database lookup. You could use scrollbars if the window and the record size
are the same, but in many cases the visible window (and the scroll region)
have nothing to do with the logical records.
You could do this by setting up a standard menu item such as 'movement'
with two items 'forward' and 'backward', but a menu operation requires
you to {point,click,drag,position,unclick} to cause the operation to
happen. In a highly repetitive situation that turns into a lot of small but
highly details hand movements, and gets tiring.
I'd like to extend the user interface to allow a menu item (say 'forward'
or 'backward') to exist without a menu attached. If someone clicks that
menu item, a special menu code is returned and the operation is acted upon.
This way, you could simply point at 'forward' and then {click,unclick}
through any number of records quickly, something I haven't seen done well
yet on the Mac (pointers are welcome, folks...)
Any comments on this? I think it looks good, but I'm not close to taking a
religious position on it. If you've got ideas (pro or con), drop me a line
and I'll summarize to the network.
chuq
--
Chuq Von Rospach nsc!chuqui@decwrl.ARPA {decwrl,hplabs,ihnp4}!nsc!chuqui
Take time to stop and count the ewoks...holly@dartvax.UUCP (Holly Cabell) (09/22/85)
Switcher uses this. (Click on the arrow to move to the next application.) -- --johnc at [the.world] ! dartvax ! holly
tim@k.cs.cmu.edu.ARPA (Tim Maroney) (09/25/85)
No, Switcher does not use this, if I understand the proposal. First, the Switcher arrow is graphics, not a menu title. Second, it does not go through the Menu Manager; instead, it intercepts mouse-down events in GetNextEvent and uses "raw" hit-testing to see if they occurred in the Switcher arrow. This is not the same thing Chuq is suggesting. I still think that controls and character equivalents for menu commands do the same thing better than no-command menus, though.... -=- Tim Maroney, Carnegie-Mellon University, Networking ARPA: Tim.Maroney@CMU-CS-K uucp: seismo!cmu-cs-k!tim CompuServe: 74176,1360 audio: shout "Hey, Tim!"
barmar@mit-eddie.UUCP (Barry Margolin) (09/26/85)
I tried to send this as mail to chuqui, but it didn't go through, so I'm
posting it:
I don't like your proposal, primarily because it is confusing to use the
menubar for multiple things in this way. By the way, Switcher does
something like your proposal, with its double-arrow icon at the
righthand end of the menubar; while it doesn't really confuse me, I can
imagine that it would confuse less experienced computer users ("the rest
of them"), especially since one has to be very precise and point at the
correct little arrow head.
There are several command styles that I have seen which provide the
functionality you are describing. First of all, you can have ordinary
"Next/Forward/Previous/Backward <unit>" menu items, but have command key
equivalents; this is probably the most standard way to do this, and it
provides the simplicity that novices need and the shortcut that
experienced users want. Another possibility is to use Forward/Backward
buttons somewhere in the window. Finally, a method I have seen in some
software (although I don't fully approve of it) is to make use of the
horizontal scroll bar when real horizontal scrolling doesn't apply in
the current context; the standard Scrapbook DA does this, although I
would much prefer real scrolling, or at least the ability to resize its
window (I seem to be digressing).
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmardimitrov@csd2.UUCP (Isaac Dimitrovsky) (09/27/85)
[] > There seem to be certain cases where it would be nice to be able to get to > a command, usually something that would be a repetetive operation, quickly. > Things like next/previous page in MacWrite or next/previous record in a > database lookup. Why not just have an additional icon on the screen or in the window control area that does the repetitive operation, as in macpaint or excel. Isaac Dimitrovsky allegra!cmcl2!csd2!dimitrov (l in cmcl2 is letter l not number 1) 251 Mercer Street, New York NY 10012 (212) 674-8652 ... Hernandez steps in to face ... Orl ... HERchiiiser ... and it's a liiine driive, deeeeep to the gap in left center ... - Bob Murphy, Voice of the Mets
barmar@mit-eddie.UUCP (Barry Margolin) (09/30/85)
In article <568@k.cs.cmu.edu.ARPA> tim@k.cs.cmu.edu.ARPA (Tim Maroney) writes: >No, Switcher does not use this, if I understand the proposal. First, the >Switcher arrow is graphics, not a menu title. Second, it does not go >through the Menu Manager; instead, it intercepts mouse-down events in >GetNextEvent and uses "raw" hit-testing to see if they occurred in the >Switcher arrow. This is not the same thing Chuq is suggesting. Until I read Inside Switcher this week, I thought that it somehow used the Menu Manager (until this reading, I was very confused when I couldn't find the resources for Command-[, Command-], and Command-\). However, this is all besides the point. I was referring to the user view of the interface. To the user, the switcher arrow seems like a strange menu title with weird properties. The very fact that I have described it as "strange" and "weird" should alert developers to the fact that it is not consistent with the rest of the system, and consistency is supposed to be an important feature of the Mac. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
mmt@dciem.UUCP (Martin Taylor) (10/08/85)
The following was a response to a proposal that menu-bar items on the Macintosh should be allowed to cause "real" actions rather than just calling up window-blind menus. >I don't like your proposal, primarily because it is confusing to use the >menubar for multiple things in this way. By the way, Switcher does >something like your proposal, with its double-arrow icon at the >righthand end of the menubar; while it doesn't really confuse me, I can >imagine that it would confuse less experienced computer users ("the rest >of them"), especially since one has to be very precise and point at the >correct little arrow head. > >There are several command styles that I have seen which provide the >functionality you are describing. First of all, you can have ordinary >"Next/Forward/Previous/Backward <unit>" menu items, but have command key >equivalents; this is probably the most standard way to do this, and it >provides the simplicity that novices need and the shortcut that >experienced users want. Another possibility is to use Forward/Backward >buttons somewhere in the window. Finally, a method I have seen in some >software (although I don't fully approve of it) is to make use of the >horizontal scroll bar when real horizontal scrolling doesn't apply in >the current context; the standard Scrapbook DA does this, although I >would much prefer real scrolling, or at least the ability to resize its >window (I seem to be digressing). >-- > Barry Margolin Why should it be confusing for a menu-bar item to cause an action other than presenting a new menu? The menu-bar provides a menu. Clicking on a menu item does something. Sometimes that something is to call down another menu, sometimes it is not. Sometimes items in the window-blind menu call up a third-level menu, sometimes not. Personally, I'd much rather have a menu item "Quit" on the menu-bar than to have it as the only entry under "File", as it is in several applications distributed over the net. (Why "File", anyway? What's that got to do with quitting?). The suggestion about loading other controls, such as scroll bars, sounds much worse, since those items do have specific functions in the usual case. Forcing the use of command keys is bad: in my view, command keys should apply ONLY to visible menu items, and a new set of command keys should be available when a sub-menu is alive. For example, ^F (clover-F) might call the "File" menu, and ^S could be "Save" under that menu, so that ^F^S always meant "Save". That way, there would be compatibility between what is done at the keyboard, as well as the possibility for giving every menu item a commend-key equivalent, be it two, three, or more keystrokes. The only cost of that would be that only those functions on the menu-bar could be performed with one keystroke. I don't consider that a problem. -- Martin Taylor {allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt {uw-beaver,qucis,watmath}!utcsri!dciem!mmt
stew@harvard.ARPA (Stew Rubenstein) (10/10/85)
In article <1701@dciem.UUCP> mmt@dciem.UUCP (Martin Taylor) writes: > >The following was a response to a proposal that menu-bar items on the >Macintosh should be allowed to cause "real" actions rather than just >calling up window-blind menus. > >>I don't like your proposal, primarily because it is confusing to use the >>menubar for multiple things in this way. > >> Barry Margolin > >Why should it be confusing for a menu-bar item to cause an action other >than presenting a new menu? The menu-bar provides a menu. Clicking on >a menu item does something. Sometimes that something is to call down >another menu, sometimes it is not. Sometimes items in the window-blind >menu call up a third-level menu, sometimes not. Personally, I'd much rather >have a menu item "Quit" on the menu-bar than to have it as the only entry >under "File", as it is in several applications distributed over the net. >(Why "File", anyway? What's that got to do with quitting?). Why? Because practically all other menu bar items in every application written for the Macintosh cause this action. Menu items which cause a third level menu (dialog box) should end with an ellipsis (three dots). Quit is on the file menu because there is no better place for it. ALL OF THIS IS IN THE "USER INTERFACE GUIDELINES" SECTION OF INSIDE MACINTOSH. ***** READ IT! ***** Sorry to shout, but consistency is an important feature of the Macintosh. Please take the time to read this important section -- it will make your applications much easier to use. It also states (top of p. 35 in the phonebook edition) "Nothing actually happens until the user chooses the command; the user can look at any of the menus without making a commitment to do anything." In my opinion, this is gospel. The switcher \had/ to be an exception because it has to intercept the mouse-down at the event stage, without relying on the application to call MenuSelect or anything like that. >The suggestion about loading other controls, such as scroll bars, sounds >much worse, since those items do have specific functions in the usual case. The use of scroll bars on the left and lower edges of a document window conventionally scrolls the document in the window. A scroll bar in a non-document window or in a different place in a document window has no conventional meaning. I think that scroll bars may be reasonably used in these positions for other purposes. Moving "Forward" or "Backward" (whatever that means for your application) may well be a left-and/or-lower edge situation. Scroll bars are often used for value selection where non-graphical systems might well ask the user to type in a number. This is \not/ a left-and/or-lower edge situation. >Forcing the use of command keys is bad: in my view, command keys should >apply ONLY to visible menu items, and a new set of command keys should >be available when a sub-menu is alive. For example, ^F (clover-F) might >call the "File" menu, and ^S could be "Save" under that menu, so that >^F^S always meant "Save". That way, there would be compatibility between >what is done at the keyboard, as well as the possibility for giving every >menu item a commend-key equivalent, be it two, three, or more keystrokes. >The only cost of that would be that only those functions on the menu-bar >could be performed with one keystroke. I don't consider that a problem. > >Martin Taylor >{allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt >{uw-beaver,qucis,watmath}!utcsri!dciem!mmt This last may be a good idea. Unfortunately, it is too late for incorporation into the Macintosh user interface. The most common things ought to single keystrokes, though, and I can remember more than 5 or 10 at a time, myself. A less experienced user might well be different. I was going to suggest using icons (such as in MacPaint, or MacDraw, or my application, ChemDraw), but this may not be so good. Selecting an icon from a pallette is a great way to handle "tools" but the action of selecting an icon usually doesn't do anything. Inside Mac doesn't say anything about them, but these applications all work that way. I remember an implementation of a dataflow processor simulation (by Gus Fernandez at Stanford maybe?) which used a vertical "icon bar" with pop-out icon menus. I think that this may have worked differently, i.e., something happens when you click in some cases, though some icons were mode selections. The current mode was, as I remember, displayed as the "title" of the icon "menu". I liked this when I saw it, but that was a year or so ago, before I had any experience as a Mac developer. What about other applications which use icons? A survey, anyone? Stew Rubenstein Rubenstein@lhasa.harvard.edu (maybe) Rubenstein@harvard.arpa (more likely given current confusion) { seismo, ut-sally, decvax!genrad!wjh12 } ! harvard ! rubenstein (uucp)