The common clipboard is arguably one of the most important concepts to give rise to the non-modal computer (that can run several applications at once). Copy in one app, paste in another. It's great, and it's essential.

Oddly, it looks like Apple's trying to replicate this design pattern in the 'search' widget that has become common in the iApps (iTunes, Mail, Safari, etc.).

Experiment: Open Safari, navigate to a page, and use command-f to find a phrase in that page. Now switch to OS X's Mail program and enter a phrase into Mail's 'search' box, then go back to your Safari window and hit command-g ("Find Again"). Amazingly, Safari thinks that you don't actually want to 'find again' but you want to find an instance of the word you just 'searched' for in Mail!

I can see the designer's argument for why this could be a good idea: The most recently entered item into a lexical-specification widget must be the mote that the user is concentrating on at that moment, so naturally we're helping them if we assume that they want to find that same phrase in a web page.

There are two problems with this, in my opinion, neither of which are devastating alone, but combine badly.

First: It acts as if 'search' and 'find' are the same thing when they're not. To 'search' on the web, in a list of emails, or in an iTunes playlist actually means to filter based on a substring match. 'Find' on the other hand means to bring to the forefront the specific substring in the context of the data source currently being looked at, be it an individual email, word document, or web page.

Within the context of a specific application, bridging these together doesn't present a problem. It's usually a two-stage approach: First you search for relevant items, then you find within each item for the relevant data. Google uses this approach with the automatic highlighting of search criteria when displaying cached copies of pages returned from a search. Safari does it too, taking the text entered into the 'google search' field and placing it into the 'find' dialog, whether it's visible or not (and, perhaps arrogantly, whether you had previously been 'finding' for something else).

Within an application, soft-integrating search and find (or perhaps more appropriately, "filter and highlight") can be helpful, though it can still create unexpected results.

The second problem is the fact that different applications usually represent different cognitive tasks in the user's mind, so a search for one criteria in one application is irrelevant to the finding task in another application. Even worse, it can be a direct inhibitor, for example a few minutes ago when I was 'finding' IP numbers listed in a web page, then manually looking up the name next to the IP, filtering that name in Mail, then going back to find the next instance of the IP, only to find that Safari took me to the next instance of the person's name. This kind of self-perpetuating failure means I have to manually type or re-paste the 'find' criteria each time.

I don't know if this is an intentional design decision on Apple's part or an accidental sharing of the namespace for a widget class, though the former seems more likely, since shared namespaces across applications in a unix environment seems pretty darned unlikely considering find and search aren't OS X 'services'. Either way, I'll have to take a look later and see if the behavior exists in iTunes and other apps that use the find/search widget.

Oh, and on a different Safari-bug note, it appears that if you hit the 'find previous' button in the find dialog box, it does exactly the same thing as 'find next'. I guess that's why it's beta. :-)