There’s a pattern I fall for, about once a day, while browsing the web on the iPhone. It goes something like this: follow a link to a new page as the page starts filling in, read the first screenful do the “scroll up” gesture to make more content visible watch as the iPhone randomly does … Continue reading “iPhones and the need for responsiveness”
There’s a pattern I fall for, about once a day, while browsing the web on the iPhone. It goes something like this:
- follow a link to a new page
- as the page starts filling in, read the first screenful
- do the “scroll up” gesture to make more content visible
- watch as the iPhone randomly does one of three things:
- ignores the gesture completely.
- waits about a second and then scrolls a few pixels
- starts loading the page pointed at by the link you happened to be over when you started the scroll up gesture
Ok, so it’s not like I don’t understand what’s going on here: The poor thing is busy painting the page, and it just can’t deal with the added processor requirements of recognizing all of the events that make up the gesture. It either misses them all, or gets just a few of them, which leaves it either scrolling “a bit” or treating the gesture as a click on the link.
The thing is, it really doesn’t matter to me whether this is processor limited, or a bug in the OS (i.e. events get lost), or it’s just a bad design (i.e. input handled in the same thread that does the drawing), but the end result is that because I can’t trust what the phone will do in response to my touch, I have to wait until the page fully “settles” before I start scrolling. On pages that have lots of content and go off to ad services to fill in side bars, etc., this means I wait for a long time.
I mean, c’mon Apple; do I really have to tell you about the need for responsiveness?
Anyway, as frustrating as this is, the only real reason I started ranting about it is because it got me thinking about Eclipse, the UI thread, and the multi-core CPU trend. We’re pushing more and more work into multiple threads, drastically increasing the contention at the glass. The Jobs framework and UIJobs are interesting, but don’t address issues like recognizing when multiple jobs are attempting to paint conflicting (or even exactly the same) information in the UI… Anyway, there are aspects of the e4 “modeled UI” that are related to this, but it’s not clear that we’ve thought enough about it yet. Hm…