context menus activated by a special button
I don't know if you accidentally misused the term "context menu", or if I'm being overprecise in my definition, but the dedicated Android menu button is a contextless menu. (Or, I guess, a "current-page-context menu".) Actual context menus, that is, menus that are relevant only to a specific UI element, are accessed by a long press on the element itself.
I may be misusing the term, but basically I'm talking about a menu option hidden off from the normal user interface. The dedicated button just never made much sense to me over having a button in the app UI when it was needed. Having the dedicated button encourages developers to use it and potentially hide something there that should just be part of the normal UI. I was mostly using it as an example of how a desktop mentality of context/right click menus still being carried over instead of being rethought for touch.
I've not played with iPhoneOS that much, but precision placement of a cursor in text is a pain. I think I've seen that iPhoneOS provides a transient zoom-in for cursor movement, which is nice, but that's actually somewhat innovative, and I'll bet it's patented. Moreover, probably in a way that Google saw as tortiously defensible.
Fair enough, though it seems Google has gotten over fearing Apple patents by implementing their own multitouch now. I'd hope Google isn't hobbling other parts of the OS due to legal fears. Patents can be licensed after all.
dedicated zoom and scroll areas
I don't really know what you're talking about here at all.
Areas was the wrong word, buttons or other things. Google Maps is a perfect example. On the iPhone/iPad, it opens to just a full screen map. On Android, it's got UI zoom buttons, as if they carried over that feature from the web interface. I know it ties into the multitouch situation, but it's one of those situations where Google used an older UI method to get around it instead of coming up with a new touch method.
So I do understand your point here, but I don't really have a problem with an additional interface that (almost certainly) adds virtually nothing to the size of the device. The N1 trackball does do double-duty as a hard button.
It's one of those things that does come down to opinion. Minimalist vs flexibility. The iPhone OS definitely went with the minimalist approach, starting from scratch and adding only what is absolutely necessary. Android and the phones built around it come from more of a traditional design model that tries to fit everyones different use cases, adding potential unneeded complexity. Over the years, I've come to appreciate the Apple method quite a bit, and understand their point of view on the iPad. Trying to shoehorn a desktop OS into a tablet failed for the most part, possibly due to bad UI and trying to adapt PC concepts. The iPad starts from near scratch, and builds up to try and make a touch device work well, while sacrificing flexibility of loading a desktop UI designed app on the device. This method forces new apps to be built around the new design, and introduces a new way of interacting with the apps. Is it the right approach? Hard to say, but it does present some interesting new use cases.
Previous Topic
Index
