►
Description
Keynote: What are the Top 10 Frustrations for Web Developers and Designers? Lessons from the 2019 MDN Developer Needs Assessment - Kadir Topal, Senior Product Manager, Mozilla
Speakers: Kadir Topal
A
Bonjour
and
hello,
everyone
can
I
see
a
show
of
hands
who
hear
things
chocolatine
when
they
see
this
picture
one
all
right
and
who
thinks
that's
very
clearly
upon
shockula,
alright,
alright,
so
thank
you
for
a
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.
A
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
well
Before.
We
jump
into
that
a
quick
intro
first,
so
this
is
CSS
grade.
Css
grid
is
a
web
platform
feature
that
allows
developers
and
designers
to
layout
the
page
in
two
dimensions
instead
of
just
one.
A
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
grade
was
released
and
CSS
great
was
a
massive
success,
so
in
Mozilla
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
Square
was
a
success.
A
So,
looking
at
this,
we
had
a
few
questions
when
it's
when
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.
A
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's
standardization
and
implementation,
and
there
is
adoption
now,
as
you
can
probably
tell
immediately.
This
is
a
very
simplified
version
that
really
smooth
this
out
many
things,
and
this
looks
like
a
pipeline
when,
in
reality,
it's
more
like
a
loop
or
a
loop
of
loops
that
look
back
on
themselves.
A
A
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
ten
people
involved
in
different
stages
of
that
process
and
became
clear
that
there
was
no
formal
research
really
if
muslim',
we
have
an
amazing
team
that
does
use
a
research
for
Firefox,
but
that's
for
end-users,
and
that's
so
much
the
case
for
when
it
comes
to
developers.
A
We
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,
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,.
A
A
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.
A
A
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
like
their
needs
and
pain
points
over
time,
so
we
can
see
the
impact
of
our
own
efforts.
So
that's
what
we
need
to
do
this
regularly
and
not
just
once,
and
if
you
do
this
well,
we
think
the
MDM
web
to
open
its
assessment
or
mvn
web
DNA.
A
A
So
let
me
tell
you
a
little
bit
about
the
process
we
went
through
for
that
and
I'll
make
that
short,
but
and
I
already
apologize
up
front
because
I'm,
not
a
researcher.
We
worked
with
a
very
talented
Ellison,
make
key
from
pinpoint
research
to
design
the
the
for
the
research
design
and
to
also
conduct
this.
So
I'll
do
my
best
to
channel
her
here.
A
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
he
had
run
with
with
what
browser
vendors
wanted,
the
questions
would
have
been
based
on
the
internal
perspective
of
browser
vendors.
A
By
conducting
the
interview
we
made
sure
to
derive
the
survey,
questions
from
the
stories
of
developers
and
designers,
but
what
was
important
to
them
in
their
work,
but
also
what
caused
them
frustrations
and
so
to
go
from
interview
findings
to
the
surveys
you
follow
up
in
points
analysis
process
going
from
observations,
that's
what
we
heard
and
saw
to
insights
what
it
means
really
two
critical
themes:
that's
what
matters
and
we're
continuing
that
process
incorporate
the
survey
findings
into
what
we
learned
from
the
pilot
interviews.
So
in
practice,
that
means
we
transcribed
16
hours
of
interviews.
A
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
this
central
survey
question
around
the
frustrations
of
developers
and
designers.
We
then
continue
to
work
with
our
product
advisory
board
on
the
overall
survey
with
pilot
interviews,
where
we
watch
multiple
people
or
take
the
survey
at
every
iteration
to
really
ensure
that
survey
questions
would
be
as
unambiguous
as
possible
it
with
the
help
of
more
than
30
stakeholders
from
various
and
the
MPA
B
member
companies.
A
A
So
just
for
the
completed
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
mdn
web
DNA
the
biggest
web
developer
and
designer
focused
survey
so
ever
conducted
and
with
that
scale
can
benefits.
So
we
can
segment
that
data
by
experience,
level,
developer
role,
country,
satisfaction
and
we
still
can
get
useful
information
out
of
that.
A
Yes,
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
it's
the
US
China
Russia
India,
Germany
and
France.
It's
a
little
bit
surprising
because
we
didn't
even
translate
the
survey
into
German
yeah.
That
said,
we
still
have
a
pretty
good
representation
from
Europe
Asia
and
North
America,
but
especially
the
Africa.
We
can
really
do
better,
hopefully,
next
time
where
we
just
got
2%
of
our
responses.
This
year.
A
So
one
segmentation
we
were
interested
in
was
developer
types.
There
is
this
there's
of
course
the
classic
split
between
front-end
back-end,
but
recently
people
have
started
talking
about
front
of
the
front
end
and
like
back
off
the
front
end,
there
is
no
generally
understood
term
for
this.
We
really
try
to
find
one.
So
in
the
end
we
asked
whether
people
used
primarily
JavaScript
on
the
front
end
or
CSS
and
HTML.
A
In
terms
of
experience
or
industries,
of
course,
growing
at
an
incredible
pace,
so
it
shouldn't
be
too
surprising
that
one-third
of
all
participants
at
less
than
three
years
of
experience
and
almost
two-thirds
of
all
participants
at
five
years
of
experience
or
less
and
speaking
about
representation
from
previous
surveys.
Who
were
aware
that
we
would
have
to
make
an
extra
further
than
a
special
effort
to
get
better
gender
representation.
And
we
did
do
that.
But
unfortunately
we
didn't
fully
succeed
for
that.
A
So
women
participated
at
a
rate
of
between
8
and
12
percent
in
our
survey
and
unfortunately,
there
are
no
global
general
population
numbers
when
it
comes
to
software
development.
But
we
know
from
us
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
when
we
want
to
better
account
for
in
future
iterations
of
this.
A
But
for
now
we
want
to
at
least
acknowledge
the
bias,
and
we
also
asked
you
that
that
you
take
that
into
account
when
interpreting
the
results,
all
right.
That
was
the
demographic
breakdown.
But
what
about
actual
results?
So
that's
further
ado
here
they
are
all
28
needs
from
biggest
frustration.
To
least
frustrating
and
I
want
to
draw
your
attention
to
the
top
5
and
the
bottom
5.
A
So
I'll
talk
a
little
bit
more
about
the
top
5
and
top
10
in
a
moment.
But
when
we
look
at
the
bottom
5,
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
solo
and
from
our
interviews?
A
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
by
I
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.
A
Its
web
compatibility
and
interoperability,
one
of
the
biggest
strengths
of
the
web,
is
that
there
is
no
single
entity
controlling
the
the
platform.
But
that
does
not
come
for
free
web
developers
and
designers
are
frustrated
by
not
being
able
to
use
features
by
having
to
work
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.
A
A
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
top
five
frustrations
between
some
of
the
top
countries
in
the
survey,
and
you
will
notice
that
there
is
very
little
variation
between
those
countries,
despite
those
being
very
different
markets,
but
they
all
share
the
same
top
frustrations.
A
And,
as
you
know,
the
space
the
pace
of
change
on
the
web
is
incredible,
so
we
asked
people
what
their
biggest
barrier
for
entry
was
when
when
it
came
to
new
technologies
or
when,
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.
A
Once
again,
browser
compatibility
is
very
high
on
the
wishlist,
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.
A
So
we
asked
how
would
you
rate
your
overall
satisfaction
with
the
web
as
a
platform
and
set
of
tools
to
enable
you
to
build
what
you
need
or
want,
and
a
full
76
percent
are
either
satisfied
or
very
satisfied,
and
only
nine
percent
are
dissatisfied
or
very
dissatisfied.
So
well,
there
is
room
to
grow.
The
web
is
really
an
amazing
platform.
A
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
metric,
we
were
excited
to
be
using
the
MDI
web
PNAS,
one
of
the
main
sources
of
data
to
help
us
understand
and
prioritize
the
key
areas
of
developer
frustration.
A
What
they
said
was
in
the
Firefox
team.
We
are
always
listening
to
our
community's
needs
in
order
to
make
to
make
product
decisions
and
the
comprehensive
overview
of
the
developer
communities
needs
provided
by
the
MD
and
DNA
report
is
therefore
absolutely
essential
to
us,
and
we
are
already
in
cooperating
its
findings
in
our
plans.
A
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
and
what
developers
expresses
their
frustrations.