We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

What are the Top 10 Frustrations for Web Developers and Designers?

00:00

Formal Metadata

Title
What are the Top 10 Frustrations for Web Developers and Designers?
Subtitle
Lessons from the 2019 MDN Developer Needs Assessment
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The MDN Web Developer Needs Assessment is the first edition of an annual study providing a prioritized list of designer and developer needs. As an industry working on the Web, as a platform and set of tools, we recognized a critical voice was missing when it came to making decisions about feature development — that of web designers and developers. The MDN Web Developer Needs Assessment is the first edition of an annual study providing a prioritized list of designer and developer needs. We put this report together with the help of more than 30 stakehold- ers from the MDN Product Advisory Board member organizations and the input of more than 28,000 developers and designers from 173 countries who took the twenty minutes necessary to complete the survey entirely. That’s more than 10,000 hours contributed by the community to help us understand their pain points, wants, and needs. With that involvement, we believe the MDN Web DNA is the largest web developer and designer focused research study ever conducted. Their input now, and in future versions, will influence how browser vendors prioritize feature development so we can address the needs of designers and developers, both on and off the Web. By producing the report annually, we can track needs and pain points over time so we can see the impact of our efforts. A critical aspect of the report is that it provides a voice for commu- nities of practitioners. We did not tailor it to current assessments and priorities of participating browser vendors. A single browser vendor does not own it.
Software developerWeb-DesignerFrustrationWebdesignComputer animation
Archaeological field surveyWorld Wide Web ConsortiumData managementWeb 2.0Product (business)Frustration
Cross-site scriptingCASE <Informatik>Video gameComputing platformStandard deviationImplementationProcess (computing)Software developerVideo trackingProduct (business)Process (computing)Computing platformWeb browserTable (information)Formal grammarCASE <Informatik>Level (video gaming)Single-precision floating-point formatPhase transitionPerspective (visual)Electronic mailing listUser interfaceWeb-DesignerWorld Wide Web ConsortiumProgrammschleifeLoop (music)Point (geometry)Projective planeMathematicsMultiplication signStandard deviationDimensional analysisWeb pageView (database)Feature spaceImplementationPivot elementRepresentation (politics)TrailWhiteboardMassDirection (geometry)Computer animation
Software developerWorld Wide Web ConsortiumWeb-DesignerWorld Wide Web ConsortiumFrustrationWeb 2.0SpacetimeComputer animation
Archaeological field surveyProcess (computing)World Wide Web ConsortiumWeb browserWeb-DesignerProduct (business)Decision theoryVideo gameWhiteboardBitPerspective (visual)ResultantComputer animation
EmailFrustrationArchaeological field surveyWhiteboardCentralizer and normalizerProduct (business)Web-DesignerComputer animation
Archaeological field surveyWhiteboardRevision controlProduct (business)Online helpComputer animation
Local ringDependent and independent variablesSoftware developerFormal languageArchaeological field surveyResultantFrustrationPoint (geometry)Scaling (geometry)Complete metric spaceConfidence intervalWorld Wide Web ConsortiumDependent and independent variablesSampling (statistics)Source codeComputer animation
Representation (politics)Goodness of fitBitArchaeological field surveyDependent and independent variablesComputer animation
Data typeSoftware developerFront and back endsProxy serverHeegaard splittingBitNumberComputer animation
Level (video gaming)Term (mathematics)Archaeological field surveyComputer animation
GenderGroup actionRepresentation (politics)ResultantGenderBit rateComputer animation
Software developerCodeSoftware frameworkImplementationMixed realityConvex hullCross-site scriptingTwin primeComputing platformoutputWeb browserSoftware testingInformation securityPhysical lawWorld Wide Web ConsortiumFrustrationStandard deviationSoftware frameworkBitObservational studyMoment (mathematics)Sampling (statistics)CodeMultiplication signLibrary (computing)Context awarenessRankingWeb-DesignerWeb browserFreewareWeb application2 (number)Focus (optics)Computer animation
Computing platformOperating systemOnline helpFrustrationBounded variationMassWorld Wide Web ConsortiumFile systemMathematicsDependent and independent variablesElectronic mailing listThresholding (image processing)Internet service providerSimilarity (geometry)MeasurementWeb-DesignerVapor barrierWeb browserCategory of beingNumberGoodness of fitSet (mathematics)ResultantComputer animation
Archaeological field surveyoutputProduct (business)Software developerComputing platformGoogolSource codeMetric systemFrustrationStandard deviationDecision theoryDependent and independent variablesStrategy gameIterationExplosionPlanningTraffic reportingAreaArchaeological field surveyFrustrationStandard deviationWorld Wide Web ConsortiumRevision controlDecision theoryProduct (business)Multiplication signComputing platformMetric systemArithmetic progressionoutputKey (cryptography)ResultantFlow separationSource codePoint (geometry)Internet service providerOrder (biology)IterationComputer animation
ExplosionSoftware developerMultiplication signRow (database)World Wide Web ConsortiumWeb 2.0Scaling (geometry)Similarity (geometry)ResultantComputer hardwareInformation privacyWeb browserVapor barrierNeuroinformatikInformationHypermediaComputer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
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.
Kadir's gonna talk to us about frustrations for web designers and web developers. Kadir, 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 pond of chocolat? All right, okay. 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 Kadir. I'm the product manager at MDN, MDN Web Docs. 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. Firefox, the Firefox Grid inspector in this case.
And it was seriously awesome. That said, 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. First phase is research. 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 us 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 and we 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 a 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 we 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 whether 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 what 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 the process we went through for that. And I apologize up front because I'm not a user researcher. We worked with a very talented Allison McKee from Pinpoint Research on this.
So I'm going to do my best to channel her here. 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
before we put the final survey together. And that is because we wanted the survey to be rooted in the voices of web developers. If you 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's 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 frustrations of web developers and designers. And then we continued to work with our product advisory board 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 would misunderstand, and 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, Roku, 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 WebDNA 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 US, China, Russia, India, Germany, and France.
And Germany's a bit of a surprise, because we didn't even translate the survey into German. That said, we still have pretty good representation from Europe, Asia, and North America, where 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, from previous surveys, we are aware that we had to make a specific effort
to get better gender representation. And we did. We reached out specifically to groups to get that. But unfortunately, we didn't really succeed with that goal.
So the participation of women, you can see here, has a rate of about eight to 12%, depending on which country you look at. Unfortunately, there are no global and general population numbers, but we know that in the US, at least, the participation rate of women
in self-development is about 20%. So that's what 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 wanna 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 wanna 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 Iana. 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 people,
a lot of people don't get to do that. So accessibility is often deprioritized. So you might rank this low because, 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 a similar bucket. It's web compatibility and interoperability. One of the biggest ranks 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 upsides 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, yeah, they have very similar frustrations. As you know, the pace of change on the web is incredible, so we asked 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% mentioned 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. We 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 spend their time on, and identifying what the 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, which is why 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 MDM DNA as one of the main sources of data to help us understand and prioritize the key areas of developer frustration. And 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 so we can 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 TPEC in September,
and it was very well received by the W3C, which makes me 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 of meeting, that's the TPEC, and we anticipate the published report
will continue to support Senate's progress. It makes me very hopeful to hear that from them. Not surprisingly, Mozilla is on board as well. And 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 MDM Web 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 at the end of 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 roadmaps, 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 we will field the survey in May, and then publish the results in September,
just in time for the next TPEC and the 2021 planning season. And if you want to see the full report, you can now download it from insights.developer.mozilla.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. Thank you, Guillermo. And now we can take questions. We're quite early, so plenty of time for questions. Yeah, exactly. So we have plenty of time for questions.
If you have questions, you raise your hand, I'll give you the mic. So you can ask questions, and it's recorded. I'm gonna start by the first here, 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 from the results was developers want more and more access to hardware. Excuse me, can you speak up a little bit? Is that better? Oh, yeah. 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 user 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. And so, yeah, we know on the user side, privacy is a big concern. There's a lot of research going into that
at Mozilla, but also at other browser vendors. And 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 a reason why we don't have access to all of that yet. Any other questions? No, thank you, Genier.
So I'll say it again, if you're sitting on the is, please try to move to the center so people.