onMenu behavior with Menu2/CustomMenu

the-ninth said:

It seems onWrap() behaves a bit differently than other delegate functions. According to the documentation:

Oh sorry haha should've read the manual

the-ninth said:

With CustomMenu, the behavior is closer to what I need. There’s no onWrap() method

Sorry if I'm missing something, but CustomMenu inherits from Menu2 and both Menu2 and CustomMenu use a Menu2InputDelegate, which implements onWrap(). Furthermore, the Menu2Sample SDK sample's "Wrap Out" menu (MenuSampleWrapCustom.mc) is an explicit example of a custom menu which implements onWrap().

Yes, it's true that as per the doc, prior to CIQ 5.1.0, some of the methods on Menu2InputDelegate were only called for CustomMenu (but as of CIQ 5.1.0, these methods "are used for all Menu2 types"). However, I don't see anything in the docs which says that certain methods are only for Menu2 (base class) and not CustomMenu.

Btw, I don't see your bad wrapping behaviour on a real fr955, when I test the Menu2Sample SDK sample.

I should have been more precise:

With CustomMenu, if onWrap() is not implemented (i.e., wrapping is allowed), but onNextPage() and onPreviousPage() are implemented and return true, wrapping no longer occurs. If neither onNextPage() nor onPreviousPage() is implemented, then wrapping does happen as expected.

With Menu2, however, returning false from onWrap(), or returning true from onNextPage() and onPreviousPage(), doesn't seem to prevent wrapping at all. This happens only on the real device, in the simulator wrapping can be disabled as expected.

Have you tested whether it's actually possible to disable wrapping with Menu2 (not CustomMenu) on the Forerunner 955?

One idea I haven’t tried yet is whether changing the focus inside onWrap() or within the paging methods (onNextPage()/onPreviousPage()) could help prevent the wrap.

Maybe I’m also missing something - right now my wife and kid need my attention, so I only have limited time to experiment with this. ;-)

the-ninth said:

Have you tested whether it's actually possible to disable wrapping with Menu2 (not CustomMenu) on the Forerunner 955?

No, I just tested menu2sample, which uses onWrap() in CustomMenu.

I was more focused on the statement about "no onWrap() method", which I now understand to mean that there's no need to override onWrap() in your implementation.

That makes sense, as I think onNextPage() / onPreviousPage() are sort of functionally equivalent to onWrap(), except that the former functions are triggered by both swipes and button presses, while the latter is only triggered by button presses. (Ofc, Garmin watches don't wrap menus on swipes, just button presses, which explains the separate sets of functions and the different names.)

FlowState said:

the-ninth said:

Have you tested whether it's actually possible to disable wrapping with Menu2 (not CustomMenu) on the Forerunner 955?

I tested this just now [by modifying menu2sample], and I see the same thing as you: returning false in onWrap() has no effect for a Menu2 (not CustomMenu).

It's kinda funny that with CIQ 5.1.0, as per the docs, Garmin changed the Menu2InputDelegate so a bunch of methods that were previously only for CustomMenu also apply to Menu2 in general, but it seems that they also added a bunch of new methods which are [apparently] inadvertently only for CustomMenu....

FlowState said:

I tested this just now [by modifying menu2sample], and I see the same thing as you: returning false in onWrap() has no effect in a Menu2.

Thanks for confirming and reproducing it. 

One small upside: when using CustomMenuItem instead of the standard MenuItem, the sub-label can be a TextArea that automatically adjusts its font size based on the content.

I assume by "button-based" and "touch-based" you mean:

- "button-based": watches which may or may not have touch support, but touch support can be disabled (while leaving button functionality enabled) and 99% of the device functionality still works. i.e. 5-button watches which may or may not have touch support. e.g. Forerunner 965, Fenix 7, Fenix 8

- "touch-based": watches which have touch support, and most of the device functionality would not work without touch. e.g. Venu, Vivoactive. It's notable that these devices don't let you disable touch without also disabling buttons (in this case, rather than "disabling touch", the UI/manual refers to "locking touch")

I'll just say that by these definitions, Fenix 8 is a "button-based" watch. But Fenix 8 has notably gotten rid of the behaviour which opens the system settings by scrolling past the end of the current context-sensitive menu, and has restored the old behaviour where system settings is just another menu item which opens a submenu when selected.

I disagree that opening a 2nd menu when the user scrolls past the bottom of the current menu is any more or less intuitive/natural whether the user scrolled via buttons or touch. Either way, it's unintuitive and to the end user, it just seems like one big menu (instead of 2 separate menus). This can be seen by the confusion that arises when the activity menu and the settings menu both have an entry called Navigation, and users sometimes select the wrong menu item since the activity menu and settings menu are "combined into a single menu" when you hold the UP button during an activity. This is also seen by the fact that Garmin is unable to properly document how you would open the system settings Navigation item when you are currently in an activity. (The manual just ignores this issue completely.).

I think the idea of scrolling between different tabs/sections makes sense on a web page in a browser or phone, where there is room in the UI to indicate which section you are currently in. Since there isn't room on the watch UI for such a nav element, I think the same kind of idea doesn't work as well, and I think Garmin has acknowledged that by doing a 180 on this behaviour in Fenix 8.

Just my 2 cents, not trying to make you do anything haha.

TL;DR I think the real problem is with combining 2 menus into 1 via scrolling (on a Garmin watch), not with the method by which the user scrolls.

FlowState said:

I disagree that opening a 2nd menu when the user scrolls past the bottom of the current menu is any more or less intuitive/natural whether the user scrolled via buttons or touch. Either way, it's unintuitive and to the end user, it just seems like one big menu (instead of 2 separate menus). This can be seen by the confusion that arises when the activity menu and the settings menu both have an entry called Navigation, and users sometimes select the wrong menu item since the activity menu and settings menu are "combined into a single menu" when you hold the UP button during an activity. This is also seen by the fact that Garmin is unable to properly document how you would open the system settings Navigation item when you are currently in an activity. (The manual just ignores this issue completely.).

I think the idea of scrolling between different tabs/sections makes sense on a web page in a browser or phone, where there is room in the UI to indicate which section you are currently in. Since there isn't room on the watch UI for such a nav element, I think the same kind of idea doesn't work as well, and I think Garmin has acknowledged that by doing a 180 on this behaviour in Fenix 8.

In my app, the main menu structure is derived from a user-defined configuration on the server. So it feels intuitive to keep the menu aligned with that definition.

The behavior differs between button-based and touch-based devices: on button-based devices, you simply scroll through the menu using the up/down keys. On touch devices, you scroll to the end of the main menu, then perform a full swipe up to access the settings menu.

Overall, I would have preferred the onMenu behavior (or tap-and-hold on the VA6) over the current implementation. The settings menu isn’t used frequently, so hiding it out of sight would be perfectly acceptable. However, since onMenu isn't available, I’m actually quite satisfied with the current setup.

In any case, if a Fenix 8 user ever raises concerns, I could easily adapt the behavior on a per-device basis and switch to the touch-style approach.