So here's a trick that everyone should be using once they've got RB2005r3 (or greater) on their machines.
One problem I see people run into constantly, especially when they're unaware (such as people coming from the Mac, but creating a Win32 UI) is with keyboard mnemonics. For those of you who don't know what those are, they're the little underlined letters in your UI. These allow keyboard users to quickly navigate and utilize your UI and are a must-have for any Win32 application. You create a mnemonic by placing an & in front of the letter you want underlined, and you use a mnemonic by hitting Alt+ the underlined letter. The purpose of these mnemonics is to either transfer focus (such as mnemonics in a StaticText) or perform an action (such as mnemonics in a PushButton).
So what's the problem that I see people run into? Well, it's two-fold. The first problem is that people don't put any keyboard mnemonics in their UI. Remember: keyboard mnemonics are extremely important for a professional UI on Windows. Things like menus, static text, group boxes, push buttons, etc should *all* have a non-conflicting keyboard mnemonic. The general rule of thumb is, if the element can be interacted with directly, without text input, it should have a keyboard mnemonic. If the element doesn't satisfy this, it should have a label, which has a mnemonic to set focus. For example, a PushButton can get focus and doesn't take text input, so it has a mnemonic on it. An EditField can get focus but does take text input, so it should have a StaticText that describes it which has a mnemonic and sets focus to the EditField.
Unfortunately, there's no real good way to alert users when they're missing mnemonics because there are times when a mnemonic is not desired. For example, with an OK and Cancel button, you do not use a mnemonic because they already have keyboard shortcuts (Enter and Escape, respectively). So there's not much to be done here, sadly.
However, the second problem is with conflicting keyboard mnemonics. Quite often, it's very difficult to remember what mnemonic is assigned to which UI element. And the problem only gets worse as the UI gets more complex. And duplicate mnemonics are a real pain of a bug for keyboard users. For example, if I have &File as a menu label, and &Folder as a PushButton, every time I try to activate the push button with the keyboard, I get the File menu dropping down. Yeesh!
RB2005r3 has a way to combat this problem though! In the window editor, right click anywhere and you'll see a contextual menu choice which says "Check Keyboard Mnemonics." Selecting this choice will check the current view for keyboard mnemonic conflicts. This is an important distinction -- it checks the view you're currently in for conflicts, but the view can change. For example, if you have a tab panel, you need to check the view for each tab, since UI elements on non-visible tabs don't affect the current view. Same thing goes for PagePanels.
Let's see this in action. Open up a window, and put two PushButtons on it. Set the captions to be "F&oobar" and "&Ogre." Now, right click on the window and select Check Keyboard Mnemonics. You'll see that a dialog appears telling you that O is conflicting in those two UI elements. Now, we'll make it more interesting. Fix the first button to say "&Foobar" instead, and check the mnemonics again. Oops! Now you're in conflict with the File menu! Delete that button. Now, add a tab panel to the window, and add a button to it. Set the button's text to be "Wind&ow", and then click on the second tab. Checking the mnemonics shows that there are no conflicts. However, if you click back to the first tab and check again, you'll see that the O's are conflicting.
Another handy feature (that's been in since RB2005r1) is in the menu editor. When you set the text of a menu item, it checks the mnemonics against the current view automatically, and will alert you of a conflict immediately. Check the status bar for the conflicting information. For example, open up a menu bar, go to the EditMenu and add a new menu item. Set it's text to &Unreal. You'll see that the mnemonic 'U' conflicts with Undo.
When you get ready to release your application in the Windows market, you should use these features to your advantage. Make sure you have keyboard mnemonics and make sure they don't conflict. Doing these two simple actions will help you have a much more professional application on Windows.
One thing to be aware of is that on some versions of Windows (I think XP and above) the underline doesn't show up until you press the alt key. This is due to a setting in Control Panel >> Display >> Appearance Tab >> Effects. There is a check box for "Hide underlined letters for keyboard navigation until I press the Alt key" and it is checked by default.
This setting does what it says for most programs. RealBasic compiled apps appear to respect this setting for the menu, but controls like StaticText or BevelButton always show the underline. Some other programs don't respect this setting either. For example, Firefox menus always show the underline.
Yes, I should have mentioned that. It's DAMN annoying, and a horrible step backwards, IMO, that they have that on by default.
And you're partially right about the behavior (some apps just ignore it). The system has a very strange sense of when to show the underlines and when not to. Assuming the setting is on:
Top-level menus get the underline only when Alt is pressed. All other menu items get it always. UI elements on the window do not show the underline until the Alt key is pressed, but once it's been pressed, they display always until the window is closed.
How confusingly stupid is that? :-P
Yeah, it was probably a "feature" to keep some low ranking MS employee busy for a week. Definitely should not be there.
I just noticed that Office 2003 products always show the underline in menus. Go figure.
It's surprisingly difficult to get the behavior correct when you owner-draw things like the menus. It's also quite easy to overlook since most developers tend to turn that "feature" off (hiding mnemonics) once they install the OS. :-P
Minor correction Aaron:
By default, the underscores do not appear in the menu at all unless the Alt key is pressed. (Both the top-level items, and the other items.)
Among the applications that ignore this setting:
Word, Excel, Office in general, Firefox, Gaim, Microsoft Anti-Spyware (which doesn't show underlines at all... of course it has a weird mutant menu bar.)
Once you hit Alt once in a property page, it'll show the underlines... but they "stick" and hitting Alt again won't make them go away. (In fact, there doesn't seem to be any way of getting the underlines to go away once they're shown in a property page...)
Surprisingly, Lotus Notes, the application with the worst UI ever, actually respects this setting and handles it correctly. It even pops up little tooltips that show the keyboard shortcuts for non-menu items in the window when you hold Alt. How strange.
What this all boils down to is why do so many applications re-invent the wheel? What was so lacking in the default Windows menu bar that Microsoft Anti-Spyware had to write a new menu bar from scratch? (In the case of Firefox and Gaim you can kind of forgive them because they're cross-platform... but Lotus Notes is also cross-platform, and it does things correctly.)
Good catch James! As for why draw the menu yourself -- I'm guessing it's because each of those applications use icons in the menus. The Win32 APIs for doing this are atrocious to use (they support only certain sizes, color depths, etc), so it's easier to just owner-draw the menus.
Well, I'll challenge that... I actually like it that the Alt-key mnemonics are turned off by default. How many Windows users actually use the shortcuts? Maybe 1%? Mostly, us developers. (I do use them.) Otherwise, they just confuse my mom.
What Windows should do is just turn them all the time if they detect that the user intentionally uses them a couple of times (if you press the Alt key to display the hidden shortcuts). That way you wouldn't have to hunt down the hidden preference--your new PC would just automatically start displaying mnemonics after you select a couple of items via Alt-key.
I don't agree with that logic. The right mouse button confused my mom, but that doesn't mean it should be hidden, and after explaining to her why it's useful, she loves it. Let's face it, mnemonics are hardly an "in your face" type of confusion. If you don't use them, you don't even notice them. It's not like a dialog with technical jargon-type confusion.
And, I consider the "hold down alt to make this appear" thing to be a horrible design flaw. Just like I consider the "drag this CD and trash turns into eject" to be a horrible design flaw -- and for the same reasons too. The user has no initial idea that doing an action (like hitting Alt, or dragging an objet) is going to change the state and behavior of their workflow. There's no reason to hit Alt by itself, and so why would I (as a user) think to do it? Similarly, when I want to eject a CD, why would I ever think to start a drag operation? Both of these scenarios assume the user *already knows* the outcome of their actions. This means the UI is harder to use since it's unintuitive to discover functionality. It's a design flaw, IMNSHO.
But... if this sort of crap must be in place, I agree with you -- turn it on when you see that I use it. Don't make me hunt for the preference.
>> Let’s face it, mnemonics are hardly an “in your face†type of confusion. > There’s no reason to hit Alt by itself, and so why would I (as a user) think to do it? > Similarly, when I want to eject a CD, why would I ever think to start a drag operation?
>> Let’s face it, mnemonics are hardly an “in your face†type of confusion.
I'll agree with that. It certainly didn't prevent her from using it. But it does make the UI ugly" (scare quotes, those are!). That's probably why Microsoft hid them.
>> There’s no reason to hit Alt by itself, and so why would I (as a user) think to do it?
Well, if you're an advanced user that's wondering where all the mnemonics went, I suppose the very first time you saw it you might not understand what's going on. Other users aren't interested in mnemonics and will continue blissfully using the computer, unaware that the Alt key even exists ;)
Or perhaps you mean, how will users discover that they can use Alt as an accelerator, when they are becoming advanced users? Well, I don't see how having little underlines all over the interface will really help with that either. Until they understand that the Alt key is logically connected with accelerators, it doesn't matter if the mnemonics are flashing purple.
>> Similarly, when I want to eject a CD, why would I ever think to start a drag operation?
Very true. It's a bad UI, left over from Mac System 1 where there simply was no other way to add an "eject disk" command that could be done in one UI step. That's on the way out; all new keyboards that ship with Macs have an eject button. I never drag CDs to eject anymore, just press the eject button. Or push the "eject" button in the Mac sidebar on screen, if I happen to have a Finder window open.
Anyway, this is way too minor to be bothering you about. Thanks for the feature in r3; it's going to be insanely helpful once r4 is out. (I can't use r3 due to the external item bugs.)
Woah, that first attempt at my comment came out pretty garbled. I'm thinking that two less-than signs are a PHP or SQL end of string indicator, or something; originally, I had closed the quotes with double less than.
"Or perhaps you mean, how will users discover that they can use Alt as an accelerator, when they are becoming advanced users?"
No, I mean, for users who already understand the concept -- why would they think "gee, I need to hit Alt to see where my mnemonics have gone to." FWIW, I over-simplified how mnemonics work. You don't always need to hit the Alt key. If the control which currently has focus does not take keyboard input, you can simply hit the mnemonic without using Alt. For instance, if you hit Alt+F to get to the menu, you can hit 'x' to exit, without holding down Alt. Or, if you're on Windows 2000 or 2003, you can hit Ctl+Alt+Del to bring up the dialog that lets you choose admin options, and just hit 't' to bring up the Task Manager.
So there are plenty of cases where a mnemonic isn't shown, but hitting a key on the keyboard MAY do an action. The trouble with the new UI is that you have no clue which key may cause the action to happen since you're not shown the mnemonic.
This "feature" of the OS is one that's always twerked me the wrong way because it seems like a step backwards. The previous behavior was very unobtrusive for those who didn't know the feature existed, and the new behavior is obtrusive for the people who use the feature, and really has no affect on the people who don't use the feature (since they never noticed it in the first place).
Goddamnit, the old "drag a disk to the trash" crap.
It's been gone over about 50,000 times that the proper way to stop using a disk in MacOS Classic was the Put Away menu item in the Special menu. It had a shortcut (Y) and everything. The "drag to the trash can" was just a shortcut for this that somebody snuck in... it's not REQUIRED to put away a disk, the Put Away menu item works just fine.
Sorry for the ranting, but could we finally just put that one to rest once and for all? The correct way to stop using a disk is to use the "Put Away" command, period. The dragging is just a shortcut that wasn't even in the original design.
I had a mac for almost a decade (WinME was my first windows machine) and I always thought that the trash can should have changed to an open door or some other clever icon when you clicked on the disc to indicate that dragging it there would eject it. Regardless I always liked that feature of the mac for some reason... like the shut down that actually turned off your computer it seemed rather "high tech" at the time.
~joe
Heh, I'm sorry, I got to the "WinME was my first Windows box" and fell into convulsions of pity. You want to talk about a worthless OS, that one tops my list. :-P
As for dragging to the trash, I've always found it unintuitive and I rarely use it. I've always used the menu for it (or corresponding shortcut). However (directed at James), it's an easy UI disaster to point to. I could have used some other example to showcase the concept of pre-knowledge on the user's part, but this happened to be the first that came to mind. The moral of my long-winded story is, you should never use pre-knowledge in your UI since it's very difficult to discover the intentions.
Yea it was a move of desperation as Amelio experiment was failing and I wasn't able to find a decent statistical package for my mac. The irony of the whole thing was that I was looking forward to being able to program in BASIC again and soon thereafter I got my last Mac magazine and I believe it included a free demo copy of RB. I didn't give it a second thought since I had a forest of second rate basic languages to choose from. I like WinXP but since I'm running RB I've been pondering a return to the Mac.
~joe
By the way, check your work email for a message from me. I've proven oimkwgvo does really exist (the default button bug). It's the weirdest bug I've seen in some time--check out the demo project I sent you.
Anyway, all cool weirdness aside, it's really causing problems with my project that's otherwise ready for release, so if you could slip it into r4 really quick I'd appreciate it bigtime!
Adam
Thanks for the project -- there's definately a bug there. However, I don't slip things into releases anymore -- it comes back to bite me too often. ;-)
Well, it just bugs me that people always bring that up when there already was a perfectly good menu item and keyboard shortcut to put away a disk. Apple should never have let that 'drag to trash' shortcut make it into a release.
A couple suggestions about the 'Check Keyboard Mnemonics' option:
1. It should have some kind of feedback, so I know if it successfully executed and didn't find any conflicts. At least display a message in the status dialog (and make sure the message doesn't go away immediately if I mouse over something else by accident, like error messages do).
2. I really need a global option. I know this is work since you need to design a new UI with a summary pane showing each item's problems, but it would be really nice. I can't be moving around to each of my 50+ windows in each project checking each one individually.
I've filed these as feature requests: aktxdece and scihnftu, respectively.
1) It does give feedback on success, so I'm not certain what you're talking about. It tells you "There are no duplicate keyboard mnemonics in this view."
Do you have some steps to reproduce?
2) Yeah, this would be a nice option. But any time something requires UI, it pretty much triples the amount of time it takes to implement. So I try to avoid adding new UI. :-P
1) Hm. Close the report, then--I'll work on reproducing it.
2) OK, but it would be nice to have sometime. Even if it just took me to the next window with a duplicate.
I'll leave the report open for now, but whenever you get steps to reproduce, email them to me directly and I'll see if I can figure it out. From looking at the code, there's no code path that I can see which would fail to give feedback. So unless you're getting some sort of unhandled exception which takes you out of the normal code paths, I'm lost.
And just because I said it takes a lot longer to get UI into the product (and I should note, it's not that it's hard to do the UI, it's that it takes forever to get people to agree on the UI) doesn't mean it's not a good idea. ;-) I'll look into mocking up the UI and see if I can come up with something reasonable.
I can reproduce it. I'll see what I can do to narrow it down and send you some instructions; I have a guess that it could be there are some non-Controls on the window.