►
From YouTube: UX/Frontend Monthly Call - 2019-03-26
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Yeah
hi
everybody
I'll
go
ahead
and
get
us
started.
It
looks
like
I'm
first
on
the
agenda,
so
I
want
to
talk
about
the
design
system.
Push
that
we're
doing
that.
All
of
you
are
familiar
with
I
just
wanted
to
kind
of
close
out
on
it
and
I
see
that
tins
almond
is
also
on
the
call
so
Tim,
please
jump
in
on
any
of
this.
A
So
firstly,
I
wanted
to
say
thank
you
to
everyone.
We've
got
a
ton
of
enthusiasm
and
momentum
around
moving
Damas
forward.
So
honestly,
that's
one
of
the
most
important
aspects
of
the
project,
so
thank
you
for
your
passion.
I'm
really
excited
to
see
how
this
evolves
over
time,
so
CSS
clean
up,
actually
I'm
going
to
turn
this
over
to
Tim,
because
I
basically
is
this
is
happening.
Thank
you.
So
much
for
Anand
engineering
team
Tim
conducted
the
specific.
B
Thanks
a
lot
Christy
yeah
so
as
we
are
doing
already
tons
of
or
have
done,
tons
of,
CSS
stuff
and
it
l'épée
I,
stuff
and
all
is
rolling.
The
idea
was
to
especially
with
the
new
model
of
working
groups,
to
actually
form
a
team
of
people
who
are
driving
the
topic
along
the
already
planned
and
decided
roadmap,
so
that
simply
someone
is
in
the
driving
seat
and
is
creating
those
issues
that
are
needed
and
pushing
the
work
across
the
whole
organization,
especially
engineering
and
definitely
Oren
decided
in
February
are
the
main
drivers
in
that
roadmap.
B
That
means
we
did
it.
We
are
split
up
the
roadmap
in
three
different
steps,
and
the
idea
is
that
the
working
group
is
simply
creating
the
issues
along
that
road
is
seeing
that
we
are
following
all
the
different
stops:
steps
that
we
have
everything
in
place
that
we
need
for
linters,
etc,
etc.
The
team
at
the
moment
is
a
couple
of
front-end
years
with
Phillip
Phil,
Denise,
Sarah
and
Simon
and
at
the
moment
follow
for
a
UX
ID,
it's
Christy
and
Tory,
and
we
can
see
that
we
also
extent
a
team.
B
If,
if
someone
is
really
super
interested
and
we
need
some
specific
expertise,
etc,
and
if
you
take
a
look
at
the
epic
that
is
linked
there,
I
started
today
on
simply
collecting
all
the
different
issues
that
are
already
are
out
there
and
decided
to
bring
them
under
one
roadmap
and
especially
the
other
CSS
stuff.
It's
really
about.
We
retranslated
that
phrase
from
something
which
sounded
a
little
bit
rougher
to
stop
the
cascading.
B
So
the
idea
is
really
to
stop
first,
that
we
are
adding
more
and
more
CSS
that
we
would
need
to
clean
up
at
some
point
or
remove
or
figure
out
what
we
should
do
with
it.
So
the
idea
was
to
add
statement,
as
we
only
had
like
a
quite
old
gym
and
place
so
far
for
building
of
CSS.
We
have
now
stylings,
which
enabled
us
to
write
also
our
own
plugins.
There
are
some
plugins
now
in
place
that
are
best
practices
practices.
B
Those
are
already
fixed
for
the
most
important
cases,
but
we
also
have
terms
of
warning
so
for
each
and
every
file
that
be
currently
have
in
our
code
base
for
the
CSS
files.
We
have
now
warnings
about
too
much
nesting
if
we
have
stuff
that
is
actually
duplicated,
so
we
have
in
two
different
spots
in
the
same
file
to
different
classes,
which
actually
do
exactly
the
same.
We
do
linking
about
utility
classes.
B
So
this
means,
if
some
classes
that
were
invented
are
actually
there
to
do
exactly
the
same
thing
that
our
utility
class
already
can
do.
Then
we
also
warn
about
that
stuff
and
those
linters
and
additional
data
routes
that
we
want
to
implement.
So
that
really
say:
okay,
please
don't
add
anything
more
to
our
page
specific
CSS.
B
So
this
means
there
will
be
one
issue
profile
on
page
specific
CSS,
which
will
tell
me
okay,
please
remove
all
the
warnings
that
are
therefore
that
are
there
through
silence.
Please
take
a
look.
Can
we
replace
some
of
some
of
the
CSS
that
we
have
created
here
for
something
that
we
anyhow
have
in
a
generic
way
for
a
component?
Are
there
parts
that
we
actually
can
delete
because
they
are
not
used
at
all?
It's
really
hard
to
do.
B
Mapping
of
our
CSS
against
the
source
code
as
we
have
different
types
of
source
code,
so
we
can't
really
use
automated
tools,
so
this
would
be
also
simply
a
manual
task
to
simply
take
classes
and
search
for
the
code
base
and
see
if
there
is
anything
that
is
actually
using
it.
Stuff
I
have
seen
in
some
classes
and
removes
them
or
in
the
past,
so
I
mean
I.
Would
guess
that
there
are.
There
are
more
and
then
the
last
step,
which
is
also
an
important
topic
in
the
overall
performance.
B
Is
we
have
a
lot
of
CSS
written
those
pre,
specific
files,
which
is
really
just
page
specific,
but
they
leaked
out
over
time,
so
this
meant
means
that
some
people
said
okay,
there
is
something
that
implemented
for
quartz.
You
know
what
this
class
is
already
great.
I
will
also
use
it
in
a
different
page,
which
makes
it
hard
to
simply
take
that
file
and
just
load
it
on
the
board's
page,
for
example.
So
the
target
of
the
engineer-
and
we
are
also
very
happy
and
spreading
out
the
invitation
to
all
you
access
to
all.
B
So
let
us
know
if
you
are
interested
to
pick
up
some
of
those
files
to
simply
learn
more
about
it
with
some
coaching.
There
is
really
to
figure
out.
Are
those
cloud
classes
all
used
on
the
boards,
then
yeah?
Let's
go
create
a
specific
bundle
out
of
it.
It's
super
easy
and
then
only
dead,
CSS
stuff
is
only
loaded
on
that
page
and
not
on
all
the
pages.
B
Because,
right
now
we
have
one
humongous
CSS
file,
that
is
learning
all
the
CSS
for
85%
of
all
the
CSS
that
was
ever
written
on
every
page,
and
this
is
also
something
which
is
definitely
not
great
for
performance
and
during
this
manual
task
we
want
to
do
that.
So
if
we
have
40
engineers
working
on
that
everyone
does
like
to
3
files,
we
already
have
like
those
120
files
that
we
currently
have
in
the
CSS
conference.
B
This
is
step
number
two,
and
this
is
something
that
we
really
want
to
take
it
over
the
next
weeks
and
then
become
ready
to
step
number
three,
which
is
the
main
part
where
discussions
started
so
far.
There
is
no
actual
detailed
plan
on
how
to
do
things,
except
some
ideas
that
currently
go
in
the
direction
of
taking
all
the
generic
stuff
and
everything
that
is
reusable
out
of
fit
kit.
Let's
see
and
move
it
to,
people
apply
why
there
are
a
couple
of
issues
out
there,
because
simply
it
makes
it
easier
to
have
the
CSS.
B
Next
to
the
component.
We
can't
put
visual
screens
or
testing
on
top
of
it.
We
have
something
really.
This
generic
is
usable
and
can
be
us
throw
out
the
product
so
that
we
basically
move
everything
to
keep
the
VI,
and
only
the
page-specific
stuff
is
left
in
CD
and
do
two
step
one
and
two.
You
should
have
at
that
point
already:
wait-wait-wait-wait-wait
less
CSS
on
stage
specifically
and
by
driving
it
through
the
working
group
and
scaling
out
go
out
still.
The
work
is
for
everyone.
B
It's
not
that
those
poor
souls
no
need
to
go
through
CSS
for
months,
I,
know
and,
and
apparel
can
tell
us
a
little
bit
of
the
tales
that
happen
picked
them.
So
it's
definitely
not
time
in
the
target
is
that
we
are
scaling
about,
but
the
working
group
is
really
driving
that
by
creating
those
issues
enjoy
Nesta
so
yeah
any
questions.
B
C
B
Would
see
like
I
have
taken
a
look
for
like
two
days
on
the
CSS
and
I
think
there's
a
tons
of
things
that
can
be
regrouped
simply
under
components
so
either
or
through
a
combination
of
utility
classes.
So
it's
the
generic
bootstrap
label
class
to
it
add
a
helper
to
move
it,
the
five
pixels
over
and
you're
done,
and
then
you
can
delete
the
whole
custom
class
that
you
have
in
there.
B
I
think
there
is
a
lot
of
stuff
that
can
actually
be
simply
replaced
by
taking
those
classes
to
the
files
and
getting
rid
of
custom
stuff.
That
is
not
that
custom
or
editing
there,
everything
else.
Yes,
there
can
still
be
stuff
for
a
page
specific,
and
it's
really
about
this
should
be
a
time
boxed
endeavor.
So
this
should
not
be
that
an
engineer
sits
at
this
for
the
next
three
weeks
and
their
mind
is
blown,
but
rather
like
take
a
look.
B
D
B
Is
something
that
can
happen
afterwards?
I
think
of
what
I
was
trying
to
put
out
there
in
the
component
roadmap
at
the
end
of
the
epoch
is
really
that
we
that
we
split
up
the
topics
that
we
currently
compile
a
lot
in
in
our
discussions,
which
is
like
implementing
on
the
code
side,
a
new
bootstrap
component
or
a
bootstrap
component
general
and
get
it
styled
and
I
would
like
to
split
that
simply
in
the
terms
of
okay.
This
is
one
topic
and
that's
our
topic
and
having
been
in
reality
a
third
stage.
B
I
think
that
would
be
a
great
job
also
for
handing
it
out
for
an
automated
way
in
those
issues
as
we
do
it
with
the
screen
sprinting.
But
I
would
really
say
that
we
have
like
step
one
stop
the
cascading.
We
are
already
almost
done
spring
cleaning,
and
then
we
get
to
the
styling
of
the
components,
because
people
would
start
now
with
really
the
styling.
Then
we
would
run
into
problems
again
as
we
have
those
over.
B
Let's
remove
something
it
looks
worse
again
and
different,
etc,
and
getting
those
Tufton
into
the
product
depends
on
the
component.
I've
seen
some
components
very
simply
to
replace
it
in
seven
different
places
in
your
time.
This
is
something
that
someone
that
is
actually
implementing
its
component
into
right
away,
but
there
are
also
especially
the
more
layout
focus
components
and
with
stuff
that
is
more
like
going
all
over
the
place.
That
is
something
I
would
target
as
we
do
it
now,
with
the
EE
to
GE
moves
and
with
the
spring
cleaning
trades
really
simple
tickets.
B
D
Just
to
follow
up
in
our
last
UX
meeting,
we
were
saying
that
front
Enders
would
be
picking
up
a
component
in
eleven
eleven.
That
is,
that
reasonable
with
the
spring
cleaning.
Or
are
you
thinking
that
this
is
going
to
happen
after
the
spring
cleaning,
which
is
likely
not
going
to
be
by
eleven
eleven
night.
B
B
That
would
be
something
that
is
doable
if
we
all
are
on
the
same
page,
that
this
is
not
fully
100%
style
at
that
moment,
and
then
we
get
half
but
half
the
advantage
that
we
already
are
using
the
same
coupling
like
100
places
and
then
started
at
the
end
and
one
of
the
places
it's
like
magic.
Pretty
then
this
can
be
doable,
but
I
think
we
should
take
a
look
totally
right.
If
we
have
this
in
a
big
steak.
B
Overlapping
with
the
spring-cleaning
plus
doing
a
couple
of
components
at
the
same
time
could
be
problematic,
but
on
the
other
hand
we
are
now
38
from
the
engineers.
Please
remind
me,
so
there
are
a
lot
of
people
out
there
that
that
can
really
jump
in
and
as
a
smaller
did.
We
do
the
issues
the
easier
to
be
to
actually
jump
on
those
and
we
take
and
replace
stuff
and
test
it
out
if
it
still
works
and
all
is
good
and.
D
B
B
D
C
B
So
the
ideas
right
now
that
philippe
tourbillon
and
the
others
will
start
with
creating
one
example
issue
inside
we
are
having
a
caller
that
n
we
still
need
to
set
up.
Hopefully
we
can
get
one
done
for
a
first
day.
There
will
be
create
one
issue
for
one
file
as
an
example.
Give
that
to
one
person
have
one
front,
an
engineer
figure
out:
do
they
actually
understand
everything?
Is
there
everything
in
there
etc?
B
A
E
Cool
thanks
Christy,
so
just
a
couple
items
just
to
move
things
forward.
One
is
the
that's
kind
of
in
a
pattern
of
extreme
values,
sounds
weird
extreme
instances
of
the
UI
usage
where
we
have
thank
you,
I
get
distracted
with
down.
Sorry
things
with
translations
like
German,
will
push
the
to
do
button
in
the
top
right
sidebar
of
like
issues
and
merge
requests
over
and
then
I
know
we're
also
exploring
abbreviation
of
extreme
numbers
where
it's
like.
E
Okay,
if
we
have
whatever
a
million
stars,
is
it
really
matter
if
we
have
a
million
thirteen
thousand
four
hundred
sixty
eight
or
do
we
just
want
to
abbreviate?
It
then
also
I,
more
from
my
own
amusement
included
this
screenshot,
which
I've
already
turned
into
an
issue
of
the
epics
view
linking
issues
to
it
and,
having
a
more
extreme
case
of
that,
so
the
short
story,
or
the
short
question
I
want
to
ask,
is:
is
there
an
issue,
epic
to
track
the
efforts
for
handling
extreme
values
in
the
UI?
E
If
not,
I
will
create
that
one
just
so
we
can
kind
of
whatever
keep
kind
of
a
an
eye
on,
or
at
least
have
a
way
to
track
these
things.
Maybe
a
label
is
better,
but
I'm
also
open
to
suggestions
that
I
just
kind
of
wanted
to
put
the
feelers
out
there
good
point
about
Chinese
being
much
more
dense.
I
was
thinking.
The
epic
name
could
be
like
gitlab
extreme
UI,
anyways
15-time
in
mythic.
D
E
E
D
E
B
F
Thanks
Dennis
I
just
wanted
to
share
and
also
ask
for
front-end
developers,
feedback
and
also
UX
designers
feedback
on
what
are
the
best
ways
you
found
to
do.
Ux
reviews
on
merge
requests.
We
just
started
in
a
slack
thread
and
I
started
listing
out
some
of
the
things
that
I
usually
use
and
that
other
people
have
mentioned.
F
Sometimes
you
need
to
do
a
review
call
not
only
to
before
the
work
starts,
but
also
when
you're
already
reviewing
the
implementation
by
the
front
end
developer.
It
works
really
well
for
a
larger
and
more
complex,
merge,
request
and
also
when
you
have
to
set
up
a
lot
of
different
things.
Then
one
of
the
things
I
personally
have
tried
with
squash.
F
All,
for
example,
was
setting
up
an
end
grok
and
if
that's
how
you
say
it,
but
M
growth
tunnel,
so
that
I
could
do
the
UX
review
could
say
async,
so
he
doesn't
have
to
stop
his
work
for
us
to
do
a
review
call
he's
implementing.
Maybe
they
come
the
set
up
for
the
merge
request
is
specifically,
it
is
kind
of
complex.
So
we
had
this
tunnel.
F
Okay,
no
one
talked
so
I
will
to
read
what
people
have
written
so,
but
so
Lucas
suggested
screen
captures
video
to
show
behavior.
That's
a
really
good
point:
I
forgot
to
mention
screenshots
/
video
captures
yeah,
and
then
we
have
a
lot
of
other
people.
Writing
other
things.
Tim.
You
want
to
say
something
yeah.
B
So
we
discussed
this.
This
is
the
same
thing,
because
it's
not
only
for
your
expert,
it's
also
for
PM's,
and
especially
other
engineers
that
are
reviewing
cross
speciality
wise,
especially
as
you
are
having
more
and
more
domain
topics
in
specifically
in
see,
ICT
and
and
all
those
topics,
it's
very
hard
to
get
that
stuff
set
up.
So
we
had
the
idea
in
the
discussion.
B
I
think
it
was
in
December,
so
to
create
something
like
GDK
helper
tools,
so
that,
basically,
you
can
call
on
a
different
URL,
a
UI
where
you
can
say:
okay,
I,
want
to
add
to
my
GDK
a
repository.
That's
different.
Five
types:
I
want
to
create
a
repository
with
C
ICD
pipelines.
I
want
to
connect
to
a
runner,
or
something
like
that
which
is
of
which
would
be
super
nice
because
you
simply
start
the
instance
three
buttons
as
you
do.
B
The
the
example
would
be
the
busey
liu
IM,
which
is
going
in
the
same
direction
as
to
some
project,
setup
click
like
buttons
and
today
and
have
a
perfect
configuration
for
a
thing.
But,
of
course
this
would
need
engineering
time
and
might
make
sense,
but
we
definitely
should
follow
that
up.
If
that
is
across
groups,
a
big
topic
for
your
eggs
from
vendors
like
anders,
I
will
have
a
look
and
try
to
follow
this
up,
how
hard
this
could
be
so
that
we
figure
out.
B
Ok,
there
is
something
that
might
be
a
quick
win
and
see.
If
that
works,
then
we
can
extend
with
other
to
more
and
more
topics,
as
every
instance
has
all
of
their
own
API
and
can
imports
stuff.
We
can
also
import
repositories
that
we
have
signaled
left,
call
and
import
them
by
a
click
and
and
setup
scripted,
the
same
stuff
that
we
have
for
our
tests.
B
F
D
F
I
think
you
touched
on
the
good
points
and
I
I.
Remember
some
situations
when
I
was
reviewing
a
merge
request
locally
and
I
managed
to
find
a
weird
scenario
where
something
broke
and
I
not
only
had
to
report.
Ok,
this
is
happening.
This
is
a
bug
that
needs
to
be
fixed.
Sometimes
it
was
kind
of
specific.
The
way
you
get
into
that
specific
scenario
that
I
had
to
also
describe
how
you
could
create
that
scenario.
So
and
then
the
developer
would
have
on
this
local
instance
to
create
that
scenario
and
review
it.
F
Bah,
bah,
bah,
so
I
think
there's
a
lot
of
time
that
we're
spending
here
unnecessarily
and
that
we
could
streamline
if
we
everyone
was
working
with
the
same
team
same
thing,
it
was
just
a
matter
of
linking
and
I
think
that's
what
people
expect.
The
review
apps
could
bring,
and
also
another
thing
that
maybe
we
should
be
doing
that
we're
not
doing
today
is
is
listing
out
what
are
the
scenarios
that
we
as
UX
designers
will
look
out
for
specifically.
F
Sometimes
there
is
a
scenario
that
you
remember
when
you're
testing,
but
most
of
the
scenarios
I
think
we're
already
able
to
describe
and
lists
even
before
implementation
begins,
so
that
developers
can
already
implement
and
test
those
scenarios
when
they're
implementing
before
doing
some
commits.
That
is
some
things
that
I
usually
find
happen.