Acknowledged
CIQQA-3097

Vivoactive6 simulator: menu key not working

In the simulator for the new Vivoactive6, the menu key (m) is not working.

Also the image only shows a black and white scheme of the watch, but maybe that's intended?

  • especially not the end user (who again, probably has no idea what long press of UP does)

    I hadn’t really thought about it before, but my app unintentionally reflects that. I use the onMenu input as a kind of debug view that displays version and status information. It’s not something users need to discover on their own - they’ll either find it in the troubleshooting guide or I’ll point them to it while helping resolve an issue.

    That’s why the visual indicator for onActionMenu on the Vivoactive 6 felt too intrusive for my use case. I am now using the onHold input for this view on the Vivoactive 6 (thanks again for your help with that in another thread).

  • > You're right - I got that mixed up. The indicator I mentioned actually corresponds to a single short press of the UP button, not the long press that triggers onMenu.

    Yeah this kinda highlights the fact that this stuff isn't intuitive for anyone, especially not the end user (who again, probably has no idea what long press of UP does)

  • When there's a menu hint in the left-center, the user can open a menu by short-pressing the UP. I would argue that this is not the same as "onMenu" / universal menu gesture (hold UP) because in some cases, holding UP opens a *different* menu.

    You're right - I got that mixed up. The indicator I mentioned actually corresponds to a single short press of the UP button, not the long press that triggers onMenu.

  • I think it might be time for me to reconsider the navigation structure in my app.

    In my mental model, I use onPreviousPage and onNextPage to move between views on the same level. onSelect is used to dive into subordinate views - those slide in from the right. Conversely, onBack brings the user back up a level, with the view sliding in from the left. Then there’s onMenu, which I treat as something a bit outside of this two-dimensional structure - it opens up additional information related to whatever is currently on display.

    Of course, this isn’t a universal rule. For example, on my Epix 2 Pro, some native apps show an indicator for onMenu in the left-center, which in my opinion still interferes less with my two-dimensional navigation model than the approach of the Vivoactive 6.

    So, for my app, onActionMenu is closer in spirit to onSelect, and that’s how I plan to implement it.

    Yes, I agree that if you want to display context-sensitive menu or info that doesn't take the user completely out of what they're currently looking at, an action menu (or action menu-ish popover) would be the best way to go.

    As far as the native UI goes, related information is usually not displayed in a popover (like an action menu), but is usually displayed as a separate full-screen page of info.

    It would be kind of cool to have an action-menu ish popover which displays related info, if that info is fairly brief. Wouldn't be too different from the map page which shows a bottom overlay when a location is selected with the crosshairs)

    --

    As far as navigation goes, this is what I see in the native glances such as Performance or Training Status, for FR955:

    - multiple pages / top-level categories (navigate via UP/DOWN buttons or swipe down/up). the current page/category is indicated by vertically arranged dots on the left side of the screen

    - multiple subordinate pages for the current top-level category (navigate via pressing START button or swiping left/right). The current subordinate page is indicated via a segmented arc next to the START button. To be fair this is a little awkward, especially when there are several subordinate pages, as the segments get really small

    - if there's additional info for the current top-level page, this is indicated with a START button hint. If you press START, tap the hint or swipe left, you get more info as a full-screen page. Ofc the big flaw is this implementation isn't possible if you have multiple subordinate pages for the current top-level category

    So yeah, what Garmin does natively isn't perfect, and I think a lot of it is due to the requiring almost all functionality to be accessible via the buttons. Since there's no such requirement for VA6, Garmin went ahead and made the context-sensitive menu functionality more intuitive and discoverable by ditching the menu button gesture altogether.

  • Of course, this isn’t a universal rule. For example, on my Epix 2 Pro, some native apps show an indicator for onMenu in the left-center, which in my opinion still interferes less with my two-dimensional navigation model than the approach of the Vivoactive 6.

    "some native apps show an indicator for onMenu in the left-center" - Yes and no.

    When there's a menu hint in the left-center, the user can open a menu by short-pressing the UP. I would argue that this is not the same as "onMenu" / universal menu gesture (hold UP) because in some cases, holding UP opens a *different* menu.

    Here's a couple of examples on fr955 where's there's a left-center menu hint, and short-pressing UP does something different than long-pressing UP. (I think other watches like fr965, fenix 7, etc. are similar)

    - spotify / other music providers - music player screen:

    If I short-press UP, I get a radial menu with additional player controls (and a button to go the library). If I long-press UP, I get a completely different menu (settings menu)

    - activity start page (before timer is started):

    Short pressing UP gives me a "short" menu with *only* activity-related items. Long pressing UP gives me a "long" menu with the activity-related items followed by general watch settings.

    (To be clear I think this kind of thing really sucks)