|
|
Fixed in 2210 |
|
|
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: SEARCH CURRENT VIEW (o) Filter matches ( ) Scroll to selection ----------------------------------- Options 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. |
|
|
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: https://www.mediamonkey.com/forum/viewtopic.php?p=458897#p458864 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 https://www.mediamonkey.com/forum/viewtopic.php?p=458897#p458864 (which leaded to the item G) in 0015077) |
|
|
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) |
|
|
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: SEARCH CURRENT VIEW (o) Filter matches ( ) Scroll to match --------------------- Options 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 https://www.mediamonkey.com/forum/viewtopic.php?p=458897#p458864 |
|
|
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. |
|
|
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. |
|
|
Resolving, this has been already matured in various related issues... |
- Anonymous
