 I was secretly hoping I would keep the couch over there, and I could use that, but oh well. So the plug-in directory, when we started working on a new version of the plug-in directory on this project that I'm about to talk to you about, it was six years earlier, almost to the day, that I made my very first commit to a version-controlled repository, and that was the plug-in directory at the time. I followed the documentation that came with the directory that was on the directory as it is still today, even to the detail of using that commit message that they have in that documentation for my first commit, and it looked probably something like this. I was thrilled. When I did my first commit, the plug-in directory looked a bit different than it does now, and I want to show you a little bit about how it looked and where we came from. So the first version of the plug-in directory was released in March 2007, almost ten years ago, and WorkPress at this time has had a development hosting on wp-plugins.org for quite some time, but it didn't have a user interface at all, so users were not able to browse plug-ins and conveniently find more information about plug-ins and find a plug-in that would address their need in the way that it was possible with this new plug-in directory. It was built on BBPress, which made sense at the time because WorkPress did not have a custom post-type like it does today, and so, yeah, I decided to use BBPress, which is still run on today. The current version of the plug-in directory still uses the same BBPress installation. Mike Adams, Marc Jacobs and MT were the ones who worked on this project. This is a screenshot of the single plug-in view, which looks almost nothing like it does today. The plug-in directory over time has undergone quite a few iterations on design updates. One of these design updates was done around 2009, where WorkPress 2.7 was released and introduced also a new WP Admin design, and so WorkPress.org's design, including the one for the plug-in directory, was informed by that. You have the dark header and the light blue sub-navigation here. When we look at the single plug-in page, again, here it's Akismet as an example, it looks much more familiar already, you know. We have this big download button to the top right that we still have today, and we have tabs to split up information and, you know, make it easier to navigate. And of course, on the right-hand side, we have more meta-information about the plug-in, and this structure basically lived on until today. In 2011, there was yet another design update. We have the gray header, and also plug-in banners were introduced. And for the first time, plug-in authors had a way to individualize their plug-in detail pages a little bit more than just with, you know, text out of their README files. It was a huge success. A lot of plug-ins adopted that right up from the start, as I want to say. And it's still used today, of course, and will definitely be used in the future as well. Last year in April, the plug-in directory saw its latest round of updates, introducing the card view that was added to WP-App and in WordPress Core. And to make that more recognizable on the plug-in directory side as well, this was taken over from there. It was just released a couple of months after we finished our work on the new themes directory, which, again, was inspired by the way that WordPress Core does the theme management screen. The technology, as I said earlier, throughout this time for the plug-in directory remained the same. And so this was one of the things that made it really... Yeah, it didn't make it easy to get started working on WordPress.org projects for me personally, because I never really worked with VBPress before. The theme directory was the first project for myself to work on the WordPress.org infrastructure. And as a developer, when you first dive into a new code base and try to understand and learn how things work, you don't ever want to encounter a comment like this. This preceded the code that managed theme downloads for the theme directory, the old theme directory. And so it kind of gives you an idea of the challenges we faced doing that shift. The directory that we're currently working on that we hope we'll be able to release in 2016 fully. I want to talk about that and give you more of a broad idea of what we try to achieve with it and where we go in the future. Some of our goals that we discussed when we first started working on it in February was, of course, open sourcing the directory and the plug-ins API. This is an integral step to make sure that more folks can get involved in contributing to the plug-in directory and also stay in sync with the philosophy of the rest of WordPress. And, yeah, continue to foster the open-source idea as well. Our second goal was to use WordPress, which is, I know, ground-breaking. But it's something we thought we should do. It also helps people to contribute to the WordPress directory code or anything on meta because a lot more contributors are familiar with WordPress than they are with BebePress. And so writing the new plug-in directory from scratch using WordPress allows us to open-source it and have more people involved in that process. Those first two goals are kind of achieved or will be achieved just by working on the directory. It's not really something that we had to work hard on. It's just something that came with working on the project. The first thing that we did have and continue to work hard on will be enhancing user experience, which is an integral part of the new plug-in directory. The directory has grown significantly since its inception in 2007. We have now almost 45,000 plugins. And everyone here who has ever tried to find an SAO plug-in and find the right SAO plug-in for themselves knows that it can be daunting to weed through, I don't know, how many hundred SAO plugins we have currently in the repository. So making that experience better and making it easier for users to find the specific plug-in that they're looking for is our number one priority with this project. This goes hand-in-hand with improved search. Search is one of the most used actions on the plug-in directory. And so improving that will help us and go a long way in improving the overall user experience as well. And last but not least, achieve a scalable review process. Currently, plugins are being reviewed almost like themes in a theme directory, with a big difference that the plug-in review team is a set of, I think, five people who have access to that. And the majority of reviews are done by just a couple of reviewers. So making it easier and more scalable will help, yeah, keeping that queue short, as we just talked about with the themes in the Q&A in the previous session. And make sure that these queues that we see over there will not appear and will not be likely in the new plug-in directory. If you're interested in kind of getting idea of how it looks like under the hood, this is a good diagram for that. We have a regular WordPress theme as the basis. And then a plug-in that together with WordPress itself, of course, powers that site. The plug-in uploader and the plug-ins API are technically part of that plug-in, but I separated them out because they're so important to the directory. First of all, the plug-in uploader is something that we would like to try in this iteration. Much like we have had an uploader with themes for quite some time, we thought that adding an uploader to the plug-ins directory could help with automated code tests for plug-ins. So that plug-ins who don't satisfy basic requirements don't even make it to the review queue in the first place, but rather give straight feedback to the plug-in author and give them an opportunity to fix basic errors and re-upload those plug-ins for a proper review. And then, of course, the plug-ins API, which is based on the WordPress REST API. And it also has a compatibility layer to work with the plug-ins API that your WordPress installation uses to ask for updates to current plug-ins or to plug-ins that you have on your sites. As I said, plug-in consumers are on the forefront of this transition for us when we started working on it and trying to gather requirements. This is one option that we think or one design that the plug-in directory could have. Using a centralized search slot, which is more prominent than it was now, because we are confident that we will be able to provide better results. And so making that search bar more prominent will lead to a better user experience long-term. Search is a better way to find what you're looking for than exploration. And so this is why we think having a central search bar would be something that users would appreciate. On the homepage, we also have different kinds of sections that we could change at any point in time. Having beta plug-ins, for example, and featuring those and getting more users involved in testing our feature plug-ins or feature projects would be a good idea. We could also experiment with various data sources and have feature plug-ins or the most popular ones, which is in the current version of the iteration on the homepage. As you can see, it's also design-wise. There's a lot more white space than there used to be. Font sizes are bigger. This is also one of our, yeah, some of the feedback that we got from users is that the current font size is fairly small. So we try to accommodate that and increase that in the new iteration. For search, we're now using Elasticsearch servers. It was part of the diagram that I just showed. Elasticsearch is more modern than the Sphinx search that we used previously, or used currently, as a matter of fact. Elasticsearch is better supported. We have a lot more know-how in the community around Elasticsearch. And it's more flexible. It allows us to incorporate extra factors in the ranking of plug-ins for search drills.