View Issue Details

IDProjectCategoryView StatusLast Update
0016067MediaMonkey 5Playlists (Auto) / Search / Filterspublic2019-11-12 15:41
Reporterrusty Assigned To 
Status feedbackResolutionreopened 
Product Version5.0 
Target Version5.1Fixed in Version5.0 
Summary0016067: Clarify Search Terminology and UI
DescriptionAs suggested at (item 2), the terminology/descriptions/UI differentiating between Global/Contextual search can be improved upon.

1) Tools > Options > Library > Search
Contextual search (typing in a view):
Search current view:
Typing to find items in a view: Filters matches / Scrolls to matches

Full text search (search bar):
Global search

2) Search bar tooltip:
Search (Ctrl+F) --> Global search (CTRL+F)

Note: can be a bit confusing, because the context menu also allows for other searches, but since this is the default...

3) Search context menu
a) Terminology isn't consistent / can be improved:
Contextual search (typing in a view) --> Search current view

Search whole library (CTRL-F) [this is different than the Options menu which shows 'Full text search'
--> Global search (CTRL+F)

Advanced Search --> Advanced search

b) Currently, the user can right-click on Search and choose via a radio button. e.g.
(o) Search current view
( ) Global search (CTRL-F)
( ) Advanced search

This ui implies to the user that they are selecting the mode that will be used by the search bar (contextual search in the above example) and yet when the user types in the Search bar, a Global search is initiated. All the radio button does is initiate a search of the type chosen. A simple fix would be to:
i) remove the SEARCH MODE header (since 'mode' implies a persistent change)
ii) remove the radio buttons; that way the UI implies that a search of the type chosen will be initiated (or switched to using the current search term).

c) For consistency with 3a) if the user initiates a contextual search, the context menu should show SEARCH CURRENT VIEW (instead of CONTEXTUAL SEARCH). I would, however, suggest that it be displayed _below_ the 3 search actions (in the Options... section of the context menu).

4) As previously discussed at 0012371:0054159 and raised by Barry at the link above, there's no real difference between 'Advanced' and 'Filter icon' in Global Search. Would it make sense to get rid of the icon in this view (since it's already accessible via the 'Advanced' link)?
TagsNo tags attached.
Fixed in build2212


related to 0012371 closedLudek Search bar functionality 
related to 0015077 closedLudek Improve incremental search 



2019-10-29 18:53

developer   ~0055136

Fixed in 2210


2019-11-05 15:31

administrator   ~0055205

Last edited: 2019-11-11 23:50

View 3 revisions

Tested 2210--looks good. Just a couple of minor issues remain:

1a) Note the change in phrasing (it wasn't explicitly highlighted above). Also, I've changed the capitalization:
Filter matches --> filters matches
Scroll to match --> scrolls to match

3a) Global Search (undefined) --> Global Search (CTRL+F)

b) Even though the radio buttons have been eliminated, the UI still implies that a persistent mode is being set e.g.
1 Right-click on the Search icon and choose 'Search current view'
--> contextual search window opens
2 Close the contextual search window
3 Right click on the Search icon
--> 'Search current view' is highlighted in yellow!

ii) In relation to the above, I'm not even sure that there's a need to indicate that a mode is being set (it's confusing to imply that a mode is being set, because it's not a mode--just the current context which is shown in the breadcrumbs bar). I suppose that we implemented this so that the combobox next to the searchboxes can indicate what type of search is being implemented and allow the user to switch to a different type of search. But is this really necessary? i.e. the combo box for contextual search doesn't really need to allow the user to switch to Global or Advanced search--it can just have:
(o) Filter matches
( ) Scroll to selection

And if the user wants to switch to a Global/Advanced search, they can just initiate it as they normally would via the Global Search button.
d) Similar to c) the 'v' that appears next to the search bar doesn't make sense. i.e.
1 click Global Search
--> Search bar appears with 'v' that appears to allow the user to choose a search mode for the bar, though in actual fact, it changes the command.


2019-11-05 18:33

developer   ~0055215

Last edited: 2019-11-05 19:14

View 9 revisions

1a) Are you sure that you want to introduce different terminology in Options > Search and in the dropdown?
i.e. "scrolls to match" in Options versus "Scroll to selection" in the dropdown??
I think that the terminology should be same (also for the translators etc)

