This isn't the first thing I've seen that Google devs really just didn't get. I think it's from the rapid expansion that Google has done. They get people working on things that aren't really their area of expertise because they wanted to try something in their 20% time.
In this case, it's obvious that we've got server people working on mobile code. Future hardware will resolve these inefficiencies? UGH. That's definitely someone from the server world speaking.
But the thing is, nobody actually cares about this. I have used an Android phone since the beginning. Touch responsiveness is not something I have ever noticed. Any delay in rendering web pages is due to the network.
I think people that write articles about touch responsiveness or animation latency are suffering from the "benchmarking hello world" problem. Yeah, you could speed that stuff up. But 99% of the time, the phone is waiting for data on a socket, which is not going to get fast any time soon.
People care, they just don't know what to call it. People who use iPhones try out an Android device and say things like "it's just not as polished", or just notice that it doesn't feel right. That "not feeling right" is because when you scroll on an iPhone it really feels like there's a piece of paper under the screen that your physically moving around with the tip of you finger. With Android it just feels like your finger is telling a computer what to do, which is in turn doing a reasonably good job of doing it.
Twelve years ago or so, I was reformatting my home desktop (then a Linux machine) and I decided to try to change things up a little, so I installed FreeBSD to try it out. I figured that there wouldn't be any superficial differences, but I knew that there were architectural ones that I'd run into eventually and maybe I could learn a little more about how different OSes worked.
One thing I did notice right away was that the console felt different. It felt like it was maybe more responsive somehow, and not just when it was scrolling a wall of text. It even felt different when I was typing. Somehow, typing at a console (not in X, not via SSH) felt better in FreeBSD than it did in Linux. I couldn't tell you why, and I didn't really understand it myself. It wasn't something I could measure, or even describe, but it left me feeling like FreeBSD was more than 'just like Linux'.
I only used it for a day or so before I realized that I'd screwed up the partitioning and wiped out my Windows partition, and so had to re-reformat, but it left a profound impression.
I feel like iOS is the same way. All the Android phones I've tried (including a friend's Nexus One) have been, theoretically, the same as an iPhone in terms of features and capabilities and even hardware, but even before I got into using them in depth there was just something that felt a little off about tapping on icons or scrolling lists, and I could never put my finger on it, so to speak. Perhaps it's just design decisions or usage patterns that I'd internalized already, but I've always felt like it was something more. Maybe the scrolling behaviour is something I picked up on unconsciously, because while I don't remember it being slow or jerky, I do remember it didn't feel right.
Perhaps the numbers-oriented engineers at Google can't quantify it and so don't prioritize it, or maybe they just don't think it's worth wasting time on, but I think consumers, in the end, will notice. The real question is how many will actually care, and how many will shrug it off because of the benefits (perceived or real) that Android provides them over the iPhone?
At that time the FreeBSDs scheduler was much better than Linux'. I had the same feeling about FreeBSDs responsiveness.
I had a similar perception with Solaris on SPARC. It was slower overall but more responsive when interacting on the shell. Sometimes I had high load (10 or more) and did not notice when using a shell in a terminal.
I think Linux got much better since then. I don't feel the difference on current FreeBSD, Solaris or Linux installations.
I'd suggest "not feeling right" has more to do with experience with a different platform, just as random decisions about mouse acceleration or font hinting or what side of the window to put close buttons can completely befuddle switchers.
You specifically state "People who use iPhones" and many others seem to think that the problem is only apparent if you compare it side-by-side. Which suggests to me that it's a fairly marginal concern, particularly compared with other Android flaws that the same people could be working on.
I switched from iPhone (to one of the lowest-end Android phones on the market) and didn't notice this particular issue. I did have general confusion at where things were and how to do things, but by the same token two weeks later my iPhone felt like it was missing a back button.
With subtle effects like this it's easy to sound like audiophiles talking about mp3 encoding. I'd suggest that if you're expecting the hoi polloi to pick up on these subtleties (which may well be imagined or exagerrated in some cases) and carry this fight for you then, like the audiophiles, you're going to be disappointed.
"when you scroll on an iPhone it really feels like there's a piece of paper under the screen that your physically moving around with the tip of you finger"
Thats one of the best descriptions of iOs scrolling I have ever read. It's exactly right.
Perhaps, but for me, it's absolutely about usability. Whenever I see new Android phones or builds, the first thing I try out is how responsive the scrolling or zooming is. Often times, I'm waiting for Android to respond to my touch, other times my touches are missed completely. These issues cause unpredictability for me and make the phone harder to use.
As phones got faster, the situation improved, until a larger screen was added, which brought things back down again as the CPU burns to keep up. The milliseconds latency here and the stuttering FPS there decreases the usability significantly in my opinion.
I think that there is a group of users who don't notice these latency and animation issues. But I do, and I think many users still unconsciously attribute their dislike for Android to these issues. (example: my brother in law, used several Android Froyo phones extensively before settling on a BlackBerry because it felt "faster".)
I have never noticed any latency. I blame the manufacturer-specific Android "improvements", as I use plain AOSP and don't have any trouble.
My EVO 4G gets about 24 hours battery life, with moderate usage during the day. (But again, this is because I don't use HTC's build. With their build, the battery life is barely long enough to boot the phone.)
I've used vanilla Froyo on the Nexus One. It's dog slow. I don't think this problem is isolated to OEM-specific Android modifications (though they certainly don't help).
Responsiveness and framerate-wise, even a simple cursory examination will tell you: WP7 and iOS run laps around poor old Android. I got to play with a Nexus S recently, and the responsiveness is greatly improved over Froyo on N1... but is still noticeably less smooth than either Apple or MS's platforms.
It's an odd day when MS's UX is more polished than somebody else's...
One area where Android's lacklustre performance really hurts usability is diving into menus. iPhone came up with the novel idea of sliding menus - a simple animation that communicates a lot of context to the user (A belongs under B triggers modal window C, all based solely on the direction of the swipe animation). On Froyo+N1 this animation is jerky enough, frequently enough, that this relationship can easily be missed, resulting in more user confusion and worse UI comprehension overall.
Google needs to realize that we are in the year 2011, not 1995. "UI design" is no longer about placing the right buttons in the right places, and animation is often now the defining line between an easily comprehensible user experience and an obtuse one. IMHO graphics/animation performance is the #1 obstacle in Android's way, and the main advantage everyone else seems to have on it (and it's a huge advantage).
When I use a 2.2 phone, my impression is one of annoyance. I don't know if my touches will be detected, and even if they are, I don't know how long I'll have to wait for the phone to respond. Heck, I enjoy using WP7 phones more than Android because of the performance, despite the fact that WP7 is significantly less featureful than Android! Navigating WP7 is a pleasure, and it never feels like the phone stands in your way. I have yet to get this feeling from Android.
How about we compare the N1 (released Jan 5th, 2010) with the first gen iPhone (released June 29th, 2007)? Even the 2007 iPhone had smooth scrolling/compositing/animation and was always responsive to touch gestures. I'm pretty sure you can't claim a phone made three years before the N1 had an unfair technology advantage, right?
It's interesting how you railed on people earlier for mentioning that responsiveness and animations weren't great, and yet you have animations turned off.
I have a Droid Incredible. (Similar specs to the Nexus One)
I don't have animations off. I have 5 home screens and 3 active home screen widgets (Beautiful Widgets and 2 different Jorte Calendar widgets.)
I don't have any problems with responsiveness or battery life.
I have a DI as well (with an undervolt/overclock kernel) and while the stutters are quite short, they're definitely there. As an easy example, scrub left/right quickly using the optical joystick on the stock home screen. If you're looking for it or paying attention, it's not that difficult to notice 2-3 frame pauses elsewhere but those are intermittent so I assume they're GC pauses. It doesn't hinder my enjoyment of the platform, but when you're looking for something to criticize it's an easy target.
As for battery life, it depends entirely on where you live. I experimented on it for months before finally figuring out that well over 50% of the power draw on the system is the data network (mobile network option when you hold down power). If you have it on when you have really weak/no reception, the phone will burn through the full battery in about 4 hours and it's pretty simple to lose 20% battery in 15 minutes. If you always have a decent connection, your battery life will be fine, if you happen to live in a place where you have holes in your coverage (e.g. NYC urban canyons), battery life is terrible.
After realizing that, I set up a set of Locale rules to shut down the network when I'm on the wireless network at home/work and to shut it down when I lose signal. Combined with the undervolted kernel, I normally get 48 hours on a charge for my normal use (~350MB/mo).
For perspective, the first-gen iPhone and iPod touch are perfectly responsive, even though they're ancient in gadget years. When there are Android phones which feel as slow as crud despite featuring the same (or better) hardware as an iPhone 3GS, you have a big problem.
Google has done a lot of cool stuff for developers in the last few iterations of Android. The NDK has evolved into something quite decent, definitely good enough for writing games now. But responsiveness is the major user experience issue that they've completely failed to address.
Samsung cared, and they spend X million dollars building new devices that made use of the hardware they had onboard because they cared. As a result they can run a browser at 720p smoothly on their phone.
Innovation doesnt come from asking people what they want. It comes from finding new markets and making new means.
The first thing I've noticed about Android was the overall slugishness of UI animation. And the guy who was showing it to me was amazed by the smoothness of my iPhone 3G UI. BUT YES OF COURSE NOBODY CARES.
If you actually look really closely, a lot of what iOS does with animations are about giving the illusion of responsiveness and smoothness.
I'm not saying things aren't incredibly responsive, but some of the animation techniques are used brilliantly to disguise lag.
Three examples:
1. Mobile Safari doesn't wait to render what it hasn't downloaded/formated before responding to touch gestures. You swipe and the page scrolls. It might display a checkerboard before it catches up with rendering, but the swipe command takes precendent.
2. Those wizzy transitions when double-tapping the home screen, or returning to the spring-board. They start immediately and actually mask what's going on behind the scenes with regard to processing a request. They're the ultimate illusionist progress-bar. And they need to be tuned finely to present the illusion or else it becomes obvious that they're masking tactics.
When people complain about the performance of new iOS versions on older devices such as the 3G, what they're really noticing is the illusion has been broken as Apple is optimising and fine-tuning the illusions for the latest hardware.
3. Those screengrabbed snapshots of apps that have been completely closed and display when an app is restarted. If the load time is short enough, the illusion of instantly re-entering an app is maintained, even if all you're seeing is a stale image of the app your closed earlier.
I'm not sure if Android employ any of these tricks, but they demonstrate the focus and undocumented nature of Apple's drive to create the illusion of perceived GUI 'smoothness'.
Well, of course. And if you think about it further, all user-facing software is, in fact, an illusion. Smoke and mirrors all the time. Apple just pushes the illusionist work even further than what most software developers (who are themselves illusionists, whether they realize it or not) consider as being "real". But it works, users prefer that.
Not only that, but I'm convinced that users are actually more efficient when perceived responsiveness is added: for instance, most users will not start thinking about what to do next on an app until they are seeing the app interface; presenting then with a non-interacting screenshot as soon as possible actually makes the overall interaction more efficient. But the ultimate is what the guys making PCalc discovered ( http://www.dragthing.com/blog/2009/07/how-to-make-your-iphon... ): you can put a non-interactive screengrab in such a way that even though it is a dumb image, touches will actually be recorded and have their effect as soon as the actual interface is set up; users can actually interact very soon. Now that's badass.
(however, most animation stuff doesn't fall in the category of perceived responsiveness, as most often, for instance for transitions, the end result must be ready before the animation begins; also, "undocumented nature"? Apple's obsession with perceived responsiveness is well-known).
Whilst I agree with your main point, I have to nitpick your aside about running iOS on older devices. When I tried iOS 4.0 on my 3G (and the reason I'm now running 3.1.3 again) the UI would frequently completely freeze for several seconds. That can't be explained away as poorly-tuned animations.
One of the reasons I'd switched to Opera over Mozilla/Firebird/Firefox was because it remained consistently responsive. A page would be freaking out dog slow doing heaven knows what... in firefox, the browser would be frozen, in Opera, I could continue interfacing and issuing gestures and keyboard commands. Even on my old Fujitsu P1120 - a dog slow 800MHz Transmeta Crusoe beast with 223 MB ram - Opera, while not visually responsive, was at least queuing my operations, and would respond as fast as it was able. There didnt seem to be any event queue in firefox; if the browser was freaking out, keyboard commands &c would be outright dropped.
if you're dealing with lots of data from the Media Providers right on the phone, and you've worked for months on optimizing how to retrieve, cache, massage and display this data on lists, and you're still not getting a decent frame rate when scrolling through List Views you care about posts like these.
Never ocurred to me that GPU would help. I also come from a server programming background and hearing that GPU acceleration on the UI could help is like breathing fresh air.
There's several other more complex things you can deal with if you're writing apps that bring some actual value to the user, other than doing stupid web clients on android. It's not all waiting for data on a socket.
i'd throw ANDROID-1147 and ANDROID-1376 in the Android technical management "absolutely really just doesn't get it" bucket. otoh, the issue Charles Ying of Satine.org rages aobut, ANDROID-6914, seems much more questionable to me because the issue itself is really complex.
the two tickets, "Support for external keyboard, mouse" and "Browser doesn't render SVG images" both strike me as absolutely essential to making smartphones competitive with PC's. people have been happily attaching fold up keyboards to Palm Pilots for a decade now, SVG is perhaps the only sane route forwards for resolution independent apps and animation, and Apple has found religion on both these topics-- yet Android is obstinately behind.
otoh composited gpu acceleration is not nearly the huge obvious win C. Ying boasts it as. the gpu is more power efficient than the cpu for intensive applications, but a smartphones natural state is not intensive use. mr guy of android points out a number of complexities-- opengl drivers only supporting a single context, opengl acceleration proving less speedy than software implementations. it places huge emphasis on driver support, which any embedded wonk will tell you is a scary prospect.
although gpu acceleration is becoming better supported, keep in mind that the smartphone market expands, both up and down, with broadcom & others putting out chips designed for sub $75 smartphones. android is definitely not winning the race for the top atm, but performance has always been a rather lonely market-- that said, unsmooth experiences dont fly. software graphics focus insures a base level of performance for everyone, and strikes me as the right place to start to insure a speedy experience not subject to external interrupts.
the current silkiness situation is a little sad. it'll get better. more relevant to me is Android not playing in the ecosystem-- external peripherials, UPnP/DLNA, SVG-- these are the real things that will make or break not Android, but the open digital web, and Android is failing, badly, even in compare with non-web-enthusiasts Apple.
I'm talking out of my hat here a bit because I haven't actually worked with Android yet but it sounds to me that these problems might be related to the choice of Java as the core programming environment. I doubt that was a decision made by somebody working on a 20% project.
Although Java has its problems, I think the core of Android's issue is a bad utilization of computing resources. One can only hope that Google will eventually fix this problem.
Palm's WebOS put much of its core logic in JavaScript, which had a slower implementation (at the time) than Dalvik VM does. However, Palm carefully made sure to take advantage of the GPU to achieve many of the effects in the UI.
Have you guys tried MIUI on Froyo ? It gives me 60FPS for scrolling, panning and almost everything on a Nexus One: http://www.youtube.com/watch?v=Or-9T44Bt7M
It has got NO GPU acceleration.
That PWNs it
In this case, it's obvious that we've got server people working on mobile code. Future hardware will resolve these inefficiencies? UGH. That's definitely someone from the server world speaking.