Thinking about Developer Satisfaction and Web Developers

It would be an understatement to say that MDN’s Developer Needs Assessment has helped the Chrome Web Platform team prioritise their work for 2020, in fact it’s been central to DevRel and the Web Platform teams objective setting (more on that soon).

Over the last year or so we’ve been fortunate to collaborate with the MDN team via the PAB (Product Advisory Board), and during that time we’ve been thinking about how we measure the satisfaction that developers have with the platform, and even if it’s important.

We believe it is incredibly important. The hypothesis that I have is: if developers can do all that they need to do on the web and it’s easy for them to build high-quality experiences by default, their users will be happier, developers will create more content, and as a result their satisfaction with the platform will increase.

There are lots of ways to look at this hypothesis, on one hand you should start with the end-user needs first, but this leads in to a lot of areas (such as browser UI etc) that I can’t influence. So we chose the one group we work with: Developers.

Chrome’s Web Platform leadership now has core-objectives to improve developer satisfaction on the web in 2020. The question is, what does that mean, and how should we do it? Well, the MDN survey is one amazing source of data, that when broken down roughly falls in to the following areas that need massively improving:

  1. Browser Compatibility - The web is lumpy, it should be a lot smoother. Chrome should continue to ensure it is compatible with the broad web platform; Chrome should work with all browser vendors to help with compatibility; Chrome should help to ensure that we don’t have a Chrome-only web.
  2. Testing - It should be easy to end to end test your sites across all browsers. It’s too hard right now.
  3. Documentation - It should be easy for developers to find the best and most up to date reference material, and also opinionated and validated best practice guidance.
  4. Debugging - Developers look at debugging as a failure case, we should ensure that developers have all the tools they need to understand the issues they are facing and fix them as quickly as possible.
  5. Frameworks - We can’t escape the fact that a huge number of developers use frameworks, how can we continue to make sure that there is a strong partnership between browser vendors and framework authors? and that developers know how to use these tools effectively.
  6. Privacy & Security - There is a huge amount of legislation that is slowing developers down, not to mention ecosystem changes that are happen due to effective competition. This change worries developers and we need guidance and tools to help people.

The above list is not an exhaustive set of issues that developers struggle with, but MDN has shown that they are important areas that if we can help with (both in Chrome and across the web ecosystem) then we believe that developers will be more productive and ultimately more satisfied with the platform.

We have some ideas about what we can solve some of the issues lain out in this post, but the number one goal we have is to continue to improve the connection we have with the ecosystem and address the issues that developers are facing day to day.

I aim to post more about this over the coming weeks with a lot more specifics when we have them worked out a little more.

We will continue to contribute to MDN, and the MDN survey to drive our web platform prioritisation - we use the satisfaction number as our north star metric. We will be running more engagements with developers to keep getting your feedback and validating the work that we are doing. We will also be creating a lot more tools and guidance with the ecosystem to continue to make it easier to build high quality sites and apps on the web.

Is this list a good set of focuses? Are there areas we should be addressing more? How would you like Chrome to engage with the you (in the ecosystem sense)?

Picture of me smiling.

Paul Kinlan

Trying to make the web and developers better.

RSS Github Medium


Russell Huq Wellington Torrejais da Silva Saurabh Rajpal #WeAreWebinions Yusuke Utsunomiya Vikram is hiring! 👩‍💻 👨‍💻 👾 Sidekick Digital Muhammad Ghazali filipe.replace('lipe', 'guarnieri') Robert James Maxim «PWAdvocate» Salnikov Martin Schierle Duncan Godwin Braulio Cassule 🇦🇴 Alexey Rodionov Joe Gaffey Stefan Fejes Jack Franklin Bzz2k6 #BZZ2006 andreban Kenneth Auchenberg 💭 Rowan Merewood Houssein Djirdeh Odili Charles Opute Jon Wiedmann George Salib® Bramus! Romain Huet Aaron Williams Alex Russell Andrey Lipattsev Shingo Yamazaki Kathleen McMahon Chen Zhixiang Muniyakumar Ivan Babak Adam Argyle Önder Ceylan 🥥 Ricardo Machado Gerhard Awais Andrea Giammarchi Fernando Serboncini Nikolay Cholakov 🙏 4 ❤ Experimental Web Yohan Totting すがもと@がーすー Kai Dmytro Olefyrenko Eric Lawrence 🎻 Friandy D. Noviandha ItzLevvie Erik Isaksen Dion Almaer Yoav Weiss


Russell Huq Wellington Torrejais da Silva Saurabh Rajpal #WeAreWebinions Yusuke Utsunomiya Martin Schierle Henri Helvetica📍✨👩🏾‍🚀✨ YYZ George Salib® andreban Maye Edwin Rowan Merewood Houssein Djirdeh Elizabeth Sweeny Ivan Babak Ricardo Machado Satya Kresna Chrome Developers Aiyub Mollah Shihab Nikolay Cholakov🙏4❤ Experimental Web KΞNNΞTH C.⚡ Eric Lawrence 🎻 ItzLevvie Dion Almaer

Comments and Replies

Pain point 5) As a developer, I would like to be able to use await import and workers locally, with urls like: "./..." or "file:///C:/Program%20Files/...". IHMO, being forced to launch a webserver - just to test some basic concepts - breaks the philosophy of simplicity of HTML.
Pain point 4) Content check API. Internet knows a raising content regulation. Non-compliance with laws leads to fines or shutdown. Countries, firms & religions define such regulations. Websites have tremendous difficulties to comply or stay up-to-date. Let's simplify this
Paint point 2 : GDPR. Terrible experience on all EU websites. Would benefit a unified UX. This way is suggested by the CNIL (French GDPR regulation) in its recommandation project published on 15th january :… (Look at Article 9, page 21).
Paint point 3 : I'd like native Payment Request API on all browsers. No need for a JS library.
Pain point 1) Multiple Auth. Google One Tap SignIn/SignUp tremendously improved the identification flow (since ur logged on Android or Desktop Chrome 70% market shares). Works only for Google Ids. Model should be standardized, promoted and implemented by other social providers
Dan FabulichDan Fabulich
"Performance" isn't on the list. "Performance" and "speed" don't even appear in this article.
Erik IsaksenErik Isaksen
security & privacy I would not have last
Paul KinlanPaul Kinlan
They're not far off. How would you order them?
Erik IsaksenErik Isaksen
excellent. Hoping they are not in priority order but this is great