Thanks for posting and sorry to hear that you are experiencing some lag. You mentioned the lag in the context of your dashboards becoming more complex, so are you referring to lag when navigating between dashboards?
Thanks for the clarification. In that case, it sounds like more like a rendering performance thing (not cloud vs local). All the content is already loaded in memory, so the performance implication would be the time it takes to render (and in this case also derender previous dashboard tiles).
Would you mind sharing some screenshots (or a video) of your dashboards so I can see if there’s any suggestions I could make?
A couple things you could try:
Try minimizing the number of unnecessary tiles. For example, instead of using several 1x1 Spacer Tiles, try using large Spacer Tiles (eg. adjust their dimensions).
Try using the new Dashboard Overlay feature. One benefit of this is it doesn’t have to derender tiles before rendering the new ones which can result in a significant performance boost.
Test on a modern device with a completely updated browser as a benchmark / comparison (eg. a laptop or computer with an updated version of Chrome/Safari).
Related to this, if you’re testing on a device with Fully Kiosk Browser, you could try testing on the device’s built-in browser and/or installing a browser with its own up-to-date rendering engine and test on that (eg. Chrome or Firefox).
A common cause of performance issues is the device having an outdated WebView - particularly common on Fire tablets. Make sure the device OS is up-to-date as Fire tablets bundle the WebView with their OS updates.
On my phone, both on fully and via chrome, it takes around 10 seconds to initially load the dash below. This includes several supertiles. The supertiles show “?” during this period. On android it takes about 6 secs. I’m guessing the difference is down to initial app loading times as chrome is probably already in memory whereas I’m opening fully kiosk from scratch.
Then, when I click the large button to the right of the highlighted green one (in the image above), this takes me to another dash.
On fully kiosk, the press results in a lag and a brief message about “android webview rendering process unresponsive”, which vanishes when the dash loads. Takes around 6 seconds on chrome, which often gives the impression I must have ‘missed the button’ - I press it again and sometimes this is bad timing, as the dash then does actually open and I hit a button I don’t want to accidentally during the screen-catchup.
This is the same behaviour on both android and fully on my phone.
Everything is pretty snappy on my desktop, to be honest. So whatever is going on here means that the dashboard’s are bordering on unusable on my phone.
I tried the overlay - this may be the way forward, with a bit of redesign. Cheers!
Ideally, I need a 'close current overlay button", by the looks of things. The Large “x” at the top right just doesn’t run well, and takes up additional space which could be better used IMO. I open a dash via overlay and I get something scrollable, which I’m avoiding. If I open this design via standard methods, it fills my screen. The additional “x” and border means it’s larger than needed. Maybe an option to
have a ‘close current overlay’ option for an icon
clicking on a blank area closes the overlay
the option to hide the x and additional borders
this would give the benefits of the speed of overlays, without adding in this clunky extra view, i.e.
How quickly does the initial dashboard loading complete where you at least see tiles, but the Super Tiles are still showing the ?
It might be helpful to see a screen recording so I can better understand the timing of various parts of the network loading vs rendering. You can share it via iCloud, Google Drive, etc or send an email to support.
The lag when navigating between dashboards and the browser reporting “rendering process unresponsive” correlates with what I was originally suspecting, but the video might help sus out how much is rendering vs loading data.
Would you mind sharing more details about the make, model, and OS version of the phone?
You can adjust the size of the ‘Overlay Width’. If you shrink it, it will allow more content vertically as it shrinks all the content. Of course, as you’re alluding to with your post, it sounds like you’re reusing a dashboard that was already designed to be ‘full bleed’ for the whole screen and the close button at the top of the screen is naturally going to take up space.
I suspect that most people are either tweaking their existing dashboards to accommodate this new feature (including slight style adjustments) or creating new dashboards suited to the feature.
If you use a dashboard back tile, it will close the overlay (if you haven’t navigated within the overlay creating a history trail).
We don’t have any plans to remove the close button at the top. With the various modals we’ve implemented, we played with the concept of just having the blank space behind modals be the only method for closing them, but found that there’s often cases where its either unintuitive or the blank space gets filled up by the content and then it’s not possible to close. Removing the top close button could perhaps be accomplished with Custom CSS, but is not something we would suggest nor officially support.
I’ve actually made a discovery. Navigating from a…
non-supertiles dash TO a supertiles dash - FINE
supertiles dash TO a supertiles dash - SEVERE LAG
supertiles dash TO a non-supertiles dash - SEVERE LAG
This is true regardless of model of not.
i.e it’s literally a case of if supertiles exist on the current dash, the UI lags. That’s it. Not so much a problem on my laptop (wifi), but definitely a problem on the phone. Note that it is noticeable on the laptop, but still fine.
Obviously the phone can’t handle it.
Fine by me, if you could let me know how to best do this via android/windows I’d be happy to provide this.
Agreed. Its actually 100% reproducible. Evert time you’re navigating FROM a screen with a few supertiles.
Samsung s9, Android 10.
So…not so much of a complex problem after all. Phone can’t handle it. Which is odd, because I use my phone for all sorts and this is the first time I’ve ever thought to myself “I could do with an upgrade”. I’m not upgrading my phone. I think it’s obvious that the use of supertiles is just something that increases the resource usage far too much. This would also, I presume, make the cheaper wall-mounted tablets etc struggle in the same scenario.
All in all, no supertiles = no problem. Which is a shame, because they work ace in every other respect.
Is this a good example of where you are experiencing lag navigating from a Super Tile dashboard? Most of my usage of Super Tiles has been much more lightweight than this, so I’m looking to try to reproduce a good test case to see if I can identify why it takes so long to navigate away from a dashboard with a number of Super Tiles with lots of items spread throughout them.