Lazy Search Ideas

[hickinbottoms]

My Jive remote turned up today - very nice indeed from the small amount of time I've spent with it so far. I'll post separately if I have any impressions that haven't been amply covered by others here before.

I've been starting to think about something like a Lazy Search interface for it over the last few days and have an initial idea documented here:

http://www.hickinbottom.com/jive-lazy-search-idea-1

As you can see from that mockup (which I've also attached to this post), I'm thinking about two widgets - a wheel in the top portion and a scrolly menu list in the bottom portion.

Now, I've some initial questions as to how to go about this:


For that 'custom control' at the top, will I have to write that as a C widget and get that compiled into the Jive UI code (in /src/pkg/jive/src/ui), or can it be provided by a custom applet? If it has to be C, can that also be separately packaged with the applet or does it really need the Jive platform to be rebuilt?
Can the existing Jive menu control be made to sit at the bottom in this manner, being refreshed as the search is entered, and then activated when the top control wants to, or would I have to implement that as a custom control also?


An alternative to that custom control being implemented in C would be for the applet to be all Lua. Would that create a UI slick enough for this kind of thing? I've been looking at the Invaders and Snake samples and they look pretty slick, but I'd really like the applet to fit in style-wise with the standard menus and controls if possible.

I can probably work this out for myself eventually, but true to form I'm just being "lazy"... Whilst they might seem like quite specific questions for my needs I think what I'm really wanting to know is how applets can go about extending the user interface and how such applets could be usefully packaged for end-users, which are relevant beta topics.

Stuart

[cliveb]

First of all, let me just say that I'm an enthusiastic user of Lazy Search on the standard remote, and you have my admiration and thanks for making it available. But (you knew there was going to be a but!)....

I'm not sure that your proposed interface for Jive would really be that usable. It seems to me that the rationale behind Lazy Search was to minimise the number of button presses required to get to a particular artist/album/song. Meanwhile on Jive, the major barrier to quickly arriving at your desired selection is not button presses but the amount of scrolling required, simply because long lists are laborious to scroll through.

I'd have thought the simplest way around this would be to have the option of a two-level list, the first being a simple alphabet from which you select the initial letter, which then dives into a list of artists/albums/etc with that starting letter.

For example:
1. My Music -> Artists -> hit 'go' button (what is that centre button called?): displays a scrollable alphabet
2. Scroll to a letter -> hit 'go' button: displays list of artists beginning with that letter. This list is much shorter and can therefore be scrolled quickly.
(NB: No need for custom widgets in this scenario).

If you can get access to one, check out a Rio Karma DAP to get a better idea of how this works.

(Might this approach also reduce the amount of WiFi traffic required between Jive and SlimServer when building the scroll lists?)

[hickinbottoms]

I agree that it's certainly not ideal. I think your proposal has the
following issues, though:

1. You've got to select that initial letter from the full list of the
alphabet (plus all numbers - remember some titles start with
numbers). With the current letter select widget that in itself is
many revolutions of the wheel in my experience.
2. This will be narrowing the search based on the initial letter of
the search title. That's not always what I want to do as sometimes
it's better to search for a later word as it's 'rarer' in your
collection (eg I'd search for "Floyd" rather than "Pink" if I
wanted a bit of prog, for example).

I'm kind of hoping that the scroll events are sufficiently high
resolution to allow me to rotate the wheel in the display in step with
the actual scroll wheel. I think that would mean that the amount of
scrolling is very much less - given that about three characters are
enough to narrow the search in my experience that would be at most three
half-revolutions and two button pushes. I suspect that using a two-level
approach just selecting that first character would be much more than
that on its own.

I'll continue having a think about this, though. I'm not planning on
starting anything for a while yet so there's plenty of time for me to
change my mind!

Stuart

cliveb wrote:
> First of all, let me just say that I'm an enthusiastic user of Lazy
> Search on the standard remote, and you have my admiration and thanks
> for making it available. But (you knew there was going to be a
> but!)....
>
> I'm not sure that your proposed interface for Jive would really be that
> usable. It seems to me that the rationale behind Lazy Search was to
> minimise the number of button presses required to get to a particular
> artist/album/song. Meanwhile on Jive, the major barrier to quickly
> arriving at your desired selection is not button presses but the amount
> of scrolling required, simply because long lists are laborious to scroll
> through.
>
> I'd have thought the simplest way around this would be to have the
> option of a two-level list, the first being a simple alphabet from
> which you select the initial letter, which then dives into a list of
> artists/albums/etc with that starting letter.
>
> For example:
> 1. My Music -> Artists -> hit 'go' button (what is that centre button
> called?): displays a scrollable alphabet
> 2. Scroll to a letter -> hit 'go' button: displays list of artists
> beginning with that letter. This list is much shorter and can therefore
> be scrolled quickly.
> (NB: No need for custom widgets in this scenario).
>
> If you can get access to one, check out a Rio Karma DAP to get a better
> idea of how this works.
>
> (Might this approach also reduce the amount of WiFi traffic required
> between Jive and SlimServer when building the scroll lists?)
>
>
>

[rtitmuss]

For that 'custom control' at the top, will I have to write that as a C widget and get that compiled into the Jive UI code (in /src/pkg/jive/src/ui), or can it be provided by a custom applet? If it has to be C, can that also be separately packaged with the applet or does it really need the Jive platform to be rebuilt?


It should be possible to implement custom widgets in lua. The C code is only needed to optimize the drawing speed. I would suggest prototyping with a lua widget, and then seeing what optimizations are required to run on the hardware. It might be the Jive platform needs optimization to make a lua widget work well, or the widget would need C codes for drawing.

Triode made some modifications to allow applets to include C code for the RetroBrowser. This would need extending to allow the C code to run on multiple platforms, at the moment this applet will only run on the Jive hardware. I have concerns about applets with C code, as they could then cause the remote to crash, etc. We would need to consider how this could be made safe.



Can the existing Jive menu control be made to sit at the bottom in this manner, being refreshed as the search is entered, and then activated when the top control wants to, or would I have to implement that as a custom control also?


Probably. The existing menu is provided by the SlimBrowser applet, and that is already somewhat complex to support incremental list browsing, etc. Some refactoring may be required to allow this to happen.

I have to agree with Clive that this may not be the best interface to use on Jive. I also don't like the two level list idea, although that is something that is being considered. What we will be implementing soon is accelerated scrolling through the menus, and if it works as planned then other solutions may not be needed :).

Richard

[cliveb]

What we will be implementing soon is accelerated scrolling through the menus, and if it works as planned then other solutions may not be needed :)
Like how an iPod works, right? In that case, perhaps it will be all that's required.

