Bug 13519 - Define search button behavior (IR remote) for Squeezeplay devices
: Define search button behavior (IR remote) for Squeezeplay devices
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: UI
: unspecified
: PC Other
: P1 normal (vote)
: 7.5.0
Assigned To: Andy Grundman
:
Depends on:
Blocks: 14879
  Show dependency treegraph
 
Reported: 2009-08-19 19:49 UTC by Mark Miksis
Modified: 2010-04-08 17:26 UTC (History)
5 users (show)

See Also:
Category: Feature


Attachments
Search flow proposals (271.95 KB, image/png)
2009-11-20 15:06 UTC, Weldon Matt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Miksis 2009-08-19 19:49:56 UTC
If I have one or more Music Services plus a local library, I'd like to be able do a single search that displays the results from all available sources.  This would apply to all UIs.
Comment 1 James Richardson 2009-08-20 10:28:47 UTC
Patches Welcome :)
Comment 2 Weldon Matt 2009-10-06 10:02:01 UTC
I'm hijacking this bug, since something like this is planned for fab4 (since it has a global search button).

Having said that, it might not be a true "live" search, need to do some research.
Comment 3 Weldon Matt 2009-10-16 10:28:55 UTC
The Fab4 remote has a dedicated "search" button, and there is a growing need in our products for a more "unified" search interface. 

Stay tuned for details.  Feature spec placeholder page is on the embargo wiki:

http://embargo.wiki.slimdevices.com/index.php/Squeezeplay_Search
Comment 4 Weldon Matt 2009-11-12 10:35:25 UTC
We've narrowed down to 2 basic options, to be discussed Monday with Andy.

Both options include a "search" menu option on the home menu.  Selecting the "search" item or pressing the "search" button on the remote will trigger one of the following 2 flows:

- option 1 (preferred): user presses "search;" user enters search term in a text entry screen.  After entering search term, user can choose options from a list of possibilities - the list is dynamically generated based on what apps the user has installed.  ("Search My Music for 'Snoop Dogg';" "Create Pandora station for 'Snoop Dogg," etc)

- option 2: user presses "search;" user can then choose options from a list of possibilities - the list is dynamically generated based on what apps the user has installed.  ("Search "My Music," "Search Napster," etc).

In either case I will need to come up with the list of potential "search" items (some may be less than obvious).  Some of the "search" options may actually be other cases where a string is entered (creating a Pandora station etc).
Comment 5 Weldon Matt 2009-11-17 14:20:12 UTC
defined basic flow with Andy.  Last task is to put together proper strings for screens in the flow.
Comment 6 Weldon Matt 2009-11-20 15:06:41 UTC
Created attachment 6333 [details]
Search flow proposals

Current direction is to use option 2.

Please leave submenus for search same as current within apps...
Comment 7 Michael Herger 2009-12-01 03:08:30 UTC
I consider this design part of the search button behaviour done. Implementation is tracked in bug 14879.
Comment 8 Chris Owens 2010-04-08 17:26:32 UTC
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!