Key shortcut for repeated Find?

[James Gifford—NitroPress]

In making a long series of minor edits to a book, I ran into a UI issue that's bugged me before.

Absolutely every other text-mangling tool I've ever used assigns Ctrl-F to "Find." So does ID. But where every other tool uses Ctrl-F to open the Find or Search pane on first call, then re-enter it (to the search term entry field), ID uses Ctrl-F to toggle Find/Change on and off the screen.

That is, every time I hit Ctrl-F in Word or Notepad++ or even most browsers, my next step is to start typing the search term, because the search window has been opened, or left open, and the cursor put in the search field.

In ID, if Find/Change is open... hitting Ctrl-F closes it. Which means that, digital memory flying ahead of me, I start to type the search term into the document itself. Annoying, and embarrassing if you don't catch that broken fragment before the author, client or published edition does.

Besides this confusion, it is inefficient [removed by moderator] to have to stop and click the search term box every single time.

I searched a few help topics without finding an answer. Am I missing an option, or another keyboard shortcut, or something? If not, is there a feature fix request in for this, and (while we're here) how would you prefer Find/Find Next Thing to work? Maybe Shift-F to toggle the Find/Change window, and (as seems to be widely standard) Ctrl-F to open the window if necessary but then return the cursor to the open search term field instead of toggling the window closed?

—

[Eugene Tyson]

Check the Keyboard Shortcuts for things like this

Load Find and Find Next instance	Text: ⇧ + F1	Text: ⇧ + F1
Load Find with selected text	Text: ⌘ + F1	Text: Ctrl + F1
Load Replace with selected text	Text: ⌘ + F2	Text: Ctrl + F2

Replace with Change To text and Find Next

Text: ⇧ + F3

Text: ⇧ + F3

Find Next	⌥ + ⌘ + F	Alt + Ctrl + F
Find/Change...	⌘ + F	Ctrl + F

For example - select your text then press CMD F1 or CTRL F1(windows) - if you're on Mac make sure your FN keys are active.

Then you don't even need to copy and paste - just use the keyboard shortcuts to move around. Less danger.

Mostly it just seems like you need to slow down. Take your time.

And use a Text Comparison tool - plenty online.

Load the previous file and the new file and compare

Or as I do on smaller projects -open the PDF in Photoshop

Flatten that page

Open the old version in photoshop on same page

set it to difference and 40%

Copy and paste it on top of the New file

Check for any text differences - it should be obvious were on the page a change was made.

[Lukas Engqvist]

There is a very good compare function in Acrobat. You can even generate a report depending on if it is text or layout changes you want to compare.

[Eugene Tyson]

Where good at finding text changes, it doesn't highlight differences between bold, italic etc. Text comparison tools can do this. So it makes an even smarter way of checking.

In case inadvertently changed something.

[James Gifford—NitroPress]

I can't see where a text comparison would have been any great help, since the workflow pass was editing about 100 spots in the press-ready layout (a very complex, textbook-like one), accompanied by text-fitting (tucking in widows and orphans, etc.) over 400 pages. I suppose I could have searched hundreds of flags for ones that were due to my mistypes, but in every case I caught myself making the mistake anyway.

But thanks; it's a good step for (mostly) simpler text flows and (mostly) after doing non-text work where few or no text changes should have occurred. I use it for things like global reformatting.

—

[James Gifford—NitroPress]

The list of keys is more or less the answer I was looking for, thanks. None of them were covered in the half dozen or so tutorials and help posts about F/C I looked at (the focus being on the many search modes and options).

However, unless I've mis-tested them, not a single one of those key combos works the way Ctrl-F does in every other app: start a new text search by putting the cursor in the text box. I mean, all the auto-load the selection and find stuff is nice, but if you have to search for "dog," and then search for "cat," and then search for "bird"... you have to stop and put the cursor in the field for each new search. Anomalous behavior in a general sense, and a hurdle to efficient workflow. Unless you're going to argue that ID got it right and every other app is wrong. 🙂

(I do periodically review the feature and keys list for all my major apps, and always find one or two things I'd overlooked and find useful.)

The bottom line here is that every single app of every kind I've used for... at least 30 years now, since app UIs standardized, uses Ctrl-F to (1) initiate search and (2) initiate next search. Can't think of an exception, across text, layout, database, office and programming tools. So ID's use of Ctrl-F to do (1) but implement not just a different, but conflicting/detrimental action on (2) is not a learning issue.

(Putting on my app/UX design hat, I'd put it in the category of a feature developed by one programmer or team according to their whims, and never fully reviewed. You see it all the time with minor features that really, really needed someone to review the UX.)

And yes, yes, I suppose I should have "slowed to ID's speed," but that's a patch, not a fix. I had to make ~100 author corrections and was using Find to locate each next one; since I usually do that in more standard tools it was hard not to hit "Ctrl-F... start typing next search term" as works—again—in absolutely every other tool of the last 20+ years. Having to stop and put the cursor in the search field was as pointless an interruption as having to spin around once in my chair between searches.

Yes, I am blaming the tool. I don't do it often.

ETA: I can't think of one time in a hundred that selecting text to start a Find was a useful approach. I suppose if you find one instance and then want to find others, or such, but in general a "find" means you don't know where the relevant text is. Obviously the UX team thought it was important enough to assign multiple keys to, though... 😛

—

[James Gifford—NitroPress · Accepted solution]

Feature request entered here.

—