Fast Open

I’ve been using Scrivener to write research papers and a thesis which involve quite a bit of hierarchically-organized research material. 6 or 7 sub-levels might seem a bit much for many, but in my case it is often very necessary. Otherwise I end up with data soup. Using MMD for output also forces me to express my manuscript contents hierarchy in the structure of my manuscript in the Binder. That is, of course, entirely logical, but does add to the depth I end up digging through to get to various parts of my work.

I’ve been mostly thrilled with Scrivener’s interface, but I do find myself hunt-and-pecking for the correct combination of treelist expand triangles to dig out a bit of material that isn’t linked in any open document. Quite often I’ve a fairly good idea what the title of that document happens to be, or at least how it starts.

Usually I wouldn’t stoop to asking for feature X in unrelated program Y, but in this case I would really appreciate something along the lines of Textmate’s “Go to File…” in Scrivener. For those unfamiliar, the feature works roughly so:

  • A small window pops up with a search field above and a file list below
  • Typing into the search box filters the file list below - any file matching the entered text in part remains in the list, while all others are filtered out
  • Pressing Return at any point opens the topmost result for editing

A similar feature for opening nodes quickly by title in Scrivener would likely save me hours, especially if it could be mapped to a keyboard shortcut.

Many thanks, feature or no feature. Quite a pretty piece of software, all in all. It has certainly been my home for the past few months!

When you use TextMate with the Markdown or MultiMarkdown bundle installed, it does something very similar. All the sections are in one file, of course, but it does let you quickly navigate.

I would guess it wouldn’t be too difficult to implement something similar in scrivener, but it might be fairly low on Keith’s priorities?

F-

It’s a good idea, I think. A quick keyboard based go-to would be nice. There is a slight work-around to this problem that you might find handy, and it is what I use to find a lost binder item. Project search. Cmd-Ctrl-F will get you there, and you can then type in the part of the title you remember. You should get some good results pretty quickly if the title isn’t too generic (if many are, you could consider using the Title restriction feature of Project Search). Once you have the file you want selected, just Cmd-Ctrl-F and Escape to clear the search. If you need to actually see the file in the Binder, Cmd-Opt-R will expand the necessary folder/text container architecture to do so. This method accomplishes all but the last in your list of wishes. Pressing return wouldn’t be desirable using this method anyway since search results are by Binder order, not by hit matching or relevance. You can Cmd-Opt-Ctrl-B to get to the search list and arrow keys to move about though.

On the problem of Binder order seeping into the Compile in a way that isn’t satisfactory: It is possible to disable title generation for individual Binder item types. In complex books with a lot of logical hierarchy (not outline hierarchy) I stick to use Folders for everything that needs a title. Then use text and text containers for all other sorting.

What is the difference between this and a project search using title only?
All the best,
Keith

Efficiency, mostly. It’s analogous to the way the Go To menu is different from the Binder. One has a large number of features and functions, the other performs one task only with minimal input. A Go To Title type feature would act like search in that it gathers binder items and so forth, but would only have one singular function, to isolate from that list a single result and jump straight to it without any fuss. A good implementation of this is in The Hit List. You tap the ‘g’ key and start typing a title, as soon as you’ve typed enough to identify the intended article, you press enter and that’s it. You can switch between lists with only two keys more than the unique portion of the title necessary to find it.

The more time one spends navigating, which I assume correlates to how often needs has to access different “materials” documents, the more substantial the dividend. In user experience terms, the argument for inclusion is that the feature streamlines the navigation process to the point where one needn’t commit any brainpower. The navigation interface becomes “transparent”, and is uncoupled from the search mechanism at large.

As concerns my personal motivation:

I am approaching the end of a project right now, and up to last week literally half of my time in Scrivener was spent digging through my source document hierarchy. I ended up dumping my “materials” section to text files, tossing together a script to pack all the metadata nicely, and dumping it all into a TextMate project.

Right now I’m doing all my external source work in TextMate, where I have “Project Search” (with regular expressions when I need metadata-only hits), as well as “Go to File…” as previously described. I have lost all of my highlighting, formatting, full screen reading, and generally all the creature comforts of Scrivener, but the efficiency benefit is substantial enough to warrant adding TextMate to my current Scrivener-BibDesk-Dictionary combo. The coating on my MacBook’s command and tab keys was in bad shape well before this, but it is hard to be happy with the compromise. Scrivener just barely comes up short.

On the one hand, you can write the feature off as a way to eliminate a very painful edge case (see above). On the other, I think you’ll find that the mechanism is intuitive and responsive enough that most users of other editors which sport the feature (there are analogs in Emacs, modern vim builds, and TextMate) favor it far and above hopping through outline views. I know ^⌥⌘B by heart in Scrivener, but I had look up ⌥⌘(backtick) in TextMate…

Another way to reduce endless searching of a very large binder, at least for a subset of frequently used files, would be to have a set of, say ten, user-defined favorite files, accessible through hotkeys or a menu.

