Hacker News Reader

Comment by danielrm26 | Hacker News Reader

iOS user here, so bias acknowledged, but I am a mobile security guy and I get new phones quite often.

Just last week I fired up the new Google Nexus device from LG and tried to spend a full week on it--for the purpose of being more familiar with Android as a user.

I couldn't make it a full 24 hours.

This was a fully stock Android experience, on the latest and greatest phone, and Chrome crashed six (6) times on me. Scrolling in the browser was markedly inferior. And the overall experience of reading on the device just felt far worse.

I didn't want to read anything on it, honestly. I tried to account for my own bias towards iPhone/iOS, but I don't think it makes up even half of the bad experience I had.

In short, I think Android phones discourage, from a UX standpoint, the activity of browsing. And I think that's a much larger factor than that mentioned in the original post.

View on HN

The scrolling difference is due to differences in how Android and iOS prioritize things. On iOS, putting your finger on the screen stops all processing on the page - no rendering, no animation, no Javascript, no downloading, nothing runs until you lift your finger off the screen. This lets the system devote 100% of its processing power to moving that rendered graphic around.

Android, by comparison, continues to perform its tasks while you scroll. This means that the scrolling can be jerkier if things are loading, but you continue to get a full interactive page while you're scrolling.

Speaking as a developer, iOS(/mobile Safari) gives me fits. It's the mobile generation's IE6.

Well, given that a tiny fraction of users are developers, doesn't it seem like a poor decision on Google's part to have a poor user experience in order to help in some other area?

Seems like UX should in fact be the highest priority.

The way that iOS does things prevents developers from doing things to help UX! For example, as an effect of this prioritization, iOS doesn't report scroll position while you're scrolling a page or scrollable div in a page, until the scroll has completed, and the scroll momentum has come to a full stop. This makes all sorts of app-like interactions impossible in an iOS webapp.

I don't really think that the user experience is poor, per se. I think it's a matter of acclimation; I've been using Android since the Nexus One, and while it was certainly frustrating in the past, Android 4.1 really stepped things up, and it's a really nice experience now. I appreciate how iOS scrolling feels, but in general, Android's way of doing things seems to be a lot nicer to me. I actively use Android and iOS devices on a daily basis (my phone is an LG Nexus 4, the same one you disliked), and Android feels much, much better to me than iOS does, with the sole exception of scrolling smoothness.

It's worth noting that there is one difference that might have been annoying you; iOS starts scrolling as soon as you start moving your finger. Android has a deadzone of a few pixels, so it might feel less responsive if you're used to the lack of deadzone on iOS. Once you're used to it, it's not an issue.

I don't think this is strictly true. The runloop has different modes, and you can attach background operations to them accordingly. It's true that scrolling does block some modes (and by extension some background tasks and timers), though.

Perhaps in apps, but not in the browser.

"...no downloading, nothing runs until you lift your finger off the screen."

It's not true. The browser continues fetching data, and the kernel continues with context switching.

I'll have to try it again then. Last I'd looked at it (this was early iOS 5), though, it caused really nasty issues with a preloading gallery I was working on. We ended up having to preload several slides in advance, as iOS would just flatly refuse to do anything in the page until the user had removed their finger from the page. The context switching I'll give you. I really meant that the browser appears to stop doing all its stuff while you're touching the screen, not that the system comes to a full halt. Obviously the render loop is still running.

The fact that you also don't get scroll position updates until the drag momentum wears out is also a giant pain in the ass.

Maybe that's why iOS has so much more "mobile data" - all these weird hacks like prefetching a bunch of data the user may never see in order to make scrolling behavior more acceptable.

This has been repeatedly invalidated over and over and over again, and I'm really tired of being brought up as the excuse.

First, you can simply prove that's not right empirically: start loading a large page, slap down your finger, scroll around for awhile, notice that the rendering has halted (which seems to confirm what you're saying), and then release your finger, to witness the page snap to 100% completeness. Why? Because things were indeed continuing in the background; the only thing that "blocked" is that the OpenGL canvas you're dragging around doesn't get swapped while you're scrolling.

Here's what's actually happening: iOS makes it absurdly easy to do computations on background threads. Android doesn't. iOS makes it very easy to offload a lot of processing to the GPU. Android doesn't. The difficulty means that many apps end up doing computation and actual rendering on the UI thread, which, surprise, makes for a jerky experience, whereas most iOS apps do the computation on a different thread than they do their rendering. Throw in that Dalvik's GC is beyond horrible and you've got everything you need for a nice and jittery UI experience.