3a) I cannot replicate, but most probably fixed in 2211

Re the presentation of the selected mode in the dropdown. Yes, we introduced it to make the things about the searching more clearer, mainly the distinction between contextual search and global search mode and how to switch between them.
It was originally implemeted as item G) in 0015077 and was rather Barry's proposal/idea (I was not keen of adding it), see the discussion here:

So if I understand correctly you are suggesting:
- removing the dropdown arrow next to the search bar entirelly in the global search mode
- remove the magnifying glass right-click menu entirely (as it is not expected and hard to discover by users anyway)
- leave the dropdown arrow next to the search bar only in the contextual search mode with the options to switch from "scroll" to "filter"

For me it would make things cleaner, but probably not clearer. Users like Barry will probably objecting that they cannot realize how to switch to global search, in which mode they are etc.

EDIT: Before the conclusion please read this discussion (which leaded to the item G) in 0015077)


2019-11-05 19:18

developer   ~0055216

Thinking about it further I think that we should rather revert the text to 'Search current view (typing in a view)' and use it also in the dropdown like this:

This way it will be clear how to swtich between the modes (i.e. Ctrl+F versus typing in a view)
search.png (40,807 bytes)   
search.png (40,807 bytes)   


2019-11-12 01:38

administrator   ~0055319

Last edited: 2019-11-12 15:41

View 2 revisions

Bug 16067 (comment)

1a) Currently the menu&dropdown show 'Scroll to match' and the 'Filter matches'. I wasn't trying to suggest using new phrases (though I see at 3bii I accidentally changed the phrase). I was just suggesting adding an 's' to both of them since 'Typing to find items in a view:' isn't gramatically correct with the existing phrases. But, I agree with you that it's better to be able to use the same (existing) phrase in both locations, so we can change 'Typing to find items in a view:' --> 'When typing in a view:'

3a) Verified in 2211

3b) Or item G) at 0015077
My point is that the UI that highlight the search mode are mainly to differentiate between the types of searches since it's relatively obvious how to switch from one to another via the search button (note: 'relatively' because the 'v' only appears after the user clicks the Magnifying glass). But with the current UI, these highlights are not really needed since:
- If the user initiates a contextual search by clicking Search>Search current view, then it's self-evident what they've initiated and self-evident how to initiate other searches.
- If the user initiates a contextual search by typing, then clicking the dropdown will show:
(o) Filter matches
( ) Scroll to match

So, again in this case, it's also clear what type of search has been initiated.

So to clarify, my suggestions were only to:
- Remove the 'highlights' that appear in the Global Search dropdown (the dropdown is still required to choose an alternate search type & configure search options)
- Remove the option to choose search type from the Contextual Search dropdown (the dropdown is still required to choose the contextual search mode & set options)
The main issue that this resolves is the impression that the UI currently gives that a persistent setting is being set. However, this is a relatively minor point and it still doesn't resolve the more significant issues that have been raised, so I'd leave it as is.

Same goes re. the text change that you suggested 'Search current view (typing in a view)'. It's not necessary because once the user clicks that, the search bar opens and the user types--so it doesn't really clarify anything.

As far as the major remaining usability issues, I'm referring to:
i) the use of 2 different search bars on the top row is confusing
ii) users can't see or choose search types via the mouse until after initiating search & multiple clicks are required to do so
iii) switching between search types is confusing since it involves switching locations (i.e. Global --> Contextual --> Global)
iv) users can't search the current Collection (i.e. expanding the search domain always always switches out of the current Collection)

We've previously discussed and rejected the following approaches to dealing with aspects of the above:
A) MM4 approach of single search bar with mode selection: iirc, the issues are that:
 - duplicate search terms appearing in the Search box and breadcrumb bar is ugly (though we already take this approach for Global Search)
 - it's confusing to not have an obvious visual distinction between Global and Contextual search (either prior to or after searching)
 - persistent search mode selector can be annoying (it requires too many button presses to switch between search modes)
B) Search bar with buttons to switch between modes: discussed at 0015077:0052972 Item f. Main issue was:
 - Search bar takes a lot of room
 - Switching between contexts (entire library vs current view) for an existing search is confusing

