Manually exit a widget (or simulate a keyevent)?

FlipStone said:

However, now when pressing back from the main view I get back in the dummy view and you have to press back once more to actually get out of the widget. Is there a way to do this automatically?

System.exit() and popView don't work... the first doesn't do anything it seems and the second isn't allowed.

Is there a way to emulate the back button press or a key event programmatically perhaps?

Yep I have the exact same problem with a stopwatch widget and there's no way around it. It's too bad because it means that a glance-enabled view doesn't have parity with an older non-glance view, since the user has to deal with the extra dummy view.

https://forums.garmin.com/developer/connect-iq/f/discussion/249991/glance-mode-widget-please-allow-popview-at-top-level-for-parity-with-non-glance-widget-ux/

If anyone wants to take that post and turn it into a CIQ feature request, I won't argue.

Thanks for the extensive info! Hmmm....Don't see how handling things different could work. In order to be able to handle the up and down buttons in the 'main' widget I need to have a dummy 'placeholder' screen in between (for non glance mode) and that enivitably leads to the extra 'press'.

If you mean at least make it work for glance widgets as they don't need it, that's true and I guess I'll do that then. Indeed pretty sucky though.

Well hopefully I'm not missing something here, but this is how I see it.

For non-glance mode:

You need two views:

- Non-interactive top-level "front page" (similar to garmin widgets). Press START on this page to enter the interactive part of the widget

- Interactive view. Might display the same info as the front page, but maybe with BG/FG colors inverted (like with older Garmin watches) or some other indicator that it's not exactly the same as the front page, and here you have the ability to scroll. If you press BACK, it automatically pops this view and takes you back to the front page, which is fine since that's what the user expects anyway. (Pressing BACK should take you back to where you "came from" and/or undo the action taken by pressing START.)

For glance mode:

You have two views:

- Glance view. Press START to enter the full widget

- Full widget top-level view. This should support UP and DOWN (if it doesn't I would consider that a Garmin bug, but I believe it does IIRC). Pressing BACK here should take you back to the glance (as the user would expect.)

--

I think the problem only arises if you need to override the BACK button in the glance mode "full widget view", since it's the top-level view and you can't programmatically exit. That's the problem I have, and that's what necessitates a dummy view between the glance view and the full widget "top-level" view. I can automatically "skip over" the dummy view when entering the full widget, but I can't do the opposite when exiting.

The simple approach, and what I do in my own widgets, is just not use up/down, and stick with a single view.  I then use onSelect() to toggle the screens, and also have a user configurable time to toggle the screens.  So a user can use select to switch what's displayed at any time, or it switches itself after X seconds.

Much less involved than glance/no glance, and trying to exit from the second view.  I started doing this before there were glances, as I didn't like the multi-step exit when pushing a second view.

jim_m_58 said:

The simple approach, and what I do in my own widgets, is just not use up/down, and stick with a single view.  I then use onSelect() to toggle the screens, and also have a user configurable time to toggle the screens.  So a user can use select to switch what's displayed at any time, or it switches itself after X seconds.

That may be simpler (and I have seen it with some CIQ widgets), but it's not consistent with the UX of widgets in either older non-glance watches or newer glance-enabled watches.

The standard Garmin Widget UX model (from my POV) is:

- Top-level view = non-interactive summary. Pressing START takes you to the 2nd level, if present.

- 2nd level view = more details / possible interaction (UP/DOWN scrolls through more pages, if available). Pressing BACK returns you to the top level.

Garmin takes this model so far that they even have some (non-glance) widgets where the 2nd level view is exactly the same as the top-level view, meaning there was no point in having the 2nd level.

Then again, no one ever accused Garmin of having great UX.

But then again, consistency does count for something. Once the user learns how their Garmin is "supposed to work" it's kind of jarring to see a 3rd party app that behaves differently, IMO. I use 1 or 2 widgets that have the "Press START to cycle through screens" behavior and it's kind of annoying to me. Yes, it's easier because there's one less "mode" to think about it, but it's also completely different than all the built-in widgets.

Plus once you're in glance land (which is the case for all modern watches), you always have that extra mode anyways (glance view vs full view).

Native widgets are not written in CIQ, and can do things you can't do in CIQ

I've has widgets that work as I've described and not had a single complaint about that in 7 years

jim_m_58 said:

Native widgets are not written in CIQ, and can do things you can't do in CIQ

Yes I understand that. I just meant that it's jarring when a 3rd party widget has a different user interface model than most or all native widgets. That's all.

Native things have been able to do things you can't do in CIQ since day one of CIQ!

jim_m_58 said:

Native things have been able to do things you can't do in CIQ since day one of CIQ!

I don't understand why you keep saying this? I know that, and even if I didn't know that, you say it all the time.

I was referring to this:

jim_m_58 said:

The simple approach, and what I do in my own widgets, is just not use up/down, and stick with a single view.  I then use onSelect() to toggle the screens, and also have a user configurable time to toggle the screens.  So a user can use select to switch what's displayed at any time, or it switches itself after X seconds.

Native...widgets...don't...work...like...this. Even on newer watches, START always "drills down" while UP/DOWN flips pages. (Yes, there's some native widgets which support both UP/DOWN and START, but you're flipping between different things in that case)

The user has to learn a 2nd interaction model to work with CIQ widgets which have this alternative user interface model, even though it's simpler. I'm speaking from personal experience because I've used widgets like this and the first thing that jumped out at me is I have to interact differently with them compared to all the other widgets on my watch.

Nothing to do with the implementation or capabitilies of CIQ vs native widgets and everything to do with human-computer interaction and UX/UI.

Just my opinion, but sometimes consistency is better than providing an alternative UI model which may be easier or simpler.

Then again I have a data field which grossly violates this principle and is more complicated, so I'm not always consistent either.