►
From YouTube: CI/CD UX Team Design Review | 18 February 2020
Description
- Iain Camacho | 00:07
Update the design for the container registry
B
I
am
really
excited
because
we're
going
to
share
the
container
registry
UI
that
I've
been
working
on
for
a
while
and
have
really
excited
to
get
some
designer
feedback.
I've
gotten
feedback
from
engineers,
I've
gotten
feedback
from
other
parts
of
the
company
and
I
realized
I,
don't
know
if
another
designers
have
looked
at
them,
so
I'm
very
excited
to
to
share
it
with
you.
B
One
of
the
big
issues
that
exists
with
images
is
many.
Many
of
them
are
created
using
CIA
and
the
pipeline's
means
there's
a
large
quantity
of
things
to
manage,
but
very
few
of
them
are
really
necessary
irrelevant.
So
it
kind
of
created
an
interesting
experience
we
have
to
work
through
the
current
UI
is
a
little
bit
bare-bones.
So
if
you
go
to
the
container
registry,
you
get
dropped
on
the
page
that
just
lists
out
the
different
image
repositories
and
then
you
can
expand
them
out
to
see
the
individual
tags.
B
So
a
tag
is
kind
of
like
a
version
of
that
image
and
the
information
we're
providing
is
pretty
minimal.
You
can't
really
sort
it.
You
can't
really
filter
it.
There's
not
a
way
to
engage
with
it,
but
you
can
get
the
whole
address,
which
is
the
most
important
thing
that
most
people
this
little
copy
thing.
One
of
the
technical
challenges
to
keep
in
mind
is
that
the
container
registry
is
not
part
of
the
rail
system,
so
it's
a
little
bit
slower
at
times.
B
So
if
you
have-
and
some
people
do
have
hundreds
and
hundreds
of
tags,
this
spinning
wheel
can
take
so
long
that
the
UI
is
now
not
usable,
because
it's
only
had
this
many
and
it
took
that.
Well
and
again,
it's
all
built
up,
there's
no
way
to
search
it's
no
way
to
filter.
It's
kind
of
difficult
when
you
start
getting
into
six
pages
of
tags
and
you
needed
to
find
a
specific
one.
B
Where
does
this
all
came
from?
We
did
a
bunch
of
research.
At
the
same
time,
we
did
the
package
research,
so
we
understood
what
data
they
needed.
We
did
qualitative
interviews
to
figure
out
why
they
needed
it.
We
did
some
awesome
brainstorming
throughout
the
whole
team,
using
think
big
conversations,
as
well
as
just
kind
of
an
async
brainstorm
where
we
had
all
the
engineers
come
together
and
say:
here's
the
problem,
here's
the
data
points.
B
What
would
you
do,
which
was
pretty
fun
and
exciting,
and
so
we
came
up
with
two
new
designs:
we
try
to
keep
the
quick
action
available
that
delete
display
more
of
the
robust
data
about
the
image
itself,
as
well
as
where
the
image
came
from,
which
is
99%
of
the
time.
The
question
that
our
users
are
trying
to
answer
when
they
go
to
the
UI
is:
where
did
it
come
from
and
what
built
it?
B
Now
that
the
container
registry
and
the
golang
engineers
that
we
have
are,
you
know
fully
ruling
forward
and
ready
to
take
on
the
next
step,
I'm
going
to
switch
to
the
design
and
walk
through
it
a
little
bit
more
fluidly,
but
there's
a
couple
of
things:
I'm
really
looking
for
one.
Does
the
basic
structure
make
sense?
B
There's
a
point
where
there's
details
of
a
specific
tag
and
they're
built
in
an
accordion,
because
there's
not
too
many
pieces
of
information
related
to
it.
I
would
love
to
know
after
we
go
through
it.
How
many
is
enough
two
pieces
of
data
where
it
should
get
an
independent
page,
I'll
walk
through
that?
More
specifically,
when
we
get
there
we're
gonna.
Do
solution,
validation
after
we
do
the
review,
so
if
there's
anything
that
as
you're
looking
through
it
that
you
would
call
out
that
you
would
want
to
ask
a
user.
B
That
would
be
something
that's
really
important,
and
the
last
question
is
shockingly
one
of
the
more
important
ones.
The
container
registry
is
a
set
it
and
forget
it
feature,
so
it
should
just
work
and
those
kind
of
features
require
a
lot
of
trust,
and
one
of
the
responses
we
got
during
research
is
that
the
current
UI
doesn't
look
like
the
rest
of
gitlab.
It
doesn't
feel
get
lab'.
Almost
every
user
said
that
exact
phrase.
So
the
question
is
with
this
new
UI:
does
it
look
like
the
rest
of
gitlab?
A
B
B
B
We
added
a
title
section
and
a
quick
actions
studying.
So
we
provide
a
little
bit
of
context
about
the
registry
in
total,
so
how
many
different
images
there
are,
how
many
different
tags
in
total
are
there,
as
well
as
the
overall
space
of
the
registry.
On
the
last
part,
the
space
is
really
important,
because
there
is
quotas
and
there's
maximums
of
how
big
that
can
get
and
there
isn't
a
good
way
to
clean
it
up.
So
that
number
is
it's
pretty
important.
B
B
The
number
one
reason
why
our
users
are
coming
to
the
UI
is
to
check
if
an
image
was
created
recently
as
they
expected
and
so
I
created
this
moment.
That
is
the
three
most
recent
tags
that
have
been
published
in
the
registry.
Also,
it
shows
you.
This
is
the
name
of
the
tag.
This
is
the
image
it
belongs
to
and
then
a
little
bit
of
information,
as
well
as
the
branch
and
commit
information
which
is
usually
like
when
you
have
a
merge
request,
it
merges
in
it
fires
off
a
pipeline.
B
The
pipeline
does
this
and
bills
the
package
and
adds
it.
This
commit
Shah
tends
to
be
the
most
important
information
related
to
a
specific
tag,
because
that's
what
you
would
pay
somewhere
else
to
use
it
or
to
find
like
what
what
it
came
from
and
then
we
have
that
delete
a
specific
tag
underneath
the
most
published
only
published
tags.
We
have
the
image
repositories,
so
this
is
one
single
image.
B
B
This
is
one
of
the
things
that's
changing
is
when
you
click
on
one
of
these
individual
repositories.
Instead
of
it
expanding
and
showing
a
table
of
its
tags,
we
gave
it
its
own
detail,
page
which
looks
like
this.
If
you
notice
it
has
a
lot
of
the
same
structures,
that's
the
most
recent
tags
above
about
the
commit
and
branch
information,
as
well
as
the
tag
name.
We
provided
a
size
as
well
as
docker
has
docker
labels,
which
are
always
key
value
pairs.
So
we
kind
of
added
this
key
and
value
set
to
the
labels.
B
Not
everyone
uses
them.
That's
why
it's
not
given
a
very
prominent
space,
but
the
ones
that
use
them
really
want
to
see
them
quickly.
If
you
wanted
more
information
about
one
of
these
specific
tags,
knowing
that
for
most
of
our
users,
they
either
want
to
copy
this,
or
they
want
to
copy
this.
There's
the
ability
to
expand-
and
this
is
the
I-
pulled
this
UI
from
the
commit
UI.
Where,
if
you
get
the
commit
information,
you
can
hit
that
button,
it
expands
and
shows
you
the
commit
message.
B
If
you
remember
at
the
beginning,
I
mentioned,
you
know
how
many
of
these
pieces
of
information
can
we
get
to
before
it
needs
its
own
detail
page.
This
is
what
I
was
referring
to
eventually
we'll
get
to
the
point
that
there's
five
or
six
or
seven
pieces
of
data
in
this
list,
and
so
I'd
love
from
the
UX
perspective.
How
many
is
too
many
for
this
and
should
be
moved
into
its
own
page?
B
C
I
hate
to
go
here
first,
because
I'm
afraid
it'll
devolve
into
like
a
conversation
about
this,
but
my
first
like
not
getting
anything
that
I,
noticed
I,
think
you're
correct
in
using
outlined
buttons
there,
but
we
break
the
rule
everywhere
else
and
get
out
I
always
see
those
solid
with
the
lead.
Icons
are
always
solid
red
with
white
trash
cans
on
them.
C
B
D
I
think
like
when
I
saw
it
first
saw
the
you
I
was
like
whoa
all
this
little
UI
elements,
but
that's
what
pajamas
suggests
right.
That's
what
we
we
have
to
do.
Those
are
the
components
so
I
feel
like.
Is
this
really
the
best
way?
We
can
apply
these
components
or
what
can
can
change?
For
example,
you
use
there.
What
is
this?
D
This
is
the
I
think
emerge
request,
but
it's
in
bold
right,
I
think
most
places
is
just
a
regular
way,
so
I
think
maybe
those
no
small
polishes
might
help
to
make
you
look
a
bit
more
it
lab',
but
then
again
we
have
to
pay
attention
because
a
lot
of
what
we
have
in
the
product
right
now
it's
legacy
and
they
shouldn't
look
the
way
it
does.
So
it's
a
bit
I.
B
Totally
understand
agree
with
that:
I
wanted
to
find
a
good
combination
of
like
making
sure
we
build
something
based
on
what
we
should
be
building
towards,
knowing
that
it
needs
to
feel
familiar.
It
was
kind
of
tricky
because
this
is
actually
a
UI
elsewhere
in
the
product.
That's
where
I
pulled
it
from
so
it's
the
styling
that
already
exists,
then
I
was
hoping
you
would
be
familiar
because
it
is
an
icon
and
not
really
the
most
straightforward
icon
to
represent
a
commit
in
a
branch.
B
D
B
D
B
Yes,
that
is
exactly
what
I
was
thinking
up
on.
You
know,
I'm
going
to
make
a
note
changing
it
over
one
of
the
nice
things
is
that
this
is
a
lot
of
changes,
and
this
is
very
not
NBC
in
terms
of
the
design,
so
each
one
of
these
elements
will
go
through
its
own
little
design
process.
The
next
stage
is
for
us
to
go
to
our
users
and
say
we're
gonna,
add
a
bunch
of
this
stuff,
and
we
think
it's
gonna
look
mostly
like
this.
Does
it
make
sense?
E
B
E
E
B
That's
a
good
call,
I
think
I'm
gonna
make
it
I
will
make
a
note,
not
gonna,
think
about
it,
and
when
I
do
user
testing
I'll
see
if
they
I'll
ask
users
like
if
you
were
to
click
on
this,
what
interaction
would
you
expect
and
if
they
constantly
say
like
it's
a
binary
and
it
should
switch,
then
we'll
know
and
if
they
think
yeah
I'll
be
acts
like
a
label
that
might
be
yes,
cuz.
It's
true!
D
Ian
also
have
a
question
unrelated
to
you
why
you
mentioned
tags
a
couple
of
times
and
I
just
wanted
to
understand.
If
the
tag
that
you're
showing
there
are
the
same
tags
as
in
release
tags
and
if
not
yeah,
can
that
confuse
users?
So
that
could
be
a
good
thing
to
to
check
during
your
research.
Then
your
interviews,
yeah.
We
are
using
tags
in
different
ways
across
the
product.
You
have
kind
of
labels
tags
and
these
met.
Yes,.
B
There
are
a
couple
of
things
we
need
to
check.
For
example,
we
say
image
repositories
here
and
that's
technically
correct
and
it's
the
way
interacting
with
the
API
works
and
make
sense
in
the
verbage,
but
no
user
actually
refers
to
them.
As
that
and
part
of
the
challenge
is
that
a
container
registry
has
done
something
interesting
where,
instead
of
like
packages,
you
have
a
package
and
then
you
have
all
the
versions
of
that
package.
B
Images
should
work
the
same
way,
but
they
think
about
them
completely
differently
and
that's
why
I
like
the
image
repository
contains
many
tags
instead
of
containing
many
images,
it's
and
so
we're
gonna
test
that
with
users,
because
this
is
technically
correct,
but
if
it
doesn't
make
sense
to
them
and
doesn't
resonate
with
them,
then
we're
gonna
have
to
figure
something
else
out.
Yeah.
D
F
B
E
B
That
would
be
perfect,
because
I
would
imagine
in
the
near
future,
there's
a
couple
of
icons
that
will
want
like
a
tag
that
actually
matches
container
tags
and
isn't
used
as
a
reference
to
something
else
where
the
retention
policy
is
another
one,
where
I'm
using
the
icons
for
like
checked
and
canceled,
and
it
it,
the
expiration
policy,
doesn't
have
its
own
on
an
off
icon.
Another
example.
C
Feel
like
we
always
got
to
do
negative
things
on
this.
Let
me
point
out
as
positive.
I
love,
love,
love,
love,
love
the
fact
that
this
is
not
like
tabular
data
with
columns,
I
hate
that
pattern
gitlab.
Thank
you.
Thank
you.
Thank
you
for
losing
a
list
type
pattern
to
make
a
much
better
way
to
organize
information.
B
C
Yeah
he's
just
there,
you
know
we've
short
side
ourselves
on
a
lot
of
tables
across
get
lab
wares.
You
can
they're
just
bursting
at
the
scene,
everything's
truncated,
like
there
is
it
there's
so
many
tables
where
the
conversation
is.
If
we
have
to
add
one
more
piece
of
data
to
this,
it
has
to
be
completely
redesigned.
B
B
So
the
reason
we're
not
seeing
tabs
up
here
is
because
this
is
a
collection
of
tags,
and
this
is
a
collection
of
images
and
so
I
thought
it
broke
the
mental
model
because
we
use
tags
to
sort
or
kind
of
filter
the
same
types
of
things
based
on
different
criteria.
So
here
a
verified
tag
is
incredibly
important.
It
means
someone
actually
went
in
and
said:
I
am
you
know
a
maintainer.
This
is
the
image
to
use,
and
so
that's
why
I
kind
of
got
a
tab.
B
Navigation
I've
struggled
with
that
because
on
issues
ray
we
have
the
designs
have
in
the
discussion
tab
and
you
could
argue
that
they're
the
same
categorical
thing,
but
they
kind
of
not
so
I,
just
kind
of
steered
away
from
mixing
the
two
of
them
in
that
tab.
It
was
a
rambley
way
of
answering
your
question.
Yeah.
C
D
Personally,
that
this
was
a
completely
different
proposal
for
the
same
view.
Now
that
you
mention,
am
I
oh
yes,
wait?
This
is
something
completely
different.
I
was
confused
and
that's
why
I
kind
of
skip
my
first
point
where,
in
this
view,
you
have
two
columns
in
the
in
the
ListView
right
so
for
most
recently
published
tags.
You
have
this
info
on
the
right
and
below
you
don't
have
so.
D
My
first
comment
that
was
like
yeah
looks
a
bit
unbalanced,
but
then
I
thought
oh,
no
he's
making
any
proposal
with
the
tabs
and
that's
solving
having
two
different
lists
on
the
UI.
So
to
me
it's
a
bit
weird
I
would
have
you
personally
expect
to
see
that
there,
because
it's
two
different
contents
yeah
and
a
page
or
something
like
a
bigger
header
or
you
can
say
image
repositories,
and
you
know
it's
really
defined,
but
just
from
from
from
a
perspective,
oh
yeah,
that's
how
I'm
used
to
the
product
right
now
does.
B
B
Pagination
is
a
whole
beast
in
and
of
itself,
because
of
the
way
the
container
registry
is
built
compared
to
the
way
we
want
to
display
it
don't
line
up.
So
that's
a
can
of
worms,
but
yes,
technically
it
should
be
paginate
'add.
One
of
the
reasons,
for
example,
why
we
separated
the
image
repositories
and
gave
tags
their
own
UI
is
so
you
didn't
end
up
with
pagination
inside
a
pagination,
which
is
why
technically
happens
in
our
UI
right
now,
right,
just
not
great.
F
A
Actually
wanna
just
other
might
interest,
come
back
to
the
first
comment
that
you
might
get
about.
The
trash
icon,
red
white
versus
white
red
curious,
like
were
like,
is
it
feel
like
just
for
my
understanding,
is
still
outdated
and
supposed
to
be
updated
in
their
pajamas
or
like
purification.
Where
did
you
take
this
one,
and
why
are
we
not
in
sync
there?
Yes,.
B
B
C
There's
argument
rises
and
falls
on
your
interpretation
of
this
text
and
I
haven't
memorized
because
I
live
this
this
battle
before
right,
so
you
should
only
have
one
primary
button
for
a
given
context.
Now
the
question
is:
is
this
row
having
a
delete
button?
That's
primary!
Is
that
its
own
context
or
since
there
is
another
primary
button
on
this
page?
Is
it
not
in
that
context,
so
I
think
that's
where
this
this
really
rises
and
falls
is
on
what
you
consider
that
context.
I.
D
B
B
D
And
I
just
checked
on
pyjamas,
and
it
says
that
yes,
the
secondary
button
should
be
used
in
most
cases,
I
think
not
maybe
not
on
a
modal,
for
example,
when
it's
really
the
primary
action
but
I.
Just
in
here
the
pajamas
guidelines
saying
that
the
secondary
button
is
the
correct
choice,
as
the
user
most
likely
not
be
motivated
to
delete
the
content,
so
yeah
legacy.
A
D
We
don't
have
read
it's
very
generic
and
it
says
that
yeah
the
danger
button
is
used
for
deleting
or
things
that
cannot
be
undone,
but
a
secondary
category
is
the
correct
choice.
They
say
often
it's
the
correct
choice,
so
it's
only
rotation
will
be
nice
to
really
improve
on
on
this
guy,
because,
for
example,
if
we
have
a
model
right,
I
think
in
this
video,
it's
fine,
but
when
you
have
the
only
delete
button
on
the
page,
does
that
change
the
context?
A
D
C
E
A
My
biggest
worry
here
is,
let
you
know
like
I
feel
we
have
to
agree
on
this
like
document
it
like
a
fish
so
weed,
we
are
not
puzzled
and
no
other
recording
designer
is
being
like
pauses
and
thrown
under
the
bus
with
this
type
of
question
like
this
would
be
super
clear,
like
what
type
of
bond
and
we
have
to
use.
This
is
why
almost
asking
yeah.
C
E
It
almost
makes
me
think
that
I
I
don't
get
why
it's
so,
even
even
if
it's
secondary
it
still
feels
too
inviting
my
open.
You
know
sometimes
I
have
seen
patterns
where
you
just
actually
entering
to
a
delete
mode.
So
I
wonder
why
we
never
thought
about
that.
You
know
like
they're
like
oh
it's
time
to
you,
lead
you're
going
to
be
lead
and
they
even
start
deleting
things.
D
Because
we
also
have
some
patterns
not
sure
if
it's
something
that
it's
a
recommendation,
but
we
have
more
actions
right
and
then
that's
where
the
user
can
copy
delete
or
whatever.
Perhaps
that's
something
it
would
be
best
to
hide.
That's
because
you
have
the
leads
to
make
the
whole
thing
and
you
can
delete
them
individually,
which
is
even
more
secondary
in
a
way.
Then
right.
D
D
B
I've
gotten
that
that
same
feedback
before
so
I
think
that's
a
really
good
suggestion
of
just
giving
this
a
bit
more
States
to
breathe
inside,
because
yeah
it
is
that
that
space
is
pretty
small.
My
original
concern
is:
if
a
lot
of
people
have
you
eyes
say
just
kind
of
have
this,
and
so
I
was
wondering
if,
when
it
got
that
empty,
it's
the
white
space
would
make
it
look
even
more
empty.
But
so
in
that
case
we
have
two
different
users,
and
so
we
had
to
pick
one.
B
B
D
To
be
the
same,
I
think
the
the
biggest
challenge
here
is
because
most
some
of
those
UI
components
are
not
updating.
Pajamas
yesterday,
let's
say
don't
exist
yet,
and
they
might
look
for
in
two
people.
So
let's
say
that
yeah
you
go
ahead
and
implement
it,
as
is
with
the
current
state
of
the
components.
It
might
look
different
and
it
might
look
more
get
lab'
just
because
yeah.
A
D
A
D
D
B
Sorry,
the
different
image
repository.
So
we
got
that
little
piece
of
feedback,
and
then,
on
top
of
that
there
was
the
realization
that,
like
if
an
image
repository
has
any
verified
tags,
it
needs
to
be
really
easy
to
see
that,
because
that
greatly
increases
the
likelihood
that
that's
the
image
you
want
to
be
working
with,
and
then
the
expiration
policy
is
like
currently
gitlab.
It's
an
outrageous
amount
of
space
is
consumed
by
the
images
in
the
container
registry.
B
So
knowing
if
an
image
repository
has
this
expiration
on
or
off,
is
also
really
important
like
it's,
this
admin,
so
I
was
mostly
just
highlighting
the
two
most
important
pieces
of
data,
I'm,
not
sure
if
maybe
I
just
want
to
leave
the
color
for
the
verified
tags
and
leave
these
as
gray.
It
does
feel
a
little
over
colored
at
times
and
then
I
come
back
and
look
at
it
and
it
looks
really
boring
so
I'm
not
I
haven't
been
able
to
land
on
the
right
amount
of
color
ya.
D
Understand
because
when
I
look
at
these
interfaces
or
thirsty
and
naked
groups
like
the
ListView
for
groups
where
we
also
see
some
of
these
icons
and
yeah,
just
sort
of
listen,
DUI
they're,
not
they're,
not
color,
so
I
just
wanted
to
understand,
but
it
definitely
catches
your
attention.
Like
first
thing,
I,
look
at
it's
the
tags,
that's
where
I'm
going
for.
B
Yeah
I'll
take
a
look
at
that
again
and
maybe
get
feedback
directly
from
users
like.
Is
it
distracting?
The
color
is
like
it's
not
actually
helpful.
Where
is
it
and
you
could
turn
into
something
where
it's
the
expectation
that
all
of
these
are
enabled,
and
so
it's
just
a
red
if
it's
abnormal
that
kind
of
thing.
D
C
B
So
if
you
have
a
specific
tag,
organizations
that
are
very
large
and
have
like
a
DevOps
team
would
like
the
ability
for
a
DevOps
manager
to
come
in
and
identify
and
say
this
specific
tag
has
been
verified.
I
a
person
say
this
is
the
one
to
use,
so
the
star
is
just
the
icon
I'm,
using
to
kind
of
just
share
that
idea.
B
This
is
one
of
those
that
has
to
go
through
its
own
design
process
on
its
own,
but
that's
what
the
original
idea
of
the
star
was
was
that
it's
kind
of
the
same
as
like
favoriting
it
or
adding
it
to
a
list.
It
should
be
that
high
light
of
an
interaction,
but
it's
kind
of
important
for
those
bigger
teams.
C
To
do
well
that
bad
I
think
it
is
a
good
icon
in
that
sense,
but
the
previous
page
words
are
saw
highlights
my
slight
hesitation
with
it
is
that
in
a
get
world
or
so
in
github
and
get
lab,
but
stars
have
a
specific
meaning
here,
it-it's
like
how
popular
is
this
thing
right?
That's
the
github
star
thing
so
slight
hesitation
that,
like
you
know
there
might
be
some
confusion
there,
that
this
is
indicating
its
popularity
but
you're
it
kind
of
is
right.