►
From YouTube: Solution Validation Editing frontmatter #1031
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
So
this
is
editing
front
matter
within
the
context
of
the
static
site
editor,
and
what
we
wanted
to
understand
was
whether
setting
the
front
matter
to
be
editable
as
key
value
pairs
would
be
sufficient
as
a
first
mvc
step
towards
her
solution,
and
we
had
a
hypothesis
that
editing
the
front
matter
in
a
modal
or
a
panel
would
be
preferable.
Then
editing
inline
in
the
page
and
the
research
questions
that
we're
trying
to
answer
is
whether
the
feature
of
editing
the
front
manner
was
discoverable
and
whether
the
feature
meets
the
requirements
of
the
user.
A
This
was
done
partly
as
unmoderated
research
using
a
testing
platform,
and
that
feedback
was
also
useful
for
the
ux
research
team
on
which
tools
to
move
forward
with.
So
let's
get
into
this
a
little
bit
more.
So
what
we
did
in
our
moderate
testing
was
starting
off
with
a
prototype
like
this
to
see
where
users
would
navigate
to
to
edit
the
description
field.
A
They
were
exploring
the
toolbar
as
a
place
to
potentially
add
the
description
to
the
page
in
the
context
around
the
title,
or
perhaps
one
of
these
icons
either
this
code
one
or
this
thing
here,
but
once
they
discovered
settings,
they
clicked
on
it,
and
it
was
quite
obvious
to
see
that
description
field
was
there.
So
that
was
the
first
task.
A
The
second
task
built
upon
this
description
and
it
was
to
figure
out
where
they
would
edit
the
title
here.
I
wanted
to
see
whether
people
would
naturally
gravitate
towards
the
settings
bar,
which
would
allow
you
to
edit
the
title,
or
would
they
try
to
edit
inline
so
editing
inline
would
do
something
like
this,
where
you
click
on
the
title
and
it
opens
up
the
sidebar
there
with
the
title
field,
focused
one
participant
clicked
on
the
title,
but
I
think
due
to
the
priming
of
the
questions
most
well
with
the
settings
options
at
the
top.
A
A
I
think
what's
important
here.
The
key
takeaway
was
that
when
the
section
headings
here
were
received
well,
I
think
the
contents
in
here
is
pretty
short,
so
the
section
was
deemed
not
to
be
really
necessary
versus
just
listing
it
straight
up
here.
So,
but
it's
something
that
we
should
take
into
consideration,
whether
we
have
many
items
in
our
lists
or
different
ways
of
grouping
the
information.
The
key
thing
here
is
that
grouping
the
information
into
logical
blocks
made
a
lot
of
sense
to
people
when
comparing
the
layout
selection.
A
Most
people
worked
with
the
handbook
page
with
the
table
of
contents
and
because
of
this,
they
that
was
the
one
layout
that
they
knew.
They
preferred
seeing
a
visual
expression
of
the
layout
so
that
they
could
have
a
hint
one
participant
suggested
that
you
know.
This
doesn't
really
tell
me
much
like
what
is
this
blob
and
this
lower
blob
here
versus
the
top
one,
because
it
all
looks
the
same.
A
A
A
In
terms
of
author
there's,
author
and
guest
author
there's
different
ways,
we
can
implement
this,
and
this
is
one
way
just
listing
what's
available.
Another
way
is
to
add
a
plus
sign
to
say,
add
additional
authors
and
then,
from
there
kind
of
have
a
flow
to
say.
Is
this
a
good
lab
user?
Is
this
a
good
lab
team
member,
sorry
or
someone
external
to
gitlab
and
adding
their
necessary
details
in
there?
A
A
So
we
jump
into
the
insights
and
some
of
these
I've
already
touched
upon,
so
I'm
just
gonna
roughly
go
over
these
things.
The
form
input
for
front
matters
is
a
familiar
interface
and
it's
user
friendly.
So
that's
definitely
true
and
it's
familiar
in
the
sense
that
it
looks
like
other
cms
systems
out
there.
Other
tools,
I
think
in
front
matter
as
a
form,
will
prevent
errors
and
improve
efficiencies.
A
So
some
of
this
kind
of
stuff
is
that
you
know
the
possible
names
that
can
be
added,
so
you
don't
have
to
wait
for
things
to
be
deployed
to
check
them
and
also
you
don't
have
to
worry
about
dashes
or
spaces
when
you're
entering
information,
if
we
can
provide
validation
on
the
form,
that
would
help
people
a
lot
and
once
again
the
auto
completion,
because
it's
a
form
is
something
that
people
would
expect
yep.
So
this
is
just
touching
upon
the
forum
interactions
potentially
having
ad
additional
users.
A
And
that
said,
with
images,
images
in
the
handbook
aren't
used
not
much
for
main
pages,
it's
more
for
marketing
pages
that
are
shared
out
to
social
media,
but
it
has
been
raised
in
one
participant
scenario
where
they
wanted
to
share
a
handbook
page
on
social
media,
but
wanted
to
have
a
custom
image
in
that
scenario.
So
allowing
this
ability
would
be
useful
to
both
worlds,
discoverability
of
front
matters
and
the
label.
A
However,
after
they
finished
the
first
task,
users
quickly
knew
where
to
go
to
edit
the
title
by
clicking
the
settings
icon
in
the
scenario
where
there
was
a
settings
button
and
the
ability
to
click
on
the
title.
One
participant
clicked
on
the
title
directly
and
better
labeling
could
help
improve
this
experience.
So
settings
alone.
Wasn't
that
clear
and
perhaps
other
names
that
were
suggested
was
edit
metadata
or
page
settings
would
be
more
fitting
for
this
label.
A
The
subheadings
are
good,
but
I
think
there's
other
ways
we
can
do.
Grouping
and
section
things
out
so
that
things
fit
better
on
on
the
on
the
panel
or
model,
whatever
direction
we
decided
to
go
with,
and
that's
it
for
this
quick
run
through
the
solution,
validation
for
front
manner,
any
additional
comments
or
details-
and
you
can
follow
this
issue
link
here,
issued
in
1031
in
the
ux
research
repo,
and
thank
you
very
much
for
your
time.