View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000860 | MMW v4 | Main Panel/Toolbars/Menus | public | 2003-11-03 17:05 | 2004-11-22 00:58 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 2.3 | ||||
| Summary | 0000860: Improve 'All' folder usability | ||||
| Description | In the Locations folder, 'All' is a very useful means of accessing information that is located in subfolders from a high level. The downside to it is that in a directory hierarchy, there are often multiple instances of 'All' all of which are adding nothing in terms of displaying tracks that can't be seen. The 'All' nodes should be modified so that they don't appear for a directory in which an 'All' node displays the identical contents of an 'All' node that appears at a higher level in the hierarchy: --this includes a directory that has no subdirectory (an endnode) --this includes a directory that has no subdirectory that ultimately contains any files i.e. 'All' should appear only for directories that contain both files and subdirectories (providing that the subdirectories contain files at any point deeper in the hierarchy). Setting this as 'Immediate' because it's a very obvious blemish that I'm assuming is simple to fix. | ||||
| Additional Information | e-mail discussion between Russell and jw@abprosys.com > 1. Why did you produce so many versions of the same example folder > (John Mayall)? This complicates the listing and navigation. Is this > some sort of bug or working as designed? As you can see in the > Explorer shot, there is only one folder. This problem repeats for any > folder and is not specific to this example folder. It looks like this is > caused by you creating multiple levels of "ALL" files under every > instance of a folder. Can this be stopped? The 'All' folder is meant to give the user a means of quickly seeing ALL files that appear in a folder and it's subfolders and their subfolders... The John Mayal that appears below ALL is also intentional because in many folder hierarchies, clicking ALL may yield a huge number of files--the John Mayal that appears gives the user additional filtering capabilities (i.e. browse to a particular directory and browse to all tracks by John Mayal that appear in that particular directory or subdirectories thereof. Note that in normal usage, the Locations folder and the ALL folder are often not even used--they are mainly provided for file management operations. [JW] I can understand the value of having an ALL folder. My problem is "all" the variations of ALL that you produce. Let's look at this in detail using the John Mayall example. 1. The highest level folder is BLUES. 2. Next is the John Mayall folder . 3. Under that is the name of the album - Turning Point. In turning point is a list of songs. 4. Under that is an ALL folder. This contains a list of the songs. 5. Under this ALL folder is a John Mayall entry with a list of the same songs. 6. Under the John Mayall entry is a Turning Point entry with the list of songs again. 7. On the same level as #6 is ANOTHER Turning Point album entry Further complicating this mess: You back up to level 3 and list another ALL folder with more sub folders for John Mayall and Turning Point. Starting from level #3, there are 9! Redundant entries of the same exact thing. Perhaps this is some sort of recursive error? I think that you don't need to do an ALL list for a single folder with one entry in it. > 2. When I did scan, MM didn't pick up WAV files. How come? The 'Add Folders' dialog allows the user to choose which file types to scan for. In it's default configuration, it doesn't scan for .wav files--if you want to do so, just check off the [ ] wav option. > 3. When I look at the real ALL list for the whole folder, there is no > indication of when a listing under ALL has multiple songs in it. See > the 3rd .GIF. You should change the folder icon to indicate multiple > songs present. Good point. I'd go even farther than that: the 'All' folder should probably only appear for any given directory when there are additional file(s) in subdirectories--otherwise there's no point to it. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I don't think it's that simple to remove 'all' from the lowest level in folder hierarchy and in all levels that don't introduce any change in the content. It depends on what is stored in what folder, usually 'all' wouldn't be of much use in the last two levels, but sometimes it may be useful. Also showing 'all' for some levels and not for others is probably more confusing than showing it always. I think that a better solution is to simply allow user to hide all 'all' folders in the Options dialog. |
|
|
wrt your two objections: a) the rules that I described should ensure that the 'all' folder appears only when it's needed b) the fact that it appears sometimes and not others wouldn't be confusing--it would be enlightening--it would let the user know that there's additional information about tracks contained in sub-directories that aren't visible in the main node. Currently, the user has no way of understanding whether the 'all' node is of any use. I think that if this isn't much work and not too computationally intensive, we should implement it--it cleans up a piece of functionality that _is_very_useful (a piece of functionality that I'd rather not 'hide' within the Options folder). |
|
|
One other related issue that should be addressed at the same time: Once the functionality is adjusted so that 'All' appears only when it makes sense, the ALL node should appear directly below the parent node instead of after all of the other folders contained within the parent node. i.e. if the user clicks /My Music/Rock Artists, he shouldn't have to scan 50 folders to get to the /All node. |
|
|
I reviewed how it works and how do you think it should work and my objections could be summarized as: 1. It isn't a simple operation to realize whether content of one folder is the same as contect of its parent folder, new queries would have to be executed with non-negligible running time. And to make it even more complicated, in case user copies/moved a file to the parent folder, 'All' node would have to be dynamically added. Thus the whole thing isn't simple in terms of implementation and required CPU time. 2. I also don't agree with moving 'All' to the top. It would clutter all folders and also in the current position it isn't hard to scroll to 'All' node - either it's visible or user can type 'All' (or usually just 'A'). 3. I still think that having 'All' in all folder is less confusing than defining some way of having it in only some folders. To make it even better I think something like 'All (folder name)' could be used. 4. Even 'All' for folder without any subfolders can be useful. If 'All' is expanded then, user can e.g. drag&drop tracks in order to assign them to correct album (useful for multi-artist albums). This is mainly important for large folders. |
|
|
In terms of all your comments re. usability, I have to disagree based on my experience with this functionality and that of users who've complained: 2) It is a bit of a pain to scroll when there's a directory that has > 0000026:0000035 subdirectories. Equally importantly, it's a bit strange to have 'all' at the bottom of the list of directories rather than at the top. 3) It's not confusing if 'all' appears in the places that it makes sense. Currently, this functionality appears all over the place, cluttering the hierarchy. 4) I believe that this usecase isn't as common as the usecase in which: a) user is browsing the tree which is clutterred by 'all' b) user is browsing 'all' in order to see all the _tracks_ that are sub to a directory and all subdirectories i.e. I think it's better to fix the more common usecase than the outlier. But if from an implementation perspective there's no way to make this functionality less 'cluttered' without being too computationally expensive, then I agree that we have to figure out another way to solve the problem. Perhaps this can be done by removing this functionality entirely, and using a filter instead. e.g. 'Show all' filter to show all tracks sub to a directory/subdirectory. Pushing to 'urgent'. |
|
|
push23 |
|
|
fyi: Some user feedback about this: http://www.songs-db.com/forum/viewtopic.php?t=1659 |
|
|
Fixed in 809 |
