Why the iPad is not for web browsing (yet)
interuserface.net
interuserface.net
2) The author points out that some current "interactive components" available in a mouse-dominated world won't work in a touch based paradigm and labels these UI paradoxes. These include mouseovers and flyouts. The thing is, hidden behavior (requiring the end user learn these interactions) is almost always bad UX. I don't see the paradox there.
3) The author points out that web-based Google Maps may be a problem on the iPad. Note that web-based Google Maps (not just the iPhone native app) works fine on the iPhones I've tried it on.
For the same reason, the iPad is brilliant -- you can't scale the desktop metaphors down easily, but the iPhone interface scales up just fine. It may not make a ton of money for that reason, but it will enable the product space, which nobody else has been able to do.
Or re-think their design choices in the first place (which is of course building a new version, but perhaps not specifically for touchscreens).
1 - Links should look like links. If I have to move my mouse around to figure out which part I click or if it's clickable at all, it's a failure. I shouldn't monitor my status bar or watch my mouse curser for a change. I'm not saying everything should be underlined or something, but make clickable things look like clickable things in whatever way is intuitive for the given site.
2 - Hover to navigate. Get rid of it. Find a way to make the click action do the same thing. I abhor menu systems that require a series of mouseovers to get to the clickable element. If I move my mouse a bit too far it disappears, or FSM-forbid if I don't even know that I'm supposed to be able to just hold my mouse over it to do an action. Also: Javascript required.
The above may not apply to flash widgets, so that's understandable. But even some of the complaints in the linked article could be fixed with a better UI:
"Video players where the controls appear on mouseover and hide otherwise." - OH NO! Maybe do what every app does already: tap once to show controls, fade away after no clicks within a window. Is that hard?
"Menus that popup up subpage links when you mouse over a main button, vs. going directly to a main category page when you click." See #2.
"Buttons that have important explanations/summaries on mouseover, which you need to understand before deciding what to click." This is relatively valid, but again, make your UI cleaner or more intuitive and this problem solves itself. Look at game controllers for consoles: do they have tooltips?
"Functions that use mouseover to preview and click to commit; such as choosing hair colors for an avatar: you mouse over the colors until your character looks the way you like, and then you click to commit."
Hover becomes a click. Make a separate submit button. Done. Please hire me, I'm apparently an exceptional UI engineer.
... Anyway, I'm not saying there wouldn't be issues of someone took an existing for-desktop flash app and tried to run it on a touchscreen. Most wouldn't work. That being said, is it really so hard to come up with a UI that doesn't require mouse-hovers?
Is it impossible for Adobe to conceive of their product ever working on something without a mouse? That when the mouse-n-curser paradigm is phased out (and eventually it will be) that Adobe is going to close shop because there's just no way to do Flash w/ touchscreens?
I doubt it.
+1. I cannot begin to tell you how frustrating it is to try explaining to my parents (both of whom are in their late 60s) how and when common mouse gestures should be used. And I'm not talking about anything extraordinary, but instead left clicking, right clicking, mouse hovering, and so on.
Of course, once they get their iPads I'll have to explain pinching, but that seems relatively straightforward compared to our 40+ year old Engelbartian input mechanisms.
Re-tooling your site so that it's not dependent on mouse-overs, fine. Making a "third" version? Time to re-think your existing site.
* Accessible means no Flash, no unnecessary JavaScript, and clean markup practices.
Only seeing drop down menus and interface elements when you hover over them: Make them respond to a click as well as a hover. (and I think Facebook does this already, I certainly remember having to click to get the log out link)
I think that's all the objections answered. Did I miss anything?
Most of it should work fine and with time developers will utilize new APIs for this new(ish) browsing style. Not a huge deal.