I’ve been inspired by the Firefox interface, when I’m searching a word or an expression on a web page.
I think that could make Scrivener faster and more confortable for searching actions.
Maybe for a next version. 
Scrivener_Window.pdf (133 KB)
I have to say that I really dislike these in-window Find search fields. A lot of apps use them now, including TextEdit and Xcode, but I find them annoying. You have to click around more (I use shortcuts a lot) and you have to press extra buttons to show the “Replace” field. So Scrivener will be sticking with the separate Find panel, purely because I much prefer it. 
All the best,
Keith
I don’t think like you (and I’m also a shortcuts user too)
A search box at the bottom of the document’s window would be more confortable, and faster to be used than the find’s pop up window called with cmd F.
That would be more true when using the split screen, where it would be possible to have a different expression to search in each document at the same time.
Then to know the number of the occurencies would be a good information when your search is on a long document.
“there is more than one way to skin a cat”
It’s possible to have your cake and eat it too, if the in-window search field of the active window snaps to focus when you use the keyboard shortcut. Hit the shortcut again, and it acts like Tab to advance to the next search field.
I absolutely agree. I hate the extra clicks and looking around for where on earth Application X puts its search field. Give me a window that open up, so I always know where it is: In my face when I need it.
And yeah, the replace function the way TextEdit does it… NNGFJNENJ(/)Y0[ñüµ≠[ü±]ƒ[±ª¥≠ !
I don’t care what the search box looks like, just please for the love of god make it so it doesn’t pop up covering the first highlighted result. Why can’t it pop up over the inspector instead of over the editor?
I tend to not like these slide-in panels, mainly because they are usually created as a way of simplifying search down to a couple of buttons, and that’s the last thing I want for a search tool in a text editor. A web browser, sure, why not, a filter bar in a list of objects, like a photo viewer, fine—but interfaces like TextEdit are just maddeningly inaccessible and thus a pain to use for all but the most basic of searching (which I don’t even need a visible tool for most of the time, just double-click a word to search for and hit Cmd-E and off you go with Cmd-G).
Sublime Text is an interesting exception. Sublime doesn’t hide anything from you, every field and option is right in the slide-up panel, accessible via keyboard navigation and hotkeys (Opt-Cmd-W to toggle the “whole word” operator). Up and Down keys rotate through the search and replace pattern history. Esc dismisses the find panel in all cases, no matter where the cursor is. All functional exit buttons are wired to shortcuts (like Ctrl-Opt-Return to replace all and dismiss the panel in one move). Everything is fluid and the current search parameters are easily seen at a glance, no poking through magnifying glasses and flipping arrows because Replace is “advanced” or whatever.
To be fair, I would hugely prefer if Sublime Text had a standard Find window, but its implementation is good enough to suggest to me that the problem isn’t so much with whether the interface is in a window or panel, but with how the panel is typically implemented: with disregard for the various ways in which people used the window and the features within it. Just a very basic example: one should not have to enable full keyboard access in OS X and use five keystrokes to get from the Find field to the Replace field. That would be bad design no matter what type of panel mechanism you shove it into.