Here's another idea that might resolve all issues:
4)a) Typing: Initiates contextual search (in the breadcrumb bar--as today)
b) CTRL-F: Initiates global search. But the mechanism is slightly different: the Search bar opens in the breadcrumbs bar, but the breadcrumb shows:
Home > [Magnifying glass] > _search bar_v (Note: the view would not update until the user starts typing)
c) In both of the above cases, the Search being performed is the same operation--the only difference is on which node it's being performed on. In addition, Searches would persist until either the user presses ESC, OR Types a different search term in the box, OR Closes the search (e.g. by pressing a CLOSE button on the Search (similar to how Filters can be closed--and possibly additionally by clicking the currently active node)). The reason and ramification of this is that it solves problems related to switching contexts--if the user wants to expand the search to to include the Entire Library, they can just click 'Home'; if the user wants to contract the search to only include the current collection, they can click 'Music'. [Note: this would require that Global Search results also include Collections in the Search results].
This seems like a clean solution--the only question is whether users will find it annoying to have to 'close' searches to cancel out of them. I don't expect that it'll be an issue though, since users already have to exit search results (e.g. by clicking CLOSE or by clicking a higher level node).
d) Re. Use of the mouse to initiate searches:
. i) Move the magnifying glass to the leftmost icon position (i.e. to the left of the filter icon). This would probably mean that all icons would be positioned on the right without the space that currently exists e.g. [Search]v [Filter] [View switcher]v [Panel toggle]
. ii) Clicking the [search]'v' button would present _all_ search options (allowing the user to set a persistent search mode as in the past). It would add a 'Search current Collection' option as well.
. iii) Clicking the [Search] button would open the searchbox in the persistent mode chosen by the user
Note: in this scheme, there's no need to support switching between contexts using the search mode (i.e. the only contextual entries for the Search _Bar_ are related to 'Filter matches', 'Scroll to match' & Options.

Lastly: Although this may very well work, I expect that it's will require tweaking once we start implementing it, so it's probably not something we should tackle for 5.0, and we should just leave it as is for now.

p.s. this is fairly similar to Barry's suggestions at


2019-11-12 13:50

developer   ~0055324

Last edited: 2019-11-12 13:53

View 2 revisions

1a) is fixed in 2212

4b) While I agree that this can eliminate some confusion (e.g. the two positions for the search bar) it can bring another. e.g. The breadcrumb bar out of context when Ctrl+F is pressed and user does not start typing yet

4c) As for the new feature re persisting searches while navigating outside of current node/view (to be more like funnel filtering). I see that it may be useful, but I am afraid that it adds further confusion, especially when contextual search is set to "Scrolls to match" -- which needs to be temporarily overridden until user escapes the search context by pressing ESC or clicking the close button in the search bar? This adds further confusion and is rather something to evaluate for a future version.

4di) As for the moving the magnifying glass icon to the leftmost icon position. I am not sure that it is right direction, the suggested place is already occupied by many context related buttons. Having it on the right is also more consistent with most of other apps, but this is rather minor issue.

4dii) Introducing the "Current collection" search mode like in MM4 and the persistent modes. I think that it does not solve the confusion about persistence of the search modes -- as in the suggested scenario the modes are persistent only when the search is initiated by clicking the magnifying glass, right? Or are you suggesting that the mode should be persistent also when pressing Ctrl+F ? Generally I think that eliminating the persistent modes was a good step forward against MM4. Note that in MM5 user can still search current collection by using the contextual search while the collection root node is chosen (while I agree this might be hard to realize). It could be rather resolved by adding Collection: [Entire Library^] dropdown directly to the search results view ?

Anyhow I agree that most of the new suggestions are rather 5.1 items.


2019-11-12 15:40

administrator   ~0055326

4b) Agreed, but the breadcrumb bar being temporarily out of context is probably a minor point in comparison to the current situation.

4c) Would 'Scroll to' search behave any differently than currently? i.e. just as today, the user could exit the search by ESC/Closing it, or clicking one level up in the breadcrumb bar.

4dii) I meant that persistence is only configured for the search button (i.e. Typing vs CTRL-F always always trigger contextual vs global searches). BUT, the only reason I suggested this is to solve the current issue that: search modes aren't initially visible and that 3 clicks are required to initiate a non-global search with the mouse, and that if we try to solve this by having MM display a dropdown next to the Search icon , it would have to be for configuration purposes (in which case the setting would be persistent). BUT, I think that this issue is orthogonal to everything else that was suggested, so it could be implemented (or not) independently.