Keyboard navigation improvements?

Scrivener Wish List
1

Hi, I’m a long-time user of Scriv (since the “Gold” times…on and off) and I feel comfortable in it, except for a few issues when navigating in my projects. I haven’t found a discussion about this, so please have a look at my humble suggestions, maybe someone shares my views.

Very often (VERY often!) when I want to select all the text in my editor pane… I end up selecting every single file in the binder instead… It’s annoying, not because I keep on making the same dumb mistake, but because I’m working on a lot of files, and with my 512MB RAM it always takes a few seconds to select them all (when the whole structure in the binder is expanded… that is, all the time).
This of course happens because I’m still in the binder, while I thought my cursor was in the editor.
I wonder if there can be a better visual way in the future to tell the user if the binder is active or inactive? One solution would be to grey out the binder slightly to show it’s inactive.

The second request is for an improved way of navigating between the editors and the binder using the keyboard. I find the present system difficult to manage: I just can’t get to learn the different keystrokes, they all require 4 keys pressed at a time (and disjointed wrists, like Paganini’s…). I would like to see a context-dependent system, something like the following:

Whenever I don’t have a split editor I would like just to press cmd-key to go from the binder to the editor AND BACK. In other words, I’d like Scrivener to understand that I’m in the binder, so if I hit cmd-key it’ll take me to the editor, and if I’m in the editor, it’ll take me to the binder.

When I have a split editor instead, things get a little more complex, as I can choose to go:
A) From the binder to editor 1 (default editor)
B) From the binder to editor 2
C) From editor 1 to editor 2
D) From editor 1 to the binder
E) From editor 2 to editor 1
F) From editor 2 to the binder

I would therefore like to press (again) cmd-key to go from the binder to my default editor, and back, as above.
I would then just like to press cmd-opt-key to go from the binder to my second editor.
Finally, I would like to press the same cmd-opt-key when I’m in one of the editors to go to the second editor.
It’s 2 shortcuts for 8 different actions. Maybe this is unmanageable in terms of programming, I don’t know. Maybe it doesn’t make sense at all… but the bottom line is I’d like Scrivener to offer a better way to navigate with the keyboard.

As for the rest, I think Scrivener is a beautiful piece of sotfware.
All the best
Ptz

2

Thanks for your feedback. The binder selection already greys out if it’s inactive; anything else would be counter to the HIG (human interface guidelines). The trouble with the keyboard shortcuts is that most of the really short ones - cmd-something - are already taken up by common tasks. Most programs don’t even have any navigation between panes. And the trouble is that if you can navigate between the binder and the editor, you should also be able to navigate into the inspector - which the current system allows but which wouldn’t be possible if there was only one contextual shortcut. A contextual shortcut would either be limited to a toggle between binder and inspector or would end up getting more complicated than the current system by being too contextual. The system you suggest unfortunately only allows for navigation between the binder and the editors.

That said, I am open on this. I agree that navigation could be refined, it’s just how. Your suggestion wouldn’t be difficult to program; not at all. It is just that it brings up these issues:

• What cmd-key (and opt-cmd-key) is not already in use that would be intuitive for this.
• How would you navigate into the inspector? (Ctrl-opt-cmd, or shift-cmd perhaps? To which pane - the synopsis or the notes?)

In fact, I quite like your idea, so I’d welcome feedback or ideas from other users on the above.

On the other hand, though, given that you say that one of your problems is that you sometimes mistakenly select everything in the binder, in the current set up you only need to hit the keyboard shortcut to go to the editor to know that you are there. In your set up you wouldn’t be sure whether this would swap you to the editor or to the binder…

All the best,
Keith

3

Thanks keith for taking the time to reply.

That’s right, the selection does; but sometimes it’s not in view; and unless I messed with the colours (I did, actually) the binder background doesn’t grey out, do you confirm?

I understand your concern for the inspector… I didn’t include it in the same “pane navigation” category. I actually think that navigating to the features in the inspector could be done by normally assigning separate shortcuts, as it happens now. I see why you want to keep it under the same umbrella, but my feeling as a user is that navigating to and from the binder and the editors is a sort of a “more basic” action, more common, and one which needs more keyboard control than navigating to and from the inspector. This is also because the inspector usage is much more customizable, I think: for example, I sometimes use the synopsis, I don’t use keywords, I rely a lot on notes and labels, etc… So, to use your terminology, I guess I’m proposing a contexual system limited to the binder and the editors only.

Just FYI and to give you a comparison: I once worked on a Windows file manager which had the equivalent of your binder and two editors: it only had TAB and Shift-TAB to navigate; while it was not an elegant solution (and probably the Tab solution is not feasible in Scrivener), you were never two tabs away from your target.

