►
From YouTube: Content & Source Editors consolidation. Session 2
Description
In this session we check the PoC for the effort and talk about potential UX issues, future concerns, etc.
A
A
It's
about
letting
both
editors
live
on
their
own,
but
thinking
about
how
we
can
make
those
play
together
in
the
same
environment
and
to
allow
users
to
easily
switch
between
the
two
and
as
we
agreed
during
the
first
session
with
Enrique
we
take,
we
take
it,
we
take
it
in
the
baby
steps
and
the
very
first
step
is
to
see
how
we
can
like.
We
had
two
approaches
possible
approaches
to
let
the
editors
somehow
communicate
with
each
other,
and
the
second
one
was
to
somehow
move
one
into
another.
A
We
just
discarded
the
second
one,
so
we
talk
about
full
size,
editors
playing
together
and
the
very
first
use
case
in
order
to
take
it
in
a
real,
really
simple:
we
will
oh
Angelo
I'm.
Sorry
I,
see
you
typing
I!
Think
the
I
just
put
the
wrong
date
here.
The
all
the
tags
you
see
below
is
the
text
that
I
prepared
for
today's
Me
session.
We
just
need
to
put
the
attendees.
Thank
you
very
much
so
yeah
getting
back
to
that
train
of
thought.
A
But
I
came
up
with
the
POC
as
we
agreed
during
that
that
first
session
and
technically,
the
point
of
today's
meeting
is
to
demonstrate
that
POC
we
have
the
link.
The
link
is
in
the
agenda
with
all
the
all
the
things
in
place.
There
is
no
video.
There
is
nothing.
So
it's
going
to
be
the
first
time
we
we
see
this
POC
here
before
I
start
sharing
my
screen.
Do
we
have
any
questions.
A
A
A
Now,
in
the
repository
we
have
the
toolbar
here,
so
I
played
a
bit
with
the
toolbar
already
following
the
Julius
suggestion
of
moving
the
content,
editing
actions
to
the
right
of
the
toolbar
and
placing
the
sort
of
the
editor
wide
actions
on
the
left
and,
in
particular,
I
have
added
one
button
again.
We're
talking
about
the
POC
real
button
might
look
completely
different.
It
might
be
the
drop
that
and
it
should
be,
probably
the
drop
down
as
we
use
in
the
contact
editor
where
we
switch
between
the
markup
and
reach
text.
A
But
that's
that's
that's
it
for
now
and
we
click
that
button
and
we
are
in
the
content.
Editor
no
page
load,
nothing.
We
are
in
the
in
the
editing
mode
here
we
can
just
add
something
something
new
here:
let's
make
it
header
one
again,
and
then
we
can
using
the
same
switch
that
we
already
have
in
the
content
editor.
We
can
get
back
to
the
to
the
markdown
and
we
are
back
to
our
code,
editing
with
the
header
in
place,
the
new
header
that
we
typed
in
the
same
way.
A
We
can
do
you
think,
oh,
let's,
let's
type
in
other
characters,
let's
at
least
use
caps,
lock
the
same
thing
we
type
in
things
in
the
markdown
we
switch
to
the
to
the
visual
editor,
and
since
this
one,
this
text
that
I
typed
in
was
not
the
header.
It's
just
the
regular
text
and
that's
that's
how
it
is
how
it
should
be
rendered
if
we
type
in
the
new
line
here
it
will
be
the
separate
paragraph.
A
Are
in
sync
between
the
the
two
editors,
so
we
can
we
can
do
whatever
we
want,
and
the
main
question
is
of
course
like:
does
it
like
changing
changing
things
in
two
different
editors?
Is
fine,
but
it's
useless
as
long
as
we
cannot
commit
really
right.
So,
let's
switch
to
the
visual
editor
and
try
to
commit
from
the
visual
editor
here.
A
B
C
A
Yeah
yeah,
it's
just
when
you
preview
is
only
when
you're
in
the
code
editor
a
code
like
in
the
markdown
mode
right,
so
so
that
you
could
follow
the
things
that
you're
typing
on
the
screen.
You
cannot
edit
here
right.
So
that's
that's
kind
of
the
the
the
in-between
step
between
the
markdown,
the
code
and
markdown
as
the
rich
rich
text.
A
A
This
this
is
a
very
good
point
and
I
was
thinking
about
this,
but
the
difference
in
preview
and
content
editor
is
that
again,
content
editor
allows
to
edit
and
like
having
two
editing
interfaces.
Side
by
side
doesn't
make
a
lot
of
sense.
Moreover,
pulling
in
content
editor
just
for
the
preview
function,
isn't
really
performant.
Operation
preview
is
much
lighter
thing.
We
just
make
one
API
call
and
get
the
content
rendered
from
the
server.
A
A
A
However,
the
the
content
editor
gets
pulled
in
only
when
we
switch
to
the
content
editor.
So
that's
that
creates
this
sort
of
performant
aspect
to
at
least
loading
this
this
page.
So
with
this
POC,
we
won't
harm
loading
performance
of
these
editing,
editing
form.
However,
when
we
are
already
in
the
when
we
have
fetched
the
the
content
editor,
it's
not
going
anywhere,
so
you
will
see
that
the
switch
happens
instantly.
We
do
not
load
anything,
it
stays
there.
A
So,
okay,
getting
back
to
the
original
question
or
a
suggestion
to
replace
the
preview
with
content,
editor
I
still
think
that
the
classical
preview
has
its
has
its
hues,
because
it
doesn't
require
anything
new
with
content
editor.
It
would
require
us
to
think
about
how
to
how
to
to
do
this,
and,
in
particular,
I'm
very
worried
about
the
confusion
moment
when
people
will
have
to
actually
editing
interfaces
side
by
side,
so
they
can
edit
here
and
they
can
edit
here
and
it's
it's
a
bit
scary
to
me.
A
D
D
A
A
Right,
yeah,
yeah,
technically
it's
as
I
said
it
is
possible.
Technically
there
is
nothing
impossible
here
right.
The
only
thing
is
that
we
will
need
to
to
think
properly
about
the
engineering
solution
here,
because
the
solution
with
two
editing
interfaces
is
prone
to
memory
to
to
memory
leaks
due
to
keeping
the
editors
in
sync
constantly
after
every
character,
typed
in
right.
This
solution
is
not
doing
that
because
we
do
not
show
the
editors
side
by
side
where
we
do
not
sync
the
editors
on
right.
A
Yeah,
so
so
it
will,
it
will
kind
of
open
the
Pandora's
box,
but,
as
I
said
like
we,
just
it
just
means
that
we
will
have
to
be
very
careful
with
the
engineering
solution
here
and
it
can
well
be
the
next
step,
but
for
now
I
think
we
are
total.
We
should
be
totally
fine
with
either
or
kind
of
like
either
mark
down
with
preview
or
reach
text.
C
A
A
C
A
A
A
C
A
C
A
I
I
actually
think
that
we
need
to
custom.
We
need
to
extend
the
toolbar
for
the
source
Editor
to
to
allow
support
for
the
drop
downs
and
then
just
use
exactly
the
same
Button
as
we
have
in
the
contentator
I
I.
Think
I
even
wrote
this
down
in
in
the
yeah
in
the
agenda.
I
put
it
as
a
separate
point
because
we
have
to
like
this
is
this
is
sort
of.
A
In
my
understanding,
this
is
the
glue
between
the
two.
So
we,
the
button,
has
to
look
exactly
the
same
between
the
two.
That's.
What
will
make
this
consolidation
real
like
that
this
will?
This
switch
will
feel
very
natural
to
the
users,
even
though
the
rest
of
the
buttons
will
be
changed.
If
this
one
button
stays
the
same,
that's
that's
what
will
give
the
users
feeling
of
okay?
This
is
the
same
thing
which
I
just
switched
them
out.
So
I
think
that,
because
this
this
button
is
so
non-informative.
A
This
is
just
I,
took
pretty
much
the
only
more
or
less
possible
shooting
button
from
from
the
gitlab
svgs,
but
I
think
this
drop
down
is
a
much
more
informative
and
much
better
solution.
So
what
we
have
to
do
is
actually
leave
content
editor,
as
is
but
extend
the
toolbar
for
for
Source
header
in
order
to
contain
the
same
button.
E
Yeah
I
want
to
raise
a
point,
I
think
I
think
that's
a
good
answer,
although
probably
the
way
we
will
organize
buttons
will
also
depend
on
the
way
we
want
to
organize
those
previews
and
editing
and
stuff.
So
maybe
that's
the
way
to
process
the
the
steps
right.
Unless
yeah,
we
don't
want
to
evaluate
the
idea
of
having
the
you
know,
editable
preview
in
a
sense
but
I
think
it's
something
we
could
work
on
and
then
definitely
coherence
in
the
buttons.
It's
a
it's
a
great
point
we
need
to.
A
The
order
of
the
buttons
is
more
or
less
the
same,
and
that's
that's
pretty
much
it,
but
we
won't
be
able
to
do
to
make
the
things
identical,
I
think,
but
we
still
can
make
it
more
or
less
similar
and,
as
I
said
this,
one
button
that
will
stay
on
the
on
the
screen
should
be
exactly
the
same.
In
my
opinion,
but
again
we
are
getting
to
Julius
field,
so
Julia
will
tell
us
how
to
do
this.
Julia
will
tell
us
what
nift
needs
to
be
fixed
here,
because
this
is.
A
A
Okay,
so
I
think
this.
This
is,
this
is
still
POC
right.
It's
it's
pretty
that
it
has
been
done
pretty
a
lot
in
this
POC,
but
it's
still
a
POC.
It
has
to
be
digested,
it
has
to
be
fine-tuned,
but
I
think
this
would
be
a
very
good
way
of
introducing
Con,
in
particular
content
Editor
to
even
wider
audience
and
technically
introduce
content
Editor
to
pretty
much
all
of
the
markdown
editing
interfaces
and
experiences
we
have
in
the
product.
This
is
from
from
what
I
understand.
A
D
D
A
In
general-
and
this
this
is
where
we
are
getting
now
in
general.
This
particular
solution
would
allow
us
to
get
to
to
issues
and
to
to
comments
as
well
combining
the
source
header
in
content
editor.
This
way
we
would
have
hundred
percent
consistent,
XP
editing
experience
for
all
markdown
files,
except
for
weekly,
because
Wiki
is
is
separate
thing
I,
don't
believe
that
we
have
to
pull
in
Source
header
into
wikis.
A
That
would
be
a
bit
of
a
stretch,
I
think,
but
for
the
for
the
descriptions,
comments
and
single
file
editing.
This
is
this
is
definitely
something
to
to
think
about
in
my
in
my
idea,
but
we
are,
we
are
getting
of.
Eventually
we
are
getting
close
to
the
to
the
end
of
this
hour.
What
are
the
interesting
things
here?
What
has
to
be
done
here?
I
wrote
in
one
of
the
comments.
A
A
Let
me
just
explain
it
with
the
with
a
patch,
so
let
me
just
get
it
here:
apply
stash,
so
let's
reload
this
thing
and
get
rid
of
the
so
let's
this
is
yeah.
This
is
definitely
not
the
correct
file
but
because
I'm
actually
fetching
the
content
from
from
the
local
storage.
Here,
let
me
just
clean
it
up.
A
A
A
In
this
particular
case,
nothing
in
the
interface
tells
the
user
that
this
is
not
the
real
content
of
the
file
they
are
looking
at.
This
is
the
restored
content,
and
this
is
very
crucial
in
terms
of
the
committing
workflow,
so
users
might
not
notice
that
they
have
some
type
or
somewhere
down
on
the
screen
that
they
were
working
with
and
then
just
reloaded
the
page
and
forgot
about
that
change.
Nothing
in
the
interface
tells
them
that
this
is
the
restored
content.
This
is
not
100
identical
to
the
to
the
real
content
file.
A
A
I'm
just
kidding
this
app-
this
is
this
is
literally
I
was
finishing
a
couple
of
seconds
before
we
started
the
call.
So
I
didn't
finish
this
so
in
case
we
are
restoring
restoring
the
version
from
the
local
storage.
We
can
show
definitely
not
this
but
proper
G,
proper
alert,
saying
the
content
has
been
restored
from
with
your
local
changes,
and
then
this
text
switch
to
the
server
version
should
be
the
link
that
will
clean
up
the
local
storage
and
reload
the
content
as
it
is
on
the
server.
A
We
might
even
go
one
step
further
and
provide
the
link
to
show
differences
between
this
version
and
the
version
on
the
server.
This
is
totally
possible
as
well
using
the
source
header.
So
there
are
things
to
consider
when
we
talk
about
restoring
content
from
the
local
storage
in
this
particular
instance,
because
this
might
very
negatively
affect
when
when
when
somebody
commits
things
that
should
not
be
committed-
and
they
just
don't,
have
any
clue
about
that.
A
A
So
if
users
switched
to
the
to
reach
text
editor
and
then
they
they
reload
this
page
or
get
to
another
markdown
file,
they
will
go
straight
to
the
to
the
Rich
Text
Editor
instead
of
source
editor.
So
that's
that's
that
gets
preserved.
That's
not
a
big
deal
and
I
have
to
tell
you
that
I
took
this
was
this
was
really
great
exercise
because
I
learned
so
much
By.
A
Looking
into
the
content
editors
code,
Thank,
You
Enrique,
it
was,
it
was
really
great,
like
I
was
thinking
how
to
do
that
and
how
to
do
that
and
then
I
figured
out
that
Enrique
already
did
this
in
the
content.
Theater!
Oh,
that's!
That's
super
Time
Saver
so
and
getting
back
getting
to
the
actual
implementation
and
I'm
I'm.
Pretty
sure
Enrique
will
be
happy
to
hear
this.
This
is
not
implemented
as
an
extension
like
a
Content.
Editor
is
not
extension
here
to
the
source.
A
Hitter
like
that
thing
that
everybody
was
scared
of
is
not
gonna
happen
here,
so
Enrique
can
breathe
freely.
This
is
pure
view.
Application
I
can
I
can
probably
I
need
to
share
my
my
editor.
Now
we're
actually
I
will
no
I
will
continue.
Staying
here,
I
will
just
go
and
grab
the
all
the
URL
to
our
to
our
merge
request.
A
So
if
we
go
to
the
commits
of
this
merge
request
the
the
POC,
where
is
it
yeah?
Here
we
go
so
the
whole
consolidation
is
just
one
view
component
where
we
use
content
editor
as
the
view
component
and
Source
header.
As
view
component,
this
makes
things
so
much
easier
for
this
particular
implementation,
much
easier
to
maintain
it's
just
what
I
in
the
beginning,
I
started
working
with
them
within
with
an
extension,
but
then
I
I
figured
out
that
it
so
doesn't
make
sense
here.
A
So
we
just
switched
to
to
pure
view
implementation
here,
I
see
that
Enrique
is
already
happy.
So
that's
that
makes
me
happy
because
seriously,
this
will
make
it
much
easier
to
maintain
by
any
team
member
in
the
group
so
and
like
the
the
communication
between
the
two
editors
will
be
much
much
simpler.
A
Right:
okay,
okay
Enrique:
this
is
considering
concerning
just
this
particular
implementation,
but
other
implementations
we'll
talk
to
talk
about
a
bit
later,
but
the
cool
thing
you
know
what
is
the
best
thing
ever
happening
in
this
POC
is
that
we
actually
finally
get
to
use
that
old
web
editor
thing
that
we
have
all
over
the
documentation.
Nobody
knows
what
that
is,
so
this
Consolidated
Source,
editor
and
content.
Editor
is
called
Web
editor
now
and
now
all
of
our
documentation
automatically
going
to
be
relevant
to
the
to
the
correct
place.
A
A
The
Blob
editor,
we
do
not
like
there
is
no
blob
editor
implementation
per
se.
There
is
the
JavaScript
module
that
pulls
in
Source
editor
in
raw
format,
but
we
have
the
feature
flag
introduced
here
so
oops
not
to
my
profile
but
to
the
feature
flag.
So
we
have
the
feature
flag
that
technically
allows
in
the
again,
let's
go
here
in
the.
Where
is
this.
A
A
Otherwise
we
get
to
this
new
web
editor
module
and,
and
that
one
all
it
does
is
just
bootstraps
the
View
application
and
passes
down
the
properties
from
from
rails
to
down
to
view
so
this
this
is
it
bootstrap
module
for
so
super
Trail.
Super
simple
bootstrapping
module
that
just
bootstraps
The
View
application
for
the
for
the
web
editor
component
and
that's
it.
A
Very
straightforward,
very
simple:
so
that's
that's
pretty
much.
It
I
have
the
list
of
the
things
that
should
still
be
done
in
my
opinion,
so
it's
there
are
some
some
things
that
are
different
when
we
switch
between
the
things.
So
if
we
go
to
the
markdown,
for
example,
and
I
type
in
multiple
lines
here,
I
switch
to
markdown.
Obviously
they
do
not
render
as
multiple
lines
unless
I
edit
the
markdown
file.
They
stay
the
same,
but
once
I
edit,
the
markdown
file
in
the
reach
text
editor
and
get
back
to
my
markdown.
A
Those
empty
lines
are
gone.
Should
we
even
care?
I,
don't
think
so?
But
it's
just
something
to
keep
in
mind.
It's
it's
still
like
a
full
markdown
as
many,
no
matter
how
many
empty
lines
you
type
in.
It's
still
just
one
empty
line
for
markdown
when
you
render
it,
but
some
some
changes
like
this.
Probably
we
have
to
keep
in
mind,
probably
not
I,
wouldn't
I.
D
If
what
you're
seeing
is
the
the
problem
statement
for
that
whole
effort,
which
is
as
you
toggle
between
the
two
it's
going
to
reformat
and
sort
of
yeah
prettify
your
markdown,
but
based
on
the
set
of
rules
that
we
have
on
our
deserializer?
So
if
we,
if
you
wrote
a
markdown
file-
and
it's
really
long-
and
it
has
footnote
style
annotations
for
links
rather
than
inline,
like
you,
switch
back
and
forth,
it's
going
to
mess
up
all
your
links,
they
won't
break.
But.
A
Do
two
Styles
here,
then
both
of
them
are
italicized
in
the
reach
text,
editor
right
right
and
they
they
are
the
same.
If
I
don't
change
that
text,
but
once
I
change
the
text
in
the
content,
editor
yeah
both
of
them
are
unified.
So
that's
exactly
but
those
those
are.
Those
are
not
news
right,
so
they
we
do.
We
do
know
about
those
right.
D
It's
not
yeah,
it's
not
new,
but
I
do
think
it
might
become
a
blocker
to
Rolling
it
out
wide
as
a
option.
This
is
great
Dennis.
By
the
way,
this
very
timely
Angelo
is
going
to
be
kicking
off
an
effort
this
week
to
to
understand.
What's
next
for
the
content
editor
for
over
his
internship
in
the
next
quarter,
extremely
timely
demo
and
proof
of
concept,
I
really
appreciate
it,
because
what
we
need
to
figure
out
now
is.
Is
this
the
next
step?
D
E
D
We've
just
finally
come
full
circle
around
to
the
edit
one
markdown
file
visually
problem
statement
and
with
the
great
work
that
Enrique
and
Munch
have
been
doing
on
the
content
editor,
we
actually
might
be
able
to
realize
the
full,
like
mature
version
of
that,
within
the
application,
without
any
fancy
rewriting
of
code
or
injecting
dependencies
into
a
middleman
project.
We
can
just
pull
up
a
markdown
file
edit
it
visually
and
commit
yep.
A
Yeah,
but
so
technically
there
are-
and
there
is
one
one
more
thing
that
is,
that
is,
that
has
to
be
implemented
on
the
source,
editor
side
of
the
things,
and
that
was
that
came
as
a
surprise
to
me.
We
actually
do
not
have
file
upload
in
this
single
file.
Editor
like
like,
like
no,
we
just
do
not
allow
users
to
do
that
like
there
is
no
button
to
upload
an
image
I.
A
Yeah,
so
it's
it's
the
the
thing
like
either
we
do
it
on
the
either.
We
add
the
support
to
the
source
header
with
a
button
and
and
the
support-
or
we
just
will
have
to
trim
this
in
the
content
editor
for
this
implementation,
but
I
would
much
rather,
of
course,
extend
this
like
two
files
commit
that's
fine
like,
but
it
was
the
user
who
actually
added
this
image,
no
matter
what
so
yeah
and
also,
as
the
like
you
know,
getting
looking
into
the
Far
Far
Future
this.
A
This
consolidation
would
also
help
us
to
play
the
other
way
around.
So
if
users
prefer
editing
markdown
files
in
the
markdown
in
the
reached
text
format,
but
they
still
want
to
check
the
changes
before
they
commit.
That's
where
the
source
header
would
back
this
up,
because
we
would
be
able
to
actually
switch
to
Source
header
and
show
the
diff
model
to
show
the
differences
between
the
original
document
and
the
edited
document.
So,
in
my
opinion,
this
consolidation
is
a
great
Improvement
of
the
single
file
editor
there
are.
A
C
Yeah
that's
great
work.
There
is
an
implementation.
I
think
that
the
Simplicity
that
which,
like
you
implemented
this
is
quite
evident,
I'm,
very
glad
that
it
was
like
so
straightforward
to
switch
on
the
content
between
both
of
them
and
I'm,
surprised
about
the
story
in
the
the
preference
of
which
is
the
date
or
that
the
last
letter
of
the
user
was
using
today.
The
file
so.
A
D
D
I
I
love
it.
This
gives
us
a
lot
to
talk
about
Dennis
I.
Don't
we
were
gonna
scope
it
just
to
content
editor,
but
given
this
I'm
gonna
add
you
to
our
kickoff
call,
because
it
could
come
up
that
this
is
like
the
next
step
that
we
want
to
take
and
have
Angela
work
on
so
I'm
gonna.
Add
you
this
on
Thursday.
So
if.
A
Yes,
so
that's
that's
pretty
much.
All
I
wanted
to
show
you
if
you
want
to
get
into
the
code.
The
the
link
is
in
the
agenda
with
some
links
to
particular
commits
about
different
different
phases.
So
that's
that's
pretty
much
it
as
as
mentioned
previously,
it's
very
straightforward
implementation
so
which
which
actually
highlights
how
mature
both
Source
header
and
content
data
are
like
just
take
those
things
combine.
D
Switching
within
the
web
editor
as
well,
but
yeah.
It's
a
I
think
this
is
probably
the
more
straightforward
from
problems
to
solve.
First
step
for
the
web.
Editor
then
jumping
right
into
solving
the
multi-file
because,
as
we've
learned
from
data
like
85
percent
of
all
commits
or
something
like
that
from
the
web,
editors
were
a
one
file
change.
So
we
know
we
can
solve
a
lot
of
people's
problems
with
just
this.
While
we
focus
on
getting
the
right,
ux
and
solving
the
right
problems
with
the
other
solution,.