►
From YouTube: Create:Editor Product/UX Weekly - 2021-07-07
Description
Weekly Editor group sync between Product and Design
A
Hey
everyone:
this
is
the
editor
group
product
and
design
weekly,
sync
call
and
I'll
jump
right
in
to
move
around
my
agenda
items
the
first
one's
super
quick
and
came
up
right
before
the
meeting,
enrique
posted
a
comment
on
an
issue
based
on
feedback
from
the
content
editor,
and
I
wanted
to
run
it
by
you,
michael.
A
This
is
related
to
keyboard
shortcuts
and
code
blocks.
So
the
issue
that
came
up
was
that
when
you're
creating
a
code
block
in
the
content,
editor
the
shortcut
to
exit
the
code
block,
if
you
were
smart
enough
to
figure
it
out,
is
command
return,
which
also
happens
to
submit
the
form
on
the
page.
So
it's
kind
of
a
weird
loop
of
unexpected
behavior.
A
There's
two
issues:
one
is
that
there's
like
conflicting
keyboard
shortcuts
and
the
second
one
is
about
education
of
keyboard
shortcuts
in
general
and
that
being
sort
of
a
hidden
functionality
when
you're
working
with
codeblocks
to
solve
the
first
problem
of
the
conflicting
keyboard
shortcuts.
I
think
enrique
proposed
shift
return,
because
it's
already
alternative
shortcut
for
tip
tap.
A
I
feel,
like
that's
fine,
and
then
we
can
probably
close
out
the
issue
related
to
inadvertently
submitting
the
form,
because
you
used
the
shortcut
to
exit
a
code
block
and
then
we
can
focus
on
better
in
app
notifications
and
education.
Around
keyboard
commands
that
help
you
navigate
through
the
content,
editor
sort
of
as
a
separate
issue.
A
B
Okay
cool,
so
I
I
have
two
thoughts
about
this,
because
I
think
it's
a
good.
I
think
it's
a
perfect
mbc
solution
right
now,
I
think
respecting
command
return
to
submit
a
form
is
the
right
way
to
go
and
like
keeping
it
like.
That
is
cool
by
me.
The
part
where
we
probably
might
iterate
in
the
future
is
this
shift
return,
because
shift
return
is
how
you
do
enters
in
code
blocks
in
the
slack
editor
so
in
in
the
like,
auto
formatting
world.
B
A
Cool,
so
I
would
say
it's
safe
to
close
out
once
we
get
that
implemented
safe
to
close
out
the
bug.
That's
like.
A
Specifically
accidentally
submitting
the
form
in
general,
the
command
return
keyboard
shortcut
is
also
a
little
opaque,
but
if
you
do
know
that
it's
there
at
least
you
won't
accidentally
trigger
it.
So
that's
great.
I
think
I
agree
that
we
should
work
towards
documenting.
I
see
the
issue
you
added
in
the
and
the
agenda
yeah,
so
yeah
making.
A
B
Yeah,
so
that
that
was
off
the
back
of
talking
to
you
enrique
about
the
toolbar
editors
and
and
like
keyboard
shortcuts
with
them.
So
one
of
the
things
that
we're
looking
to
introduce
for
learnability
is
introducing
keys
for
keyboard
shortcuts.
B
We
kind
of
already
do
that
in
the
current
content
and
the
current
block
the
editor
tool,
but
we
just
want
to
double
down
on
that,
and
you
know,
because
there
are
known
keyboard
shortcuts
that
are
common,
that
such
as
like
command,
v
or
ctrl,
v,
whatever
like
cut
and
pasting
and
all
that
stuff.
But
we
also
have
these
gitlab
shortcuts.
B
What
we
wanted
to
do
right
now
was
see
if
there
is
an
overlap
of
potential
shortcuts
and
ensure
that
we
don't
do
that
and
plus
also
probably
have
a
separate
list
of
keyboard
shortcuts
for
other
common
tools
so
that
we
know
what
kind
of
where
users
could
be
coming
in
from
from
their
mental
models
of
actions
like
this.
In
this
week,
like
I
learned
about
command
k
and
like
it
took
me,
I
don't
know
how
many
years
in
this
industry
to
finally
figure
out
how
to
do
that.
A
B
In
all
the
tools,
so
that
that's
kind
of
cool,
so
things
like
that
and
that
that
will
help
with
learning
ability
with
get
lab.
We
may
have
overlaps
but
we'll
cross
that
bridge
when
we
need
to
so
yeah.
A
A
Well,
shifting
gears
to
talk
about
the
web
ide
a
little
bit
while
we
were
trying
to
draft
our
quarter
three
okrs
or
our
proposed
okrs
for
quarter
three,
I'm
starting
to
think
a
little
bit
more
broadly
about
what
we've
been
talking
about
with
the
commit
flow
and
improving
that,
and
I
think
we
could
probably
set,
maybe
even
like
a
a
a
year
long,
a
one
year
goal
for
improving
the
mr
to
web
id
workflow
and
that
could
be
inclusive
of
the
act
of
committing
whether
it's
a
new
commit,
or
that
creates
an
mr
or
a
commit,
that's
going
to
an
existing
mr.
A
But
that
also
opens
it
up
for
us
to
explore
things
like
revisiting.
The
idea
of
having
mr
comments
show
up
in
the
gutter
of
the
web,
ide
or
or
even
bring
back
the
discussion
about
in-context
editing
and
how
that
fits
in
with
the
web
ide.
So
I
think
this
this
theme
makes
it
possible
for
us
to
identify
the
the
most
effective
and
most
like
ready
to
develop
solutions.
While
we
also
explore
some
other
opportunities
and
do
some
solution,
validation
for
some
of
the
bigger
challenges.
A
So
I
just
wanted
to
get
your
thoughts
about
that
and
I'll
schedule.
A
think,
big
session
around
this
just
kind
of
get
all
those
ideas
out
and
see
which
ones
are
more
more
exciting
and
more
achievable
and
maybe
more
valuable.
B
Yeah,
I
think,
there's
an
issue
out
there
at
the
moment
that
I
created
a
few
weeks
ago
about
the
mr
flow.
But
so
is
this
talking
about
dmr
flow
specifically
to
the
web
id,
or
is
this
talking
to
like
across
the
board
like
across
the
different
editors
yeah,
mr
yeah,
whereby
these
right.
A
Well,
you
can
go
to
the
single
file
editor
and
that's
where
we
can
have
a
discussion
about
whether
or
not
there's
like
an
in-context,
editing
and
progressive
path
to
open
up
things
in
the
web,
ide
or
or
something
like
that.
But
I
think
ultimately,
what
I
would
probably
be
going
for
is
driving
usage
of
the
web
ide
by
making
the
mr
workflow
more
useful.
So
things
like
being
able
to
see
your
comments
alongside
the
code
in
the
mr
from
the
mrs
in
your
web,
ide.
A
But
that
also
comes
with
like
what
we
were
talking
about
with
the
commit
flow,
where
there
might
be
some
paths
in
the
web
id
that
don't
end
up
in
a
commit.
So
you
might
want
to
take
some
feedback
from
an
mr
and
create
a
patch
file
or
a
comment.
That's
effectively
a
patch
file
to
be
applied
by
somebody
else,
or
you
might
want
to
leave
a
comment
and
just
leave
it
at
that.
A
B
Yeah
I
had
this
conversation
with
another
designer
about
some
of
these
ideas
that
we're
exploring
such
as
creating
patches
or
like
creating.
Like
a
mr
comment
and
it,
this
is
like
a
interesting
world
where
our
world
crosses
over,
with
like
source
code
or
code
review
very,
very
heavily,
and
what
I
don't
understand
is
like
the
line
between
the
worlds,
and
so
maybe,
as
part
of
this,
we
kind
of
shape
this.
B
We
figure
out
where,
where
things
like,
whose
responsibility
is
x
because,
like
these
ideas
are
awesome-
and
I
just
had
a
yeah,
I
think
in
the
spirit
of
get
up
with
short,
toes
and
and
not
worrying,
about
stepping
on
each
other's
toes.
I
feel
like
it
is
like
fine
for
us
to
like
carry
it
through
end
to
end,
but
yeah
it'd
be
good
to
know
where,
like
if
it's
because
it
starts
in
the
web
ide.
That's
like
that's
kind
of
like
a
rule
potentially
or
yeah,
but
yeah.
If
you.
A
That's
a
good
point
in
making
sure
we
stay
informed
of
and
in
step
with,
the
strategies
from
code
review
and
any
other
potential
avenues
of
integration
would
be
important,
but
I
think
things
that
happen
in
the
web.
Ide
are
fair
game
for
us
to
to
explore,
and
I
I
am
starting
to
feel
like
the
the
potential
for
the
source
editor
to
drive.
A
It
would
benefit
the
workflow
related
to
like
security
scanning,
so
you
could
highlight
areas
of
vulnerabilities
or
or
risk
in
this
that
come
out
from
a
security
scan
and
wherever
possible,
enabling
that
workflow
and
then,
if
they
don't
implement
it,
I
don't
see
why
we
couldn't
do
it
for
them,
because
it
does
benefit
everybody
and,
and
it
drives
usage
of
the
web
id
at
the
end
of
the
day
but
yeah.
That's
I
think
we
can.
We
can
think
really
big
about
the
problem.
A
We
can
identify
areas
that
are
that
are
already
feasible
like
we
don't
need
to
wait
for
so
there's
no
hard
dependencies
on
other
work
to
be
finished
or
other
teams
to
to
help
us
along
and
then
do
some
solution,
validation
and
see.
If
we
can
verify
that
this
is
stuff
that
people
want.
B
Of
git
lab
there's
this
the
idea
of
this
source
code
editor,
there's
the
get
pod
and
then
web
id
is
in
this,
like
funny
number
and
one
of
the
questions
that
comes
up
from
time
to
time,
and
it's
like
what's
the
job
to
be
done
of
the
body
or
what's
its
kind
of
use
case
in
the
whole
scenario,
if
some
engineers
are
more
developing
locally,
you
know
what's
the
purpose
of
the
web
id,
are
we
trying
to
explore
this
as
we
go
as
in
like
yeah?
B
This
is
a
good
idea
to
have
here's
a
gateway
for
that.
So
let's
try
to
use
it
and
then
we
can
shape
and
use
the
web
ide
as
we
please
to
help
find
a
use
case,
or
would
it
be
better
to
figure
out
actually,
I
kind
of
scratched
my
own
idea,
because
I
was
like
I'm
not
clear
what
the
web
ids
role
is
right
now,
nor.
A
B
Anyone
really
defined
it
clearly,
but
I
could
be
wrong.
I'm
just
gonna
check
our
direction
page,
but
right
now,
but
that's
the
question
I
have
is
like.
I
feel
like
doing
this.
We
might
be
able
to
find
the
purpose
for
the
web
id
versus
trying
to
do
some
kind
of
like
research
to
find
what
it
is
about,
where
what
we're
doing
right
now
is
taking
some
action
doing
some
stuff
with
it
and
seeing
what
works,
what
sticks
and
then
maybe
under
there
we
see
a
direction
to
double
down
on
the
web.
B
A
I
I
I'm
right
there
with
you,
I
agree
and
I
don't
think
you're
wrong.
It
is
a
in
an
in-between
state.
I
think
the.
A
I
think
you're
right.
We
need
to
define
that
more
clearly
and
I
think
thinking
harder
about
why
this
area
excites
me.
I
think,
by
the
process
of
figuring
out
this
workflow,
we
could
determine
if
the
web
id
really
makes
the
most
sense
right
now,
as
like
the
mr
editor
right
like
when
you
need
to
do
work
related
to
an
mr,
but
you
don't
want.
A
So,
if
that,
if
that
helps
us
in
the
in
the
process
of
researching
it,
come
to
a
conclusion
there,
then
that
would
be
great
or
it
might
lead
us
in
a
different
direction,
actually
nobody's
doing
any
real
work.
A
B
A
Cool
that
was
helpful
and
it
actually
that
helps
frame
where
I'm
coming
from
better
for
me,
actually
in
the
process
of
talking
that
through
that.
A
Hopefully,
this
will
help
us
find
our
place
for
the
web
id
and
if
it
doesn't
then
it'll
at
least
narrow
the
focus
a
little
bit.
You
want
to
jump
into
your
topics.
A
B
You
deal
with
to
eric
on
a
daily
basis,
is
feedback
from
the
navigation
changes
in
14.00.
B
There
are
comments
in
there
that
make
me
want
to
revert
everything
and
just
take
things
back,
but
rather
than
taking
a
knee
jerk
reaction
to
all
the
things.
B
One
of
the
issues
that
I
created
earlier
this
week
was
gathering
data
on
discoverability.
So
one
of
the
messages,
one
of
the
angles
that
we
wanted
to
promote
with
consolidation,
the
top
menu,
was
the
discovery
of
the
dashboard
pages.
And
what
I
want
to
validate
of
through
data
is
that,
yes,
we
are
actually
tracking
those
like
we're
actually
seeing
more
visits
to
those
pages
from
the
top
nav,
and
I
realized
that
we
are
not.
We
don't
have
any
events
on
the
specific
dashboard
items.
B
A
B
Various
various
merge
requests.
The
interaction
patterns
is
a
fun
one.
Yes
to
help
people.
I
think
the
hover
pattern
would
help.
It
is
not
like
ideal
keyboard
scenario
as
same
as
the
search
focus,
but
the
search
focus.
One
is
an
interesting
one,
because
that
was
one
where
we
thought
it
was
cool
to
like
continue
because
it
was
removed
in
13.9.
But
then
not
everyone
updates
at
the
same
time,
so
that
we
get
some
delayed
reactions
or
like
people
didn't
feedback.
A
B
Didn't
see
the
feedback
on
the
removal
of
the
search
thing
so
yeah,
I'm
okay
with
bringing
that
back,
which
brings
this
to
like.
B
B
This
potentially
solves
like
keyboard
navigation
in
a
saner
way,
but
also
eliminates
the
issue
with
oh,
should
we
have
flyouts
on
menus
or
not,
because
one
of
the
things
that
we
understood
from
the
data
was
people
actually
use
the
file
menu
when
the
menus
expanded.
So
I'm
like
okay,
because
it's
a
hover
rather
than
the
click,
it's
more
simple,
potentially,
but
that's
something
that.
B
There's
that
epic,
that
we
have
issues
for
iterations.
What
I
my
question
is
here
is:
how
do
you
want
me
to
mark
things
that
are
certain
versus
those
that
are
waiting
for,
like
more
information
data
research
versus
those
where
I'm
still
exploring?
Should
we
use
the
workflow
labels
in
that
scenario,
or
is
there
a
way
to
like
mark
things
with
color
or
something
like
that.
B
C
A
Development,
I
mean
there's
not
much
here,
that's
going
to
need
technical
exploration,
and
I
I
assume
at
this
point
like
you
know,
your
front-end
skills
are
enough
to
validate
that
something
is
possible
and
we
have
such
talented
front-end
engineers
anyway.
I
think
we
can
execute
on
anything
in
a
reasonable
time
frame.
So
if
you're,
confident.
B
A
C
A
B
C
A
Yeah
that
works-
and
I
I
hear
the
feedback
too.
I
I
hope
that
you
don't
take
it
too
hard.
It's
valid
feedback.
We
want
to
address
it
all.
We
don't
want
to
revert
it.
I
still
think
it
was
a
good
direction
to
go
in.
We
can
take
their
feedback
and
make
a
couple
small
changes
here
and
there
and
explore
additional
interaction
patterns
and
things
like
that
down
the
road,
but
it's
still
a
change
for
the
better
we're
just
not
hearing
the
positive
feedback
from
anybody
in
that
issue.
A
A
I
was
surprised
at
the
vocal
reaction
to
moving
members
by
a
couple
people
in
there,
because
it
seemed
like
a
really
benign
change
but
and
one
that
we
tested
with
pretty
certain
results
that
it
wouldn't
impact
anybody
yeah.
B
So
with
the
members
when
I
think
that
one
is
not
the
change
itself
that
bothers
and
people,
it
was
more
like
the
messaging
as
in
they
were
informed
of
it
through
the
the
update.
So
maybe
there's
something
that
we
could
do
in
the
future
to
talk
about
it
like
two
milestones
ahead
and
like
be
annoying
and
and
then
yeah,
maybe
yeah.
I
think
there's
something
there
where
people
were
just
shocked
because
they
went
from
like
13,
8
and
then
updated
and
they're
like
whoa
where's,
everything
and.
A
Absolutely
the
the
shock
factor
is
is
real
there
we
knew
that
was
going
to
happen
and
I
should
have
in
retrospect,
found
a
way
to
communicate
that
more
broadly
through
in-app
messages,
although
it
doesn't
help
if
you
upgrade
from
13-8
to
14-0,
because
you
wouldn't
have
seen
it
but
blog
posts
or
I
don't
know
it's
a
real
challenge
because
not
every
reads
our
blog,
not
everybody
follows
our
release
posts.
Not
everybody
watches
our
videos
that
we've
been
talking
about
for
five
months
as
we've
been
working
through
these
things.
A
Not
everybody
looks
at
the
issues
so
yeah,
it's
a
tough
challenge,
but
it's
it's
feedback
to
cake
for.
B
Okay,
cool
all
right,
so
this
is
the
wiki
page
that
we
know
right
now
and
last
week
I
was
pinned
on
one
of
the
issues
where
there
was
like
some
reordering
of
the
page
that
was
like
explored
a
year
ago.
So
this
was
kind
of
that
restructure
and.
A
B
There's
some
elements
in
here
that,
like
I,
really
likes
kind
of
like
having
the
commit
thing
at
the
bottom
of
the
page,
which
was
very
similar
to
an
exploration
that
I
did
maybe
like
a
month
ago.
So
the
fact
that,
like
two
people
coming
up
with
like
a
similar
pattern,
is
always
an
interesting
sign,
especially
when
they
don't
know
about
each
other
in
a
year
apart.
B
The
reason
I
explored
this
today
is
because
yeah
that
that
comment
that
you
left
for
me
was
a
week
ago,
but
also
a
friend,
raised
a
question
about
having
the
delete
button
somewhere
on
the
main
page.
So
you
don't
have
to
go
to
the
other
page
to
delete
it.
So
I
was
just
exploring
kind
of
this
pattern
and
where
this
could
live
so
here
we
go.
B
So
I
took
the
parts
that
I
liked
from
the
old
exploration
and
combined
it
with
where
we're
kind
of
at
with
our
and
with
our
page
right
now
in
the
edit
page.
B
Currently
we
have
like
the
sidebar
is
like
the
parent
page
as
well,
and
we
have
all
this
information
here
and
then
this
is
like
the
version
with
the
toolbar
and
then,
if
we
kind
of
adopt
this
pattern
to
like,
have
delete
inside
this
inside
this
triple
dot
vertical
triple
dot,
then
if
we
take
it
to
the
reading
kind
of
view,
it
kind
of
makes
sense
to
go
through
and
have
it
here
to
surface
delete
so
like
this
almost
doubles
down
on
the
idea
that
we
okay
should
do
delete
like
that.
B
I
did
a
few
more
explorations
I'll
just
jump
down
to
this
one
where
I
started
thinking
about
you
know,
what's
the
purpose
of
this
side
menu
while
you're
editing,
so
it
feels
like
it's
distracting
to
have
a
new
page
like
like
yeah
new
page,
I
was
exploring
like.
Why
is
it
on
here?
I
know
in
issues
we
have
it
like
that,
but
it's
really
associated
to
this
area,
so
moving
new
page
potentially
to
somewhere
on
the
right
hand,
side
when
you're
in
editing
mode
page
settings
pops
up.
B
This
is
where
all
your
formatting
and
changing
parent,
page
or
whatever
you
want
to
do
with
this
page
potentially
could
go
here.
This
is
like
something
that
we
explored
very
lightly
and
actually,
we
actually
implemented
for
the
static
site
editor.
So
that's
there
and
I'm
trying
to
now
look
at
like
unifying
this
top
area
and
this
edit
page
so
that
they
kind
of
look
the
same
and
where
I
got
to
here
is
this
kind
of
view
where
we
have
breadcrumbs
at
the
top
of
the
page.
B
I
don't
really
know
how
useful
they
are
when
you
basically
have
the
breadcrumb
on
the
right
right-hand
side
of
the
page.
So
that's
something
that
we
could
explore
in
the
future.
Then
this
page.
A
A
B
Cool,
oh,
no,
no
dramas
that'll
be
just
like
an
extra
line
across
the
reading
and
edit.
So
that's
consistent
new
page,
like
I
said,
really
belongs
here,
but.
A
B
Could
live
in
the
top
area
if
we
really
needed
to
have
it
in
the
short
term,
so
this
is
all
kind
of
iterative,
but
what
I'm
pretty
happy
about
is
like
the
alignment
at
the
top
menu.
So
that's
always
like
a
primary
action
to
the
page
now
so
it's
new
pages,
the
main
action
edit
page,
is
the
secondary
visually.
It
kind
of
works.
In
that
sense,
this
is
like
the
read
view,
jumping
into
edit
view.
This
is
what
you
would
see,
so
this
is
using
our
kind
of
block
editor.
B
B
Content
content,
editing
content
tool
so,
where
I
am
happy
with,
is
like
this,
this
top
bar,
so
between
the
reading
state
and
the
editing
state
it
shares
similarities.
Any
extra
actions
down
here,
like
page
history
or
delete
page,
would
be
tucked
away
in
here
and.
A
I
really
like
this
direction.
I
think
that's,
it's
a
really
a
really
thoughtful
consolidation
of
the
actions,
and
I
like
the
repurposing
of
the
sidebar,
when
you're
or
or
actually
removal
of
it
in
most
in
some
of
the
concepts,
but
the
sidebar
not
being
visible,
makes
a
lot
of
sense,
and
I
like
the
pattern
that
we
kind
of
introduced
in
the
static
side
editor
with
the
settings
and
the
the
drawer
so
yeah.
A
I
I
think
that's
a
it's
a
nice
evolution
of
the
edit
page,
I
would
say
the
only
challenge
we're
going
to
run
into
that.
I
see
right
now
is
that
the
content
editor
in
this,
this
editing
view
would
only
be
valid
for
now
for
markdown
pages.
So
if
you
switch
the
format,
we'd
still
need
to
have
a
backup,
editing
experience
for
like
rdoc
and
others.
A
B
A
Yeah,
that's
gonna,
be
a
challenge
and
then
also
we
could
talk
about
like.
What's
the
we,
we
have
already
discussed
what
how
often
are
pages
being
changed
format
once
they're
created
like?
Is
that
even
a
thing
that
we
need
to
solve
for?
Should
we
prevent
that
from
happening
and
only
allow
you
to
choose
a
format
when
you
create
the
page,
or
is
there
a
different
path
to
like
changing
the
format
that
doesn't
involve
switching
out
the
editor
from
under
your
feet?
If
you
choose
the
wrong
one,.
B
Okay,
cool
that
makes
sense
to
me
your
your
comments
and
changing
the
format
is
the
page
type
or
page
settings
thing
that
I
tucked
away.
A
B
It
says
everything
it's
gonna
be
wiped
out.
If
you
do
this
and
and
that,
then
it
gives
you
that
action
to
say,
okay,
cool,
just
wipe
everything
or
like
okay,
give
me
a
second.
Let
me
like
cut
and
paste
everything
somewhere
else
so
that
I
can
maintain
stuff.
A
A
C
C
A
A
Cool
I
I
like
this.
I
want
to
move
on
as
fast
as
we
can
honestly.
I
think
this
is
the
this
is
the
other
half
of
our
journey
to
having
a
complete
content
editor
in
the
wiki?
That's
like
the
default
editing
experience.
The
first
half
is
getting
full
support
from
gitlab
flavor
markdown
and
the
second
half
is
making
these
changes,
because
once
those
both
fall
into
place,
I
feel
like
this
is
a.
B
A
C
C
B
C
B
I
think,
and
the
first
step
towards
that
is,
I
can
finally
answer
a
friend's
question
whether
we
should
use
the
triple
dots
or
the
icon
button
yeah.
I
think,
introducing
the
delete
in
the
in
the
drop
down
feels
strange
but,
like
I
think
it's
it'll
teach
us
something
about
our
ideas
for
the
future.
A
And,
like
I
said
in
the
issue-
and
you
mentioned
here
like
moving
the
page
history
in
there
and
things
like
that,
lesser
lesser
access
to
actions
makes
sense.
A
Well,
I'm
gonna
wrap
this
up
then,
whatever
that
needs
to
continue
with
their
day
continuing
their
day.
Let
you
wrap
up
and.