Search redesign
bragefuglseth opened this issue · 11 comments
As discussed in #611, we want to give the search view new functionality and a facelift, making it more usable and beautiful.
The initial suggestions sound good to me! I'm a little unsure about the pinning feature, as you can e.g. easily search for "Beethoven symphony" if you're looking for all symphonies made by Beethoven anyways. Might be something I don't understand properly there, though, so I have created a mockup for that as well 😅
Initial mockup
Compact results
We can also make every result a compact row except for the first one. This would put even more focus on that, and we would avoid things not lining up properly. A weakness of my current proposed design is that the different sizes make the results look a little messy.
I've added a mockup for Compact Results. I think it looks a lot more tidy, and it's more in line with what Spotify does.
For the separator, I used the bullet • character from the Typography design tool.
Thanks for working on this already! It looks good!
I think I am more partial to having consistently sized search result (compact one). Not sure I would be able to provide a top result however (the API gives me results split up by artist/album/tracks/etc, I can't really know which one "scores higher" in relevancy across all categories).
Oh and to give some more insight into what I had in mind for the filtering, here's what the initial search could look like (rough design in Workbench, don't pay attention to the sizes/fonts/spacings etc) :
and upon "pinning" an artist, the results would be refined to include results relevant to that artist, while still allowing the same level of interaction with the artist card (ie you can still browse to the artist if you've filtered the search):
(Oh and technical note: I don't think I'll ever implement that star everywhere in the app, at least not for tracks, as knowing whether something is liked of not requires a lot of requests to the Spotify API)
(the API gives me results split up by artist/album/tracks/etc, I can't really know which one "scores higher" in relevancy across all categories).
Doesn't that make the current mockup hard to implement in general? How will you determine the order to put the results in if they are in one monolithic list? Will you iterate between artists, songs, albums and playlists consistently?
(Oh and technical note: I don't think I'll ever implement that star everywhere in the app, at least not for tracks, as knowing whether something is liked of not requires a lot of requests to the Spotify API)
Ah, ok, makes sense.
I can swap out the star symbol with a pin icon and create a new mockup for filtered search.
How will you determine the order to put the results in if they are in one monolithic list? Will you iterate between artists, songs, albums and playlists consistently?
that's... a good point ahah.
I'll look more closely at the API to see if there's anything that would help. Otherwise I guess the results will appear in a consistent order which might not be so bad.
I can swap out the star symbol with a pin icon and create a new mockup for filtered search.
sure but take your time! I probably won't personally get started on this soon
Here you go! I just swapped the pin button with a search icon. Makes the behavior clearer imo
sure but take your time! I probably won't personally get started on this soon
That's okay! I'm just putting it out here for the future 😁
I have a few questions about this new search:
- Why do we no longer separate artists / songs / albums / playlists? It seems rather useful to me and the Spotify API is seemingly also organized this way.
- Will this also solve the visibility of the search view? E.g. being able to clearly see that it is selected (I see that that is done using the search icon on the left, this seems good).
- Does search work like an overlay over the currently selected tab or is it a view by itself? What I mean is should the previous view remain "selected" in the left bar or not?
- When the app is in a small window (e.g. mobile screen or tiled) we should still be able to cleanly navigate in and out of search (this is not the case on the current flatpak version I believe).
Why do we no longer separate artists / songs / albums / playlists? It seems rather useful to me and the Spotify API is seemingly also organized this way.
I’m not sure about this either. Might have to do another iteration on the design if @xou816 decides that it should follow how the API works.
From a pure design perspective, I think ordering them arbitrarily works better because what people look for is always different, and can’t really be represented in a static order. We can allow filtering (playlists, songs, albums), etc.
One possible way to order the results might be to fetch the play count of songs and albums, and the listeners/month for artists, and stack things this way? Is that possible?
I am not a rust developer, however since there has been no progress on this issue as far as I know, I will give my two cents on this issue.
Thanks to these lines of code, I am fairly certain that @xou816 uses the Spotify Web API (also because src/api/client.rs is an entire file that uses the isahc http client to do network requests to the api.spotify.com endpoint).
In the Spotify Web API reference, /search returns tracks, artists and albums separately. However, each Track, Album and Artist is assigned a popularity integer that is supposed to show how popular each piece of media is, but there's no mention of whether that popularity is only limited to each type of media (i.e. whether an album with a popularity of 80 means that the album is very popular when compared to only other albums or if that's compared to a track as well). I also do not believe that this matters when listing by popularity, because we can just list them by decreasing/increasing popularity.
I am still partial towards listing them separately, because I like the layout of the Spotify webapp search results.