►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
hello,
there.
So
thanks
a
lot
for
joining
this
session,
where
we
are
going
to
talk
about
content,
editor
and
Source
editor
possible
potential
consolidation.
So
that's
that's
the
probably.
The
very
first
thing
that
we
have
to
figure
out
is
what
what
are
the
expectations
here
so
I'm
I'm
I'm
going
to
move
the
yesterday's
agenda
to
to
die
in
the
in
the
agenda
document,
since
it
didn't
happen
yesterday,
so
I
will
I
will
start.
A
If
you
don't
mind
so
the
very
first
thing
we
have
to
figure
out
is
before
we
talk
about
any
consolidation.
We
have
to
figure
out
what
is
consolidation
in
this
particular
case
right,
so
whether
it
makes
sense
whether
it
doesn't
so
in
my
understanding,
consolidation
doesn't
mean
smashing
the
two
editors
together.
A
Absolutely
not.
There
are
several
reasons
to
not
smash
together.
The
editors,
the
most
obvious
one,
is
that
there
are
still
use
cases
where
having
two
editors
smashed
together,
it
doesn't
make
sense
where
the
tasks
are
sort
of
targeting
only
one
particular
like
let's
say
editing,
Wiki
Pages.
It
doesn't
make
sense
to
pull
in
Source
header
there
at
the
same
time,
pipeline
editor.
A
It
doesn't
make
sense
to
pull
in
content
editor
there,
so
there
are
use
cases
where
we
just
we
just
have
to
have
two
different
two
different
editors
and
also
I,
believe
it
was
in
Eric's
video
on
the
vision
where
we,
where
he
suggested,
is
it
confidential
information
or
not
I'm,
not
sure
that
Vision
thing,
probably
not
anyway.
This
is
not
something
like
hugely
like.
This
is
not
not
Financial.
A
Involvement
involving
information,
so
I
I
believe
in
that
in
that
recording
he
mentioned
that
in
the
presentation
that
we
at
some
point
we
might
want
to
out
to
open
source
both
editors
so
smashing.
Those
together
in
this
regard
doesn't
make
a
lot
of
sense
either.
So
there
are
very
good
reasons
not
to
smash
the
editors
together
right.
So
what
do
we
mean
by
consolidation?
A
How
can
this
be
used?
So,
let's
start
with
the
example
of
polling
and
content
data
into
the
source
header.
Let's
say
we
are
dealing.
We
are
editing
a
file
in
or
we
create
a
new
file
in
the
Repository,
so
the
file
isn't
named
anyhow
yet
so
the
first
thing
we
do,
we
pull
in
Source
editor,
then
the
user
names
the
file
with
MD
extension.
A
So
it's
natural
natural
idea
to
give
user
at
least
the
ability
not
push
it
but
give
the
ability,
let's
say
providing
a
button
to
switch
to
visual
editor
in
this
case.
What
what
should
happen,
in
my
opinion,
in
my
understanding,
is
that
the
The
Source
header
is
seamlessly
swapped
with
content
editor
without
messing
up
the
interface
and
the
user
is
able
to
edit
the
markdown
file
in
the
visual
mode
right.
A
However,
in
the
in
the
near
future,
we
will
prove
we
will
start
providing
like
we
will
start
working
on
the
multi-file
interface
for
the
source
editor,
where
user
will
be
able
to
open
the
file
tree
and
edit
different
if
edit,
multiple
files.
So
let's
say
we
swapped
to
content,
editor
and
then
user
goes
to
the
file
tree
and
opens
let's
say,
Javascript
file.
In
this
case,
we
have
to
provide
the
source
header
for
for
that
purpose.
So
and
again,
the
interface
should
be
very
smoothly.
A
Swapped
from
content
editor
of
the
markdown
file,
a
user
has
been
looking
at
at
the
moment
to
the
Javascript
file,
which
is
the
newly
open
file.
So
things
like
this
when
it
comes
to
pulling
in
the
source
header
into
the
content
editor.
A
good
example
would
be
a
user
edits
the
markdown
file
in
the
weekend,
and
then
they
need
to
pull
it
to
to
to
add
a
code
snippet.
A
What
would
happen?
They
would
have
the
button
add
code
snippet
and
what
this
button
would
do.
It
would
pull
in
The
Source
header,
but
not
swapping
the
content
editor.
It
would
be.
It
would
a
pull
in
Source
header
as
a
widget,
so
to
speak,
where
user
can
edit
the
snippet
get
all
the
benefits
of
syntax,
highlighting
different
extensions
if
they
are
available
for
that
file,
type
click
save
and
that
would
be
converted
into
the
code
snippet
in
the
content
editor.
A
So
things
like
this
again,
the
consolidation
is
about
smooth
transition
between
the
between
the
editors
to
provide
so
that,
even
today,
Julia
posted
a
note
that
we
have
like
five
different
possible
editing
experiences
in
the
product,
so
by
consolidation,
I
I
don't
mean
SWAT,
squat,
so
sort
of
squashing
the
editors.
What
I
mean
is
provide
some
some
way
of
seamless
integration
of
one
into
another
without
actually
sharing
the
code
base
or
if,
if
we,
if
we
can
avoid
that
so
this
is
this
is
my
idea.
A
B
C
So
I
think
thinking
about
these,
perhaps
less
less
less
generally
without
geralizing
to
future
use
cases,
I'm
very
focused
on
on
how
we
can
allow
users
to
use
a
decontinator
to
it.
Files
within
the
single
pilator
I
wasn't
thinking
in
the
opposite
case.
That
is
allowing
users
to
use
the
sourceter
to
a
code
where
the
continuator
is
used,
because.
C
A
A
A
A
We
could
say
that
one
thing,
one
one
sort
of
path
of
consolidation
is
swapping
the
editors
completely
like
in
Source
later
swapping
with
content
data
and
then
in
the
week,
when
users,
edit
with
a
visual
editor,
they
would
be
they
would
get
the
opportunity
to
to
swap
the
whole
editor
with
Source
Editor
to
edit
the
whole
markdown
file
with
code.
This
is
one
thing
and
then
another
one
is
actually
like
targeted
injection
of
the
source
error
into
the
content
editor.
That
would
be
the
second
thing.
C
B
C
Consider
considering
all
as
well
like
teacher
teachers
like
how
you
multiply
8
and
support
within
the
single
file
highlighter,
and
from
that
point
of
view,
what
I
want
to
consider
is
like
what
is
the
the
simplest
path
like
do
we
need
to
think
about
integration,
or
do
we
need
to
think
about
how
we
can
enable
the
user
to
have
like
different
editing
modes
for
for
a
file?
Let's
say
that
the
file
is
like
the
single
source
of
Truth
and
we
want
to
just
like,
have
or
provide
those
different
editing
modes.
C
C
How
can
we?
How
can
we
achieve
that
like?
How
can
we
say
like
how
can
we
separate,
or
or
or
think
about
the
the
single
pilot
or
independent
independently
of
the
of
the
source
hater,
and
that's
it
the
reason
that
I
that
I
think
that
consolidation,
the
consolidation
here
is
like
I
start
thinking
about
integration,
I
start
thinking
like
we.
We
need
to
integrate
both
eight
or
eight
hours
so
that
we
can
allow
users
to
edit
file
systems
in
the
container
in
the
single
file
letter.
But
what
I
want
to
think?
C
A
A
So
and
that's
that's
exactly
the
problem
that
I
would
like
us
to
solve.
That's
why
we
have
to
make
sure
that
we
seamlessly
swap
the
swap
the
things,
but
this
so
this
is
technically.
This
is
not
the
technical
issue,
because
technically
we
can,
we
can
discuss
like
I.
Have
a
I
have
ideas
how
to
how
to
make
this
happen.
A
But
the
problem
we
are
trying
to
solve
here
is
the
actually
actually
the
ux
ux
issue
where
users,
users,
users,
do
not
need
to
know
that
they
have
like
20
different
editors
served
to
them.
It
all
should
feel
like
natural
editing
experience
to
them,
no
matter
the
file
type,
they
are
editing,
so
we
can
talk.
We
can
discuss
how
this
is
technically
possible
to
achieve,
but
the
whole
idea
in
my
understanding
is
sort
of
hooked
on
the
on
the
idea
of
shared
UI
elements.
A
So
the
integration
part
actually
doesn't
like
in
my
in
my
sort
of
idealistic
World.
Probably
the
integration
part,
is
actually
not
that
big
of
a
deal
we
have
and
especially
keeping
the
two
editors
separate
as
two
different
entities
makes
it
a
bit
easier
to
to
achieve.
We
have
two
different
things
and
then,
when
user,
for
example,
clicks
a
button,
we
just
pull
in
one
thing,
so
the
the
the
hard
part
is
actually
do
this
visually
so
that
users
do
not
get
confused.
That's
that's
the
complexity.
A
So,
in
my
understanding,
the
the
very
first
thing
to
do
for
this
would
be
to
to
to
make
sure
that
the
toolbars
of
two
editors
can
say
like
they.
They
are
not
similar
because
they
will
be
for
different
files
right,
but
they
use
the
same
styling
the
same
look
and
feel
the
buttons
are
located
where
they
are
located
like
in
at
the
same
spot
for
both
editors
so
things
you
know
like
Supple
things
like
this,
and
then
we
we
can
create.
A
C
C
How
would
we
design
that
transition
right,
but
I
think
that
an
important
question
that
we
need
to
ask
is
if
all
the
problems
that
you
listed
I
promise
that
we
need
to
solve
odd
ones
to
actually
move
forward
with
enabling
this
feature
to
this
picture
to
users
like
some
of
the
problems
that
you
mentioned
like
having
these
two
different
toolbars,
and
maybe
those
two
toolbars
not
having.
Perhaps
the
same
order
of
the
actions
that
you
can
execute.
A
A
She
started
thinking
about
how
the
source
editor
should
look
like
in
the
future
and
in
specifically
in
terms
of
the
buttons
placement
and
things
like
this
and
accounting
for
the
button
to
toggle
the
file
tree
and
things
like
this,
so
the
only
tech,
technical,
the
only
thing
that
we
have
to
make
sure
is
that
the
the
main
editing
buttons
are
placed
similarly
like
because
she
went
all
the
way
at
the
moment.
We
have
all
the
buttons
on
the
right
side
right.
A
So
what
she
went
in
her
design
is
she
moved
all
the
buttons
to
the
left
side?
So,
if
Source
later
implements
buttons
on
the
left
side
and
then
contact
editor
has
buttons
to
work
with
content
on
the
right
side,
it's
going
to
be
like
a
bit
messy,
so
things
like
you
know,
grouping
of
the
buttons
for
Source
theater.
It
will
be
three
groups
of
of
action.
A
So
the
right
side
of
the
toolbar
will
be
dedicated
to
the
editor-wide
actions
like
toggle
full
screen,
soft
wrapping
things
like
this
and
like
switching
to
con
to
to
visual
editing,
for
example.
Then
the
left
side,
the
yes,
the
left
side
of
the
toolbar-
will
be
dedicated
to
the
content.
Editing
actions
like
bold
italicized.
If
we're
talking
about
markdown
things
like
this
and
then
the
left
most,
there
will
be
only
one
button
on
the
left
Mouse,
which
will
toggle
the
the
file
tree.
So
we
just
have
to.
A
Similarly,
in
two
editors,
and
then
this
this
already
will
create
some
sort
of
feeling
of
okay.
It's
not
technically,
it's
not
100
the
same,
and
it
shouldn't
be
100
the
same
right
because
the
action,
the
buttons
when
editing
far
a
markdown
file
with
a
visual
editor
and
editing
file
with
the
source
header,
those
buttons
will
be
different.
No
matter
what
I'm
not
saying,
we
have
to
create
the
same
buttons,
I'm
saying
that
we
have
to
follow
the
same
patterns.
A
That's
that's
the
main
thing
so
that
user
knows
that
on
the
right
they
have
site-wide
or
editor-wide
actions
which
do
not
change
the
content,
for
example,
and
then
on
the
left.
They
have
the
file
the
the
buttons
that
do
change
the
content.
Just
simple
things
like
this.
So
getting
back
to
your
question
conceptually,
this
is
no
different
to
switching
between
like
classical
editor
and
content.
Editor
in
wikis
conceptually
it's
it's
the
same.
The
only
thing
that
I
want
us
to
do
is
to
make
it
really
smooth
experience
where
user
just
clicks.
A
The
button
excuse
me
clicks
the
button
and
there
are
no
page
reloads.
There
is
nothing
it's
just
like
a
swap
where
even
the
heights
of
the
things
are
preserved.
So
and
it's
it's
really
not
complex
things
thing
to
do
right.
It's!
The
only
thing
is,
is
where,
where
the
complexity
kicks
in
is
when
we
introduce
the
multi-file
editing
thing:
okay,
bye
chat
thanks
for
joining,
so
the
only
thing
the
only
complexity
will
come
when
we
talk
about
the
multi-file
support
in
the
source
editor
in
this
case.
A
Technically,
what
what
should
happen
is
that
when
we
swap,
for
example,
when
we
switch
from
Source
header
to
content
editor
content,
editor
should
not
replace
the
things
responsible
for
the
file
tree.
It
should
really
be
responsible
just
for
the
editor
side
side
of
the
things
so
that
when
I,
for
example,
I'm
on
the
content,
editor
and
then
I
pick
Javascript
file
I
just
open
the
new
tab,
as
as
it
is
in
the
Legacy
web
ID
right,
but
but
I'm
kind
of
I'm
I
get
I
still
get
this
continuous
interface.
A
So
this
means
that
we
have
to
make
sure
that
the
height
of
the
toolbars
in
two
editors
is
the
same.
The
colors
are
the
same.
The
borders
are
the
same,
so
you
know
like
this
tiny
little
things
which
are.
You
know
like
not
very
interesting
and
exciting
from
the
developers
point
of
view,
but
we
have
to
make
sure
that
we
we
work
towards
this.
This
shared
shared
experience
and
this
this
is
sort
of
the
consolidation
that
that
I
mean
in
my
in
my
head.
B
C
We
need
well.
We
I
think
that
we
need
a
follow-up
discussion
where
the
concepts
that
she
is
coming
up
with
about
how
the
the
single
violator
looks
like
in
the
future.
She
should
take
negotiation.
The
idea
that
a
file
might
be
edited
in
multiple
ways
in
multiple
modes,
so
she
can
integrate
that
concept
or
at
least
like
conceptually,
taking
consideration
that
that's
a
news
case,
so
I
I.
C
Imagine
that
the
language
she
was
thinking
about
this
problem
didn't
consider
that
aspect
so
I
think
that
if
she
considers
that
then,
like
other
questions
will
arise,
so
I
think
that's
that's
that
that's
an
action
point
that
that
we
should
take
the
other
actual
problem
is
that
I
understand
that
there
is
an
ideal
way
of
doing
this.
Where.
B
C
Consider
all
of
those
aspects
but
I
think
that
we
should
also
have
an
iteration
plan
for
this
right.
So
let's
say
that
that's
the
local
version,
like
the
description,
well,
the
way
that
you
described
in
the
language,
the
source,
the
single
pilator
works
with
multiple
80
modes.
It's
The
Lovable
version.
But
what
is
the
the
NBC.
A
That's
that's
the
thing
that's
I
wanted
to
jump
on
in
on
this
discussion
before
I
I,
throw
in
any
POC
to
to
show
how
I
envisioned
this
this
consolidation,
and
so
then,
after
that,
we
can
jump
into
the
discussion
and
see
whether
it's
a
viable
POC
or
we
should
think
about
something
else
or
like
in
conceptually
it's
fine,
but
there
are
details
that
we
have
to
think
about
so
I
I
do
plan
to
and
I
have
this.
This
assigned
for
for
15.9
I
have
this
this
task.
A
The
the
main
point
I
wanted
to
I
wanted
to
to
bring
here
is
to
figure
to
to
sort
of
to
make
sure,
because,
from
the
from
the
comments
that,
for
example,
himanshu
left
in
the
agenda,
I
had
the
feeling
that
there
is
some
some
sort
of
attention
it's
like
and
that
that
the
word
consolidation
is
seen
and
perceived
as
like
smashing
together
the
editors-
and
this
is
not
something
that
we
are
going
to
do.
This
just
doesn't
make
any
sense.
A
What
we
have
to
do
is
to
actually
create
the
environment
where
both
editors
can
can
develop.
Their
own
paths
still
find
this
Middle
Ground,
where
they
meet
and
they
meet
so
that
users
do
not
get
the
discomfortable
distraction
or
some
sort
of
experience.
That
thing
makes
them
think:
okay
I'm
getting
from
one
thing
to
another
thing
and
then
from
the
second
thing
to
the
first
thing.
A
A
That's
that's
pretty
much
it
and
that's
that's
why
I
didn't
really
want
to
engulf
Juliet
just
yet
so
that
we
we
figure
out
that
the
Common
Ground,
the
common
understanding
of
how
this
consolation
is
going
to
work,
because,
from
the
engineering
point
of
view
again
when
it
comes
to
pulling
in
content
editor
into
the
source,
editor
I,
don't
I,
don't
have
any
any
new
way.
It's
going
to
be
the
content.
Editor
is
going
to
be
wrapped
into
an
extension
with
View,
and
things
like
this.
A
This
is
this
is
the
easiest.
By
far
the
easiest
way
for
the
POC
and
the
the
good
thing
about
this
approach
is
that
in
this
case
the
source
header
will
just
say:
okay
I'm
done
here,
so
no
toolbar
from
Source
editor,
Nothing,
Like
contact
letter
takes
over
and
that's
that's
his
area
and
then,
when
we
switch
to
another
file,
the
answer
says:
okay,
it
might
even
be
that,
like
if
user,
the
scenario
imagine
this,
like
user,
edits
a
markdown
file
and
then
they
select
edit
visually
right.
A
So
content
data
is
pulled
in
and
then
they
go
to
the
file
tree
and
open
another
markdown
file.
Then
we
have
the
the
possibility
to
remember
that
choice
on
the
first
file
and
we
open
content
editor
right
away,
so
that
because
that's
what
user
prefer
to
edit
markdowns
in
so
they
will
have
two
tabs
with
content
editor
at
this
moment.
The
question
is
whether
content
editor
is
has
capability
of
creating
multiple
instances
on
the
same
page.
C
A
A
A
If
we
do
it
automatically
right
away,
there
are
still
things
that
we
can
do
for
performance
when
user
user
requests
content
editor
not
automatically,
but
by
choice,
for
example,
the
tricks
that
we
do
in
the
repository
when
user
only
hovers
the
button
to
to
switch
to
visual
visual
mode
when
editing
markdown.
That's
the
moment
when
we
start
loading
the
content
editor
and
when
they
actually
finish
the
click.
A
C
Opinions
like
if
it
is
bundled
within
a
source,
extension
or
or
not,
I
I
don't
have
like
a
strong
concerns
about
that
right.
What
I
want
what
I
really
want
to
to
know
is
that,
first,
there
is
no
technical
blocker
like
we
are
both
seeing
that
this
is
La.
This
is
feasible
yeah
and
we
can
achieve
that
and
second
that,
from
a
ux
point
of
view,
is
your
experience
point
of
view.
C
We
have
an
iteration
plan
and,
for
example,
in
the
in
the
case
of
on
this
idea
of
how
these
are
transition
to
the
continuator
yeah.
Maybe
at
some
point
in
the
future
we
can
Implement
something
that
automatically
decides,
which
is
the
best
editing
mode,
but
right
now,
like
probably
the
best
options
is
like.
It's
just
allow
the
Israel
to
decide
to
switch
to
the
continuator,
and
that
is
never
the
default
option,
because
I
said
the
less
intrusive
way
of
doing
things.
B
C
Those
both
of
those
ideas
are
quite
simple.
The
first
one
is
that
we
have
a
technical
direction
that
is
not
introducing
big
architectural
decisions.
We
are
just
like
relying
on
their
own
architectural
decisions
that
we've
made
so
far,
and
second,
we
have,
let's
say
a
proof
of
concept
that
is
simple
to
implement,
because
it's
following
existing
UI
pattern
patterns
and-
and
it's
not
it's
not
intrusive.
The
containers
are
very
like
loading
asynchronously,
so
it's
like
we
have.
A
A
So
we
on
the
engineering
level
level,
we
will
still
can
continue
talking
about
the
technical
implementation,
but
I
want
to
have
some
concept
to
show
what
we
mean
by
swapping
the
editors
and
providing
different,
different
editing,
contexts,
so
I
think
I,
think
and
I
think
we
are
on
the
same
page.
We
understand
that
this
is
this
is
possible.
This
is
this
is
not
like
huge
major,
architectural
rewrite
or
refactoring
or
new
architecture.
A
This
is
just
this
is,
and-
and
this
is
this
is
really
cool,
because
this
is
a
very
good
proof
of
the
both
editors
being
mature
enough
to
to
work
together
without
any
like
major
major
rewrite
or
major
refactoring
in
the
groups
code.
So
I
think
this
is
going
to
be
a
really
good
experience
and
it
will
create
a
really
really
smooth.
A
What
when
it
will
create
the
smooth
editing
experience
for
the
users,
it
will
be
very
well
well
received
in
the
product,
so
I
think
that's
that's
what
we
should
aim
for
and
once
I
pull
in
the
POC
I
will
ping
you
himanshu
Julia
in
the
in
the
POC,
so
that
we
could
take
a
look
at
how
this
works
and
then
I
will
set
up
another
call
so
that
we
could
discuss
this
async.
If,
if
that's
okay,
for
you.