View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005726 | MMW v4 | Playlist / Search | public | 2009-06-04 21:25 | 2009-06-18 22:03 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | text | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.1 | ||||
| Summary | 0005726: Searchbar-generated subnodes are incorrectly labelled as: _Any_ text field contains "<search term>" | ||||
| Description | 1) When the user performs a search via the searchbar, the search configuration options limit which text fields are actually searched. Thus 'Any text field contains "<search term>"' is a misnomer on two counts: a) MM only actually searches only those text fields that have been configured to be searched. (for Searchbar-initiated searches [and not to search-dialog-based searches], since the search parameters apply only to those searches). b) MM actually searches multiple fields i.e. all the search terms do not have to be contained within a single field Suggested wording by Chris: Chosen text fields contain "<search term>" If this is too long, we might use the slightly more vague: Text fields contain "<search term>" 2) Issue b) also warrants a change to the wording of 'Any text field' in the Basic and Advanced Search dialogs. Suggested wording: 'Any text fields' | ||||
| Additional Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=39991 Related issue at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=39990 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1252 | ||||
|
|
> Chosen text fields contain "<search term>" > If this is too long, we might use the slightly more vague: > Text fields contain "<search term>" Actually "text" seems redundant since all choosable field are text, so how about "Chosen fields contain"? |
|
|
Since it would most likely mean to create a new unlocalized string, I'd suggest to defer. |
|
|
Absolutely. I think I was getting tired ;-) |
|
|
Alternatively we could fix for MM 3.1 by using one of these: Search "<search term>" "<search term>" |
|
|
My preference is: 1) Contains: "<Search term>" 2) Any text fields |
|
|
'Contains:' looks good. For 3.1 inclusion we would have to capitalize the first letter, as currently we only have 'contains'. We can do, I guess it isn't a big deal either way... |
|
|
1) fixed in build 1252 by using suggested 'Contains:' |
|
|
This fix simple drops the faulty noun rather than fixes it, replacing inaccuracy with imprecision. Please keep open an issue to change to "Chosen text fields contain" or any other accurate sentence form. |
|
|
Yes--we'll need to open a new bug before closing this issue. This was the best way to 'fix' without introducing a new string. |
|
|
Re. issue 1): on second thought, imprecision might be better than strict accuracy in this case. i.e. 'Chosen fields contain' though accurate, will confuse most users in the sense that they will have no idea what the 'chosen fields' are referring to. |
|
|
> they will have no idea what the 'chosen fields' are referring to. Such users cannot properly interpret the search results anyway. I don't think user that do have an idea should should be disadvantaged for the sake of those that don't. This is problem arising from a search results display that, unlike most app searches e.g. Word, Gmail,does not ID the scope or specific matches. The best solution would be for MM Track List to highlight searched columns and found strings, but given the reliance on an third-party search engine, this might not be easy. |
|
|
I like the idea of highlighting the text fields containing the searched string, but highlighting all fields that are being searched would be a visually unpleasant, I think. If you've seen an implementation along those lines, it might be worth adding a topic to the wishlist with a screencap or 2 (once the beta is out, I'll be going through the wishlist / & bug report forums...oh joy...). |
|
|
> highlighting all fields that are being searched would be a > visually unpleasant, I think. I agree, but I suggested only to highlight the /columns/. :) > If you've seen an implementation along those lines Like this: http://img189.imageshack.us/img189/2194/91348762.gif MM's new search poses the difficulty of the technically false match, red-ringed. EDIT: "technically false" is false - apologies. |
|
|
We might add a new checkbox to the Options|Search panel to enable the highlights for users that want this. |
|
|
Ludek suggested: > We might add a new checkbox to the Options|Search panel to enable the highlights for users that want this. Agreed, and I suggest it be checked by default. And important is a button on the search bar to turn off the current highlighting - one of the things Gmail got right! :) |
|
|
Assigning to Rusty for review. 1. What the text change should be? 2. Should we open a new issue for the "highlight fields" feature? |
|
|
Re-resolving this as fixed. I've migrated the discussion to 0005801. |
