►
From YouTube: Converge on design concept to restructure merge requests
Description
Annabel Gray and Pedro Moreira da Silva, Product Designers from Create:Code Review, discuss the design concepts to restructure merge requests (MRs), to converge on at least 2 concepts to prototype and validate against our current design.
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/365334
A
So
we
have
just
for
some
context.
We
have
these
different
design
concepts
that
were
added
to
this
issue,
to
converge
on
design
concept
for,
and
we
had
designers
chiming
in.
We
had
also
stanislav
our
front-end
engineer
from
code
review,
chime
in
as
well
and
share
his
opinion
and
and
yeah.
I,
in
our
code
review
group
meetings
doc.
A
A
Others
are
just
too
specific
concepts
that
I
have
named
here:
accordion
or
accordion,
and
anacond
sidebar,
tab
concepts
and
so
on,
and
then
we
have
a
space
here
for
open
questions,
but
yeah
we
can.
We
can
quickly,
go
through
them
and
then
maybe
talk
about
each
of
the
design
concepts
and
try
to
then
choose
two
design
concepts.
They
don't
have
to
be
exactly
as
they've
been
shown
here
or
actually
help
me
open
here
figma.
A
What
we
need
to
decide
on
is
just
the
basic
idea
of
each
of
the
concepts
that
we
choose
and
we
can
then
refine
a
few
things
here
and
there
I
mean
we
will
be
forced
to
refine
them
when
we
get
to
prototype
them
and
get
them
ready
for
validation.
So
we
can
compare
with
the
current
design
so
so
yeah
any
questions
before
we
get
started
and
at
all.
A
A
Initially,
we
were
showing
the
comments
in
a
drawer
or
sidebar,
so
they
were
a
little
bit
constrained
in
the
space
that
you
could
use
to
see
and
reply
to
them
and
the
latest
design
concept
that
I
shared,
which
I
you
know
just
named
comments
tab.
I
think
mainly
because
of
that
is
just
having
a
view
here.
It's
using
a
tab
for
comments,
but
you
could
apply
this
to
all
of
the
other
concepts,
basically
just
having
a
view
that
you
can
access
through
a
sidebar
or
through
tabs
or
through
icons.
A
It
doesn't
matter,
but
you
have
this
view
here.
That
lists
the
comments
you
can
filter
them
and
you
have
a
big
area
to
reply
to
the
threads
and
you
can
treat
this
almost
like
a
inbox
inside
of
the
merge
request
that
you
can
then
triage
in
action
quickly
on
the
threads
without
having
to
find
them
scroll
to
them
and
you
know,
go
through
them
in
the
diffs
or
whatnot,
just
a
focus
view
to
deal
with
the
comments,
and
I
think
this
is
particularly
helpful
for
the
authors
or
people
that
are
authoring.
A
B
B
A
B
A
Yeah
yeah,
I
think
that
makes
a
lot
of
sense.
I
I'm
thinking
that
we
could
try
to
find
a
way
to
visualize
the
if
we
have
this.
So
there
are
two
ideas
here:
one
is
having
a
list
of
the
comments
and
then
the
detail
of
each
of
these
common
threads
and
an
alternative
is
to
have
the
threads
shown
stacked,
as
you
would
see
them
in,
for
example,
in
slack.
A
If
you
go
to
the
all
threads
or
just
threads
area,
you
just
see
the
threads
and
you
scroll
through
them,
but
you
don't
have
a
table
of
contents.
You
don't
have
a
navigation
to
jump
to
specific
thread.
You
have
to
just
keep
scrolling
through
them,
but
still,
I
think
in
in
this
case
we
can
try
to
have
a
better
visual
indication
and
grouping
of
threads
that
belong
to
a
review,
for
example,
or
even
better
filtering
here,
to
filter
by
a
specific
reviewer.
A
So
you
would
see
all
of
their
threads
and
even
here
in
the
activity
which
I
think
is
perhaps
the
closest
to
what
you
have
been
exploring,
is
to
have
a
entry
in
the
activity
for
the
review.
So
if
they've
approved
or
just
left
comments
or
requested
changes,
you
would
have
an
entry.
Maybe
you
can
have
the
comments
just
a
blurb
of
the
comments
below
this
one
or
you
know,
but
just
have
a
grouped
thing
that
you
can
then
click
to
see.
A
A
This
felt
like
a
big
positive
thing
of
having
something
like
this,
no
matter
how
it's
designed
like
these
two
different
ways,
but
having
a
view
that
is
big
just
for
the
comments
where
you're
focused
on
them,
then
the
dedicated
reports
checks
view
which
is
also
applicable
to
any
concept,
really
is
just
having
a
view
which
here
in
this
these
wireframes
I
fleshed
out
a
bit
more.
But
again
these
can
be
applied
to
any
of
the
other
design
concepts
having
a
list
of
the
reports.
A
Code,
quality,
sas,
continuous
scanning
code
coverage,
metrics
accessibility,
all
of
those-
and
you
can
then
see
the
details,
so
you
can
drill
down
into
each
one
of
these
reports,
and
this
area
would
be.
You
know
up
for
consideration
this.
In
this
case,
it
shows
a
low
fidelity
version
of
what
we
usually
see
for
in
the
security
vulnerability
dashboard,
but
this
can
be
whatever
the
the
report
wants.
A
Basically-
and
this
was
also
well
received
from
the
angle
of
not
only
having
a
dedicated
view
to
triage
and
action
on
these
findings
from
the
reports,
but
I
think
especially
because
it
relieves
the
merge
widgets
that
exist
today
in
the
overview
tab
from
displaying
so
much
information.
So
we
could
save
all
of
that
to
have
just
the
status,
a
basic
status
and
summary
of
the
merge
and
ci
checks
of
basically
the
health.
A
B
A
Yeah,
that's,
I
think,
yeah,
that's
it
the
other
one.
So
we
could
remove
the
pipelines
tab,
which
already
have
some
research
pointing
into
that.
It's
it's
not
that
useful
in
favor
of
having
the
status
in
the
overview.
Something
like
this.
I
don't
know
how
exactly
or
having
it
in
the
reports
check,
reports
or
checks
view
it
depends
on
how
we
call
it.
So
we
could
have
the
details
of.
A
The
pipeline
as
well
next
to
the
reports.
Basically,
so
you
could
drill
down
into
each
of
the
stages
and
jobs
if
you
want,
but
I
think
the
simplest
would
be
to
just
have
the
pipeline
summary
here
and
if
you
want
to
dig
into
the
pipeline,
you
go
into
the
pipeline
page
or
if
you
want
to
look
at
previous
pipelines,
for
this
merge
request,
there's
already
an
issue
open
to
create
a
filter
in
the
pipelines
list
to
only
show
you,
the
pipelines
related
to
a
specific
merge
request
or
a
specific
branch.
A
B
A
B
A
A
B
A
Cool
yeah,
filtering
and
sorting
everything.
People
were
happy
about
that
capability.
You
know
activity
comments,
files
reports,
you
know
on
each
of
the
views.
Once
we
once
we
get
to
a
certain
number
of
items
you
just
need
to
filter
and
sort,
or
else
it
will
be
very
difficult
to
make
sense
of
all
of
that
information.
B
I
was
just
thinking
also,
maybe
there's
some
activity
pieces.
We
can
look
at,
maybe
they're,
not
that
important
or
maybe
we
could
batch
or
combine
them
like
you
know,
you
see
so
many
like
added
label,
and
it's
just
you
know
it's
not
always
that
valuable
to
see
every
single
thing.
So
maybe
there
are
things
we
can
do
there.
B
Or
if,
like
someone
adds,
you
know,
rebases
and
adds
you
know,
50
commits
and
then
the
next
day
they
do
it
again
and
it
shows
up
as
two
they
take
up
quite
a
bit
of
space,
those
you
know
added
so
and
so
commits,
and
then
you
could
just
have
that
over
and
over
and
over
and
it
that
could
all
be
bashed
together.
Somehow.
A
That
makes
sense
to
me
well,
another
thing
that
is
only
applicable
to
the
non-tap
concepts
is
the
more
vertical
space
for
content
and
that
basically
means
that
these
concepts
that
have
the
tabs
at
the
top
like
this
one
or
this
one
so
yeah
just
having
tabs
they
take.
As
we
already
know,
it's
it's
what
we
have
today,
they
take
up
vertical
space
and
so
the
alternative
of
relying
on
a
sidebar
using
icons
or
expanded
with
with
an
accordion
or
this
one.
That
has
like
a
master
detail
view.
A
So,
relying
on
a
sidebar
versus
the
tabs,
at
the
top,
which
you
could
say
are
is
the
difference
between
the
vertical
tabs
or
horizontal
tabs.
So
in
a
way
there
they're
basically
tabs,
but
you
it's
how
you
place
them
it.
It's
the
trade-off
between.
You
know
vertical
and
horizontal
space
and
yeah.
It's
it's
something
worth
thinking
about,
and
maybe
testing.
B
A
That
that's
good
too,
do
you
think
from
from
those
conversations,
and
I
mean
I
think,
at
the
end
of
the
day-
and
I
was
talking
today
with
with
michael
leo
about
this
as
well
we're
constrained
by
the
the
header
here
at
the
top
and
the
the
sidebar
on
the
left
side,
and
this
is
what
we
have
to
work
with
today.
So
we
whatever
we
do.
A
B
Yeah,
I
think
so
the
last
last
design
I
saw
made
just
so
much
sense
and
I
think
when
they
look
at
the
tracking
of
the
top
nav,
the
most
commonly
clicked
thing
is
the
tanuki
icon
or
whatever
brings
you
to
the
home
button
and
then
like
user,
it's
not
very
much
used
compared
to
like
the
left
side
nav.
I
think
so
it's
there
just
because
it's
always
been
there.
B
A
A
A
A
It
will
be
very
difficult
to
not
have
a
sidebar
somewhere
right
so
with
the
concepts
that
don't
have
tabs.
We
at
least
leverage
those
sidebars
that
we
will
kind
of
be
forced
to
have
somewhere
to
yeah
to
serve
as
navigation
as
well,
so
so
yeah
anyway.
It's
just
something
to
keep
in
mind.
I
think
it's
to
me
in
my
my
minds,
other
than
all
of
the
other
pros
and
cons
it's
more
tabs
versus
sidebar.
A
B
Yeah
yeah,
I
agree,
and
I
just
think
it's
interesting
that
this
latest
one
that
you
posted
it's
it's
got
the
tabs
and
everyone
loved
it
so
much
and
I
loved
it
too,
wow
tabs,
it's
so
innovative,
I'm
just
kidding
it.
Is
it's
really
good.
I
really
did
like
this
last
one.
I
think
it's
logical.
It's
not
changed
for
change
sake,
it's
like
it's
taking
the
tab
concept
and
it's
it's
making
it
way
more
powerful
and
it
makes
much
more
sense
the
way
that
this
is
laid
out
and
we
still
have
the
sidebar.
A
Yeah
yeah
yeah.
I
know
I
know
yeah
the
that's.
Okay,
let's
see,
okay,
so
moving
on
least
confident
pros.
So
I
think
they're
pros,
but
still
might
be
something
we
need
to
test
further
and
I
don't
think
they're
a
blocker.
We
can
still
test
any
concepts,
but
maybe
something
we
need
to
look
into
later.
If
we
want
which
one
is
to
try
to
make
better
use
of
screen,
space
is
moving
sidebars.
So
one
example
seen
here
is.
A
You
know,
keep
ourselves
open
to
these
ideas
and
try
to
see
what
else
we
can
do
to
reorder
content.
I
think
another
example
is:
is
this
one
here
in
comments
where
you
know
you
can
look
at
the
comments,
the
content
of
replies
and
so
on
on
one
side
and
the
diff
can
be
sticky
and
so
that
you
can
always
maintain
context,
and
this
is
making
better
use
of
the
screen
state.
A
If
you
have
a
smaller
screen,
we
could
show,
as
today
you
know
the
diff
at
the
top
and
the
comments
below
the
div
so
yeah.
I
think
it's
just
this
better
approach
to
screen
real
estate
in
general
file
tree
is
more
useful
than
a
drop
down
to
jump
to
files.
You
commented
on
that.
I
think
we're
aware
of
that.
What
that
is
yeah.
I
think
I'm
I'm
confident
on
it.
A
A
B
So
like
it's
just
on
the
left,
you
basically
have
a
list
of
all
the
comments,
so
you
don't
have
to
scroll
through
them.
You
know
what
I
mean,
so
I
don't
necessarily
know
if
it's
important
to
be
like
okay,
I
want
to
see
the
thread,
but
also
the
diff
and
then
scroll
through
the
diffs,
but
also
maintain
that
thread.
I'm.
A
A
Yeah
yeah,
I
agree.
I
agree,
then
I
think
a
positive
thing
from
the
accordion
and
icon
sidebar
or
just
I
would
say
you
know
the
sidebar.
Only
concept
is
that
it's,
I
think,
more
similar
to
ides
and
those
workspace
tools
where
you
rely
mainly
on
on
those
sidebars.
We
see
this
in,
for
example,
vs
code,
and
this
allows
you
to
toggle
the
information
that
is
shown
here
and
the
same
thing
with
the
accordion
expanding
and
collapsing
sections
of
content
yeah.
A
A
So
in
this
one,
when
you
go
into
the
overview,
you
have
these
navigation
sections,
but
the
changes
and
the
the
tree
is
immediately
visible
below
and
appears
by
default,
which
is
something
that
we
can
experiment
with
and
validate.
If
we
try
to
prototype
a
one
of
these
designs
that
relies
on
a
sidebar
for
everything
right
to
navigation
and
so
on,
I
think
if
we
have
the
tabs,
it
will
be
very
difficult
to
have
an
argument
to
always
show
changed
files
with
with
a
tab
view.
A
You
know,
for
example,
being
here
in
the
overview
and
having
the
file
tree
here,
but
then
you
click
and
it
goes
to
the
changes
and
it
might
be
a
bit
confusing
what
else
biggest
cons,
which
is,
I
think
something
that
we
already
discussed
because
of
the
navigation
and
those
constraints.
Initially,
I
was
thinking
hey.
Let's
just
you
go
into
a
merge
request.
We
auto
collapse.
A
The
navigation,
sidebar
and
people
were
vocal
about
it
that
they
kind
of
hated
that
automatic
behavior,
and
it
was
just
me,
I
think,
frustrated
by
the
amount
of
chrome
that
we
usually
have
around
the
contents
in
gitlab
and
that
all
of
our
features
have
to
be
designed
inside
of
a
fairly
small
space
because
of
all
the
navigation
that
we
have
around.
But
anyway,
I
I
think
we
have
to
embrace
these
constraints
that
we
yeah
the
navigation.
Sidebar
has
to
be
there
basically.
A
A
So
you
could
click
here
to
change
the
content,
but
these
ones
below
would
only
show
a
different
sidebar
over
yeah.
It's
it's
sophisticated.
I
I
think
it's
not
too
critical
way
to
put
it
and
and
yeah
it's
it
can
be
confusing.
I
think
if
you
know
how
it
works,
it
can
be
powerful,
but
you
know
it's
as
in
the
first
tries
you,
you
have
to
wrap
your
head
around
it,
so
that
was
a
big
con
and
tap
concepts.
We
already
talked
about
this.
A
When
we
have
tabs,
we
have
less
vertical
space
for
content.
The
single
view
performance
concerns
in
a
nutshell
and
yeah,
and
then
we
have
some
open
questions,
one
that
you've
been
battling
for
some
time
now.
Do
we
have
a
sidebar
only
on
the
overview
or
not
for
the
details
or
the
metadata
and
marcel
he
had
this
concept
of
okay.
A
What
if
we
have
some
or
all
of
the
metadata
sticky
and
then
like
when
you
well,
not
sticky,
but
when
you
scroll
it
would
hide,
and
you
would
click
here
to
show
it
again
yeah,
I'm
concerned
about
vertical
space
again,
although
it's
nice
that
it's
compact
yeah,
I'm
concerned
about
it,
I'm
wondering
like
when
I
was
looking
at
this
idea.
I
was
thinking
that
in
one
of
the
design,
this
is
just
an
example.
A
It
can
be
applied
to
the
some
other
concepts,
but
in
the
designs
that
we
have
tabs
if
we
were
to
use
something
like
this,
an
icon
or
a
button
with
a
label
that
says
details
to
open
the
sidebar.
If
we
can
also
have
some
avatars
here
for
the
authors
and
reviewers
when
you
close
the
details,
so
that
would
be.
B
A
B
I
think
a
couple
of
things,
one,
the
the
option
that
marcel
came
up
with
he
he
mentioned
it
like
before
the
or
maybe
during
the
beautifying
ui
thing.
We
were
trying
to
figure
out
where
we
could
put
that
metadata
and
he
was
playing
around
with
that
header
too.
The
problem
is
like
all
of
a
sudden
you've
taken
these
tiny
pieces
of
metadata
that
works
so
well
in
a
sidebar
because
they're
small
and
they
belong
in
a
nice
column.
B
When
you
put
them
vertically,
they
start
to
wrap
it's
just
like
our
project
page
like
depend
now
we
need
to
account
for
so
many
different
screen
widths
and,
if
they're,
let's
say
they're
like
100
labels,
because
that's
what
we
do
with
gitlab,
where
how
do
you
show
that?
Is
it
like
a
drop
down?
Does
it
does
that
expand
again,
so
you've
got
like
expand
and
expand,
and
all
that
kind
of
stuff
I
do
like
so
in
one
of
the
concepts
or
even
maybe
this
one.
B
I
I
guess
I
didn't
really
consider
when
I
removed
it
a
few
milestones
ago.
The
thing
I
don't
like
about
it
is
that
it
does
clutter
the
page
up
and
it
all
of
a
sudden.
We
have
to
deal
with
again
all
of
the
different
screen
widths
and
all
the
different
configurations
that
people
might
have,
but
if
we
opened
it
on
those
different
tabs,
but
it
was
a
true
overlay.
It's
just
like
it's
just
for
informational
purposes.
It
doesn't
stay
open,
it
doesn't
shift
the
content,
then
maybe
it's
not
so
bad.
B
Maybe
if
you
are
like
on
the
changes-
and
you
have
that
sticky,
you
know
icon
somewhere
in
the
sticky
header.
That's
like
hey,
who
is
this?
What's
the
label
again
click
it?
Oh
yeah
that
sounds
okay
to
me.
There's
something
about
like
the
current
sidebar
experience,
where,
like
it,
pushes
the
content
most
of
the
content
kind
of
breaks,
depending
on
how.
A
A
B
A
So
like
like,
we
have
the
drawer
when,
when
you
click
well,
this
is
not
a
good
example,
because
there
are
very
few
columns.
But
in
this
case
I
think,
let
me
see
okay,
so
we
have
more
columns
and
I
think
if
I
click
on
one
yeah
it
just
it
overlays
the
content,
this
drawer.
Well,
this
is
moving,
but
you
know
what
I
mean:
you
click
here
and
it
overlays
the
content.
It
does
not
shift
it
to
the
right.
I
think.
B
Or
maybe
it
doesn't
need
to
be
a
sidebar
if
we're
doing
something
like
that,
maybe
I
can't
think
of
an
example.
I
guess,
but
if
we
need
to
show
metadata
just
because
someone
can't
remember
where
they
are
and
they
don't
want
to
leave
where
they
are,
they
don't
want
to
leave
the
current
context.
Maybe
there
is
a
way
we
can
show
that
without
pushing
the
content
and
having
to
design
and
maintain
all
of
these
different,
it's
like
the
maintenance.
I
don't
want
to
build
for
you
know
making
it
easy
to
develop.
A
A
Yeah
yeah,
I
I
completely
understand
yeah.
I
think
that
this
is
mainly
a
problem
in
the
concepts
that
have
the
tabs,
because
we
may
we
may
be
able,
like
this
one
and
this
one,
the
metadata.
The
idea
would
be
to
show
it
in
the
overview
so
that
that
completely
negates
the
problem.
It's
like.
Okay,
if
you
want
to
see
the
metadata
go
to
the
overview,
but
there's
another
one.
A
A
I
agree,
but
I
I
think
that
we
can
still
make
progress
here
and
try
to
prototype
and
test
something,
even
if
we
don't
have
an
answer
today
to
whether
we
show
it
always
on
all
tabs
or
all
views
or
just
on
some
of
them
or
we
toggle
it.
I
don't
think
it.
It
affects.
Of
course
the
merge
request
experience,
but
I
don't
think
it
affects
the
navigation.
B
A
A
B
B
A
A
Yeah,
I
think
so
the
the
contents
like
what
we
are
showing
in
in
in
this
concept
of
the
comments
tab,
what
we're
showing
inside
of
each
tab
that
can
be
replicated
to
the
sidebar
concept.
So,
basically,
what
we're
deciding
is.
Do
we
want
tabs
to
navigate
between
views
or
do
we
want
a
sidebar
to
navigate
between
views
which
we
can
also
leverage
to
show?
You
know
other
sidebar
content
like
the
file
tree
or
metadata,
or
the
list
of
comments
or
the
list
of
reports
and
the
report
view.
So
we
can.
A
A
It
is
different,
like
it's
not
as
much
vertical
tabs
as
this
concept
here
with
the
icons.
This
is
definitely
more
vertical
tabs.
This
one
is
a
mix
where
you
expand
and
collapse
sections,
and
you
also
change
the
content
here,
so
it's
both
tabs
and
accordion
all
in
one,
and
it
has
those
problems
that
we
mentioned
you
know
of
like
this
is
very,
can
be
a
very
constrained
view.
A
A
Okay,
so
let's
imagine
that
these
are
actually
tabs
and
let
me
just
remove
this-
and
here
you
click
to
go
to
the
overview
and
we
show
the
overview
content
and
the
metadata
sidebar.
You
click
here
to
go
to
the
changes,
tab
and
we
show
the
file
tree
and
the
change
files
click
here
to
go
to
the
reports
tab
and
we
show
the
list
of
reports
and
reports
detail
and
you
click
here
to
go
to
the
comments
tab.
So
this
can
also
function
as
a
navigation.