(for # questions, take a few guesses, then ask the audience which they think is right (raise your hand))
When I started working on this presentation, I wasn't sure how I was going to present it. Generally, I form an outline and then build slides based on that. But this time my outline was just a list of people and teams and I wasn't sure how to turn that into slides in a meaningful way. So I just started writing.
Next thing I knew, I had a 4,000 word speech. I've never delivered a long speech at a conference, so I wasn't sure how it would go. Yesterday, during the morning presentations, I was talking to Monika about this and we started joking about displaying random images as refrencing them as if they were part of the presentation.
Then in the afternoon, John Dimm gave his Fun with Speech presentation. In his presentation, John showed an app he built called TalkShow. TalkShow listens to your conversation and shows flickr images based on what you say. So for the duration of this talk, I'm going to have TalkShow running on the big screen.
::Turn on TalkShow::
When most people think of jQuery UI, they think of a set of JavaScript widgets. The typical user doesn't think about how jQuery UI is built, the decisions behind the designs and implementations, or who's involved in the project. This isn't unique to jQuery UI though. When using a library, whether it's open source or not, developers tend to focus on the released code as opposed to the team and process behind the code.
So, I'd like to start by getting an understanding of how this audience views not only jQuery UI, but jQuery projects in general.
How many people do you think are on the jQuery UI team? 8
And how many people do you think are on the jQuery core team? 9
For perspective: there are 9 people on the jQuery core team, 37 on the full team, a little over 400 of you in the audience, about 15 million people employed to create web sites and approximately 60 million sites using jQuery. With over seven billion people in the world, it's probably safe to say that at least one billion people are end users of jQuery. And this is the team managing all of that.
To date, there have been 1,200 pull requests for jQuery UI. How many do you think were from the community as opposed to committers on the jQuery UI team? 900
Since moving to GitHub, there have been 3,576 commits to jQuery UI. What percent do you think are from the community? 13%
Other than what is essentially a collection of random users on GitHub, what other teams or projects do you think the jQuery UI team works with?
We actually work with a number of different teams and groups, ranging from other open source projects to standards bodies and browser vendors.
As I mentioned earlier, we have millions of direct users and at least a billion end users. This means that we don't really have an archetypal user. Our users range from designers to inexperienced developers to highly experienced developers creating applications and frameworks. Our end users might have fiber optics running straight into their houses or they might be connecting over slow, shoddy cellular networks. They might have small low-res screens, retina displays, screen magnifiers, or even screen readers.
Yet we try to provide the best user experience to everyone. Doing so requires us to rely on the knowledge and help of others. Working with other teams is mutually beneficial because we can provide feedback and insight from our vast user base and past experiences.
A few weeks ago, during our annual State of jQuery series of blog posts, Dave Methvin wrote about the jQuery Foundation's involvement in standards. Members of the jQuery team are involved in all aspects of standards, working with WHATWG, W3C, and ECMA TC39. But for this talk, we'll focus on the direct involvement of the jQuery UI team.
With the new input types and other APIs being introduced in web standards, it's becoming increasingly more common for there to be overlap between jQuery UI and web standards. This provides a great opportunity for jQuery UI to provide feedback to the standards bodies.
For example, when the new number-based input types were added to HTML5, we were working on our implementation of the jQuery UI spinner widget. We noticed that while our stepUp() and stepDown() methods defaulted to taking one step, the proposed WHATWG spec had a default of zero steps. This essentially meant that these methods were desigend to be called with exactly one parameter. So we posted a message on the WHATWG mailing list about the expected behavior and a week later the HTML specification was updated.
Providing feedback based on actual usage by web developers is greatly beneficial to the standards process. The standards bodies and browser vendors love being able to test APIs through JavaScript implementations before finalizing them in a specification or implementing them directly in a browser. We're starting to see projects like Polymer take on this work to find pain points and iterate on design prior to finalizing the associated specifications. With jQuery UI being used on over six million sites and averaging ten thousands downloads a day, we're able to guage how users respond to various implementations.
One example of this is focus handling within dialogs. We've tried a few different implementations, and we're still trying to figure out if there are better methods for determining which element should be focused when a dialog is opened. Unfortunately right now, the ARIA specification and the HTML specification disagree on what should happen. And we have plenty of user feedback indicating that neither implementation is ideal. So we'll keep iterating on ideas until we find something that we think works the best, then we can work with the W3C and WHATWG to try to get the various specifications aligned with each.
And of course, there's touch support. How many people in the audience have heard my spiel about why Touch Events aren't supported in jQuery UI?
Back in February 2009, Paul Bakaus filed a ticket to add touch support to jQuery UI, along with a patch. I pointed out that supporting a proprietary event system via user agent sniffing wasn’t a good idea. It would have been easy to replace the iPhone check with a proper feature check, but that wouldn't have helped with the mess that would ensue over the next few years.
Because Touch Events only existed in Apple's proprietary fork of WebKit, there was no open standard for us to follow. You could certainly argue that ideological zealotry has held us back while other libraries have added rich functionality for touch devices. But I'd like to point out what happened by allowing Apple to design this event system in private and have web developers either accept or reject it without any official standards work for two and a half years.
It took one and half years just for touch events to land in the main WebKit repository, and the implementation was reverse engineered by Google. Half a year later, Mozilla landed their own touch events system in Firefox 4, with a very different API than WebKit. Unfortunately this never caught on, likely due to the difference in market share on touch devices. At this point, I have to ask my favorite question: Has anyone in this room ever used Mozilla's touch event API?
Eventually, Microsoft released IE 10 Developer Preview with yet another approach called Pointer Events. In man ways, Microsoft's pointer events are closer to Mozilla's touch events than Apple's touch events. Regardless, at this point, we had three different event models.
During this time, Mozilla abanonded their event model for web compat and the W3C formed the Web Events Working Group to create an open specification for Touch Events based on the WebKit model. This Working Group had representation from every browser vendor except for Apple. But even the working group wasn't really happy with the standard.
I represented the jQuery Foundation in this working group and tried to bring community awareness to the issues around touch events, which included legal issues around patents, awkward APIs, and a dreary future. As part of this work, I published a blog post with a call to action for Microsoft to submit a proposal for the W3C to standardize pointer events.
I'm happy to say that Microsoft did submit a proposal and there is a Pointer Events Working Group that is making great progress. Chrome, Opera, and Firefox are all on their way to having Pointer Event implementations, and we're working with the Polymer team to get a polyfill in front of developers for as many browsers as possible.
We want to make sure that everyone starts using Pointer Events as soon as possible, so we had discussions with MS Open Tech and the Polymer team to figure out the best path forward. We decided that leveraging Polymer and adding a layer in jQuery to make oldIE work would be the best approach. At this point, we've pushed some changes upstream to get Polymer to parse in oldIE and we've added hooks for jQuery to provide the missing support for event handling in oldIE.
We have a proof of concept in the jquery-pointer-events repo if anyone is interested in helping get pointer events ready for everyone to use. jquery-pointer-events will serve as a base for the interaction rewrites planned for jQuery UI 1.13 and will also replace the virtual mouse abstraction in jQuery Mobile.
When I discussed focus handling for dialogs earlier, I mentioned ARIA. How many people know what ARIA is? ARIA is a set of attributes which define roles and states to extend the semantics of HTML. The attributes are mapped to the accessibility API provided by the operating system.
Accessibility testing is actually quite difficult. There are a variety of disabilities and assistive technologies to account for. Even given a seemingly straight-forward tool like a screen reader, it takes a lot of knowledge and experience to use assistive technology in the same manner as someone who relies on the technology every day.
And just like conforming to the standard HTML and JavaScript APIs won't protect you from browser bugs, conforming to the ARIA specification won't protect you from assistive technology bugs. In order to ensure jQuery UI is as accessible as possible, we work with various individuals, teams, and communities.
We've worked with the Inclusive Design Research Centre at OCAD University, The Paciello Group, Deque Systems, Mozilla's accessibility team, and more. Members of our team are also active on the WebAIM mailing list, which is a great resource for anyone looking for accessibility help or advice.
In 2011, we organized an ARIA hackathon in collaboration with the IDRC at OCAD University. The event was open to the public and was intended to provide a full range of information on accessibility and ARIA, as well as reviewing and improving jQuery UI's accessibility. There were several great presentations, including an overview of how accessible information is exposed at the browser and OS level by David Bolter, the accessibility engineering manager at Mozilla; a walk-through of various assistive technologies by Colin Clark, the lead software architect at the IDRC; and a real-world demonstration of screen reader usage for various tasks by Jennison Asuncion, a blind accessibility consultant.
Even with all this expertise, most things still don't have a clear, straight-forward solution. For example, when implementing autocomplete, the ARIA specification provides three different models based on how focus is managed and whether the value of the text field is updated during navigation.
Given the model that we use, where a list of suggestions is displayed, but the text field retains focus, the specification requires us to use aria-activedescendant to indicate which item is active during navigation. Unfortunately, this presented a variety of issues in different browsers. After extensive testing and discussions with several groups, we decided to use live regions to effectively hack around the problem.
Live regions provide a buffer of text that should be announced. By resorting to live regions, we basically throw semantics to the side and provide verbatim text for the assistive technology. This makes live regions to ultimate fallback, but it's a fallback that comes at the price of starting from nothing.
Surprisingly, even this isn't enough as we recently discovered thanks to Dylan Barrell from Deque Systems. Our initial implementation used a polite region, which announces updates at the next graceful opportunity, and we changed the value to always contain the most recent announcment. The intent was that if a screen reader was being noisy and the user navigated quickly, only the most recent message would get announced, since that's the most relevant data.
Dylan's solution was to use an assertive region with aria-relevant="additions" and to hide the previous messages when adding a new one, rather than replacing the old message. This resolves issues in a few screen readers. JAWS, a popular screen reader for Windows, would announce deletions even with aria-relevant="additions" and VoiceOver, the screen reader for OS X, would sometimes re-read all the messages, not just the additions. The combination of aria-relevant and hiding old messages works around these bugs. So now we have a hack on top of a hack just to announce the suggestions while navigating through an autocomplete list.
And you all thought dealing with IE6 was a pain.
Accessibility is an extremely large problem to tackle and while many developers are aware of the basics, most developers don't have a deep understanding of all the intricacies involved. That's why it's so important for us to work with the larger community to find the right people with the right knowledge.
Dealing with globalization, or localization and internationalization, is the same. How many people have dealt with internationalization in a project they've worked on?
For a long time, the only part of jQuery UI that dealt with globalization was the datepicker widget, which has always had support for various languages. We've been relying on the community to provide the values for each locale for several years now. This is a really haphazard way to manage data. We're constantly getting pull requests to add or fix locales.
A few years ago, we decided that we should have a more comprehensive solution. So we started working with Microsoft to build a new project called Globalize. Dave Reed built the initial implementation based on Microsoft's .NET implementation. We primed the locale data with a JSON representation of the .NET data. While this increased our number of locales from about 70 to 350, we were still using a custom set of data, so the pull requests kept coming.
We looked at what else was available, and decided that the Unicode Consortium was the best resource to look to for a canonical data source. So we're now switching Globalize to use the Unicode Common Locale Data Repository, or CLDR, and stop maintaining our own locale files. This is a massive undertaking and is being led by Rafael Xaviers.
Delegating to CLDR for all data also makes it easier to collaborate with other projects that have a focus on globalization. In fact, we're working with developers from moment.js and Wikipedia to ensure that end users can use a single set of data for multiple tools. The Unicode Consortium's main files are in XML, but they've recently started to provide the data in JSON. We've found some issues with their JSON files, so we're working to get fixes and other improvements upstream. Rafael has also created cldr.js which makes it easy to pull data out of the JSON files. This serves as a low level utility for other projects to build on top of.
We're holding regular meetings with Wikipedia and moment.js to make sure our goals stay aligned and keep collaboration as productive as it can be. You can expect future versions of moment.js to use CLDR and to play well with Globalize. The vast amount of localized content that Wikipedia deals with will ensure that we're providing solutions that scale and meet the various needs of the community.
We've also reached out to Twitter since they have a CLDR project as well. They've expressed interest in decoupling the data from their JavaScript implementation, but they don't currently have time to tackle that.
If you're interested in hearing more about Globalize, you should attend Rafael's talk right before lunch.
We also spend time collaborating with other open source projects that use jQuery UI to ensure that we're providing the functionality they need. As you're probably aware, jQuery and WordPress have a great relationship. WordPress is a founding member of the jQuery Foundation, and a diamond sponsor of this conference. Andrew Nacin, Lead Developer for WordPress, spent a lot of time helping us setup our custom WordPress network that powers all of the jQuery sites.
The WordPress team is also extremely fast at updating when new versions of jQuery and jQuery UI are released. Just like jQuery can help standards bodies by getting code in front of lots of users, WordPress is able to get new versions of jQuery in front of lots of users with their huge install base and Automattic's hosted solution on wordpress.com. They can even get betas and RCs in front of many of their users, providing essential feedback before stable releases.
Most recently, we worked with members of the WordPress team to land support for the CSS touch-action property in jQuery UI interactions. This allows widgets like draggable and sortable to work properly on Window 8 touch devices, and will soon affect other devices as well.
Landing touch-action support actually turned out to require even more community collaboration, and I think this is a great mini-story in itself. When TJ VanToll put together the pull request, our unit tests failed because we validate our CSS with grunt-contrib-csslint. Because touch-action is so new, the linter was identifying it as an invalid property. As you might expect, grunt-contrib-csslint relies on Nicole Sullivan's csslint to do the actual linting. csslint in turn relies on Nicholas Zakas' parerlib to determine what is and isn't valid. So TJ sent a patch to add touch-action to the parserlib module and then we had to wait for that to propagate all the way back to grunt-contrib-csslint. This is the kind of collaboration that we love to see happening throughout the open source community.
We also have two-way collaboration with the Drupal team. Members of the Drupal accessibility team have provided a lot of testing and suggestions for improvements. We're also working on increasing our collaboration by replacing Drupal's own custom JavaScript widgets with jQuery UI widgets. This frees up their team to focus on building a solid CMS rather than dealing with all the intricacies of individual widgets. In the past, we even adjusted our roadmap to ship accessibility updates that were blocking Drupal from using jQuery UI's dialog widget.
We want to make sure that we're serving other open source projects as well as we can. So if you're working on a large open source project that uses, or should be using, jQuery UI, and you have concerns about jQuery UI, you should contact us. You can even find me in the hallway or at lunch.
We've also created tons of open source projects ourselves to support jQuery UI or improve our workflow. Many of these tools are used in several jQuery projects or by several jQuery team members.
During the course of a normal day, I probably view diffs dozens of times. But viewing diffs in Terminal just doesn't compare to GitHub diffs. So I built pretty-diff, which has the same API as git-diff, but generates a GitHub-style web page for the diffs.
When I'm happy with my changes, I run tests through Grunt. How many people are using Grunt?
We've built a few grunt modules that we use in jQuery UI. Jörn Zaefferer, dev lead for jQuery UI, created grunt-html, which lints all of our demo and test files to ensure they're valid. This module builds on top of validator.nu, and we worked with Mike Smith to get the necessary updates into validator.nu to make this possible.
Jörn also build grunt-css which handled CSS minification and linting, but that has been replaced by grunt-contrib-cssmin and grunt-contrib-csslint, which he helps maintain.
Once I'm ready to commit, Jörn's newest project, commitplease, ensures that my commit message conforms to our commit message style guide. This runs as a commit-msg hook and rejects the commit if the message isn't valid.
After I push the commit to GitHub, we kick off a job in TestSwarm. We use node-testswarm, also written by Jörn, to submit the appropriate tests. Then we spawn BrowserStack clients using testswarm-browserstack written by Clark Allen, which uses one of my modules, node-browserstack, to spawn the BrowserStack workers.
Every once in a while, we need to track down where some code came from, or why something is done a certain way. Although git-blame helps here, recursively looking through history is pretty painful, even on GitHub. So I built a tool called recursive-blame, which will walk through history finding matches for a regex pattern. This will follow file renames and can even be used to find when a certain block of code was removed.
We also maintain a list of all contributors to jQuery UI in the AUTHORS.txt file. In order to keep this up-to-date, I created a grunt task called grunt-git-authors which just looks through the history and generates a list of unique authors, in order of first contribution, and honors the mailmap if there is one.
How many people use IRC notifications for GitHub events? Has anyone configured notifications for events other than commits? Do you remember how you set that up?
GitHub's service hooks are great. But they're a huge pain to setup if you want notifications for anything other than the default set of events. Each service hook has it's own settings panel, but none of them allow you set which events the hook should apply to. The only way to set the events is through the API. And it takes a bit of work to do so since you can't get the hook's id through the UI.
So I created a module called hookup which makes it easy to manage your service hooks. It's a node module that's designed to be installed globally and provides a CLI for managing your web hooks. You can also use the module directly in node to manage any type of hook. We use this to setup our IRC notifications for pushes, issues, and pull requests.
Hookup builds on top of a simpler module, github-request, which simplifies API calls to GitHub.
Finally, we have the tools used for managing our web site. Even though we use WordPress for all of our sites, we manage our content in git and host it on GitHub. In order to sync the data between git and WordPress, we use grunt-wordpress which builds upon node-wordpress, which utilizes WordPress' built-in XML-RPC API.
During the transition to the new site setup, we were updating our dependencies pretty frequently. We noticed that most of our team didn't run npm install often enough, so their local dependencies wouldn't be up-to-date. In order to catch this as soon as possible, Jörn created the grunt-check-modules task which will fail the grunt run if the dependencies aren't correct.
Again, all of these tools are open source and built to be used in other projects. While we built them to help with our work on jQuery UI, we've found them invaluable when working on other projects as well.
Finally, I'd like to mention the support that we have from browser vendors. Some browser vendors are better than others when it comes to bug tracking, but that's something that affects all developers, so I won't go into detail about that. However, I would like to say that Chromium has a meta ticket for tracking tickets that affect jQuery.
But even outside of the bug trackers, we have direct lines of communication with all of the browser vendors other than Apple. Tony Ross from Microsoft has been a huge help with tracking down and working around IE bugs. Boris Zbarsky from Mozilla is our Firefox liaison and a great resource for information about web compat, history, and general questions.
Mike West and Paul Irish from Google are available in the jquery-dev IRC channel, along with Mike Taylor from Mozilla, previously from Opera. We also use non-jQuery IRC channels and mailing lists to communicate with several others.
Hopefully this look behind the scenes of jQuery UI has shown how important the community is. We wouldn't be as successful as we are today if it weren't for the help of countless others.
Raise your hand if you've ever contributed to any open source project. Let's give everyone a round of applause.