Saved searches: opinions wanted

[chaley]

Implementation of saved searches is well underway, and given that I am close to useless at user interface design, it is time to ask for some feedback.

In an earlier thread, I heard that:
1. The name of the saved search should appear in the search box, not the value (the search itself).
2. There should be a way to select and create saved searches near the search box, without being required to open the tag browser.
3. Tooltips should be used to show the value of a saved search.
4. The tag browser should be used (as well) to select saved searches.

The current (unreleased) implementation includes a try at items 1 - 3, along with a way to delete saved searches. The linked screen shots show what it looks like. I didn't embed the screen shots because doing so made the post almost impossible to read.

1. Just after calibre starts. This is what you see when the application starts. There is a new combo box and two new buttons on the right side of the search box. (attachment 1-after_opening.jpg)

2. After typing in a search. The search box contains the search (duh!). The saved search box is still empty. (attachment 2-After a search.jpg)

3. Named the search. I typed "honor" into the combo box and pressed the save button. Note that the text in the search box changed from the search itself to the name of the search. Note also the tooltip showing the search text. (attachment 3-Named a search.jpg)

4. Here is a shot with the combo box open, showing the available searches. There is no easy way (that I know of) for the tooltip to show each search. (attachment 4-Search selection open.jpg)

5. I selected a different search (hammer). This screen looks much like 3. (attachment 5-A different search.jpg)


Any suggestions? Be kind.

[itimpi]

That looks good.

One question - can you embed searches so I perhaps could create a new search that said something like
"search:search1 xxx yyy"
and then make this into a new search? If this was allowed I would expect that if search1 was changed then this would also affect every search that had this one embedded.

[Starson17]

Originally Posted by chaley

Implementation of saved searches is well underway, and given that I am close to useless at user interface design, it is time to ask for some feedback.....Any suggestions? Be kind.

Having just gone trough this with merge code, I'd suggest you do what makes sense to you, what fits well with existing code and what matches, as best you can, the existing interface.

I didn't implement a lot of suggestions, but they really helped me think about what would work and what I needed.

I heard that:
1. The name of the saved search should appear in the search box, not the value (the search itself).

I may have been in the minority, but I'd prefer the search, not a name, so 1)I can edit it, 2) I don't have to remember what it does, and 3) I don't have to think up a name.

How about this: Make the the default name the search. The "search:" leader in the bar would match the name of the search in the quotes after that leader, but if match fails, it would treat the contents as a search as if the leader and surrounding quotes were not there. Then if I search:

author:bob and cover:false

that is the default name and if later selected I'd see:

search:"author:bob and cover:false"

on the bar. I could edit it to anything I want. Editing it would cause a match failure in the saved search lookup, but the code could then treat it as though the search: and surrounding quotes were not there. Maybe it removes them automatically on match failure.

2. There should be a way to select and create saved searches near the search box, without being required to open the tag browser.

I wanted this. It looks good so far - although you might consider putting the saved searches below the search bar instead of to the side if you need more length.

It looks great so far. Thanks for tackling this.

[chaley]

Originally Posted by itimpi

One question - can you embed searches so I perhaps could create a new search that said something like
"search:search1 xxx yyy"
and then make this into a new search?

Yes. 'search:xxx' is a term like 'tag:xxx' etc. They can be parenthesized, 'not' ed, and combined together. For example assume that I have a named search 'MyFavoriteGenres' that searches for a set of tags. The following expression would find books I have read in genres other than the favorites:

tag:=read and not search:MyFavoriteGenres

If this was allowed I would expect that if search1 was changed then this would also affect every search that had this one embedded.

Yes, if you change the contents of a named search, all searches that use it will change.

I haven't yet implemented the ability to change the name of a search. When I do, I will (almost certainly) implement the suggestion that changing the name of a search should also (optionally) change all searches that used the old name.

[chaley]

Originally Posted by Starson17

I may have been in the minority, but I'd prefer the search, not a name, so 1)I can edit it, 2) I don't have to remember what it does, and 3) I don't have to think up a name.

How about this: Make the the default name the search. The "search:" leader in the bar would match the name of the search in the quotes after that leader, but if match fails, it would treat the contents as a search as if the leader and surrounding quotes were not there.

Counter proposal:
1. If the save search button is pressed when the combo box is displaying nothing (blanks), then the search is used as the name (as you suggested).
2. Another button is added that would copy the search associated with the currently selected name to the search box. You could them edit to your heart's content.