I know this has been dismissed in the past, but it still would be very useful to writes of big, complex projects.

This is possible using the OS X keyboard shortcuts settings in System Prefs, assuming you aren’t allergic to mortifying hacks.

As long as your document titles don’t change, you can set an app-specific shortcut in the keyboard settings pref pane. There is possible weirdness in that the same item name technically exists in the “Append to…” menu as well. I’m on Leopard 10.5.6, and if i pop the “View” menu first I can get a hotkey bound to View-Editor-Go To-(Whatever).

There will be bookmarks for 2.0, which will place bookmarked files at the top of the Go To list etc, too.

As for the main feature request - did you know that if you are using Leopard you can already do much of what you want? If the focus is in the binder, you can type a title and the selection will jump to the title you type. This was added to table and outline controls in Leopard.

All the best,
Keith

Cool. That in itself is worth $19.95 of an upgrade.

I trust this will also include the “Append Selection to Document” list?

Wow, that does help, but only if the folder containing the item in question is expanded.

michpen - it will, yes.

kemitchell - yes, the default behaviour of this OS X feature only looks through the list of visible items in the binder. However, before it returns a result, it asks the program. If the program doesn’t tell it anything - as is the case with the current version of Scrivener - it uses the default behaviour. But the program can tell it to select something different. So presumably, at the point it asks, I could write some code to look for the next item and expand its parent folders if it isn’t currently visible, then have that selected. This seems to me a better solution than a whole new feature that would essentially do the same thing. Thoughts?

All the best,
Keith

I’m certainly not against even any incremental improvement on what is currently available.

However, in “essentially doing the same thing” I think the spirit of the feature request is lost. In terms of function the feature is already available. It is just clunky to use and buried in a UI element that primarily gets used for something else.

As concretely concerns the proposed workaround: It would give an incremental improvement in user experience for those who actually notice it, but in terms of what it does this actually gets us less than what the restricted search box provides. More precisely, it would save us one key command (C-M-A-b type A-M-r C-M-A-e | vs. | C-M-F type C-M-A-b A-M-r C-M-A-e) but at the cost of:

  • Non-standard behavior for a common control.
  • Requires “typing blind” i.e. the only feedback for input is a change in selection (typos?)
  • No fuzziness in search results or substring matching
  • Resolving a case where entered text might match multiple documents (or discovering that this is the case in a long binder) requires typing the same string again.

To be honest, I’m for the change, but if I were in your position, I would be against it. The “newness” of the feature from Apple’s side would make me wary. Also: how are busy users, who don’t have time to read the manual in its entirety, going to find out about this?

Having thought a bit more, I might propose a different half-way measure: a menu item that (1) changes the search type of the search box to “Search in Titles” and (2) focuses the bar.

The issue then is that switching back and forth from text searches to title searches remains clunky. You probably don’t want to go completely “modal” and store the previous search filter state. Thus, you might also consider another menu item for setting the filter to “Search all” and focusing the bar. Since I think it is fairly safe to assume that most searches are “Search all”-s, i think this would solve most of the problem if rigging up a separate UI box is entirely unappealing. Users who need this feature could simply adapt to using the new shortcut for “Search all” in place of the current “Find>Project search…”. Doing Title searches and broad criterion searches without worrying about the state of the search bar thus becomes painless.

There is already a menu item for moving to the search box (Edit > Find > Project Search). You can also set it to search only in titles using the search field menu. And there are shortcuts for jumping to the editor via the View mode (which will get easier in 2.0).

All the best,
Keith

Really the difference between the described proposal and the existing method is essentially the difference between using SpotLight and something like LaunchBar. One takes less than half-dozen keystrokes to get anywhere and start writing—the other takes a little moving around and such. The main thing which sets the two apart is not so much the number of steps required to do them, but whether or not you can do them blind. I can open a file in LaunchBar “blind” by rapidly typing in a series of letters that I know go precisely to it. I don’t wait for feedback, or read what it has to say, I just slam out three letters and hit return (some stuff, like Scrivener, is just one letter ‘s’ and return; I don’t even think about it). Spotlight requires that I read the interface, determine its accuracy, and then act upon it. Unless I never change the structure of the Binder, I can not “blindly” know how many times I’ll need to press DownArrow to get to the intended document, or if it will be at the top, et cetera. It requires “action, feedback, and action” as opposed to “action”.

I still think this fits the “would be nice, but adding to bloat, maybe in the future” category…
All the best,
Keith

+1

I would use anything that gave really rapid navigation to a binder item. Today’s Project Find is great but it really does interrupt my flow as well. I think kemitchell’s suggestion of 2 new menu items (which I can keyboard-shortcut) would serve well, without new UI machinery

As I say, not happening in the immediate future for reasons stated, and given that there is no voting system for features, just an autocracy (me), putting “+1” in a wish list item has no effect. :slight_smile: