►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts
A
Hello,
everyone-
this
is
eric
and
I
am
starting
the
september
8th
product
design,
weekly
meeting
for
the
static
site,
editor
group
and
nothing
to
call
out
specifically
I've
been
doing
a
lot
of
talking
on
these
weekly
calls.
So
I
thought
maybe
I'd
turn
it
over
to
michael
first
for
any
design
updates
not
to
put
you
on
the
spot,
but
I
don't
have
much
on
my
agenda
and
I
was
curious
what
you
had
this
week.
A
B
I
think
the
key
thing
for
the
session
next
week
is
it'll
be
run
by
yourself,
eric
and
we'll
just
take
the
scores
and
the
times
from
that
to
like
added
to
the
average
overall,
it's
been
a
good
learning
experience
for
me
because
some
of
the
people
we
talk
to
actually
don't
use
the
static
site
editor
usually
or
like
it's
their
first
time,
seeing
it
so
just
discovering
things
on
the
sidebar
or
like
where
it
is,
is
like
a
good
eye-opening
experience.
B
So
that's
good
with
editing
front
manner.
We
ran.
B
We
ran
that
solution,
validation
as
an
unmoderated
testing
and
the
platform
we
used
was
a
little
bit
tricky
to
use,
but
three
of
the
five
people
were
able
to
use
it.
The
other
two
I'm
doing
like
one
one-on-one
calls
to
get
the
feedback.
So
that's
a
win
for
both
us
with
the
solution,
validation,
but
also
like
the
ux
research
team
for
their
kind
of
research
on
what
tools
to
use
as
we
move
forward
with
like
scaling
out
solution,
validation
through
unmoderated
research,
which
is
good.
B
The
feedback
from
there
is
useful.
I
haven't
had
time
to
deep
dive
and
like
actually
analyze
it
properly,
but
I'll
look
to
do
that
by
the
end
of
this
week,
and
I
think
this
segways
really
nicely
into
one
of
the
talking
points
that
you
have
this
week
is
like,
and
you
know
the
next
block
of
things
that
we
need
to
validate
and
move
forward
towards
13.5
13.6.
B
B
So
at
the
moment,
our
kind
of
page
looks
like
this
with
the
title,
the
text
area
and
at
the
moment
we
have
this
bottom
footer
bar
part
of
the
next
round
of
solution.
Validation
is
actually
sticking
to
the
bottom
footer
bar
right
now,
because
most
of
this
designs
that
I've
had
so
far
has
this
bar
at
the
top.
But
at
this
moment,
like
my
initial
intent
of
it,
was
this
bar
takes
over
this
whole
gitlab
navigation.
B
But
I
don't
think
we
have
a
strong
stance
or
a
strong
position
or
rationale
to
take
it
over
completely.
So
as
part
of
the
next
iterations
for
solution
validation,
I'm
gonna
do
test
it
with
the
links
at
the
bottom.
So
all
these
things,
rather
than
being
at
the
top
in
the
other
design.
So
far,
it's
gonna
be
at
the
bottom,
just
to
see
how
that
go.
Just
to
keep
that
going,
because
whatever
the
interaction
is
whether
it's
a
panel,
a
drawer
that
pops
out
or
a
model
it's
independent
of
wherever
this
toolbar
is
located.
B
So
I'm,
okay
with
that
until
we
have
a
better
rationale
for
completely
taking
over
the
navigation
or
or
like
just
moving
it
at
the
top.
So
at
the
moment,
so
my
next
round
of
iterations,
that's
looking
at
the
publishing
flow,
will
keep
the
button
at
the
bottom.
Just
for
the
sake
of
not
too
many
changes
going
on
and
just
to
keep
me
grounded
in
current
reality.
Otherwise,
I'm
like
deviating
way
too
far
from
where
the
whole
rest
of
the
team
and
the
product
is
where
everything's
still
at
the
bottom.
B
So
that's
that's
what
I'm
looking
at
and
what
I'm
looking
at
is
yeah
going
through
this
cleaning
up
and
the
publishing
flow.
I
didn't
have
a
really
productive
week
last
week,
so
I'm
looking
at
tackling
some
of
that
this
week.
A
That's
great
yeah.
I
actually
I'm
really
curious
to
see
how
that
goes
in
the
testing.
I
like
that,
a
lot
actually,
when
I
saw
it,
I
immediately
jumped
to
the
possibilities
for
that
based
on
some
of
the
discussions
actually
derek
you
were
talking
about
in
an
issue,
I
believe
about
accordion
revealing
different
options,
and
things
like
that
that
that
bar
on
the
bottom
to
me,
maybe
feels
a
little
more
natural,
if
like
it,
if
it
grew
the
space
underneath
and
showed
more
options
I'll,
let
you.
A
To
explore
that,
but
that
was
my
natural
instinct
was
like
if
we
need
to
reveal
more
about
the
actions
or
the
status
of
a
build
or
an
mr
detail
or
something
like
that.
That
bar
could
grow
and
it
would
feel
maybe
a
little
more
natural
than
trying
to
push
the
whole
editor
down
and
make
room
between
the
two
bars
or
something
like
that.
But
yeah,
I'm
interested
to
see.
A
I
like
that
approach
and
sounds
good,
and
I
actually
that
does
segue
well
into
my
only
topic
that
I
wanted
to
discuss
in
real
at
length,
which
is
just
as
we
get
closer
to
making
a
decision.
A
It
seems
like
we're
very
likely
going
to
re-architect
the
wysiwyg
editor,
which
gives
us
an
opportunity
to
address
a
bunch
of
issues
which
I
brought
up
in
the
call
earlier
today,
and
I
know
michael
you
saw
the
issue
I
created
that's
just
kind
of
a
list
of
paper
cuts
and
feature
gaps
and
and
other
types
of
just
little
bugs
that
are
inherent
in
the
toast,
ui
library.
A
So
things
like
the
the
cursor
that
jumps
to
the
bottom
of
the
page
as
you
switch
between
modes
between
wysiwyg
and
markdown
mode,
or
the
the
extra
line
break
that
we've
we've
found
a
way
to
overcome,
but
it's
just
kind
of
a
bug
with
with
toast
ui.
A
So
I'm
trying
to
collect
those
as
as
a
way
to
quantify
some
of
the
changes
that
will
be
resolved
by
switching
to
a
different
editor,
without
necessarily
making
that
the
exclusive
reasoning
but
saying
that
we're
by
moving
to
this
editor
we're
getting
a
block,
editing
experience,
we're
these
are
all
hypothetical
and
that
the
architecture
is
still
being
defined.
But
we're
able
to
use
editor
light
as
our
code
source
editor
and
you
know
we
have
an
easier
path
towards
extensibility
for
other
static
site
generators.
A
Plus
these
dozen
bugs
are
resolved
in
this
other
editing.
Experience
right,
I
think,
to
to
wrap
a
bow
around
that
story
and
tell
that
over
the
coming
months,
it'd
be
great
to
once.
We've
identified
with
which
editor
will
be
the
one
that
we
move
forward
with
to
take
whatever
the
out
of
the
box
features,
are
and
apply
our
take
on
it
and
get
a
good
prototype
and
a
good,
a
good
set
of
figma
files
that
we
can
share
around.
A
What
that
would
look
like,
and
so
I
think,
testing
this
early
is
a
great
idea
that
we
can
apply
towards
the
inevitable.
A
And
I
was
talking
to
jean
about
this
as
far
as
planning
and
sequencing,
and
I
think
what
we're
what
we're
looking
at
is.
13
5
is
still
wrapping
up
work
on
some
of
the
bugs
in
toast
ui
and
some
of
the
features
that
we
are
going
to
be
implementing
like
the
image,
upload
and
youtube
video
embeds,
then
13,
6,
13
7
would
mostly
be
re-architecture
and
then
13
8
would
likely,
if
all
goes
well,
we're
not
holding
anybody
to
it.
B
B
Going
to
chime
in
with
once,
we
identified
the
framework
of
the
library
that
we
want
to
use
in
addition,
or
maybe
even
potentially,
instead
of
using
like
a
clickable
prototype
since
we're
getting
into
more
like
high
fidelity
interactions.
If
we're
doing
more
like
more
interaction
based
things,
perhaps
it's
worth
like,
creating
like
prototypes
in
code
using
the
editor
itself,
so
that
we
can
kick
the
tires.
So
I
can
do
a
little
bit.
C
B
So
we're
not
looking
for
like
full
like
test
coverage
or
anything
like
that
or
a
good
structure.
It's
just
like
something
scrappy
to
get
testing
going.
That
could
be
something
that
once
we
identify
the
library
or
our
framework,
then
we
can
like
think
about
the
best
things
that
we
want
to
test
from.
D
A
A
Call
I
think
that
would
probably
be
something
we'd
fit
into
the
13.6.
As
we
start
implementation,
and
I
know
that
at
least
right
now,
enrique's
been
kind
of
tagged
to
do
that
initial
architecture
and
implementation.
So
that
might
be
part
of
it.
Just
like
a
proof
of
concept
that
we
can
have
as
a
little
sand
box
and
maybe
maybe
carve
out
a
little
extra
time
for
some
additional
styling
and
make
it
a
little
more
polished
so
that
we
can
take
it
to
testing
yeah.
I
think
that's
a
good
call.
C
The
other
common
I
had
on
that
is
in
addition
to
the
paper
cuts.
Maybe
you,
if
you
could
dig
up
the
list
of
criteria
that
we
had
when
we
originally
picked
toast
ui?
Why
we
liked
it
and
what
we
features
we
thought
it
gave
to
us
and
list
those
out
also
as
a
criteria
for
choosing
whatever
we
do.
Instead,.
A
Yeah,
that's
good.
Obviously
it
wasn't
an
issue,
so
I
will
find
it
it's
somewhere
and
probably
in
our
category
category
maturity
for
minimal,
so
it's
linked
there
yeah
and
you
know
see
since
these
videos
get
posted
and
and
we're
talking
about
this
openly
in
to
the
public.
I
don't
wanna.
I
do
want
to
make
it
clear
that
toast
ui
worked
really
well
for
us
to
get
our
initial
validation
and
there
are
requirements
that
we're
gathering
things
that
were
things
we're
discovering
about
the
different
use
cases
we
want
to
solve
that.
A
A
Yeah,
I
don't
have
anything
else
to
specifically
call
out
this
week,
I'll
be
working
on
a
lot
of
13.5
planning
and
issue
refinement.
A
I
don't
have
a
specific,
like
area
of
issues
that
I'm
trying
to
go
through,
but
anything
that's
related
to
the
editor
experience
or
linked
to
from
our
direction
page
would
be
the
ones
I'd
start
with.
First,
I
still
have
on
my
radar
to
go
back
through
and
do
some
housekeeping
on
the
handbook
epics.
So
chad,
I
haven't
forgotten
about
that,
but
it
just
keeps
getting
bumped,
so
I
will
give
them
some
attention.
A
Yeah
and
absolutely
for
since
you
can't
join
us,
I
I
will
thank
him
on
on
the
record
for
doing
that
and
yeah.
I
think,
making
sure
that
our
our
maturity
epics
are
squared
away,
because
we
also,
I
guess,
should
highlight.
A
First,
community
contribution-
and
so
I
think,
the
further
we
can
get
ahead
with
our
direction
items,
the
more
likely
we're
able
to
flag
issues
that
would
be
well
suited
for
community
contributions
and
I
think
extensibility
across
other
static
site
generators
or
markdown
flavors
or
you
know,
renderers
of
any
kind
or
or
things
like
that
would
be
prime
candidates
for
that.
A
A
C
D
Nothing
in
mind,
I
mean
one
thing
that
comes
to
mind.
It's
probably
obvious.
I
guess
but
michael
your
comment
about
getting
some
engineering
effort,
I'm
sure
there's,
there's
obviously
two
core
device
right.
It's
like
the
editor
itself
and
the
tool
we
use
to
actually
create
the
ast.
That's
the
difference,
whereas
toast
ui
had
those
glued.
B
D
Actually
want
those
separate
is
kind
of
the
highest
level
architectural
decision
change.
So
in
terms
of
the
editor
itself,
just
like
toast
ui
there's
going
to
be
probably
sandboxes
that
we
can,
you
know
we
can
play
with
the
only
difference.
Now
is
maybe
some
of
the
things
we've
learned
with
toast
ui
that
ended
up
being
shortcomings.
We
can
now
you
know,
drill
on
the
editor
a
little
bit
harder.
Basically
with
that
context,
so.