This is more a best practices/usability question around the behavior of MacOS apps.
I have an app where a user is constantly typing into a NSTextView (think text editor).
I want to support a few keyboard shortcuts for common tasks within the app so that the user does not need to reach for the mouse to click a button.
But because the user is also typing into a text view, this is a bit tricky figuring out what combinations are available.
All single character keys are off limits (since the user will actually want to type that character).
Most cmd+key combinations are also taken (cmd+c, cmd+left, cmd+right, etc).
What's the expected behavior/best practice here?
Related
I wonder, why doesn't xCode "act" as a normal editor? For example, when I press Ctrl+X, I'd like the current line to be copied-cut. When I press Shift+Tab I'd like the current selection to be shifted to the left, etc. That's the stuff most editors do by default.
How to make it do that?
Take a look at Preferences -> Key Bindings. Here you get a list of actions and their keyboard shortcuts - and you can change those keyboard shortcuts!
It's quite amazing how many actions there are, including a great number of familiar Emacs actions such as mark and yank. Many of them have no corresponding menu item; many of them have no keyboard shortcut by default. Some of them may be the things you are looking for, and all you need to do is change the shortcut if you don't like it. It is very possible that you'll find at least some bindings that you can use to make Xcode behave in a more familiar way.
Is there anybody who knows the history of appearance of Ctrl+Enter ↵ hotkey which means "Send"? It is pretty "classic" now. I remember that for the first time I've met that hotkey in ICQ 99, but now almost every IM have such hotkey and many popular social networking sites. Some time ago I was surprised that in the "Commit" dialog of eclipse IDE that hotkey also available with the same meaning.
I think Ctrl+Enter ↵ doesn't mean "Send". It means, "double-click", or "do the default".
In email clients Ctrl+Enter ↵ was the shorcut for finish-editing-and-send. I remember using it in Microsoft Internet Mail and News back in Win95 days. Probably Mirabilis copied it for ICQ and others copied from ICQ.
Of course, it's impossible to answer something like this for certain, but I'll offer myself as a candidate for creating this standard.
In the summer of 1992, I was a junior programmer at America Online (AOL), working on what was to be version 1.0 of the Windows AOL client software. Part of my duties included refining many of the UI forms, including E-mail composition and Instant Message composition. Like many techies of that era, I was a keyboard jockey... using a mouse just slowed me down. I wanted a way to send messages quickly. Some of my colleagues suggested that I could just hit TAB until input focus was on the "Send" button, then hit the spacebar to activate the button. That was true enough, but for me the problem was that every composition form was structured differently... maybe the E-mail form needed Tab ↹ Tab ↹ Tab ↹ Space , while the IM form needed Tab ↹ Tab ↹ Space . Sometimes it even varied for new messages vs. replies. Yuck.
One day I became tired of the inconsistency, and decided to add a consistent keyboard shortcut for "Send" to all composition forms. My first choice was actually the Enter key on the numeric keypad. Seemed easy enough, but I soon realized that many people used the numeric keypad to move the input cursor, and would sometimes mistakenly hit the Enter key, prematurely sending their message. Not good. Next beta release, I changed all those shortcuts to Ctrl+Enter ↵, with the idea that it was virtually impossible to press Ctrl+Enter ↵ by mistake, but quite easy to hit that key combo with one hand if that was your intention.
There were no reported complaints about that shortcut, nor did I explicitly document it anywhere. However, before long, various "guides to America Online" had published the shortcut, and it remains to this day, AFAIK. At the time I selected that shortcut, I was not aware of any other software that used Ctrl+Enter ↵ to mean "Send".
Over the following few years, the Windows America Online client was arguably the single most popular way to send online messages, and I know the Ctrl+Enter ↵ shortcut became very popular amongst power users. This solidly predated Windows 95 and its related apps. Was this the true genesis of the shortcut? I don't know for sure, but I like to think so. :)
I think the first, and probably still most obvious, use for Ctrl+Enter ↵ was to insert a new line, in a text box where usually you don't need more than one line, and thus the simple Enter is used to confirm the entry.
In applications where you do need to enter many lines, such as e-mail clients, it comes natural to do the opposite, that is assign Ctrl+Enter ↵ to the function normally associated with simple Enter (usually confirm the entry, which can be regarded as send the message in an e-mail client).
I don't have historic references, so I can't say for sure, but I saw Ctrl+Enter ↵ used for line inserting a lot earlier than seeing it used to send a message.
The thing is that it's usually an hidden use, in that you rarely need it and is rarely documented, but if you try you'll see a lot of apparently single-line text boxes accepting a Ctrl+Enter ↵ to insert a new line, and that often turns out as a big time-saver and a major increase in the usefulness of the functionality.
The shortcut is probably harmed significantly by the use of Alt+Enter ↵ in Excel to enter new lines, with Ctrl+Enter ↵ left for a more obscure functionality (and probably just as a side-effect for confirming the entry without moving to another cell). It's likely that more people know about this than the (to my knowledge) much more widely used Ctrl+Enter ↵.
Of course it's also possible that Alt+Enter ↵ came first, I'm not really a software historian
Consider that, for a Windows video game, I need to determine if the key which generates the ` and ~ characters on the U.S. English keyboard layout (which is usually below the Escape key and left to 1) has been pressed. This may sound like a trivial question, but it doesn't seem like one to me.
When Windows sends keyboard messages, it specifies the virtual key code and the OEM scan code. We can't rely on the OEM scan code, because "the value depends on the OEM" - and nor can we depend on the virtual key code, because it depends on the currently active keyboard layout.
Our current "solution" is to use LoadKeyboardLayout and MapVirtualKeyEx to find the OEM scan code of the key that generates the ` character on the U.S. English keyboard layout, then just listen for that OEM scan code. The problem is that this doesn't work if the user doesn't have the U.S. English layout installed.
Is there a real way to do this on Windows?
The OEM scancode does not change from keyboard to keyboard. No reason not to use it.
Back in the DOS-days the same scancodes have been used for games because it has been the only way to detect key-up and key-down events. Noone had problems with it and I doubt it will change in the future.
If you want another option you may want to give DirectInput-API a try. It gives you the raw scancodes as well and if I'm not mistaken you can also query the physical position, dimension and whatnot of each key.
Tie the game action to the character, not the position of the key. Otherwise, how do you tell the user which key to press? "under the escape key"? They may not have anything there, but if you tell them "the ^ key", they can look for it.
You'll probably also want to make it configurable to accomodate exotic keyboard layouts and user preferences.
In pretty much all applications that have a menu bar, some of the items have an ellipsis (...) after them, and some don't. Is there a well known convention on when to put that ellipsis there and when not to? When do you do it? Do you do it?
I have looked at various windows applications, and this is what I have come to:
Ellipsis
Menu items which opens a form that require user input to do something (Replace, Go to, Font)
No ellipsis
Menu items which just does something (Cut, Paste, Exit, Save)
Menu items which opens a form that does not require user input (About, Check for Updates)
But then there always seems to be menu items that doesn't follow this rule. For example the Help items (How do I, Search, Index) and the Find and Replace (Quick Find, Find in Files, Find Symbol) in Visual Studio.
So after thinking about it a bit more I now think this might be the thing:
Ellipsis
Menu items that will definitely open a modal window.
No Ellipsis
Menu items that opens a non-modal window.
Menu items that doesn't open any window.
Menu items that most likely won't open a modal window (Like Save, which does open a modal window if you haven't saved before or something like that, but otherwise don't)
What do you guys think?
The crucial factor is whether the menu option requires additional information (input or a selection) before it carries out the operation. So Help-About doesn't require an ellipsis, but File-Open does. That's what the Microsoft, Apple and KDE guidelines say anyway.
Microsoft Windows applications are supposed to follow Microsoft's "User Experience Guidelines". Here's what they say about ellipses on menu items.
While menu commands are used for
immediate actions, more information
might be needed to perform the action.
Indicate a command that needs
additional information (including a
confirmation) by adding an ellipsis at
the end of the label.
This doesn't mean you should use an
ellipsis whenever an action displays
another window—only when additional
information is required to perform the
action. For example, the commands
About, Advanced, Help, Options,
Properties, and Settings must display
another window when clicked, but don't
require additional information from
the user. Therefore they don't need
ellipses.
David's answer cites the KDE 3 user interface guidelines,
Notice that every item in a menu that
first opens a dialog requiring
additional information must be
labelled with a trailing ellipsis
(...) (e.g. Save As..., Open...).
There's no space between the menu item
and the "...". A simple confirmation
dialog is not considered a dialog that
requires additional information.
The Apple Human Interface Guidelines say:
Append an ellipsis to a menu item’s label when people need to provide additional information before the action can complete. The ellipsis character (…) signals that another view will open in which people can input information or make choices.
Old versions of the HIG went into greater detail, and gave examples:
When it appears in the name of a
button or a menu item, an ellipsis
character (…) indicates to the user
that additional information is
required before the associated
operation can be performed.
Specifically, it prepares the user to
expect the appearance of a window or
dialog in which to make selections or
enter information before the command
executes. Because users expect instant
action from buttons and menu items (as
described in “Buttons” and “Menu
Behavior”), it's especially important
to prepare them for this alternate
behavior by appropriately displaying
the ellipsis character.
As far as I understand this, (...) a the end usually means that user will be asked for some input. And no (...) means that no input is needed.
You're right, that about sums it up. If you want to know more, you can find a list of User Style Guides here: http://www.experiencedynamics.com/science-usability/ui-style-guides
I'd agree, that matches my own perception of when to include the ellipsis fairly well.
I guess the point of the ellipsis is to "warn" the user, so that she can understand that a certain choice is safe to explore, it won't immediately do something without asking for more information through a dialog.
In some programs, like (at least older version of) Autodesk's Maya (a high-end 3D modelling package), the ellipsis was actually a small dialog-icon. You could click the icon, in the menu, to get the icon, or click the rest of the menu item (the text) to repeat the command with the same settings as last time, or something like that. It seems that idea didn't catch on and become mainstream.
This is a very tricky question indeed. At first had it might seem obvious but there are many actions that fall between the categories. It is interesting to see that Microsoft themselves violate this practice.
Example from Vista
In Computer Management menu File - Options... has ellipsis
In Computer Management / Users and Groups / Users. Right-click a user. The New user... action has ellipsis but Rename does not although it requires extra actions to actually rename the account.
In Micrsoft SQL Server Management Studio menu File - Print has Properties... button with Ellipsis.
This is just after 5 minutes of investigating. There are plenty more examples.
You can argue for both conventions for both these actions. You can't actually change any properties or options without doing some extra actions in the dialog that is displayed which assumes that ellipsis should be used. However you might just be interested in viewing what options or properties that are defined and that would assume that no ellipsis is used. Microsoft also acknowledge that there are instances when there is ambiguity
"In case of ambiguity (for example, the command label lacks a verb), decide based on the most likely user action. If simply viewing the window is a common action, don't use an ellipsis." However based on this it would make more sense to have ellipsis for Options and Properties as it is probably more likely that you want to change a property that just view it.
This is a GUI application (actually MFC). I need a command window with the ability to display a prompt like such:
Name of favorite porn star:
The user should be able to enter text after the prompt like such:
Name of favorite porn star: Raven Riley
But I need to prevent the user from moving the cursor into the prompt area. Users should also be prevented from backspacing into the prompt in order to prevent the following:
Rrraven Rrrileeey Ruuuulez!!! Name of favorite porn star:
Also need to control text selection and so on. And finally, I should have no problem retrieving only the text the user entered (minus prompt text).
Will it be better to create my own window class from scratch (i.e inherit from CWnd) or should I reuse the Windows EDIT control (i.e. inherit from CEdit)?
A similar command window can be seen in AutoCAD and Visual Studio (in debug mode).
I think you'd be better off creating a subclass of CEdit and limiting filtering key-presses. I suppose the hard part is not letting the user move the caret to the prompt area, but you can probably write some code to make sure the caret always get sent back to where it belongs (the input part).
Anyway, if you really, really want to implement your own control (it's not that difficult after all) I recommend you read Jacob Navia's "technical documentation" on how he built the LCC compiler and environment. Actually, it seems the docs are not online anymore, but I'm sure you can get them through his e-mail (jacob#jacob.remcomp.fr).
Edit: I liked your previous example better. Keep it classy, LOL :)
I had a very similar requirement and did exactly what davidg suggested; subclassed a edit control and filtered key presses. This was actually using Qt not MFC but the principle will be exactly the same.
You need to remember to filter keys such as home as well as left and backspace. I just checked to see if the move would move the caret into the prompt and if it did ignored the keypress.
Another thing to watch for is pasting multiline text, you will have to choose whether to just paste the first line or all lines, adding the prompt on all lines after the first. When subclassing the control you get lots of behaviour which won't work exactly as you want it.