…yes I’ll probably end up doing that twice in a row just to understand where I am… but I need to test it first to give you a confident answer :stuck_out_tongue:

Thanks
Ptz

4

You’re right that the binder doesn’t change colour (turn grey) when it loses focus - and neither should it. On some applications in Leopard - those that use a proper source list - such views turn grey to indicate an inactive window. It would not be correct to have it change colour if the window is still active. From a personal perspective, I’d hate it, and I doubt many users would really need such a visual cue anyway.

As for shortcuts - I think a number of users would disagree about inspector navigation. And you are correct that using the tab key for navigation between panes at all is completely out in Scrivener. Remember that it is mainly about text, so you couldn’t use the tab key for navigating if you were editing text.

One think I am thinking about is maybe using the arrow keys - opt-cmd and up, down, left and right. It would mean reassigning the zoom in/zoom out commands, but this could be intuitive - the arrow would point to the element you were trying to move to. I can’t promise anything as a feature, though, until I get to looking at it.

Best,
Keith

5

sure, thanks for taking it into consideration.

I think I found out the reason why I don’t seem to learn the ctrl-alt-cmd-B, E and R combinations: when I have one editor displayed, I can navigate to it with ctrl-alt-cmd-E; but when I have two of them (I decided on Top/Bottom for ease of use), to go to the same editor which is now at the top, I should press ctrl-alt-cmd-R instead! I’m not sure if I’m doing something wrong, but that’s the situation the way I set my layout now.

Maybe the “split editor” interface might benefit from simplification? Like calling the editors “Editor 1 and Editor 2” or “Primary and Secondary” or “Default and Alternate”, regardless of their position on the screen?

I also notice the submenu shows a “Supporting editor” which is always grayed out when my editor area is not split, but then it shows a “Top” and a “Bottom” editor when the area is split (or Left and Right, as appropriate). Is this normal? What’s the “Supporting editor”?

That said, I would have never thought of bothering you with these details if my trackpad hadn’t broken down… but I’m not comfortable using a mouse on an iBook…!

As for the arrow keys you mention, I think a large number of small utilities already use them (to shuffle iTunes songs without switching to iTunes, for example).
Ptz

6

I think it is an idea worth looking into but finding a simple shortcut would be quite difficult to say the least. You may have to find a seldom used “easy shortcut” and steal it and repalce it with a more difficult one so the easy one is freed up for use for navigation.

The trick will be deciding what shortcut to actually use…

this may help

7

Regarding “Supporting Editor”… This just means the other editor, which is neither top, bottom, right nor left if it isn’t visible. It can only be labelled with its position if it is on screen. Regarding having one editor always be primary… It used to be that way and I had hundreds of requests for the editors to have the same status. Which just goes to prove that you can’t please everyone! I prefer it the current way, though, as you can split the editor and then close the original pane and have it taken over by the other one if you want… It’s more flexible (navigation terminology notwithstanding).
Best,
Keith

8

Hi
New user here. I’d definitely concur with the second request.

Also, I don’t understand why the shortcuts under

View > Edit Scrivenings

are almost always greyed out with the corresponding keystrokes inactive. I’d really like a shortcut to enable me to edit my entire project with needing to take my hands off the keyboard & click over to a particular document or selection of documents in the binder first.

9

You can get over to the Binder user Ctrl-Option-Cmd-B, and then use the arrow keys in conjunction with shift to select multiple documents. The Edit Scrivenings shortcuts can be used right from the Binder. The reason some of them are greyed out is that not all of them are always relevant. Cmd-Opt-1 takes the selected container and forms a session out of its children—if you just have two straight documents selected, this command doesn’t make sense—in the latter case, Cmd-Opt-4 makes sense.

10

Hmm…if I’m in the editor and use Ctrl-Option-Cmd-B, all of the Edit Scrivenings shortcuts are disabled.

I guess Ctrl-Option-Cmd-B, followed by Option-up arrow, and Option-Cmd-1 works but it seems like a pretty convoluted sequence.

Are you saying that the label “All Content” for Option-Cmd-1 doesn’t actually refer to all content in the current document? I would assume that if it’s really editing all content, the context in which it’s applied shouldn’t matter.

11

“All Content” refers to all the content of a folder or file with subdocuments. Given that “Edit Scrivenings” compiles together multiple documents, obviously it won’t be available if you have only one document selected which has no subdocuments. I would definitely recommend referring to the Help file, which fully explains this.
Regards,
Keith

12

I’ve always found, on the contrary, the way one navigates with shortcuts in Scrivener very intuitive!