The first deals with (your) #2 and #3. The second lets you easily get the search string to edit it, and (should you wish) after editing you could push the save button to copy the changed search into the original name.

If the above are done (and in particular the second), I begin to wonder whether I need to build a more general-purpose editor dialog. Everything one would want to do with the dialog could be done directly from the search line. This would simplify the tag browser implementation (I think).

[Starson17]

Originally Posted by chaley

Counter proposal:

It sounds great and intuitive.

[Starson17]

Originally Posted by chaley

I begin to wonder whether I need to build a more general-purpose editor dialog. Everything one would want to do with the dialog could be done directly from the search line. This would simplify the tag browser implementation (I think).

On the tag browser issue, I'd be satisfied if only the non-default named searches appeared there. Those are in the small class of searches that I truly expect to go back to many times. I might hunt them up in the tag browser.

The other class - default named, are probably the searches that I'm currently using, but I may not use tomorrow when I'm doing something different.

[rchiav]

I think saved searches will be a good addition to the application, but I did have a suggestion on the UI for them. Would it make more sense to store them in a pulldown menu type format with flyouts so people could organize them instead of just as a list box? Another thought might be to put an icon for that in the white space above the search bar. It seems like there should be more there, but as far as I can tell, there's nothing that happens there.

[itimpi]

Originally Posted by rchiav

Another thought might be to put an icon for that in the white space above the search bar. It seems like there should be more there, but as far as I can tell, there's nothing that happens there.

Kovid has already that is not available for that purpose. At the moment it normally starts with a single icon there representing your Calibre library on disk and adds additional ones for any plugged in reader and associated cards. If I plug in my Sony Reader with two plugin cards then 4 icons appear there.

It is also intended that if/when multiple library support is added that are will be used for that purpose.

[Starson17]

Originally Posted by rchiav

Another thought might be to put an icon for that in the white space above the search bar. It seems like there should be more there, but as far as I can tell, there's nothing that happens there.

Read the linked thread that chaley references. Kovid says there is a planned use for that space - additional libraries

[kovidgoyal]

Although this might be slightly tricky to implement, I'd suggest having default text in the save search combobox "Save search" just as there is in the search box, as otherwise it's not clear what the combobox is for.

[Starson17]

Originally Posted by chaley

1. If the save search button is pressed when the combo box is displaying nothing (blanks), then the search is used as the name (as you suggested).

You might consider:

1) as Kovid suggested - "Save search" as default text, but the code rejects that as the actual name. (Note how this works in the Search bar with text that says: "Search ...")

2) I can type over "Save search" to put in my desired name, then press the save button to save it.

3) If the save button is pressed with "Save search" displayed, it copies the search text in, but does nothing.

4) Now I have two options. I can just press the save button again to use the default search as the name, or I can edit the search text in the Save search box, not to change the search itself, but to change its name. Then I press save to save the search under its edited name. Often I will have typed into the search the same text I want to use as part of the name, so this lets me reuse that typed text.

[chaley]

@Kovid: I borrowed (and hacked up) SearchBox2 in SearchBox.py, making something equivalent for saved searches. An empty box now displays 'Saved Searches' in grey. When the focus enters the box, it is cleared. When the focus leaves the box, it is reset to help text if the box is empty. Note also that the tooltip follows this text. When 'Saved Searches' is displayed, a general tooltip is provided. When a saved search name is displayed, a tooltip showing the saved search text is provided.

The attachment 6-With copy button.jpg shows what the screen looks like now.

@Starson17:
1. If you press the save search button while the help text is displayed, the box is treated as if it were empty. This preserves the 'save search name == save search value' function.
2. If you select a search, push the copy search button, edit the search, then push save, the new search will be copied over the previous name. The right thing happens if you change the name (the search is saved under the new name). The right thing happens if you clear the name: the search is saved as in #1 above.
3. I didn't implement your third suggestion, because (I think) #1 makes it redundant.

During testing, I discovered that I implemented recursive searches. At the moment, it just takes a while and then stops. I think that I will add a test for this, because there is no case where recursion is useful.

Now to the tags browser part.

[Starson17]

Originally Posted by chaley

@Starson17:

Sounds good to me. Sometimes the right answer appears obvious when you're in the middle of coding.

[kovidgoyal]

Looks good to me. When you're ready submit the patch and I'll merge it as soon as I can find the time to review.