|
04/07/2010, 08:41 PM
#3094
Supposed Terrible Solutions:
A) The best case: every Flash app on every site is re-thought by its designers and re-coded by its programmers (if they’re even still available), just for touchscreens. They wouldn’t use mouseovers any more—or else they’d have dual versions of all Flash content, so that mouse users could still benefit from the mouseovers they are used to. That’s a ton of work across the Web, for thousands of parties, and just isn’t going to happen. Plus, with many sites, mouseovers are so fundamental that the very concept of the site would be altered, creating a whole different experience that would annoy and confuse the site’s existing users. (And would this be any easier than simply re-designing without Flash at all? Not always.)
B) Gestures, finger gymnastics or extra physical buttons are created that simulate mouseover—which is absurd since mouseovers, by their nature, are meant to be simpler than a click/tap, not more complex. And meant to be natural, not something new to learn. Not a whole set of habits that violates our desktop habits. And any additional complexity is unworkable when it comes to games: you need to react quickly and simply, not remember when to hold the Simulate Mouseover button, or use three fingers, or whatever. The game itself is enough to deal with. Anything on top of that takes away fun.
C) Make clicking itself—the fundamental, constantly-used action—MORE complex. Such as requiring a double-tap or two-finger tap before anything is registered. (Two taps is how Mobile Safari does JavaScript popup menus: the first tap pops it up, the second selects.) But many Flash apps and games already use double-click (or rapid-fire clicking) for other things. Extra taps only make sense for certain limited situations (like menu popups). And it’s not just clicking: you have to allow for movement: dragging vs. a moving mouseover. And even if a system could be created that was quick and simple enough to do all this in the middle of a game, how would the user know which parts of a web page played by these special rules? One part of a page (the Flash elements) would do fundamental things like scrolling or link-clicking differently from the rest of the page! (Not to mention the rest of your touch-based apps.)
D) Have a visible mouse pointer near your finger, and not interact with things directly. Use Apple track-pad style tap-and-drag gestures, as seen in some VNC clients. This kind of indirect control violates the very principle of direct touch manipulation. This is making the touchscreen be something “like a laptop but worse” and has little reason to exist. And again, you’d have to keep remembering whether you were in direct touch mode or “drag the arrow” mode, and which parts of the page behaved in which way.
E) Require extra force for a “real” tap. So you’d have to learn habits for a light tap vs. a hard tap. This extra complexity is non-intuitive, cramp-inducing, and easy for the user to get wrong (even with click feedback, as in RIM’s failed BlackBerry SurePress experiment). This complicates the whole device just for the sake of one browser plugin, and makes it more expensive to build.
|
|
|