There's just one thing that concerns me. The scrolling on an iPod is very responsive, presumably because it's a standalone device and the wheel is hardwired to the OS.

In contrast, the responsiveness of the controls on Jive is currently a little unpredictable, presumably due to the requirement for comms (via a potentially contended network) to SlimServer which in turn is competing for resources on its host PC.

This unpredictability of Jive response is perhaps the biggest niggle for me: one intuitively just expects remote control devices to action things immediately. Obviously I'm hoping that things will improve. Perhaps what's needed is a separate high priority thread in SlimServer for Jive interaction?

[Patrick Dixon]

In contrast, the responsiveness of the controls on Jive is currently a little unpredictable, presumably due to the requirement for comms (via a potentially contended network) to SlimServer which in turn is competing for resources on its host PC.

This is an issue for me too. For example, when browsing by Artists, the wheel is very unresponsive initially (like a slipping clutch), and then behaves OK. I think the priorities of the controls and/or the caching and downloading of data need a bit of work. Maybe the db Artist and Albums lists could be cached locally on JHW start up?

[Patrick Dixon]

I've been starting to think about something like a Lazy Search interface for it over the last few days and have an initial idea documented here:

http://www.hickinbottom.com/jive-lazy-search-idea-1


Sounds pretty good to me - looking forward to trying it out!

[hickinbottoms]

Thanks for the pointers, Richard. I'll take a look at the Lua approach
initially (which is preferable for lots of reasons!).

I certainly agree that allowing third-party compiled code to run within
the remote is problematic, and would need very careful consideration
from a support point of view. I imagine the target audience of the
remote would not want to be aware of such intricacies in the same way
that people who mess around with a SqueezeCenter installation are
prepared to be, and being embedded it's likely to be harder for
end-users to both diagnose and repair problems. One possible mitigation
might be to force such 'extreme' applets to run as another process while
the main Jive interface sleeps, but I'm sure that's likely to introduce
all manner of other pitfalls. Something to think about for when things
are a bit more mature, no doubt.

