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

[Davo]

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.

[dmcritchie]

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

[Barry4679]

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

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.

[Davo]

@ 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 ) 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.

[dmcritchie]

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

[Barry4679]

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.

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

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

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.