Most of the thinking on iPad’s exclusion of Flash has been focused on battery life, performance, stability, or control of the application market, but here’s a Flash developer who’s thinking differently. Morgan Adams argues it’s all about the mouseover, and he raises a point that is just as relevant to rich Javascript apps.

Many (if not most) current Flash games, menus, and even video players require a visible mouse pointer. They are coded to rely on the difference between hovering over something (mouseover) vs. actually clicking. This distinction is not rare. It’s pervasive, fundamental to interactive design, and vital to the basic use of Flash content. New Flash content designed just for touchscreens can be done, but people want existing Flash sites to work. All of them—not just some here and there—and in a usable manner. That’s impossible no matter what.
….Mouseover examples:

* Video players where the controls appear on mouseover and hide otherwise. (This seems to be the norm, in fact. Whereas a click on the same video does something different: usually Pause. Try Hulu for instance.)

* Games where you steer with the mouse without clicking (extremely common).

* Menus that popup up subpage links when you mouse over a main button, vs. going directly to a main category page when you click.
….

He claims all the alternatives are unsatisfactory, e.g. re-coding every application manually, introducing gestures, substituting double-clicking for clicking and clicking for mouseovers.

It’s a bit like Dion’s recent tweet: “I find myself typing click^H^H^H^H^Htap 20 times a day at the moment. Is there a term that abstractly could mean both? :)”. We can get away with simple substitutions with straightforward web apps maybe, but it gets a lot more complicated with seriously rich interaction styles, the kind traditionally seen in some Flash games and now possible with Javascript. We tend to think of mobile device design as a matter of massaging the look with some CSS…the harder part to get right is often the “feel” in the look-and-feel equation. Platforms, like the web, which want to support multiple interaction styles, need to provide ways to ease the transition for developers, automating degradation and enhancement in the first instance, but allowing application designers to customise further for each device. Dan Saffer‘s sideshow below makes the point well, regarding gesture design in touch devices:

Yes, you can’t rely on hover effects when creating a webapplication that needs to work on touch devices. I’ve found another problem with the IPhone, At my sparetime project http://obsurvey.com I use contenteditable divs that resize as you are typing (flow layout). They are used in the survey editor. When you activate one of these contenteditable divs, the IPhone does not bring up the keyboard, this is the only thing keeping the IPhone users from beeing able to use the application. Has anyone else faced this problem? Does anyone have a solution for this? Is there some way to bring up the keyboard on IPhones?

let me add another problem about building web application used by touchscreen devices : the scroll inside the page.
When you put content inside an element, say a DIV, with an overflow: scroll, how can the device know if the user wants to scroll the element or the whole window ?
that Safari iPhone has a radical answer to this : you can’t scroll this element, and you dont even see the scrollbars…

Good riddance to hover effects – they are confusing, distracting and inconsistent. Users should know if something is “clickable” by looking at it, it’s called “good UI design” (remember when links were deliberately made to look like links?). Users shouldn’t have to put the cursor over something, then wait so see if something happens. They also shouldn’t have all sorts of UI effects firing off just because the cursor runs certain elements lurking in the page on its way to some other destination.

@RobG: I disagree. Hover effect often let you make better UI.
Good example here would be drop-down menu.
Or a gallery, where after hovering image, semi-transparent buttons slide-in letting you do “stuff” with that image. Of course back in the days (or even now) this doesn’t seem to be intuitive, but I think that soon enough people will know that there is a chance for more UI elements upon hovering image. Cuts on the clutter on site.

The problem with Morgan Adams’ argument is that in a way it applies to almost all interactive websites or applications on the web, since they often rely on mouse hover. However, I don’t see anyone complaining about that. In fact, many developers have created completely new, almost from scratch, versions of their websites specifically for mobile browsers.
Fact is, yes, there will be some apps that would have to be recoded for touch devices. There will however, also be flash apps that only need a minor tweak to work with touch, and there will be some (like YouTube player) that won’t need anything to work inside a mobile browser.

At the end of the day, like it or not, Flash is a ubiquitous technology on the web, and while HTML5 will eventually (at least 2-3 years) offer a better way to play videos, it will not provide a viable alternative for more interactive flash apps like games.
So calling Flash “dying” the way Steve Jobs did recently is shortsighted and ignorant.

A touch device doesn’t seem any different to a laptop touchpad. It seems to be a (relatively) trivial task for Apple to implement a modified gesture system to do something like onFlashActivate() -> this.setGestureSet(touchPad).

Yes, activate. In SVG there is an onactivate property, and the SVG specification recommends using it instead on onclick — “To support the widest range of users, the onactivate event attribute should be used instead of the onclick event attribute.”

Unfortunately in HTML onactivate is an IE-only extension with slightly different semantics than the SVG version.

I think simply depressing your finger on an item (but not removing it) would be a decent substitution for activating the hover… consider the video player scenario.. you push down on the video to show the controls, then move to which control you want, and release to “click” it.
.
Yes, this breaks down with elements that allow “drags”… those might have to require a simple two finger guesture substitution (like one finger depress for hover, two finger depress for click and hold).
.
But again, I think those things COULD be done by the host OS and simply mapped to their equivalent events, meaning a flash app LIKELY wouldn’t need to change to work properly. Might *some* content still have to change? Sure, that’s inevitable. But I bet the majority of them, some simple mapping of one or two finger depress event guestures is enough.

This argument is a cop-out and really has nothing to do with the real reasons Apple is avoiding Flash. Palm Pre will have Flash soon, as will Android, as will other devices, whether it be smartphone or tablet or newfangled whachamathingie…

Apple simply wants to control every piece of content imaginable, and if possible a) make you pay for it and b) take a cut. That’s all there is to it, and anyone making any claims to counter that is just plain old wrong.

As others have already posted here, the mouseover effect would work just fine via “hold finger down” in some cases, or a modifier gesture can be used (i.e. “two finger glide”), or the app in question can be ported (as many app devs are OK with if they want their app adopted on said new platform).