onMenu not working in app any more

Hi guys,

I recently realized that pressing the menu button in my app does not execute the "onMenu" code but opens an intermediate menu. There I can choose to execute my applications code or navigate to settings and other sub menus. On the simulator the onMenu code is executed immediately. Is this expected behavior on the device itself? Because in that case it makes no sense any more to use "onMenu" in apps.

SDK: 2.3.2

Thanks!

Bye

jim_m_58 over 7 years ago

r.485.. All I can say is Alpha Monkey is the "big banana" in CIQ land! He does listen and does what he can!
( I just hope he remembers that he owes me a beer at #CIQSummit18! :) )

ekutter-dnu over 7 years ago

So does this completely remove the ability to get to the system menu from an app? Is there some other way to call this menu? If not, could this be added?

While this change was slightly annoying at first, having access to the system menu while in a CIQ app is useful. Specifically, any app that records a workout, it was nice to have access to sensor settings. Today on a trainer ride using my own app to record it, I realized the power meter was not connected so I was getting no power data. With this current functionality, I was able to enable it without restarting my workout.

gasteropod over 7 years ago

Worst case ekutter, you long press the down button to get back to the watch face, and you can get to the system menu from there. Then you can use back or start to get back to your app which should be running where you left it.

AlphaMonkeyC over 7 years ago

It's a lot easier for a user to relate the menu that will appear with the screen that's currently being shown. If the current screen is an app or a widget, I'll see the menu of that app or widget. If it's the watch face, then I'll see the system menu.

As developers we've gotten very used to the hamburger menu in phone apps and web pages as "this is where the options go". The difference with wearable apps is that we always have it available but not every app uses it. On the original vivoactive there was a hamburger menu on the lens art of the device - can't be much more front facing than that. One of things we heard over and over from testing was that people expected that button to always bring up a menu. Ever since then the UX team and product managers have wanted to ensure that the menu action always brought up a menu.

ekutter-dnu over 7 years ago

Worst case ekutter, you long press the down button to get back to the watch face, and you can get to the system menu from there. Then you can use back or start to get back to your app which should be running where you left it.

Your talking from an standard activity, possibly with CIQ fields. This doesn't work from a CIQ App. Am I missing something?

On the 935, I did just find a way though. Press hold the light button to bring up the "controls wheel", I can then press and hold the menu button to bring up settings. Not sure many people would discover this but this is at least an option.

r.485 over 7 years ago

As developers we've gotten very used to the hamburger menu in phone apps and web pages as "this is where the options go". The difference with wearable apps is that we always have it available but not every app uses it. On the original vivoactive there was a hamburger menu on the lens art of the device - can't be much more front facing than that. One of things we heard over and over from testing was that people expected that button to always bring up a menu. Ever since then the UX team and product managers have wanted to ensure that the menu action always brought up a menu.

Ok, this is a good point, but...

- A hamburger menu on a phone app or web page will open a menu related to that app or web page. It won't open your phone or browser settings. This would be unexpected and unwanted in 99.9999% of the cases.
- Not every single phone app or web page has a hamburger menu for the simple reason that not all of them need it.

I agree that my stopwatch is misusing the menu action [because it doesn't show any menu]. But it really felt like the right thing to do, since it only needed two actions - "start/stop" and "reset" - and the non-touchscreen watches so far had exactly two ways to interact with widgets without pushing an extra view: "menu" and "enter". And honestly I think most users were happy with that.

The other examples do show a menu. So the UX team want should be happy with my design and not use that excuse to push an intermediate menu.

Finally: in any system, you have expected behaviors for some keys. But if the app does not implement that behavior [or if it misuses it], I don't think the system should force some [un]desired action.

Talkabout over 7 years ago

I also have a stopwatch app (and widget) on the store. In my case I am also using the onMenu-trigger, but this is to open the lap list. For resetting the stopwatch I have captured the onBack trigger. Here if stopwatch is running, laps are created. If the stopwatch has been stopped, the onBack-trigger resets it. If the clock is 0 it triggers the standard onBack-action. I think a use case where you need to reset the stop watch without stopping it is a rare one, so maybe you could think about a similar solution.

Bye

r.485 over 7 years ago

Let me reorganize my points. In this thread I'm not discussing how my widgets function or trying to find solutions for them. They work just fine. I used them as examples to illustrate why I don't consider the intermediate menu a good thing.

First, I argue that a widget which already shows a menu with onMenu doesn't need the intermediate menu just to comply with what AlphaMonkeyC said ("Ever since then the UX team and product managers have wanted to ensure that the menu action always brought up a menu").

The second thing was about allowing situations in which the menu button do something else than opening a menu.

My third point was to avoid mixing system stuff with connect iq stuff. If the user is interacting with widgets, I don't think it's a great idea to bring him a system menu, and then let him choose to interact the widget again by choosing the first option on that menu. It's an unnecessary confusion...
--
Now, about my stopwatch widget, it works fine, as I always wanted it to work [except by the intermediate that I don't really love...]. My objective was to have a simple stopwatch [i.e. no laps, just start-stop-reset] that could be accessed and managed with the least number of actions or button clicks. I really think I managed it. I don't push an extra view [that avoids one click], and then I have two possible input: ENTER and MENU. Just enough for what I needed: start/stop and reset. It still works after the introduction of the intermediate menu, the difference is that the user has to click an extra time. Not a disaster, all functionalities are preserved and I still accomplish my goal of having as few clicks as possible. The question is: does the user want the intermediate menu?

Talkabout over 7 years ago

Don't get me wrong, I am not arguing pro intermediate menu. I also think that it is not the right way to handle this use case of the UX team as you can see on the first page of this thread. It was simply an example how it can be also done. I was not aware that you tried to accomplish the stopwatch functionality on the first widget view, this is of course something you cannot implement in a different way, as only these two buttons can be handled.

Bye

r.485 over 7 years ago

I know, we are playing in the same team ;-]

I didn't get you wrong and I appreciate your suggestion, even when I didn't really needed it.

I replied to make it clear that I wasn't trying to find solutions for my widgets specifically, but exposing my opinion about the UX team's decision.