Poll: Media Tree Nodes with sub-nodes useful or not?

Post a reply

Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Poll: Media Tree Nodes with sub-nodes useful or not?

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Barry4679 » Sat Jun 08, 2019 9:44 pm

Davo wrote: Sat Jun 08, 2019 5:59 am To date i haven't heard one solid argument that suggests an expanded Media Tree can't coexist with a multi-dimensional graphical browser based display.
Sometimes simplicity is paramount
I don't know why they turned it off.

I am not trying to argue with you ... just saying that I don't miss it ... and that I am pleased with the new browsing methods, that for me, have superseded it.

As I said in the previous post, I not worried if they come back, provided they don't make the UI sluggish.

Davo wrote: Sat Jun 08, 2019 5:59 am The Media Tree is an extremely simple & efficient way of locating information without having to wade through views & search queries, no matter how multidimensional, sleek, or exciting that may be
Yeah, I said all that multi-dimensional yadda yadda ... but that doesn't mean that it is complex to use, or there is anything much you need to learn

I don't want to labour the point unnecessarily, but here is a couple quick example to make that point.

First make sure that you still have Tools|Options|Library|Search set to the default ... Contextual search, at the top, still set to "filter matches".

Unless I have mixed you up with someone else, you are interested in Classic Music ... right?

So go to the Classical Music node to filter just to your classical tracks, and click AllTracks .... that's all the "wading" through indexes and views that is required

Say you wanted to view or edit some of your Beethoven tracks played by Jacqueline Du Pré

All you do is type beet jacq .... there is no special search syntax that you need to learn ... just typing into the view, when the mouse focus in in the grid, opens a search control for your for the "beet jacq"criteria, and filters the display to just your albums containing these tags
https://www.dropbox.com/s/bbrs4sfms3hh9 ... q.png?dl=0

Or you were looking for the quartet containing the title "Death and the Maiden" .... just type maid, and it filters to just albums having tracks like this
https://www.dropbox.com/s/7da5tspmjad653v/maid.png?dl=0

And if you want some list scrolling it is done better with the Column Browser. In this example I have configured it with 3 columns; Composer>Genre>Artist. ... So I scrolled to Brahms, and then to his Chamber music, and finally filtered to just his Chamber tracks featuring Daniel Barenboim ... ps. the column browser is switched on like this
https://www.dropbox.com/s/mcno7i1le233j ... r.png?dl=0

And if I wasn't so album focused, I would have used the List view for these three examples, rather than the Album&Tracks view
https://www.dropbox.com/s/pn967ucuksl2j ... s.png?dl=0

Davo wrote: Sat Jun 08, 2019 5:59 am By user defined Media Tree, i mean being able to set up multiple views of the tree, eg Composer/Album or Composer/Artist etc. This obviates the need to proscribe what & how data elements are viewed & avoids endless discussion about implementing particular nodes & the structure of the tree. Just set it up the way you wan't it.
Thanks for the clarification.

There are things that you could do in MM4 if you used the magic Nodes extension ... and this flexibility will be lost in MM5, because Magic Nodes is not being migrated to MM5 ... it would have been good if some extra flexibility was built into MM5 to compensate ... like being able to substitute albumartist index for artist index, or summarising a list to show just the artists or albums that it contains, in list mode, rather than just grid mode ... but in many of these cases the Column Browser is your friend

dmcritchie wrote: Sat Jun 08, 2019 1:52 pm So the new way is fine for those who prefer it or learn to like it, but there is little disadvantage to supporting both ways of accessing our data. And as I wrote before, the average user migrating from MM4 to MM5 is not likely to want to fool around with an unfamiliar interface for very long. I think he/she is mostly going to want to hit the ground running, and then think "That was easy!". :-)
I don't think that we have any significant point of disagreement. ... I do think that the case for upgrade to MM5 will be compelling, due to the new and improved features, and enhanced navigation is just a part of that.

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by dmcritchie » Sat Jun 08, 2019 1:52 pm

the other name for keeping all the old ways of doing thing is "software bloat" isn't it?
Actually, no it's not. As a software developer, I can tell you that the other names for "software bloat" are bad design and inefficient implementation. Backward-compatible features are customarily left in many libraries and products with no discernible effect on their efficiency and usability, because they're well designed.

