[Feature Request] Store previous searches and or results

[Qluxzz]

Spotify's search works by when entering a query it shows you the results as expected. But it does not store the search before you click on a media type. If you click on an artist the artist is stored as a previous search, if you click a track the track is stored as a search result and so on.

The simplest way to store previous searches would be to add a new tab to the search tab with "searches" or "previous" as name, and just store the queries.

But I would think that would add up to a lot of noise and I think we should move in the direction to how Spotify currently does it.

If anyone else have any input, please reply!

[Qluxzz]

Example of how the search history looks in the client when searching for Thomas Newman and then clicking an album, the artist, and a track

[mtshrmn]

I would totally like to see my previous searches, but I'm against a new tab. Adding another tab would just make it impossible to use in small resolutions.

Here's my proposal: So basically when you enter the search page or clear query, it would display this screen (top) and you can browse the recent queries. Of course that once you click the query it would just auto fill the search bar and the behavior would be exactly the same. You could go back to that screen by clearing the search bar.

(I hope that this simple mockup I've created in vim will be enough to express my idea)

About what items will be stored in recent searches, I totally agree that it should be the same way Spotify handles this.

[hrkfdn]

@mtshrmn I like the idea. We could just push the search results view (without the edit field) on the stack which can then be closed via Backspace like other views.

[mtshrmn]

To be honest, I'm not very keen on not having the search bar alongside the results. Spotify does this and it always bothered me. But if I'm the odd one out then I'm totally fine with that. Implementing it this way would also solve #219.

[hrkfdn]

Yeah, that was the idea. I don't have any strong opinion on either approach, but I do agree that the search input stealing the focus can be annoying sometimes.

[Evidlo]

I'm a fan of @mtshrmn's idea. In my opinion as soon as the user hits enter they don't need to see the search bar anymore.

That would be option 3 in https://github.com/hrkfdn/ncspot/issues/219

[hrkfdn]

Search and search results are now separated in master. The search view is still sort of empty, but could now be used to show recent search terms. The screens now also retain opened detail views, so if you open an artist in the library or search and jump to the queue, the detail view will still be open when you jump back to the library/search.

[Qluxzz]

Of course that once you click the query it would just auto fill the search bar and the behavior would be exactly the same.

If we want to replicate the behaviour currently in the desktop client selecting an entry from the search results would instantly go to the artist or album instead of auto filling the search bar.

And I would think that is a better behaviour than doing the search twice, if I'm reading the mockup correctly?

[hrkfdn]

Would be nice, though I wonder how feasible this is. When saving a search query, how do we know whether the search was for albums, artists, tracks, ..?

[Qluxzz]

As I mentioned in the beginning no search results are stored before the user has navigated to a type of media.

So if the user interacts with an album, the album would be added as the search result. If the user interacts with an artist the artist would be stored as the search result and so on.

That doesn't seem like it would be so hard to keep track of?