|
|
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)! b) 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: https://www.screencast.com/t/zZvtWipTaWbM 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) |
|
|
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. |
|
|
5A) fixed |
|
|
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: S4) 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 Log attached. 7b) TBD 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. |
|
|
S4c/6) ok, so maybe we could resolve it by introducing third view type called "Grid/List" that would be available for playlists and folders and would achieve what you want ? i.e. folders in grid and tracks in list. I guess we could use the "browser" icon for the new view type. |
|
|
S4c/6) Sounds good to me, such a view could work fine. 8. Just a small aesthetic tweak - I'd introduce a subtle separator between the containers and tracks part. It probably could be just some 10-20px of empty space, even though a horizontal line with a low opacity in the main skin color could work too. |
|
|
S4c/6) is implemented in 2220 Lowering priority for the others items |
|
|
S4c/6) Verified 2220 in both playlists and Folders, but it looks little bit confusing and would suggest change back to just grid/list and in subviews add "Show playlists(folders) as list(grid)" depending if Grid or list is selected? In addition to above I wonder if Folders browser would look better if Sub Folders/Playlists would be presented in Multicolumn? bug15926_(S4c_6).jpg (101,291 bytes) |
|
|
S4c/6) Maybe "Grid (Playlists) / List (Tracks)" would be clearer ? Also in 0016266 we replaced 'Grid' by 'Grid (by Album)' which probably makes sense for folders (though makes less sense for playlists) So for folders the view menu could look like this: "Grid (Folders) / List (Tracks)" "List (Folders) / List (Tracks)" "List (Folders) / List (by Album)" "Grid (Folders) / Grid (by Album)" EDIT: Thinking about it again this really is cumbersome, I guess that better is to remove "Grid/List" entirely and modify it like this: VIEWS "List" "List (by Album)" "Grid (by Album)" SUBVIEWS [] Column filter [x] Grid (Folders) [] List (Folders) => Fixed in 2222 |
|
|
Re. S4/6) two possible approaches: A) If we just make wording changes, the only one that really needs to be changed is "Grid (Folders) / List (Tracks)" (i.e. the additional descriptive text for the others makes them more unwieldy). B) A preferable approach (though I don't know if it's realistic) is to use subviews to make the View name more clear i.e. stick with Grid/List, but have the subviews indicate what subviews are enabled. Currently it shows: [ ] Column filter [x] Info panel [ ] Playlist tree [x] Playlists [x] Status bar Wouldn't it make more sense to display: [ ] Column filter [x] Info panel [ ] Playlist tree [x] Playlists (grid) [x] Playlist tracks (list) [x] Status bar By the same token, this should be configurable within 'Manage views...' i.e. Sorting: Subviews: [ ] Column filter [x] Info panel [ ] Playlist tree [x] Playlists _[[grid], list]v_ [x] Status bar [x] Playlist tracks _[[list], list (by album)] . . . Columns: {Column Selector} |
|
|
I have made it per my later EDIT of my note 0015926:0056032 So let's test in 2222 Test notes: I have made the two sub-views mutually exclusive, so if "List (Folders)" is checked then "Grid (Folders)" is automatically unchecked. BTW: This way the "Playlists (Grid)" and "Playlists (List)" are mutually exclusive, but "Playlist tree" still can be enabled together with either of them -- so it resolves my original objection in note 0015926:0054554 (to be able to hide media tree, show playlist tree and playlist grid at the same time -- like this https://www.dropbox.com/s/cjss5dr5g9ybscg/Screenshot%202020-01-20%2022.32.33.png?dl=0 ). I am just not sure about the wording i.e. whether use "List (Folders)" or rather "Folders (List)". For the playlist I used it the other way, i.e. "Playlists (Grid)", but this can be adjusted anytime later. |
|
|
OK--will review in the next build. |
|
|
Tested 2223 and there are still cases in which the settings for Home > Playlists don't match the settings for Home > Playlists > PlaylistName e.g. for Playlists - Playlist1 - - Playlist 1-1 - - Playlist 1-2 --------------------- - - Track 1 - - Track 2 - - Track 3 i) Home > Playlists [Grid] shows playlists as a grid. Navigate to Playlist1 [Grid | Playlists (list)] --> Playlists display in list view ii) Home > Playlists [List] shows playlists as a list. Navigate to Playlist 1 > Playlists [Grid | Playlists (grid)] --> Playlists display in a grid One might say that these examples aren't bugs because the views are displaying in the manner that they're configured to display, however, it _is_ a bug because it shouldn't be possible to inadvertently switch the manner in which playlists are display from the top level of the hierarchy to the next level in. The solution is that changes to how folders are displayed made at the Home > Playlists level must apply to the Home > Playlists > Playlist name level and vice versa. Possible implementations are either: A) The view switcher icon works as it does today i.e. - It switches between Grid | List for Playlists at the Home > Playlists level - It switches between tracklist views at the Home > Playlist > PlaylistName level If the user switches the subview for PlaylistName (e.g. to Playlist (Grid)) then when the user navigates to the Playlist, the view should automatically be set to the same view as the subview. OR a possibly simpler approach: B) The view switcher icon always changes how _Playlists_ (or Folders) are displayed (at both the Home > Playlists and Home > Playlists > PlaylistName levels), and for the subview configuration to: - Not include Playlists (list) or Playlist (grid) - Include only Playlist tracks (list), Playlist tracks (list by album), or Playlist tracks (grid) I think that the second approach might be much easier to understand (and probably to implement) |
|
|
The current approach in 2223 is the most flexible that we ever had, because: 1) it allows me to use 'Grid' for the root Playlists node and see the thumbs and assigned images to the playlists/containers (when I have just a small number of root categories and playlists) while using the 'Playlists (list)' for individual playlists like "Imported playlists" where I have a large amount of sub-playlists. The same goes for Folders where I want to see the grid with several drives and servers with thumbnails like this https://www.dropbox.com/s/3d7hwo9314kdd4j/Screenshot%202020-01-27%2021.17.18.png?dl=0 while using 'List (folders)' to listing many sub-folders in [Folders > C:\ > Music] 2) it allows me to configure whatever combination of grid/list, i.e. List/Grid (folders), List/List (folders), List (by Album)/Grid (folders), List (by Album)/List (folders), Grid (by Album)/Grid (folders), Grid (by Album)/List (folders) 3) it allows me to set up MM5 with MM4 like view (i.e. to disable Playlists/Folders subviews when I want to see just tracks and using media tree) 4) it allows me to hide media tree, show playlist tree and playlist grid at the same time -- like this https://www.dropbox.com/s/cjss5dr5g9ybscg/Screenshot%202020-01-20%2022.32.33.png?dl=0 - with your approach A) => item 1) is not feasible - with your approach B) => items 1&3 are not feasible So from my point of view no change is required (with except to EDIT and EDIT2). EDIT: For better consistency and clarity we might want just rename: "List" --> "List (Tracks)" "List (by Album)" --> List (Albums) "Grid (by Album)" --> Grid (Albums) EDIT2: Testing it again there is a remainder from previous builds causing that changing root Playlists/Folders node to 'Grid' causes that the 'Grid (by Album)' is automatically used for tracks in individual sub-folders. I guess this should be independent again. |
|
|
I think that we may be getting lost in the details, perhaps because I wasn't clear in what I was trying to say. I'm just trying to make a simple point: that the format of folders/playlists shouldn't change as the user navigates higher/lower in the hierarchy. So if the user changes the format for containers at the top level and then navigates deeper, the format shouldn't change (and vice versa). In 2223 the format of folders changes as the user navigates up/down and it's difficult to understand why. See: https://www.screencast.com/t/9MkApHIgISeH Another confusing thing that you'll see in the video is that it's possible to disable Playlists from appearing entirely. I would argue that they should automatically be hidden if the tree is enabled (rather than allowing for this possibility). |
|
|
Yes, there was kind of misunderstanding, because what you have observed in the video was influenced by the bug that I later added as EDIT2 in my last note. This is a survival from previous implementation when there was only List (folder+tracks) and Grid (folders+tracks) and it was persistent for whole the branch. This needs to be fixed for 2224. Otherwise I don't think that 'Playlist (grid)' should be automatically hidden when the tree is enabled, see my example 4) in my last note , also e.g. Windows Explorer shows containers both in the tree and the view and user can choose where to open the containers. Also ability to hide both Playlists (list) and Playlists (grid) is required to meet the MM4 like design, i.e. my example 3) in my last note |
|
|
Fixed in 2224. So please give a try with 2224 - I believe that it finally meets all the needs, fixes the issues mentioned by you while keeping the flexibility (all items 1,2,3,4 from my note 0015926:0056268 are feasible) + modified the wording slightly for clarity |
|
|
Tested 2224, and although it's flexible, it's still confusing: 1) List or Grid makes perfect sense at the root level, but as soon as the view goes lower (where there's a mix of Containers and Tracks), the view names are confusing. e.g. a) Container containing only containers: ------------------------------------- i List (Tracks) ii List (Albums) iii Grid (Tracks) All three cases are confusing because switching views doesn't necessarily have an impact, and the View names don't make that clear. b) Container containing only tracks: --------------------------------- i List (Tracks). OK, though '(Tracks)' is superfluous. ii List (Albums). OK, though '(by Album)' would make more sense for consistency with other views. iii Grid (Tracks). OK, though as already discussed elsewhere, I think that this view is totally unnecessary and even confusing--why do we need to display tracks as a grid for Playlists and Folders and not for anything else?! 2) As described at 0015926:0056296, it's confusing when the manner in which Playlists are shown (Grid or Folder) switches when navigating between different levels of the Playlists view. I don't know why we didn't think of this sooner, but we already have a solution for how to display multiple levels of items within a view--just look at Music > Genres > GenreName [Browser]. It provides a simple means of switching the view at a high level, while also allowing to independently switch the manner in which tracks are displayed. Applying this to playlists could look like this: Playlists views: Grid, List (it would apply to containers i.e. no change) --- Playlist>PlaylistNameX [Grid] could show: [Playlist1] [Playlist2] [Playlist3] [Playlist4] [Playlist5] [Playlist6] [PlaylistNameX] [edit] [Play] [shuffle] [overflow] . . . . . . . . . . . . . . . List, [[List (by Album)]]v # . Title . . . . . Artist . . . . . Album . . . . . Date . . . Genre . . . . . Rating . . . -- Playlist>PlaylistNameX [List] could show: [icon] Playlist1 [icon] Playlist2 [icon] Playlist3 [icon] Playlist4 [icon] Playlist5 [icon] Playlist6 [PlaylistNameX] [edit] [Play] [shuffle] [overflow] . . . . . . . . . . . . . . . [[List]], List (by Album)v # . Title . . . . . Artist . . . . . Album . . . . . Date . . . Genre . . . . . Rating . . . -- This approach eliminates confusion, is simpler/more usable, and doesn't compromise on flexibility. |
|
|
We can eliminate "Grid (tracks)" view. I believe that it has been added only because we wanted to have just "Grid" for both tracks and containers like in Windows Explorer (and Grid by album does not make sense for playlists) As for the confusion, I guess that your latest approach does not solve much, because mostly playlists have no containers (just tracks). And in that case (and/or with the 'Info panel' and 'playlists' subviews disabled) the result would be Playlists > PlaylistNameX [Grid] # . Title . . . . . Artist . . . . . Album . . . . . Date . . . Genre . . . . . Rating . . . Track1 Track2 .... ... which is confusing ("Grid" view is showing just list of tracks !?) Alternativelly we could rather add the "in view" grid/list switch for containers. But I don't think that it improves anything and just consumes one more row of screen space? In addition it would complicate the "Manage views" functionality. So (for 5.0) I would suggest just eliminate the "Grid (tracks)" view and probably revert the wording to the default (i.e. unify it again with the others views for consistency)? |
|
|
Generally speaking, I'd agree with Ludek's proposal for 5.0 solution. And, I'd also consider what I suggested some time ago, since I think that it not only is nicer, but would make thinks somewhat easier to understand: 8. Just a small aesthetic tweak - I'd introduce a subtle separator between the containers and tracks part. It probably could be just some 10-20px of empty space, even though a horizontal line with a low opacity in the main skin color could work too. |
|
|
As an example of the challenges with the current approach, try going through the exercise of configuring MM: a) to use Tree view [there's no really good way without duplication of content) b) to switch from Folders to Grid or vice versa for containers (thinking like a user who'll have a tough time disambiguating what View and Subview applies to tracks vs containers) Ludek, re. your point that [Grid] wouldn't be the best name for a view that might only show playlist _tracks_ (and not containers). That's true, but the same holds true for [List] view that showed only Containers in a grid. That's why I was suggesting use of a 'Browser' type view (one that separates container and track presentation modes, and eliminates the need for different layers of views/subviews, and for most users to have to 'manage views..'/subviews to choose how containers are displayed. We could change the naming and use the folllowing pre-configured Views: enabled Subviews [Brower]: Column filter, [Info panel], Folder tree, Folder list, [Folder grid], [Tracklist], [Status bar] [List]: Column filter, [Info panel], Folder tree, [Folder list], Folder grid, [Tracklist], [Status bar] [Tree]: Column filter, [Info panel], [Folder tree], Folder list, Folder grid, [Tracklist], [Status bar] It seems almost ideal. But we need to get this finished asap, and if the approach I'm advocating adds too much time/risk then let's just move forward as you've suggested. As to unifying the view wording, is this what you meant? : Root Level [List]: Folder tree [Grid]: Folder tree Container Level [List]: Column filter, [Info panel], Folder tree, Folder list, [Folder grid], [Status bar] [List (by album)]: Column filter, [Info panel], Folder tree, Folder list, [Folder grid], [Status bar] |
|
|
a) to use Tree view [there's no really good way without duplication of content) => If you mean duplication of containers in the tree and in the view then it is how Windows Explorer (and many apps) works too. So it is nothing unexpected. And in MM5 user can disable the containers in the grid (having them only in the tree). So I don't see any limitation. b) to switch from Folders to Grid or vice versa for containers (thinking like a user who'll have a tough time disambiguating what View and Subview applies to tracks vs containers) => This was clear once we had only 'List' and 'Grid' for both containers+tracks, but you didn't like grid for tracks so we are abandoning it and thus making it more complicated (but also more flexible). Re: 'Folder tree' - I don't think that this sub-iew is needed for 5.0? It just duplicates the media tree. Re: 'Browser' view: Yes, I agree that this could be a better name for the Grid/List mix of containers and tracks. ---- Sooo, with the above in mind I think that this chould work for 5.0 and is just a tiny/cosmetic change: - for folders: [Brower]: Column filter, List (Folders), [Grid (Folders)] [List]: Column filter, [List (Folders)], Grid (Folders) [List (by Album)]: Column filter, [List (Folders)], Grid (Folders) [Grid (by Album)]: Column filter, List (Folders), [Grid (Folders)] - for playlists: [Browser]: Column filter, [Info panel], Playlists tree, List (Playlists), [Grid (Playlists)], [Status bar] [List]: Column filter, [Info panel], Playlists tree, [List (Playlists)], Grid (Playlists), [Status bar] [List (by Album)]: Column filter, [Info panel], Playlists tree, [List (Playlists)], Grid (Playlists), [Status bar] Note1: the rationale for using " Grid (Playlists)" instead of "Playlist grid" is the original issue 0015712 where user expected that "Playlist grid" will show tracks in grid grouped by album ("Grid (by Album)") and was confused: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=95040 That said we should also consider adding "Grid (by Album)" to playlists (as it can be useful for auto-playlists, see the user's use-case on the forum) and was available in MM4 too. Note2: The question is whether [Browser] should be the default view? i.e. do we want the containers to be shown as a list or as a grid by default? |
|
|
Regarding Note2: I'm suggest 'Browser' should probably be the default view. As to other changes/discussions: 3) Re. Playlists Tree: a) Terminology: For consistency of Playlists tree vs List (Playlists) vs Grid (Playlists), we should probably also use 'Tree (Playlists)' b) The current configuration is unfriendly because: . i) It duplicates the content in the main panel at the root level. . ii) Users have to enable it at both the root and container levels. Suggested solutions were to: - Remove the functionality (I'd rather keep it for now and collect feedback) - Disable the tree option at the root node (would be strange from a UI perspective to not have the tree at the root node) - Rationalize the Root and Container nodes with a single set of settings (too risky/time consuming at this point) So we'll leave it as is for now--available for those who want to try, but not enabled in any of the default views. 4) Re. Folders/Locations views: a) As discussed above/offline: 'Tree (Folders)' subview could be useful here. b) Is there a reason why [Status bar] shouldn't be available (at least for Locations views where this info is already in the DB)? |
|
|
8. OK, implemented the horizontal line separator in 2228 Note2: OK, implemented in 2228 3a) ok, makes sense, changed the terminology to "Tree (Playlists)" 3b) ok, makes sense Note1: You haven't written what do you think about adding "Grid (by Album)" view to playlists, but because some users are seeking for it (and it was in MM4 too) then there is probably no downside adding it. So I added it in 2228 together with the "Browser" view that is the default. 4a) Added in 2228 4b) OK, added 'Status bar' as sub-view also for location/folders (in 2228). |
|
|
5) fyi, you may have noticed this as you fixed things, but in 2227, the tooltip for the 'Grid' icon in the Folders/Locations nodes is 'Release date' |
|
|
5) Fixed in 2228 too 6) I have also noticed some 'Status bar' issues, tracking them separatelly as 0016360 |
|
|
Verified everything in 2228 with the exception of 3b) which we're pushing, and one minor item: Playlists > PlaylistName still includes Grid (by album) in contrast to what was last discussed at 0015926:0056613. Is this intentional? |
|
|
Yes, it was intentional. You have probably overlooked my Note1 above and the rationale for adding Grid by album for (auto-)playlists at https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=95040 |
- Anonymous
