You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Item readability could be greatly improved so that users know instantly what type of item they are looking, whether it is a track, an album, an artist or a playlist.
1. Change the default track cover art to a music note so it doesn't look like the album default cover art
2. Change default artist visual to circle-shaped art
3. Remove genre art, list them like tags
Problem solved
In general: not knowing exactly which type of item we're looking at. For example, when using the global search bar, all the items are listed together (to be fair, in their own category). See screenshot below:
Otherwise, when switching tabs between albums, artists, playlists etc… you're looking at the list, not the tab names above. Although a quick look suffices, it's still needed sometimes. There is text accompanying each listed item that allows you to infer which category of item they belong in, but it's not explicit.
More specifically, and for each point i mentionned:
When browsing tracks and albums without covers, both have the same default cover art. The size difference between the two helps, as well as the categorization, but it's not sufficient to know it from the first look.
Allows to easily discriminate between albums and artists, for artists who have an eponymous album, or a similar/duplicate art for both album and artist category. In addition, circle-shaped art for artists is quite standard as seen in "Other implementations" below.
Associating an image with a genre can be pretty misleading, and as your music folder gets larger and better tagged, it fuels your genres list with more niche or combined genres that are in turns associated with only a few covers, repeated in all your search list. Removing covers kills two birds with one stone: avoid that problem entirely, and differentiate genres from other items… with the added benefit of making a list of genres more compact.
Other implementations
Deezer (top to bottom: artists, titles, albums):
Spotify (artists albums and tracks mixed in search results):
Symphony player (used to do this in previous versiwns, doesn't do it anymore):
Benefit and shortcomings
It will further help users navigate the app, recognize the tab they are browsing, and recognize which items are which among each other without relying on in-app context. It will greatly help navigate search resluts as it will provide visual cues as to what they're looking at.
I don't have a fitting solution for playlist, but i figured the current implementation was good enough as playlists essentially work like user-created albums. Users can be expected to recognize their own playlists among other albums… although this may not be true for imported playlists and such.
I understand these changes may be quite hard to implement, for small sensible result to most current users, but it will definitely help people who are accustomed to online services such as Spotify which already do this kind of differenciation.
Duplicates
I have checked this feature request for duplicates.
I have checked that this feature is not implemented in the lastest version.
I have checked the Why Are These Features Missing? page.
I agree to the Contribution Guidelines.
The text was updated successfully, but these errors were encountered:
Genre: A cluster of various album artworks (IIRC google photos does something like this)
Good idea, but it wouldn't work around the problem i pointed to : "as your music folder gets larger and better tagged, it fuels your genres list with more niche or combined genres that are in turns associated with only a few covers".
For playlists though, that would be quite good !
"as your music folder gets larger and better tagged, it fuels your genres list with more niche or combined genres that are in turns associated with only a few covers".
For playlists though, that would be quite good !
My hope is that a genre's "cluster" would have an arrangement seeded from it's cover composition, so two genres with small cover samples will still have different clusters. Either way, I'll take in your ideas.
Description
Item readability could be greatly improved so that users know instantly what type of item they are looking, whether it is a track, an album, an artist or a playlist.
Problem solved
In general: not knowing exactly which type of item we're looking at. For example, when using the global search bar, all the items are listed together (to be fair, in their own category). See screenshot below:
Otherwise, when switching tabs between albums, artists, playlists etc… you're looking at the list, not the tab names above. Although a quick look suffices, it's still needed sometimes. There is text accompanying each listed item that allows you to infer which category of item they belong in, but it's not explicit.
More specifically, and for each point i mentionned:
Other implementations
Deezer (top to bottom: artists, titles, albums):
Spotify (artists albums and tracks mixed in search results):
Symphony player (used to do this in previous versiwns, doesn't do it anymore):
Benefit and shortcomings
It will further help users navigate the app, recognize the tab they are browsing, and recognize which items are which among each other without relying on in-app context. It will greatly help navigate search resluts as it will provide visual cues as to what they're looking at.
I don't have a fitting solution for playlist, but i figured the current implementation was good enough as playlists essentially work like user-created albums. Users can be expected to recognize their own playlists among other albums… although this may not be true for imported playlists and such.
I understand these changes may be quite hard to implement, for small sensible result to most current users, but it will definitely help people who are accustomed to online services such as Spotify which already do this kind of differenciation.
Duplicates
The text was updated successfully, but these errors were encountered: