UI suggestion: Place search in header

[doctorjames]

On desktop there is a lot of space in the header. Would it be possible to move the "Search" field from "My Music" to the header? You could even make it collapse to a magnifying glass on mobile if you felt this made it more consistent.

This would make search more discoverable to occasional users (rather than having to scroll down the "My Music" list to bring it on screen) and be functionally similar to many web sites people are familiar with where some form of search is prominently at the top.

Many thanks for breathing new life into the squeezebox with this effort!

[CDrummond]

I do agree that on desktop there is a lot of wasted space in the header. However, where to put search? Really it belongs on the left hand side - as it searches the library which is shown there, and not the queue. But, on the left is the player selection menu. Perhaps in the middle?

I think the following might work:

1. If desktop and width>600(?) pix, then show seach field in middle of header.
2. Otherwise, show a magnifying glass icon (for mobile, only when on browse view). When button is selected whole header turns into a search field, with a close button.
3. Only enable search when at top-level of browse. Otherwise you give the impression that a search from that level on is performed.

Can't always show search in mobile, even if wide, as the details of the currently playing track are shown under the player menu - and this might cause the text to be needlessly truncated.

Does that make sense?

[doctorjames]

Yes, that makes sense and is pretty much what I was imagining.

You make a good point though about the arrangement. Thinking out loud a bit here (and with the caveat I've not really used the mobile view):

1. Do the "track information" and "expand now playing" buttons conceptually belong in the playing controls section as they apply to the currently happening activity?

2. A "track information" button could even also appear on each entry in the queue or in the queued tracks' context menus.

3. The settings menu would make sense moved to the far left.

4. With those buttons moved, the player selection menu (and subtitle on mobile) can move over to the far right and be right aligned. This way the player name will be directly next to its volume control and directly above its current queue.

5. You can then put the search at the top left (to the right of the now-moved settings button) and above the library to be searched.

Would that work?

[CDrummond]

1. Yes, they could be moved there - but not on mobile. I'd like mobile and desktop to be as consistent as possible.
2. No. Tack info is for current track, and can be configured to) change when track changes
3. Again, no. Android apps, chrome, firefox, etc have this three dotted menu on the right
4. Again, no
5. Nope, because of the above

The more I think about this, the more I'm coming round to the opinion that its more hassle than its worth.

[CDrummond]

Can't determine a good place to put this in the main toolbar. In the middle is jsut odd, to the right and its over the queue, on the left either it's location would change (due to player name label) or there would be a varying gap between the player name label and this.

So, in main toolbar is probably a no-go.

However, as a compromise, how about placing this in the sub-toolbar in the browse page? This is the toolbar that has the home and back icons when navigating. At the top-level it is not currently shown. I could have it always shown, and place search there. This would then balance the browse and queue views more. Sound reasonable?

[doctorjames]

Yes, I think that would work.

[CDrummond]

Implemented in 81-search-position branch. But I'm not 100% sure about it.

[doctorjames]

I had a play with it, and while it certainly improves on the discoverability problem, I understand your "not 100%" comment about that location.

There's possibly an even simpler solution: how about forcing the search entry to be top of the "My Music" list rather than at the bottom? That way anyone going to the page will see it without having to know to scroll down, and it makes it clear that it only searches "My Music" and not other things.

[CDrummond]

The location of 'Search' works for me when not using server-side menus. Scrolling is only required when using server menus. But, I think that it should be in the same location with both. So, still not sure. To me search is not the main interface, so I don't want it at the top of the list.

[doctorjames]

With 'Search' back in the list you won't need to force the sub-toolbar to be visible so even placed at the top it should result in roughly the same menu entries being on screen as in 81-search-position.

Anyway this is your decision; I'm just contributing ideas. The issue was prompted by multiple visitors asking how they can search the library, hence it suggested to me that it is a minor usability issue you might like to be aware of.

Personally I keep the server side menus enables as I like to quickly jump to "New Music" when I'm getting to know new albums.

I suppose I often forget to use 'Search' but now playing with it, it is much faster (especially with the material skin) for people using a keyboard with a specific album, artist or song in mind. It also seems useful for collections where the genres are overly divided into sub-genres.

Reorder-able and hide-able menus would be great but more effort than it's worth, however forcing 'Search' to the top of 'My Music' could always be an toggle option.

[CDrummond]

Had a better idea. I've added a search icon to the right of 'My Music' - this produces a dialog allowing the search term to be entered. I've removed the 'Search' entry from the list.

Using a dialog will allow me (in the future) to perhaps add more options - such as onyl searching artists, albums, or tracks, etc.