issue: expose custom fields in media tree
Posted: Sun Jul 31, 2016 9:20 am
I purchased the Gold edition last night. Thank you for developing and maintaining this excellent software. You show an extreme attention to detail and are responsive to user feedback, hallmarks of a great development effort. Congratulations!
Please note that I recognize that you may initially deem this report a feature request as opposed to a bug. I ask you for patience and to bear with me on this; in 2016, I believe this request has become a de facto requirement for your software due to other already-integrated features, and therefore this report should stand as a bug report.
Starting long ago, MediaMonkey supports tagging custom fields. A user can even edit the display name of custom fields, and the software provides auto-completion with previously-used values in the fields. So a user believes that this feature is fairly complete in its integration.
However, despite this robust support for custom fields, there is a fairly gaping hole in the functionality: Custom fields do not appear in the media tree. This severely limits the ability of a user to quickly ascertain how to effectively use custom fields vs. other non-standard fields like occasion, quality, etc. The workflow discrepancy between classification fields and custom fields is confusing to a user, who wonders why they can't simply get custom fields to show up in the media tree.
I have no need or desire to use the available extremely complicated, detailed (and well-developed) node plugin from Mr. Dimitrijević; nor should I have to. An average user will expect that, with all the support MM has for custom fields, that the custom fields will simply show up in the media tree. To have to discover that this is not the case, and then seek out an advanced-usage plugin just to get this basic functionality, is in my opinion a UX bug.
I believe it is obvious that [a] "Custom Fields" should be a top-level node of Music like Album, Genre, etc.; the user-edited titles (or the default "Custom Field x" titles) should be sub to that top-level "Custom Fields" node; and [c] all detected values in those fields should show up as sub to that.
For example, from the top level of Music, you might have:
----------------------------------------------------------------
Music
...Custom Fields
.........Theme
...............Teamwork
...............Joyousness
................Farm Life
.........Culture
................Mayogo
................Rendille
.........Custom Field 3 (unused)
.........Custom Field 4 (unused)
.........Custom Field 5 (unused)
------------------------------------------------------------------
As someone who works in software development, my cursory analysis (while of course, not having examined the underlying code) of your software leads me to believe that integration of this feature would be fairly straightforward, perhaps even trivial. Since a user like me decided to purchase the software precisely because of custom field support, to hassle the user with requiring additional plugins for the most basic node support seems a bit silly.
I see at http://www.ventismedia.com/mantis/view.php?id=8110 that this request has been in place since 2011, pursuant to a 2005 request made in the forums here: http://www.mediamonkey.com/forum/viewto ... =4&t=59198. I understand the reliance on Mr. Dimitrijević's work offered an expedient way to pursue other more pressing features; but surely, 10 years after the first request, this might now be considered for basic implementation.
Given the apparent simplicity of addressing this issue vs. its huge and obvious benefit, I request its inclusion as an item to be fixed quickly.
Please note that I recognize that you may initially deem this report a feature request as opposed to a bug. I ask you for patience and to bear with me on this; in 2016, I believe this request has become a de facto requirement for your software due to other already-integrated features, and therefore this report should stand as a bug report.
Starting long ago, MediaMonkey supports tagging custom fields. A user can even edit the display name of custom fields, and the software provides auto-completion with previously-used values in the fields. So a user believes that this feature is fairly complete in its integration.
However, despite this robust support for custom fields, there is a fairly gaping hole in the functionality: Custom fields do not appear in the media tree. This severely limits the ability of a user to quickly ascertain how to effectively use custom fields vs. other non-standard fields like occasion, quality, etc. The workflow discrepancy between classification fields and custom fields is confusing to a user, who wonders why they can't simply get custom fields to show up in the media tree.
I have no need or desire to use the available extremely complicated, detailed (and well-developed) node plugin from Mr. Dimitrijević; nor should I have to. An average user will expect that, with all the support MM has for custom fields, that the custom fields will simply show up in the media tree. To have to discover that this is not the case, and then seek out an advanced-usage plugin just to get this basic functionality, is in my opinion a UX bug.
I believe it is obvious that [a] "Custom Fields" should be a top-level node of Music like Album, Genre, etc.; the user-edited titles (or the default "Custom Field x" titles) should be sub to that top-level "Custom Fields" node; and [c] all detected values in those fields should show up as sub to that.
For example, from the top level of Music, you might have:
----------------------------------------------------------------
Music
...Custom Fields
.........Theme
...............Teamwork
...............Joyousness
................Farm Life
.........Culture
................Mayogo
................Rendille
.........Custom Field 3 (unused)
.........Custom Field 4 (unused)
.........Custom Field 5 (unused)
------------------------------------------------------------------
As someone who works in software development, my cursory analysis (while of course, not having examined the underlying code) of your software leads me to believe that integration of this feature would be fairly straightforward, perhaps even trivial. Since a user like me decided to purchase the software precisely because of custom field support, to hassle the user with requiring additional plugins for the most basic node support seems a bit silly.
I see at http://www.ventismedia.com/mantis/view.php?id=8110 that this request has been in place since 2011, pursuant to a 2005 request made in the forums here: http://www.mediamonkey.com/forum/viewto ... =4&t=59198. I understand the reliance on Mr. Dimitrijević's work offered an expedient way to pursue other more pressing features; but surely, 10 years after the first request, this might now be considered for basic implementation.
Given the apparent simplicity of addressing this issue vs. its huge and obvious benefit, I request its inclusion as an item to be fixed quickly.