1. The Safari address bar momentarily drops down from the top and then back up again.
2. A loading modal appears for a few seconds and then disappears.
3. The page I'm currently on jumps to the top.
4. The new page slides in from the right and the old one slides out to the left.
Steps 1, 2 and 3 are extremely jarring and, in my opinion, totally unnecessary. (I mean unnecessary from user perspective; I understand that the behavior is probably difficult for the framework developers to control cross platform.) I guess there's an argument for #2, but does the user really need such an obnoxious cue that content is being loaded?
Anyhow, I'm a huge fan of the idea behind this and I'm really rooting for this framework to succeed. But I could not at this point in good conscience implement it for any projects I'm working on, sadly.
I see that modal when browsing the docs (http://jquerymobile.com/demos/1.0/) in Chrome on a broadband connection ("I canna go any faster captain!"). The presence of that modal made me question other design decisions (yes, I get it, you have a sleek pop-up experience... now why are you showing it to me on every page load?).
IMO, with ajax page loads you need to show the user something that indicates their click was received. All browsers have a spinner or message somewhere to indicate "they're working" on pulling down the next page of content. If you take that visual clue away from users when loading content via ajax, what you'll end up with is frustrated users who click multiple times on the link since they think it's not working.
Whether the big obnoxious "loading" popup with ugly spinner is the right design choice is another matter, but fortunately the styling and location of that is easily changed.
Sure, we can tweak it to have a small transparent spinner in the lower right... but what other changes are needed too? I want a framework where the authors already fixed these obvious things.
i'm sure jquery's focus is on compatibility (not unlike the values of jquery core). unfortunately, this puts experience in the back seat. i do have faith this stuff will be resolved in time. granted, i've been saying that for over a year.
I couldn't agree more. I'm less disappointed with the lack of progress here than I am with the fact they consider the current version worthy of being labeled 1.0. That signals to me that they don't consider an outstanding UX to be a core feature of the product.
If they focused 100% on iphone / android, I'm sure they could achieve a better UX and performance.
Just look at zepto.js thats 100% focused on mobile safari vs jquery.
Generally, I kind of liked it. I'm using an earlier version internally for some infield data collection, and it works pretty well. I am, however, using it in a long-view situation where ajax continually refreshes the data without reloading the page if that makes a difference.
I guess there is a place for a library that has sub-optimal performance but works across many different devices.
I would say the problem is not in these frameworks, but in the browser. It wasn't made for these kind of apps and it is slowly catching up.
On performance, we've found that on older devices, changing pages can be pretty slow, but on more recent hardware it's quite usable. Scrolling hasn't really been a problem except on fairly old hardware, such as the original Pre and some older Android phones.
We did run into one odd problem when overlaying some jQuery Mobile buttons over the HTML5 game canvas because the buttons used css border-radius, which reduced framerates by about half. We were able to switch to custom buttons that used css border-image instead, which had a much smaller impact on the canvas performance. But that really seems to be a bug in the mobile browsers rather than a jQuery Mobile issue.
disclaimer: these was just preliminary tests and im not a real coder :)
If you just want to format read only content for a mobile website, then you don't really need JQM.
you can make jqm better by coding very thoughtfully - making sure you transition to a new page before doing an ajax call, for example. in fact, waiting for any ajax response before giving the user visual feedback will sink your app - give the visual feedback first.