Hi,
Barry4679 wrote: ↑Wed Jun 12, 2019 12:44 am
What does the function of the + control that you added to your proposal?
it allows the definition of an n-deep index? ... eg. Genre>AlbumArtist>Album, or Composer>Genre>Artist>Album
or it allows the creation of additional subnodes? ... eg. create Genre_2 which is Genre>AlbumArtist>Album, additional to Genre_1 which is just Genre>Album
I think that both would be desirable.
I was referring regarding that Berry proposal to add [+] column for the purpose of adding additional sub nodes to tree. Which I personally think would complicate things.
I changed initial mockup so that User can add additional Root Tree nodes and its subnodes per collection view (Similar to way how new columns are added to track/list view) instead of having list of all fields available to be seen as root nodes (current UI behavior).
The main reason for that is to make tree views more customized per collections (eg. Types as predefined collections) and make them much understandable as novice users.
Example:
Music Collection tree nodes -> All Tracks, Artist (and/or Album Artist if selected), Albums, Genres, Years, Rating, Classification, ...
Classical Music Collection tree nodes -> All Tracks, Artist eg. Performers, Composers, Conductor, Albums, Genres, Years, Rating, Classification, ...
TV Collection tree nodes -> All Series, Series, Season #, Genres, Years, Actors, Producers, Rating, Classification, ...
Why I removed Berry [+] is that it can be handled differently in the way that defined Root nodes Even if they are not shown (eg. enabled) would define how sub nodes are formatted and if they would allow more subnodes.
Example based on Music Collection, which have these root tree nodes:
[x] All Tracks
[x] Artist
[ ] Album Artist
[x] Albums
[x] Genres
[x] Years
[x] Rating
[x] Classification
For each root tree node you would be able to select additional sub node from defined Root nodes List (eg. NONE + List of Root nodes enable or not).
This is How I would set my Music Collection Tree nodes:
[x] All Tracks -> [None]
[x] Artist -> [Years]
[x] Album Artist -> [Albums]
[x] Albums -> [Artist]
[x] Genres -> [Album Artist]
[x] Years -> [Albums]
[x] Rating -> [None]
[x] Classification -> [Artist]
That setting in multiple Subnodes showing and my tree node browsing more Dynamic.
Album Artist Root Tree node used as starting point:
Queen -> A Kind Of Magic -> Queen -> 1986
Same result Using Years as starting point:
1980s -> 1986-> A kind of Magic - Queen -> Queen (In case that on that album Queen had collaborations with other artists like John Stuart or Feargal Sharkey then they would also be listed and I would be able to right click to FIND MORE FROM SAME ARTIST to expand my knowledge of that collaborating artist)
Adding Double Node definition like you said Genre 1 and Genre 2 with different subnodes would most likely confuse regular users even I see it can be useful, but I (personally) doubt that most users would constantly use same thing in two different ways all the time and you would end in duplicate tree nodes cluttering UI (personal opinion).
dmcritchie wrote: ↑Tue Jun 11, 2019 3:03 pm
This seems to be contradicting how the Composer->Genre->Artist example works.
Can you clarify?
With examples I hope that now I have made things more clear, unless I made things more complicated/confusing
Graves wrote: ↑Wed Jun 12, 2019 3:53 pm
Totally supporting Peke's idea!
Thank you, but I am afraid that I just added more complexity for us to develop
I never liked Statistical science