3 ms·
I've shipped a Cordova app for iOS that utilized heavy touch interaction. We found that GPU-rendered elements were best kept at the top of the DOM and had to do
by kainolophobia 11y ago
I've shipped a Cordova app for iOS that utilized heavy touch interaction. We found that GPU-rendered elements were best kept at the top of the DOM and had to do some serious restructuring of the app to get everything to perform "well enough" on the iPhone 4.
Weird thing is, when we went native, the users didn't seem to care too much. Comparison tests repeatedly left us with users that didn't notice/care about a lagging touch interaction or a screen that took too long to load. This was the case for both in-house tests and overall app usage metrics.
In our case (dating app), I think we noticed something akin to the weather app phenomenon: if an app tells you it's going to rain, and it doesn't, you feel lucky. If the app tells you it's not going to rain, and it does, you blame the app.
Most people either don't notice, assume they need to upgrade their device, or believe there's some technical problem that's out of their control (which it is) and that their experience only depends on what the app does, not how fast it does it. If the app does what it says it will do, albeit slowly, they'll still use it. This isn't to say that buggy apps won't lose users, but rather, slow apps aren't as bad as we might think.
(Note: on the flip side, I've made performance improvements on large scale consumer web sites that saw noticeable increases in user activity/revenue)
- BinaryIdiot 11y agoInteresting though it doesn't preclude it from being a UX issue. For instancing asking people who are already active users rarely matters (unless the app is just that bad). Typically making a change like that you measure the retention rate of new users and if it went up or down. How was the retention rate of new users after the change?