Improving the Web Developer Experience - TPAC 2022 breakout

14 September 2022


AlexL, AndyLuhrs, AnnetteG, brwalder, CurtBellew, CurtisB, DanielL, David-Clarke, DavidBaron, DavidClarke, DavidG, DavidSInger, Dom, duga, FLorianScholz, Francois, Geun-Hyung_Kim, Geunhyung, JamesG, jgraham, JoeM, JohnR, JonathanDavis, Kadir, kadirtopal, MarkcCarthy, MatthewA, miriam, Neil, NeilS, PhilA, Rachel, RichardWorth, RobEisenberg, Symon, tidoust, VincentS, zcorpan
Dominique_Hazael-Massieux, Kadir_Topal

Meeting minutes

Present° Miriam, Yehonathan

Slideset: https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0004/Developer_Experience__TPAC_breakout_2022.pdf

Kadir: the feature is there and not there at the same time - you have to deal with this a developer
… Some of us have been thinking on this topic for a while - want to present the results of thinking and open it up for disccussion

[Slide 2]

[Slide 3]

[Slide 4]

[Slide 5]

Kadir: 2 main problems: keeping up with changes, and fragmentation in browsers
… hard to know when a feature becomes well-supported
… there are real interop issues as discussed in the Interop 2023 session
… the way the platform is managed has an impact - not just missing features & capabilities

[Slide 6]

Kadir: the MDN survey we ran in 2019 highlighted these issues
… A simplified picture of how a feature lands on the platform
… ideally, this starts with research on what people might want and why
… that research is currently ad hoc if done at all
… this leads to spec & implementations, and then a drive to adoption

[Slide 7]

Kadir: a recent addition in this project is the Interop initiative to help addressing fragementation issues
… but this still leaves a few open questions around research and awareness on adoption
… how things get prioritized and get deployed to developers

[Slide 8]

Kadir: research done together has more impact than done by individual vendors
… in particular on what gets built *and* accelerated through this process
… what developer needs, what keep them away from the platform
… there is an opportunity to feed into the prioritization process
… at the tail end of the process, probably the most neglected part right now, in terms of awareness & adoption
… adoption is the overall motivation we're here for
… interop helps with fixing fragmentation issues
… but figuring what the right problems are, and letting the world knows when these problems are fixed would be useful complement to Interop

[Slide 9]

Kadir: two goals for this addition: clear guidance on what has landed and what hasn't yet
… longer term, reducing the time to ship the right features through better coordination
… so that the question "can I use" doesn't have to last several years
… Dom brought together people around these questions, based on the Interop effort
… we've been looking at the developer experience, the outcomes of the Web DNA survey

[Slide 10]

Kadir: we identified 2 opportunities of collaboration:
… - shared researched
… - building awareness of available features
… In terms of research, finding an unbiased source is key, and MDN provides a great opportunity for this
… Philip and Robert Nyman had been working with the MDN team to set up infrastructure for running short surveys on MDN
… in terms of clarity of what's available on the platform - there is of course "can I use", but things aren't so simple when you look at the details
… e.G. MDN documents 500 features for WebRTC, 2 in can I use
… describing that "a feature is available" requires agreeing what a feature is
… we're trying to build a shared taxonomy of features across MDN, can I use and others

[Slide 11]

Kadir: so the idea is to complement the Interop project with more regular research to feed into the prioiritization process, and a dashboard to provide more visibility and awareness of the situation, and in terms of awareness, creating opportunities for "moments in time" when interoperable platform land
… there is a unique opportunity to do something like that
… for a very long time, IE11 provided the baseline of the Web platform
… that is falling away now
… we're no longer held back by this
… the list of "safe" interoperable features will now be growing every year
… This has been our focus on Developer Experience

[Slide 12]

Kadir: is DX something that needs to be targeted?
… if so, are there other items to consider beyond the 2 we described
… What would make the research more impactful and useful? how to make sure it is used in prioritization
… what would be the good and bad ways to go about clarity and guidance on what the platform is?

DavidG: what kind of buy-in are you getting on the shared research idea?

Kadir: so far, mostly informal conversations with people from all browser vendors
… there is quite a lot of interest in doing that research together
… because of the impact we've seen from that before
… coming up with questions together is important too

ydaniv: during adoption, there can be browser bugs
… it's somewhat related to the DX - if the feature is there but you're running into issues (new & old)
… browser bug trackers are really hard to use to keep track of these bug fixes

<miriam> +1

ydaniv: it's also really hard to get people to open issues or look for them, or to submit reproducible cases
… leading to people using polyfills to work around this, leading to bloat

kadir: so this is about closing feedback loop, when something ships

ydaniv: more accessible bug trackers with better input to prioritization would help
… when you identify a bug in the process of a development, making a bug reproducible ends up being very costly

kadir: good point