In this case, as David wrote, I don't see it as an either-or situation. A user-configurable media tree can be efficiently implemented that would not consume cpu resources when not actually in use. You could argue it would require some additional memory, but that would likely be very small potatoes in comparison to the memory footprint of MMW as a whole. And the memory needed would likely not be much more than that needed by the fixed-format media tree currently in MM4. Also, for users with no use (or only occasional use) for the media tree, using the toggle (Ctrl+Alt+T) easily makes the media tree invisible.

So the new way is fine for those who prefer it or learn to like it, but there is little disadvantage to supporting both ways of accessing our data. And as I wrote before, the average user migrating from MM4 to MM5 is not likely to want to fool around with an unfamiliar interface for very long. I think he/she is mostly going to want to hit the ground running, and then think "That was easy!". :-)

Dennis

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Davo » Sat Jun 08, 2019 5:59 am

@ Barry
I don't understand what either of you are saying, btw ... ?
I don't believe this is an either/or discussion, unless there are critical technical issues which preclude a particular implementation.
The Media Tree is an extremely simple & efficient way of locating information without having to wade through views & search queries, no matter how multidimensional, sleek, or exciting that may be (not that i am against stuff like that mind you :wink: ) This simplicity is especially important when it comes to editing data.
By user defined Media Tree, i mean being able to set up multiple views of the tree, eg Composer/Album or Composer/Artist etc. This obviates the need to proscribe what & how data elements are viewed & avoids endless discussion about implementing particular nodes & the structure of the tree. Just set it up the way you wan't it.

To date i haven't heard one solid argument that suggests an expanded Media Tree can't coexist with a multi-dimensional graphical browser based display.
Sometimes simplicity is paramount, like when i log on to view my bank statement. I just want to see a list of transactions in chronological order.

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Barry4679 » Sat Jun 08, 2019 12:17 am

dmcritchie wrote: Fri Jun 07, 2019 4:02 pm And it would also seem that you don't mind typing to search, whereas I prefer to not take my hand off the mouse, and would rather complete my search by clicking a few more times.
Yeah, I see a little typing as being a small cost if it advances MM to multi-dimensional navigation, from all that node switching and scrolling. ... Besides, to avoid shoulder injuries, it is good ergonomic design if our s/w gets us to move our hand away from the mouse from time to time :D

dmcritchie wrote: Fri Jun 07, 2019 4:02 pm So as Davo wrote, I agree it is best to let users define the media tree nodes and levels, since no single solution will please everyone.
I don't understand what either of you are saying, btw ... ?

I think that you are arguing for the existing MM5 status quo? ... ie. a user option to switch on a compatibility option having sub-nodes in the Media Tree ... and retaining the Gold version option of defining the selection criteria and display attributes for their own Media Tree collections?

I suppose I don't mind if the sub-nodes are sitting hidden, and unopened, in My Media Tree, as long as MM is not made more sluggish, by fetching and caching their info, in the improbable expectation that I may want to open those nodes sometime ... But the downside is that, for new users, the sub-nodes are bit like junk food ... ie they will get used, delaying people from taking the time to learn how to use MM5 in the way that it was designed.

I think that the MM Designers should stay their course, with a sleek design as the default option. MM5's default mode of navigation moves beyond single level indices, which is one of the pluses of MM5. ... And it is also suitable for touch type devices, with limited screen real estate. It is also generally better suited to smaller screens; you & I may have large screens, but only 20% of us enjoy 1920x1080 http://gs.statcounter.com/screen-resolu ... /worldwide

I also think that it is good that they offer a compatibility mode for casual, or satisfied users, or to assist the initial decision whether to upgrade.

I think that your suggestion of a wider-ranging "compatibility mode" install, or configuration, option is a good one.

They do with a couple of those ... eg. have another one for album-focused customers, which would do things like:
  • auto-enable display of the Album Artist 2nd level nodes
  • replace the Artist eye candy on the home screen with Album Artist eye candy
  • and use album artists in Genre>Artist>Album
  • etc etc.
