1) The author is criticizing an unreleased product.

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.

This is a powerful thing to point out. Touchscreens really are a different animal than mouse-based browsing, and in the short term it's going to require building versions of sites specifically for them.

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.

> in the short term it's going to require building versions of sites specifically for them.

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.

> Or re-think their design choices in the first place

+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.

I don't think the article was making a case that it will be difficult to make design changes to fit the touch screen---just that it does, in fact, require changes. It's another hurdle of adoption to jump over before the iPad can really be considered the "best web browsing experience EVER" or whatever they are marking it as.

Maybe I overreacted, but the article does make some pretty big claims: needing an entirely new version of a site just for non-mouseover browsers? C'mon...

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.

Because it was not yet released?

I agree that work needs to be done to optimize websites specifically for the iPad, but most accessible* websites I can think of now would work just fine.

* Accessible means no Flash, no unnecessary JavaScript, and clean markup practices.

Scrolling Google Maps like elements: Doesn't the iPhone use a two finger scroll for this?

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?

TLDR: Touchscreens are different from desktops. I don't have an iPad, but I doubt Apple considered this.

I bet something can be done with multitouch to ameliorate this problem, possibly introducing modes into touch, but it would require a learning curve to use...

The iPad is not for some web browsing.

Most of it should work fine and with time developers will utilize new APIs for this new(ish) browsing style. Not a huge deal.

A clearer title might have been "Why the web is not ready for the iPad (yet)", as people have seized upon this as some kind of attack on the iPad, when it's nothing of the sort.