Issues with search

[lightonflux]

Video

spot-bug.mp4

Sidebar indicator wrong/confusing

When searching the search view is displayed out of nowhere. But the indicator on the left in the sidebar still indicates that you are in "Currently playing" or Library.

UI orientation issues

1. focus the search (top middle)
2. the search view slides in from the right, but does not cover the sidebar
3. arrow to go back points left and resides above the sidebar, not the area covered by the search view

If the back button belongs to the search view it should on the left of the area, not above another unrelated area.

Possible fixes:

• cover the sidebar with the search view
• make the search an option in the sidebar

Search only displays album & and filter don't work

Moved to #35.
See video.

The filters should be next to the search input, if the popover is supposed to be a search filter. I can't tell.

Animation disruptive

The slide animation is pretty fast and disruptive. Doesn't feel good.

Maybe slide from the top aka from the search bar.

No keyboard navigation

Issue moved to #32.

Closing/opening search is not possible with the keyboard as far as i know.

Would have expected that Esc and alt+←(go back) work for closing and ctrl+f for opening.

Text field is too short

Moved to #34.

If you are searching for "Lightspeed Champion" it is already too long. The text field should be wider.

Search box compared to other apps:
1: spot
2: lollypop
3: nautilus

[xou816]

Thank you for taking the time to write this all up! (although I'd prefer separate issues :p)

Sidebar indicator wrong/confusing (1)

Agreed! It could use some improvements.

UI orientation issues (2)

The idea was to make search accessible from anywhere, without requiring switching to a dedicated pane. The sidebar needs to remain visible so that you can freely switch back to one of the main views -- this would make more sense once the issue above is fixed. As for the back arrow, it is used for other views as well: try opening an album from your library, then clicking the artist, for instance. Does it make more sense?

Search only displays album & and filter don't work (3)

Not implemented yet :D I should just remove it to avoid confusion until it's implemented! I agree about positioning the filters somewhere else however, good idea!

Animation disruptive (4)

A bit too fast maybe, you're right! As for the direction, the rationale is the following: main views fade over each other (Library, Now Playing), and other views are pushed from the right, and pushed back when using the back arrow.

No keyboard navigation (5)

Absolutely, I should work on that!

Text field is too short (6)

Agreed, that's an easy fix as well!

Again, thank you for your input! Lets discuss a bit more the UX related issues (2, 4) in this issue. Would you mind creating separate issue for the others? It will make it easier to track their progress and would even allow new contributors to jump in.

[xou816]

@lightonflux saw your issues, thank you :)

[lightonflux]

The new issues are linked in the original issue description.

4: Which other element is slided in from the right? Didn't find another one so far.

1: This might be harder than it first seems.
Especially if you want to show the sidebar.
Personally i would suggest a solution like in the android app. If you focus the search field the whole application (apart from the headerbar) shows the last used search terms (or better played results) and when the user searches the view is used to display the current search results. This could be done by a gigantic popover, but i think lollypop did that in the past and removed it for good UX reasons. Or just make the slided in view larger. I don't know anything about the hierarchy of GTK views. So it would be nice if you could give you input.

ScreenRecord-2021-01-25-19-23-34_klein.mp4

Personally i would like it if the search view slided in from above thus connecting it visually to the search field. But as i said a fade in would also be fine. I could create an issue about extending the view over the whole, app, but i don't think thats what you want.

1,2&4 are all linked.

Here a mockup how i would like it to look. (With slide from above.)

As you can see artist results are just in the same list, but differentiated by the circle shape. Oh and the shuffle button could be moved to the control cluster in the middle. Think about users with large screens.

[xou816]

4: pretty much every other screen! To be clear, I mimicked the behavior of mobile apps: the sidebar acts like a typical tab bar on mobile, tapping/clicking a tab will start a navigation from this tab, and every subsequent navigation pushes a screen on top.

So in spot's case:

• click Library, click an album (pushes Album view), click artist (pushes Artist View), hit back, (pops Artist View), hit back (pops Album view), can't go back anymore
• same with Now playing, clicking "View album" will push the Album view on top, etc
• search acts similarly: it pushes the Search view wherever you currently are

The Spotify iOS app behaves similarly, in fact if you open an album from the Search tab, Search is still highlighted, even though you're no longer in the actual search results view.

It might not be the best approach however for a desktop app, I don't know! I suppose Lollypop does not create or delete views as needed but rather keeps them around and keeps a history of visited views, and just updates their content, maybe that's the right way to go.

Since you asked about the hierarchy: there are two stacks, one with the main views (Library+Now playing), and one for pushed screens (all others: Search, Album, Artist) + that initial screen with a stack. If you're curious use the Gtk inspector or look at the window.ui file in Glade :)

1: makes sense on a small screen, and that's something I would do if I get to grips with libhandy! But otherwise I don't see the point of hiding the sidebar (except perhaps to clear up any confusion as to where the user is -- maybe there's a way I can have no active selection in the sidebar as soon a screen is pushed).

I really like the search mockup however, makes sense to merge all result kinds!

[Diegovsky]

This issue is a bit old and we have committed to a new design as per #616. Closing but feel free to re-open if it still applies