| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016188 | MMW 5 | Main Panel: Toolbars & Menus | public | 2019-12-12 19:18 | 2020-01-15 16:30 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0016188: Improved tree navigation in cases where 'showallnodes' is enabled | ||||
| Description | Peke has indicated that MM5 doesn't provide him with the tools to navigate his collection as well as MM4, primarily due to deficiencies with the tree functionality. This has been alluded to in various bugs but without communicating a clear understanding of the consequent problems. I've I've tried to provided a comprehensive description of the various issues and a couple of possible solutions. The main reason that FMFS can't be used as effectively as in the past because is because users must manually navigate to the location of the tree even after they've navigated to the same location in the tracklist. This results in the following types of situations: 0 Set views to list view (as advanced users would likely do when organizing their library) 1 Select a track and then FMFS folder (Library) --> MM shows contents of \\Share\very...long...path\..Last Directory --> Tree has Music > 'location' highlighted The problems here are that: a) the user must click the breadcrumb bar in order to see the parent directory's contents (and click it again to see other parent directory contents) b) it makes drag and drop operations very difficult since the user must manually open the tree to the desired location in order to e.g. drag files to a parent directory. A related case is: 1 Select a track and then FMFS Artist (Library) --> MM shows contents of Home > Collection > Artists > ArtistName --> Tree has Music > Artists highlighted Issues here are that: c) if the user is using the list view, there's no possibility of seeing 'subfolders' (i.e. Albums) of the Artist without first switching to Browser view (which advanced users wouldn't want) d) if the user wants to switch to drag tracks between albums, the user must first manually open the tree to the desired location All of the above cases could be resolved with either of the following changes _only_ when showallnodes is used: A) Modify the behavior of clicking the breadcrumbs so that it opens the node in the tree (as previously suggested at 0016024) B) Add an option to 'Expand to open folder' (if showallnodes is used) as alluded to in #13798/0015783. This would work similarly to the identically named Windows Explorer option (it's no longer the default behavior of Windows Explorer). note: I think that if showallnodes could be modified to support A) only, that most needs would be met. | ||||
| Steps To Reproduce | EDIT: Comments by Peke Comparison Behavior MM4 and MM5 (up to build 2219) which shows that tree nodes are almost unusable for FMFS and tree on Clean Install (with or without 'showallnodes' installed) Preps: 1. Create Folders c:\TESTCASE\1\ and c:\TESTCASE\2\ 2. Copy Single Music track to c:\TESTCASE\1\ (Please use track that have most metadata filled as it will make tests easier) [Test 1] MM4: -------- 1. Install Clean MM4 Portable and Start (Cancel first Start Wizard) 2. Using Windows explorer Drag and Drop track from c:\TESTCASE\1\ to Now Playing 3. Right click FMFS -> Folder (My Computer) 4. Drag and drop Track from Track list to c:\TESTCASE\2\ MM5: -------- 1. Install Clean MM5 Portable and Start (Cancel first Start Wizard) 2. Using Windows explorer Drag and Drop track from c:\TESTCASE\1\ to Now Playing 3. Right click FMFS -> Folder (My Computer) 4. You can't drag and drop file to c:\TESTCASE\2\ as it is not focused 5. Expand Folders 6. Expand c:\TESTCASE\ 7. Drag Track to c:\TESTCASE\2\ [Test 2] MM4: -------- 1. Install Clean MM4 Portable and Start (Cancel first Start Wizard) 2. Scan c:\TESTCASE\ to Library 3. Open Music Collection 4. Right click FMFS -> Genre 5. Drag and drop Track from one genre to another (Additional features available by Holding CTRL or SHIFT) MM5: -------- 1. Install Clean MM5 Portable and Start (Cancel first Start Wizard) 2. Scan c:\TESTCASE\ to Library 3. Open Music Collection 4. Right click FMFS -> Genre 5. You can't Drag and drop Track from one genre to another as it is not focused 6. Expand Genre 0016190 (Shows point where to click to expand Genre even ShowAllNodes Script is not installed like on Vanilla MM5 install) 7. Scroll To Track Genre 8. DRAG and DROP not implemented 0016189 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2220 | ||||
|
|
Steps for explaining several behavioral bugs of FMFS like #13798 0014379 #13222 and many of their related bugs. In Windows you can easily enable Tree Followup browsing (Attached Picture): With Disabled Option very Similar behavior to current MM5: 1. Open File Explorer 2. In Quick Access Tree node -> right click on any recent file -> Open File Location 3. Location is opened but Tree has not changed (Exactly the same behavior we have in MM5 only Root tree node is highlighted) With Enabled Option behavior and user experience is completely different: 1. Open File Explorer 2. In Quick Access Tree node -> right click on any recent file -> Open File Location 3. Location is opened and Tree has been focused to folder with the file As we assume that user do not use/have Tree opened it was never implemented in MM5 and behavior is the same as not enabled navigation panel option. Where solution would be to Implement rusty suggestion B) Where For Location/Folder browser it would Open + Focus tree to that folder (0016024 and Rusty description of [0] for list views and also in case that ShowAllNodes extension is installed would do same thing and open + focus to desired node 0015783 (Rusty Related case [1]). Another approach would be that under Views drop selection we add Option to switch tracing behavior #13798 (eg. Same like explorer option Expand to open folder) where users can chose desired behavior which is combination of my expected behavior 0016024 both Rusty suggestions A and B (THIS BUG) as it will be best because users that use touch mode can get easy access thru tree especially as tree can be hidden/risen with one toolbar button. EDIT: As talked to Ludek offline any doubts and questions should be sent to me. Especially if there is too much work involved for full implementation in 5.0. |
|
|
From my understanding Peke is suggesting a config for (like in case of Windows Explorer). i.e. even when showAllNodes script is uninstalled then there should be a config for expanding tree when doing "Find more from same" actions or clicking a hyperlinks (like in the Preview window) I am not keen of adding this though for the reasons below: 1) auto-expanding of the tree results in worse performance 2) in MM5 the expand states are remembered for all nodes (not just the last opened node like in MM4), with that it mind the tree can become extra large and maybe with the config enabled we should probably auto-expand just the nodes for the last selected node after restart (like in MM4) 3) it is annoying for users that prefers to keep the tree small - they would have to close the auto-expanded nodes after each FMFS action 4) there are very well usable workarounds in MM5. e.g. in the Peke's examples with D&D user can simply pre-expand the nodes before performing FMFS and the node will be focused. i.e. this works in MM5: -------- 1) Expand Music > Artists to have all artists expanded 2) Use find more from same artist anytime later (even after MM5 restart) => the artist is focused in the pre-expanded tree |
|
|
While talking to Ludek and revising test cases, if Implementing this it can improve data management and usability of Drag and Drop and user experience of Touch Mode. From Skype: Just found out one more use case where Tree will NOT move focus at all if View dropdown option "Focus Tree Node while browsing" is disabled (that Small context menu is implemented) By my rough calculation it would save much CPU/Rendering of UI especially if tree is hidden and FMFS -> Artist/Year/... Would show much faster and secondly user can position tree to desired place like Playlist and use FMFS or Track Browser to find files he/she needs and then just Drag and Drop To tree. |
|
|
To be honest I like the "Open in tree" contextual command on the breadscrumb originally suggested by Rusty here: 0016024:0055116 Rusty wrote that he is not keen on that either because the UI currently doesn't make assumptions about the tree being open. But I suppose that the context menu would be shown only when the tree is visible? i.e. having [Music > Location > C:\ > Music > Folder1 > Folder 2] on the breadcrumbs I can right click Folder 1 > Open in tree I guess that this will work fine for the Peke's use-cases and minimizes all the cons of auto-expanding tree by default (like in MM4). |
|
|
But thinking about it again I guess that the solution A) suggested by Rusty should work better (as with the addon all items are part of the tree) + gives users the choice (simply by installing or not-installing the addon) A) Modify the behavior of clicking the breadcrumbs so that it opens the node in the tree (_only_ when showallnodes is used) Assigned back to me to implement it (once more urgent issues are fixed/implemented). |
|
|
As Talked on Skype here is my observation of current state. This is not an issue only for Folder browser but also apply on Rating, Classification, Genre and all other tree nodes based browsing where Folder browser is most obvious and most extreme due the lengths of path (eg. [Music] > Location > Network > NAS > Multimedia > Music > Pop > Queen > The Miracle > Track Name) where FMFS is most used. As pointed in MM4 we implemented that in most nodes, in MM5 behavior is completely removed making it not possible to use tree at all without big downfall of extensive multiple clicking and navigating. I agree that Tree less browsing have its benefits especially if viewed on Large Screen with D-Pad or In touch Mode, but more advanced Users with large number of Tracks and extensive folder Structure on multiple NAS/Cloud/PCs (which is more and more common these days) have Tree Node Open (Default UI setting for MM5 Clean Install) we can't assume that most of user do not use it. Even we assume that tree is not visible adding Overlay Tree Auto-Hide/Open is useful as most modern UI have Slide in/out left right Columns eg. Windows Action Bar or Firefox/Opera/Chrome SideBars, explorer preview, Android, iOS, ... (This is for another feature in future versions of MM5.x) So any modern browsing app have both Context on breadcrumb solutions (very rarely both) and also Check Box "Follow Tree Nodes when browsing" (MM4 Behavior) are more than reasonable and very much usable. Especially as user can easily switch them. in MM5 we currently we force users to single use case even they got used to one last 15 years in MMW where with little dev time we can make it possible for all three cases: 1. Tree less Behavior Like Rusty prefer (Pros: UI is faster, less CPU, Less Rendering. Cons: almost no D&D functions, playback focused, not good for mass tagging and to archive common tasks) 2. MM4 Like behavior where Tree is open and browsing follows tree (Pro: easy tracking and corrections of Tags in Tree, D&D, tree corrections for Mass tagging (eg. typo issues), Easy tagging Multi value enabled fields (Point 2 in 0016189) . This way also make use of Context menu "Open in Tree" as suggested along with FMFS MM4 Behavior for all main enabled Nodes (mainly Folder/location nodes) and when ShowAllNodes script is install to all nodes like artists. 3. With and Without Tree Open (Will use tree open example as it can be understood easily) as sort of hybrid mode of Two of them above. User Can browse (expand tree nodes to desired view like Music > Ratings (expanded) the uses Grid browser to navigate to Artist -> Queen -> Album Miracle. Tree Node do not change focus/move at all it still shows Expanded ratings and user can easily select several tracks to D&D to 4 star rating. (Pro: UI is fast, less CPU/Rendering, User is not distracted by tree movement and can easily switch main root view for track browsing as in case 1, By using Context "Open in Folder" user would get also all pros from 2. Only major Con for this approach is for mass taggers and library managers that heavily use D&D and maybe few more taps/longtaps in touch mode. NOTE: Behavior will expand on all tree nodes when ShowAllNodes is installed If anything is unclear let me know. Personally current approach is nice looking and fast, but lacks major functions that MM is known for and not much usable for advanced users. |
|
|
It seems that we still aren't simply in an agreement. For me using D&D on the tree nodes is the most cumbersome method of editing (especially for many sub-nodes), I have never used it so I probably don't see Peke's use-cases as so important. I also don't see why I should D&D to '4 stars' node when I can use right-click > My Rating > 4 stars easily or use mass edit on tracks (for whatever attribute)? EDIT: As for the agreement: Rusty & Jiri concluded in 0013962 that the showAllNodes addon doesn't need to be installed by default, however, it's very important that users who do want this be able to install the functionality easily as per 0014042 i.e. 0014042 seems to be the real TODO IMHO EDIT2: If we would want to pre-install the showAllNodes addon then the "Open in tree" contextual command (solution A) would be better to resolve this issue and to prevent from undesired auto-expanding of the tree. I would suggest to postpone until we have an agreement. |
|
|
Note that based on IM discussion Peke prefers "Follow Tree Nodes when browsing" checkbox even in MM vanilla (i.e. without showAllNodes installed). I am not sure where to locate such a checkbox though (to be discoverable and keep context). Maybe the breadscrumbs context menu would be the most appropriate? |
|
|
To summarize the above, there are three main points of contention: 1) Should ShowAllNodes be enabled by default? We'd previously decided (0013962) that this functionality would be available via an addon, but Peke and Lowlander feel that this is insufficient. 2) When ShowAllNodes is disabled (as it is by default), as of build 2018 Years/Location/Files/Playlists to Edit still expand. There's been discussion recently here and in various other bugs (#13151, 0016190, 0016191, ...) about adding folder expansion to other nodes by default. e.g. there's been discussion re. extending this to Ratings, and Classification because like Years, they always have the same set of subfolders, and Genres because it would be useful. 3) When ShowAllNodes is active, how should MM behave with respect to opening folders of tracks that have been visited (so as to facilitate viewing of the associated hierarchy and/or drag&drop to the folder in question)? Options suggested are: A) Modify the behavior of clicking the breadcrumbs so that it opens the node in the tree (as previously suggested at 0016024) B) Add a subview option like Windows Explorer's 'Expand to open folder' (or 'Open in tree') for list views, as alluded to in #13798/0015783, that when enabled, would cause a tree node to open. C) In combination with B) always switch focus to the relevant folder when FMFS is used, if the folder is already open. D) Add an 'Open in Tree' context menu (rather than a config option, though I'm not really sure how this could work--i.e. _which_ tree/attribute would open?) Taking all the feedback thus far, I would suggest: 1) Continue with MM5's current approach, but instead of including 'ShowAllNodes' as an extension, make it an Option (e.g. [ ] Allow tree nodes to expand). This can be an option of the 'Media Tree' element.) 2) Assuming we implement 1) (which means that 'ShowAllNodes' type of functionality is relatively accessible, there's no need to implement tree expansion by default for anything other than the bare minimum (e.g. Folders, Location, Playlists, and perhaps the Podcasts nodes which already behave this way). 3) Re. opening the folders associated with an entry, I think that the cleanest approach is option A (which is similar to how Windows Explorer and Free Commander work, and obviates the need for any configuration options. But we'll probably have to go with whatever approach is most expedient. Assigning to Jiri for feedback to ensure we're in agreement. |
|
|
1) OK. While I still don't think tree nodes are that important in MM5 given the other new features, since we already implemented the script, it possibly makes sense to make it part of MM5. 2) OK, even though I'd keep the current set of tree nodes, the new option should only add nodes where with potentially unlimited # of subnodes, i.e. as it currently does for Artists, Albums, Genres... 3) I prefer B), I don't this we should force tree expand for users who don't like it. Both 1&3 need a new option. They can be either directly part of the tree pop-up menu or, Ludek suggested to create a '...' button in from of the Home tree node (there's an empty space, since the node doesn't have an Expand icon) that would show tree configuration. I'm ok with both, or possibly even better to hide this option in the 'Configure Collections and nodes' dialog, since I don't expect they'd be changed too often to be worth showing them too prominently. |
|
|
OK, as for the wording, I guess that following could work for media tree context menu (to be reviewed by Rusty once I implement it): [ ] Make all nodes expandable [ ] Expand media tree when navigating Configure collections and nodes... I would keep this only in the media tree's context menu (as currently we have no longer a section in Options for media tree). As for the three dots menu, I guess it will need to be in the right-top corner (because Home node could be configured as hidden and then the expand mark of a collection could be in collision with the three dots menu button) |
|
|
Re. 3A) I wasn't suggesting that clicking the breadcrumbs should always expand the tree. I was suggesting that it should expand the tree _only_ if the user enabled '[ ] Allow all tree nodes to expand' (thereby obviating the need for the second option). If we continue with 3B) despite the above comment, the strings could be: [ ] Allow all tree nodes to expand . . [ ] Expand media tree when navigating [Tooltip: Causes folders to open when navigating to content like in earlier versions of MediaMonkey] It would also make sense to include this in 'Media Tree' options (e.g. via a 'gear' next to 'Media Tree' in Layout) so that like everything else, it can be configured via Options. But this isn't urgent (especially considering that no other options are yet configured there). |
|
|
IMHO these two options are independent. 'Expand media tree when navigating' can still be useful without 'Allow all tree nodes to expand' e.g. for playlist nodes. This is also the reason why I think that 3B) is better than 3A). |
|
|
OK. So the wording can be changed to: [ ] Show all subnodes in the media tree [ ] Highlight nodes in the media tree when jumping to content [Tooltip: Available subnodes open when navigating to them via links or breadcrumbs] OR further simplified to the following if context makes it clear that it's Media tree config: [ ] Show all subnodes [ ] Highlight nodes when jumping to content To be clear: [ ] Show all subnodes in the media tree => Gives user the expand/collapse icon so that he can manually show e.g. all artists below the Artists node. If disabled, the only nodes with expand/collapse functionality (excepting Podcasts) are Location/Folders/Playlists. [ ] Highlight nodes in the media tree when jumping to content => Expands the media tree to the active node, but only when the tree can be expanded. I.e., it always shows the active playlist, but if you navigate to Beatles when Artists subnodes are disabled (default), it won't create/show Beatles tree node, Artists node will remain focused instead. |
|
|
OK, I would just suggest: - to change the word "highlight" -> "focus" - add "Collapse the tree" item (like in MM4) - move "Configure collections and nodes" from context menu of individual collection nodes to the new three dot context menu So the menu could look like this: media tree menu.png (17,372 bytes) |
|
|
Implemented as suggested in 2220. I decided to keep the "Configure collections and nodes" in the context menu for individual collection nodes too (for the cases when the tree isn't visible) -- related to 0015766 But I suppose that we could possibly rather remove them (as mostly users configure the nodes mainly because of the media tree + we also have this config in Options already) |
|
|
Verified 2220 It surprisingly works very well and all should be covered. Small tweaks will be added in new bug. |
