I hate to say it, since I was looking forward to this, but on iPhone/iPod touch, this feels like crap to use. It jumps around, feels really slow and has some troubles responding to my taps. I really wanted to like it, but I much prefer simple mobile sites to ones that use JQuery Mobile.
I think I wrote up something very similar the last time jQuery Mobile was posted here, but I'm afraid it hasn't improved much since then. This is exactly what happens when I touch a menu item using my iPhone:
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.
The loading modal was a huge turnoff. Why would you ever show that to a user? After clicking a link, when is your browser not loading the next page?
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?).
> The loading modal was a huge turnoff. Why would you ever show that to a user?
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.
I should have clarified -- it's not that a loading message is unnecessary, it's how it was implemented. The fact that a giant overlay modal appears on every page in their public docs calls into question other UI decisions. This isn't the padding on some button, it's an in your face element.
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.
like i've said recently [1], jquery mobile is 90% complete. unfortunately, the last 10% accounts for nearly all the polish required to make a web app feel awesome. personally, i think that's important for 1.0.
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.
> the last 10% accounts for nearly all the polish required to make a web app feel awesome. personally, i think that's important for 1.0.
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.
I use the previous version of JQM at http://bumb.ly and have for the most part been happy with it. The key for me was getting rid of the default page transition animation effect, and instead using "none" as the default transition effect.
On my android evo 4g, its a little too jerky and feels pretty slow, I thought it worked pretty well on my ipad2. Are you referring to the demos or an actual use somewhere? The demo site is pretty slow, try setting up a quick demo for your self if you really want to see it in action.
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.
Unfortunately, they are bound by the constraints of the mobile browsers. To be fair, they have done a phenomenal job of supporting so many browsers across so many devices.
Sencha is currently in the uncanny valley between traditional mobile and native apps. It is very close, but the unresponsiveness/flickering etc is noticeable.
It's not as responsive as Sencha Touch, which is the best out at the moment, but Sencha Touch is noticeably less responsive than native apps. It's noticeable enough to where you can't design mobile apps that are native-looking because they aren't responsive enough. Plus theres little stuff like flickering that get in the way.
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.
I can speak from my experience having released an MMO strategy game that runs on iOS, Android, webOS and most web browsers (http://spaceuncharted.com). JQM is far from perfect, but its compatibility has been solid. It was really nice to be able to write the app once, and use Phonegap to have it run on all the phone platforms with only minor tweaks. I originally wrote the game using the WebOS SDK in Javascript, and porting to PhoneGap seemed to be a reasonable thing to do...
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.
Except jQuery core, everything around it--jQuery UI and jQuery Mobile are extremely bloated and over-engineered. I think, their itch for compatibility is the main problem.
I was actually about to make the same comment. jQuery core is awesome, but everything else just seems like bloat. In their defense, they're tackling a hard problem but I think they might be going about it the wrong way. I think they should solely focus on cross-compatibility and forget about UI frameworks. Then again, UI frameworks aren't a terrible concept for those who want to whip something together quickly (and inefficiently). Maybe it's just a better idea to branch off rather than try to be somewhat of a subsidiary and ride the coattails of the jQuery name.
It is a bit herky-jerky on most of the mobile devices I've tried it on. I've written an app that is fully client-side rendered and plan on compiling it down to native using phonegap. I'm optimistic that this will help a bit (I don't have any technically sound reason to be optimistic - I just am), and that the library will continue to improve, and mobile browser speeds will do the same. Overall I've enjoyed using JQM and it's proved a very valuable tool to get quickly to minimum viable.
i've just started today my first experiments with phonegap and web frameworks like jquerymobile and sencha and im not so optimistic about huge performance improvement: it's basically just running the webpages of your app from the smartphone memory instead of loading it from the website.
NB of course it all depends on the way you develop the app (background updates etc..) but i've quickly tried a long listview in sencha touch vs a native one and the first one was at worst not shown correctly in the smartphone browser (opera) and at best not as responsive as the native one.
disclaimer: these was just preliminary tests and im not a real coder :)
I think that's fair, but for developing cross platform applications, especially with lots of form controls, the functionality is pretty good and difficult to duplicate.
If you just want to format read only content for a mobile website, then you don't really need JQM.
taps are finicky but they're faster than click events. the iphone waits for a double click on click events - several hundred milliseconds i believe.
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.
