The Find Applet is a truly bizarre mix of interface elements: a dialog box with a menu bar. This is typically regarded as a beginning programmer's mistake. There's always been a rather simple rule to follow when designing a window: dialog boxes don't have menus. Menus indicate a document-centric application, such as text editors and graphics applications, in which you can have multiple documents open simultaneously.

An 'Edit' menu? What is there to cut, copy or paste? 'View'?, there are no icons to arrange? Since this the only dialog box without a Cancel button, the first menu the user is likely to use is the File menu; it contains the Close command.

The Find window is not really a dialog box. Well, it is, sort of, until you perform a search. The menus become relevant only after you have hit the Find Now button (as opposed to Find Later), and they are only relevant if the search was successful. As soon as the user presses Find Now, the dialog box becomes taller, to display the results of the search. Of course, if you've moved the form to the lower portion of the screen, you might never know that your search was successful.

In this way, the Find dialog exists as both a dialog box and a document-centric application. Confused? So was the designer.

The basic problem is that the Find window attempts to simultaneously display the contents of what should be displayed in two separate windows. There should be an initial Find dialog, for the user to enter their criteria, and a separate results window. This would avoid confusing the user with controls that have no relevance to the separate purposes, and allows the design of a window optimized for its distinct purpose.

Now that you have the display arranged according to your needs, don't exit the Find Applet; if you do, you'll just have to reset them the next time you perform a search. Find has no memory between sessions, and no means to specify your display preferences.

Interface designers refer to all this management as excise; it represents all the piddly stuff you have to do just to get to the real purpose of your task. In Find this excise is part of the price the user has to pay because the designer decided to combine the criteria and results into the same window. If the designers had used a separate results window, they could have optimized its design to take into consideration the purpose of the window: to provide sufficient information, properly arranged, to allow the user to rapidly identify the desired file or files.

Thanks to Tim Jones for pointing out Find's forgetfulness:

I *HATE* the way the damn thing NEVER remembers what size I had its results portion or how wide columns were, fancy having to do that *every* time you use the darn thing...I use the damn thing everyday and it is amazing how quickly you adapt to such ugliness.

One point of conflict imposed by the Tabs is the type of files to be searched. As shown in the figure, the user could specify the file type by entering a file extension and wildcard for the 'Named' field (what kind of label is that?!) on the Name & Location Tab, or could select one of the file types from the 'Of type' (who comes up with these labels?) drop-down on the Advanced Tab. Changing one of these fields causes the other to change, but because they are placed on separate Tabs, this change is not visible to the user. Regardless of the criteria specified in the File Name field, Type will read 'All files...'. Changing the File Type has the effect of deleting the earlier *.ini specification. The end result of all this is that the user is confused as to which files are being searched for.

The appropriateness of the term 'Advanced' is dubious at best. Is searching for a string of text in files really an advanced feature? The likely result of the 'Advanced' label is that some users will be intimidated from ever exploring the Tab.

An appropriate design of the Find Criteria dialog would have been a single window which would allow the user to instantly see the types of criteria allowed, and allow them to specify any combination from the same location. The Find dialog allows very few criteria; therefore there is no reason not to provide them in a single location.

This is pretty powerful stuff, and probably the most advanced feature in the dialog. Unfortunately, the Containing field on the Advanced Tab does not support wildcards nor placeholders in searches. Entering develop* with the expectation of finding all files containing the words develop, developer, development, etc., will only lead to disappointment and frustration. The 'Containing' search is a literal search.

