jackiw@cs.swarthmore.edu (Nick Jackiw) (08/15/90)
Has anyone noticed the rather poorly thought out logic of the new
guidelines for pull-down menus? They insist that you append a "scroll-down"
arrow (a la any scrolling menu) after the menu item currently listed in
the default box, e. g.
+--------------+
Font: | Palantino V|
+--------------+
Where V is the scrolldown arrow. Now either your default popup rect is
is wider (by scrollarrow-width) than your widest item, or it's not. In
the later case, if one of your menu's wider items is chosen, you'll have
to truncate it to make room for the arrow--ugh! In the former case, though,
if the user clicks on the scroll-down arrow (a common choice, I think) then
the menu pops up, but is off to the left 20 or 30 pixels from where the
cursor is located (so no item is initially hilited...again, ugh!).
This seems poorly thought out, to me. While I suppose you could force the
menus to be wider--adding scrollarrow-width to the result of CalcMenuSize--
there's no clean way to do this, and it would give you a pop-up with an
oddly-blank right margin.
I think I liked the old method better. Grumble grumble...
--
------------------------
Nick Jackiw jackiw@cs.swarthmore.edu "Just break out the
Visual Geometry Project jackiw@swarthmr.bitnet rum so we seem natural!"
Swarthmore College, PA 19081-1397 -F. Franklinausting@Apple.COM (Glenn L. Austin) (08/16/90)
jackiw@cs.swarthmore.edu (Nick Jackiw) writes: >Has anyone noticed the rather poorly thought out logic of the new >guidelines for pull-down menus? They insist that you append a "scroll-down" >arrow (a la any scrolling menu) after the menu item currently listed in >the default box, e. g. > +--------------+ > Font: | Palantino V| > +--------------+ >Where V is the scrolldown arrow. Now either your default popup rect is >is wider (by scrollarrow-width) than your widest item, or it's not. In >the later case, if one of your menu's wider items is chosen, you'll have >to truncate it to make room for the arrow--ugh! In the former case, though, >if the user clicks on the scroll-down arrow (a common choice, I think) then >the menu pops up, but is off to the left 20 or 30 pixels from where the >cursor is located (so no item is initially hilited...again, ugh!). >This seems poorly thought out, to me. While I suppose you could force the >menus to be wider--adding scrollarrow-width to the result of CalcMenuSize-- >there's no clean way to do this, and it would give you a pop-up with an >oddly-blank right margin. >I think I liked the old method better. Grumble grumble... Use the Popup CDEF (ID 63) documented in the Macintosh Communications Toolbox reference. It does some neat stuff, including using compressed type, auto- "truncating" (ie "LongMenuName" becomes "LongMenu..."), useWindowFont, etc. It also does the "correct" polygon and scales it as necessary. It also handles correct checkmarking of items (using bullet instead of checkmark when checkmark is not defined...). -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
kazim@Apple.COM (Alex Kazim) (08/16/90)
For the case with a menu width > the item rect, yes, you will have to truncate. There should be a Script Mgr call to handle this in Sys 7, but Sys 7 will ship with a popup CDEF anyway. For the case with a menu width < the item rect, you should erase the item rect before calling _PopupMenuSelect so it won't look ugly. If it kills you to do things this way, axe the arrow. These are guidelines, not laws... ======================================================================== Alex Kazim, Apple Computer Not much to say ========================================================================
mdavis@pro-sol.cts.com (Morgan Davis) (08/17/90)
In-Reply-To: message from jackiw@cs.swarthmore.edu Grumble, indeed. Apple has yet to release the "Here's How You Really Do It" spec on drawing a pop-up menu. (Though, there's a CDEF supplied with the CommToolBox, so maybe that is The Way). In any case, the downward pointing arrow on the *right* side of the item (of all locations) puts undue strain on programmers. Plus, if the item shown in the pop-up menu's (PUM's) rect is the bottom-most one in the menu, then shouldn't the downward arrow really point upward? And, if the item is not at the top or bottom of the list, shouldn't it be more line a diamond shape to point up *and* down? UUCP: crash!pnet01!pro-sol!mdavis ProLine: mdavis@pro-sol ARPA: crash!pnet01!pro-sol!mdavis@nosc.mil MCI Mail: 137-6036 INET: mdavis@pro-sol.cts.com America Online, BIX: mdavis
kazim@Apple.COM (Alex Kazim) (08/21/90)
In article <3961@crash.cts.com> mdavis@pro-sol.cts.com (Morgan Davis) writes: >Apple has yet to release the "Here's How You Really Do It" spec on drawing a >pop-up menu. (Though, there's a CDEF supplied with the CommToolBox, so maybe >that is The Way). The CommToolbox CDEF is being massaged and will be included in System 7. > >all locations) puts undue strain on programmers. Plus, if the item shown in >the pop-up menu's (PUM's) rect is the bottom-most one in the menu, then >shouldn't the downward arrow really point upward? And, if the item is not at >the top or bottom of the list, shouldn't it be more line a diamond shape to >point up *and* down? > The arrow is meant as a visual clue, rather than a definition. It's like a road sign indicating curves ahead: the curves on the sign don't match the terrain in any sense. Similarly, the popup arrow is meant to indicate the presence of a menu rather than its modus operandi. ========================================================================== Alex Kazim, Apple Computer Never trust the suits ==========================================================================
russotto@eng.umd.edu (Matthew T. Russotto) (08/22/90)
In article <44112@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: > >The arrow is meant as a visual clue, rather than a definition. It's like >a road sign indicating curves ahead: the curves on the sign don't match >the terrain in any sense. Similarly, the popup arrow is meant to indicate >the presence of a menu rather than its modus operandi. Nice rationalization, but I've never seen a sign for a left curve on the road have anything but a left curve on the sign, nor vice versa. Even when it is a series of curves, the first curve on the sign always matches the first curve on the road. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
dwal@ellis.uchicago.edu (David Walton) (08/22/90)
In article <1990Aug21.200600.13164@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <44112@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: >> >>The arrow is meant as a visual clue, rather than a definition. It's like >>a road sign indicating curves ahead: the curves on the sign don't match >>the terrain in any sense. Similarly, the popup arrow is meant to indicate >>the presence of a menu rather than its modus operandi. > >Nice rationalization, but I've never seen a sign for a left curve on the road >have anything but a left curve on the sign, nor vice versa. Even when it >is a series of curves, the first curve on the sign always matches the first >curve on the road. Yes, and knowing that the curve on the sign follows the direction of the curve on the road is something that I simply couldn't do without when I'm driving. :-) :-) Note the words which Alex uses: "clue" versus "definition" or "modus operandi." The roadsign indicates, "hey, guys, watch out, there are some curves ahead," while the down arrow in a popup menu says, "this is one item in a popup menu." In neither case do the indicators serve as exact blueprints to the thing they're referring to (curves or menus). Furthermore, I really can't see that having the arrow change based on the selected item's position in the menu offers that much advantage. I can see situations where the immediate visual cue might be useful, but I wonder if the changing state of the arrow might not just confuse The Rest of Us (tm), in which case I don't think the extra functionality would be worth it. (But somebody with a much better background in cognition and human interface design than mine would have to answer this question.) Just my $.02. >Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu -- David Walton Internet: dwal@midway.uchicago.edu University of Chicago { Any opinions found herein are mine, not } Computing Organizations { those of my employers (or anybody else). }
lim@iris.ucdavis.edu (Lloyd Lim) (08/22/90)
In article <44004@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: > >Use the Popup CDEF (ID 63) documented in the Macintosh Communications Toolbox >reference. It does some neat stuff, including using compressed type, ... Since everyone is commenting on certain visual aspects of the interface, I thought I'd throw in my opinion and get blasted also. :-) I think the use of compressed type in the new Standard File and Popup CDEF is a bad idea. It seems like an inelegant kludge that undermines the consistency of the interface. Why not just widen the list or menu to make more room? If there is plenty of space, then it doesn't seem unreasonable to just truncate the oddball 50 or so character items. I believe for popups the item should be drawn wider and then erased if the widest item is the current selection. I admit there are trade-offs but compressed type seems so... uhhh, ugly. No offense intended to whoever thought of it but I just had to see if anyone felt the same way. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
kazim@Apple.COM (Alex Kazim) (08/23/90)
In article <7597@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) writes: > >I think the use of compressed type in the new Standard File and Popup CDEF is >a bad idea. It seems like an inelegant kludge that undermines the consistency >of the interface. Why not just widen the list or menu to make more room? If >there is plenty of space, then it doesn't seem unreasonable to just truncate >the oddball 50 or so character items. I believe for popups the item should > The problem with widening the list or popup is that some items are dynamically placed in those items. "Just widening" it doesn't work if there are other items in a dialog that would get overlapped. Also, should it remain centered? What about StandardFile that allows you to customize the dialog box? Actually, menu items in the popup will not be condensed, only the title will be. And, I think condensing will look better as font technology progresses. Then again, maybe it won't. ======================================================================== Alex Kazim, Apple Computer Which way did he go, which way did he go ========================================================================
jimc@isc-br.ISC-BR.COM (Jim Cathey) (08/23/90)
In article <1990Aug21.200600.13164@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <44112@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: >> >>The arrow is meant as a visual clue, rather than a definition. It's like >>a road sign indicating curves ahead: the curves on the sign don't match >>the terrain in any sense. Similarly, the popup arrow is meant to indicate >>the presence of a menu rather than its modus operandi. > >Nice rationalization, but I've never seen a sign for a left curve on the road >have anything but a left curve on the sign, nor vice versa. Even when it >is a series of curves, the first curve on the sign always matches the first >curve on the road. My interpretation of that downwards pointing arrow is more aligned with a "Push _down_ on the mouse button here to see more choices..." viewpoint than a "There would be more menu choices available in _this_ linear direction if you were to push here." Just try explaining to your mother when and why that little doodad changes. It would only be one more level of needless detail that would confuse the unwary. Unless you learned to ignore the arrow's changing (in which case why change it at all) I would think that the changing arrow would conjure up an endless succession of mental ghost images of how the (invisible) menu looks at that moment, which is extra brainwork, and useless as well. After all, the current choice is either right or wrong, and pressing on the item is soon enough to begin thinking about whether the right choice is actually available or not. Eliminates guesswork, too. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
murat@farcomp.UUCP (Murat Konar) (08/23/90)
In article <1990Aug21.200600.13164@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: -In article <44112@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: -- --The arrow is meant as a visual clue, rather than a definition. It's like --a road sign indicating curves ahead: the curves on the sign don't match --the terrain in any sense. Similarly, the popup arrow is meant to indicate --the presence of a menu rather than its modus operandi. - -Nice rationalization, but I've never seen a sign for a left curve on the road -have anything but a left curve on the sign, nor vice versa. Even when it -is a series of curves, the first curve on the sign always matches the first -curve on the road. I would argue that telegraphing the relative position of the currently selected item in a pop-up is pretty nearly useless to the user. Nothing bad will happen if the current item isnUt where the user expects it. Contrast this with the potentially disastrous consequences of zigging when you should have zagged while driving. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
stanbach@Apple.COM (Francis Stanbach) (08/23/90)
I started this by adding condensed type to the chooser. AppleTalk allows network devices to have 32 character names and I could not make the chooser big enough to show the entire zone and device name (believe me, I tried) so I condensed the text. I felt that if a maximum of 5% of the items were condensed it would look OK. Unfortunately, these things can get out of hand. If you can only display 50% of a string and condensing it allows you to display 60%, I don't think it is a real win. If more than 1/4 of a list is condensed, it looks bad. Francis -- wmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwm Francis Stanbach Software Engineer Finder & Applications Apple Computer, Inc. wmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwmwm
lim@iris.ucdavis.edu (Lloyd Lim) (08/23/90)
In article <44165@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: >The problem with widening the list or popup is that some items are dynamically >placed in those items. "Just widening" it doesn't work if there are other >items in a dialog that would get overlapped. ... Actually, I meant that the dialogs should probably be designed so they are wider to begin with. Even an original Mac screen has quite a bit of room and if you really wanted to, you could move all the buttons underneath the list to make even more room. (Don't take that too seriously.) >Actually, menu items in the popup will not be condensed, only the title >will be. Yes, I know. I still have mixed feelings about this. I pretty much agree with Francis Stanbach's views on this. Like they say, you can't have it all. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616