Maybe because I am one of these two-fingers-typing-guys. I keep the left hand above shift/ctrl/alt/cmd. Pressing ctrl-alt-cmd, that has become “jump!” in my body memory - plus a letter that tells where to jump.

I consider this easy. I mean - I know I want to go to the binder, don’t I? Therefore I press jump-B. After I’ve managed whatever I wanted to manage there, I want to go, let’s say, to the synopsis pane, therefore I press jump-U. And so on.

I wouldn’t want a system where I
(1) have to look where I am,
(2) decide whether I want to go to “the other place” and then
(3) give a command.

No. I want to go the editor - that’s jump-E. Target-oriented. The way a writer should be. :laughing:

13

Keith–thanks for clarifying the meaning of “All content.” I had been through the tutorial but hadn’t read the help files in detail.

Andreas – I guess what I’m trying to avoid is the “After I’ve managed whatever I wanted to manage there” of the workflow you describe. I’d like to avoid the intermediate steps of going to the binder and selecting the Draft folder before being able to edit the entire doc.

BTW I am very impressed overall with the program – it’s the only writing tool I’ve ever seen that makes it easy to take a document and break it apart into an outline/component parts. I had looked at it about 6 mos. back for a 250 pp. ms. but the learning curve / transition seemed like too much…now I’m trying again with a few shorter articles & can really see its strengths.

14

It takes time to get used to it, no matter how thoughtfully it’s designed and how easy everything looks. First you have to learn it, then you have to forget it again in order that keystrokes and everything else may happen almost by themselves, automatically and without thinking about the interface instead of thinking about the story. It just takes time.

15

Glad I looked before I leaped. The existing keyboard commands more than meet my needs. Thanks, WOK, for posting the long list.

Tom

Raleigh

16

NP :slight_smile:

Glad to help

17

Regarding navigation between Binder and Editor(s):

  1. If the given key combinations don’t seem intuitive or handy enough, remember you can use System Preferences to reassign those key commands to something more to your personal liking.

  2. In thinking of adding some additional navigational aid, maybe OS X’s cmd-tab function might be the right sort of model to think about. A single key combo does all the work: that’s good. It might just cycle you through the available (i.e. open) places (binder, editor(s), inspector),* or it might just take you to the last place. Either way, you would presumably need to have some visual clue as to where you were going (think royal blue bounding box around the relevant pane). Not sure about the general utility of the feature, but, for what it is worth, this is the kind of functionality that sprang to mind when I read this thread.

  3. Apropos of nothing, in my personal navigational regimen, these are the keys I really use constantly:

Cmd-opt-B : toggle the Binder (usually open)
Cmd-opt-I : toggle the Inspector (usually closed)
Cmd-opt-F : toggle Fullscreen

Ctrl-cmd-opt-B : move focus to the Binder
Ctrl-cmd-opt-E : move focus to the Editor

These custom additions are handy for me because I typically work on a 12" screen:
Cmd-opt-[ : Close binder, open inspector (uses a macro program to work)
Cmd-opt-] : Close inspector, open binder (uses a macro program to work)

–Greg

  • I think an argument might be made that cycling just between binder and editors would be a more generally useful aid than cycling also over to the inspector.
18

If I may … this has happened several times to me as well. It may already be on the 2.0 feature list, but anyway: at the moment there is no visual indication of which pane has the keyboard focus: binder, editor (1 or 2), inspector. The cursor (often hidden due to flashing, often tiny e.g. in the inspector) really does not draw your eye at all until you actually look at it.

The one exception to this is the “Project Find” field, which gets an unmistakable blue border when it has the focus.

Please consider using some highlight of the active pane. The blue border works well, perhaps that is feasible.

19

The highlight on the selected document in the binder should be blue if the binder has the focus and grey if it does not. The active editor has its title underlined.

20

Check the title in the header field. The active editor will be underscored. The Binder indicates active state by its selection bar becoming more vivid. When it is not active, it will be a light grey. This is blue or dark grey, depending on your OS preferences. If you do not have the “Source list” option checked in Fonts and Colors, it will be whatever colour your highlight preference is.

I think the main problem with indicating active frames, and I believe this has been stated before as a reason to not do it, is that any standard mechanism for doing so would be quite ugly. That bright blue border being around whatever you are in is kind of distracting. Further, it would not really truly be a standard mechanism with OSX. That frame does sometimes end up on an entire section, but when it does so, it generally means that any of the widgets within it are not active. At least that is how I have seen it done.

If you need or desire a more obvious cursor, check out the options in Text Editing preferences. “Use block insertion point”, “Disable insertion point blinking”, and “Block width” will all help to make the caret a bit more obvious. There are separate controls for the main editor and full screen.