Currently some apps are terminated before they have finished displaying their information. This is often a problem for the News apps when it moves on to the next app before the headline has finished scrolling. While some static apps only need to display for a few seconds to communicate their information (e.g. Crypto price apps) some could benefit from displaying until they have finished displaying what they want to show (e.g. scrolling headline)
It would make sense if Apps could specify their own relative duration, perhaps as part of the .webp filename that is sent to the device. The developer could optionally create variants that fit within different durations that are sent according to the app cycle speed selected by the user. The developer could then adjust the animation/transition speed of the app for each variant to ensure it completes within the allotted time.
For example, a static app (e.g. crypto price) might have variants that are:
Normal: 10s
Quick: 8s
Turbo: 7s
Plaid: 6s
Whereas an app that conveys a lot of information (e.g. news headline, trivia app) might have variants that are all displayed for a big longer:
Normal: 15s
Quick: 12s
Turbo: 10s
Plaid: 8s
The developer could specify the duration for each user-selected speed “level” and then adjust the animation/scroll speed to ensure the information being conveyed fits within the allotted time.
This would prevent data from being cut off before the next app is displayed.
I would love to see per-app time specification, but as a free-form entry, as sometimes I wouldn’t mind keeping the weather (for example) display for as long as (gasp) 1 minute.
Yes. agree that would be awesome… I wound up putting two subway apps for the same station together to make it display longer, but an in app selection would be great…
I prefer the idea of developers optimizing variants of their apps for the four different speeds, rather than letting the user specify how long they want each individual app to display for. The former is more elegant and makes for a cleaner experience for the user.
would be awesome if there is a signal that can be sent to tidbyt that the app has finished rendering ( + a custom buffer timer) and then the cycle can continue. of-course there has to be a max-time limit in case someone accidently did not send the app finish signal.
This would be great if the asyn responses from the server are taking longer. In the begining, I remember that the server was taking longer to respond for the startup and my tidbyt was stuck in a restart loop.
Agreed - I think building in the ability for the news app to understand when it’s finished displaying the entire headline would be most useful. I set my cycle speed to ‘Turbo’ and other apps are fine, but headlines are almost always cut-off.
I concur that this should be set at the individual app level, or at the very least have a number slider that we can manually set a cycle time. I’m developing an app that cycles through content which take about a minute, and is always cut off after 15s.
Totally agree with this, especially apps that have scrolling content it seems weird to cut it mid-scroll. For example the quote app, if you don’t catch it right when it comes up, you’re bound to read only part of the quote every time. It should allow 1-2 scrolls and not cut out in the middle.
It’s frustrating that nobody from the company acknowledges system-level suggestions like this one. Is it planned? Are we wasting our breath bothering to offer ideas?
They mentioned it a couple months ago when announcing the pin/muting apps update but no timeline and agreed this would make a lot of apps easier to manage/see
“ We are continuing to look into some common requests like how to manage apps that need longer time to display information and how we best handle that….”
Sorry for the late reply here. We do use the feedback here to help inform new features, we just don’t always have time to reply.
We are currently working on a first iteration that will enable apps to show information that requires more screen time than 15 seconds. More information to come very soon!
