 Welcome, everyone. Please be seated. Don't stay on the stairs. And the better you are in the center, the better for the room, so people that are late can join. Kedir is going to talk to us about frustrations for web designers and web developers. Kedir, the show is yours. All right. Can you hear me all right? Cool. So can I see a show of hands? Who here thinks Chocolatine when they see this picture? Well, there. Let's see a show of hands. And who here thinks that is clearly a part of Chocolat? All right. OK. So now that we have so very obviously separated the heathens from the civilized ones, we can move on to less controversial topics. Hi, I'm Kedir. I'm the product manager at MDN, MDN WebDocs. And we started all of this with one question. What are the biggest frustrations of developers and designers on the web today? And I wish answering a question was as easy as the survey that we just did. But before we jump into that, a quick intro. So this is CSS Grid. And CSS Grid is a web platform feature that finally allows web developers to lay out a page in more than one dimension, in two dimensions, actually. That was not the case with floats and flexbox. And this project that I'm going to talk about, it started in 2017 shortly after CSS Grid was released. And CSS Grid was a massive success. So yeah, CSS Grid was a massive success. It was shipped in most of the major browsers at the same time. And it was shipped with tooling, the Firefox Grid inspector in this case. And it was seriously awesome. That set, CSS Grid, was years in the making. And we've known that layout has been an issue for web developers at least since the late 90s when we abused tables to develop our UIs for the web. So looking at this, we had a few questions. Why did it take until 2012 to even start working on this? And why did it take until 2017 to ship this? When we've known for so long that this was an issue for web developers. And how was this coordinated to ship at roughly the same time? Because that's not a very common thing, like that most major browser vendors shipped it at roughly the same time. And what were the roadblocks? And what were the pivotal elements that actually helped to move 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 who were involved in the process, we identified three distinct phases. The first phase is research. The second one is standardization and implementation. And the third phase is adoption. Now, as you can probably tell immediately, this is a very simplified view of the process that really smooths this out over many things. And it looks like a pipeline when it's actually more a loop or a loop of loops that loop back on themselves. I mean, you get the idea. But it was good enough for us to get started. So most of us on my team had a pretty good idea about the adoption phase, because that's really where the end shines. And we also had a pretty good understanding of the standardization and implementation phase. But what we were really interested in was research. So what we wanted to know more about was how do we learn about web developers? What web developers needs? What their pain points are? And how do we decide what to work on next? How do we prioritize what we should add to the web platform or change about it? So we interviewed more than 10 people involved in the process and people who were involved in different stages of the process. And all of them, essentially, so it became clear that there was no formal research at Mozilla at first. So we have a great UX team at Mozilla that works on Firefox. They're doing an amazing job. There wasn't much of formal research when it comes to the web platform. And that's important, because at a place like Mozilla we have limited resources. So every time we decide to ship something, we incur serious opportunity costs because it means that we cannot ship something else. So this is really important for a place like Mozilla to have a good understanding of why are we doing the things that we're doing. And this is what we heard from people about how things are prioritized. And there's one thing that really stood out. Every single person said the same thing. We need to hear more from developers. And it makes so much sense. I mean, none of us can be successful, really, without that part. It's hard to prioritize what to ship and the right thing if you don't know what pain points are. And you can't get people to use something unless it actually solves one of their problems. So for all of those reasons, we propose the developer needs assessment. So what is that exactly? It's a prioritized list of developer and designer needs. And it's a simple tool for harsh prioritization that's representing a diverse audience and a pretty massive feature space. It's published on MDN, and it's not owned by a single browser vendor. We initially proposed this under the MDN Product Advisory Board because there we have representation from major browser vendors, but also from the industry and from the W3C. Because as a community, we at least have to have a common understanding of the facts, even if you then decide to prioritize different things. And finally, it's reproduced annually. And this is really important because as an industry, we need to know whether we're addressing pain points of developers and whether we are having impact with the things that we're actually doing. So we need to track pain points over time to see where things are actually going and where we are really moving things in the right direction. And if you do this well, we think the MDN web developer needs assessment or MDN web DNA for short. It can be the voice of developers and designers working on the web today. And asking web developers and designers about their frustrations is not trivial because the problem space is just so vast and the audience is very diverse. So let me tell you a little bit about this we went through for that. And I apologize up front because I'm not a user researcher. We worked with a very talented Alison McKee from Pinpoint Research on this. So I'm going to do my best to channel her here. So in January last year, we started the process by fielding a survey to our product advisory board members and we asked them for data that they would use for decision-making. We then had almost 20 in-depth interviews with web developers and designers to put the final survey together. And that is because we wanted the survey to be rooted in the voices of web developers. If he had started from the questions that browser vendors had, it would have been based on the internal perspective of browser vendors instead of really being rooted in the everyday life of web developers. So by conducting those interviews up front, we made sure that we derived the questions from the stories of developers and designers about what is important to them in their work on the web, but also what's frustrating for them. So to go from the interview findings to the survey, we followed Pinpoint Research process. We went from observations, what we saw and heard from web developers to insights, what it means, and then to critical themes, why those actually matter. And we continued that process by incorporating those survey findings into the survey results as well. And in practice, that means we transcribed 16 hours of interviews, we then coded them, and finally, we bucketed them to derive insights for the items in our research. And that's a very hands-on approach, as you can see here. And based on these themes, we constructed the central survey questions around the frustration of web developers and designers. And then we continued to work on the overall survey. We ran pilot interviews where we watched multiple people take the survey just to make sure that it was really understandable. There was nothing that people misunderstand to ensure that the survey would be as unambiguous as possible. And with the help of more than 30 stakeholders from our product advisory board members, we put the final version of the survey together in July of last year. And we put it on MDN, but it was also fielded through our product advisory members. That's the W3C, Google, Samsung, local, Microsoft. And not just in English, we localized the survey into eight languages. That's Arabic, simplified Chinese, English, French, Japanese, Korean, Brazilian, Portuguese, Russian, and Spanish, because, again, it's a very diverse audience that we're trying to address here. And 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 28,000 people took the 20 minutes to complete the full survey. And that's from 173 countries. And just the complete responses alone, that's more than 10,000 hours that the community has essentially contributed to let us know about what the biggest pain points and frustrations are. We believe that makes the MDN Web DNA the biggest web developer focused survey ever conducted. And with that scale come benefits, because now we can segment the data by experience level, by developer role, country satisfaction, and we can still retain very high confidence for the results that we get from that because the sample size is so large. So after this intro, you might be interested in actually seeing results. So top countries. As I mentioned, we had participation from 173 countries across the globe, but that's not uniformly distributed. Just six countries make up more than half of the participants, as you can see here. That's the U.S., China, Russia, India, Germany, and France. And Germany is a bit of a surprise because we didn't even translate the survey into German. That said, we still have pretty good representation in Europe, Asia, and North America. But we can do better to reach developers in Africa where we had just 2% of the responses this year. And one segmentation we were interested in was developer type. And there is, of course, the classic front-end back-end split. But recently, people started talking about the front of the front-end and the back of the front-end. And there are no generally recognized terms for this. So if you ask people, are you on the back of the front-end or the front of the back-end, they don't really know what that means. So we asked whether people use primarily JavaScript on the front-end or CSS and HTML, and that's a bit of a proxy for that. And as expected, given our audience, only a small number of participants saw themselves as pure back-end developers. And we had a somewhat even split between JavaScript and HTML plus CSS developers. But interestingly, way more people consider themselves full-stack developers. In terms of experience, of course, our industry is growing and it's 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 the participants in the survey had less than five years or less experience. Speaking about representation, so from previous surveys, we are aware that we had to make a specific effort to get better general representation. And we did. We reached out specifically to groups to get that. But unfortunately, we didn't really succeed with that goal. The participation of women, you can see here, has a rate of about 8% to 12%, depending on which country you look at. Unfortunately, there are no global and general population numbers, but we know that in the U.S. at least, the participation rate of women in self-development is about 20%. So that's all we were shooting for. And that is a clear bias of our survey. And it's one that we want to better account for in future interviews. So for now, we want to at least acknowledge the bias. And we want to ask everyone that they consider this bias when they make use of the results when they interpret the results here. All right, that was the demographic breakdown. But what about the actual results? So without further ado, here they are, all 28, from biggest frustration to the least frustrating thing. And I want to draw your attention to the top five and the bottom five. And I'll go into a little bit more detail in a moment about the top five or top 10. But there are some surprises at first glance when you look at the bottom five here. In particular, making sites accessible. So that's really important, as we've just heard about from Yana. But people who have worked on this know that there are many frustrations involved with actually doing that work. So why is it ranked so low? And this is where the interviews really come in handy because from our interviews, we know that a lot of people don't get to do that. So accessibility is often deprioritized. So it might rank this low not because it's easy to do, but because most of the time, they just don't have the time to actually do it. So they never really encounter the issues involved in that. And that example should make it clear that context for this is really super important. This is a quantitative study. It can answer the question of what and how many, but it can't answer the question why. And that's why we did the in-depth interviews to really add that context. Let's focus on the top 10 a bit more. So one thing you might have noticed is that four out of the top five items are in the similar bucket. It's web compatibility and interoperability. One of the biggest strengths of the web is that there is no single vendor that controls the platform, but that doesn't come for free. Web developers and designers are frustrated by not being able to use features or by having to find workarounds, fiddling with browser differences and by the difficulty to verify that something that works in one browser will also work in another browser. There is another bucket, though. It's less clear-cut, but it also shouldn't be too surprising because the web doesn't just consist of JavaScript, HTML, and CSS. It's the ecosystem of libraries and frameworks as well. And there is no standard web library. There is no one way to build a web application. That, again, comes with upsets and some very specific drawbacks. And those really manifest here in these frustrations. Documentation and sample code is almost always the top priority for developers. And you can see that here. It's in the second position, really. But handling multiple frameworks and keeping up with the ever-changing landscape is also something that developers find frustrating at a very high rate. I mentioned before that one of the big benefit of having big numbers is that you can segment and you can slice the data and still get useful results. So here's one such segmentation. The top five frustrations between some of the top countries in the survey. You'll notice that there is actually very little variation between those countries. And that's somewhat surprising because these are really different markets. When you ask web developers, they have very similar frustrations. And as you know, the pace of change on the web is incredible. So we ask people what the biggest barrier for entry was when new technologies become available. The results very much match the frustrations we talked about earlier. It's interoperability and documentation. Those are the leading issues when it comes to why people might not jump on some new tech. So when you're working on some new technology and you want developers to adopt it, look at this. It's interoperability and documentation of that. 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 platform. So we asked the question, what are the things that you would like to be able to do on the web but what web platform features to do? And we had a massive long tail, massive long tail of a wish list that you can see here that's represented by the other category of things that have less than 2% mention each. And on the other hand, the biggest category by far is access to the underlying devices. So that's USB, Bluetooth, camera, SMS, and all kinds of sensors. And we broke out access to the file system as its own category, as it's the biggest request for the net category, and in a similar way, people want access to native APIs. So that's contact lists, calendars, and other features that the operating system provides. And you will notice once again, browser compatibility is very high on the wish list because what good is a feature if it's only implemented in one browser and it doesn't reach that threshold of availability and you cannot use it? So now this was a little bit bleak. So before we finish this, I have some good news. You wanted to have one measure that would help us understand what the current sentiment is among web developers. So we asked how would you rate your overall satisfaction with the web as a platform and a set of 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 an amazing platform indeed. And by understanding what web developers spent their time on and identifying what their biggest frustrations are, we can focus our attention on those and help make things even better. So next year, when we do this again, hopefully the numbers will be up. I'm very happy to share some of the responses we got from the browser vendors who were involved in this. So Google came up with a very strong endorsement and I want to thank them for that. They said the Google Web Platform team is now using developer satisfaction as one of our top-level metrics. We're excited to be using the MD&DNA as one of the main sources of data to help us understand and prioritize the key areas of developer frustration. They followed through the developer satisfaction question that you've seen before. It's really now a top-level KPI that they're using for this year and we're looking into how can we actually make this actionable and move the needle on that. And we're looking at the top frustrations for that one. We shared an earlier version of this report at TPAC in September and it was very well received by the W3C, which makes it very hopeful. So they said that earlier reports from the survey provide valuable input to several standardization and pre-standardization discussions at W3C's beginning meeting. That's a TPAC and we anticipate the published report will continue in its progress. It makes very hopeful to hear that from them. And that's surprisingly Muslim as onboard as well. In the Firefox team, we're always listening to our community needs in order to make product decisions. The comprehensive overview of the developer community's needs provided by the MD&DNA report is therefore essential to us and we're already incorporating the findings in our plans and we really are. So what I just presented and much more is in the full report that was published last year. And I want to thank all of the product advisory board members for their support and we really invite everyone here to use the results to shape their road maps and to do that to better reflect what developers really need, what their biggest pain points are, what their frustrations are. But as I said, we want this to be an annual thing so the next iteration will hopefully start in March and be able to survey in May and then publish the results in September just in time for the next TPAC and the 2021 planning season. And if you want to see the full report, you can now download it from insights.developer.mosella.com and it's free, it's very comprehensive and you can pick the things that are really important to you. That is it. I'll just leave this up. And now we can take questions. You're quite early, so plenty of time for questions. Yeah, exactly. So we have plenty of time for questions. If you have questions, raise your hand. I'll give you the mic. So you can ask questions and it's recorded. I'm going to start by the first tier so I don't have to walk too much and then I'll go to the person that's on the top afterwards. I was wondering if you'd done anything on a similar scale with actual users because one of the things in there was developers want more and more access to hardware. Can you speak up a little bit? Is that better? So I was wondering if you had done a similar thing on a similar scale with end users who just use the browser rather than developers because one of the things there was the developers want more and more access to hardware and computer information and things but that could be totally opposite to what the users want. Yeah, that's a really good question. So it's actually one of the verbatim quotes that we have from a developer who says, as a developer, I want access to the hardware and I want access to the sensors but as a user, that sounds like a nightmare and I don't want that at all. So it's interesting because even developers who really want access to the hardware are still horrified by the implications of that. So yeah, we know on the user side privacy is a big concern and there's a lot of research going into that at Mozilla but also at other browser vendors but when we look at developers, this is what they want to actually build more things on the web. So I think it's on us to figure out how to do that while still respecting the privacy of users. I think there's movement in that area. I think web media is one of the next things that's coming in. Web Bluetooth, Web USB, we're working on that. There are still big barriers to it but yeah. It's something that we know there is an issue with that. There is no reason why we don't have access to all of that yet. Any other questions? No, thank you. So I'll say it again, if you're sitting on the aisles, please try to move to the center so people can