View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009679 | MMA | Action bar | public | 2012-09-09 22:45 | 2012-09-16 06:05 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 1.0.1 | Fixed in Version | 1.0.1 | ||
| Summary | 0009679: Unselect tracks upon completion of contextual action | ||||
| Description | Currently when creating a playlist or adding tracks to Now Playing, the user must 1 select tracks 2 perform an action 3 unselect tracks 4 go back to step 1 In addition, step 3 is often overlooked, resulting in duplicate copies of tracks being added to playlists. Upon completion of an action, tracks should be unselected. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 30 | ||||
|
|
I thought about such a change in the past, but since other applications (tested some Google apps) seem to take the described approach, seems to be preferable to do it the same way. I think that it also has some advantages, since sometimes user might want to do multiple operations on the same set of tracks. |
|
|
The problem is that most actions in MM are: - One-time contextual actions - One-time contextual actions on a single track And the current workflow forces the users to go through an extra step to perform a task as simple as adding a track to Now Playing (select-hold, Add to Now Playing, Unselect, Select-hold another, Add to Now Playing...). Other apps get around this via: - one-time contextual action mechanism (in addition to multi-select) that allows the user to perform an action once. e.g. most any music player will allow the user to select a track and add it to the Now Playing queue, and then proceed to do so with other tracks. - other apps that have multi-selection have a means of deselecting tracks quickly after a multi-select action has been completed. e.g. Gmail has a 'Done' button, ES File Explorer has a button to disable multi-select (mediamonkey has this, but it's not obvious). Possible solutions: 1) Implement one-time contextual actions via a context button next to each item in a tracklist (similar to Google Music) 2) a) Display the states of the multi-select button so that it's more clear that it can be used to control/disable selection (e.g. one of 4 selected for enabled, 4/4 selected for all selected) OR b) Use a 'Done' button like in Gmail. 3) The approach suggested earlier in this thread (disabling selection after performing an action). I think that the best approach would be a combination of 1) and 2a), but since 1) is probably too risky at this stage, 3) seems like a good compromise. |
|
|
1) I don't like an addition of a new button, particularly since it only duplicates existing functionality. 2) Ok, this could probably be modified, e.g. like in Gallery, where 3 buttons are: Select All, x items, Unselect all. That said, I'm not sure whether it's better than the current state in MM, it's just a different representation of the same, possibly marginally easier to understand. 3) This one is hard to decide. I guess that after some actions (like Set As...) it's quite unlikely that user would need to re-use the selection. After other actions, this feature might be _very_ useful for users. In any case, looks like a small issue to me, that can be decide later based on user's feedback. |
|
|
1) It's true that it duplicates existing functionality, but it fulfills a different usecase. The question is which is the more common usecase. 2) You're right--this would only be a minor improvement--but at least it would eliminate the likelihood of users not realizing that tracks are still selected after adding them to NP. 3) As I alluded to above, I believe that single-track, one-time selection is the most common usecase (the only time repeat selections might be needed is for Playlist construction and for that usecase it's likely the exception rather than the rule). A possible compromise would be to let the user decide (e.g. [x] Keep tracks selected after executing an action), but I think that the it's better to take the approach suggested (unselect after carrying through on the action), and adjusting from there based on feedback. Even the Gallery application works this way. |
|
|
As discussed, we'll go with the 3rd approach, and revert if it causes issues. |
|
|
Fixed in build 30. |
|
|
Verified build 30. |
