View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015077 | MMW 5 | Main Panel | public | 2018-09-05 09:39 | 2019-12-09 22:55 |
| Reporter | Ludek | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015077: Improve incremental search | ||||
| Description | Currently when 'incrementalSearch.mmip' is installed then user can use incremental searching on various components (tree, view) like in MM4, there are some issues though: a) When user focuses a list-view then it always scrolls to the first file/track starting with the search phrase within title of the track. In MM4 when user sorts the file list by artist then it scrolls to the place where tracks from this artist are. Someone can call this "power scroll". b) Incremental search within media tree nodes is slow and can freeze UI (espacially when there is a lot of media tree nodes -- like in case of showAllNodes.mmip script installed) c) we should consider to make the incremental search feature to be the default (or at least there should be an option for this without a need to install the incrementalSearch.mmip script) ? | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=90949&p=449187#p449182 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2180 | ||||
| related to | 0014381 | closed | Ludek | AddOn to mimic MM4 incremental search |
| related to | 0015182 | closed | Ludek | Contextual search should apply to the NP Window |
| related to | 0015185 | closed | Ludek | Scroll to match doesn't find all matches (and improvements) |
| related to | 0015559 | closed | Ludek | Default tracklist columns sort and visibility is problematic |
| related to | 0016067 | closed | Ludek | Clarify Search Terminology and UI |
|
|
c) I prefer the current implementation to be the default one. But yes, it seems to make more sense to make it an option in MM UI, not just a script. Something like: 'Typing letters results in: [Filtering, Incremental Search] [v]' |
|
|
a&b are fixed in 2121 |
|
|
re. c) You can modify Options > Library > Search, as follows: Contextual search (typing in a view): _filter matches/scroll to matches_ Full text search (search bar): [ ] Search whole words only Search mode: ....... Search the following fields: ... |
|
|
Implemented in build 2121 and incrementalSearch script removed. |
|
|
re C) while this works, it can be still unclear for the novice users how to switch from "filter matches" to "scroll to matches". Discussed with users at: http://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93547&p=454860#p454860 There was a suggestion that clicking into the view (focusing) should always perform "scroll to matches" and having a node selected in media tree should perform "filter matches" I guess this won't work: - when media tree is hidden and user navigates just using view (e.g. touch mode) - when "showAllNodes" addon is installed and "scroll to matches" is performed also on media tree (so that user can scroll into a concrete artist when Music > Artist node is expanded) So maybe we could just add a menu button next to the search bar with a link to Options > Search and/or radio buttons for "scroll to matches" and "filter matches" ? |
|
|
Further complaints: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93956 https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93945 Another solution is to show toast message like: "MediaMonkey 4.x Incremental Search was replaced by Live Filtering in MediaMonkey 5.0. You can change this behavior in Options. [Change] (x)" And clicking the close button would cause that this message won't show again. Implemented in 2165 and left assigned to Rusty for feedback / wording revision. |
|
|
Tested 2165 and: D) Powerscroll toast problems (these three issues can be ignored if we implement F I). i) Sometimes if powerscroll is enabled, the message about MM4 search appears!? (it shouldn't appear if the user has already re-enabled powerscroll) ii) The toast message always obscures the newly found track when the track is found below the list of currently displayed tracks. The default location should be a bit higher. iii) The text of the message should match the terminology used in the Options. i.e. "MediaMonkey 4.x Incremental Search was replaced by Live Filtering in MediaMonkey 5.0. You can change this behavior in Options. [Change] (x)" --> "Tip: search behavior can be changed to 'Scroll to match' in Options. [Change] (x) E) Powerscroll search problem: i) In many circumstances (e.g. if the user has initiated a filter) / new views (e.g. Home or in any browser view) no 'section' is selected. Thus when the user initiates a powerscroll search, nothing happens! e.g. if the user navigates to Genre:Rock where Artists/Albums/Tracks are displayed, then using powerscroll has no effect until the user firsts selects either an Artist/Album/Track). MM should ensure that an entry within a view is always selected so that powerscroll search can proceed. F) Contextual search: powerscroll doesn't yield useful/expected results in some nodes. e.g. i) Any node for an attribute that isn't searchable (assuming the default sort order): Home, Rating ii) In any node when the sort order is by an attribute other than which the the user is searching (unlike in MM4, it's not obvious to all users that sorting determines the search field) For such cases, allowing the user to trivially switch between contextual search modes would be useful. I'm not keen on adding more buttons to the toolbar, so other possible implementations might be: I) Using an approach similar to firefox i.e. CTRL-F/Search Button --> Search bar appears. It would look like this: ___________________ [Current View] [Find all] [Scroll to] If the user initiates a contextual search (i.e. by typing in the view), it would look like this (by default): _SearchTerm________ [[Current View]] [[Find all]] [Scroll to] If the user initiates a contextual search after having changed the default to [Scroll to], it would appear as follows: _SearchTerm________ [^] [v] [[Current View]] [Find all] [[Scroll to]]. . . . . . . [x] Note: In the first two cases, pressing ENTER causes the search to execute and the search bar to disappear (i.e. searches aren't on the fly in those two cases) -This approach eliminates the need for the toast message, solves the need to easily switch search modes on the fly, and seems to be a cleaner approach that better merges these different functions. Moreover, it can even combine and integrate 'Advanced filtering' and 'Advanced search' functionality so that the Filter button can be eliminated. e.g. CTRL-F/Search Button --> Search bar appears. It would look like this: ___________________ [Current View] [Find all] [Scroll to] . . . . . . . . . . [Advanced search/filter...] II) Another approach that requires fewer changes, but also yields fewer benefits would be to just add the following to the search icon context menu: Advanced search Options ---------------- Contextual search o Filter matches . Scroll to match This doesn't yield the following benefits though: - trivial on the fly changes in search modes - simplification of the menu bar - integration of filtering |
|
|
I like the idea of FI) supposing that the search bar will be shown at the bottom (like in Firefox) , i.e. in our case above the player? |
|
|
Based on the described issues, came to the following on IM with Ludek: 1. Global Search: a. The Search bar isn't too visible/nice in Material Design skins (after Search icon click). Ludek will tweak it based on a screenshot I made. b. The Options and Advances Search are currently accessible on right-click on the Search icon. This isn't too intuitive and in order to not introduce too many UI elements to the toolbar, I think it makes more sense to show them only in the Search results view, somewhat in the top-right corner. 2. The Filtering/Incremental Search bar in the Breadcrumbs should have some easy way to switch the search modes. One option (I'm not sure that it's the best though) is to add a drop-down arrow which would show a pop-up menu: [x] Filter Matches [ ] Scroll to Matches ---------- Search whole Library {This is a one time action that initiates a Global Search for the currently entered phrase} |
|
|
F I) -- It was my intent to display the 'search bar' just below the toolbar. Re. Jiri's suggestion: 1a) Without seeing this, it's hard to understand whether it meets the requirements for understanding search options and trivially switching between them. But given the fact that _executing_ a Global Search switches contexts (i.e. changes from whatever node the user was previously browsing to Home > Search , I don't understand how it would be possible to trivially switch to a different search mode since the context has been changed by virtue of executing a Global search. 1b), One of the goals of F I)here and at 0012371 was to clean up the toolbar (remove Search bar and Filtering (funnel) icons), since I intended for the Search bar to appear transiently below the toolbar at the top of the list. Before going ahead with Jiri's suggestion, though, please think about how it integrates with filtering functionality (Funnel icon) as per my suggestions 0012371:0052976. Re. 2) Note that I chose wording of 'Find all' (vs filter) in order to eliminate confusion between contextual search filtering and Filter (funnel) functionality. |
|
|
I have implemented basics for both approaches today (FI & FII), namely showing the search bar when 'scroll to matches' is configured -- like [ _search_term_____ [^] [v][x]] But with FI) I am confused about the [Find all] -- I thought that it was meant to be a button for global library search? Or how can one switch from "Current view" search to "global" search? With the Jiri's suggestion (that is similar to FII) there is another issue. Namely where to place the search bar. Currently we are placing it on the right to indicate global search (and we are placing it next to the navbar in case of local "current view" search). But with the incremental search it looks strange to be place in either location, because user can perform incremental search within "media tree", "main view", "now playing" , so I guess that in case the incremental search the search bar should be rather placed in the middle of the toolbar? Or (with FI) we could place the search bar above the currently searched component (be it "media tree", "main view" or "now playing"), I am just totally confused about the [Current view][Find all][Scroll] buttons and don't get their meaning -- so I guess users won't get the meaning too ;-) Therefore the Jiri's suggestion seems clearer for me atm. EDIT: During implementation I found another problem though: user can filter a view ('filter matches' set), but then click into 'now playing' and perform incremental search within 'Now playing', in this situation we would actually need two search bars (one for current view filtering and another for now playing scrolling). |
|
|
I think that Incremental search initiated either in the Tree or NP shouldn't result in any toolbar activity, unlike when it's started in the 'Main view' |
|
|
ok, sounds good |
|
|
Implemented in 2167 |
|
|
Re-opened, just noticed that the switcher (dropdown arrow) from 'Filter matches' to 'Scroll to matches' does not appear when a collection root node is selected (like Music) => Fixed in 2167 |
|
|
Works pretty well imho. I just don't like the delay between typing and scrolling in the 'Scroll to Match' mode. Can't this be immediate? And, depending on focus, sometimes Backspace in the 'Scroll to Match' mode results in deletion of the last character in the search string and sometimes it results in return to the previous view. I think that this should be unified, I'd prefer to always delete the last character in the Search string, until is isn't empty. |
|
|
The delay was initially 500ms, but then (based on user requests) was enhanced to 1000ms for slower typists (item 10 here 0015185) We could probably decrease it again to 500ms -- as the slower typists has a workaround now: using search bar. Just the workaround cannot be applied when searching 'Now Playing' (or other components) when the search bar is hidden. Re: backspace key: I see, when focus is out of search bar then it returns to previous view instead of deleting the last character in the search bar. Always deleting the last character in the search string makes sense. TBD |
|
|
I understand the delay needed to reset the search string (i.e. to start a new search then). What's wrong imho, is that search isn't started immediately: e.g. when I type 'R', I get scrolled to 'Rolling Stones' immediately in MM4, while I have to wait ~1s in MM5. |
|
|
Some feedback & others improvements suggested here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94130 |
|
|
Fixed in 2168 |
|
|
Re-opened: as reported here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94130&p=457153#p457147 It currently does not cooperate with 'Column Browser' as it should. => Fixed in 2168 |
|
|
Verified 2170 Column browser now works OK also |
|
|
I'd never reviewed the design of this issue because it was 'Closed'. Functionally it's fine, but the current implementation doesn't seem to resolve the issues originally raised in F) i.e. that powerscroll doesn't yield useful/expected results in some nodes and that it would be important to allow the user to trivially switch between contextual search modes. I suppose it's too late to make any changes at this stage, but I still think that the unified search bar approach described at 0015077:0052972 is cleaner and more functional and could be worth considering in the future (pending resolution of issues that Ludek mentioned while experimenting with the implementation). |
|
|
Currently user _can_ trivially switch between contextual search modes -- just by using the dropdown arrow, see: https://www.dropbox.com/s/f6lccfir1wxz6cs/Screenshot%202019-05-16%2011.40.11.png?dl=0 And I also (personally) no longer see any usability issues. I believe that the current implementation is cleaner than previously suggested extra row: [Current View] [Find all] [Scroll to] . . . . . . . . . . [Advanced search/filter...] as the row unnecessary adds some further elements (buttons) on the toolbar and it is not obvious what the buttons do, the button captions are not clear enough. In addition this extra row would result in unnecessary resizing of the middle view part -- which does not look good (already tried during the implementation) Also, there isn't any negative feedback re the current approach so far, so I would consider this as 'no change required'. |
|
|
Agreed--I was looking for the switch on the Global Search context menu instead of the contextual search. Re-resolving. |
|
|
Re-opened: per feedback here: https://www.mediamonkey.com/forum/viewtopic.php?p=458897#p458864 G) User can be confused about which mode (contextual vs global) is used. Suggestions to improve: Show the dropdown arrow next to the search bar in _all_ modes (i.e. whenever the search bar is displayed -- including whole library search mode). - It should include the switch ( https://www.dropbox.com/s/u1ujmn1ylhzxpac/sort%20config%20dropdown.png?dl=0 ) between the search modes - it should also include links to 'Options' and 'Advanced search' (that are currently missing there -- and are only available when right-clicking the magnifying glass - which is hard to discover by users). - some tooltips or background text ( https://www.dropbox.com/s/2f9i4mozg8ypi3r/search%20control%20backgroud.png?dl=0 ) might be added -- in order to be clear which mode is being applied |
|
|
H) Since the scroll index is not obvious to the user, we could allow a free form scroll, where the user can explicitly override the default tag to be scrolled, by using the syntax of "fieldname:A" |
|
|
Items G/H are implemented in 2180. Some other improvements were suggested here: https://www.mediamonkey.com/forum/viewtopic.php?p=458897#p458864 |
|
|
Closing, this has been moved to 0016067 |
