View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013404 | MMW 5 | Track Browser | public | 2016-07-08 03:43 | 2020-07-12 11:24 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 5.0 | ||||
| Summary | 0013404: Choose Columns configuration doesn't work well | ||||
| Description | The choose columns configuration works in the same manner as MM4 but it is really not very friendly because: a) it forces a multi-step process for i) enabling columns ii) dragging columns to the correct location b) step aii isn't user friendly in the sense that dragging columns is a multi-step process since users can only drag columns to other columns that are _visible_. e.g. for columns a,b,c,d,e,f,g,h,i,j,k,l,m in which columns a-e are visible; if the user wants to drag m to b, he must first drag m to h, then do another drag operation from h to d, and then a third drag and drop operation from d to b. If we fix b, the most painful aspect of this will be solved. Alternatively, we could have a config panel in which users can select fields between two panels and re-order them. Note: this isn't a regression from MMW4, but it's still a rather painful/outmoded process. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2092 | ||||
|
|
While I can't reproduce b) (listview just scrolls when I drag an item near to a boundary and so I can d&d it anywhere), I agree that a 2 column implementation would be more user friendly, particularly re. reordering of visible columns. Assigning to Michal to implement sometimes, not critical for the first release. |
|
|
Already fixed by different Choose columns dialog. |
|
|
Tested build 2066 and there seems to be a regression: 1) Column order cannot be changed in either the list view or in the choose columns dialog. 2) After a field has been added a context menu entry "Hide column 'FieldName'" appears. I don't understand the purpose of this since the column can just as easily be removed by unchecking the field. |
|
|
1) caused by Petr's commit, assigning to him to fix it 2) this entry is just speedup, user does not need to search for clicked column name (it could be somewhere in other submenu) |
|
|
Fixed item 1 |
|
|
Re. item 2) from my perspective, it's unnecessary clutter. Do you remember if we specced this out for a reason? |
|
|
rusty: it is taken from MMW4, we have "Hide this column" there, I only added column name for better orientation in MM5. |
|
|
And this is the original issue for this: 0003189 |
|
|
Given that we're moving to a 'chooser' based UI, I think that we can get rid of some of the extra stuff from the past. I would suggest: 1) Remove 'Hide column x' 2) Remove 'Classification and custom' 3) Remove 'Others' 4) In the list of fields that appear upon right clicking, there should be clearer logic re. why fields appear there. e.g. why does 'channels' show up there? I would suggest to just show fields that are recently enabled so that it's easy to disable/re-enable them. 5) The Chooser dialog doesn't look great with the alternating light/dark bands. This may be a skinning issue as the problem occurs in numerous dialogs. |
|
|
1) Seems to be quite useful in order to quickly hide one column, I'd rather leave it there. 2&3) The idea here was to be able to present _all_ the available fields, while making them easy to find, particularly the most often used ones. Maybe it isn't _that_ important here since we added the Column Chooser, but we should refine this feature anyway and use it thorough the MM UI (like chooser for fields in queries). 4) It is supposed to show the most often needed, possibly with a mix of MRU. Channels are probably unnecessary. 5) It's a skinning issue, we probably should keep the banding for the main tracklist only and remove it in other listviews. 6) Column Chooser dialog doesn't save its position. 7) It's a bit hard to find a particular field in the Column Chooser dialog. We might consider an implementation similar to 2&3, i.e. grouping of fields, particularly the most important ones and/or add incremental search by typing the first letters of the requested field. |
|
|
1) If we leave it then it needs to be fixed. ATM it seems to be random which column it lists. i.e. Enable 'Channels' then it causes "Remove 'Rating'" to appear. Also, it doesn't seem to be integrated with the "Choose columns' dialog. In truth, though, I think it's clutter. 2/3/4) Choosing to list commonly used columns in a location doesn't work well because it's not really objective--what is 'common' to one user might not be to another (mm4 had a similar problem with it's field list). I much better like the idea of organising fields by objective categories, though my preference is to implement that in the Field chooser as you proposed in 7) 5) OK, can we fix this skinning issue as part of this bug OR should I open a new issue? 6) Column chooser dialog doesn't save it's position. 7) I completely agree. In fact, I think that once the column chooser is better organized (similar to 2&3 -- or perhaps even more granularly if we want) the contextual menu implementation can be much simplified to just show: Choose columns [ ] Auto column widths ---------------------- [x] Enabled column 1 [x] Enabled column 2 [x] Enabled column 3 ... In terms of more granular organization of fields, here's a possibility: General metadata - Comment - Genre - Producer - Publisher - Rating - Title - Original Title - Year - Original Year Audio metadata - Album - Album Artist - Album Art - Artist(s) - Author - BPM - Composer - Conductor - Grouping - Initial Key - Involved people - Lyricist - Lyrics - Original Artist - Original Lyricist - Podcast - Track # - Disc # - Track volume - Album volume Video metadata - Actor(s) - Director - Episode # - Season # - Parental Rating - Series Title - ?Series? (different from Series title?) Classification - Occasion - Mood - Tempo - Quality Custom - Custom 1 - Custom 2 - Custom 3 - Custom 4 - Custom 5 Properties - Added - Bit depth - Bitrate - Channels - Filesize - File Type - Filename - Framerate - Length - Media - Path - Resolution - Sample rate - Timestamp - Type Play History - Last Played - Played # - Skipped # ?????? (what are these?) - Source - Summary - Scenarist ?not english? 7b) We may also want to adopt a more consistent approach to naming the fields: i) Only capitalize the first word ii) Split 'words' such as Filesize, Framerate, Bitrate 8) Repositioning columns via the 'Choose columns' dialog sometimes fails https://www.screencast.com/t/btEgKsvmX3AH (first bug) 9) Adding/Removing column via 'Choose columns' doesn't refresh the view correctly if the list isn't at the top https://www.screencast.com/t/btEgKsvmX3AH (second bug) |
|
|
1) It always offers to hide the column, where mouse right-click occurred, which works fine to me. Doesn't it for you? 2-4&7) You are right that to find really 'common' fields is hard or impossible, that said I think there are field that are important to most users and also, there are fields that are hardly used. Given that most of our users use MM for audio, I'd say that at least all ID3v1 fields should be readily available (and not hidden in a submenu) + some other fields, like Rating. That's the idea behind the current organization. So, while I agree that the proposed organization is quite good and logical, I'd make at least few changes, namely: a. General Metadata (always expanded, or directly in the root level of the tree structure): add at least: Album, Album Artist, Artists, possibly Track#, Length, consider removal of Comment, Producer, Publisher, Original Title, Original Year b. The rest looks more or less good - with just some changes possibly needed caused by changes in a. c. Consider a new column Disc# + Track#, so that 2 separate columns aren't needed? (A bit off-topic) 5) I fixed it. Assigning the rest to Michal, Rusty please comment re. the issues above. |
|
|
Reminder sent to: rusty |
|
|
Re. 1) Here's a screencast illustrating what I meant about the functionality not working: https://www.screencast.com/t/2XA50jCyaVGH Re. 2-4&7) Field configuration is something that's generally done once, so I don't think it's a big deal if the user has to go 1 menu deep to configure which fields to display, especially if it leads to a cleaner experience. Re. the proposed organization: a) General metadata: i) I was assuming that all fields would always be displayed in the selection dialog. The headers are just there to facilitate organization. ii) Re. which fields to display: I agree that Producer, Publisher, Original title, Original Year aren't the most common fields. I was trying to get to an organization that separates Music, Video, and Common metadata. The challenge is that: - Comment, Producer, Publisher, Original Title, Original Year (some of which aren't common) can apply to both video and audio - Artist, Album, Track# (which are all common) apply solely to audio We could modify it to something like the following. The downside is it's not absolutely clear which fields apply to Video and which to Audio, but perhaps it's better. Basic - Album - Album Artist - Album Art - Artist(s) - Comment - Genre - Length - Rating - Title - Track# - Year Audio - Author - BPM - Composer - Conductor - Grouping - Initial Key - Involved people - Lyricist - Lyrics - Original Artist - Original Lyricist - Podcast - Disc # - Track volume - Album volume - Classification -- Occasion -- Mood -- Tempo -- Quality Video - Actor(s) - Director - Episode # - Season # - Parental Rating - Series Title - ?Series? (different from Series title?) Other - Original title - Original year - Producer - Publisher Custom - Custom 1 - Custom 2 - Custom 3 - Custom 4 - Custom 5 Properties - Added - Bit depth - Bitrate - Channels - Filesize - File Type - Filename - Framerate - Length - Media - Path - Resolution - Sample rate - Timestamp - Type Play History - Last Played - Played # - Skipped # ?????? (what are these?) - Source - Summary - Scenarist ?not english? c) Re. Disc# + Track#) I suppose it could be helpful (to conserve space I suppose?). Though that also makes me wonder whether it could be useful to allow users to set a mask (e.g. Artist/Composer). On the other hand I can see such features causing some difficulty in the sense that it would be unclear which field is being edited. |
|
|
Re field names with question marks: Scenarist - will be corrected to Screenwriter and should be placed under Video. Source - seems to be icon of the file source (local drive, cached from cloud, stream from cloud) Summary - metadata in summary format, defined in playback rules Series, Series Title - seems to be bug, there will be only Series (meaning Series title). |
|
|
I have found out, that originally, Series Title was probably meant to be "Series title/Episode title", i.e. both titles concatenated with slash. Probably no need for this I think? |
|
|
New column hierarchy implemented in build 2076. Now we also support any nesting in this (like Classification submenu). This hierarchy could be easily changed e.g. by simple script (by changing definition of TrackListView.prototype.fieldGroups). |
|
|
And note, one field could be in more than one place in hierarchy. So e.g. Comment could be in both - Audio and Video submenus. |
|
|
1) Seems to still be a misunderstanding. The field shown there isn't the last enabled/disabled, it's the one where mouse right-clicked in the LV header. I.e. in order to get rid of some visible columns of a listview, just do steps like: Move mouse over 'Genre' column header, right-click, click 'Hide 'Genre'', then move move over 'Rating' column header, right-click, click 'Hide 'Rating''. 2-4) Note that while the column customization is mostly a one-time action, there are various other places where I'd like to use the very same hierarchy, where fields are accessed more frequently, like e.g. filtering, advanced search, auto-playlists, etc.That's why I think it's important to have fields like Rating or Genre very easily accessible, not hidden in the hierarchy, but rather in the top level. An option would be to show both MRU and Basic fields in the top level (and other fields deeper in the hierarchy), or possibly for better consistency, to show only ~15 MRU fields in the top level and pre-populate the MRU list with all the Basic fields (i.e. that they could bubble out of this list, when other fields are frequently used). I like the idea of having a field in multiple categories (where it makes sense). Generally speaking the current version looks good, there are just few minor issues, like that Track # is in Basic and Disc # in Audio, which individually is good, but together looks a bit strange. This possibly could be resolved by getting rid of the Basic section altogether and implementing MRU as described above. Note that we probably should unite all the places where fields are used to use the new hierarchy as part of this issue. That would include all the places listed above + the Column Browser dialog itself (which currently has only the whole list sorted alphabetically). |
|
|
1) Re. 'hide column' functionality: ahh...now I understand (though I'm not sure if users will) 2) Re. Series Title/Episode Title: I don't think there's a need (though I'm not sure why this was introduced in the first place--there may be a reason I'm unaware of). Re the hierarchy, since "one field could be in more than one place in the hierarchy", that would solve the organizational problems--provided that the UI makes it clear when a field is common to Audio and Video. Thus if we replace Basic with 'recently used' and duplicate fields across both Audio and Video we'd have: Recently used - Album - Album Artist - Album Art - Artist(s) - Comment - Genre - Length - Rating - Source - Title - Track# - Year Audio - Album - Album Artist - Album Art - Artist(s) - Author - BPM - Comment - Composer - Conductor - Genre - Grouping - Initial Key - Involved people - Lyricist - Lyrics - Original Artist - Original Lyricist - Original title - Original year - Producer - Publisher - Podcast - Rating - Track# - Disc # - Title - Track volume - Album volume - Year - Classification -- Occasion -- Mood -- Tempo -- Quality Video - Actor(s) - Director - Comment - Episode # - Season # - Genre - Original title - Original year - Producer - Publisher - Parental Rating - Rating - Series - Screenwriter - Title - Year Custom - Custom 1 - Custom 2 - Custom 3 - Custom 4 - Custom 5 - Summary Properties - Added - Bit depth - Bitrate - Channels - Filesize - File Type - Filename - Framerate - Length - Media - Path - Resolution - Sample rate - Source - Timestamp - Type Play History - Last Played - Played # - Skipped # And yes--we could use this organization elsewhere (e.g. column browser) as well. |
|
|
2) it was copied from MM4 (but in MM5 it was buggy and not working). "Recently used" category is filled automatically, based on.. eh.. what user recently used :-) I.e. every user could have here his/her own last used fields. |
|
|
Looks good, just for the reasons described above, I'd just like to not have 'Recently used' fields hidden in a submenu, but rather directly accessible, i.e. something like: ***Recently used*** {centered, italic?} Field1 Field2 ------ ***All fields*** {centered, italic?, not needed here, but looks good imho} Audio> Video> Custom> ... |
|
|
Last version implemented in build 2076 (for tracklists). |
|
|
The same hierarchy implemented for column browser in build 2090. |
|
|
The same hierarchy used for masks in build 2091. Resolving. |
|
|
Verified 2091 |
|
|
Re-opened: These QUnit test fail constantly: TTestMasks.TestMaskDiscNumber TTestMasks.TestMaskTrackNumber It no longer takes <Disc#> as mask, only <Disc #> is valid now, I guess this isn't intentional ? |
|
|
Tests fixed, it was intended change, unification, all fields with "#" now contain space before #. |
|
|
Verified 2260 Tested with all # fields using ' #' instead of just '#' |
