►
From YouTube: Solution validation summary - Navigating to settings
A
Hello,
my
name
is
mike
lee
of
the
editor
group
and
today
I'm
going
to
talk
about
the
inside
summary
for
the
solution:
validation
issue
number
1306,
which
looks
at
navigating
to
settings
so
for
this
solution,
validation.
It
was
an
unmoderated
study.
Looking
at
three
tasks.
A
First
one
was
to
find
the
name
of
a
protected
tag
in
repository.
So
the
goal
of
this
solution,
validation,
was
to
see,
if
presented
with
new
ways
of
navigating
to
settings
which
way
would
users
choose.
So
we
have
this
button
in
the
middle
here.
So
this
allows
you
to
navigate
to
settings
and
also
as
well
as
a
settings
link
down
here.
A
Most
people
chose
this
settings
link
out
of
the
five.
Only
one
person
chose
this
so
clicking
into
this.
The
user
would
then
be
prompted
to
look
up
the
name
of
the
protected
tag.
So,
in
this
case,
the
answer
would
be
trunk,
so,
as
you
can
see,
the
users
would
have
to
like
scroll
down,
and
this
was
something
that
through
observation
saw
that
like,
even
though
the
ui
is
cleaned
up
and
there's
actually
a
lot
of
sections
within
our
settings.
A
And
potentially
we
could
look
at
different
ways
of
kind
of
showing
an
outline
of
available
different
areas
within
a
different
section.
Somehow
perhaps
an
outline
with
a
list
or
something
like
that
to
help
you
navigate
to
what
you
need
to
the
most
so
once
that
they
discovered
that
the
name
of
the
protected
tag.
What
then
the
next
action
was
to
navigate
back
to
the
repository
session
repository
page?
A
Ideally
they
would
click
on
this
button
here,
but
most
people
miss
that
completely
and
just
click
on
repository,
we're
going
to
look
at
another
solution,
validation
where
we're
going
to
observe
like
revisit
how
breadcrumbs
and
navigation
work
together.
So
that's
going
to
be
for
a
future
issue.
A
The
second
task
was
taking
a
look
at
merge,
request
settings
so
navigating
from
a
merge
request
to
settings,
and
in
this
first
scenario
the
task
was
to
look
at
deleting
this
design
approval
and
seeing
how
people
would
navigate
to
it.
There
are
three
areas
to
navigate
in
this
prototype,
so
there's
this
link
up
in
here.
A
This
link
on
the
right
hand,
side
in
the
sidebar
and
the
settings.
So
most
all
the
participants
are
familiar
with
gitlab,
so
they
went
immediately
to
settings
and
from
here
they
would
search
and
for
merge
requests
settings
here.
They
couldn't
find
it,
but
they
could
quickly
see
that,
because
the
left
nav
is
visible,
merge
request
rules
are
on
a
separate
page
here,
so
clicking
onto
there.
A
A
How
do
you
get
back
to
the
page
that
you
started
at,
but
things
that
we
can
take
away
from
this
was
consolidating
pulling
out
merge
requests
into
its
own
page
will
help
with
discoverability,
especially
if
we
are
moving
with
the
direction
of
having
most
of
these
sections
expanded.
A
Merge
requests
array
has
a
lot
of
items
in
there,
so
allowing
it
to
have
its
own
page
makes
a
lot
of
sense,
and
the
third
test
was
looking
at
ways
to
navigate
to
settings
again,
but
this
time
to
rename
the
approval
rules,
because
this
task
was
sequenced
right
after
the
previous
one.
If
users
clicked
on
this.
A
This
is
the
most
ideal
state
of
it
where
it
shows
only
the
settings
required
for
it,
but
in
a
spirit
of
mvc.
I
think
the
first
iterations
would
have
like
all
the
merge
request
rules
in
here,
and
the
task
here
was
to
rename
design
to
team
members.
So
looking
at
this
interaction
pattern
where
a
model
pops
on
top
of
a
panel,
this
was
easy
for
people
to
follow
and
no
one
complained
about
distractions
or
stuff.
A
People
commented
that
this
felt
faster
than
what
they're
accustomed
to
and
for
some
reason,
the
prototype
doesn't
work
anymore
and
yeah.
There
should
be
like
a
toast
that
pops
up
from
here,
but
then
yeah
the
toast,
was
also
recognized
as
a
good
way
to
provide
feedback
for
what's
going
on
in
the
page.