►
From YouTube: Create:Editor Product/UX Weekly - 2021-03-25
Description
Weekly Editor group sync between Product, Design, and UX Research
A
A
A
The
only
point
I
really
had
to
bring
up
this
was
in
slack
and
it's
in
an
issue.
That's
public
we've
added
a
1312
release.
So,
as
we've
been
strategizing
for
14.0
with
the
top
nav
and
left
now
changes,
we
now
have
a
1312
to
add
work
into,
or,
as
I
posted
it
in
slack,
just
be
more
confident
in
our
rollout
of
the
changes
that
we've
already
kind
of
committed
to.
So
I
think
this
is
a
good
thing.
It
also
allows
us
to
help
with
the
some
of
the
the
company-wide
efforts
to
improve
stability.
A
A
A
And
even
that
was
you
know,
it
was
aggressive
to
begin
with,
so
this
buys
us
more
time.
We
can
do
it
more
confidently
and
maybe,
with
a
little
more
testing
and
roll
out
like
a
slower
ramp
roll
out.
So
I'm
happy
about
this
change
and
more
information
to
come
because
it
was
fresh
as
of
like
four
hours
ago.
C
Yeah
so
from
the
design
front,
not
too
many
like
indesign
kind
of
moments.
At
the
moment
I
think
the
top
nav
left
nav.
If
there's
any
questions
or
design
changes
and
just
feel
free
to.
Let
me
know
I
see
that
you've
broken
up
some
of
the
issues
into
smaller
ones.
Eric
and
so
that's
cool
by
me.
That's
fine.
D
C
That
segues
into
like,
where
I'm
spending
most
of
my
time,
it's
more
like
solution,
validations
of
the
other
areas
that
our
group
is
responsible
for
for
right.
So
at
the
moment
I'm
looking
last
week,
I
did
the
project
overview,
change,
so
kind
of
understanding
the
potential
impact
of
that.
So
this
is
changing
like
project
overview
to
project
information
and
the
first
click
on
things
like
that:
yeah,
no,
no
red
flags
there.
I
think
we're
safe
to
move
forward
with
it.
We
we
also
considered
it
to
be
a
relatively
safe
move.
C
I
just
wanted
to
double
check
if
my
concern
around
how
people
get
home
and
to
the
home
page
of
a
project
and
would
be
greatly
affected,
but
I
think
it's
kind
of
common
for
it
to
be
almost
split
because
people
click
on
the
home,
icon
or
or
the
project
name
itself
and
at
the
moment
we're
going
to
switch
out
the
home
icon
as
well.
So
that
should
help
clear
things
up
and
that's
so
confident
about
moving
forward
with
this
decision.
C
D
C
Wiki
web
ide
editor
editing
is
like
thinking
of
the
jobs
to
be
done
there
in
both
context
of
framing
what
we're
trying
to
solve,
but
also
thinking
of
you
know,
category
maturity
and
all
that
stuff.
So
bringing
those
past
category
maturities,
scorecard
kind
of
jobs
to
be
done,
seeing
if
it
holds
up
to
today,
do
we
need
to
reword
it
or
rephrase
it
if
not
at
the
minimum,
just
bringing
that
to
the
direction
page
and
if
there's
opportunity
to
refine
or
clarify
some
things.
C
A
A
I
asked
whether
or
not
there
were
existing
jobs
to
be
done
documented
for
some
of
the
categories
that
are
still
newer
to
me.
Although
it's
been
several
months,
I
should
probably
know
this,
but
I
think
it'd
be
a
good
time
to
take
a
look
at
any
existing
jobs
to
be
done,
make
sure
they're,
still
accurate,
come
up
with
some
new
ones,
specifically
around
the
content,
editor
and
more
wysiwyg
editing
experience.
A
We
can
probably
borrow
a
lot
from
what
we
did
in
the
exploration
of
jobs
to
be
done
for
the
static
site,
editor
and
then
work
on
validating
those
instead
of
starting
from
scratch.
I
will
try
and
make
this
a
priority
over
the
next
couple
milestones.
But
if
I'm
honest,
it
probably
won't
get
a
lot
of
momentum
over
the
next
couple
weeks,
just
because
of
what's
on
my
plate,
but
I
agree.
This
would
be
really
helpful.
D
Yeah
from
what
I
remember,
I
know
some
basic
jobs
to
be
done
were
created
for
snippets
because
they
did
a
category
maturity
scorecard,
I'm
not
aware
of
any
for
wiki
or
web
ide.
I
remember,
michael,
I
think
you
might
have
created
some
for
static
site
editor,
so
those
might
be
some
starting
points,
but
yeah
I'll
keep
in
I'll
keep
an
eye
out
to
see.
If
I
can
find
any
things
I
don't
know,
but
I
don't
think
it's
documented
in
the
handbook.
C
Cool,
so
I
just
assigned
myself
to
create
an
issue
or
an
epic
around
this,
so
I'll
probably
create
an
epic
to
like
create
jobs,
be
done
for
the
editor
group
and
then
break
it
down
to
individual
issues
like
wiki
snippets
and
all
that.
So
we
can
tackle
each
one
kind
of
independently
and
there's
more
information
on
one
than
the
other,
then
so
be
it.
But
yeah.
A
Great,
I
appreciate
it
yeah
if
you
want
to
just
drop
that,
like
I
think,
creating
an
epic
to
define
these
in.
Our
editor
hq
like
global
epic
would
be
great,
and
then
we
can
just
break
it
down
into
issues
for
each
one
and
collaborate
within
those
I'll,
try
and
dig
up
the
ones
that
we
drafted
for
static
site
editor.
D
Yeah-
and
I
just
had
a
fyi
point
down
here,
especially
actually-
no-
we
didn't
talk
about
that
on
here,
but
so
I'm
working
right
now
on
a
content
audit
for
our
left
sidebar.
So
what
that
means
in
a
in
a
nutshell
is
that
we
have
a
bunch
of
stuff
in
there
that
I
can
make
some
assumptions
around
who
they
pertain
to
or
who's
using
them.
But
it's
difficult
to
know
exactly
who,
so
what
I
want
to
get
into
is
who
are
they
like
the
main
target
audiences
that
are
being
served
by
this
left
sidebar?
D
D
So
I
want
to
get
into
some
of
these
complexities
and
use
cases
and
outline
that
and
also
identify
any
opportunities
where
some
of
the
views
and
pages
might
be
able
to
be
combined
or
linked
in
some
way
just
to
get
a
little
bit
deeper
into
this
whole
cleanup
of
the
left
side
by
our
topic
and
what
belongs
in
there
and
whatnot.
So
that's
what
I'm
working
on
in
that
sheet
and
then
the
other
note
is
that
I
wrapped
up
the
first
iteration
of
our
like
high
level
buckets
proposal.
D
So
I
just
documented
the
findings.
In
dovetail,
I
linked
to
a
comment
that
kind
of
talks
about
some
of
the
key
takeaways
from
that
and
then
provides
links
to
the
dovetail
binding.
But
basically
from
that
I
saw
that
there
was
potential,
but
it
wasn't
quite
right.
The
the
top
level
category
labels
weren't
quite
right.
There
were
some
edge
cases
that
didn't
really
fit
into
one
or
the
other.
D
There
were
some.
There
were
some
complications
with
the
term,
build
like
the
scope
of
what
should
be
under
it
like
should
it
be
focus
more
on
code
related
things
or
can
include
other
aspects,
and
there
was
also
like
even
someone
who
like
codes
in
python.
It
was
like
never
use
build
in
the
left
nav
and
I
was
like
okay.
Let
me
look
into
why
you
feel
that
way,
but
yeah.
So
there
was
interesting
things
like
that.
That
came
out
of
it.
D
A
This
is
great
yeah.
I
was
looking
through
those
proposals
and
obviously
we
talked
a
little
bit
about
this
before
the
recording
started,
but
I
think
there's
some
great
iterations
that
are
available
in
there,
both
something
achievable
in
the
near
term
and
then
some
of
the
the
more
dramatic
changes
with
the
buckets
that
could
be
just
really
yeah,
really
impactful
to
how
we
organize
the
app
itself
and
yeah.
B
I
just
had
a
quick
mention,
the
the
collaborative
editing
that
topic
that
comes
up
periodically,
I'm
trying
to
get
involved
in
that
discussion.
More
there's
the
real
time
group
that
they
had,
but
it
seems
like
that's
closing
down,
and
that
is
that's
a
very
specific
focus
of
like
showing
some
updates
from
our
current
backend
real
time,
which
is
a
very
different
problem
than
collaborative
editing
and
operational
transformation.
That
implies
a
lot,
a
completely
different
architecture.
B
B
A
Yeah
this
is
great,
and
I'm
also
so
thanks
for
picking
me
in
the
thread.
I
was
catching
up
on
that
slack
thread.
I'm
also
going
at
this
from
the
product
side.
Trying
to
understand
the
scope
of
work
has
been.
That
has
been
considered
already
for
the
single
engineer
group,
whether
or
not
that's
still
happening
how
we
can
collaborate
and
share
notes
and
make
sure
that
we're
not
trying
to
solve
the
same
problem
in
two
different
ways,
and
also
you
know,
if
they're
doing
something
that
can
help
us
along
great.
A
How
can
how
can
we
work
together
towards
the
same
goal
and
so
yeah?
I
think
bringing
this
up
in
slack
is
a
great
first
step,
and
then
I
know
you
know.
Product
leadership
is
aware
that
that
we're
working
towards
something
that
could
provide
collaborative
editing
within
the
context
of
like
an
issue
description
or
an
mr
description
and
up
till
now,
I
think
that's
a
good
call
out
that
they've
only
really
been
working
on,
like
you
know,
making
sure
the
like
epic
and
the
labels
like
are
updated
in
real
time.
B
Yeah
and
that's
the
simple
problem,
it's
like
you
know
once
the
data
is
on
the
back,
yet
just
push
it
out
in
real
time
right.
Multiple
people
editing
a
document
reconciling
those
changes
and
with
optimistic
concurrency
like
a
real-time
edited
document
like
google
docs,
is
a
completely
different
topic.
A
A
A
For
for
how
you
deal
with
conflicts-
and
I
mean
we
had
try
not
to
talk
about
other
companies
on
this,
but
we
had
a
very
popular
design
tool
that
we
could
bring
down
in
a
matter
of
seconds,
with
a
combination
of
hitting,
undo
and
redo
and
and
messing
up
the
event
tree
and
stuff
like
that,
so
yeah,
we
we
have
a
steep
road
ahead.
If
we
want
to
bring
collaborative
editing,
I
think
we're
on
the
right
track,
but
we
will
certainly
need
cross-functional
collaboration
before
we
can
really
tackle
it.
B
A
A
Docs
but
yeah,
I
appreciate
bringing
that
up.
This
is
more
of
a
long-term
strategy
for
us.
I
think,
right
now.
The
content
editor
is
very
focused
on
the
the
near-term
opportunity
and
the
mvc
for
just
like
bringing
wysiwyg
editing
across
gitlab
when
we're
in
working
with
markdown
content
and
making
that
as
rich
as
possible,
and
I'm
really
excited
about
the
way
that
it
could
tie
in
to
get
lab
flavored,
markdown
and
the
kind
of
helpers
that
we
have
in
there
and
the
extensions
yeah.
A
B
A
Yep,
well,
I'm
not
afraid
of
some
some
hard
work
as
long
as
it's
bringing
solid
value.
So
I
think
it's
a
it's
a
mountain,
probably
worth
climbing
for
for
issues,
I'm
less
convinced
on
like
pairing
in
the
web
ide,
you
know
like
pair
programming
or
anything
like
that,
as
collaborative
editing
in
in
that
environment.