[Design] Search

[Sheila Mooney]

John,

Thanks for writing this up. I am going to download the latest build  
and try it out - then I can respond to the email in more detail.

In the meantime, I just wanted to let you know that Reid just checked  
in some changes to make the Quick Entry box look less like a search  
box (since you mentioned this specifically) https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=7648.

Cheers,
Sheila

On Jan 30, 2007, at 12:00 PM, D John Anderson wrote:

> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design