View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003506 | MMW v4 | Now Playing | public | 2007-09-05 14:18 | 2007-10-26 19:26 |
| Reporter | Assigned To | ||||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0003506: useability issues with the 'now playing' search in current node | ||||
| Description | searching in the "now playing" node highlights the next found match everytime you press enter... but the selection is ADDITIVE each time, this is counter intuitive. It is also additive on any selection you had before you searched. It would probably be useful at times for it to be additive, but mostly it would be annoying... how about making it additive if the user presses "shift+enter" instead of just enter. also, in the "now playing" search, the search box should wait for the user to press enter. the search should search from the top of the list again once then end is reached (unless nothing was found - to prevent an infinite loop) the now playing search doesn't take into account the new search logical operations | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1094 | ||||
|
|
Dale raises some important issues here (also raised by others in the forum). 1) Change search current selection in Now Playing to not be additive (apparently this is confusing to users) The other 3 items don't seem to be 'immediate'ly pressing: 2) Wait for user to press <enter> 3) Cyclic searching 4) Search logical operators don't work |
|
|
I agree with rusty that 2, 3, and 4 aren't immediately pressing, however, I'll explain why at least one of these two; 2) Wait for user to press <enter> 3) Cyclic searching need to be implemented at some point. If the user starts typing "theology", then after the user types "the" the search jumps to a file with "the" in it. Then, once the user finishes typing "theology", if the file with that word in it is above the selected word with "the" in it, it can never be found by search.. - because the search isn't cyclic. either "2) Wait for user to press <enter>" or "3) Cyclic searching" would work to fix this issue - here are the cons for each one as I see it: cyclic searching: - having this alone, still means the first (or more) items will be skipped initially, which would be confusing to the user (and they might not search enough times to make it back top the start and see what they missed. - I imagine this would also be wierd to code if the skipped item is the ONLY item to meet the criteria (because it would have to loop once again to find it which means that has to be taken into acount when writing the code to prevent an infinite loop). waiting for enter: - this might be confusing at first because searches i other windows don't need it. I think waiting for enter is most logical and even it's con is negated by the fact that to continue searching you already have to hit enter anyway - so it's a related action. applying "2) Wait for user to press <enter>" would downgrade cyclic search to a pretty trivial issue. |
|
|
Assigning 1) to Ludek, feel free to implement the others based on their complexity and risk of introducing a regression... |
|
|
In order to be consistent with it "how searching works globally in MM" I would suggest to replace 1,2,3 by Everytime user change the search word/phrase , NP list is searched from start (the first track) and _all_ satisfied tracks are selected and the first satisfied track is focused. i.e. After changing the phrase all tracks became deselected and the process goes again. This way user can see all the tracks that satify his actual criteria and in addition it is working similar like searching another current node then NP. i.e. There is no confusing. Assigning to Rusty for a review. |
|
|
I agree that that's more immediately clear to the user, however, I don't think it's very functional. It's fair to assume the the user wants to do something with the track when they find it, however, if all valid tracks become selected and they only want one of them, then it is a pain to then select the one they want. ie. they have to deselect all, while keeping an eye on the one they want, and then select it manually. I don't think that hitting enter is such an issue, if they assume it will search automatically and it doesn't, then hitting enter will be the next thing they do naturally. Dale. |
|
|
I prefer the current functionality for the reasons Dale explained, and even more because searching within a playlist is mostly useful if the user can find the relevant track within its context (e.g. so the user can then adjust the position of the track within the playlist. If you think of a Playlist as a 'document' the user needs to find items within the document while preserving the context of what is found). (note: I also agree with Ludek that in the future, we should probably improve consistency somewhat--that may involve using different types of Search bars ... not sure ... consequently I would defer that). Thus: -We must fix 1) -We should fix 2/3 if it can be done with little risk |
|
|
1,3,4 fixed in build 1094. |
|
|
Verified 1094. |