I'm looking forward to the standard search improvements myself! I'm just
kicking around ideas for now until something feels right and helpful.

Stuart

rtitmuss wrote:
> hickinbottoms;235348 Wrote:
>
>> For that 'custom control' at the top, will I have to write that as a C
>> widget and get that compiled into the Jive UI code (in
>> /src/pkg/jive/src/ui), or can it be provided by a custom applet? If it
>> has to be C, can that also be separately packaged with the applet or
>> does it really need the Jive platform to be rebuilt?
>>
>>
>
> It should be possible to implement custom widgets in lua. The C code is
> only needed to optimize the drawing speed. I would suggest prototyping
> with a lua widget, and then seeing what optimizations are required to
> run on the hardware. It might be the Jive platform needs optimization
> to make a lua widget work well, or the widget would need C codes for
> drawing.
>
> Triode made some modifications to allow applets to include C code for
> the RetroBrowser. This would need extending to allow the C code to run
> on multiple platforms, at the moment this applet will only run on the
> Jive hardware. I have concerns about applets with C code, as they could
> then cause the remote to crash, etc. We would need to consider how this
> could be made safe.
>
> hickinbottoms;235348 Wrote:
>
>> Can the existing Jive menu control be made to sit at the bottom in this
>> manner, being refreshed as the search is entered, and then activated
>> when the top control wants to, or would I have to implement that as a
>> custom control also?
>>
>>
>
> Probably. The existing menu is provided by the SlimBrowser applet, and
> that is already somewhat complex to support incremental list browsing,
> etc. Some refactoring may be required to allow this to happen.
>
> I have to agree with Clive that this may not be the best interface to
> use on Jive. I also don't like the two level list idea, although that
> is something that is being considered. What we will be implementing
> soon is accelerated scrolling through the menus, and if it works as
> planned then other solutions may not be needed :).
>
> Richard
>
>
>

[oreillymj]

The way the iPod works might be difficult to implement with Jive because the Jive's wheel is not touch sensitive AFAIK like a touchpad on a laptop.

In the case of the iPod, the wheel works in 2 modes.

Mode 1) User is moving their finger round the wheel slowly. Move through a list 1 item at a time.

Mode 2) Once the movement around the scroll wheel exceeds a set velocity, change to scrolling 1 letter of the alphabet at a time. Crucially, once in mode 2 the user can slow down again for precision precision, still moving 1 letter of the alphabet at a time. The important piece of this design is that the wheel does not revert back to Mode 1 until the user removes their finger from the wheel. and that is the key to it's usability.

Unless the wheel on the Jive is pressure sensitive,this cannot be implemented with the current h/w. It could be approximated using a time-out. So if the user stops moving the wheel for 3 seconds go back from mode 2 to mode 1, but I think the Apple design it a very clever implementation.


Although Lazysearch is a very efficient method, once you understand what your doing, I don't think it's suitable for the Jive's target market. i.e. Joe Average.

It's not intuitive to change the input method, compared to the rest of the Jive. And inconsistent UI's lead to user confusion and frustration. i.e. Why is this remote now acting like a mobile phone???

[peterw]

I have concerns about applets with C code, as they could then cause the remote to crash, etc. We would need to consider how this could be made safe.

Maybe I've been reading too many Apple vs. iPhone Dev Team stories (and Fake Steve Jobs posts), but how would compiled Jive applets differ from SqueezeCenter plugins? Can't I already include .so/.DLL compiled code in an SC7 plugin? Can't I already write 100% Perl code for SC7 (or 100% Lua code for Jive) that makes a real mess of things? And even bad C code inside Jive should only crash the Jive process, and in the worst case scenario mess up Jive settings. You should be able to use common techniques to respawn Jive if/when it crashes, and to "factory reset" any dedicated hardware like JHB.

...which is to say, I hope you're thinking about how to make it less likely that developers will hang themselves with all the rope they'll have and *not* whether you should try to hide the rope. :-)

[Mark Lanctot]