Interestingly, there is no indication that wildcards are permitted in the File Name field (nor any indication that they are not permitted on the Containing field). Further, there is no mention of wildcards in the Help file, nor in the context-sensitive ('What's This?') help for the field.

Since there was plenty of room left on the Tab, we can only surmise that Microsoft placed it in the Options menu only so that the Options menu would have more than one menu item under it.

By the way, Find ignores the case sensitivity setting when performing a File Name search (e.g., COPY*), even though Explorer displays files with case. Case sensitivity only applies when searching for a particular string within a file, therefore, it should only be enabled when a string has been specified.

The Find dialog 'Look in' control only displays the physical drives available for searching. The 'Look in' control used elsewhere in Explorer displays the drives, Network Neighborhood, and the desktop folders. To search a desktop folder, the user would have to click on Browse, then navigate through the hierarchy until C:\WINDOWS\DESKTOP\(folder) is specified. There can be no rational reason why the Find 'Look in' should operate any differently than any other 'Look in'.

When the user selects Save Search from the File menu, Find creates an icon on the desktop with a name assigned by Find. The user cannot specify the name nor the location of the saved search from the Find Applet. To change the name or location, you have to use a different application.

A related problem occurs when trying to run a previously saved search. The Find dialog provides no means of 'Opening' a previous search. You would have to open the search file from the Explorer, or perform a 'Find' to locate the search file before running it. This, quite simply, is bizarre, and is completely contrary to the principles of MDI design that Find is poorly attempting to implement.

Notice that the name that Find assigned to the desktop icon above. The actual search saved was the *.ini search shown previously on this page. Due to Windows95's own file-naming rules, the asterisk (*) is an invalid character in filenames, thus, a different character (@) is substituted. We would have to wonder how many users re-open such searches to see if they had mistyped the * in the critera.

I performed a search and clicked on the "Save Results" option numerous times, thinking that it would prompt me to save the results of my search, or at least place an icon on the desktop like it does when you select "Save Search" on the "File" menu. From what I could tell, all it did was place a checkmark next to the menu item. Selecting it again removed the checkmark.

After having lots of fun turning the checkmark on and off for a while, it suddenly dawned on me that I had no idea what was happening (and I consider myself a pretty savvy Windows user!).

It was not until visiting the Win95 help system, and performing a find on "find" (itself another area of discussion altogether), that Albert learned that to save the results of a search, the user must select "Save Results" from the Options menu, and select "Save Search" from the File menu. In other words, to accomplish a single task, the user must select two menu items from two different menus. We find it interesting that all that usability testing that Microsoft claimed to have performed did not find this to be ... awkward.

To see this for yourself, uncheck the checkbox (using any of the standard GUI techniques), click on the Advanced tab, then go back to the "Name & Location" tab. You will find that the "Include subfolders" checkbox has been magically selected for you.

Spin buttons are intended to provide guidance to the user by restricting input to the range of acceptable values. The range of acceptable values for the number of days in the Find Applet, as discovered by scrolling down until the minimum value is reached, and up until the maximum value is reached is from 0 to 999 days. So it would seem. When a search is performed using 0 days, the program responds with the message "You must specify a valid number." Despite the fact that 0 is indeed a valid number, the developer's failure to specify the correct range negates any benefit of using a spin control.

Another failure is evident in the fact that the user can, if he or she so desires, type letters into the textbox portion of the control. Since the applet can only interpret integers, the developer should have written a line or two of code to ignore any non-numeric input. This would have negated the need to perform a specific error-check for non-numeric input, and consequently, would have made the erroneous error message unnecessary.

Psychologists refer to this as a Mode Error, in that the behavior of the application is dependent on the selected mode (not unlike the difference in word processor behavior between "insert" vs. "overstrike" modes). The problem is exacerbated in the Find Applet by the fact that there is no indication of the particular mode, and moreso, by the fact that the mode is specified in a completely separate application. As a result of this design, the user can never be sure of the results of the familiar wildcard search unless he or she has gone to a separate application to ascertain whether or not the correct mode has been specified.

Alex Regenass wrote us to point out that Microsoft's translators made the German version of Find Applet even more difficult to use:

I fully agree with your criticism of the find applet. But in the german version of Windows 95 Microsoft even managed to make it worse. The button "Browse" which is used to choose another starting directory is labeled "Durchsuchen" which you could translate as "search", "comb", or "scour". The button "Find now" is labelled "Starten" (obviously translated as "Start"). So guess how many people try to find a file by clicking on "Durchsuchen". It happens to me even I know about this mislabelling. Arrgh.