In Windows95, there is perhaps no better example of how applications should NOT be designed than the Find Applet. It suffers from poor overall structure, applies internally inconsistent control rules, employs controls that are inconsistent with the same controls used elsewhere in Windows95, restricts the user by applying arbitrary rules, and offers essentially no support. While it offers several useful features in addition to those provided by the Search function in the Windows3.1 File Manager, the implementation of those features is poorly realized.
Last updated 24-February-1999
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.
Viewing the results of the search can often involve a considerable amount of screen management. Find only leaves enough room to display 4 files, so you'll often want to resize the screen so that more files are listed. If you make extensive use of long file names, you'll probably want to increase the width of the name column. If you are interested in the file's location, you'll probably want to increase the width of the Folder column. Interested in the file dates? You'll either have to scroll to the right, or increase the width of the window to see them.
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.
The use of Tab sheets in this dialog represents an unnecessary application of micro-management. Tab sheets are a great means of reducing clutter on a complex windows, by organizing the information into discrete sections. However, their use in the Find dialog is inappropriate, since the dialog is neither complex nor cluttered, nor do the imposed sections reflect distinct sections. In fact, similar criteria are entered on separate Tabs, creating a conflict for the user.
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.
The image shown above also illustrates the inconsistent use of control rules in the Find applet. The File Name field supports the use of wildcard characters and placeholders for searching. As shown, *.ini would search for all files with the extension .ini. Similarly, d*.ini would locate any files beginning with the letter 'd' having the extension .ini, and ??d* would located all files that have the letter 'd' in the third character of the name, of any file extension.
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.
As discussed above, the Advanced Tab allows the user to search for those files containing a particular string. We found it somewhat surprising that the Tab did not provide a means to allow the user to specify a case sensitive search. For some inexplicable reason, case sensitivity for the search string is specified under the Options menu. If you forget about this hidden function, you might never get the results you expect.
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.
When specifying where the search can be conducted, Find provides a drop-down control with the label 'Look in'. Unfortunately, the Find 'Look in' control operates differently than all other Look in controls in Windows95.
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'.
One potentially nice feature of the Find Applet is that you can save your search criteria for use at some other time. Unfortunately, Microsoft's implementation of this feature leaves much to be desired.
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.
Unfortunately, the Find Applet's ability to save a search is dependent on when you decide to save it. Despite the fact that the "Save Search" menu item is enabled before a search is performed, and despite the fact that the applet will create a file on your desktop, the search itself is not saved. If you save your search before performing a search, all of your search criteria will be lost.
We'll let visitor Albert Walker describe this unusual interface feature:
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.
One notable feature of a well-designed GUI is that it provides the user a variety of ways to perform an action. For example, in addition to clicking on the control of choice, the user can also chose a keyboard shortcut, or can use the Tab key to navigate to the control. The designer of the Find Applet took this feature one step too far: in addition to clicking on the "Include subfolders" checkbox, the user can also set it by clicking on any of the other tabs in the dialog, then return to the "Name & Location" tab.
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.
The "Date Modified" tab of Find Applet provides spin buttons to allow the user to specify the number of days or months since a file was last modified. Given the size of the up and down buttons provided by the control, we would consider the use of spin buttons to be a dubious choice, even in the hands of a competent developer. In the case of the developer of the Find Applet, on the other hand, the implementation of the buttons is particularly poor.
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.
Peter Lind wrote to inform us of a particularly problematic feature of the Find Applet:
The success of a search performed with the Find Applet is dependent on the user's selection for the Hide Files option in the Explorer application. For example, if the Show all files option is selected, the Find Applet will correctly locate the file moricons.dll (located in the Windows directory), even if the user has simply entered "moricons" in the Named field. However, if the user selected the Hide files option in Explorer the Find Applet will incorrectly report that it cannot find "moricons", "moricons.*", or even "moricons.dl*". If the Hide files option is selected, the Find Applet will only find the file is the entire filename is specified.
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.
Perhaps one of the most shameful aspects of the Find Applet is the fact that it does not provide on-line help. Sure, there is a help menu, but selecting that will dump you into the Windows95 general help file, which contains only a mere mention of the Find Applet. There is no mention that you can search for strings in files, or use wildcards in File Name searches. The user is left to learn about the applet through trial and error, or by learning about it from some other source.
We received a letter from an individual using the name "Spearfish", which may provide some insight into Microsoft's reasoning behind the design of the Find dialog:
If Microsoft made everything perfect the first time around, they would be a defunct company. I hate to say it, but the find dialog problems were probably purposefully DUMB on the part of Microsoft. What better way to get at our pocket books again than to make a better product?
Our hope is that most developers will take the alternative view that quality sells.