GNOME Bugzilla – Bug 131544
Have history in search box
Last modified: 2018-05-24 10:28:33 UTC
Hi Watching my friends use Rhythmbox on my computer, I noticed that the current search interface can be confusing in 2 common scenarii: 1st one: - You are looking for a song using the browser. - You set the artist/album but can't find the song in the (filtered) list - You then try using the search dialog In this scenario, the search will fail because the user forgot to reset the filters to all artists/all albums. I saw that happening a lot (always actually) when other people used rhythmbox. My proposition would be to automatically reset the artist/album filters when you perform a new search. But I guess some people wouldn't like it... So another solution would be to have the following UI: Search [ ] among |songs from [name of the artist]| |songs from [name of the album] | |all songs | 2nd one: - You are looking for a song named "Penny Lane" using the search field - You found your song and play it - You then click on an artist in the artist list (for example "Madonna") In this scenario, nothing appears in the song list because the user forgot to reset the search (by selecting "Penny Lane" and pressing DEL). And as Madonna never sang Penny Lane (AFAIK), nothing appears. My proposition would be simply blank the search field when changing the artist or the album filter. What do you think of those propositions ?
I think this is an important issue too. Peronally, I would love to just see "Search" button that must actively be pressed to start a search. Searches always default to global, unless "search within current results" box is checked, or something similar. Another suggestion I have for search is to make it much more lenient. If I have a file artist tagged "james p johnson" and I search "james johnson" then nothing shows up. Maybe separate words could be OR'ed together instead of treating them as a string? I don't know how yammi does its "fuzzy search" but something like that would be ideal.
Additionally, Debian user Nicolas Évrard wishes that rhythmbox borrowed more ideas from "madman", see <http://madman.sourceforge.net/tour2.php>. This is Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267341
*** Bug 135803 has been marked as a duplicate of this bug. ***
*** Bug 135802 has been marked as a duplicate of this bug. ***
I would like to second this request. I myself often enter a search term to create a playlist and then happily play those songs. then i come back and select an artist/album from the list and wonder why nothing comes up. It's happened enough times now that I know what the cause is, but it's still annoying. I never think to clear the search term first (because it's usualy ages since i set it). I note that the itunes behaviour is to automaticaly clear the search when an album/artist/genre is selected from the list. It has never felt unintuitive to use.
Created attachment 45993 [details] [review] Patch to use always global search The way this patch works: - Changing the search entry text (focus is not enough) resets all category filters to "All blah blah". - Selecting any of the three categories clears the search text internally, in effect disabling it. It does not clear the entry and to activate the search again you must edit the text. The patch can be dropped straight to debian/patches for automatic patching purposes. Incidentally, s prebuilt deb for Ubuntu/hoary (i386) is available: http://iki.fi/zuh/rhythmbox_0.8.8-7ubuntu5_i386.deb (please don't complain that the version is not bumped :) I might be willing to make this a command-line option, if the rb team would accept the patch...but the search re-activation needs some more thought (maybe focusing should activate the search again after all...).
Thanks Kalle for that patch. The .deb works as advertised. However, I'm not convinced by this: - Selecting any of the three categories clears the search text internally, in effect disabling it. It does not clear the entry and to activate the search again you must edit the text. I find it very confusing, especially because there is no way to re-search the same string without modifying it, and re-typing it. For example, if you searched for "beatles", you get the search results for "beatles" in all the categories. Then, if you select a category, you get everything in this category. So far so good. Now, if you want to search "Beatles" again, you have to modify the search string, and enter "Beatles" again... I guess it's not really obvious. More over, if you go to the search entry and empties it, it will reset the category selection for no obvious reason (because from the user point of view, emptying the search entry means "cancel search", not "search for ''"). You propose: "maybe focusing should activate the search again after all...". But I don't think it's a great idea either, because just focusing the search entry could surprisingly change the list of songs, which wouldn't be expected by users. I really think that, if the search entry isn't used when displaying the tracks list, it should be resetted in the UI, so that users understand what happened. And maybe pressing the down arroow in the search entry should bring back the latest search string.
Julien Olivier: > > - Selecting any of the three categories clears the search text internally, in > > effect disabling it. It does not clear the entry and to activate the search > > again you must edit the text. > I find it very confusing, especially because there is no way to re-search the > same string without modifying it, and re-typing it. The main motivation for not clearing the text is that there is no obious way to get a reference to that entry ;) but yeah, it probably should be cleared (or at least dimmed to indicate that the search is not active). Note that you only need to modify it, not retype it ('beatle' will find the same files and possibly more as 'beatles') > More over, if you go to the search entry and empties it, it will reset the > category selection for no obvious reason (because from the user point of view, > emptying the search entry means "cancel search", not "search for ''"). "Cancel search" implies "clear categories" in my mind, especially since "do search" means it too. And besides, why would the user clear it if not making a new search? > You propose: "maybe focusing should activate the search again after all...". > But I don't think it's a great idea either, because just focusing the search > entry could surprisingly change the list of songs, which wouldn't be expected > by users. That's why I said it needed some more thinking through. :) Oh, and don't bother trying that .deb on Ubuntu/breezy, hearsay says that it doesn't work.
Imo the search entry should be cleared when the search is reset, it seems you agree too except that you didn't find an obvious way of doing it ;)
I said it need thinking, the fact that there is no obvious way just stopped me from doing it at 2am, not for good ;)
Just a few anwsers to Kalle's comments: > And besides, why would the user clear it if not making a new search? The main reason might be that, browsing a category, the user didn't find anything useful (because she doesn't _have_ the files she's looking for), and she notices the search entry, thinks it's filtering her results, and tries to cancel it, just to be sure the search didn't hide the files she was looking for. And consequently, she'll fall back to browsing all the categories... I agree that it's a bit far-fetched, but that happened to me when trying your modified version. So it _might_ happen. > Oh, and don't bother trying that .deb on Ubuntu/breezy, hearsay says that it doesn't work. Well, I did try it on Ubuntu/breezy, and it worked flawlessly. What exactly is supposed to be broken ?
> I agree that it's a bit far-fetched, but that happened to me when trying your > modified version. So it _might_ happen. I had a heated discussion about this, but suffice to say that what you described sounds like a habit developed with the current standard behaviour ]:-) Also, I did admit that the patch is broken as it does not indicate the search status (active/inactive) but I still refuse to accept that the smart way to fix it is to clear the entry. There are other possibilites like visual indication or a decent history for the search field (in which case the entry could be cleared, as the search term is not lost).
So I got inspired to finish this patch and here is the result: - I implemented a search history with entry completion for the search field - The search history is per-session (cleared on startup) - A new history item gets added when the filtering changes (ie. you click on the browser categories)
So I got inspired to finish this patch and here is the result: - I implemented a search history with entry completion for the search field - The search history is per-session (cleared on startup) - A new history item gets added when the filtering changes (ie. you click on the browser categories). This is to avoid overcrowding the completion, if added when a search is done, it would add an entry every time you think 0.3s the next letter to type. Not good. - The search field is cleared when the search is "moved" to history (ie. when you change the filtering by clicking the browser categories) So please test and complain further ;)
Created attachment 47988 [details] [review] A new patch that clears the entry and implements history And sorry for the spam, tab-space in the wrong place
Using this patch means that the user cannot use both the browsers and the search box at the same time. I'm not sure whether anyone else uses this, but I use it a bit when I have filtered on genre and want to find a particular song. Also there is no size limit on the history, and as it's stored across session (in gconf) it could grow endlessly - it probably needs to have some (arbitrary) limit.
(In reply to comment #16) > Using this patch means that the user cannot use both the browsers and the search > box at the same time. I'm not sure whether anyone else uses this, but I use it a > bit when I have filtered on genre and want to find a particular song. I use that feature considerably, so I wouldn't want to add that part. But couldn't we commit the section to remember searches and clear the current text in that box? > Also there is no size limit on the history, and as it's stored across session > (in gconf) it could grow endlessly - it probably needs to have some (arbitrary) > limit. Yes indeed.
The search box now filters the browsers, so the bit clearing it probably isn't useful any more. Having history for the search box would be useful. Retitline bug to reflect that part.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/25.