Go to main screen after timeout

[drzacek]

It looks like when I enter settings or app list, or notification*, PineTime remembers that screen and stays there forever. While it is okay for it to stay and not reset after 5s timeout (I can imagine it being annoying when you check firmware info etc, display dims and you're back in the clock and have to navigate back all the time), it should eventually go back to clock - when I check the time one hour later, I rather don't expect it to show the settings menu. And the point of having "wrist raise to wake" is not having to touch the screen (sometimes it is impossible).

Also, sorry for opening lots of issues lately, I only recently got my PineTime and I'm actively using/testing it as daily driver and find lots of stuff that can be improved imho. I'm also setting up the dev environment again and fiddling with the code a bit, so I might start doing so actual work soon myself (no promises).

• sometimes I think it goes back to Clock screen on its own when notification was open. Maybe there was new notification in between or I accidentally touched the screen, still trying to catch this.

[hubmartin]

Hi, for me it makes sense that menus/config screen should close after some bigger timeout and go to clock face. Not sure if closing should have the same timeout like turning screen off. Maybe make another timeout (like 10 seconds longer?) so if your screen turn off automatically, then you have few more seconds to wake the clock and finish your intention in the menu. Or maybe with the new dimming before sleep functionality it actually might go to main screen together with timeout.

Also the current wrist raise to wake sometimes triggers when you don't need it, so I wouldnt base going to main screen on that, or unless its detection is rock solid.

Just please do not jump to main screen automatically when I'm in an app. I use music player with wrist-wakeup which stays open to control volume and pause when I listen podcasts and work on the garden.

[Riksu9000]

480 Will probably help with this because it makes returning to the watch face much easier. Just hold the button down for a bit when you're done navigating the settings and it returns straight to the watch face.

Also, sorry for opening lots of issues lately, I only recently got my PineTime and I'm actively using/testing it as daily driver and find lots of stuff that can be improved imho.

Don't be sorry. It's important for making this firmware as good as it can be :)

[JF002]

Also, sorry for opening lots of issues lately, I only recently got my PineTime and I'm actively using/testing it as daily driver and find lots of stuff that can be improved imho.

Don't be sorry. It's important for making this firmware as good as it can be :)

I agree, feedbacks are very valuable for us to continue improving the project! And many devs open new PR after they saw a bug report of feature request !

I've also noticed that sometimes, when the watch is sleeping for a long time, I've been confused by the watch showing the screen I was before instead of just going back to the Clock screen.

I also agree with this:

Just please do not jump to main screen automatically when I'm in an app. I use music player with wrist-wakeup which stays open to control volume and pause when I listen podcasts and work on the garden.

Sometimes, we probably won't expect the watch to automatically go back to the main screen...

[adocampo]

