View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009245 | MMA | Playlists | public | 2012-03-27 20:59 | 2012-09-11 22:13 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 1.0.1 | ||||
| Summary | 0009245: Workflow for adding tracks to playlists has redundant step. | ||||
| Description | At the moment user Selects Track(s), Chooses Playlist, and then user is Prompted whether to add to the selected playlist or to Create a New Playlist (even though the user already chose a playlist). | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 27 | ||||
|
|
There are implemented hiarchical playlists. When playlist is opened, user has option to add items to this playlist or create a subplaylist. There is also a row with path of currently viewed playlist. |
|
|
I guess that this issue would be solved by showing the playlists in their hierarchy, i.e. with an 'expand' indicator, which would show sub-playlists of the selected playlist. Pressing a playlist (not the expand indicator) would result in adding tracks to that playlist. |
|
|
Decreasing priority, would be nice to have this modified for 1.0, but might be deferred if not possible. |
|
|
Although the current implementation supports multi-level playlists, a) it's confusing to use for single level playlists because of the extra step to 'Add to this playlist' after the user has already chosen to add a track to the playlist. b) it's near-impossible to use for multi-level playlists because there are no cues re. the playlist hierarchy, it's difficult to navigate up or down in the playlist hierarchy, and the dialog shows directory paths which will be meaningless to most users. It's proposed to resolve this via the changes below (see attached graphic): 1) In the playlist list view, include an indication of which playlists are containers of playlists. i.e.: i) An indication of the number of playlists contained within a playlist (i.e. currently the view shows only the number of tracks--it should show the number of tracks AND the number of playlists) 2) For sending tracks to playlists, creating new ones, or moving existing playlists, use an implementation as proposed in the attached graphic that: i) uses context menus to move playlists / add tracks + modify dialog titles as suggested ii) displays 1 level of hierarchy at a time, but includes cues re. which playlists contain children. This implies changing the presentation of the playlist that's listed (currently it appears in small text as a path. It should be at least as large as other playlists that are displayed, and should appear in a friendlier manner e.g. Playlists > Favorites (instead of \playlists\Favorites\) ... > Favorites > Rusty's Top 20 (instead of \playlists\Favorites\Rusty's top 20\ ) iii) uses a row of action buttons (New, OK, Cancel) to perform operations iv) ensures that the most common operations are easiest to perform (the less common operations adding tracks/moving playlists to 'container' playlists involve an extra step). i.e. the screen doesn't change each time a playlist is chosen--focus remains on the current screen, except if a playlist has a child, in which case the child opens. (In contrast, in the current implementation, whenever the user clicks a playlist, a new dialog opens up containing the playlist and 2 commands (Add to / Create New)--which is quite confusing.) |
|
|
2 v) Jiri suggested adding checkboxes next to the playlists. This would give users the ability to add directly to a parent playlist (without having to go one level deeper in the hierarchy. It could be as simple as providing checkboxes on the right hand side, and once the user clicks a checkbox it gets added to the list. This would make the UI consistent for both Navigation and Selection, despite the fact that playlists can be both both Playlists and Containers. Graphic has been updated accordingly. |
|
|
Implemented in build 22. But something is still missing: - I still don't have icon for playlist-container. - Button cannot be easily styled. So they have default style. Please give me feedback what should be changed. |
|
|
Fixed playlist path container in build 23 |
|
|
It's mostly working, though cosmetically/ergonomically it really needs some improvements. Here's how it currently looks: 1) Choose Playlist (Yellow background-dark margin) 2) /playlists/ (Dark grey background [thin band] - dark margin) 3) [PL icon] <Playlist Name> '+' (Black background - white borders/dark margin) 4) [OK] [New] [Cancel] (light grey background-dark margin) I would suggest that this can be cleaned up as follows: 1a) Add the playlist icon prior to 'Choose Playlist' b) Use the same background for the entire dialog (except item 2a). It should preferably not be completely black so that dialogs can be easily distinguished from the main app. c) Use a single faint margin (if any) around the entire dialog (same color as 2a) 2a) The band should be the same width as other playlist bands (the different color is only to indicate that it's 'Active'. b) The playlist shouldn't be displayed as a path. i.e. it should look like a Playlist (or playlist container), the only difference being that it's the active one. e.g. [Playlist icon] Playlist > Test-1 c) As implied in 2b) it should also display a playlist icon 3a) As suggested at 1b, the background should be the same as for 'Choose Playlist' b) The stark white separators should be switched to faint separators that match those used in the track browser c) Consistent margin d) The [Playlist icon] (I don't see a container icon) and the '+' icon are both confusing, since '+' looks like 'expand' and [Playlist icon] looks like 'Add to playlist'. A simple solution might to: - Don't show any of the Playlists with an icon - Show playlists that are containers with a '+' on the left side - Show the [Playlist icon] on the _right_ side for adding to the playlist 4a) The background can be the same as either 2 or 3--we shouldn't introduce another new color. |
|
|
Per Skype discussion, the dialog is currently system dependent and should be rewritten to be completely custom. Then we'll be able to make it look quite as suggested by Rusty above. Some clarification: 2) This part of the dialog should be completely hidden in the playlists 'root', since there's nothing useful to show. Deeper in the hierarchy, this should look like a standard playlist entry, but somehow highlighted, possibly by a yellow background. 3d) We planned '+' (or whatever they look like) icons to save one step in playlist selection. However, since it's quite hard to design/implement them in an easily understandable fashion, we could remove them from the first version altogether. 5) Back button should correctly return in the hierarchy. 6) OK button should be disabled in the root. 7) (Optional, probably for future) 'New' button has quite a different context than OK and Cancel (both immediately close the dialog). I think that it would make more sense to include '+ Create a new Playlist...' item directly in the playlists view above - as suggested in the screenshot in http://www.ventismedia.com/mantis/view.php?id=9500. Note that I would make it the very first item (instead of last), in order to avoid scrolling in case user has a lot of playlists. |
|
|
Implemented two versions of 2) - Yellow background/black text (same as title) - Dark grey background/ yellow text |
|
|
Tested build 26 and found at least one issue (I haven't tested the others because this issue impedes testing): 8) Creation of child playlists isn't taking place at the correct level of the hierarchy if the playlist is created from tracks within an existing playlist. e.g. if I try to send a track from an existing Playlist to New Playlist 1 > Child of New Playlist 1, the child playlist isn't created in the correct hierarchy. Edit: I'm actually not sure what's causing this problem. Although I created a couple of playlists in correct hierarchy initially, now all playlists aren't being created in the correct locations. I wonder if perhaps it's related to the fact that I used the 'back' button... Edit: It seems that all child playlists except for the first aren't created in the correct location. |
|
|
"New" button fixed |
|
|
Tested build 27, and it looks good. But there are a couple of cosmetic issues remaining: 1) This is the only dialog that has an orange header/border (all others are black/grey) (e.g. Properties, Delete confirmation, Set as..., ). It seems out of place. 2) This is the only dialog that follows the Android convention for Cancel/OK (vs OK/Cancel). We should use one approach across the entire application. 3) The glow on the interior of the dialog looks strange. Can we get rid of that? |
|
|
Resolving, since 3) is fixed and 1&2 will be fixed as part of 0009500. |
|
|
Verified 28. |
