The Finger is Not a Mouse
Christopher Allen
* The finger is bigger and blunter then a mouse pointer or stylus, thus links or buttons too close together may be difficult. As our member Kevin Darling wrote in iPhone Development Standards "Buttons should be a minimum of 1/2" tall and wide, preferably with at least 1/8" free space around them".
* If you have ever used a touch-sensitive tablet, you learn that there is some "rolling" of tip of your finger in order to make to make a more precise cursor placement. However, this works when there is a cursor, there is no cursor on the iPhone, so I'm not sure if you can use this trick on the iPhone.
* The finger can lift off the screen, so we can't expect scriptable events associated with the mouse to work the same as they do on the desktop. In fact, some events like onmouseover are not used by the iPhone at all, which will mean many things like custom tooltips or buttons or images that change when the mouse is over them just will not function.
* The finger has many duties that are served by multiple mechanical devices on a mouse. Your finger pans the display, zooms by double-tap, tap and hold to show an info bubble, text button entry, and only rarely emulates mouse movement (probably mainly for hover events for popup menus). It is also not clear to me that when you are zoomed out if events are passed to javacript, or only are passed when you are in fully zoomed-in mode.
* Tap is subtlety different then click, and less precise. Click, mouseup and mousedown events may operate significantly different on the iPhone.
* There are no windows or scroll bars on the iPhone, so you have to use one-finger pan in zoomed-out mode, or a two-finger pan to scroll frames and iframes that are larger then the display area (thus two fingers in effect emulate a scrollwheel events).
* Two fingers can also do pinch-zoom -- there is no equivalent that I know of this on the mouse.
* There is no right-click, optionkey-click, etc. Presumably we can do some clever tricks with hover events with a delay so that we can reproduce right-click functions, but there are no standards for it.
These differences at first could be considered obstacles, but I believe that there may be some novel web UI possibilities as well.
For instance, the Mac Finder has a "popup folder" experience when you drag items -- something similar may be very possible with the "tap and hold" functionality, or with hover events after some delay or gesture.
If we can detect some of the two-finger functionality, we may be able to some innovative UI design based on that.
The built-in iPhone application UI has some physics -- when you 'flick' your finger what is under it has some momentum and flies beyond your flick. I'm not sure how much of this we can emulate with webapps, but some of the sample webapps out there are trying to emulate it. Are there some other physics applicable to the iPhone? Check out this "table" user interface video at http://www.popularmechanics.com/technology/industry/4217348.html -- can we offer some of that functionality in the smaller form factor of the iPhone?
What are your thoughts about finger vs mouse? Is there anything I'm missing?
-- Christopher Allen
Kevin Darling
good points, and you are very intuitive if you've not been around
touchscreens a lot. You covered a lot.
Love the thread title, btw. Also, I think anyone can edit those pages
I wrote... can you try it? The idea is for everyone to add their
thoughts, so newcomers can find info in one spot.
I constantly have to interface with other web apps at work. They just
can't figure out why things like onmouseover popup tips are useless to
our handheld touchscreen clients. *grin*
Windows Mobile has a standard for right-click... you hold one spot for
a second, and a little ring of dots builds until a context menu
appears. (You can release your "click" during the ring creation if
you don't want the menu... it's just a notice it's about to happen.)
I notice that Apple instead just watches for clicks in blank areas of
the screen. Not as intuitive, perhaps, since it's not available
everywhere.
Btw, the two-finger pinch is mostly show-off stuff. In real life,
especially one-handed use, the double-tap zoom and unzoom is more
likely. Notice in most of the Apple demos that's what they do... it's
just easier.
So I suspect you're right, that zooms aren't seen by the app. Hmm.
But scrolling can be on most browsers. Have to try it.
You mentioned handling gestures. Flick-scrolling and page-turning are
the major ones. The scrolling Safari will handle, as we know.
Turning pages with a finger will be up to us if needed. But all you
need is a common .js routine that watches for long swipes within a
narrow vertical box.
This brings up the whole topic of us really needing to put together a
common .js file. Also, I think it's important that common methods
(functions) are used for many things, so that other browsers can be
supported.
Kev
Kevin Darling
I keep thinking that Safari will handle the flick-style scrolling.
But now I can't recall if we've see that or just plain follow-the-
finger scrolling. In either case, something obviously can be done,
since the LDAP demo has it.
Also, I wonder if we can capture double-clicks and use or cancel them
before they turn into zoom gestures. On many little iPages,
unintentional zooming could be annoying. Or not. Perhaps better to
let us old guys zoom in when needed? :-)
Kev
DayLateDon
> I keep thinking that Safari will handle the flick-style scrolling.
> But now I can't recall if we've see that or just plain follow-the-
> finger scrolling. In either case, something obviously can be done,
> since the LDAP demo has it.
My sense is that flick-scrolling (when applied to Safari) is a "meta"
feature that simply scrolls portions of a tall window into view.
(That's why the address bar stays attached to the top.) I'm thinking
that the LDAP demo created using window sized to the content of each
particular "pane" of the app (in particular a really tall window for
the results of the search query). Notice that the app loaded (or
reloaded) new pages with each step; I suspect the window sizes are
being recalculated at this time.
This sense seems born out by the observations here and elsewhere that
"normal" scrolling (i.e., scrollwheel events) are generated through
two-finger gestures. So far as I am aware, flick-scrolling hasn't been
described as an enhanced version of normal scrolling within web
content.
It seems to me that if flick-scrolling worked with in-page scrolling
elements, Apple's would've done what many people here (including
myself) are doing: load information into an out-of-view div, then
slide the div into place and let flick-scrolling do its work on any
scrolling elements. Loading separate pages isn't nearly as appealing
as sliding (especially in a demo that's suppose to be "exactly like"
the Contacts app), so there has to be a reason Apple didn't do it.
Last-minute programming is one theory, I suppose ... but I suspect
that this approach was needed to allow for flick-scrolling (which is a
higher-priority bell-or-whistle than a sliding effect). And I suspect
that I need to redesign my own app to load its panes as separate
pages. (Bummer)
--"Day Late" Don