I think that you argued that it is unwise to change a UI too much ... MM5 is a once every 10 year renewal, so some housekeeping should be excused ... the other name for keeping all the old ways of doing thing is "software bloat" isn't it? Speaking personally, I hate learning a new-to-me heritage s/w tool, where they have retained every new and old way of doing things. It is so hard to determine best current practice.

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by dmcritchie » Fri Jun 07, 2019 4:02 pm

Barry,
I want to allocate most screen width to the data columns, and the Media Tree is just in the way once I have navigated. Speed scroll in the Media Tree's sub-nodes was OK, but generally there was too much scrolling through long long lists, and expanding, and then contracting, the Media Tree column width. Also the hassle of opening|closing nodes, so that I could access the rest of the Media Tree.
This is of course very user-, collection size-, and monitor size-specific. On my monitor, I can make my media tree panel as wide as I need to not truncate the names of artists, etc., and still have ample width left for the data columns. So I rarely expand or contract the media tree panel's width. Similarly, the number of rows on my monitor are such that I do very little scrolling (a little mouse wheel rolling is enough), and usually only open and close nodes when I change the type of searching I am doing (e.g., genre vs. album artist).

And it would also seem that you don't mind typing to search, whereas I prefer to not take my hand off the mouse, and would rather complete my search by clicking a few more times. So as Davo wrote, I agree it is best to let users define the media tree nodes and levels, since no single solution will please everyone.

Dennis

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Davo » Fri Jun 07, 2019 5:23 am

IMO the media tree nodes & levels should be user defined. I must say I find it intensely irritating when application owners want to dictate how i view my own data.

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Barry4679 » Thu Jun 06, 2019 8:45 pm

I used the MM4 sub nodes for navigating, because that is all that we had. I want to allocate most screen width to the data columns, and the Media Tree is just in the way once I have navigated. Speed scroll in the Media Tree's sub-nodes was OK, but generally there was too much scrolling through long long lists, and expanding, and then contracting, the Media Tree column width. Also the hassle of opening|closing nodes, so that I could access the rest of the Media Tree.

I had some initial adjustment problem with MM5, but have worked with MM5 quite a bit during this beta test, and I now prefer the new and improved navigation tools in MM5. .... I like it that the sub-nodes are an option. I don't intend to turn the option on, because I find the new sleek design to be more functional, and less expensive in screen real estate.

The new paradigm still has scrolling. ... Better scrolling IMO ... eg. option of scrolling just of the 1st characters in the tag, or scrolling on any word in the tag
https://www.dropbox.com/s/iqe3ywg89kb0u ... d.png?dl=0

The new generic facility is also integrated with filtering .... and MM5 navigation is much more multi-dimensional that the MM4 ... ie. I went from situations like these ... https://www.dropbox.com/s/va7945agi6f5f ... t.png?dl=0

I typed "cap", and was given all these target options, which is a large improvement navigation IMO.
https://www.dropbox.com/s/qo4pla0gnz9sc ... n.png?dl=0


In vanilla mode, the MM5 Media Tree is deprecated to being little more than a tool to jump start your MM session ... ie. select your collection node, and to optionally select a 2nd-level node (eg. Artists, or Albums, or Composers, etc), where each have a index-tailored grid|art view, which is kind of like a "home" screen for the index.

Once started you can reclaim screen real estate by toggling the Media Tree off, and do further navigation without it .... and in MM5, there is a tool bar button for that toggle :)

I do have issues with some implementation issues with the new MM5 facilities, but all that is being worked through during these alpha and beta phases of MM5.

I do agree that there is a learning curve and some initial disorientation ... but this the usual cost of progress isn't it?

MM could do themselves a favour, and produce some slick training|orientation aids, like a series of videos, or some walkthoughs, because they would help, and are needed in a few areas ... but I am not optimistic because they have never excelled in this area have they?

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by dmcritchie » Thu Jun 06, 2019 4:15 pm

This matter seems to me somewhat analog to the controversies about Linux or Windows start menus:
As far as Linux is concerned surely the classical structured! start menus are by far the most popular designs, like in KDE, Cinnamon, Mate, LXDE etc. .
Gnome, Windows 8, Unity (Ubuntu) etc. lost a lot of users by their decision to remove them.
I respect but never really understood why someone could prefer the "type-in-what-you-search-for..."-designs.
Maybe both approaches should be available as an option?
I agree with Friedrich. I do not want to have to remove my hand from the mouse to type any more than necessary. With the MM4 media tree, I don't have to type at all, and thus it takes me less time to select my track(s). It is no doubt a matter of personal preference, but to reduce media tree functionality is not a good idea IMHO if you want to keep many of your MM4 users happy.