Unless the wheel on the Jive is pressure sensitive,this cannot be implemented with the current h/w. It could be approximated using a time-out. So if the user stops moving the wheel for 3 seconds go back from mode 2 to mode 1, but I think the Apple design it a very clever implementation.

And no doubt patented.

[oreillymj]

Yes I'd guess the implementation of a scroll wheel using touch sensitive material is patented.

Regualar mechanical "jog" wheels have been present on A/V devices for a log time. Mainly for use on video recorders.

Which is why Sandisk have been able to implement a scroll wheel on some of their Sansa players without getting sued.

[peterw]

The text input on Jive (circa r714) is nicer than I expected. It's clearly better for things like the Music Source setting's IP address entry, where the scrolling column has only 10 items (and that could be smarter; if it's all dotted quad IPv4, you only need 3 items in the first column, and the 2nd and 3rd might be abbreviated, etc. -- still, entering an IP is much nicer than entering a WPA key). I don't (yet) like it quite as much as the iPod Video firmware, though it makes more sense -- a uniform presentation that's independent of the number of characters that can be selected. It's *much* nicer than the standard Rockbox text entry with an iPod clickwheel. If this text chooser UI is of Slim/Logitech's own design, I think you should be proud.

Anyhow, while I'm not a Lazy Search user, I don't see why Lazy Search for Jive shouldn't combine the JHB approach with normal "telephone" keypad mappings. Have 10 items in the column -- "1", "2ABC", "3DEF", "4GHI", etc. With an average of 4 letter/number chars per slot, it should be much faster to pick lazy combos than to select from 36+ unique characters. I'd suggest a hybrid vertical/horizontal layout. In the scrolling column, use horizontal groupings, e.g.

1
2ABC
3DEF
4GHI

but in the selected text to the left of the current position, use a vertical grouping. So when choosing the "k" in "dark" as in Dark Side of the Moon, the display would look something like


8TUV
3 2 7 9WXYZ
D A P 0
E B Q 1
F C R 2ABC
S 3DEF
4GHI

The user would scroll down to 5JKL and then press Go twice to run the search.

Something like this could be used for general text input on JHB -- a "two axis" text selection model. Start with a scroll list like that described above:

1
2ABC
3DEF
4GHI

Initially, the user would scroll the wheel to move the list vertically behind the selection window (as now), to choose a "group" of characters, e.g. "3DEF". In this mode, the UI might show up/down arrow icons. Once the group was selected, the user would press the center Go button. The selection mode would then shift to a horizontal mode. Left/right arrows might appear onscreen, and a selection box would surround the "3" in "3DEF". Scrolling would be interpreted as left/right within the "3DEF" group. Once the single-character selection box was on the proper individual character, the user would press center/Go again to accept the character. Worst case for selecting among A-Z and 0-9 would be scroll down 5 rows, click go, scroll over 2 columns, click go -- versus scrolling 18 rows and clicking go once in the current Jive/JHB model.

[2eleven]

The way the iPod works might be difficult to implement with Jive because the Jive's wheel is not touch sensitive AFAIK like a touchpad on a laptop.

In the case of the iPod, the wheel works in 2 modes.

Mode 1) User is moving their finger round the wheel slowly. Move through a list 1 item at a time.

Mode 2) Once the movement around the scroll wheel exceeds a set velocity, change to scrolling 1 letter of the alphabet at a time. Crucially, once in mode 2 the user can slow down again for precision precision, still moving 1 letter of the alphabet at a time. The important piece of this design is that the wheel does not revert back to Mode 1 until the user removes their finger from the wheel. and that is the key to it's usability.

Unless the wheel on the Jive is pressure sensitive,this cannot be implemented with the current h/w. It could be approximated using a time-out. So if the user stops moving the wheel for 3 seconds go back from mode 2 to mode 1, but I think the Apple design it a very clever implementation.


I think much of the usability can be maintained without requiring Apple's patented design if we eliminate the acceleration/deceleration of Mode 2. Scroll the alphabet at a fixed rate (there are only 26 letters - we can pick an appropriate rate for them to roll by). Let a deceleration of the wheel revert it back to Mode 1. I think this would still be quite usable (not as slick as the ipod, but I doubt Steve would be quick to license that patent).

John