 Bonjour and hello everyone, can I see a show of hands? Who here thinks chocolateein when they see this picture? Anyone? All right. And who thinks that's very clearly a pan of chocolat? All right. All right. So thank you for our very first survey here. And now that we have so very clearly separated the heathen from the civilized ones, we can move on to less controversial topics. When we started all of this, we had one question in mind. What are the biggest frustrations for web developers and designers today? And I wish answering that was as easy as the survey that we just did. Spoiler alert, it's not. But before we jump into that, a quick intro first. So this is CSS Grid. CSS Grid is a web platform feature that allows developers and designers to lay out a page in two dimensions instead of just one. This was the case with floats and flexbox. And this project that I'm going to talk about, it started shortly, in 2017, shortly after CSS Grid was released. And CSS Grid was a massive success. So in Mozilla's developer relation team, we asked ourselves, how can we support that more? How can we get more of these wins? And how can we, yeah, how can we repeat that? So CSS Grid was a success because it dressed a real user need. And it shipped in all the browsers at roughly the same time and came with tooling, like in the case of Firefox with the grid inspector. And that was seriously awesome. That said, CSS Grid was literally years in the making. And layout had been an issue for developers at least since the times we abused tables to implement our layouts in the 90s. So looking at this, we had a few questions. Why did it take until 2012 to even start addressing that problem? It was very obviously a problem even before that. And why did it take until 2017 to ship something? And how was this coordinated for shipping at roughly the same time? Because most other things are not. And what were the roadblocks? And what were the things that were pivotal to moving this forward? So we took a step back to see what the whole process looked like from Mozilla's perspective. And after interviewing numerous people involved in the process, we identified three distinct phases. There is research, there is standardization and implementation, and there is adoption. Now as you can probably tell immediately, this is a very simplified version that really smooths out many things. And this looks like a pipeline when in reality it's more like a loop or a loop of loops that loop back on themselves. I mean, you get the idea. But this was good enough for us to get started. Most of us had a pretty good idea about the adoption side of things. Because that's really where MDN shines. And we had some idea about the standardization and implementation phase. But we wanted to know more about the research part of this. So how do we learn about developer pain points, what they need, and what we should prioritize for the web platform? So we interviewed more than 10 people involved in different stages of that process. And it became clear that there was no formal research, really. At Mozilla, we have an amazing team that does user research for Firefox. But that's for end users. There's not so much the case for when it comes to developers. We just don't have those resources. And it's important because at a place like Mozilla, as I said, we do have limited resources, so we can't go after everything. We can't just throw everything at the wall and just see what sticks. There are some serious opportunity costs that we have to pay when we decide to do something, because it usually means that we cannot do something else at the same time. And this is what we heard from people about how things are prioritized. So when we talked to people involved in this process at Mozilla, like we haven't tried formal research, like it's all ad hoc. But one thing stood out because every single one of them said the same thing here. We need to hear more from developers. That really stood out to us. And it makes so much sense because none of us can be really successful without that part, without having that. It's hard to prioritize the right things without knowing about developer pain points, and it's hard to find the right solution. And it's hard to get people to adopt something that doesn't solve their problem or doesn't solve the problem in the right way. So for all of these reasons, we proposed a developer needs assessment. What is that exactly? It's a prioritized list of web designer and developer needs. It's a single and simple tool for harsh prioritization across a massive feature space and extremely diverse populations. It's published on MDN. It's not owned by a single browser vendor. So we initially proposed this under the umbrella of the MDN product advisory board, where we have representation from browser vendors, but also from the W3C and industry stakeholders. Because as a community, we have to have at least a common understanding of the facts when it comes to developer pain points and developer needs, even if you draw different conclusions from them. And finally, it's reproduced annually. And this is important. As an industry, we need to know whether we are addressing developer pain points and to understand whether we are prioritizing correctly, we need to track things like their needs and pain points over time so we can see the impact of our own efforts. That's why we need to do this regularly and not just once. And if you do this well, we think the MDN web development needs assessment, or MDN web DNA for short, we think that it can be a voice of designers and developers working on the web. But as I said, asking developers and designers about their needs and frustrations is not trivial. So I think it's important to know that there are some spaces really vast and the audience is extremely diverse. So let me tell you a little bit about the process we went through for that, and I'll make that short, but I already apologize upfront because I'm not a researcher. We worked with a very talented Alison McKeith from Pinpoint Research to design for the research design and to also conduct this. So I'll do my best to channel her here. I'm not a researcher. So in January this year, we started this process by fielding a survey to our product advisory board. And we asked them for data that they would use for decision-making as part of their planning process. And we then had almost 20 in-depth interviews, almost one-hour long interviews each with web developers from around the globe. And we did that before putting the initial version of the survey together. And that's important. That's because we wanted the survey to be rooted in the voices of developers and designers from the get-go. Because if you had run with what browser vendors wanted, the questions would have been based on the internal perspective of browser vendors. By conducting the interviews, we made sure to derive the survey questions from the stories of developers and designers about what was important to them in their work. But also what caused them frustrations. And so to go from interview findings to the surveys, we followed Pinpoint's analysis process, going from observations. That's what we heard and saw. To insights, what it means really to critical themes. That's why it matters. And we are continuing that process to incorporate the survey findings into what we learned from the pilot interviews. So in practice, that means we transcribed 16 hours of interviews. We then coded them and we finally bucketed them to derive insights for the items in our survey. That's a very hands-on approach. But based on these themes, we constructed the central survey question around the frustrations of developers and designers. We then continued to work with our product advisory board on the overall survey with pilot interviews where we watched multiple people take the survey at every iteration to really ensure that survey questions would be as unambiguous as possible. And with the help of more than 30 stakeholders from various MDM PAB member companies, we have put together the final version of the survey and it was fielded in July and August of this year. We fielded an MDM, but not just an MDM. Also through the channels of our product advisory board members, that's a W3C, that's Google, Microsoft, Samsung, and Bookful. We didn't do that just in English. We localized the survey into eight languages. That's Arabic, simplified Chinese, English, French, Japanese, Korean, Brazilian, Portuguese, Russian, and Spanish. I'm very happy to announce that after fielding the survey for four weeks, more than 76,000 people took us up on it and more than 20,000 developers completed the full 20-minute survey. And that was in 173 countries total. So just for the complete responses alone, that's more than 10,000 hours of time contributed by the community to help us understand what their pain points and needs are. And we believe that makes the MDM and WebDNA the biggest web developer and designer-focused survey that's ever conducted. And with that scale, come benefits. So we can segment that data by experience level, developer role, country satisfaction, and we still can get useful information out of that. So after this intro, you might be interested in the actual results. As I mentioned, we had participants from 173 countries across the globe, but of course that's not uniformly distributed. So you can see that just six countries here make up more than half of the participants, and that's the US, China, Russia, India, Germany, and France. And it's a little bit surprising because we didn't even translate the survey into German. That said, we still have a pretty good representation from Europe, Asia, and North America. But especially with Africa, we can really do better hopefully next time where we just got 2% of our responses this year. So one segmentation we were interested in was developer types. There is, of course, the classic split between front-end and back-end. But recently, people have started talking about front of the front-end and back of the front-end. There is no generally understood term for this. We really tried to find one. So in the end, we asked whether people used primarily JavaScript on the front-end or CSS and HTML. That's what most people understood. And as expected, given our audience, only a small number of people saw themselves as back-end developers. And we had curiously an even split between, mostly an even split between JavaScript and CSS plus HTML. But we had way more people considering themselves full stack developers. In terms of experience, our industry is, of course, growing at an incredible pace, so it shouldn't be too surprising that one-third of all participants had less than three years of experience and almost two-thirds of all participants had five years of experience or less. And speaking about representation from previous surveys, we were aware that we would have to make an extra effort and a special effort to get better gender representation. And we did do that, but unfortunately, we didn't fully succeed with that. So women participated at a rate of between 8% and 12% in our survey. And unfortunately, there are no global general population numbers when it comes to software development. But we know from U.S. numbers that women are represented at about 20% in software development, and that's clearly not what we've achieved here. So that is a clear bias in our survey. And it's one we want to better account for in future iterations of this. But for now, we want to at least acknowledge the bias. And we also ask you that you take that into account when interpreting the results. All right, that was a demographic breakdown. But what about actual results? So without further ado, here they are. All 28 needs from biggest frustration to least frustrating. And I want to draw your attention to the top five and the bottom five. So I'll talk a little bit more about the top five and top 10 in a moment. But when we look at the bottom five, there are some surprises at first glance. In particular, number 24, making sites accessible. People who have worked on this know that there are many frustrations involved with that. So why is it ranked so low? And from our interviews, we think it's because accessibility is usually deprioritized. And developers who don't get to spend time on it never notice the issues that are inherent in that work. And that example should make clear that context is super important when interpreting results. So this is a quantitative study. You can answer what and how many, but you can't answer why. And that's why we did the in-depth interviews to get the context, which is also part of our full report. Let's focus on the top 10 a bit more. One thing you might have noticed is that four of the top five items are in a similar bucket. It's web compatibility and interoperability. One of the biggest strengths of the web is that there is no single entity controlling the platform. But that does not come for free. Web developers and designers are frustrated by not being able to use features to find workarounds for things. By having to fiddle with browser differences and by the difficulty to verify that something that works in one browser will not break in another browser. There is another bucket here, though. It's less clear cut, but it shouldn't be too surprising, especially at this conference. The web is not just HTML, CSS, and JavaScript. It's the ecosystem of libraries and frameworks and tools as well. And there is no standard library for the web. There is no default way to build web applications on the web. And that, again, comes with upsides and some very specific drawbacks that manifest here in these frustrations. Documentation and sample code is almost always the top priority for web developers. And generally, all developers, really. But handling multiple frameworks and keeping up with the ever-changing landscape is something that developers find frustrating at a very high rate. I mentioned before that one benefit of large numbers, or large number of participants, really, is that you can slice the data and get more useful results. There is one such segmentation, the top five frustrations between some of the top countries in the survey. And you'll notice that there is very little variation between those countries, despite those being very different markets. But they all share the same top frustrations. And as you know, the pace of change on the web is incredible. So we asked people what their biggest barrier for entry was when it came to new technologies, or when tech becomes available. New tech becomes available. And the results very much, they match the frustrations we talked about earlier. Interoperability and documentation are the leading issues when it comes to why people might not jump on some new tech. This is something to keep in mind. And so far, we've talked about what is available and causing issues, but we were equally interested in what it is that people felt was missing from the web. So we asked, what are the things that you would like to be able to do on the web, but lack web platform features to do? And we had a massive long tail of a wish list, as you can see here, represented by the other category, with 2% of mentions each. And on the other hand, the biggest category by far is about access to underlying devices, USB, Bluetooth, camera, SMS, and all kinds of sensors. We broke out access to the file system as its own category that you can see here, as the biggest request within that larger access to hardware category. And in a similar vein, developers want access to native APIs for contact lists, calendars, and other features of the underlying operating system. And of course, you will notice once again, browser compatibility is very high on the wish list, because what good is a feature that is standardized and shipped in a browser if you can't use it because it doesn't reach that threshold of availability? So I know that this was a bit bleak, so before we finish, I have some good news. We wanted to have one measure that would help us understand what the current sentiment is among web developers and designers. So we asked, how would you rate your overall satisfaction with the web as a platform and set off tools to enable you to build what you need or want? And a full 76% are either satisfied or very satisfied, and only 9% are dissatisfied or very dissatisfied. So while there is room to grow, the web is really an amazing platform indeed. And by understanding what developers and designers spend their time on and identifying their biggest frustrations, we can focus our attention on those and help make things even better than they are today. Which is, well, I'm very happy to share some of the responses we got from browser vendors in response to the survey. So Google came out with a very strong endorsement, and I want to thank the team for that. They said the Google web platform team is now using developer satisfaction, that's the measure from just before. That they're using that as one of our top level success metrics. We're excited to be using the MDF web DNA as one of the main sources of data to help us understand and prioritize the key areas of developer frustration. We shared an earlier version of this report at TPAC in September, and it was very well received by the W3C, which makes me very hopeful. And not surprisingly, Mozilla is on board as well. And what they said was, in the Firefox team, we are always listening to our community's needs in order to make product decisions. And the comprehensive overview of the developer community's needs provided by the MDM DNA report is therefore absolutely essential to us. And we are already incorporating its findings in our plans. So what I just presented, and much more, will be in the full report that we intend to publish this year still. You know, it's already the 12th, but very soon. And we will make it freely available to everyone. I want to thank all of our product advisory board members for their support here, and we invite everyone to use the results to shape their roadmaps to better reflect the needs and pain points of developers and what developers express as their frustrations. But as I said, we want this to be an annual thing, so the next iteration will start in March 2020. We will field the survey in May, and we will publish the results in September 2020, hopefully in time for TPAC 2020 and the 2021 planning season. And with that, well, merci, au revoir.