I see this issue come up at least once a month, and I feel that someone needs to explain things to Mac people (silly Mac people ;-)).
A PopupMenu is just a dumbed-down combo box on Windows. A PopupMenu is just a souped-up ContextualMenu on the Mac. It serves a slightly different function on both platforms, and so you should use caution when deciding whether it's the right UI for you. For example, on Windows, a PopupMenu (and ComboBox) has no concept of a seperator. There's simply no way (short of making your own control and drawing it yourself, which still has its down sides such as dealing with selection) to get a seperator. So if you find yourself wanting one, stop using a PopupMenu since you're trying to bastardize the standard concept of one. And before you get in a huff about how the Mac has the concept -- the Mac has it wrong (hence it being souped-up). And here's why:
There are three controls for data display which all serve the same purpose, just in different ways. First, there's the single column listbox. It displays all the rows of data to you at once, and it's always showing. Selecting a row simply highlights it, and you can double click rows to get an action. PopupMenus (which, consequently is the name for a contextual menu on Windows. The RB PopupMenu is still called a ComboBox on Windows) are like partially hidden listboxes. The current selection is displayed as the only row showing. Clicking on some UI causes the entire list of data to be displayed so the user can select from it. Finally, a ComboBox has all the same properties as a PopupMenu, except it lets you enter new data (or select existing data) by typing in the display area.
All three controls use the same implementation under the hood (I'm talking about in the OS now, not in RB's framework code) because they all serve the same purpose -- just with a different view on it.
Do you ever put a seperator in a listbox? No (or at least, you really shouldn't) -- which is the same reason you shouldn't be putting seperators in popup menus or combo boxes either. The object isn't to seperate the chunks of data, it's to display all the relevant data at once. If you find yourself wanting to put a seperator in there, then you should consider splitting the data into multiple popup menus since the data is in different groups. If you only want the seperator for a single item (like seperating Default from all the other items), then you should either make default one of the items, or consider using a ContextualMenu, or remove Default all together (which isn't always possible).
What you should not do is complain that seperators don't work on Windows and Linux -- they aren't meant to work, and while it's possible to make them work (with about a week's worth of coding, and possibly losing theme savvy-ness along the way), I don't think it's work that should ever be done -- it allows you to design poor UIs.
So you may be wondering -- why do we draw the single dash -- why not just remove it? Because 1) that breaks old code that relies on the behavior, and 2) it forces you as a programmer to figure out which platforms have this abomination, and which don't. Then you have to code around the fact that the ListIndex really isn't correct on some platforms because we've kindly removed rows from the control for you. If we only let you go off the text of the selection, or only let you go off the text of the rows, then it may be possible. But since we let you use index data as well, it's not feasible.
So to make a long rant longer, if you want to use a seperator on a PopupMenu -- fine, so long as you only plan on using it on the Mac. But if you care about Windows or Linux, then you need to rethink that design decision since it won't work on those platforms. And before you go spouting off about how "REALbasic is a cross platform tool", yada yada yada -- yes. It is. Which is why we let you put the seperator in on the Macintosh, and gave you reasonable results on platforms which don't support it. If you want to use that slipperly slope, then you're asking for only features that are on all platforms we support, which simply isn't going to happen.
From what I understand you are looking at the widgets from an API view, but if you look at the popup menu from a UI perspective things gets a bit different (at least in my opinion), here a popup is a menu not a list, in other words they should behave close to how menus work not how lists behave. In my way of looking at it, you use lists to display and select data while a contextual popup is used for selecting a commands not data. So what about popups? They are difficult but I prefer to see them as menus not as lists and in that case I think it makes perfect sense to have dividers etc.
Often times the API point of view determines the usage. And if you look at the purpose of any of the three UI elements (not from an API viewpoint), they are all used to display a list of data in one form or another. The data is typically all relational in one way or another. Since all the data relates, seperating it with some other UI doesn't typically make sense.
Just because a popup *looks* like a menu on the Mac doesn't mean it's meant to be one. They look nothing like menus on all other platforms (for good reason, IMHO), and so using them in place of a menu is where you run into troubles doing cross platform dev work -- which is basically the crux of my rant. People use popups for purposes other than which they are intended, then complain about "bugs" when they don't "work" (as the programmer expects) on all platforms.
Well, I don't agree. Lists are for displaying data, drop-down menus are for displaying commands and status, contextual menus are mostly for displaying commands. The problems are the combobox and the popup menu, in my opinion a combobox is a clear "list" in other words it's for displaying data. So in my opinion the popup menu is the real problem, is it for display data or for displaying commands ... I think that you're right in that popups should display data, a kind of mini-list of available options. So I change my mind: comboboxes and popups are lists, contextual popups are menus.
Then I'm not sure what you mean with "Since all the data relates, seperating it with some other UI doesn’t typically make sense."
And thanks for getting me to think about this!!
You see, a popup menu is still just a list of data -- it's not meant to display commands. Take some of the usual examples of popup menus: list of countries, list of states, list of colors. It's not *meant* to be used as both a list and commands. It's just that some people (mostly people who use the Mac primarily) have twisted the use of a popup menu to have commands sometimes since it was possible to do on the Mac. I think (but can't really tell) you're in agreement with me on this -- that a popup should display data (just like a listbox or combobox), but if you want commands, you use a contextual menu.
What I meant about data relation is this: the data in the lists for popups and combo boxes should always be related items. For example, listing all the states, or countries. Each item is related. If you wanted to show all the states *and* all the countries, you would make two different lists.
Since all the data relates, you shouldn't ever need to put in separators -- there shouldn't be anything set apart like that in a list of data. If there is, then you're using the wrong UI control. You should consider a listbox (if it's strictly data to be displayed) with multiple columns, or two popup/combos, or even a contextual menu (if it's commands mixed in with data).
And I'm glad the topic has struck up a good discussion! :-)
Yes, I think we agree on this.
[...] , etc (18:54) Development I can’t stop thinking about this discussion and there is one thing that bothers me: Mailsmith has a search dialog box that [...]
Since I can't post comments on your site, I'll post my response here and hope you read it. I'm assuming the menu you showed me comes from the listbox of items, not the popup menu for Search In, correct? If so -- then that's a contextual menu you're looking at. It has a drop-down widget there strictly so that you know you get a contextual menu from clicking on it (basically, it removes the hidden-ness of having to right click on the cell). So that's a perfectly valid case of a contextual menu (just with extra UI, much like you'd see in a BevelButton). The PopupMenus which I refer to are the "Search In" variety -- those should display a list of data to select from (and options can count as data, but they should all be related options, not different categories).
I think you may be mistakenly believing that contextual menus should never have UI associated with them. I should point out that this isn't the case -- take BevelButtons with menus as an example. On all platforms, these have a drop-down widget to provide some UI for the user to know a menu will appear when clicking there. It's also common in listboxes (see the REALbasic properties window or constants editor for examples). Those are all contextual menus.
I deleted the comment stuff after some spam comments should put it back some day ...
Yep, I'm the one who is confused. I'm mixing things up. Thanks for explaining
No problem! Glad I could help. :-)
The problem with the mailsmith exemple is that they are trying to build a formula with a popup menu and a listbox. It's an horrendous idea, basically because they don't know exactly how many criteria the user want anyways.
What they should have done is use the microsoft excel way of creating a formula.
Open excel, go insert -> functions now a screen popup, you choose your formula, like sum(), adds your argument or another formula. Microsoft excel never knows how much formula or argument you want, the user is in the driving seat like it should be. At the end you got a big long string that the user can easily modify or even copy/paste. There, it's all cross platform, it's easy to understand for the user, and easier to code.
It's not a philosophical question about api VS good use. BBSW just shoot themselves in the foot. Just imagine excel where each cell was a data or a formula, it would be a never ending mess of impossible to read contraption, just like the mailsmith screen is. I mean come on asking the user to add row to your listbox? Adding a popup menu to every single cell? Please keep it simple.
I don't understand what you mean. Excel can build complex fomulas while Mailsmith build search rules that are much less flexible, they are basically simple rules combined with and/or. Excel needs a flexible way of building the formulas while Mailsmith can use a simple table for building the rules. If you look at Entourage they seem to use the same method for building rules.
Take some of the usual examples of popup menus: list of countries, list of states, list of colors.
Actually, Apple recommends not using popup menus for lists that have more than 12 items: AHIG.
The Mac also has a non-editable combo box in OS X, and the Popup Menu is meant to be used for different purposes than a combo box. Just because WIndows and Linux don't have a concept of a true popup menu doesn't mean that the Mac has it wrong.
Yeah that's exactly the point, mailsmith made a complicated mess trying to make something simple, entourage blew it too to a lesser extent ( they have less choice tho ).
They are basically trying to build a RegEx, they just choose a dumb way. since you got so few operator interspaced with a couple of user choice, why bother building a grid with all that? It's going to end up as a string anyways, let the user build that string ( like in excel ) with a couple of comboboxes, some group option, the other advantages is that you can actually explain to the user what each choice means, with exemples, tooltip etc, something that isn't going to work in a popupmenu.
Let say I want to tell the computer to add 2 plus 2.
In excel I type =sum(2,2) in a single cell, I choose the sum() functions and adds all the numbers I could possibly want, in a single screens, and this is clearly explained to me.
In a bizarro world where excel is coded by mailsmith programmer I'll have to do :
Select the popup menu of the first cell, choose the = operator.
go to next cell, choose the sum functions.
next cell, choose (
next cell, choose 2
next cell etc...
You see the difference. The amazing thing is that solution 1 is probably easier to code.
No, I don't see. First of all you're not building a regex when you search, you're building a database query where you define what different fields should match. So the result is probably not a string (I'm not sure how Neoaccess is accessed but I guess it's through API calls directly and not through some query language). Secondly, if you're using some kind of language for doing the search you need to parse and validate it before calling the database, this means that you have to display error messages etc to the user in case (hehehe) they write something wrong ... which makes it much more difficult to use the search command. So far I have never managed to get an syntax error when using Mailsmiths search command (except when I use the regexp alternative) but I get syntax error quite often when I use Excel.
So I don't agree at all with your comments.
Jon -- quite frankly, Apple has it wrong. They suggestion to not have many items in the list most likely stems from the fact that Apple doesn't like using the keyboard for selection. On more enlightened systems, keypresses select items from the list. So when I hit "T", it brings me down to the Ts in the list.
As for whether Apple's implementation is the "correct" one -- I take Apple's HIG with a very, very large grain of salt. They've made so many poor UI decisions since coming out with OS X that I don't hold them up as an example of good UI. I think Windows has the concept correct, I think Apple is just copping out and messing a good concept up.
But you said it yourself, there is no such thing as a "popupmenu" on Windows or Linux. So, how can Apple screw up the implementation if there is no such control on Windows/Linux? Apple also has the ComboBox, which is what you explain is what we use as the popupmenu control on Windows/Linux. I'm not speaking in terms of REALbasic right now -- just the operating systems: If a control exists on one platform, but not on another, how can that one platform have it wrong?
Well, first off, PopupMenu on Windows *is* the term used for contextual menus. ;-) But I see what you mean now -- and you are kinda correct. On the Mac, a ComboBox serves the same purpose as a PopupMenu just like the two versions of ComboBoxes do on Windows. The difference is that the Mac calls them two different controls, but on Windows it's two different styles of the same control. That's not an issue with me... six of one, half dozen of the other.
The fact that the Mac canibalized the popup menu to serve a dual purpose is what I meant by "getting it wrong". It seems like a poor UI decision. The fact that it's used as a list control as well as a menu seems wrong. Just as wrong as if you would do that with a listbox.
Don't get me wrong, the Mac can have all its goofy little quirks -- and Mac zealots will defend them until they're blue in the face. ;-) But that doesn't mean it's good UI.
I don't like using popups for long lists, perhaps 20-30 at a maximum. Why? because it's so simple to accidently close a popup and if you need to scroll a popup to get to a certain place (even just by typing) it adds some irritation to the user experience. Better to make it a list.
(living in Sweden it's a real joy to fill in forms where they require the country ... Sweden is close to the end of the list :( )
So, what's the difference between a bevelbutton with a menu and a popup menu? Why is the bevelbutton with a menu more acceptable than the popup menu?
I guess I've never had an issue with long lists unless it's with a contextual menu (like in RB 5.5, the add control contextual menu in the window editor) that needs to scroll. *Those* are a real pain! But I'm used to seeing decently-sized lists in popup menus, so they don't bother me too much. But in general... less information displayed is better since it doesn't scare or confuse users quite so easily.
@Jem
*sigh*
Well continue to disagree.
If you think that this screen of mailsmith is the epic of UI design, well who am I to judge? Clearly it will never be equaled in it's simplicity and power, I just wish every operation I execute on a computer could be presented in a grid pattern with popupmenu on each damn cells, because I sure like to use my mouse all the time, I like to hunt down little arrow, feel like a game.
I am sure that they went to the trouble of coding a whole new query system just for the RegEx alternative, and that you aren't building a SQL query ( a string ), but a complex and undecipherable function that act on the database file on a binary level, clearly there is a powerful database indexing engine behind that screen, no way the genius at BBSW will take the easy way and use standard query system. No Sir. The idea that I suggest that this screen is just a frontend over their RegEx is just silly talk, no one do that. Man they must have spent like a year on that screen, or more, maybe someone died coding this.
Jon -- huh? A bevel button with a menu has a clear point to it -- you are selecting a command that causes an action to occur. A popup menu is a *LIST* control, it should be for selecting items from a list (which is why it displays the current selection from the list). Making a popup menu do commands blurs the use of the control. What I am getting at is that a popup menu isn't really a menu; the name sucks. Call it a drop-down list and it's much more accurately describing what its use is.
I agree on one thing: we will probably never agree. Mailsmith is intended to be used by end users, end users do not want to learn a query language like SQL, error messages from SQL queries can be hard to interpret, adding a standard query language adds the overhead of parsing and processing the language (not really an issue in this case), so in this case BBSW did the right thing ... or at least did something better that Excel. But since we are talking about computers we can both be happy: I'll use Mailsmith and you can implement your filtering with procmail.
Ohh, I should add that the filtering dialog and the search dialog both looks like this (which explains the comment about procmail)
Traditionally (aka, before OS X) there was only the PopUp menu. Developers used it to allow users to select items from a list or perform commands. Now in MacOS X there is 3 types of "Menu" controls. The PopUp menu, the PullDown menu and the ComboBox. The AHIG states that the PopUp menu should be used as a list (with commands that manipulate the items in the list), the PullDown menu for issuing commands and the ComboBox to allow the user to enter text or select from a list of suggestions.
The Windows Drop-Down list (what RB gives you for a Popupmenu on Windows) is _not_ the same as the Mac PopUp menu. It is a basically listbox that only has enough room to show the selected item, and therefore should be used as one (ie, no separators). The Mac PopUp menu is a menu. It contains checkable items and commands that act on those items. It serves mostly the same purpose as the Windows Drop-Down list but its not the same thing.
The thing that proves this the most... Mac PopUp and PullDown menus use a menu, ie. they look the same as the menus you open from the menubar. The Mac ComboBox uses a plain window with a listbox, ie. it does _not_ look like a menu. On Windows they all look the same. Drop-Down lists and ComboBoxes use the same windo type, which is _not_ the same as what you get when you open a menu from the menu bar. Basically the Drop-Down list is a read-only ComboBox.
And to show this:
http://www.beariscoding.com/macmenus.png
http://www.beariscoding.com/winmenus.png
To recap:
• Mac PopUp Menus should be used to select 1 item of a list but should also offer commands to manipulate that list.
• Windows Drop-Down menus (what RB gives you on windows for a Popupmenu control) is not a menu, but a list. Its basically a ComboBox thats not editable.
• Mac PullDown menus should only contain commands, not selectable items.
• ComboBoxes (which behave exactly the same way on both platforms) should be used where you want people to enter text, but you can offer them suggestions or completions. eg, the Function name field in the Add Method dialog in RB. (and as an example of where one should be used... the Safari address bar _should_ be a ComboBox, as it acts like).
Cheers,
Adam
Hope this doesn't become a double post... it added it and it didn't appear... :/