Dennis

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Friedrich » Sat Feb 04, 2017 6:19 pm

gamb2009 wrote:The nodes in the tree are very effective to edit bits of the database. For instance, if for some reason you have misspelled the name of an interpreter (Classic Music or Jazz, happens all the time) you can easily discover and fix in the tree, changing at once many tracks from different records. That feature is actually missing in MM5.
Fully agreed. I am using it very often, too. Having all subnode-entries in the tree editable is an extremely fast and powerful feature.
Hopefully this function can be added to the "showAllNodes"-extension ..

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by gamb2009 » Sat Feb 04, 2017 3:40 pm

One of the most powerful performances and features of MediaMonkey 4 is how good it manages a big database. The nodes in the tree are very effective to edit bits of the database. For instance, if for some reason you have misspelled the name of an interpreter (Classic Music or Jazz, happens all the time) you can easily discover and fix in the tree, changing at once many tracks from different records. That feature is actually missing in MM5.

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Barry4679 » Fri Feb 03, 2017 9:23 pm

Ludek wrote:They are intentionally eliminated. They were hard to navigate anyway. Instead you can search them in the grid view just by typing the first letters.
Typing the first letters into the grid is affected by the setting in Tools|Options|Library|Search, so you you may get more returned results than are useful. ... eg I have the above option set to AlbumArtist & Album ... if I am in the Albums node, and type an "g" into the grid, I get 452 albums returned, but I only have 72 albums starting with "G" ... this is because it returns albums like "My Song" by Jan Garbarek and Keith Jarrett ... presumably because of the "G" starting the word "Garbarek"

I prefer the sub-nodes.

The good thing about the sub-nodes, is that I can quickly browse through the list, rather than having to peck and hunt, by trying this character and then that character

If you persist with removing them, could the matrix filtering be based just upon the field that the node is grouped by?

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Peke » Fri Feb 03, 2017 1:41 pm

djdd wrote:When an extension repository is created for MM5, there should be a clear distinction between extensions build by the MM5 developer team and extensions build by the community.
This is something we are working on, but as MM5 is in Alpha stage and changes we are thinking about are big changes both MM5 App and MM Server side in order to make things right and future proof. I'm thinking that you users and current/future developer would like it.

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by Friedrich » Tue Jan 31, 2017 1:24 am

djdd wrote:Around that stable “kernel”, extension (this is the name used in MM5) can be added to extend the functionality, like this sub-node extension.
Making features optional by the way of extensions is surely the best solution one can wish for, because everyones needs and preferences can be met.
I am completely happy and content with that.
MaximusPrime wrote:Great! That's why I love MM so much, you developers listen to what the user ask for
Yes. Great devs, great community. Thanks to all!

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by djdd » Mon Jan 30, 2017 4:20 pm

For me sub-nodes are useful.

I’m working as a developer, tester and quality manager. So, I suggest, that the main program should be kept as small as possible, to keep it as stable as ever possible.
Around that stable “kernel”, extension (this is the name used in MM5) can be added to extend the functionality, like this sub-node extension.

I also would like to see, that I can start MM with two different configurations, with different extensions loaded.
  • As DJ, I use MM side by side with “Traktor”, so search songs and drag & drop them to “Traktor”
  • At home maintaining the library and preparing DJ sets I need extension, I don’t need during a DJ performance
When an extension repository is created for MM5, there should be a clear distinction between extensions build by the MM5 developer team and extensions build by the community.

Regards,
Dieter

Re: Poll: Media Tree Nodes with sub-nodes useful or not?

by MaximusPrime » Mon Jan 30, 2017 3:36 pm

Ludek wrote:The addon can be downloaded here: https://www.dropbox.com/s/zvsc6nos8p2ld ... .mmip?dl=0
It shows subnodes for all person nodes, album, series, genre, rating (like in MM4)

D&D of tracks to assign a category works for Rating, Album, Series in 2058.
The rest will be fixed in 2060.
Great! That's why I love MM so much, you developers listen to what the user ask for

Top