jgraham: we've wanted for a long time to help e.g. jQuery keep track of bugs they didn't need to work around any more
… getting that input has proved useful
… not clear how much easier we can make it to file a browser bug
… there are already a lot of dup filing
… finding existing issues is a challenge for everyone
… some of the complexity might be irreductible
… all the more so if the problem is ill-identified
… Web compat teams do some of the reduction work, but that doesn't scale

miriam: I have had concerns about quality of research
… the state of JS people created the state of CSS research without a lot of outreach to the CSS community
… not clear the data we got from that research is hard to evaluate

<kadirtopal> dom: part of the idea of shared research is exactly to address that: owning it together would hopefully lead to more ownership in the outcome, and trust in the outcome

<kadirtopal> dom: there can still be issues though in the sampling, the questions, but doing it together should increase the chances of having useful research

chrishtr: was there another survey with better information?

miriam: no, but my main question about getting qualified people to get good data
… with data researchers

chrishtr: another aspect is transparency about the process and the sampling

miriam: sometimes there are big skews, e.G. lots of white JS men-developers in the example of the CSS survey
… that isn't convincing data

<RobE> I can't provide any real objective info on these surveys. But I personally find they very frustrating. Then the survey is referenced in a lot of places and used to make decisions that re-inforce the survey results.

Rachel: the risk is about how the survey gets shared - risks of echo chambers (which hard to get out of)

<David-Clarke> This is a problem for I18n where there is a strong bias to English and Western Europe

<RobE> Yes, echo chambers.

JamesG: clearly not all decisions should be based on surveys
… but they may still provide useful signals

dgrogan: I'm one of these random survey makers :)
… re doing in the research is open - if there is expertise provided to help with getting good quality data, that's a huge incentive

kadirtopal: that was a big win in the MDN DNA survey; it took quite a bit work with iteration and testing with actual developers

chrishtr: @@@

<kadirtopal> chrishtr: Should we mine bug dbs for interop issues?

james: finding the right incentives structure to make good bug reporting happen at scale
… esp given the different pace of shipping between libraries and browsers

Mike: I think Chris' suggestion would be very valuable
… some bug trackers are very un-intuitive
… some bugs get locked because developers keep coming asking about progress
… this may be a signal worth tracking
… another place to look for signals is StackOverflow
… maybe something Machine Learning could help with
… SO is also not very representative given how it works or how unwelcoming it can be

kadirtopal: I'm hearing on shared research - surveys are useful, but shouldn't be the only source of input to the prioritization process

jgraham: re mining browser databases, you don't want to encourage browser bug systems to become discussion forum
… different browsers have different policies on which signals they pay attention to (e.g. # of stars)
… creating incentive structure that creates noise is not something we want to do

simon: another source of interop issues in the wild - web pages working around issues in their code
… if this can be done through code analysis, use counter etc
… collecting data on how common various things are worked around
… when things are worked around, they do work - that reduces the signal to browser vendors

simon: one example would be looking at pages that do UA sniffing and have different work around based on UA
… or CSS hacks to target browsers
… Another would be having a discussion with framework maintainers
… and ask them to give us a list of their top ten interop problems

<jgraham> +1 on just asking people

@@@: web developer experience needs targeting - but it's never been better from what I'm hearing from developers
… but modern deployments to cloud, CDN, fragmented frameworks creates a hodge podge of scripts and build systems
… which creates frustration

<scheib> I'd like to voice support for guiding web developers to productive forums to discuss issues, express needs, etc. The current environment is confusing, diffused to different locations, etc. It seems multiple browsers would have a shared interest in this, similar to how we share interest in documentation. Perhaps those are related enough to be a possible solution.

scheib: tying documentation with a place to collect dev input might be a good way

kadir: there are ways of linking browser bugs from browser compat data also in that direction

Joe: as a BCD contributor, I stayed away from that- difficult to maintain

Rob: the Web platform doesn't have a good Web presence
… a Java, .Net, SwiftUI developers has 1-2 channels to keep track of everything
… that simplifies my life
… in the Web space, this is one of the draws for frameworks
… it's a one-stop-shop to understand everything

<kadirtopal> ...and I understand what's coming down the line with those platforms

Rob: having a place to keep track of bug fixes, polyfill, new feature landing, etc
… this can either take most of one's time

<kadirtopal> ...average devs, content creators might not even know where to find those things

<kadirtopal> ...I've been doing this for 20 years and hate to interact with bug trackers, it's a lot to expect that from people

<kadirtopal> ...providing developers with a channel that thy can have confidence in and based decisions on

dsinger: do we have enough people from these frameworks at the table? e.G. wordpress

Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).


No scribenick or scribe found. Guessed: dom

Maybe present: @@@, chrishtr, dgrogan, dsinger, james, Joe, Mike, Rob, scheib, simon, ydaniv