►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts
A
A
I
brought
it
up
not
specifically
because
I
think
we
should
just
do
it,
but
because
he
highlighted
one
of
the
potential
failure
faces
that
I
completely
agree
with,
which
is
having
settings
in
both
places
so
like.
If
we
can't
universally
move
to
a
model
like
that
or
another
model,
and
then
we
also
have
settings
in
the
left
hand
and
also
have
settings
in
context
with
these
other
things.
And
then
you
know,
if
you
don't
know
where
to
go
to
get
to
the
settings,
then
you
know
it's
going
to
get
more
confusing.
A
A
I
don't
think
we
necessarily
need
to
move
full
steam
on
his
concept,
but
I
do
think
that
moving
forward
with
our
research
and
and
solution
validation
on
how
we
can
consolidate
and
improve
the
settings
experience
and
then
surface
them
contextually,
alongside
the
feature
where
it's
applicable,
whether
that's
through
searching
or
these,
this
component
idea
that
we've
been
talking
about,
or
maybe
the
concept
that
sid
proposed,
which
is
just
breaking
them
all
up
and
putting
them
in
settings
views
across
the
features.
So
I
figured
I'd
surface.
A
B
Yeah
so
yeah,
when
that
video
got
its
rounds
in
the
ux
world
as
well,
some
other
designers
also
pinged
me
on
it.
I
gave
my
feedback
on
it
in
the
issue
of
contextual
access
to
settings,
which
is
like
the
issue
that
I
have
in
place
for
just
gathering
thoughts
around
this
approach
of
surfacing
relevant
settings
in
context
of
any
specific
feature
at
the
moment.
My
thoughts
on
it
is
kinda
is
more
around
centralizing
the
settings
and
then
looking
at
ways
to
like
bring
those
settings
into
context
in
the
future.
B
C
B
Of
scattering
it
too
much
and
I
and
how
we
do
that
it
feels
like
there's
two
use.
Cases
like
certain
personas
would
be
like.
Oh
I'm
looking
at
this,
I
want
this
now
cool,
but
then
there
might
be
other
personas
like
a
system
admin
who's
like
looking
at
it
holistically
or
things
that
have
crossover
dependencies.
It's
like,
oh,
I
need
to
know
to
jump
in
this,
this
specific
area
to
jump
around
so
yeah.
That's!
B
A
B
Think
this
segways
into
like
setting
standardization.
It
feels
like
one
of
the
things
that
I
put
in
the
design.
Things
is
like
my
settings
right
now:
it's
just
a
mixed
bag
of
ui
elements
across
the
different
areas.
I
think
some
of
them
are
good.
Some
of
them
are
older
patterns.
I
think
we
just
need
to
audit
and
just
say
boom
boom
boom.
B
These
ones
are
like
using
the
older
patterns
to
standardize
and
give
some
guidelines
around
things,
and
then,
let's
run
with
that,
it
may
not
be
like
the
you
know,
definitive
answer,
but
I
think
if
we
approach
this
from
an
iterate
standpoint,
I
think
there's
already
certain
patterns
that
are
common
across
our
product
in
our
following
pajamas
to
a
certain
degree.
So
let's
run
with
that
and
then
set
that
as
a
baseline
and
iterate.
On
that
oh
cool,
I
just
by
talking
it
out,
I
kind
of
like
found
my
path
for
this
week.
A
No,
that's
great
yeah.
I
think
it
moves
into
your
first
update.
So
I
had
another
agenda
item,
but
you
know
we're
we,
we
started
a
little
late
and
I
don't
want
to
keep
everybody
but
reiterating
this,
but
as
far
as
my
top
priorities
for
settings
from
a
product
standpoint
defining
those
ui
patterns,
like
you
just
mentioned-
and
your
next
point
on
the
agenda
is
about-
is
what
is
up
right
up
there.
A
I
think
there's
a
couple
rounds
of
solution,
validation
for
where
we
place
these
settings
after
we
standardize
the
ui
and
how
they're
accessible
through
contextual
modes
or
global
settings,
and
then
how
do
we
search
within
the
settings
themselves?
And
I
see
your
note
about
how
that
relates
to
the
work
that
the
advan,
the
global
search,
the
advanced
search
group,
is
working
on
and
I'm
actually
meeting
with
the
pm
tomorrow.
So
more
of
that
more
on
that
later,
I
don't
have
an
answer,
but
I
will
be
looking
into
that
for
sure.
A
B
Yeah
so
the
first
one
is
just
auditing
the
different
areas
of
settings
and
then
out
from
there
standardizing
like
picking
out
what's
working
and
then
trying
to
address,
what's
been
raised
as
bugs
or
sus
improvements,
and
I'm
saying
like
yes,
this
change
will
potentially
solve
that
and
then
putting
that
together
towards
solution,
validation
and
the
next
one
is
more
related
to
the
static
site.
Editor
is
this
side
panel
improvements.
A
C
B
The
other
at
the
moment,
the
side
panel
that
we
use
in
front
matter
is,
is
like
a
very
simple
implementation
of
it,
and
we've
seen
other
groups
within
get
lab
kind
of
breaking
away
from
the
drawer.
The
basic
drawer
implementation
pajamas
and
going
a
little
bit
more
in
detail
in
the
fidelity
of
things
that
could
be
placed
in
there
and
potentially
even
making
it
wider.
So
with
that
in
mind,
it
kind
of
opens
up
a
possibility
of
improving
that
kind
of
flow
to
be
like
a
better
panel
or.
A
A
I
don't
know
if
you
think
it'd
be
useful,
but
we
could
maybe
you
and
I
and
him
maybe
over
an
issue
just
to
keep
it
async
could
discuss
like
what
does
that
implementation
look
like,
because
we
have
some
stray
issues
around
like
using
a
full
width,
editor
and
and
moving
stuff
down
to.
You
know
bottom
bars
or
like
how
we
want
to
how
we
actually
want
to
look
in
six
or
eight
months,
and
I
think
that
would
be
a
perfect
time
to
be
addressing
it
in
my
opinion.
But
I'd
want
his
take
on
that.
A
So
maybe
we
could,
if
you
not,
that
you
don't
have
enough
on
your
plate,
but
if
you,
if
you
wanted
to
take
a
stab
at
like
a
consolidated,
what
does
it
look
like
in
six
months?
No,
no,
no,
not
implying
new
features
or
anything
but
like
assuming.
We
have
a
tip
tap
based
editor
that
has
a
floating
formatting
bar
and
we
have
this
new
drawer
treatment
and
maybe
that
bottom
bar
for
the
mr
workflow,
like
what
does
that
all
look
like
together
and
then
we
can
see.
C
B
A
A
C
C
C
Yeah,
it's
interesting
because
going
through
it,
I
mainly
saw
collapsing
and
expanding,
but
then
there
was
like
the
integration
and
web
hook
pages
where
they
just
list
things
in
a
table,
or
things
like
that.
So
you'll
probably
see
a
lot
of
them
are
the
same,
but
then
it'll
randomly
jump
to
something
different
like
in
integrations
and
web
hooks,
but
I'll
see,
if
I
remember
any
of
those
to
give
you
a
hint
or
a
heads
up
on
where
to
go
but
yeah
okay.
C
While
you
guys
are
working
on
the
settings
side
of
things
but
with
settings
there's
this
issue
around
the
placement
of
settings
that
is
also
related
to.
I
think
it
is
the
contextual
issue
around
settings.
So
that's
something
that
I
want
to
start
on
from
a
problem:
validation
standpoint,
whereas
the
problem
is
already
kind
of
there,
and
I
want
to
just
kind
of
consolidate
everything
that
we've
collected
regarding
the
problem.
C
So
we
can
just
say
here's
what
it
is
here
are
the
main
areas
that
we
need
to
focus
on
and
then
also
a
benchmarking,
so
to
understand
how
users
are
performing
on
settings
related
tasks
currently,
so
that
we
can
compare
it
with
the
proposal
and
the
same
thing
goes
for
navigation,
where
I
believe,
there's
the
wayfinding
issue.
So
that's
around
groups
navigating
between
groups
and
projects
and
so
on
the
opposite.
End
of
that
it'll
be
kind
of
an
understanding
of
the
current
experience
and
measuring
all
of
that.
C
A
The
more
rank
area
for
research
and
and
the
more
understandable
priority-
I
don't
think
one
of
them
is
like.
I
don't
think
I
know
enough
to
say
once
more-
has
higher
impact
or
more
important,
but
I
think
there's
a
lot
more
thought
that
needs
to
go
into
navigation
and
that's
where
I
think
you
probably
have
the
harder
job,
because
you're
going
to
have
to
probably
do
research
on
both
streams
in
parallel,
so
that
we
can
pick
up
the
work
on
settings
first,
but
not
lag
too
far
behind
on
navigation.
A
If
that
makes
sense,
but
yes,
unlocking
all
of
that
stuff
for
settings
is
probably
the
top
priority,
because
benchmarking,
I'm
really
glad.
You
said
that
I
think
that's
super
important
for
defining
success
criteria
for
the
settings
experience
and
then,
in
general,
the
the
themes
you
have
for
for
navigation
are
in
line
with
you
know
what
we've
talked
about,
but
those
I
imagine,
will
take
a
little
longer
and
there's
a
little
more
consolidation
of
existing
research.
That
needs
to
happen.
C
Okay,
yeah,
okay
and-
and
I
remember
there's
like
a
four
solution-
validation
goal
thing
in
the
okr,
so
I
would
just
say,
michael
as
you
create
them
or
if,
as
you
create
the
issue
that
you
might
put
through
solution,
validation,
if
you
could
just
like
ping
me
in
them,
so
that
I'm
aware
that
this
might
be
the
next
theme.
That
would
be
helpful
for
me.
C
A
Yeah,
the
gist
of
it
is,
I
don't
think,
there's
any
concrete
plans
for
any
problem
or
solution,
validation
from
the
static
site
editor,
our
immediate
focus
is
going
to
be
executing
the
re-architecture
based
on
tip,
tap
and
prose
mirror,
and
having
talked
with
enrique
about
that,
there
are
some
areas
for
that.
We
could
potentially
work
in
parallel
with
multiple
engineers,
but
we're
looking
at
probably
five
milestones
of
work
to
get
feature
parity
with
the
current
static
site
editor.
A
There
might
be
opportunities
to
bring
some
that
work
in
earlier
and
actually
contribute
it
to
other
groups
earlier
within,
like
the
three
milestone
time
frame,
but
we're
probably
not
gonna,
be
doing
a
lot
of
feature
work
over
the
next
two
quarters
for
the
static
site.
Editor
it'll
be
focused
on
getting
that
new
foundation
in
place
and
building
something
that's
more
extensible.