The Problem
I switch between messages using the keyboard down arrow and quickly scan the contents of each one. For some messages the UI lags slightly, so it doesn’t feel responsive. This seems to happen with newsletters and conversations with many messages.
Even worse, sometimes tapping the up arrow 5 times will not move up 5 messages in the list. Sometimes it will, but if a message is laggy enough it won’t.
Proposed Solution
I’m not sure the best way to solve this, but the metric should be that long threads and complex HTML emails should not take significantly longer to display than a simple plaintext email. Most emails load quickly enough to flip through them quickly. But some still lag. Focus on the ones that lag and make them faster.
Ideas:
- First ensure that no matter what else happens if I tap the up arrow 5 times very fast, I will move up 5 messages in the list. This is currently not the case. If a message lags in loading, the UI misses the tap, so sometimes 5 taps on the up key results in moving 3 or 4 messages up. It’s non deterministic and this feels really broken. This is on Debian on a Chromebook, in case it’s hard to reproduce.
- Create absurdly complex messages, profile them, and focus on lags.
- Use telemetry from users and track message display latency as a metric.
- Render some placeholder content instantly before rendering the full email. This way I can at least skip to the next message quickly.
- Track “can the user skip to the next message” not just “have message contents displayed” as a metric. This will help make sure the app feels more responsive even if messages still take a while to display. Half of what people who read email do is skip through stuff they don’t really need to see, so this is fine.
- Only index or render the stuff I need to see first (most recent message, top of newsletter content) and then render or index the stuff I need to scroll or click to see later. Something is happening where content I’m not immediately seeing is slowing down the UI and this isn’t helpful.
- Lazily render the adjacent messages in the list, so that at least if I’ve been sitting on the current message for a few seconds loading the next one will be instantaneous (maybe you do this already?)
Alternative Solutions
Ideas listed above.