On Aug 17, 5:26 pm, RobG <[EMAIL PROTECTED]> wrote:
> On Aug 15, 11:59 am, Curt Kaffer <[EMAIL PROTECTED]> wrote:
>
> > I was thinking: now that we have touch event support in javascript, we
> > should be able to emulate scrolling for divs that currently only allow
> > two finger scrolls. This would allow us to have fixed headers and tool
> > bars while keeping the scrolling interface familiar for users.
>
> If a user is using an iPhone, then the familiar interface is to use
> two finger scrolling.
I know of no native iPhone applications that use two finger scrolling.
If you haven't noticed, most people writing web apps for the iPhone
are trying to make them look and feel like native apps. Clearly having
a native looking app that requires a two finger scroll is the opposite
of providing a familiar interface.
>
> I must admit it took a while to discover the two-finger trick (a day
> or two), and for the sites that I've tried it on it doesn't work very
> well, but I don't see that javascript offers a useable solution.
> There have been a few posts here trying to emulate a traditional
> interface in Mobile Safari, but I think they're missing the point.
You admit it is a "trick" that is not intuitive and takes days to
catch on to, but you think it is a familiar iphone interface element
that users are used to and expect? That makes zero sense to me. I'm
not sure what you mean by "traditional interface" but you are missing
the point of this discussion completely. The idea here is to make
mobile apps look and feel as much like native apps as possible. Most
native apps have static elements on the screen and allow single finger
scrolling. This would be nice for us to have and this solution may
bring it to us. I'm sure Apple will eventually address it since the
obviously see the value in providing tools to build native-like apps
delivered via the web (otherwise we wouldn't have gesture support,
dashboard sample apps wouldn't look like native ones, and they
wouldn't be working on full screen support)
>
> Apple designed the Mobile Safari interface to be useable on a small
> device. Converting that interface back to a traditional browser
> interface that expects a large screen and mouse doesn't make sense. I
> think a better strategy is to work with the current paradigm rather
> than trying to make it something it isn't.
I agree, but have no idea why you are brining traditional browsers,
large screens or mice into this discussion. I think it might be better
to take these points to another thread so this stays on-topic.
>
> For example, code has been posted here that adds drag capability using
> a single finger, but the cost has been confusion about when the
> browser will pan and when things till drag (or be thrown). A better
> approach might be better to use tap+drag rather than just drag, that
> way users know when things will pan or (possibly) drag.
Agree about dragging support, glad to know that people are discussing
it and posting about it.
>
> Similarly for scrolling divs with scroll bars - consider designing the
> interface without scrolling divs. If you must use them, make them big
> enough that two finger scrolling works. Device-native actions should
> always be much smoother than anything done with script in a browser.
I again am not sure what this paragraph is trying to accomplish. The
ideas that I have involve having a static header, lower tab bar or
other element, with content in the center. The fact that they may be
scrolling divs should the totally hidden to the user, which is why I
am advocating single finger scrolling. I don't want the users to have
to use the unintuitive, unfamiliar two finger scrolling when it isn't
necessary for their other iPhone apps. I also want to provide static
headers for easy navigation. Also, I agree that device native
functions work better than scripted. Just so you know, the gesture
support and CSS animation features being discussed are using the
native libraries to achieve the goal. Clearly it is not an ideal
situation to have to write code to duplicate what is already done, and
Apple's implementation may not even support it to the level we need,
but to suggest that the option shouldn't be considered is silly. You
never know what clever app, trick or element might come of
experimenting with the tools Apple has provided for web developers.
>
> --
> Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"iPhoneWebDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/iphonewebdev?hl=en
-~----------~----~----~----~------~----~------~--~---