I agree, after a big inactivity timeout (let's say 5' or 10') PT should show the watchface, and not the latest screen it was shown (app, quick access or menu). Music app: it should stay focused while music is playing (or paused), once there are no reproduction, it should be closed just as the others. The same would apply to all apps that should be running in the background, like navigation, step counter, HRM, and others: while there is some activity, it's fine to let them locked, but as soon there is no activity for a while, I think the watchapp should be closed and watchface should be shown instead.

[tmilburn]

See discussion regarding app timeouts in #681

[adocampo]

See discussion regarding app timeouts in #681

Sorry, perhaps it's related from a developer point of view, but I can't see the relation with this issue. Here we're speaking about showing the watchface instead last opened screen after an idle time of any other screen rather to the watchface, while on the issue #681 are speaking about keeping the screen turned on longer while an app is opened (which I find very useful as I have the timeout at 5'', quite enough for showing the time and navigating the menus, but insufficient for interact properly with many apps).

Here we don't mind the screen to enter in sleep mode, it could be even interesting having the music app darkened and just be shown as we raise the wrist, or let the heart monitor running in background several minutes and take a look then, for example.

[tmilburn]

I see them as all states in the app activity state machine.

Apps go from: Active and Screen On -> Active and Screen Off -> Inactive (watchface active)

Both state transitions are driven by some amount of time without input from the user.

We currently have a setting for most apps going from: Active and Screen On -> Active and Screen Off but #681 is proposing that this transition never occur and hence the transition to Inactive would never occur either.

[adocampo]

Apps go from: Active and Screen On -> Active and Screen Off -> Inactive (watchface active)

And what about all other screens which aren't apps like settings, menus and about screens? They have those states as well?

[Riksu9000]

I think a shortcut to the watch face like the one in #480 should be implemented before making any decisions, as that might be enough in many cases. Not sure if it's a good idea to automatically close apps if we can't tell whether the user still wants to keep using the app or not.

Another option is to have a "lock screen" on top of the app which shows the time, but the app and its state is preserved. Some kind of screen locking has been discussed in #395, #618 and #697.

Or maybe on every wakeup the current time is displayed at the top of the screen above the app for a short time.

[adocampo]

I think a shortcut to the watch face like the one in #480 should be implemented before making any decisions, as that might be enough in many cases. Not sure if it's a good idea to automatically close apps if we can't tell whether the user still wants to keep using the app or not.

I don't know other people, but when I'm done with an app or looking at the settings, I usually press the back button until reach the watchface. It usually takes two pressings and as I'm focused at that exact moment in the watch, it is easier for me to place the screen on the watchface that leaving as it.

The fact is right now the swiping sensor is, well, let's say too sensitive. Just dressing or washing the hands or taking a shower, or simple sitting in the sofa and accidentally rubbing the wrist against the armrests activates it, so, I would say 9 of 10 times I found a non-desired screen instead of the main watchface I wasn't me who let that screen in the first place.

On the other hand, leaving aside apps, what about of self-closing in menus, quick launches and detail pages (like 'About' screens)? At least we will solve many unwanted swiping if there is no user interaction for a while.

Regarding a shortcut in the hard button, I don't know how PT will resist the pass of the time, but as electronic I can affirm that the less we use the button, the more it will last.

As a user, I think that if I left an app opened but not running during several minutes is because I don't want anything from it at the moment, so, there is no need to show it when the screen wakes up again. As said before, if an app is running, like music, podometer, metronome, its fine to stick to that app because the most probable is I would like to continue as I left, but if I stop the music on the phone, or I stop the step counter or the metronome means I'm done with that app, and I think it will save time and increase the hard button's life if we don't need to go back to the home watchapp.

[Riksu9000]

The fact is right now the swiping sensor is, well, let's say too sensitive. Just dressing or washing the hands or taking a shower, or simple sitting in the sofa and accidentally rubbing the wrist against the armrests activates it, so, I would say 9 of 10 times I found a non-desired screen instead of the main watchface I wasn't me who let that screen in the first place.

I don't think a timeout is a good solution to this. Raise wrist wakeup being too sensitive is a separate issue #548. Are accidental touches an issue with other wakeup methods? If it is, then I think it should be handled by something like locking the screen.

On the other hand, leaving aside apps, what about of self-closing in menus, quick launches and detail pages (like 'About' screens)? At least we will solve many unwanted swiping if there is no user interaction for a while.

As a user, I think that if I left an app opened but not running during several minutes is because I don't want anything from it at the moment, so, there is no need to show it when the screen wakes up again. As said before, if an app is running, like music, podometer, metronome, its fine to stick to that app because the most probable is I would like to continue as I left, but if I stop the music on the phone, or I stop the step counter or the metronome means I'm done with that app, and I think it will save time and increase the hard button's life if we don't need to go back to the home watchapp.

The issue is that this would become way too complicated and unpredictable if every screen and app had it's own rules. Generally it's best for the state to be the same as where it was left at when the user returns to the watch.

[Riksu9000]

Duplicate of #297

EDIT: I closed that one instead because there's more discussion here.

[Riksu9000]

Unfortunately we can't know when the user wants it to stay on a screen and when they don't, thus implementing this would cause more issues. Similarly we can't use this to fix #618, because we can't know when the touches were accidental, and when they were intentional.

There's now a quick way to get back to the watchface by long pressing the button, in case anyone accidentally stays in the about screen for example.

I propose we close this issue as something that won't be implemented. The user should instead return to the watchface if they don't intend to browse the settings anymore or use an app.

[JF002]

I agree with @Riksu9000 : we don't know the intent of the user when the watch go to sleep with an app open : do they expect the app to remain active or not? For example, I wouldn't want the timer, chrono or music app to be closed automatically after some time (10s, 10m or even 2h).

It's possible that some users found their watch on a menu or app after wake up because of the wake algo (raise/shake to wake) detected a false positive (ex : https://github.com/InfiniTimeOrg/InfiniTime/issues/548) and/or because the touch panel registered unwanted touch events (water, sleeve,...). Those issues should be fixed by fine tuning the algo/sensor though.

[sammyj85]

There is clearly a lot of interest in this feature. I just came from a smartwatch which did this, and I liked it a lot.

There are concerns about long term lifespan of the hardware button.

The simplest implementation seems to be:

• APP: stay on this when it wakes up
• NON-APP: always return to clock face after a timeout

I still think this should be considered, even if accidental touches are reduced.

My usage preference (though implementation is more complex) would be that apps in some active action don't return to the clock face, but apps in idle do return after a timeout.

[manolol1]

I agree with that. It's very annoying when you have dirty hands (from garden work, cooking, ...) and you just want to look at the time but instead find some random app or the notification screen, and you have to press the button (and probably get the watch dirty) to see the time.

[lightnin]

Returning to watchface after timeout seems to be fairly standard behavior for smartwatches - Bangle JS is one example. Perhaps it is common for a reason: There will always be false positive wakeups.

Note that there is little reason to persist within a settings / options menu after the watch has gone to sleep + 10 seconds or so. Persisting within an app is another matter - there could be reasons for this, so I can see staying in app indefinitely, since it suggests the user has made a distinct choice. But there is no user case I can imagine in which the user decided to enter the choose watch face menu (for example), and wants that state to persist to say an hour later, when they are suddenly ready to make the decision about which watch face they want. Treat settings changes as short term actions. If they don't result in a change, assume to choice was made and forget whatever progress was made (It's not a big cost to the user.)

Locking the watch face (so that only wakeups / watchface displays can occur) until button is pressed is an alternative solution that could solve this. But one of these solutions should be tried soon, as the current implementation is not a good user experience. The most common use case for a watch is (still) telling time. Opening inside of a menu does a very poor job of this.

Edit: What is the process for appealing a "wontfix" label, and removing it?

[Avamander]

Persisting within an app is another matter - there could be reasons for this, so I can see staying in app indefinitely, since it suggests the user has made a distinct choice. But there is no user case I can imagine in which the user decided to enter the choose watch face menu (for example), and wants that state to persist to say an hour later, when they are suddenly ready to make the decision about which watch face they want.

Yep, something like this would be reasonable. Things like Apple watch have taken that approach. But it also has a sleep and water (both hold to unlock) to avoid accidental navigation. Just returning (after a timeout) is tedious.

So I wouldn't reopen this issue. Rather someone proposes a better solution in a new PR or issue.