ContextMenu: plugin to provide context menus

[peterw]

I've just posted code for a new plugin I call ContextMenu. I've added support for it to two of my SC7 plugins, AllQuiet and PlayLog, but really what I'd like now is feedback from other developers as to what you think & how this could be made more valuable for your code.

The basic idea is to map a key to act like a desktop OS "right click" context menu so users don't have to remember weird key combinations, or worry about what "mode" the player is in. How this works with ContextMenu:
1) Each user edits their map files to map something to ContextMenu -- I've been using arrow_right.hold so that wherever I am (whatever mode the player is in, including Off), holding the right arrow brings up context menus. The zip file includes an SC7 Default.map and a patch file.
2) Plugin developers write a couple new funcions (see ContextMenu/Public.pm for samples & info) to "register" one or more context menu possibilities. Essentially, the plugin provides a GUID for each option and a "pre-offer" coderef.

Each time the user calls up the context menu, ContextMenu executes *all* the registered pre-offer coderefs. This gives each plugin a chance to examine the current situation and determine if its contextual option makes sense. If so, the plugin tells ContextMenu how to label its option, and gives another coderef that should be executed if the user selects (Right Arrow, Play, or Add) the plugin's context option.

For instance, the new ContextMenu code in PlayLog will offer to "Log track info", but only if the Squeezebox has been playing a track for a few seconds and PlayLog hasn't already logged the track info. Otherwise ContextMenu doesn't show any PlayLog option.

Another feature of ContextMenu is intelligent ordering of context menu options. Simply put, the options that have been used most frequently are displayed first. So ContextMenu will "learn" what users choose and reduce the amount of scrolling they have to do.

