A way to zoom comments and footnotes to a larger size in the same way one does in the editing panel so that they don’t appear so small. I’m currently writing an essay that requires a lot of footnotes and it’s getting to be an eyesore that they are so small. I should note, this is different from simply making the font size bigger as I don’t want to actually do that in the final product. Yes I know temporarily I could do that, but it’s frustrating having to do for every footnote.
I really think to make a footnote or comment that one should only have ‘right-click’ and select it from the same list where cut, copy, formatting, etc are available. I know there’s a shortcut to make a footnote, and a simple button in the comments and footnotes panel, but I think having it incorporated into the right click panel might be an additional feature that would make Scrivener better. I don’t remember all the various shortcuts scrivener has, and when I’m in fullscreen compose mode, the panel is obviously not available.
I think one should also be able to change the zoom factor of the outliner and corkboard (without changing the respective font size); this is according to the same reasoning I have explained with comments and footnotes.
(1) is already there - just right-click in the comments pane and choose the zoom factor.
As for (2), it is impossible to put every command in the contextual menu that is frequently used by every user, since every user has different frequently-used commands. As you note, there are already buttons and shortcuts for this, and a keyboard shortcut is much faster to access than the contextual menu.
Zooming the outliner and corkboard would be ugly, especially the outliner, which is an Apple-coded control and not designed for zooming. I don’t see any good reason for zooming in these controls, either, since you can just change the font size. It’s not like the editor or comments and footnotes where you are using rich text, so changing the font size is less practical - the outliner and corkboard are plain text and so you can choose the font that best suits you and your display.
Thanks Keith, really helpful. I have ‘zoomed’ the comments panel accordingly. As well, I see your point in just increasing the font size, in the corkboard and outliner. There’s no real need for zooming there.
However, I must disagree with your reasoning about not putting comments and footnotes as being a part of the right-click menu. The reason I felt the need to include these features in the right click menu is that both these features requires one to highlight text, or, in the case of footnotes, direct the cursor to a specific point in the text. Hence, the fastest way to annotate a text in both these scenarios would be to right click. Lifting your hand from the mouse to the keyboard to type a shortcut, or taking your mouse away from the point in the text in order go to format menubar-comment etc, kinda gets in the way. It’s a little thing, but I think it sometimes gets in the way of my thought process…and if the whole point of this app is make the experience of writing better…well…
I realize that every user has different needs however. I get that. So what I’m thinking of is perhaps options a user could have, decided in the program preferences, specifying which ‘right click’ features you’d like to have, and which you don’t. In the same way one can decide which icons you want to have in the toolbar, I think the same freedom of choice one should have in the right-click menu. So far I don’t know any program that can do this, but there’s a first time for everything.
Keyboard shortcuts are faster than right-click commands, sorry. You don’t use the mouse with both hands (I would hope), so one hand is always free while you’re using the mouse. Highlight with the mouse and then use the free hand to enter the keyboard shortcut. Done. In a context menu, you have to highlight, then right-click, then scroll down the context menu, then click again. This is definitely not faster, unless the command you want is right where the mouse cursor is when the context menu pops up.
yosimiti as others have said the real solution to your problem is to learn to touch type properly. Then there is no need for a right-hand mouse button context menu at all. Your productivity will go up.
While I do occasionally need to include footnotes into documents I don’t need them as often as I do need to insert citations to references. I want Kevin to put that feature on the context menu instead of footnotes/comments because it is vital to my work as a researcher and academic. However, I don’t want either on the context menu when I’m writing fiction or poetry or cook book recipes. (And no that’s not a suggestion to make context menus part of project templates—some of us change the template in use when we realise that, for example, a journal paper is more suited as a book chapter or a short story has grown to be a novella or a blank has become a radio script.
There is already too much on the context menus as it is adding anything more makes them no better than the menu bar options. The best way to access any of these options is not with more and more items being put into context menus but rather users—you included—learning to touch type and thereafter using the keyboard short cuts that are already available.
I type actually using a Dvorak configuration, so I am well aware of touch typing techniques. Shortcuts are sometimes cumbersome as what works for Qwerty may not necessarily be convenient for Dvorak. I also just have the memory of a goldfish, and can’t for the life of me remember keyboard shortcuts with all the other programs I use. This is why I suggested what I suggested.
I agree, in-text citation would be nice to have incorporated into Scrivener…
However, my suggestion is not that footnotes and commenting be necessarily a right-click feature, but rather that the user should be able to chose what he’d like to right-click to, from perhaps a set of options he can decide in Scrivener’s program preferences. This would include the option for in-text citations for instance, if one wants it, and if you don’t you should just de-select it from the program preferences.
Choosing what features go into a contextual menu is just not something done on the Mac. Contextual menus should contain the most commonly-used features, and so we limit it to the features that are likely to be used by the widest spectrum of users.
This is something you could do with a tool like BetterTouchTool to create a new gesture or key+mouse-click shortcut. You could write a little script for it too (just to call the menu option) and put it in the Service menu if you really want it as part of the context menu.
What contextual menus ‘should’ and ‘should not’ contain should be decided by users. I for instance, do not need to change my text colour, or my highlight colour, or apply formatting presets. I find this on a contextual menu thus to be unnecessary.
If you’ve actually researched and developed statistics about what’s “used by the widest spectrum of users” seemingly on such a minute matter as this, then I guess either (1) I’m frankly amazed and am in complete admiration or (2) this is the kind of thing you generally say to keep annoying rabble-rousers like yosimiti quiet, in which case I would appropriately be mildly annoyed.
Choosing what’s on a contextual menu should be something done on a mac. Why? Cause macs (should) rock the house!
That’s a level of customization that few programs on any platform out there perform – and for good reason: it’s a lot of engineering for something that most users are never going to need. Changing context menus to be fully customizable would probably take a lot of time and effort to develop, test, and validate just to make sure you stayed at feature parity without introducing any unexpected bugs – and it would make support and documentation become that much harder as well. (Now you can’t just say “Oh, context menu this option…” as the person may have changed it…)
That’s dev and test time that is then not available to fixing other bugs and introducing new features. It is likely to sell very few licenses, which is likely to mean it won’t pay for itself. I understand your desire to have it be more useful for your particular workflow, but I think that your particular workflow is probably a far statistical outlier. If you look through the forums, you’ll find that users are not shy about requesting all sorts of features and tweaks. KB et all need to be careful about which requests they choose to fulfill to benefit the majority of users and make sure they’re getting an appropriate development to usefulness ratio.
well, it’s a thought that I hope one day will entrench itself into the zeitgeist computer programmers get their ideas from…and I hope one day Keith and his posse will reach out and grasp the juicy fruit that I’ve thought of…
if there are such things as customizable toolbars, customizable contextual menus seem to be a natural extension…
Yeah, yeah, it’s harder to implement than simply to suggest. But I think it’ll make for a better product.
You can download and save the attached workflow in your ~/Library/Services directory to add a “Comment” option to the “Services” section of the context menu in Scrivener’s editor. This depends on Format > Comment having the default Shift-Cmd-8 shortcut. (There’s a way to write the applescript using the menu names rather than the shortcuts, but I hit a wall with that one and don’t have the time to spend on it. Feel free to rewrite it to meet your needs.)
Not without them paying a patent licence fee they won’t. There are several patents covering th idea of contextual context menus in existence; English mate of mine has one of them so Keith, being in England, would have to pay to use it.
However the greater problem is that not all windowing systems have APIs to dynamically construct context menus. Last time I looked at doing it in Windows (back in the days of 3.1 and 95) it was impossible to do in any sensible way. Remember that Scrivener runs on 2 and fhalf platforms all with different APIs with varied capabilities so even if it were trivial to implement on one it might be difficult to the point of uneconomic to do it on the others.
And as a small example of that, my partner has written two large historical novels and never made a single footnote; and I have written many academic papers and a large non-fiction (history of medicine) text with one or more footnotes on every page and suspect that I didn’t create a single one using the mouse.*
*Actually that’s a tad disingenuous: I pretty much had to give up mousing when I developed (unconnected) arthritis in my right shoulder; but even if I was able to use one for f/n I’m sure I still wouldn’t.
Just do me a favour and once something is on the context menu - don’t remove it, or rearrange it.
I can’t tell you the number of expletives I’ve directed towards Mozilla for removing context menu options from Firefox that “not enough people used”. Or they’ve just decided “to hell with how you’re used to working, we’re randomly moving this option to a different spot for no apparent reason.”
That’s it blame the dyslexic. (I am dyslexic and have an ed pysch report to prove it.) Similar words confuse me; I used to call my PhD supervisor 'Brain" although his name is Brian. So Keith will often become Kevin too.
I really can’t get my head around my someone using a Dvorak keyboard, which was devised to make typing easier, who would ever want to take their hands off such a peripheral and use a mouse. Shortcuts become second nature thanks to muscle memory.
People watching me use an application often see my fingers typing something and massive (intended) changes occur on screen. They ask what keys I pressed and I really have to think what it is I pressed because these things have become second nature. On one occasion it took me 10 minutes to remember what I type because like when playing a piano I knew where the “key” is and what I wanted to use it for but blow me I couldn’t remember when asked which specific one I used.
(I am dyslexic and have an ed pysch report to prove it.) Similar words confuse me; I used to call my PhD supervisor 'Brain" although his name is Brian. So Keith will often become Kevin too. 