Hacker News Reader

Comment by mvkel | Hacker News Reader

It's incredibly frustrating to want, more than anything, to build a cross-platform mobile app that _feels_ native and still it's not a realistic expectation.

I'm still pushing my team forward on using jQuery Mobile. I was hoping, praying, that the biggest UX issues would be solved by the time we were ready to launch our app. Unfortunately, it doesn't look like that will be the case.

My biggest issue is one that seems minor on paper, but is infuriating as a user. I'm talking about the 200ms tap delay that is prevalent inside any Mobile Safari instance. I've seen dozens of "fixes" for this issue published in jQuery Mobile builds, but here we are, at March of 2012, and apps still feel incredibly sluggish due to this tap delay.

I'm going to have my devs take a hard look at the behavior to see if they can code up a bespoke solution, but golly, I was really hoping we wouldn't need to waste our time.

View on HN

I think it's best not to try an emulate native iOS and Android apps because the experience will almost inevitably be subpar and lead to what I call the "mobile web app uncanny valley".

Mobile web apps that are advanced websites used through the browser are perceived as useful when they are. However when they try to emulate the look, feel and behavior of a native app, the app falls victim to an uncanny valley where the app feels like a poorly made native app and those feels of negativity overwhelm the experience of utility in many cases.

It is incredibly difficult to pull off a solid mobile app. The only two that I've used that really feel right are Twitter and Facebook. All the others have been subpar.

jQM should try to be a great mobile web app framework and less like a native app emulation framework. Embrace what it means to be a web app instead of trying to disguise it.

> I've seen dozens of "fixes" for this issue published in jQuery Mobile builds

I'm not sure if that means you already know about it, but the virtual click infrastructure was built for this specific purpose.

[1/4 of the way down] http://jquerymobile.com/demos/1.0.1/docs/api/events.html

Just make sure you don't use the virtual click events with elements that move as the browser will fire it's post-touch click on what's there when the time comes.

Yes, the .tap() stuff is a holdover from jQTouch. It doesn't work very well, with some things responding correctly (buttons) and others not (inputs/checkboxes).

I was talking about the virtual mouse events. It abstracts over touch and click events so you can bind to "both" by binding to "vclick" while still getting the faster responses.

Don't blame jQuery Mobile for that. It's a result of a bunch of time-based heuristics that sometimes don't work the way you expect. You can always override them (at your peril) by going for the immediate events like touchstart.

It's February, 2012 is a leap year ;-)

Could you prevent the tap delay with onTouch-events?

try this:

    $('.fastLink').bind("vclick", function (e) {
      $.mobile.changePage($(this).attr('href'), "slide");
      e.preventDefault();
    });

Reply on news.ycombinator.com