[Design] Search

[D John Anderson]

On Jan 31, 2007, at 2:17 PM, Dan Steinicke wrote:

> I've tried the new search (and filed a few bugs).

Thanks for the bug reports

> I agree that there is a lot of room for improvement on how to make  
> the search and quick entry intuitive and easily discoverable by the  
> casual user, but I think I can live with something close to the  
> current implementation for preview.
>
> My other comment is that I didn't immediately clue into the  
> necessity of clicking the [X] in the search field to switch back to  
> a normal view.  I first tried clicking on other collections and  
> appbar view buttons and was a little surprised and distressed when  
> nothing seemed to happen.   Maybe we should make the search results  
> go away when these types to things are clicked on?

Maybe if we changed the [X] icon to be a search icon when clicking it  
goes back to the search results it might help.

I agree that it feels weird that when search results are displayed,  
clicking on the collections in the sidebar doesn't do anything. I  
think switching out of search mode in this case is worth trying to  
see how it feels.

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