[Design] Search

[D John Anderson]

On Feb 1, 2007, at 6:50 AM, Mimi Yin wrote:

> 2) We acknowledge there will be some confusion about double meaning  
> of the text field. A drop-down displaying all the command options  
> when the user types '/' is the part of the design intended to  
> address this issue. Are we still planning on implementing that? We  
> would also like to have a tooltip on the text field that says: Type  
> '/' to show commands. (See

As I mentioned in my earlier email I spent about a week trying to  
implement the drop down in the toolbar and I'm currently stuck on a  
crasher bug on Macintosh. So, it's not an issue with not wanting to  
implement the feature, it's simply a matter of being stuck and having  
limited time. So I'm not sure if I will solve the problem for  
Preview. The next step is to come up with a list features/bugs and  
prioritize them for Preview.

>
> Assuming we are, we could be on the lookout for that from users,  
> and discuss other solutions after preview. One possibility is  
> certainly to have either Search or New item creation in a separate  
> 'palettel'. However, we would need to consider how our 'Command  
> line' designs scale with respect to point #3 below.

I think a quick entry palette would scale with other commands as well  
as or better than a single line search box field. Most programmers  
use a shell for typing commands and they benefit from additional  
space over a single line text box.

> 4) As for the sidebar, we discussed this issue on the list over the  
> summer and agreed that coming up with a good design to deal with an  
> adjustable sidebar was beyond the scope of Preview. See discussion  
> here: http://wiki.osafoundation.org/Journal/ 
> WhyTheSidebarIsFixedWidthForNow

I read the link, but didn't understand the details of the design  
you're proposing. The main thing I'm confused about is this passage:

1. An alternate layout for the mini-calendar so that it doesn't float  
in the middle of a sidebar that is much wider than the mini-calendar  
itself.
2. A custom splitter tha won't make the divider between the sidebar  
and the summary pane take up more pixels. (see Apple Mail, iTunes and  
iPhoto as examples).
3. The ability to 'snap back' to the original width.

> Could we adjust the length of the Collection Name instead to make  
> sure the (#) fits?

We could take a name like "Search Results (10)" and shorten it to  
"Search R... (10)", if that's what you are suggesting.

> 5) View selector in the menu. This is certainly a cheap way to add  
> this feature into the UI! I'm wondering if the user is going to  
> understand the fine distinctions between a Dashboard and a Table,  
> especially because there is a collection called Dashboard.  Table  
> and Sectioned Table or Triage Table? might make more sense?  
> However, there's a 'Use sections' menu item in the View menu which  
> confuses things. Perhaps we should get rid of that if we have these  
> View menu options at the top.

I'm happy with calling it a "Sectioned Table" or "Triage Table" and  
getting rid of the Use sections menu Item. I need to double check  
with Bryan Stearns to make sure that turning off sections is the same  
as Table view.

> Also, in switching from table to calendar view, I found it hard to  
> navigate the search results. I think to fully meet this use case of  
> viewing search results on the calendar we would need a split-pane  
> view similar to Apple iCal.

I don't think split panes or even new windows are too difficult to  
implement, but it might have to wait until after Preview.

> 6) After playing around with it, I wonder about the value of the  
> Relevance column. Personally I rarely use it in Apple Mail. Does  
> anybody else use it in their email program? And it takes up quite a  
> lot of space because of the length of the column title. Jeffrey  
> also tried it out and felt that it wasn't quite accurate, Jeffrey?
>
> I think it's a nice idea, but we should iterate on the design a  
> little bit more before putting it into the UI. For example, we  
> should have an 'inverted state' for when an item is selected.  
> However, that's just a cosmetic change. I think we need to think  
> more about cognitive issues. What kind of 'ranking of search  
> results' actually makes sense to people?

Almost all search in the world today sorts results by relevance (e.g.  
Google), so I suspect people will be familiar with the concept. Of  
course that doesn't mean the relevance is very meaningful.

If we don't sort the results by PyLucene relevance, what do we sort  
them by? The obvious options include one of our columns in the table  
or some new column. Which would you choose?

Finally, if it just a matter of relevance taking too much space we  
could easily replace the graph with a number.

>
> Hmm, I now seem to be unable to get the Relevance column or the  
> search result numbers to come up when searching: https:// 
> bugzilla.osafoundation.org/show_bug.cgi?id=7978
>
> I've also logged a couple of bugs:
> 1. Switching collections and app areas in the sidebar should filter  
> down the search results set. bug: https:// 
> bugzilla.osafoundation.org/show_bug.cgi?id=7969
>
> 2. Overlays should grey out in the Calendar app when summary pane  
> is displaying search results: https://bugzilla.osafoundation.org/ 
> show_bug.cgi?id=7971
>
> 3. Traceback popped up when I tried to switch the search results  
> view to Dashboard view: https://bugzilla.osafoundation.org/ 
> show_bug.cgi?id=7972

Thanks for the bug reports

>
> 7) Search workflow clarification:
>
> 1. User enters 'Find mode' in the toolbar text field either by  
> typing '/Find' or Cmd/Ctrl-F or whatever other mechanism we dream up.

This was checked in last night.

>
> 2. User types in a search term and hits ENTER.

Currently we use PyLucene search command syntax, not just a search  
term. It includes a list of terms in the simple case but has a lot  
more features, including boolean search, etc. You might want to  
follow up with Andi on the syntax of a search command.

> 3. View switches to Table view and search results appear FOR THE  
> SELECTED COLLECTION AND APP AREA. Meanwhile, the collections in the  
> sidebar display the # of search results per collection.

> 4. The user can 'navigate around' switching collections and app  
> areas to 'filter' the search results in various ways.
>
> 5. User exist search mode if they a) delete the text in the toolbar  
> text field; OR b) click on the cancel button.
>
> Am I missing anything? I have also updated the bug with these  
> details: https://bugzilla.osafoundation.org/show_bug.cgi?id=7969

Thanks for the clarification. This was not clear from my reading of  
the spec.

Finally, what did you think about letting the user save the search  
results in a collection?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070201/3af951bc/attachment.html