[Design] Search

[D John Anderson]

Hi:

I just checked in a first draft of search for Preview.

Unfortunately, given the schedule for Preview we don't have enough  
time to completely implement the spec, nor do we have our usual  
amount of time to iterate between design and implementation. So,  
we're going to have to make some difficult choices for Preview.

I encourage everyone to try out search and share your feedback. Even  
if we can't incorporate all the feedback for Preview, we can improve  
search after Preview.

I'll start by giving you my first impression of search as a user of  
Chandler.

The first time I typed something into the search field and pressed  
enter, it seemed completely broken. Instead of returning my search  
results it created a new item. I thought this was a bug, but later I  
discovered that it was a feature. You have to type "/search" in front  
of your search string. This seems to violate one of the most basic  
rules of UI design: Never take a familiar widget and make it do  
something unfamiliar.

By putting the quick entry functionality into the search box I think  
we're making the same mistake we made with the sidebar icons: trying  
to put too much UI into too few widgets. As a user, I'd prefer having  
search work like search does in other applications and put the quick  
entry functionality in a new widget, e.g. a floating palette that  
comes up when you type somewhere besides a text box (or choose a menu  
to bring it up). A palette could use the extra space to make it clear  
that you type commands in the quick entry widget, it could show  
command history, be resizable and not clutter the existing window,.  
Other options include: putting quick entry in the status bar at the  
bottom of the window, putting it where search is but making it not  
look like search and putting find in a find panel.

I also think putting find functionality in a quick entry command  
seems to violate another basic rule of UI design: Don't hide  
important commands from your user. Nobody's going to figure out that  
you need to type "/search" to do a search. Even with command type  
ahead, nobody is going to discover it. As an aside, I spent over a  
week trying to implement Darshana's command type ahead in the  
toolbar, and got really close, but still have a difficult bug holding  
it up on Mac. I'm not sure I'll succeed in finishing it for Preview.

At the very least I think we should make the Quick Entry box not look  
like a search box, but I still don't know how hard that will be to do.

Other nice to have, but not currently implemented features include:

- Search results don't update as you type each character in the  
QuickEntry field. You must type return to start the search
- Performance is too slow. It has a jerky feel and occasionally spins  
the watch on a list of 3000 items.
- I'm using Darshana's Quick Entry code. It displays errors by adding  
a ? to the text instead of displaying the error underneath the search  
field. Also, when you type a search string that PyLucene interprets  
as containing a syntax error you get an error dialog written for a  
programmer not an end user.

Here's the main features in the spec which are still not implemented:

- I have not yet implemented the "as you start typing anywhere your  
focus switches to the QuickEntry field"
- When no items are found we don't display text on the summary view  
explaining that there were no items found.
- The Quick Entry field doesn't display command alternatives as you  
type.

Finally I'll summarize with some more minor things I noticed after  
using search for a longer time:

The spec didn't address how to sort the results. Since PyLucene  
returns the results in relevance order, I tried adding a new rank  
column in the search results like Apple Mail.

I kept wishing I could search for something then change the view to  
see the results in Calendar view. To get an idea for how this might  
work I checked in a simple proposal: replace the first 4 menu items  
in the view menu (which currently do the same thing as the first 4  
toolbar buttons), with 3 new commands that change the view to  
Calendar, Dashboard and Table. It's also easy to add more view types  
with new parcels.

After I cleared the search results I occasionally wished I could go  
back to my search results. I played a few simple idea which you can  
try out: when you click the delete box in the search field and there  
is no search string it goes back to the search results. Another idea  
I tried was allowing the results to be saved in a collection. To get  
a feel for how this might work I added a save button (currently with  
a place holder icon) next to the quick entry box that's only shown  
when search results are displayed. Choosing it copies the search  
results to a new collection in the sidebar. Instead of adding a  
toolbar button, it's also easy to optionally add a menu item when  
search results are available to save.

It's not unusual for the number of matches displayed in the sidebar  
to get cut off because the sidebar isn't resizable. I wonder if it  
might not be worth allowing the sidebar to be resizable and scaling  
or tiling the mini calendar to fill the space

I have a hard to coming up with words to describe how ugly the  
wxWidget's search widget looks like on windows (and I still haven't  
seen it on Linux).

So give search a try. Let me know if you find any bugs, and we'll  
work with Design to get the best search we can for Preview and a  
clear set of tasks for after Preview.

John