Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search redesign #616

Open
bragefuglseth opened this issue Feb 25, 2023 · 11 comments
Open

Search redesign #616

bragefuglseth opened this issue Feb 25, 2023 · 11 comments
Labels
enhancement New feature or request

Comments

@bragefuglseth
Copy link

bragefuglseth commented Feb 25, 2023

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

spot-search-mockup

Compact results

spot-search-mockup-compact

@bragefuglseth
Copy link
Author

bragefuglseth commented Feb 26, 2023

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.

@bragefuglseth
Copy link
Author

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.

@bragefuglseth
Copy link
Author

For the separator, I used the bullet • character from the Typography design tool.

@xou816
Copy link
Owner

xou816 commented Feb 26, 2023

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) :

image

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):

image

(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)

@bragefuglseth
Copy link
Author

(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.

@bragefuglseth
Copy link
Author

I can swap out the star symbol with a pin icon and create a new mockup for filtered search.

@xou816
Copy link
Owner

xou816 commented Feb 26, 2023

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

@xou816 xou816 added the enhancement New feature or request label Feb 26, 2023
@bragefuglseth
Copy link
Author

Here you go! I just swapped the pin button with a search icon. Makes the behavior clearer imo

spot-filtered-search-mockup

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 😁

@knokelmaat
Copy link
Collaborator

I have a few questions about this new search:

  1. 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.
  2. 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).
  3. 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?
  4. 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).

@bragefuglseth
Copy link
Author

bragefuglseth commented Mar 3, 2023

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?

@hegdenischay
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants