Tuesday, February 23rd, 2010

Mouseovers on Touch Devices

Category: Apple, Editorial, Flash, iPhone

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

The issues are relevant to Javascript developers; for example, PPK has previously speculated on the demise of mouse* events, as well as hover in touch environments. How will that play out with a web app that relies on them?

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:

Related Content:

  • 1. Touch ID
  • Keeping in touch
    The adoption of wireless Lans and the use of public Wi-Fi hotspots is increasing, but suppliers still need to sort...
  • Don't touch that!
    Your contractor put down the copper, set up your network devices and got the system running. Want to put in a patch cable? Check your warranty...
  • AMD ignites licensing touch paper
    AMD’s much anticipated launch of its first dual-core Opteron server processor on 21 April has fuelled the debate among...
  • HTC Touch Pro, Diamond: Smartphone previews
    HTC's latest mobile devices were released about the same time as this Fall's CTIA show, where Brighthand.com Editor Kevin O'Brien had the opportunity...

Posted by Michael Mahemoff at 2:35 am
14 Comments

+++--
3.4 rating from 26 votes

14 Comments »

Comments feed TrackBack URI

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?

Comment by ebdrup — February 23, 2010

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…

Comment by jpvincent — February 23, 2010

@jpvincent: a 2-finger swipe will scroll scrollable DIVs in iPhone Safari.

Comment by Menno — February 23, 2010

I would say:

http://www.mikechambers.com/blog/2010/02/22/flash-player-content-mouse-events-and-touch-input/

No worries when you are using flash and touch devices.. :)

Comment by V1 — February 23, 2010

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.

Comment by RobG — February 23, 2010

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

Comment by paziek — February 23, 2010

@paziek Actually, drop-down menus that open on mouseover are a great example of a very popular and completely terrible use of hover. Keep that junk out of my face until I click it, please.

Comment by okonomiyaki3000 — February 23, 2010

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.

Comment by iliad — February 23, 2010

This is called throwing the baby out with the bathwater.

Comment by cyrusomar — February 23, 2010

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

Even flash light would be a start!
https://www.adobe.com/mobile/supported_devices

Comment by 1Minnow — February 24, 2010

“Is there a term that abstractly could mean both?” (click / tap)

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.

Anyone else think the CSS Ninja character looks like Mr. Hanky?

Comment by JonathanLeech — February 24, 2010

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.

Comment by getify — February 24, 2010

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

Comment by RyanGahl — February 24, 2010

@RyanGahl – “hold finger down” is already a gesture in the iPhone UI to bring up the magnifier and copy/paste dialog.

Comment by RobG — February 24, 2010

Leave a comment

You must be logged in to post a comment.