Note that Android absolutely allows you to do background processing, GPU-heavy rendering; it's just harder. You can even avod the GC by carefully reusing objects in fast-render loops. In fact, our Android Trello dev either just released or is about to release an update to the Android app that makes it scroll smooth as silk by doing all of the above. But it requires a lot more effort to get to the same place, which is why "all" iOS apps perform better than Android ones.

I must be doing something different, because performing your exact test doesn't have the results you describe.

I just opened a CNET article on my latest-gen iPod Touch running iOS 6. When the page was half-loaded (header loaded in, no content yet), I placed my finger on the page and dragged it a couple pixels. I left it there for 30 seconds - nothing on the page changed during this time - then removed my finger. I then very clearly watched the story header image progressively download, and it took several more seconds for the page to become fully rendered.

There's an easy way to test this: visit a very large site while tcpdump or Burp is capturing all your HTTP traffic. And upon first touch of the site, put your finger on the screen.

Does the stream of requests from your phone stop? No, it doesn't. The requests visibly continue to be made in the background as the page continues to load, so your comment isn't accurate.

Okay, here you go. Installed tcpdump on my router, grabbed all traffic to my ipod during the test. The test consisted of opening one webpage (cnet, again), and putting my finger down on the screen twice while the page was loading. I opened the dump in Wireshark and filtered it to HTTP traffic.

http://cl.ly/image/1R0v1P3y0J1u

You can clearly see that traffic stops at 8 seconds, when I put my finger on the device. It then resumes 23 seconds later, when I remove my finger. It then stops again 2 seconds later, when I put my finger back on the device. This was one pageload, no shennanigans, just putting my finger down on the device and scrolling it slightly while the page was loading. It took ~40 seconds to load that page because I had my finger on the screen.

It looks an awful lot like the device is not downloading anything while my finger is on the screen. It certainly didn't just snap to "fully rendered" when I removed my finger at 31 seconds.

I think this is an iPod limitation implemented by Apple. I have the iPhone 5, loaded a large non-mobile site, and did the same thing. Upon lifting my finger, the rest of the page loads instantly.

The same behavior that I observed happens on my first-gen iPad, FWIW. I don't have an iPhone to test with.

I'm an Android user, and I agree completely with this. Browsing the web on Android is a painful experience.

I've personally had a different experience. (Background: I've had an iPhone 3GS and 4, HTC EVO 4G, a LG Optimus from Sprint and Virgin Mobile, some dirt cheap Android-based Samsung smartphone, and now the Samsung Galaxy Note II. All of these devices I've used for a minimum of multiple days

Other than the stock browser on the Samsung Galaxy Note II (which is easily replaced by Google Chrome's mobile browser) I haven't had issues with any Android device browsing the web compared to an iPhone. In fact in my experience, I would without a doubt say Chrome has been a better experience than Safari. Google Chrome's integration with their desktop browser has been awesome since I use Google Chrome on all my desktops.

But this is personal experience, and you can't really base all of this off personal experience. Second, if you're used to the iOS interface, switching to Android will be a big adjustment, one that if you only give it 24 hours you won't ever enjoy.

What does that even mean? Are you talking about the browser itself? About using a low-end Android phone?

Now I'm curious (I haven't used a newer Android phone). Is this common to Android phones or just the newest Nexus?

I have a Nexus 4, and this is completely over-blown. Mind you, my experience with the iphone is infrequent (wife has one), but I find the browsing experience on the Nexus 4 to be fine.

I got a chance to play with a friends Nexus 4 and it's a pretty smooth experience. Thanks for the input.

Android 2.x is a far cry from Android 4.x (particularly 4.1+) - as of 4.1, the UX is phenominal, IMO.

I've had my Nexus 4 for a week or so and I've had the opposite experience. No crashes, excellent performance. I like it so much I use it over my laptop much of the time.

Reading - really? What exactly was the problem with reading?

I've read several very long ebooks on my Android phone without problems, and that was when I still had a Nexus One. For example I read Reamde which I think has almost 1000 pages.

You didn't read Reamde in the browser, though, did you?

No, but I assumed his problems where with screen resolution or something. Last time I looked, the Android browsers could render text. I actually use Firefox on Android most of the time. There are choices.

Reply on news.ycombinator.com