►
From YouTube: Issue Refinement Session: Define the UX and technical requirements for a WYSIWYG editor
Description
Enrique and Jean review the technical and UX requirements that we will be using to guide our decision making on what editor solution to use for the Static Site Editor going forward.
A
Hello,
everybody
in
today's
issue
refinement
session.
We
are
going
to
specifically
look
at
this
issue
in
front
of
us.
We
we're
trying
to
define
the
ux
and
technical
requirements
for
our
wizardwork
editor,
so
for
a
little
bit
of
context,
we
are
considering
or
reconsidering
our
requirements
from
from
the
editor
side.
We
did
this
exercise
a
few
months
ago
when
we
started
working
on
the
product,
but
as
our
kind
of
like
direction
evolved
and
as
our
knowledge
of
of
the
technical
space
became
more
clear,
we
realize
we
need
we.
A
A
So
in
today's
session
enrique
and
I
are
going
to
go
through
the
initial
kind
of
flight
requirements
we
had
here
as
well
as
all
the
the
feedback
we've
and
discussion
on
on
this
issue,
and
the
goal
where
we
want
to
end
up
is
that
we
want
to
finalize
these
requirements
and
and
be
able
to
move
forward
where
we
move
on
to
the
next
step.
We
we
want
to
then
research
and
evaluate
the
editor
options
against
these
technical
requirements.
A
So
essentially,
success
today
looks
like
populating
the
the
requirements
in
in
this
issue,
because
everything-
that's
here
all
right,
enrique
you've,
spent
quite
a
bit
of
time
going
through.
You
know,
thinking
about
these
things
is
there
any
kind
of
like
the
high
level
remarks
you
want
to
make
before
we
get
into
the
nitty-gritty
of
you
know,
looking
at
each
of
these
requirements
and
maybe
just
creating
a
definition
or
example,
of
what
we
mean
by
them.
B
Yes,
I
can
focus
on
the
technical
requirements.
Probably
you
have
a
better
understanding
of
the
behavioral
ones
and
and
the
what
we
want
to
achieve
in
the
future,
but
I
I
will
focus
my
comment
on
what
we
learned
in
the
past
four
or
five
months,
developing
the
the
features
that
we
so
far
delivered
in
the
satisfied
editor.
B
B
Perhaps
if
we
want
to
provide
some
advanced
functionality,
we
want
to
interpret
those
template,
syntax
and
display
something
that
the
user
can
edit
or
perhaps
one
of
the
common
cases
in
the
handbook
is
including
a
partial
getting
a
page.
So
maybe
we
want
to
take
that
partial
and
display
it,
and
then
we
ship
with
eight
or
liquid,
because
we
are,
we
are
loading
that
so
that's
a
the
main
impediment
that
we
are
having
right
now
with
those
ui.
B
So
the
idea
is
that
we
need.
We
need
a
nato
or
not
necessary
nato,
but
we
need
to
to
find
pieces
that
allows
us
that
sort
of
accessibility
like
we.
We
actually
need
a
mark,
the
term
parser.
That
is
the
foundation
that
will
help
us
to
to
process
and
render
that
markdown.
But
we
also
need
the
modularity
to
implement
extensions
for
that
parser.
B
A
In
in,
in
summary,
I
think
one
of
the
things
that
I
that
I
also
would
highlight
is
that,
while
our
initial
focus
is
specifically
on
markdown,
you
know
like
we
could.
We
could
end
up
where
we,
where
we
want
to
allow
somebody
to
edit
an
html
page
in
weezyweek
mode,
and
so
it
feels
to
me
like
what
we
really
want
to
do
is
decouple
the
our
writ
or
our
wizardwick
kind
of
like
rendering
from
the
source
and
not
not
say.
Okay,
we
have
a
solution
that
is
specific
to
to
markdown
wizardwick
editing,
which
toast
ui.
A
Does
you
know
it's?
It's
very
good
for
its
specific
use
case,
but
I
think
our
use
case,
and
specifically,
as
you
mentioned,
you
know,
the
fact
that
we
have
partials
and
dynamic
code
embedded
in
templates
makes
it
a
little
bit
more
complicated
than
than
just
saying:
hey
we're
only
working
with
with
markdown.
A
B
B
That
is
what
the
that
we've
been
evaluating.
So
they
have
this
concept
of
of
trans
of
data
transformers,
so
first
they
they
have
like
this
language
to
define
rich
content.
That
is
not
markdown.
That
is
not
html.
It's
like
an
abstraction
of
all
of
all
of
those
languages,
and
then
they
define
this
protocol
where
you
take
either
markdown
or
html,
and
they
convert
those
languages
to
this
command,
which
contains
a
language.
A
B
A
A
Essentially,
what
we
want
to
do
is
we
want
to
say
we
want
to
come
up
with
a
bunch
of
evaluation
criteria,
essentially
that
we
want
to
be
able
to
reference
as
part
of
our
decision
making
process.
Now
this
isn't
a
kind
of
like
a
all.
You
know
you
have
to
whatever
we
do
need
to
check
all
the
boxes,
but
essentially
at
least
want
to
evaluate
whatever
proposals
we
come
up
with
against
these
criteria
and
see
how
they,
how
they
stack
up
to
it.
A
So
what
I,
what
I'm
suggesting
we
do
is
we
take?
We
take
some
of
our
you
know
requirements
and
we
we
provide
a
definition.
You
know
what
is,
for
instance,
what
does
maturity
mean
and
then
what
we
can
do
is
we
can
define
some
evaluation
criteria
to
say
you
know
this
is
what
you
know,
how
we
look
for
maturity
in
in
whatever
solution,
we're
kind
of
like
looking
at.
A
For
instance,
maturity
could
be
the
duration
of
the
project,
it
could
be
the
you
know,
making
sure
that
it's
not
in
a
beta
release
or
you
know,
is
it
at
least
at
a
1.0
release,
or
if
it's
not
you
know,
is,
is
there
any
api
breaking
changes
you
know
in
in
plan?
So
so
I
think
maturity
and
is
probably
you
know
close
to
stability
as
well.
You
know
we
don't
want.
A
B
A
Yeah
and-
and
I
think,
we've
yeah
we're
originally
a
community
as
as
a
specific
entity
which
we
can
cover
as
well.
So
let
me,
let
me
just
break
this,
so
so
from
a
maturity
is
amateur.
Is
the
editor
in
terms
of
feature,
completion,
ie,
stable
api
and
duration
existence?
You
know:
has
it
been
used
and
proven
and
been
proven
over
a
period
of
time?
You
know
where
what
you
know
essentially
what
we
meaning
there
is.
A
We
need
to
be
wary,
it
doesn't
mean
it
excludes
a
project,
but
we
need
to
be
wary
of
something.
That's
like
three
months
old
that
hasn't
been
used
in
projects
also,
I
would
say,
is
hasn't
been
used
in
big
projects.
You're
you're,
looking
at
the
at
you
who
uses
the
library
is
another
indicator
of
maturity.
I
think
so,
how
mature
is
there?
So
so
what
we
can?
We
just
take
this
column
and
so
I'll
copy
this
into
a
table
into
the
issue
when
we're
done,
but
I
oh
just
quick
editing.
C
A
Looking
for
api
stability,
we
want
to
look
at
feature
completion
as
well
in
the
sense
of
you
know.
If
something
you
say
it
is
0.5,
and
it's
a
known
road
map
that
they
that
there's
a
whole
bunch
of
features
that
they're
still
planning.
You
know.
It
obviously
means
that's
a
negative
thing
necessarily,
but
it
means
it
is
an
indicator
of
the
level
of
maturity
of
the.
A
Have
support
that
would
be
yeah.
That
would
be
a
big
challenge
for
us,
because
we
definitely
have
lots
of
this
in
our
handbook
and
we'd
have
to
create
that
functionality
ourselves
then
all
right,
I
think
that's
I
mean
we
can.
We
can
expand
on
these
criteria,
but
I
think
that
that
gives
a
good
indication
of
when
we're
looking
at
the
library.
What
do
we
need
to
evaluate
anything?
You
think
is
obviously
missing
there?
A
I
want
to
call
it
a
healthy
that
there
is
healthy
activity
from
the
community
and
and
the
reason
I'm
saying
healthy
activity,
because
I'm
I'm
seeing
a
community
and
be
more
than
just
writing
code.
You
know
reporting
bugs
helping
with
documentation
stuff
like
that.
I
think
you
know
we
mustn't
just
be
blinded
by
the
fact
that.
B
A
A
There
are
because
that
that,
for
me,
is
one
of
the
the
worst
things
is
when
there's
a
whole
bunch
of
merge,
requests
or
pull
requests,
and
and
but
it's
not
being
actioned
or
at
least
even
if
it's
not
being
merged
in
that
there's
at
least
discussion
about
why
it's
not
happening
we're
still
opinions.
There
are
so
sale,
meaning.
B
For
example,
one
of
the
projects
that
I
that
I've
been
looking
at,
that
is,
the
unified
collective.
They
have
a
sponsorship
from
netlify
from
gatsby
and
they
are
you
know,
sponsoring
economically,
but
also
providing
resources
for
development.
They
have
engineers
working
on
those
projects
and
that's
usually
a
very
good
sign.
A
Okay,
so
so
it
could
be
commercial
or
corporate
sponsorship,
or
even
something
like
a
patreon,
or
I
know
I
think
github
allows
you
to
donate
directly
to
projects
some
projects
as
well
now
and
so
on,
so
some
sort
of
sponsorship.
You
know,
I
think,
the
one
thing
that
I
that
I've
always
so
in
my
days,
working
on
ember,
the
one
thing
I
really
appreciate
about
the
emma
community
is
that
is
their
rc
process,
so
they
was.
A
They
were
very
open
about
changes
that
they
were
going
to
make,
but
also
gathering
getting
feedback
from
the
community
and
addressing
that
end-
and
I
think
I
think
open
to
community
input
is
the
is
the
thing
that
I'd
like
to
put
here.
So
it's
one
thing
to
to
have
a
community,
but
if
you're
not
going
to
listen
to
them,
you
know
that
that's
that's
a
kind
of
like
a
challenge.
B
A
I
cannot
cope
with
a
practice
that
doesn't
have
that
because
it
makes
it
so
difficult
to
know
when
you
can
easily
upgrade
or
anything
and
it
just
it's
the
same.
It's
a
sign
for
me,
of
overall
maturity
and
and
and
completeness
and
and
the
same
thing
with
having
a
test
suite.
You
know
like
you,
want
to
see
those
kind
of
things
in
in
a
project
all
right.
C
B
A
All
right,
I
don't
really
think
we
need
to
dwell
further
on
license.
I
mean
it's
pretty
it's
a
it's
more
of
a
binary
thing
there,
okay
browser
support,
so
this
is
one
that
that
is
definitely
it's
a
bit
of
a
a
weird
one
in
that
browser,
especially
if
we're
going
to
construct
our
our
solution
from
different
projects
that
it's
not
like
a
you
know,
toast
ui
or
you
know.
A
A
B
C
A
A
A
C
A
A
Yeah,
so
I
think
we
can.
We
don't
have
to
specify
then,
if
they're,
if
they're
bundling
it,
it's
basically
a
packaged
chromium.
So
that's
fine!
So
let's
take
that
over
here.
I
think
the
only
two
that
I
mean
link
has,
I
think,
diverged
far
enough
from
webkit
for
us
to
say,
safari
and
chrome,
separate
and
firefox
still
has
their
own
rendering
engine
as
well.
A
A
A
It's
likely
gonna
work
on
on
desktop
as
well
so,
but
I
think
you
know,
obviously
it
must
work
on
our
supported
browsers,
but
I
mean
in
terms
of
the
key
things,
because
I
think
it
comes
back
to
our
discussion
of
you
know
what
was
monaco
that
doesn't
work
on
mobile
and
doesn't
have
you
know
any
plans
to
support
mobile
right
now.
So
I
think
whatever
solution
we
come
up
with
proposal
must
be
able
to
to
work
on
mobile.
A
A
A
C
A
B
B
A
I
I
agree
it.
A
hundred
percent
agree
with
what
you're
saying
there.
I
I'm
thinking
back
on
wizardwick
editors
in
the
past
that
I've
used
and
you
could
literally
provide
a
new
css
file
with
your
theme
values
and
it
would
kind
of
like
cleanly
apply
it
to
the
editor,
all
right,
so
the
next
one
around
extensibility.
A
A
C
B
A
That's
fine,
I
would
I
was.
I
was
just
saying.
The
the
sentence.
Architecture
of
extensibility
in
mind
is,
is
fairly
generic,
but
what
I'm
thinking
about
this?
I
normally
look
for
you
know
you
know,
does
this?
Does
this
plug-in
have
sufficient
events
for
me
to
bind
into,
or
you
know
is
there
proper
functions
to
you
know
is
the
is
it
are
they
plugins
you
know,
like
you
know,
does,
does
it
support?
It's
doesn't
have
like
a
plug-in.
B
B
Accessibility
criteria:
first,
we
we.
We
need
two
levels
of
accessibility,
so
we
are
rendering
markdown.
So
we
need
accessibility
in
the
markdown
parameter,
but
we
are
also
providing
custom
18
tools
for
the
for
the
constraint
that
we
are
rendering,
for
example,
maybe
we
are
rendering
a
partial
we
want
to
render
it
in
a
very
specific
way
in
the
independent
editor.
I
want
that
partial,
maybe
to
not
be
available
or
the
user
will
interact
with
that.
A
C
C
A
A
A
A
B
A
C
A
A
A
A
A
Because,
and
and
also
the
risk
is
that
defining
something
from
a
feature
or
behavior
point
of
view
just
because
it's
not
there
doesn't
mean
we
can't
build
it.
So
so
I'm
wondering
what
best
way
it
is
to
you
know,
essentially
in
our
framework
of
providing
evaluation
criteria,
how
best
to
define
that
I
think
it's
more
a
case
of
making
sure
it
doesn't
restrict
our
desired
behavior
rather
than
you
know
it
doesn't,
you
know,
say,
for
instance,
we
we
use
a
an
editor
that
doesn't
support
kind
of
like
markdown
shortcuts.
A
A
A
This
is
why
this
is
when
the
marketing
growth
team
went
through
their
exercise
of
determining
what
cms's
and
static
side
generators
they
want
to
evaluate
they,
they
broke
it
up
into
a
must-have
shoot
half
nice
to
have
from
a
featureless
point
of
view,
and
then
they
created
a
score
a
score
for
each
of
these
tools
that
they
evaluated
and
that
helped
them
with
till
it
down
to
kind
of
like
a
few
that
they
want
to
do
proof
of
concepts
with.
So
I
think,
essentially,
what
we
probably
want
to
do
is
is
against
this.
A
This
evaluation
criteria,
specify
you
know
specified,
as
must
have,
should
have
nice
to
have
kind
of
thing,
because
ultimately,
what
we
really
want
you
know
is
is
to
evaluate
something
against
these
criteria,
and-
and
we
want
to
know
like
to
your
to
your
point
here-
what
is
the
minimum
so
now
does
it
meet
all
the
must-haves
kind
of
thing?
And
so
I
think
that's
what
we
can
use
to
define
our
minimum
criteria
and
that
would
probably
be
a
step
after
after
this.
A
C
A
A
Okay,
evaluation
criteria:
I
think
this
is
one
of
those
that
whatever
we
use,
this
could
be
expensive
to
have
to
create
ourselves
kind
of
thing.
So
we
almost
this
feels
like
it's
one
of
those
must-have
criterias,
but
I
don't
know
necessarily
how
to
put
that
as
an
evaluation
criteria.
Maybe
it
maybe
the
criteria
simply
comes
with
a
block.
A
Yeah
come
to
the
blog
legit
site
kind
of,
has
a
block-based
editing
approach,
that's
the
criteria
and-
and
I
think
we're
we're
very
much
kind
of
like
clear
on
our
on
the
requirement
of
that.
You
know:
we've
made
it.
This
is
the
direction
we
want
to
go
in
and
I
think
that's
the
right
thing
to
pursue.
A
I
think
this
means
front
matter.
Editing
is,
is
one
that
I
wouldn't
specify
as
a
must
have,
because
what
it
does
feel
like
is
you're
like
we're
pretty
much
creating
a
front
edit
front
meter,
editing
experience
separate
from
the
editor.
We're
essentially
not
not
we're
telling
the
editor.
Don't
worry
about
front
meter,
we'll
we'll
handle
it
in
our
application
kind
of
thing.
C
B
C
A
C
A
Let's
just
quickly
have
a
look
at
our
other
stuff
here,
so
this
is.
This
was
one
of
our
old
ones.
Now,
based
on
the
direction
we're
going
in,
I
don't
think
that
editing,
the
raw
markdown
and
or
being
able
to
switch
between
wizard
mode
and
raw
marker
mode
or
or
having
a
preview
of
markdown
live
preview
is
a
requirement
anymore.
Do
you
agree
with
that.
B
B
A
It
so
define
no
is
a.
It
is
a
power
user
feature,
but
it's
definitely
one
that
we
want
to
facilitate,
because
if
we
don't
do
this,
we
we
run
the
risk
of
alienating
the
more
engineering-minded
team
image
strings
inside
gitlab
who
are
familiar
with
markdown
write
it
every
day,
and
you
know
it's
almost
like.
Second,
you
know
it's
muscle
memory.
A
They
have,
you
know,
writing
markdown
and
instead
of
moving
their
mouse
to
go
and
click
a
toolbar
icon,
you
know
they
they'll
want
to
just
type,
and
so
I
think
that
is
that's
an
important
one.
So
this
again
is
one
that
doesn't
have
to
come
out
of
the
box,
but
it
it
must
allow
the
ability
to
transform
contained.
A
I
want
that
converted
to
to
the
presentation
of
that,
so
you
want
to
must
allow
the
ability
to,
I
guess,
to
to
listen
for
input.
So
I
guess
the
first
one
is
provides
the
functionality
standard
and,
and
then,
but
if
it
does
with
option,
to
extend
or
must
allow
the
ability
to
listen
for
input
and
transform.
A
Right,
so
that's
a
big
behavior
definition
that
we
need
okay,
we're
almost
on
the
hour.
I
have
a
hard
stop
at
at
four
o'clock
because
I
need
to
I
have
an
item
on
the
front
in
the
agenda
that
I
need
to
verbalize.
So,
let's
quickly
see
how
far
we
can
get
visual
styling
and
management
of
tables
right.
This,
I
think,
is
a
is
a
good
one
to
put
down
so
I'm
gonna
call
it
table
visual
table,
editing.
A
A
What
I'm
thinking
of
it
more
is
it's.
You
know
like,
for
instance,
say
say
near
the
gitlab
common
thing
you
know
like.
If
you,
if
you
add
a
comment
you
can,
you
can
start
a
table
like
that,
but
what
you
can't
do
is
you
can't
manage
the
the
table?
You
can't
say,
add
a
new
row
or
add
a
new
column
kind
of
thing,
so
I
think
it
it's
that
second
level
or
second,
you
know,
step
of
interaction
with
the
and
and
customizing
it
so
so,
for
instance,
in
in
toast
ui.
A
C
A
Like,
for
instance,
here,
if
I
right
click
here
and
it-
and
it
says
you
know-
and
I
click
on
properties,
since
maybe
it
comes
up
with
a
dialog
that
that
allows
me
to
set
the
width
and
the
height
of
the
image.
So
it's
it's
like
once
the
once,
the
the
the
syntax
has
been
added,
allowing
me
to
customize
it
in
a
user-friendly
way.
A
B
A
A
A
I
think
that's
part
of
the
accessibility
that
is
you're
right.
I
I'm
always
thinking
like
it's
going
a
step
too
far
to
define
you
know,
table
editing.
I
think
what
I'm
really
just
talking
about
is
the
ability
to
to
you
know
continue
like,
for
instance,
right
now.
You
know
like
we
don't
even
know
that
they're
hitting,
but
I
feel
like
which
eating
this
is
so
you
know
it
doesn't
show.
So
I
feel
like
it's.
The
it's
like
once,
the
the
syntax
is
being
rendered
is
to
continue
editing
that
in
that
blog,
it's
block
customization.
A
B
B
A
So
yeah,
so
it's
it's
wizzy
week,
interface,
to
to
interact
with
with
existing
elements.
Is
that
the
way
we
want
to
phrase
it
all
right?
Okay,
we're
on
the
hour
we're
going
to
stop
the
call
enrique.
I
think
we've
got
a
good
structure
going
here.
I
think
what
we
should
do
is
we
should
continue
just
fleshing
this
out.
I
will
take
the
action
to
to
keep
fleshing
out
the
the
ux
ones
and
then
async
we
can.
A
You
know,
but
we
try
to
overall,
but
we
want
to
at
the
kind
of
like
to
be
able
to
score
things
we
probably
want
to
indicate
what
of
these
are
like,
for
instance,
no
jquery,
you
know
is
a
must-have,
because
our
code
base
is
moving
away
from
jquery.
We
wouldn't.
We
don't
want
to
reintroduce
that.
If
it's
vanilla,
javascript
is
okay,
if
it's
vujs,
it's
nicer
kind
of
thing,
but
let's
take
it
one
step
at
a
time.