0006579: UI Simplification: Remove 'Views' from Collections Options - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0006579	MMW v4	Main Panel	public	2010-10-21 22:21	2011-05-27 00:03

Reporter	rusty	Assigned To
Priority	immediate	Severity	feature	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	4.0
Target Version	4.0	Fixed in Version	4.0

Summary	0006579: UI Simplification: Remove 'Views' from Collections Options
Description	The concept of Views in the Collection Options UI is confusing in the sense that: a) it's views are all named with Content Types that are near identical to Collection Names AND near identical to Content Types described in the Playback Rules configuration. b) the terminology is the same as 'Views' that are used in the main UI (Details, Art, Art & Details, Art Browser & Details) To simplify this, we should get rid of 'Views' from the UI entirely. Two approaches were discussed: i) Retain the overall structure of the current Collections dialog, but assign a 'Content Type' for each Collection (instead of a View), and define display settings for the 'Content Types'. This was rejected because it could be confusing to set a collection to multiple Content Types, and choose display options based on a single Content Type. ii) Define display settings for each 'Collection' and allow sharing of settings between Collections. For settings that are not yet configurable (e.g. custom headers, or custom grouping/sorting), either enable configuration for those items, or hardcode configuration based on Content Type (determined automatically). The second option seems simpler (simpler UI, less to configure for the user). Each Collection would persist the following, and include a UI only for the items indicated: which tree nodes are displayed (ui), which columns are displayed for the details View (ui), how columns are sorted per View, how content is grouped per View, what View is used, column browser settings per View, Each Collection would NOT determine the following which are defined per Track based on content Type: Display properties in the Properties dialog, Playback Rules, Sync mechanism, Summary format. This would involve the following UI changes: 1) Remove 'View' and associated entry / edit button from the Collections Options dialog 2) Move the Tree Nodes and Columns tabs from the 'View Edit' dialog to the Collections Options dialog 3) Add a facility to share Collections settings between different collections by adding the following row to the Collections Options dialog: Share settings with: _Music, Music Video_______________________^ Note: If the user clicks the dropdown, they would have the option of Checking, Unchecking the list of other Collections. 4) There are a couple of complications that would require some additional changes: i) Different Content Types use different headers for metadata, even if the Metadata is referring to the same field (e.g. Music:Album = TV:Series). To get around this, the list of headers will have to be modified so that ALL headers can be enabled/disabled, including those that have different names referring to the same field. ii) Different content Types require different sorting/grouping logic in AA/AA+details views (e.g. Art + Details view for Video/TV: Same as details view except modified with 2 columns (Artwork, Series/Title), Sort by Series/Title (which means sort by Season then Title, but if a season doesn't exist, only sort by Title).) This means that either: . - Grouping will have to be configurable . - Grouping will be hardcoded based on automatic determination of the content Type Requirements for grouping are described in 0006575, and the best approach is left up for discussion. iii) Display settings for Playlists are currently based on View. This will have to be changed so that it's based on Collection. See bug 0006509
Additional Information	Note: this will require changes to the spec for bug 0006575, 0006571,
Tags	No tags attached.

Fixed in build	1325

jiri 2010-10-21 23:16 administrator ~0020900	While visually this is clear - we are getting rid of Views configuration - internally, it's a little different. I think that internally Views should remain as they currently are (i.e. no changes to other parts of MM code), but they just remain hidden from the user. I.e. after a change to Share settings is later confirmed by pressing OK, Views have to be updated - Collections removed from sharing get a new View, newly added Collections get the same View as the edited Collection. Orphaned Views should be deleted then.

jiri 2010-10-25 19:12 administrator ~0020977	As discussed with Petr over IM, 3) will be implemented without a dropdown, but using a button and an external dialog. While user's experience will be pretty much the same, it will be much easier to implement, manage and be ready for future cross-platform versions. That said, it can certainly be improved in the future, based on used visual components.

rusty 2010-10-26 21:42 administrator ~0020995 Last edited: 2010-10-26 21:43	Below are a few more notes/requirements that need to be satisfied by the Collections settings mechanisms based on discussions with Rusty/Jiri: In AA view: 1. Headers would be hardcoded based on the Collection Type (including a set of headers to be used when the collection contains > 1 content Type. They should be adjusted automatically in response to the file Types in the Collection, which is best accomplished by allowing the user to choose Type(s) for each collection (e.g. 'Contains Content Types: __Types___' (note: Type would be removed from Criteria selection dialog, also we'd need to define what to display for 'mixed' Types content). 2. Header sorting defaults are based on the Content Type(s) in the collection. They are changed by clicking headers, and persist per Collection/View (as sorting always does). The UI defaults should be based on whatever Type(s) are chosen (but persist based on the Collection/View). 3a. Stacking is required for some content Types (e.g. Tracks in a Music Album need to be stacked under a single AA image), but not for others (e.g. Movies and TV shows shouldn't be stacked in AA view because the view doesn't give feedback re. the number of Files in a 'Stack' and because double-clicking a 'Stack' serves no purpose--i.e. users almost always want to play a specific episode in a series rather the entire series). At the moment, we think that Stacking is mainly required for Music, so it could be configured using a 'Stack files by' --> [Album, Series] setting--the user could just enable a checkbox to enable stacking. Like all other such settings, this would Persist per Collection/View (and would be enabled by default only for Collections where Type=Music, Classical Music, ). Whether this really needs to be configurable, though, is debatable. NOTE: The above proposal is a compromise due to time. A better solution would be to enable stacking for ALL content Types, by: i) providing a visual indicator re. the number of files respresented in a stack and ii) providing a means to access individual files in the stack (e.g. Double-click --> popup showing the image + all tracks OR Double-click opens the Album in AA+Details view). 3b. Grouping is benefical (though not critical) for all content Types. In all cases, grouping can be based on the primary Sort (as is currently the case). 4. For the Text shown below each image: When tracks aren't stacked, it makes sense to use the two line description. When tracks are stacked, we can use ??? (this is covered in 0006571). AA + Details View: 5. In MM3 the View is 'special' in the sense that it's based on the details view settings, except that it replaces two columns with two others. In MM4, for simplicity, it will simply be another view that the user manually configures with whatever columns he/she wishes to enable. i.e. details view and AA+Details view can be identical if the user configures it that way. Additional columns that will be required to support various content types are: TV & Video: Series/Title, Podcast: Podcast/Artist. These would be enabled by default for Collections based on their respective content types. 6. Sorting. Same as 2. 7a. Stacking is beneficial for ALL content Types in AA+Details View. Same UI as 3a would be used to enable stacking. b. Grouping: same as 3b (as with current implementation) In details view: 8) All fields would be listed including those that are identical to other fields but have a unique name 9) We could even list special fields such as 'Art' or 'Artist/Album' that are currently used only in the AA view (so the Details view and AA+Details view are identical in functionality--the only difference would be in their defaults) 10) To change Collection defaults: User creates a new Collection, it doesn't have any Type assigned yet, then some Type is checked by user and MM adopts the default columns, etc.? If the user changes the Type subsequently, then MM can popup a dialog along the lines of "Do you wish to optimize columns, sorting, and grouping for '<content Type>'?".

rusty 2010-11-09 18:54 administrator ~0021277	Tree nodes: 11) The Collections configuration's 'Tree nodes' tab should allow the user to enable/disable all fields (including those that are identical to other fields, but have a unique name).

petr 2010-11-12 22:37 developer ~0021330	Implemented in 1325

peke 2011-05-27 00:03 developer ~0025671	Verified 1380