►
A
So
the
purpose
of
this
session
was
to
evaluate
changing
our
category
scorecard
from
minimal
to
viable
and
to
do
that,
we
interviewed
10
participants
and
got
them
to
do
one
task
of
editing
the
handbook
page
and
based
on
that,
we
asked
them
two
questions
for
scoring,
so
one
of
them
was
the
static
site.
Editor
editing
capability
meets
my
requirements,
and
for
that
we
got
a
score
of
4.5
out
of
5
as
an
average.
A
The
second
question
was
static.
Editor
editing
experience
is
easy
to
use,
and
for
that
we
got
a
score
of
4.7
out
of
5..
Both
of
these
scores
are
high
enough
to
allow
us
to
move
our
score
from
minimal
to
viable.
So
that's
a
good
thing
for
our
group.
A
A
So
our
participants
that
took
part
of
this
study
were
also
first-time
users
of
the
static
site.
Editor,
perhaps
only
two
were,
who
have
used
in
the
stack
site
editor
before
most
most
were
brand
new,
and
for
some
of
these
new
editors
they
had
trouble
finding
where
and
the
button
or
the
link
was
to
get
into
the
static
site
editor
because
they
were
trying
to
find
links
at
the
bottom,
so
they're
more
accustomed
to
going
to
the
bottom
of
the
page
to
click
on
the
web
ide
or
a
single
page
editor
to
edit.
A
A
So
once
in
the
static
site
editor,
it
wasn't
that
clear
to
some
people
that
the
text
was
editable
partly-
and
this
is
due
to
the
fact
that
most
participants
were
used
to
the
fact
that
this
that
ui
within
the
gitlab
product
requires
you
to
click
on
edit
or.
A
A
The
page
that
I
got
people
to
edit
was
this
gitlab
handbook
usage
page,
and
the
change
was
about
three
quarters
of
the
way
down,
so
they
had
to
scroll
or
most
used
control
f
to
search
for
the
text
that
they
were
looking
for
and
in
this
scenario,
where
the
person
tried
to
use
ctrl
f,
but
it
wasn't
working,
we
followed
up
with
them
and
they
tried
again
and
the
search
was
working
again,
so
it
might
have
been
an
outlier
there
yeah,
so
people
are
scrolling
up
and
down
and
couldn't
find
the
text,
and
some
people
were
jumping
back
and
forth
between
what
you
see
is
what
you
get
and
raw
markdown
and
that
also
changed
their
cursor
position.
A
The
next
point
was
after
making
submitting
the
changes
that
it
would
appear,
slow
and
some
participants
use
context
switch
during
this,
so
some
ended
up
checking
their
emails
or
other
pa
tabs
on
their
browser,
even
during
the
testing.
So
I
think
in
real
life
yeah,
this
delay
can
is
something
that
we're
looking
at
and
something
we're
addressing
as
a
group.
A
So
so,
if
you
want
to
see
those
scenes
again,
just
once
again
just
click
play
and
then
it'll
play
back
those
and
connect
those
sections
for
you,
and
one
participant
also
suggested
doing
some
more
feedback
and
using
a
progress
bar
or
something
like
that
to
show
the
progress
of
the
things
that
we're
doing.
In
the
background.
A
Managing
emerge
requests
is
a
core
obstacle,
so
one
participant's
quote
was
the
things
that
make
it
difficult
with
merge.
Requests
are
with
edits,
is
merge,
requests
and
the
merge
request
assignments
more
so
than
the
editing
itself.
A
So
that's
this
participant
and
some
people
have
issues
trying
to
find
who
did
who
the
dri
is
to
get
and
to
assign
it
to
and
there's
different
ways.
People
try
to
figure
out
who's.
The
real
person
and
people
find
that
going
back
to
the
handbook
page
to
see
the
different
pictures
of
the
maintainers
is
a
good
sign
which
good
hint
of
who
they
could
assign
it
to.
So
that's
a
useful
feedback
on
that
feature
that
our
group,
the
static
site,
editor
group
added
to
the
handbook
a
few
months
ago,.
A
And
then
we
talked
to
other
participants,
we
focused
mainly
on
sales
and
product
marketing,
and
for
that
we
discovered
in
talking
to
a
lot
of
product
marketers
that
within
the
product
marketing
pages
in
the
handbook,
they
leverage
a
lot
of
embeds.
So
these
links
here
are
key
and
pages
that
have
a
lot
of
embeds,
if
not
very
complex
ones.