►
A
So
the
idea
to
explore
this
idea
came
from
this
issue
that
was
raised
a
few
months
ago
about
potentially
combining
the
review
tab
with
the
commit
tab
into
one
because
it
they
almost
showed
the
same
information.
But
there
were
certain
subtleties
that
we
could
combine
the
tabs
to
make
it
an
easier
experience
for
users
to
navigate,
especially
coming
from
a
merge
request
back
to
the
web
id
to
review
something.
Sometimes
it
could
get
confusing
on
what
was
being
reviewed
and
what
was
being
committed.
A
So
to
do
this,
we
allowed
users
to
be
placed
into
the
web
id
in
review
mode
and
we
presented
files
the
change
lists
and
ask
the
users
if
they
can
verify
what
the
parent
folder
is
for
each
file
next,
showing
the
path
of
the
file.
When
listing
the
files,
can
you
know
the
change
files
in
the
merge
requests
will
help
users
with
better
scannability.
A
So
what
we're
going
to
do
to
test
is:
ask
the
users
what
they
think
of
what
each
icon
means
on
on
its
own
and
in
the
context
of
the
solution.
In
the
context
of
a
change
list
to
see
if
it
makes
if
they
can
correctly
identify
the
icons
and
finally
allowing
users
to
view
the
current
changes
that
are
part
of
a
merge
request,
so
this
is
isolating.
The
change.
Files
in
a
separate
list
will
help
the
reveal
process,
especially
in
the
web
ide.
A
So
what
we're
planning
to
do
here
is
by
isolating
the
list
of
changes
in
into
a
changes,
tab,
which
is
a
variation
of
this
list
approach,
but
I'll
show
you
that
in
a
moment
and
what
we
expect
that
people
preferred
the
changes
tab
over
the
current
experience,
so
to
take
a
look
at
whether
we
need
to
provide
a
tree
structure
or
file
names.
Next
to
this,
we
asked
users
to
compare
and
contrast
options,
a
b
and
c
and
talk
about
which
ones
more
advantageous
for
their
work.
A
So
this
is
what
we
have
currently.
This
is
explorations
with
a
tree
and
this
exploration
with
the
file
names
on
the
side.
One
thing
that,
in
the
solution,
validation,
is
that
there
were
no
hover
effects
on
on
the
image.
So,
therefore,
in
production,
if
you
hover
over
this,
it
will
tell
you
the
parent
path,
but
in
in
isolation
like
this,
it
doesn't
tell
you
anything,
whereas
these
ones
tell
you
the
information
you
need
to
know
without
having
to
do
any
hovering,
then
there's
downsides
to
this
as
well.
A
And
then
this
is
the
tabbed
approach
so
similar
to
this
idea
of
having
changes
in
files.
We
we
went
with
that
and
changes
of
files
here
where
we
isolated
it
into
tabs
instead
of
a
stack
list
within
with
the
idea
that,
like
if
the
changes
are
really
long,
then
this
could
push
down
the
file
tree.
So
that
was
the
background
behind
that.
So
we're
exploring
this
concept
to
see
if
this
gives
users
a
better
experience
so
jumping
into
the
insights.
A
A
So
what
are
we
going
to
do
with
this?
We're
probably
going
to
keep
things,
as
is
for
now,
because
at
the
moment
we
have
the
list
there
and
it's
easy
to
parse,
and
if
you
hover
over
it,
you
can
see
it.
There's
probably
things
that
we
can
improve
upon
accessibility,
because
the
hover
effect
is
something
that
you
need
to
do
to
see
we'll
check
to
see
if
that
works,
with
keyboards
only
navigation
but
yeah.
A
A
A
People
did
really
didn't
really
understand
what
the
merge
request
icon
meant.
So
some
people
thought
that
meant
that
these
were
files
that
had
been
merged
already
into
the
branch.
Some
people
guessed
that
it
was
correct.
That
was
part
of
the
merge
request,
but
it
was
very
hit
and
miss
with
the
understanding
of
that
icon.
So,
potentially,
moving
away
from
that
icon
and
just
having
it
in
a
change
list
could
be
much
more
clear.
People
understood
the
added
file
icon
very
well
and
modified
people
guessed
that
it
was
either
modified.
A
One
person
guessed
that
it
was
a
file
in
progressive
syncing,
hence
the
orange.
So
that's
something
that
we
should
be
aware
of
with
the
colors
that
we
use
moving
forward,
but
yeah
modified
and
add
they're.
Okay,
the
merge
request,
icon,
no
one
understood
yeah
so
and
then
reducing
the
tabs
on
the
clarity
of
the
page.