Not only that, but when I use these commands, extremely strange things happen, like for instance, scrivener preferences opens???
Randall Lee Reetz
You need to use the shift key to get to the angle brackets. cmd-comma is the shortcut for prefs.
So why does the menu not indicate that I have to use the shift key with the command and the >< keys to zoom in and out?
You have to use the Shift key to get a ‘<’ or ‘>’ symbol.
Why isn’t it displayed? Ask Apple. We define what the shortcut is, but Apple’s code is responsible for actually showing it on the menu.
Katherine
Because Scrivener adheres to Apple’s human-interface guidelines (and on some keyboard layouts, the shift key might not be needed), and because Apple assumes users know whether the shift key is needed on their keyboard layout to access a particular character.
Are you new to using computers / Macs? The link in the quote below might help.
One of the key combinations you have been pressing is Command-Comma, which is a standard Apple key combination to open the preferences pane of the current app.
EDIT: Katherine posted while I was writing, but the link might help, so…
The other thing to think about: This is how Apple Pages displays these exact same keyboard combos for these exact same functions within its menus. Presumably, many Apple users may already be familiar with this usage.
How do you get the < and > characters while writing? Does your keyboard have specific < and > keys?
I do believe some layouts have these keys shifted from different base keys (they aren’t comma & period), and so in that case, printing the shortcut as ⇧⌘, would be false. It would be Command plus whatever combination of keys it takes to print a lesser-than sign.
Personally I’ve never been a huge fan of the nomenclature, and think the command should just be thought of as ⇧⌘BASEKEY, whatever that turns out being when shifted. That way each modifier is always printed in the menu and you can rely upon it, rather than this “well you gotta just know” approach of realising that ⌘A isn’t actually ⇧⌘a but ⌘| is actually [b]⇧⌘[/b] and not an ‘l’ or an ‘I’. But it’s Apple’s guidelines, so there’s really no sense in doing much more than grumbling to them about it.
Apple’s way of doing it is the only sensible way because the keyboard layouts differ between languages. In the Swedish keyboard the key immediately left of z (between shift and z) is < with > as the shift alternative. So Cmd < is exactly that whereas Cmd > is actually Cmd Shift <
Having the presentation of all those shortcuts changed because of changing keyboards seems to be unnecessay work. As a user you simply have to learn one basic concept: the shortcut shows the modification key and character, and if the character is a modified character, you need to press that modifier key as well.
But the pipe and the backslash aren’t always on the same key, so that wouldn’t hold true for all users, would it? Just as SHIFT COMMAND COMMA wouldn’t work universally as a zoom instruction. Or have I misunderstood?
You understand correctly in the sense that the characters aren’t always on the same keyboard keys. The keyboards used in Iceland, Sweden, Norway and Denmark are similar in some respects but different in some, depending on which of the odd characters that are more important in each language.
Both slash, pipe and backslash are found as modified versions of the 7 key in the Swedish keyboard, using shift, option, shift+option
Thanks, lunk.
Right, I’m aware that different regional keyboards have a variety of layouts—that’s not in conflict with what I’m suggesting. The point I was getting at is that the shortcut’s base key would be “,” with modifiers applied to it, the symbol “<” would in no way enter into the discussion. So it doesn’t really matter where the “<” key is on this or that keyboard, all the matters it the comma key and which modifiers you hold down along with it, each clearly printed in the menu.
Another way of looking at it: when used as a shortcut, the Shift key stops acting like a typing key and acts like a pure modifier. That wouldn’t be so strange, after all that is exactly what happens to the Option key. It is a typing key when used alone, a kind of “super shift” that lets you access invisible characters like ¥ and €. But when you press ⇧⌥⌘2 then Option stops being a typing key and becomes a pure modifier key. If we were to follow the same logic used here—that Shift isn’t really a modifier but is a typing key that makes the other modifier keys target a different symbol—then the consistent result would be print the above shortcut as ⌘€ and then let everyone figure out how to meta-super-shift the Euro symbol!
And no, I’m not seriously suggesting that is how ⇧⌥⌘2 should be printed in menus, I’m pointing out that showing the shifted character without the modifier key is inconsistent—and it isn’t even within the realm of Shifted shortcuts consistently used. Take a look at the Insert menu, where you will find that the shortcut to insert a comment is printed as ⇧⌘*. Why does that one print the shift key explicitly, while Zoom is ⌘>?
My point is that all of this special exceptional usage is unnecessarily confusing (and it is—we get support requests just like the OP’s all of the time). It should be ⇧⌘8 so that it makes sense right alongside ⌃⌘8 (insert footnote), and ⇧⌘, (not “<” but “,”) and so on. The only time Shift should be left out of the menu readout is if one does not press that key.
Interesting ideas.
I think…
Not all languages have the asterisk as an upper character, so they wouldn’t usually know / need to press the shift key. On many keyboards, ⇧⌘* looks like an anomaly, but as the shift key is operating as a modifier, there is a need for it to be made clear and written out as ⇧⌘*. Without the shift, the shortcut wouldn’t work. Alone, ⌘* would be meaningless.
That’s similar to Shift-Command-Equal sign being used to increase the size of the selection. For many keyboards, the equal sign is a lower character, so the shift is acting as a modifier. People aren’t using shift to select the plus sign which often sits above the equal sign.
I see your point, and desire for consistency, but for me, I cannot remember shortcuts unless they make “sense” to me. CMD > and CMD < make sense to me in that I only have to memorize one modifier key (CMD) and think “less than” or “greater than” to recall what the right combo is. Since I can touch-type, and have been typing those symbols for decades as part of my school work, hobby programming, and now my job, it’s ingrained in me to hold the shift key down to get < and >.
CMD SHIFT . and CMD SHIFT , don’t make any sense to me at all. Seeing them, I have to visualize the menu “Zoom In” and it’s association with the CMD, SHIFT and “.” or “,” keys. Or I have to look at the keyboard and remind myself that comma is on the same key as < and period is on the same key as > to re-assert the association with greater and lesser than.
I think it comes down to how people remember things; for me, the meaning of symbols matters more than consistency. And the fewer modifier keys to remember, the better. In the zoom example, I don’t have to remember the SHIFT key because it’s ingrained in me how to get the < and > symbols without actively thinking about the SHIFT key.
I will never remember most keyboard shortcuts beyond a short-term memorization for a specific task, but the ones that are just CMD and a symbol will always stick longer, even if that symbol requires a SHIFT key to be added to the mix.
This ongoing conflation with the shifted value is just the type of confusion that I think Apple’s approach generates! As I said, I would suggest the keyboard shortcut be ⇧⌘8 and that is it. Whether some keyboards have an asterisk shifted or unshifted (or on the 8 key for that matter) really doesn’t matter because the shortcut has nothing to do with an asterisk at this point, the only thing that matters is where your “8” key is, and which modifiers you hold down while pressing it.
That said, as an explanation for why one punctuation mark has a shift hint in the menu and another doesn’t—I don’t know. I still don’t understand how that is worth breaking consistency. Everything you say about how some people might need a hint to know that shift is a modifier key (and is it, really?) is true about the ⇧⌘> shortcut on a Swedish keyboard.
Sure maybe, but in that case we could say “<” and “>” only make sense because of how Apple labels them in menus. 
If they were not labelled that way then surely hardly anyone would select “,” and “.” for zooming in the first place, and you’d never have the opportunity to get confused over it. We’d be using the more common ⌘- and ⌘= probably, or even the “[" and "]” keys.
I couldn’t disagree with you that punctuation keys can be powerful mnemonics for shortcuts. In fact we specifically selected “8” for comments and footnotes because it hosts the asterisk key, which is of course an historically significant symbol for any form of annotation…
I’m just wondering whether it’s really worth it, when I see how many support queries we’ve had over the years from people wondering why a particular shifted shortcut doesn’t work, because Apple doesn’t print the actual modifier keys you have to hold down in order to trigger the shortcut. Where this is done the way I describe (just about everywhere but on a Mac), you do not see any questions like “how do I do X, the shortcut in the menu doesn’t work?”, or have to field “bug” reports pointing out some of the inconsistencies in nomenclature that I’ve mentioned.
And at least there are a lot of symbols unshifted. ⌘. in fact is a good example of a powerful mnemonic that has been employed since long before Mac OS X: HALT. But even if the shortcut isn’t printed with the symbol, I’d wonder whether or not we’d end up associated in our minds the more favourable concept for that key, even if Shift isn’t involved. To use Insert Footnote again as an example, that shortcut is actually ⌃⌘8; there is no shift involved, meaning technically it isn’t an asterisk—but, if you look at the “8” key what do you see? Does that make it easier to remember, it just being there on the key you need to press? Maybe not, I’m just thinking out loud at this point. I do something think about the shifted value for the shortcut I’m using, as they do sometimes make sense (more often they don’t, though—what about ⌘% to says “Take a snapshot with a title!”)—but I will also admit to having a memory like glue when it comes to shortcuts. For whatever reason I only need to look ’em up once or twice and I’m good for life (just don’t change it on me, that I cannot do, I will override the system if they change it—case in point, Apple tried to steal Shift-Cmd-5 for their badly coded replacement for Grab.app in 10.14. That got the smackdown and Scrivener went right back to taking titled snapshots, for me. 
).
THis is an interesting design discussion, but again both Apple Pages and Apple TextEdit use command > and command < for zooming (requiring shift on US keyboards, undenoted); command + and command - for text size ( by the above, the plus should require shift on US keyboards, but doesn’t.) Several other key combos in Scrivener follow Apple apps convention. I note that neither LibreOffice (more windows-like?) nor Nisus Writer Pro (more Word-like? haven’t used Word for decades so can’t tell) follow the Apple apps in their combos.
Yes, this is inconsistent usage, I agree. Each of the posters has made valid points. But:
If I were a suspicious dragon, I would suspect that KB elected to follow the already-established conventions in the Apple free apps for Mac Scrivener, betting on new user familiarity with key combos that they didn’t have to pay for 
, and also because so doing guarantees compliance with Apple user interface guidelines, however twisted they may be to us mere mortals. I therefore conclude that, consistency and logic aside, neither KB nor Apple is likely to be persuaded by this discussion.
I bow to reality and use Scrivener as it stands, with no opinion on which of the proposed changes is superior. After all, like rdale, I barely use key combos; my opinion hardly matters.
I think perhaps what I am saying is being taken down a rather different fork of thought than how I meant it. The only point I’m discussing is that Apple’s “grammar” for how it produces and communicates shortcut keys is a bit wonky, and it generates a form of perpetual confusion as a result. To go back to what I said right at the start:
As for whether any native Mac software should override the default commands given to common menu functions, that’s all rather outside of what I’ve been talking about. I don’t generally think that’s a good idea, and can lead to frustration, particularly when you end up in places like Adobe software where basic cursor navigation breaks Mac standards (let alone what you use to zoom).
Well my point is that, if I understand you correctly, you are wrong.
With the Swedish keyboard the shortcut for zoom out is literally the keys Command <, using the < key, and zoom in is Shift-Command <
There is no , (comma) key anywhere in this.
