* Note: This article was written in June 2006 and reflects the Spotlight interface at the time.
Apple’s Spotlight technology is great for two primary reasons: first, it is so tightly integrated with the OS that it’s index is always up to date, and when it performs searches, it considers not just content, but also metadata. While the degree of search is unparalleled for desktop search, there are improvements to be made with regards to the user experience.
Currently, there are two search result lists: one is a summary list that immediately appears below the corner search field, and the other is a more detailed list that appears once a user hits “return” after their search text.
The purpose of the short list is to give a quick, simple answer for the user in a hurry who expects to find their quarry with little fuss, and the larger window is a more detailed result set for a more involved search, but the results are organized in an entirely different way. Instead of presenting the same result list in two different places with two different interfaces and wildly different organization, I would prefer to utilize a single result list. This redesign has three goals: to satisfy both the quick and dirty and more rigorous search situations described above, to provide context for the search result, and to more strongly adhere to the OS X interface standards to provide familiarity to the user.
A combination of both text search and hierarchical organization is an excellent place to start. We already see this in iTunes and Mail, where as-you-type searching with contextual filter buttons have been added to an already solid file hierarchy. Both Mail and iTunes have an advantage with regards to search because the resulting files are all the same type (email or music files, respectively).
In the case of system-wide search for Spotlight, context is key. The initial window of Spotlight provides search results based on word matching, and the context is supplied by the continuously adjusting categories as more search results stream in. This jerky behavior is frustrating because the user can’t expect a particular result to remain in place. Additionally, no context beyond “kind” is provided in this interface. To get context, the user must hit ?return? and interpret a new interface. This “extended” search results interface provides context initially only by showing the date and time the file was created (incidentally, I believe that if only one date is provided, the date modified is more useful then the date created). To get more context, the user must either choose a sorting mechanism from the right side choices or click the “i” information icon. The information icon (notably a non-standard OS X UI element), behaves like a disclosure triangle and provides the data usually associated with the “get info” command: the dates the file was created, modified, and last opened, and file size, location path, and a preview. The preview is sometimes useful (graphics, pdfs) but oftentimes, it just shows a large icon for that filetype (mail messages, any kind of text file other then pdf). In short, the supporting information that is useful to put a filename match in context is dependent on the user going the extra step to choose a sorting filter and/or uncollapsing the info icon, and even this information is often non-essential (file size? filetype icon?) to the user. In addition, of the fourteen categories Spotlight can search, only about three categories (if they contain 5 or more results) and one image preview can fit vertically on a monitor at one time at 1024×768 screen resolution, meaning that the user must scroll to see other category results.
A solution to the these issues is to borrow from the improvements made to the Finder in Panther, namely using a source column to show every category Spotlight searches. The sources here are all fourteen types of media that Spotlight searches, organized into logical clusters and topped by an “All” choice. Each source that contains results will show the number of results it contains alongside the source name. The benefit is similar to that of an RSS reader: the user is presented with a non-moving, consistent list of channels to choose from. This list also serves to impress upon the user all the different media that Spotlight can search, extending it’s usefulness as a service. Assuming that three times out of four a user will know the media type they are seeking, they will be able to immediately click the category they want to get their results. [Additionally, because Spotlight clusters many user-authored files from different applications into “Documents”, the user can also choose to add a specific filetype (such as Maya or Flash for example) to the source list.] This interface also allows the user to scan a much longer list of search results, without having to scroll.
The results list of files will have columns of Filename, Path (last two directories) and Date Modified that are sortable and can be re-arranged. Additional columns such as Author, Date Created, Last Opened, Size, etc. can be added through Spotlight preferences. When a user re-sorts their results, a fluid re-arrangement animation moves the files to their new position in the list to provide visual continuity. Along the top of the window are filter buttons similar to those found in iTunes’ search and Mail’s search. Here, these buttons allow a user to specify the location of their search: Computer, Home, mounted volumes, or a specific folder a user has chosen. These considerations eliminate the need for the visually overwhelming filter criteria to the right of the “extended” results window in the current implementation of Spotlight, and provide the user with familiar interface elements with which to filter their results.
At the bottom of the results list, there is a preview pane similar to the preview pane found in Mail and the preview column in the Finder. Here, a user can see a thumbnail of an image or pdf, watch a video, play an audio file, or read the first lines of text of an email or text file. [In Spotlight, the only preview available for a text file such is an enlarged icon of the application associated with it. This is also true in the Finder, except when looking at a .txt file, where a preview of the actual text is shown. I would like to show the actual text for any text file in this redesign of Spotlight.]
While I’m at it, why not make a few improvements just for the sake of user delight?
The current method of summoning Spotlight is great — the key combination shortcut is a satisfying nod to “power users” while the clicking of the logo or choice to use an F key makes perfect sense for everyone else. However, I would like to leverage the spotlight metaphor to bring up the search field and the following search results.
The idea is this: once a user summons spotlight, the screen dims (similar to Exposé) and a roving searchlight careens into a corner of the screen to illuminate a search field that looks to have appeared out of nowhere (see demo below). Once the user types in his/her search text and results begin to come in, the spotlight pulls back to reveal that the search field is the search field for the search results window. This way, there is a single search field a user has to keep track of, opposed to the two in the current implementation (more on that later). The results window contains a list of search results, and will behave like a window of a common application, meaning that a user will be able to apple-tab to and from Spotlight. The current behavior of Spotlight is that it belongs to no other application and the window can only be brought forward by repeating the spotlight summoning command. For users used to toggling windows by using the apple-tab key combination, it is frustrating that one application cannot be brought forwards like any other application.
With this proposed redesign, familiar interface elements are used to improve search by providing intuitive filtering and context for the exhaustive search results Spotlight delivers.