Out of the box, ContextMenu offers a number of context options -- emulating various Slim Devices IR remote control buttons. This is mostly for demonstration purposes (especially the frequency ordering -- choose the context menu Favorites option two times and the context menu Browse option once, and you'll see how ContextMenu re-orders the list), though I personally find it useful, as I have trouble remember what odd buttons on my universal remote control map to what "Squeezebox" remote control buttons. ;-) In the future, I intend to either move the button code to a separate plugin or at least a submenu of the context menu.

Other things not yet done:
- making a web page describing this & end-user info like the .map files
- updating statistics algorithms (only look at last 1-2 monthes, in case usage patterns change [good idea, Erland!]; also, calculate statistics based on the ratio of Chosen/Offered/WeeksInstalled rather than simply the ratio Chosen/WeeksInstalled)
- menu UI tweaks (use line1 for more info, conditional right arrow overlay)
- Jive/Controller support. Could be tougher since it would probably require Jive software changes & new firmware images.

Here's where you can find it:
http://www.tux.org/~peterw/slim/slim7/ContextMenu/

-Peter

[Philip Meyer]

Sounds great. I'll try it out tonight.

I think this should really become standard SC core code. Also, it's essentially what the mixer (play.hold) does in certain modes, and thus it could change to use this context menu instead?

I'm not sure I will like the intelligent ordering. That may make it harder to find the option in the list. I think I would prefer a fixed order, or maybe only update the order once a day. Maybe the registered context menu options could be in a fixed order, but could be reordered manually in a web ui settings page?

Is it possible to register a hierarchy of context menu options? Eg.

Now Playing ->
Context ->
[name 1] ->
option 1 ->
sub-option 1
option 2 ->
sub-option 2

[erland]

I'm not sure I will like the intelligent ordering. That may make it harder to find the option in the list. I think I would prefer a fixed order, or maybe only update the order once a day. Maybe the registered context menu options could be in a fixed order, but could be reordered manually in a web ui settings page?

I think it should be possible to disable the smart ordering in some settings page. Some users will like it and some won't.
It might also be worth considering similar functionality as the Windows start menu, where the top 6 used items are available in the top menu with smart ordering, but all items is available in a sub menu with fixed ordering.

Is it possible to register a hierarchy of context menu options? Eg.

Now Playing ->
  Context ->
    [name 1] ->
      option 1 ->
        sub-option 1
      option 2 ->
        sub-option 2

You will currently have to implement this by registering the "[name 1]" option from your plugin and let it push the player into a plugin specific mode which shows the other options/sub menus. The plugin specific mode can be implemented by using INPUT.List or INPUT.Choice to make it easy to implement.

[peterw]

I'm not sure I will like the intelligent ordering. That may make it harder to find the option in the list. I think I would prefer a fixed order, or maybe only update the order once a day. Maybe the registered context menu options could be in a fixed order, but could be reordered manually in a web ui settings page?

I was afraid you might suggest that, too. :-/ I like that the stats-based ordering requires no user intervention *and* results in a fair system, but if you & Erland both have doubts, maybe it's not so wonderful after all.

I think doing this right would require a couple more elements be passed to the registerContextChoice registration function:
- the name of a string token to use in the web UI for editing the order of display (normally CM only gets display strings when building a menu, and only if the pre-offer code indicates that the option should be displayed). This string should probably be identical to the label normally suggested by the pre-offer coderef.
- information (another string token?) about the conditions under which the option would be offered, e.g. "when music is playing that has not already been logged" (to remind users that they likely won't ever see all the CM options offered at the same time)

For the second item, it might be best for CM to define a number of common conditions ["Always", "When music is playing", "When browsing a playlist", "When browsing your library"] so that the web page could offer a preview of how the list might look in different conditions, but I don't know that I'd find the time to implement that.

[erland]

I think doing this right would require a couple more elements be passed to the registerContextChoice registration function:
- the name of a string token to use in the web UI for editing the order of display (normally CM only gets display strings when building a menu, and only if the pre-offer code indicates that the option should be displayed). This string should probably be identical to the label normally suggested by the pre-offer coderef.
- information (another string token?) about the conditions under which the option would be offered, e.g. "when music is playing that has not already been logged" (to remind users that they likely won't ever see all the CM options offered at the same time)

I did some similar work with pippin for the iPeng plugin and it will be really hard to make a user friendly configuration. At the moment the menu looks exactly the same independent on where you launch it but when my plugins start to use this it is going to look different dependent on where you launch it from.
Making it easy for a user to configure the ordering by defining it globally will be really hard to make understandable when the menu actually looks totally different in different situations and never contains all the items.

I would still suggest that you wait a bit with making any advanced configuration interface and just add an enable/disable option:
1. Disable smart ordering = The ordering is defined according to the value provided from the plugin registering an item, no smart ordering used at all.
2. Enable smart ordering = Smart ordering enabled, exactly as it works now.

If you like to improve this I would rather suggest that to look at the "Windows start menu" approach where the most used item is showed directly and ordered by the statistics, but less used items are available in a sub menu ordered by the value registered by the plugin.

[Philip Meyer]

I don't think there's any need for being too smart with the menu ordering. I don't envisage all that many actions being needed in the context list (if a plugin wants to register many actions, it would be best to group them in a sub-menu).

A smart ordering system would be different to the rest of the UI.

In keeping with the UI, perhaps it could remember the option that the user last chose in each context menu, and move back to that position when that context menu is re-entered? If the menu isn't in the list next time in, then move to the first option.

Phil

[peterw]

Difficult and inconsistent. Excellent points.

OK, new plan!

Two modes: Smart and Alpha.

Smart mode would use the current stats approach, and I'll probably add a "Reset stats" button on the settings web page.

In Alpha mode, CM will keep track of (at least) the $uid of the option last chosen (globally). When creating a menu, CM will default to the option for that $uid if it's present, or the top of the list if not.

One additional element that CM will pass to pre-offer is the mode the client was in prior to CM (SaverSwitcher needs that). I could also track the last CM choice per-mode, which might make the list positioning a bit smarter.

Thanks!

[kdf]

It may also be wise to consider the 'weight' method that is
increasingly used for the menuing, especially in SqueezePlay. This
allows for out-of-the-box control of the order, without simply
defaulting to alphabetical. Anything without a weight would go
alphabetically at the end. Stats could be used to create the live
smart menu, which could be reverted to default order at any time.
Using existing methods would help make it easier to support and
maintain all of the different UI's.

-kdf

[erland]

It may also be wise to consider the 'weight' method that is
increasingly used for the menuing, especially in SqueezePlay. This
allows for out-of-the-box control of the order, without simply
defaulting to alphabetical. Anything without a weight would go
alphabetically at the end. Stats could be used to create the live
smart menu, which could be reverted to default order at any time.
Using existing methods would help make it easier to support and
maintain all of the different UI's.

I agree, a weight based solution would be better than just sorting by alpha.

[andynormancx]

I agree, a weight based solution would be better than just sorting by alpha.

Me too, can't remember the last time I saw a menu sorted alphabetically, that would be odd (even the SBC Settings->Advanced menu is only _nearly_ alphabetical).