 Okay, so I'm going to be talking about jQuery UI, one of the development leads. We also have Yuren Zephyrer is the other development lead. I'll talk about how that works a little bit later. But going over the history of jQuery UI, it first came out in September of 2007. And about a year later we put out one five, and then about a year later we put out one six, and then we went back in time and put out one seven. And I won't talk about why we did that, because I don't want to talk about the insanity that was going on. Then a year later we put out one eight, and then we stopped doing releases because Core decided that they were putting out too many releases and it was a bad idea. No, so what really happened is one eight went out really well. We had a new design process and new development process. And it worked so well that we said, okay, let's go back and fix everything. And so when we were working on the roadmap, I decided that we should just fix everything. And so we were looking at the cleanup. We were going to do an API redesign of all our widgets. The new widgets in one eight were nice, they were easy to work with. They only had like three or four options that they were very extensible. They had events that you could hook into, change the behavior. Some of the older widgets had upwards of like 20 or 30 options and they were pretty unwieldy. So we were going to go back, redesign all the APIs, refactor everything. While we were doing that, we were going to clean up all the bugs, make sure we had less than 10 bugs for every single component. And in addition, we were also going to go through and add full accessibility. So proper keyboard handling, proper ARIA attributes, which is pretty time consuming. So we were trying to do all of this and at the same time we were like, well, we can't just put out new versions of the existing plugins. So let's put out some new plugins and we came up with a list of plugins to work on. Things like menus, tooltips, spinner, mask, select menu. We're going to completely rewrite date picker. So unlike the other widgets where we're just going to go in, refactor them to work with the new APIs. We're going to just start from scratch with date picker because it was, I mean, it doesn't use the widget factory. So it has a slightly different API than everything else. It's the biggest plugin we have and we just wanted to take a new approach to it. But then, even beyond that, we're going to write a new website. We're going to create an API site to match api.jquery.com. We're going to rewrite theme roller to be more efficient. We're going to rewrite download builder to be more efficient. And so this was pretty ambitious. It was a little over ambitious. A few months ago, Jern got kind of annoyed about how long we'd been working on 1.9. And he was like, how about we just release and not worry about what we said we were going to do. So at that point, we decided whatever redesigns we had started, we were going to finish. Whatever we hadn't started, we'd get pushed off to 1.10. All the new widgets that had already landed in master because they were mostly done, we're going to go into 1.9 and no other new widgets could make it into master. So that brought 1.9 some sanity. 1.9 is still a massive undertaking. 1.10 was going to be almost as big. We ended up later, only a few weeks ago, splitting 1.10 into 1.10 and 1.11. Because we were talking to the Drupal team and they have some issues that they need resolved, specifically accessibility concerns with the dialogue widget that they want to get into Drupal 1.8. And we wouldn't have gotten, with the road map that we had, we wouldn't have gotten it out in time for their code freeze. So we decided to split 1.10 into 1.10 and 1.11 and get dialogue out in time for them. So that should get you 1.10 quicker, which should be nice. So what we ended up doing with 1.9, we did the API redesigns, bug fixes, and accessibility improvements for accordion, autocomplete, position, and tabs. So those, position doesn't have any accessibility concerns, because it's just positioning an element, but everything else. It's been, we've done full testing in multiple operating systems, multiple screen readers, multiple browsers. So it's testing with accessibility is even more painful than just cross-browser testing. But it's fully accessible. So that's a huge improvement. We also have menu, spinner, and tool tip. Spinner is like an input type equals number where you can, you just got a text field that you can enter a number in, but you've got the up and down buttons that you can spin through the number. You can use the arrow keys, you can use your mouse wheel. And we're also going to land all the infrastructure that we had planned. So we'll get the new website, we'll get the new API site, we'll get the new download builder, we'll get the new theme roller. So, 1.9 is still pretty big, and it is actually coming. We just released the beta this morning. So, those of you that have been waiting for it, you can go download it and play with it. We did have eight milestone releases prior to the beta. So, we'll probably continue to do that in the future. It's just an early way, it's kind of like a pre-alpha release, just to, if you're, people are interested in playing with something and having like a specific reference to go to, as opposed to just some random commit that's in master. We have 2,098 commits going into 1.9 and 201 tickets, which probably those numbers don't make sense, right? Like, why did it take us two years and 2,000 commits to get 200 tickets fixed? And the reason that happened is because of all the 1.8 releases. So, in the past 27 months, we've actually done 21 point releases for 1.8. And within those 21 releases, we fixed 536 tickets. So, the true story from 1.8 to 1.9 is quite a bit different than just 200 commits, 200 tickets. So, you can see the history that we've gone through with 1.8. The yellow is how many tickets we fixed and blue is how many commits it took to get us there. You can see that in the beginning, for like the first half a year, we released about once a month for the past two years. So, for the first half a year, we were fixing a lot of bugs, right? Like, we had a new major release. There was a lot of stuff to work on. Over the past year or so, it's kind of leveled out. Anywhere between 10 and 20 tickets are getting fixed in the 1.8 releases every month. But meanwhile, we're doing lots of new development in 1.9 and the API redesigns, and that stuff's not making it back into the 1.8 releases. So, the full story between 1.8 and 1.9 is 2200 commits with over 700 tickets fixed. So, take a look at who's doing all this work. This is a graph of the committers on jQuery UI. So, as I mentioned earlier, I'm the development lead for UI. I work on everything that's already been released. Yarn is the development lead for all new development. So, anything that's coming in a future release, Yarn is responsible for managing that section. And that's something we started with the 1.8 release, and it's worked out really well. It lets us focus on separate areas and not get, like, the bug fixes aren't getting stalled because of new development and new development's not getting stalled because of bug fixes. We can concentrate on them, and then we do a lot of collaboration, but we know that, you know, I don't have to worry about whether or not menu is going to get done in time while I'm working on API redesigns. Chris and Corey are pretty new team members. They joined about a year ago. They've been pretty helpful. Chris has been working on menu. He started with just a whole bunch of bug fixes in various widgets, and then he moved on to working on the, finalizing the menu widget. Corey's been doing a lot of work on effects and the animations that we have. He's also been working closely with the core team on animations coming in 1.8 for core. He's also on the infrastructure team, so he's been helping out a lot with getting a new infrastructure set up. Richard is the project manager for UI. He used to be pretty active in development. Now he's mostly just managing all the other projects that are going on, dealing with a lot of foundation stuff. But the interesting thing is, from 1.8 to 1.9, we had a massive impact from the community. I think it's like 340 commits from 178 members of the community, which, so that accounts for 15% of all commits between 1.8 and 1.9, which is pretty awesome. The API redesigns that we've been working on, in some cases they're kind of small, in some cases they're kind of big. The plan for 1.9 is that when we release 1.9, if you're using 1.8, absolutely nothing should break, even though there's a completely new API. The way that we did this is we built the new API, and then we rebuilt the old API on top of it. It's basically like the compact plugins that core used to do, but built into the files. So, if you just load up 1.9, you should get 1.8 behavior and 1.9 behavior at the same time, and if there's a conflict in the behavior, it'll use the 1.8 behavior. And the idea is that everyone can start using 1.9 right away, get all the extra accessibility improvements, the bug fixes, new features, but they don't have to worry about doing a massive upgrade in order to get started. The one big difference would be if you're on an old version of jQuery, we're no longer supporting anything lower than 1.6, so 1.8 has support all the way back to 1.3.2, so if you're still on a pretty old version of jQuery core, then you'll need to upgrade that. But the idea is that everything should just work out of the box. If you want to find out if you're ready for when the 1.10 release comes out, you can turn off the back compact. So you'll load up jQuery, then you'll have a single line of script that just says jQuery.ui back and pad equals false, then load up jQuery.ui, and none of the back compact code will load up. That way you can easily find out if your code is ready for when 1.10 comes out and all of the 1.8 APIs go away. For 1.10, you can expect bug fixes and accessibility improvements and the API redesigns for dialogue, progress bar, and effects. So it'll be the same pattern, right? When 1.10 comes out, these will have new APIs, but they should be back compact with 1.9, and because they're not changing in 1.9, they should also be back compact to 1.8, but then in 1.11, the back compact layer will go away. We're looking to introduce menu bar and select menu, and we'll also start our working on better integration between jQuery.ui and jQuery.mobile. Right now, the projects are pretty much separate. We don't share too much code. The plan has always been to share a lot of code, and we just, because of the API redesigns and our priorities, we haven't been able to focus on that, so we have a bit of a divide right now, and during the 1.10 phase, we'll be figuring out what the plan is to get rid of that divide and get back to where we want it to be in the beginning. For 1.11, we'll be doing the redesigns and accessibility improvements for button, date picker, and slider, so as I said before, date picker will be a complete rewrite. It's not just going to be a refactor. That will probably be the only thing where there won't be a back compact layer. The changes are going to be too big, and it's probably not possible to build the same back compact layer for date picker. We're also hoping to introduce mask time picker and more effects, different types of effects. So right now, we have a bunch of effects that are basically just toggling elements. We're looking to create textual effects so that you can animate in individual characters of strings and a couple of different other types of effects that Corey's been looking at, and there's been a few community members that have been building up effects packages that we're hoping to pull into core. We're also going to finalize our implementation of Globalize. So we started Globalize a while ago. The code was originally written by Microsoft. It's an internationalization solution for numbers and dates. We're going to be trying to figure out if we can switch right now all the data comes out of the .NET localization information. We're hoping we can switch over to the Unicode CLDR dataset, which should provide us some more, some other types of internationalization that we don't have currently in Globalize. So we'll be looking to finish that up. The 2.0 roadmap, we're going to have the interaction rewrite. So at this point, we should have all widgets done, but none of the interactions will have been touched. All of the interactions are getting rewritten from scratch. They'll have essentially the same functionality with pretty much different APIs, much smaller APIs that are more flexible, but they'll also have a completely new base. We already started this. There is an interactions branch in GitHub, and you can see if anyone's looked at the underlying implementation, we have a file called UIMouse, and it provides an abstraction over a mouse for any type of start, move, and stop action. And that powers everything that we do with interactions. So dragging something is you start, you move, and you stop. When you resize something, it's the same thing. When you sort something, it's the same thing. So we have this base, and we're going to replace that base with a device agnostic and event agnostic implementation. And this has already been started. It works with WebKit touch, the proposed W3C touch, and with MS pointer, and it has hooks so you can build in any other type of system you want. And it just normalizes two XY coordinates for start, move, and stop. So all the new interactions will be built on that, so we'll have full touch support, and whenever new devices come out, we should be able to easily support them without having to worry about changing the individual interaction components themselves. We also plan on working on more form controls. We've gotten a lot of feedback that people, as soon as they put one form control, like a date picker and autocomplete in their form, or like a button, they want to style everything that's a form control, and we don't currently have that, so we're hoping to get some more form controls in there. The list on our roadmap is every possible form control, and I probably won't get that done for 2.0, but we'll figure out which ones people need the most and start working on those. And that's it for UI. Next up is Todd Parker talking about jQuery Mobile.