Well, since I'm expostulating about my own personal design rules... Here are some of my UI design rules.
1) If there are more than 10-15 "controls" in any given view, then the UI needs to be redesigned. Now, what do I mean by "control?" I mean a logical set of functionality. So if you have a GroupBox surrounding a set of radio buttons, that's one control. If you have a static text which describes an edit field, that's one control. If you have too much "stuff" going on in any given view of your program, then your program is going to be very confusing to users. I've seen projects with 200+ controls on a single window -- that's unacceptable in just about any plausible scenario (aside from "I use this myself, and I'm the only one who uses it). Too much stuff = Bad UI.
2) If you have more than four radio buttons, it should probably be a popup menu. Radio buttons allow you to pick one option from a group of choices. That's the same behavior you get out of a PopupMenu control. The difference is that the popup menu only takes up space for one control, and radio buttons take up multiple spaces, plus the groupbox space.
3) If you have a tab panel inside of another tab panel, you need to redesign your UI. There's no good reason for a tab panel inside of a tab panel. If you point out published apps which do it, then great! You should write to them and complain.
4) If you have more than three different colors (excluding images and icons and things like syntax highlighting, hyperlinks, etc) in any given view, you should rethink your design. I'm talking about the UI where the window is a non-standard background color, and then each button on the window is also a non-standard UI color. Are those colors really needed? Because color usually detracts from a UI when used improperly. The more colors on the screen, the more confusing it is for your eyes to pick out any single important piece of the UI. Obviously, kids programs are excluded from this one. :-P
5) Any time there's a standard control with a non-standard color (be it text or background color), or non-standard font (size, style or face), it's time to really think hard about why there's a deviation. In some cases, it's perfectly acceptable. For instance, showing a user's color choice in a listbox. Or showing a user's font preference in a static text. Those sort of things are valid reasons. Having red text with a bold font style in a non-system font face at size 32 in a PushButton for just about any reason is invalid. ;-) Seriously -- use system fonts with system colors whenever possible. If you want to draw attention to the control, there are other ways to do so.
6) If anything is flashing in the UI, it better be an EditField caret.
7) MDI is unacceptable.
8) When in doubt, refer to the OS interface guidelines and follow them. They're put there for a reason and usually will show you the proper way to do things.
9) If you have more than 15-20 items in a menu, it's time to redesign that menu. Similarly, if you have < 3-5 items in the menu, you may want to do the same thing. Too many menu items scares people into thinking something is overly complex. Hiding related menu items in sub menus can help (but don't nest your submenus very deep!). Having too few items on a menu is a waste of a top-level menu item. That's screen real estate that the user sees always, so use it wisely.
10) Speaking of menus, you should never, ever have items that come and go. Only enable and disable. It's very confusing to users when menu items are sometimes there and sometimes not there. It's much easier for them to understand "hey, I can't use this right now, but it's still there when I need it." than it is for them to grok "hey, wait, I swore there was an item to do X here. Now where did that go?" You should setup your menu items when the app launches, and only set them up once. Once you have the menus set, then you can enable and disable as needed. Not certain if this rule applies to the Mac, where there's only one menu bar.
11) Continuing with the menus -- if you have an item that is always disabled, you've done something wrong. People will go nuts trying to figure out how to enable it. If it's going to always be disabled, it should have been removed at app launch time. A good example of when people do this is for debugging purposes, or registering purposes. If the user's already registered, then remove the item (at launch time) so they never see it. Don't just have it always disabled there, taunting them.
12) Don't mix up a PopupMenu and a ComboBox. They have separate uses. Use a ComboBox when it's ok for a user to enter their own text in. Use a PopupMenu when it's not ok. I see a lot of people use a ComboBox to display a list of items, and forget that the user can type in their own item. Bad mojo.
13) Similarly, and this is especially hard for Mac users, don't confuse a PopupMenu and a ContextualMenu. A popup menu is there to show a list of data. It *does not* perform actions (aside from perhaps updating a StaticText somewhere, such as a description). Contextual menus are there for firing actions, popup menus are there for displaying lists of data. What's more, on Windows, a popup menu has a very different visual look than a contextual menu (esp when compared to the Mac).
14) Contextual menus are your friend. I know that on the Mac, they are meant to be used sparingly. But on Windows and Linux, they're expected. So if you have a handy thing to do that you feel people may want quick access to, you can stick it into a contextual menu for them. However, contextual menus are *contextual* and you would do well to remember that. This means that the context changes what's in the menu. So if you right-click on a button, you should expect to get different results from right-clicking on an EditField.
15) Use system controls whenever possible. You may think you can design a button control that's uber awesome and so much cooler than the system's push button. But you're probably wrong. Because that system push button can work with screen readers. It supports high contrast mode. It properly supports keyboard and mouse interaction. It can do the right thing with a pressure screen. It gets rendered with the user's settings. And so on. There's a lot of work that the OS vendor does for you with their controls, and it's almost *always* better to let them do that work for you. So while your control may look prettier, it will probably also work worse.
Like I said, these are my design principles that I use for designing a UI. A lot of them are pretty standard design principles. But some of them tend to not be written in such concrete terms (such as how many controls in a view, how many menus is right, etc). You're welcome to follow these ideas as you see fit, or call me a crackpot. Whatever tickles your fancy. But I've found that my rules are usually pretty close to what should be followed if you want a "good" UI. Remember though, "good" is subjective. :-P
Good stuff, Aaron. Thanks!
I can understand why a tab panel inside a tab panel is poor design. How about a tab panel inside a PagePanel?
Thanks so much for the helpful tips in both Style postings! If you have more, please share!!!
TabPanels inside of a PagePanel isn't always an abomination, but that really depends on what you're doing. If you're using a PagePanel because your app has two modes (think "beginniner mode" and "expert mode"), then there's really no issue. But if you're using a PagePanel to make your own set of tabs (like REALbasic does with its tabs), then a tab panel inside of that really isn't a good idea.
Firefox redesigned their Options dialog in version 1.5 to have tabs-within-tabs and made it substantially worse in the process. (They disguise some of the tabs as icons, but they still behave exactly like tabs-- I'm not fooled! It also brings up the WTF question why, in a program whose selling point is that it has a tabbed interface, they use icons-that-behave-as-tabs instead of tabs?)
My rule of GUI design is much simplier: "Find how Lotus Notes solves the problem, then do the exact opposite."
I agree with most, but...
1) If there are more than 10-15 “controls†in any given view, then the UI needs to be redesigned.
Do you include here toolbars? If so, do you consider a toolbar as ONE control despite the number of buttons?
3) If you have a tab panel inside of another tab panel, you need to redesign your UI.
There are some exceptions - imagine this:
A tab panel where each tab represents a text file. For each text file (tab panel) I need to show the original text and also a modified version - the best way, in this case, is to use also a tab panel for “Orginal†and “Modified†versions, because there’s no space to show both.
9) If you have more than 15-20 items in a menu, it’s time to redesign that menu.
I presume you include here also the contextual menus. If so, RB needs to follow this rule when we add a new class to the project and click the “Super†property down arrow to get a list of all classes - the menu shows hundreds of items :)
15) Use system controls whenever possible[...]Because that system push button can work with screen readers. It supports high contrast mode. It properly supports keyboard and mouse interaction. It can do the right thing with a pressure screen. It gets rendered with the user’s settings.[...]
So, if you were to create a Windows only commercial application and needed to use a toolbar, what would you do? Would you use a 3dr party toolbar control that might not work correctly on all situations, as you describe above, or would you develop it using the API?
Currently my main problem with RB is the lack of a built-in toolbar control for Windows. I tried to develop it using the API (by following the TreeView example on your WFS) but it’s too much complex for me :)
The existing toolbar controls on the market do not follow some of the basic rules for toolbar controls and buttons on Windows. There’s not a single one that simulates correctly the DropDown button with a menu with a partial push effect (like the back and forward buttons on IE).
And using BevelButtons do not work correctly on Windows 2000 - just on XP, that simulates a toolbar button. On Windows 2000 the BevelButton has always a bevel (border) and there’s no way to get ride of it, the icons are drawn incorrectly and the background color is incorrect for sticky or toggle buttons - reports: tgdfsqeb, trqewsrl and kvyutzpc.
Here’s a challenge to you: Create an article on how to create a toolbar on Windows with a rebar control with the several types of buttons and icons, using the API - I don’t mind to pay $25 or more for it :)
Opps... it seems I got a little off-topic here and sorry for taking the opportunity to bring this back again, but toolbars is something very important on any application.
@Carlos
1) I think of a toolbar as one control.
3) Sorry, there's never a good reason for tabs inside of tabs. Ever. In that case, I'd show original and modified side-by-side (I'm assuming you need original because this is used for diff'ing or something) with each side independantly scrollable.
9) RB breaks rule #13 -- that should be a popup menu, NOT a contextual menu. But it does break it with the Add control menu in the window editor; tough NOT to break it there though...
15) I'd buy a 3rd party native toolbar control if I was really after the native toolbar functionality.
15) I’d buy a 3rd party native toolbar control if I was really after the native toolbar functionality.
Do you know or recommend any that works with RB? I tried to find one with no luck.
Funny you should ask -- http://forums.realsoftware.com/viewtopic.php?t=3424
Aaron,
2) -- so, what's the use of Radio Controls then at all? The way you say it, why not ALWAYS use popup menus instead when there's a choice?
13) -- a PopupMenu is used to only show a list? I thought ListBoxes are for. I don't really get what you mean here.
@TT -- radio controls are for small groups of controls. If you have a few exclusive options to pick from, radio buttons work well. They show you all of your choices up-front. But if you have more than a few, they become overwhelming. So they do have a purpose, only for small numbers of options.
The proper way to think of a popupmenu is as a specialized form of a listbox. It's a listbox where only the currently selected index is displayed. Again, a listbox is only useful if you want to show that much information. They take up a lot of room and they show you a lot of information. A popupmenu takes up less room, and shows you less information unless you interact with it. What a popup menu is NOT is a command-generating UI element. A popupmenu is not a push button, or a menu item. When the user selects something from the popup menu, they don't expect a bunch of actions to take place.
A for-instance on the PopupMenu vs ContextualMenu thing.
Let's say you have an Undo/Redo system. A popup menu selection should never, ever, cause an action that requires something being added to the Undo stack. If it's an action (something which requires an Undo), then it should be a contextual menu -- not a popup menu.
Very interesting thoughts. I have had the rare occassion where one tab panel inside of another was useful... Such as, twice.
I don't see tabs inside of tabs any different than menus inside menus, and you don't seem to have an aversion to submenus.
Even Apple uses tabs inside tabs -- check out System Prefs | Speech. And have you ever used iWork's Pages? The entire Inspector window is tabs inside tabs (the top row of tabs may look like icons, but it's still tabs within tabs).
Now if you say that tabs inside tabs is bad because RB gets confused when you do that, okay, but that's a program flaw, not a UI issue. =:)
Jay
@Jay -- as I said, pointing to apps which do it wrong isn't going to convince me it's right. ;-) Tabs inside of tabs is an abomination due to the accessibility issues with it. Menus inside of menus don't have the same accessiblity issues since there's a clearly defined behavior for them.
If *you* want to do tabs inside of tabs, I'm certainly not going to hunt you down and hurt you. But I won't be giving you any awards for a pretty UI either. ;-) However, *I* won't do tabs inside of tabs.
You asked whether it is ok to add and remove menu items on the Mac since there is only one menubar. I have seen it done, but like you said, it is very confusing. I would say, do NOT mess with menu visibility at runtime. The same way you wouldn't hide a "Save" pushbutton when there were no changes to save, do not hide menu items.
An particularly bad example is the Mac version of Maya - it has four entirely separate menubars which you choose between using a popupmenu in the main window! And each menu takes. up. the. entire. width. of. the. screen. It's basically unusable.
Aaron, now I start getting the grasp on a PopupMenu control, I guess. For example, if the user would select an item from such a menu, I would change the view of some other data, like like when one changes the view when one selects a tab from a tabpanel view, right?
BTW, I just used iDVD for the first time - there they even add a Undo Action when you switched a view (e.g. from the templates view to the layout view). That's very wrong indeed!
@TT -- sorta, yeah. The example I usually use is this. You have a PopupMenu and a StaticText. The static text describes in detail the item selected by the popup menu. In this case, selecting the popup menu would change the static text's text. That's acceptable to do -- it's not an action you would undo. However! If selecting that item from the popup menu saved some changes into a text file somewhere as well as changing the description text, that would be unacceptable (since that's an action you would want the ability to undo).
The most common interface I see for the latter case (where the popup menu chooses an action) is to have a PushButton next to the PopupMenu which actually performs the action.
Wow - here i was, going to ask you about the toolbar issue, but it looks like you knocked it dead.
A few issues, however, are not dealt with.
1. Would a palette be considered in the same class as a toolbar, or would the limitation be there as well?
2. Would a dynamic control, such as the swatches palette (where you can add and remove as many colors as you need), be considered as one or individual? (I point this out, if yes, that this might be one of very few exceptions where it would be bad design - after all, it's not that hard to figure out.)
3. On tab panels, is that 15-20 controls just on one tab or the entire panel altogether? (this ties into the palette thing.)
4. I know you mentioned the OS controls, but what about Non-OS controls? I'm not asking about tab panels and stuff like that, I'm talking more program specific controls - the color switcher found in most graphics programs, for example.
(I have opinions, just kinda curious how they mesh with your thoughts. :) )
@Wayne --
1) Depends on what it's used for. Since those are usually "mini windows", I'd say they should have less stuff crammed onto them. If you're just using it as a floating toolbar, then yeah, it's one control.
2) Since they're all related, it'd be one control. But I claim it should probably be a list control instead of just a set of canvases. That way the list can scroll when it gets too large.
3) It goes by view, so that'd be just one tab.
4) If there's not an OS control that's designed to meet your needs, then by all means, make a custom control. They certainly have a purpose in life. For instance, RB's tabs can't be OS tabs because OS tabs don't have a close widget mechanism (and on some OSes, you can't display icons in them either). So a custom control makes sense for those. The thing to remember though is that the OS takes care of a lot of work for you. In order to make your app shine, you really need to put in that leg-work yourself.
I consider this very usefull for quite a few people! I for one hate programs where people have destroyed the "Windows/Macintosh" button positioning styles or sizes. For example, making a large window nothing but a gigantic button that says "Ok" or something similar.
How about using more white space in your post so that it doesn't look like one giant mass of text? Why not use an ordered list for your points instead of justified paragraphs with no space between them?
What little I was able to read looked interesting, but I'm not going to take UI design advice from someone who produces such poorly designed documents.
>> How about using more white space in your post so that it doesn’t look like one giant mass of text? Why not use an ordered list for your points instead of justified paragraphs with no space between them?
Aah, crud, WordPress ate most of my post because I used left angle brackets. Boo for doing that and for not having a Preview mode. On the other hand, I should probably have been smarter since I just got burned by this on another blog. But at least in that case I was able to hit the Back button and get back to my browser's cached state of the text area.
Anyway, IIRC I had three main comments:
First, I had the same reaction as Dave regarding the readability of this post. An ordered list for the points would put some space between them and would also indent the text so that the numbers stand out, making each bullet easier to pick out visually. I would also try to start each point with a pithy summarizing phrase and highlight it, which would make the points even easier to pick out visually, and also easier to remember. It's sometimes tricky to come up with a catchphrase if you're making a subtle or complex point, but I would try.
Second, I notice you provide more rationale for some points than for others. When there is no rationale, a UI rule comes across to me as a matter of taste -- or even worse, as a guess -- which makes me trust it less. For example, no rationale is given for why nested tabs are always bad. I can't tell if an aesthetic judgment is being made, or if there is some logic that says nested tabs make a UI less usable. Maybe the reasoning is self-evident to others; it wasn't to me.
Third, I'm glad you qualified #2 with the word "probably." A popup menu does take less space than a radio bank, but at a cost. It costs the user an extra click to reveal all available options, and then the mouse has to travel to the desired one. I would say the right answer depends not only on how many options you have, but on how busy the window is otherwise and how often the user is likely to change the selected option. Others have mentioned the list box, which lies between a radio bank and a popup menu in terms of the tradeoffs in screen real estate, visibility of options, and gestural demands on the user.
@Dave & Andy -- yeah, the formatting sucks. So sue me. :-P I wrote the post quickly while in a meeting, so formatting wasn't exactly on my mind too much. Next time I'll try to do better.
@Andy -- Some points just seem so obvious that they require no rationale (and others are points I covered in different blogs, such as my thoughts on MDI). For instance, tabs within tabs have so many accessibility issues with them (when I use the keyboard to navigate the tabs, which set of tabs am I trying to navigate?). I could have expounded, but I figured that it'd be easier to just answer people's questions instead.
As for the Radio vs Popup vs Listbox, the cost is negligible to use a PopupMenu in the scenario I provided. If the user is prompted with a "bunch" of radio buttons, they're going to have a harder time with your UI than if they have to click once to see a list of the choices (and not be prompted up-front with so much information that they feel overwhelmed). The ListBox doesn't help very much because 1) it doesn't solve the too much information problem and 2) It's not obvious that you can select only one item from the list.
You're right in that the decision to use a popup vs radio buttons depends on how busy the window is. But usually, with more than four options, the window will already start being busy. But the 4 is subjective and not a hard-and-fast rule.
Btw, you're thinking of a popup menu as being more expensive in terms of time it takes to select an option, but that depends on how your user interacts with the UI. For mouse people, yes, it takes an extra click. For keyboard people, it can take less keystrokes. Ttab into the control, hit Alt+Enter, press the letter to select the item. With radio buttons, you have to tab into the button group, use the arrow keys to navigate the list of buttons (which has drawbacks), and hit space to select the button you want. Granted, the good UI designer will give all the options mnemonics so the user only has to hit Alt+Letter, but that requires unique mnemonics, which is difficult when the UI becomes too cluttered.
I think a blog posting on this topic might not be a bad idea.
Some points just seem so obvious that they require no rationale
If something goes without saying, why bother to say it? :) There is so much subjectivity in UI discussions that a few words to back up a point are a good idea IMO, especially in a post with an instructional tone and especially where readers can come from all kinds of backgrounds. But I understand you were blogging in a hurry; I don't mean to over-nitpick when you've put in time and effort to help other developers. Also, In fairness, you do link to the HIG docs, which provide guiding principles that one could connect to the points you make.
Your points about keyboard navigation, in both popup menus and tab views, are well taken; I had overlooked that aspect of usability. My point wasn't that "your" UI was wrong, but that it's important to understand the reasoning process rather than blindly follow a rule. Keyboard navigation is one of several factors to consider.
@Andy -- you brought up some really good points though, so I've actually started a posting (probably for Monday) which describes in more detail the entire radio vs popup vs listbox question. I've seen a few people confused by what I mean, so a more in-depth on what my thoughts are is a good idea.
And you're absolutely right about blindly following rules. UI design is highly subjective in some respects. And this posting wasn't so much about rules (well, some of it was), as it was about things which I personally try to follow.
There are most likely a ton of situations people could point out where my "rules" make no sense. For instance, in data entry, it's fine to have a ton of controls on the window -- the purpose to the UI is to quickly enter as much information as possible; not hold the user's hand.
Cool, thanks Aaron.