View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014457 | MMW 5 | General | public | 2017-10-12 07:34 | 2020-10-25 13:46 |
| Reporter | jiri | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0014457: Tabs naming | ||||
| Description | Per http://forum.mediamonkey.com/viewtopic.php?f=30&t=88539#p439984: In MM4, tab labels used to show the collection name ... now they show just the collection sub-node name ... ie. for Music>Albums, the tab label is just Albums ... not Music .... the change is not very good for Gold customers, who mad have custom collections. It's definitely hard to find a naming scheme that fits everyone, but there probably are things that can be improved. I'd keep the current implementation, just: 1. one-level-sub-collection nodes, i.e. All tracks, Albums, Artists, ... could probably rather show the corresponding icon, but instead of node title, there would be the collection name, which seems to be more useful. So, we'd change tab titles from -> to: a. [track icon] All tracks -> [track icon] Music {or another collection name} b. [album icon] Albums -> [album icon] Music etc. I'd leave lower tree level nodes implemented as they currently are. Also other nodes outside of collections look good. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2084 | ||||
|
|
I think that inverting the labeling isn't really necessary. A simpler solution would be to show first and second level information as you suggested, but as follows: a. [track icon] All tracks -> [Collection icon] All tracks b. [album icon] Albums -> [Collection icon] Albums The only change that this would require is that collections would require unique icons. i.e. new icons for Classical, Music Video. The one aspect of this proposal that I'm not happy about is that for some content (e.g. PlaylistName, AudioBookName, MovieName) users may want to leave the tab open so that they can get back to editing/listening to the content. e.g. they'd want to see: [Playlist icon] PlalistName [Audiobook icon] [Album icon] AudiobookName [Video icon] [Series icon] SeriesName I'm not sure if this approach is realistic or not... |
|
|
I'm confused about the second part, why would there be 2 icons needed? And what's specific about these use-cases? |
|
|
Re. the second part: Playlists are different because if the user has a playlist open in a tab, it's likely that they'd want to identify the tab by the playlist. As to Audiobooks / Video - they're not much different than regular Music albums, except that both of them are listened to / watched for multiple hours vs a single hour for an album. In other words, for all of the above content, the user may have > 1 Playlist, Video, Audiobook tab opened. As to the logic of using 2 icons, I was thinking that this could communicate both the 'Collection' and the 'Attribute'. e.g. AudioBook icon > Album Icon > AudiobookName. But on second thought, that might be confusing and it may be simpler to just show: Collection icon > AudioBookName Collection icon > AlbumName Playlist icon > PlaylistName |
|
|
re. Playlists - ok, but they are already implemented this way, aren't they? I.e. no change needed. re. Collection icon for some items - I'd prefer to keep the icon of them item and not include the collection icon, as I don't think it's too important. So, let's rather make the originally proposed change only (use Collection icon for the first-level sub-collection nodes) and decide later whether anything else is needed. |
|
|
Fixed in 2084. |
|
|
Verified 2084 |
|
|
Reminder sent to: rusty Reverified 2264 I would not add anything more implementation from 0014457:0049264 works OK and unified over the UI. Please close if you agree. |
|
|
Revised 2271 Further features and enhancements can be added later as needed. |
