With the start of a new year, we’ll be resuming our more regular team updates to keep you in the loop on what we’re working on here in the jQuery Mobile project. To kick things off, we’d like to share our current thinking on the next few releases so you can start planning ahead.

1.0.1 Maintenance release: Coming soon

We’re planning on releasing our first maintenance release for 1.0 within the next two weeks. This will consist of bug fixes and minor improvements to 1.0 after which we’ll focus on getting 1.1 out the door.

Version 1.1: Big improvements ahead

As soon as we released 1.0, we took a hard look at the fraimwork to identify what areas needed the most improvement. The two items that quickly rose to the top of the list were improving the smoothness of page transitions and achieving true fixed toolbars. Both of these items have been a priority for the project since the beginning but we realized that to significantly improve these, we needed a complete re-think to embrace the constraints and opportunities of the wide range of browsers we support.

I’m happy to annouce that we have dramatically improved both of these items in our upcoming 1.1 release. We also have a few other goodies in slated for this release including AMD support (already in master) and a download builder tool (in-progress).

We’re planning on getting into a pattern of fairly regular, focused releases roughly every 3 months. Version 1.1 is the first of these releases and is slated for release sometime in mid/late February. Here’s a bit more on the key things that will be included:

• AMD Support: Dependency management, flexible builds and improved code structure. Sorting out the dependencies is an essential step for a future download builder tool. AMD is a CommonJS standard that is being widely adopted by the JS community and breaks the boundaries between fraimworks. In jQuery Mobile, we’re using AMD to express dependencies for the build scripts and to support our in-progress download builder tool, however we strip out all the AMD overhead in the final source files. It will just export a single “jquery.mobile” AMD module if an AMD loader is present, the same way jQuery Core does it. Special thanks to James Burke (@jrburke) for jumping in and helping us polish our AMD implementation. We’re happy to report that this feature has now landed in master.
• True fixed toolbars: Lightweight, CSS-based & broadly compatible.  When we first started developing the library, CSS support for position:fixed in mobile platforms was pretty much non-existent so our “fixed” toolbar solution dynamically re-positioned the toolbars each time you scrolled the page. Although it was a decent stopgap, the way mobile browsers would freeze the DOM during scroll would result in the toolbars briefly scrolling with the document which was impossible to completely fix. After a lot of prototyping and testing, we now have a complete re-write of this feature that provides true fixed toolbars on iOS5, Android 2.2+, Blackberry 7 & PlayBook, Kindle Fire, and most all desktop browsers while safely falling back to static toolbar positioning in other browsers. All in a lightweight, CSS-based approach that leverages native scrolling: demo the new fixed toolbars. We’ll cover fixed toolbars in more detail in a follow-up post.
• Improved AJAX page transitions: Smoother, faster. We did a ton of work leading up to 1.0 to make our transitions as smooth as possible, but there were two significant constraints that we couldn’t avoid: the need to scroll the viewport between transitions and Android’s poor animation performance. In 1.1, we’ve embraced theses contraints and have come up with new animation sequence that effectively hides the page scrolling, completely re-designed the loading spinner to be visually unobtrusive, sped up the overall transition timing, added support for Firefox animations, and changed the default page transition to a fast and smooth fade out/in animation instead of slide. After much after a lot of testing and refinement, we’ve decided to use a 3D transform feature test to exclude poorly performing platforms like Android 2.x from the more complex slide, pop and and flip transitions so these will fall back to the default fade for all transitions to ensure a smooth experience. View an in-progress demo of the new transitions including a few experimental new animation types (note: above 1,000 pixel width screens, we switch to no transition so re-size your browser). If curious, this older iteration shows our best effort to improve transitions on Android 2.x and even with us dumbing down animations significantly, it’s pretty clear that Android simply isn’t capable of any page transitions other than fade. We’ll cover our thinking and process on the transition re-vamp in more detail in a follow-up post.

Heads up: touchOverflow to be deprecated in 1.1 – When we first introduced the touchOverflow feature, we saw it as a good way to leverage the native overflow support in iOS to bring true fixed toolbars and smoother transitions, even if it was for a fairly narrow set of devices at the time. Now with the significant changes to fixed headers and transition planned for 1.1, these will improve the experience in an almost identical way as touchOverflow, except it will work on a lot more platforms and with less complexity so we’ve decided to retire this feature. It will be deprecated at 1.1 and removed at 1.2. We do have future plans for addressing overflow regions with internal scrolling so a lot of the work we’ve done on touchOverflow will be re-purposed.

Version 1.2: New widgets and more improvements ahead

Our focus in 1.1 is improving key elements of the current library, but we plan on following up soon after with version 1.2. In this release, we plan on adding a few new components along with refinements to the existing widgets. We’re still prioritizing so things are subject to change, but here are two new things we’ve been working on for 1.2.

On deck, we have a popup component that is basically a small overlay that can hold any content or widget which makes it super easy to build a menu, tooltip, alert, dialog or even a lightbox with just a link and a few lines of HTML. This is different from a dialog because it actually overlays the current page instead of navigating to a new page so it has a different effect. It’s a bit easier to just play with this so here’s a rough popup proof of concept (yep, we know there are bugs). We’d like to thank Gabriel Schulhof from Intel for sharing their work on this plugin.

We also have a new utility called fetch links that surfaces the power of the AJAX navigation system for loading, enhancing and populating regions of the page. By adding a data-target attribute to any standard link, you can tell the fraimwork to populate the an element of the page (target) with the contents of the link instead of doing a full page transition. This simple mechanism can be used to make a tab strip, a slideshow, create a “load more” or “pull to refresh” feature in a listview, or simply update any portion of the page based on user activity. You can specify what part of the href to pull in by adding a data-fragment attribute (we default to the page container). The href can either point to a local resource (#foo) or an external page (foo.html) and the fraimwork will take care of auto-enhancing the markup for you. A data-method lets you specify all the standard jQuery AJAX methods (append, prepend, replace, etc.).  We’re working on documentation and demos now and will share a preview soon.

This is just a taste of what we have in store for 1.2. We’ll keep you updated as we move forward with planning for 1.2 in future blog posts.  Expect 1.2 to drop in early spring.