View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015926||MediaMonkey 5||Tracklist||public||2019-09-06 17:55||2019-10-18 21:20|
|Target Version||5.0||Fixed in Version||5.0|
|Summary||0015926: Improvements to navigation of Playlist/Folder hierarchy|
|Description||In 0015712, Ludek wrote that:|
"Users are confused by the "Playlist grid" sub-view, see details here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=95040
I guess we should rename it to "Sub-playlists" ?
Similarly "Folders" should be renamed to "Sub-folders" in the location tree."
I've opened this bug since the confusion stems from more than a wording issue:
Currently, navigation of Playlist hierarchy and Folders ('containers') is fine in the tree, but poor when it comes to the tracklist. The issues are:
1) Grid views are limiting in the sense that:
. i) they take up too much space thereby requiring a lot of scrolling to get to actual files in the view
. ii) they truncate important metadata
2) List views to deal with the above have been implemented via an independent tree, but it's a limited implementation:
. i) currently, the 'Playlist tree' subview is only implemented for Playlists but not for Locations/Folders
. ii) the current implementation addresses the need to navigate the hierarchy, but it replicates the Grid view. e.g.
. . . 1 Navigate to Playlists
. . . 2 Enable Playlist tree subview
. . . --> All playlists appear in duplicate (once in the Playlist Tree and once in the Grid)!
. iii) the current implementation doesn't inherit parent container settings causing view settings to change as the user navigates playlists! e.g.
. . . 3 Click the 'Imported Playlists' node in the Playlists Tree
. . . --> The Playlist Tree disappears!!
. . . . Similarly, a situation could arise in which the tree is enabled in the Playlists node, and the user navigates to a subplaylist but no Grid/List displays!!
Issue 1) can be alleviated by enabling 'List' views in addition to Grids for containers, so that containers can be displayed one per row, with metadata of the users choice (much like most file explorers). I'm not sure if this is feasible for 5.0, and may not be critical if issue 2) is fixed sufficiently. Note, however, that I believe that a List view should be the default.
Issue 2) can be resolved as follows:
a) Use x sets of heritable settings for Playlists, so that whatever the user configures for the root Playlists node applies to child nodes as well. e.g.
. i) For the Playlist root, offer view choices of:
. . - Grid: Subview configured in 'Manage views', no flags (Playlist as thumbnails, Metadata: Playlist name)
. . - Tree: Subview configured in 'Manage views', no flags (Playlist in tree)
. . - List: Subview configured in 'Manage views', no flags (Playlists in list, Metadata: thumbnail, Playlist name, #Tracks, Last edited)
. ii) For an individual Playlist (whether a Playlist or container), remove the choice of Playlists Tree/Playlists Grid as subviews, and instead create a separate section below subviews:
. . Show Playlists as
. . (o) Grid
. . ( ) Tree
. . ( ) List
If the user makes a change here, then it should apply to the Playlist root node as well.
. iii) A similar approach should be used for Locations/Folders
|Tags||No tags attached.|
|Fixed in build||2206|
I don't think that having the restriction of showing only single playlist view type is a good restriction.
e.g. with 'media tree' disabled and 'playlist tree' enabled like this:
Show Playlists as
. . ( ) Grid
. . (o) Tree
. . ( ) List
user would end up with this: https://www.dropbox.com/s/7u4pwavzi7xrehz/Screenshot%202019-09-09%2012.50.47.png?dl=0
which is strange as it looks like the "Imported playlists" on the right has no sub-playlist, but it actually has many!
So I guess that rather the grid should be always enabled (as is by default) to show the sub-playlists.
As for the grid taking much space -- this is general issue for album/artist grids too, and can be resolved by descreasing the image size, this is already configurable in the album/artists grids and the config should be added to the others grids as well ? Also, we might want to decrease the default image size?
Also, I think that in 99% of cases the playlist either contains files or sub-playlists, there probably aren't playlists having mix of files+sub-playlists (unlike folders).
So the issues that you mentioned above are rather related to location/folders.
Assigned to Jiri to review/prioritize.
I agree that the 'Tree' approach isn't the best (because it either results in duplication of containers as currently implemented OR no containers displayed in the tracklist as in MM4)--the only reason I left it is because it's the approach used in MM4 and some users may want to continue with that approach.
As to the need for a 'List' view that supports both folders and files: it's needed for the same reason that almost every file manager/explorer supports such a list view by default: because it allows the user to see most of the information that they want to see in relatively compact form. It's true that the need for this functionality is stronger for Locations/Folders, but given the _number_ of playlists that are displayed on my screen, I also find that playlist navigation would benefit from a list view (that displayed containers).
Per IM discussion with the devs, the best solution treating the problems, while being feasible to implement:
S1. Show sub-playlists as a list, instead of a grid.
S2. Rename Subviews 'Playlists grid' menu item to 'Sub-playlists' (or something better?)
S3. Add a new View type 'Grid', which would show every track as a grid item (as currently Albums or Artists are) and together with this choice, also sub-playlists would be shown in a grid (as they currently are, until we change the default to a list).
Possible future changes (past 5.0):
O1. Currently we have containers (sub-playlists) and items (tracks) in two separate lists/grids, that while scrolling together, work to some degree independently. We might consider their merge into a single entity. This doesn't make sense for 5.0 though, due to complexity and risk of regressions.
re. S1. This item actually doesn't cover the differences of the root Playlists and individual playlists nodes. Will add S4 to cover this.
re. S2. Ok, will hopefully be enough to understand it.
re. S3. The questions are mostly related to S4. below:
S4. The root Playlists and individual playlist should share their view configuration, e.g. Playlist tree visibility should no longer be independent between there two. The only differences are that the root Playlists node won't show 'Column filter', 'Info panel' and probably also 'Status bar' (even though, it possibly could be there). It will also show Playlists, regardless of '[ ] Playlists' (S2) configuration. It also probably doesn't need to show 'List (by Album)' view type, since it would result in the very same view as simple 'List'.
Since these changes all seem to be in agreement with what Rusty wanted to change and should be mostly quite easy to implement, assigning to Michal (in cooperation with Ludek), so that we can have some preview of the changes and can better discuss them in a less abstract manner.
||Implemented in 2203|
https://www.screencast.com/t/ZVrHuX1f0B1c (I apologize in advance for the length--no need to watch any of it unless something below is unclear--it's probably most useful for 2)/S4 and 7a.
2)/S4 [high level issue]
The current implementation uses the same view for both containers and tracks. This isn't at all what I was trying to suggest. I was trying to suggest that subviews for nodes and tracks should be configurable independently, and heritable independently. The current implemntation results in:
- Grid view is unusable anywhere other than the root node (see 6a below)
- As a consequence of the above, nodes display differently from one node to the other (e.g. Playlists display as icons in the root, but as list items in other nodes)
3) Playlists [List view]:
a) there's no indication of which entries are containers (no arrow/indentation)!
b) enable Playlist Tree
--> Playlist tree appears with all entries truncated!
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was, but probably related to 7a.
4) Playlist>PlaylistName [List]: Switch from Grid > List > List by Album > Grid > List >
--> List appears empty!
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was.
5) Playlist>PlaylistName [List by Album]:
a) Tracks don't display in the order of the Playlist!
1 Change the sort order so that they display in the correct order
2 Switch nodes and then back to the original nodes
--> Tracks again don't display in the correct order (the sort order wasn't saved)!
1 Navigate to Playlist>PlaylistContainer>PlaylistName
2 Navigate to a different Playlist>PlaylistName
--> List appears empty (user has to scroll halfway down the screen to see the list) and only 1-2 tracks display at any one time!
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was but possibly related to 7a.
c) For both Playlists and Locations, in List by Album view, when scrolling downwards MM often resets the view to the top by itself. See:
d) In the Locations node, if the user enables List by Album view when 'display folder content recursively' is enabled, then the button to disable recursive mode disappears (it's overwritten by the 'Collapse albums' button.
6) Playlist>PlaylistName [Grid]
a) this view doesn't make sense for tracklists (it only makes sense for tracklist containers)! This is because it's unclear that the albums represent tracks and not albums;
b) This is a moot point assuming we fix the above issue, but the albums don't display in the correct order and there's no way to sort them in the correct order
7) With Playlist Tree enabled:
a) View gets corrupted sometimes (this is most likely the cause of the various other issues that I'm having trouble replicating). I'm not sure of the exact cause, but it seems to be related to enabling the PlaylistTree and then navigating among nested playlists between both the tree and the list view. After doing so:
Navigating to Playlist>PlaylistContainer>PlaylistName
--> Multiple lines of text are superimposed upon one another just above the header bar
See at around 9:00-11:00 in the video
Associated debug log is attached.
b) Selection of an item in the tree can fail
1 Select PlaylistA in the PlaylistTree
--> Tracklist updates as expected
2 Select Playlists in the main tree
--> Tracklist updates as expected
3 Select PlaylistA in the PlaylistTree
--> Nothing happens!
c) Playlist selection can cause the tree in PlaylistTree to collapse
1 In Playlist tree, select PlaylistContainer>PlaylistNameA
2 In List view, select PlaylistNameB
--> PlaylistContainer collapses
d) Playlists>PlaylistContainer>PlaylistName [List by Album] displays incorrectly (similar to the above but worse than without PlaylistTree enabled)
(tested with Playlists>Event playlists>Channuka dinner)
--> List appears empty (user has to scroll halfway down the screen to see the list)
--> On scrolling, the header gets 'stuck' in the middle of the screen as tracks scroll through it
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was but probably related to 7a.
EDIT: I've added items 5c),d)
bug15926_item7a.7z (137,684 bytes)
ok, besides all the mentioned sub-issues above (where most of them are long-standing or Rusty can no longer replicate) there remains the main question that needs to be decided:
6a) Rusty thinks that representing both tracks and containers in a grid doesn't make sense (while Jiri thinks it is useful -- e.g. for touch mode)
Assigned to Jiri for triage / review of the Rusty's notes and the implementation in 2203
S4. Isn't implemented yet, i.e. Playlists node and individual Playlists still have independent configuration (Ludek)
2) re. same view for both containers and tracks - makes sense to me, after all this is how e.g. Explorer works. We can discuss over IM with Rusty.
3a) Containers are somewhat differentiated by their icon. That said, we certainly could consider somewhat more prominent differentiation.
The rest seems to be mainly some UI updates problems, Ludek please have a look and let me know.
Items 7a, 7b, S4) are fixed in 2204
EDIT: 7a) still isn't fully fixed, it still happens sometimes, finding more...
EDIT2: S4) also isn't fully fixed for root location/folders nodes
3a) I added the children count info directly like:
[icon] Imported Playlists (226 playlists)
=> fixed in 2205
Re-opened: I forgot to fix items 5a & 5d
=> 5d is fixed in 2205
=> 5a to be fixed by Petr (details sent over IM)
S4) is implemented in 2205, but I suppose that the default view type "list" versus "grid" should vary based on the mode "Desktop" versus "Touch" ?
e.g. 'Folders' node in the Desktop mode would default to list: https://www.dropbox.com/s/yf48pakxmvimwyi/Screenshot%202019-10-16%2012.46.29.png?dl=0
While the same "Folders" node in the Touch mode defaults to grid: https://www.dropbox.com/s/bowyfd26v1hq9qq/Screenshot%202019-10-16%2012.46.58.png?dl=0
2/S4) I am not sure whether the "grid" vs "list" should really persist for whole navigation branch, this is not how explorer works.
In Windows Explorer when you navigate C: > Temp > MP3 then you can have
- "list" in C: ( see https://www.dropbox.com/s/gzkkvako9gd09f7/Screenshot%202019-10-16%2013.13.47.png?dl=0 ),
- "grid" in Temp ( see https://www.dropbox.com/s/g3buzfgx3cwvrx8/Screenshot%202019-10-16%2013.15.20.png?dl=0 )
- "list" in MP3
And this way the view persist, so returning to C:\ is always in "list" while "C:\Temp" is always in "grid" !!
I guess that the similar could be useful in MM, e.g. for the root "Folders" node I would like to see grid (with the large icons) as there are mostly just several items, while in Folders > C: > Music > ... one would prefer "list" as the number of sub-folders is large.
S4) re. Desktop vs. Touch defaults - sounds good to me, even though I can live without it.
2/S4) I think that in MM5 it really makes sense to keep the same view type in the whole playlist hierarchy. As for the Windows Explorer, I think that it's slightly different in this aspect - it's supposed to show very heterogeneous content, some folders contain audio, some images others documents and so it makes sense to have different views in different folders. There's rather a low need for this in MM5 imho.
S4) different defaults for touch vs desktop implemented in 2205
2/S4) ok, leaving as is, i.e. keeping the same view type in the whole playlist/folder hierarchy
Tested 2205. Verified except where indicated below:
a) Re. different defaults for Touch vs Desktop mode: sounds good. I tested it out and settings seem to persist independently as expected.
b) Re. whether the grid/list should persist down the hierarchy, it appears that they do (for both playlist containers and folders) which is fine.
c)/6 BUG: The problem still remains that Playlist tracks and containers have the same view, resulting in the situation that Grid view is only useful until the user navigates to a container that contains tracks i.e. the Grid is applied to all containers in the hierarchy (useful) and tracks (useless because it obscures track order and fails to display track metadata). I may be wrong, but I don't think that Jiri intended to include tracks as part of the 'whole hierarchy'.
3a) Containers now indicate the number of playlists contained within. Seems like a reasonable compromise.
5) Playlist>PlaylistName [List by Album]:
c) BUG: List by album view still seems to scrolls to the top by itself! e.g.
1 switch to staticPlaylistA (containing 30 tracks)
2 use scroll wheel to quickly scroll down 15 tracks
--> after a second or 2, view scrolls to the top.
Repeating step 2 causes this to happen about 4 times and then it stops occuring.
7 Playlist Tree enabled:
e) BUG: Main tree and Playlist tree can be out of sync
1 Click Playlist A in main tree
2 Click Playlist B in Playlist tree --> focus switches to Playlist tree as expected
3 Click Playlist C in main tree --> focus remains on both Playlist B and C ! When the user clicks on the main tree, nothing should remain selected in the Playlist tree.
f) Performance BUG: clicking a playlist container with many subplaylists causes the UI to not be responsive. e.g.
1 Click Playlist: Imported Playlists (which contains many subplaylists)
2 Immediately click Playlist B and then Playlist C and then Playlist Click
--> UI takes about 5 seconds to respond
c)/6) Jiri really intended to include tracks as part of the 'whole hierarchy', the point of this is that grid view is especially useful in Touch mode, but also in the Desktop mode for folders and playlists including videos, music videos and TV episodes (where the video thumbnail is the most important metadata). So I believe that the current implementation is fine in this way. Also as Jiri pointed this is how e.g. Windows Explorer works. Anyhow, user can change the grid to list anytime -- so I don't see any usability issue here.
5c) I could replicate previously, but I cannot replicate now whatever I do (following https://www.screencast.com/t/zZvtWipTaWbM ).
Could you please catch this in debug log?
7b) I think that users will either use Media Tree or Playlist Tree, they will hardly use both -- so I don't think that this is really an issue that needs to be fixed.
7f) I cannot replicate, but maybe I am doing something differently, could you please screencast this bug with DbgView running?
Note that running DbgView can cause an UI responsiveness issue when many debug strings are about to output , but this is rather flaggy UI (than a freeze for 5 seconds).
FYI: re 5c/7f) There were some performance issues already fixed in 2206 that could be related ( 0015971:0055041), so it would be good to test these items with 2206.
So please re-test in 2206 and screencast+debug log in case the issues still persists for you.
S4c/6) I can understand the argument for having playlist movies display in the grid view. But when it comes to the tracks in a music playlist the grid view is useless: track representation is poor as they look like albums, metadata isn't editable in-line, and most significantly the user can't even re-order the tracks :-(
5c) Still occurring in 2206 for me. See: https://www.screencast.com/t/sRhpWmgF
7f) Can't replicate in build build 2206.
7g) I think I mentioned this at some other point, but when the Playlist tree is enabled, and the user navigates to Playlists
--> The full list of Playlists appears twice! It looks quite strange.
build2206_group-by-album_scrolls-by-itself.7z (66,195 bytes)