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.
All I want is a library that gives me JQuery-like functionality with optimized mobile performance, decent compatibility with the Android browser's nasty quirks, a reduced footprint (easily doable without needing to support IE and legacy browsers), and a few wrapper functions around mobile-specific functionality like touch events. Is that too much to ask?
(Disclaimer: haven't use it myself)
I'm glad to see that, at least in the docs, they got rid of the back button. There's already a back button in web browsers, even on mobile browsers. We don't need another one in the actual page.
I've come to believe that mobile web shouldn't try to emulate the fancy transitions of native apps for the request/response cycle, it should just be fast. If you're opting for client side async altogether, that's a different story.
The new Theme Roller has a very nice interface as well, with a direct connection to Adobe Kuler, which I appreciate very much.
I played around with an early version of Sencha Touch, but that's all I'm familiar with.
Sencha Touch: http://www.sencha.com/products/touch/
(disclaimer - I'm the author)
PhoneGap tools site has others too: http://phonegap.com/tools/
The learning curve isn't THAT steep. Sencha Touch is well documented, and there are tons of example apps. There's a bit of a gap between the basic example apps and a full featured mobile app, but the documentation covers that all pretty well.
All release candidates have been buggy and slow. It MIGHT work on an iPhone 4S or the latest quad core Android phone but anything other than that it feels slow.
Regarding mobile browser market share:
It is a common misconception that mobile browsers not based on webkit have a negligible market share.
Look at this. http://gs.statcounter.com/#mobile_browser-ww-monthly-201010-...
Which app, that you use, built with jQuery Mobile, is excellent?
I'm making an app with jQuery Mobile right now, coupled with PhoneGap. It isn't going to be the slickest app out there, but it is going to work just fine.
Discussions of what is the best platform are futile. The answer to that debate is always: it depends.
For example, looking at mobile web page transitions, jQuery Mobile is way behind the competition in terms of optimization. The slide transitions in Sencha Touch 2 are way smoother than jQuery Mobile. I recently had lunch with one of the Sencha Touch developers and learned that they optimized this by not using CSS3 transitions at all and instead use a different approach with much better results.
To pick the best mobile web framework for you, you really need to evaluate what you're looking to get out of it. Then go with the one that has optimized those things which you care about most.
I've used both jQuery Mobile and Sench Touch and ultimately I decided I value a small framework codebase and full control of the framework most. Thus, I use a handrolled solution and it's been a great decision for me.
-webkit-transition: -webkit-translate3d(X,Y,Z) …
jQuery Mobile is certainly one the most (if not The most)
optimized platform to build on
Or did you just use jQuery mobile because you have used jQuery in the past, and immediately assume it is the most optimized?
I dropped JQM and went with zepto, backbone.js and custom CSS. And wow, the performance gain was eye opening.
I think JQM is a nice tool to build prototypes and to learn about building single page apps. But no way would I consider using JQM for a production app.