►
From YouTube: Jenkins UX SIG Meeting - 5 August 2020
Description
This was a relatively short meeting due to the holiday period. Joe Brueggen showed his new designs for the first time start up screen and the log in page. Tim Jacomb gave a quick update on the work he had done to create a Backstage plugin as well as a short update on the tables to div transition.
A
Sounds
good,
so
I
think
today
it
looks
like
we
have
a
pretty
lean
meeting.
Thank
you.
Everybody
for
hopping
on
good
mix
of
attendees
today,
awesome
so
pretty
pretty
lean
meeting,
as
I
mentioned,
I
think
everyone
on
here
has
already
been
introduced
in
the
call,
but
I
don't
see
everyone's
avatar.
So
please
interrupt
me.
If
that's
not
the
case
does.
A
Awesome
does
anyone
have
anything
they'd
like
to
put
on
the
agenda
before
we
dig
in,
and
you
can
do
that
throughout
the
call
too.
Of
course,
all
right.
So
on
my
end
here
I
have
things
a
little
bit
more
low
fidelity
this
week
than
than
usual.
So
apologies
for
that
I
don't
have
a
design
deck
prepared
per
se,
but
what
I
do
have
is
a
couple
of
bucks
to
kind
of
walk
through
with
you
all
just
in
in
screenshot
form
and
talk
about
a
couple
of
things
that
are
going
on.
A
So
last
sig
meeting
we
took
a
look
at
this
screen
that
we
have
on
here.
What
this
is
is
an
attempt
to
kind
of
reconcile
the
the
layout
and
improve
the
usability
of
the
welcome
screen
within
jenkins.
You
know:
welcome
screen
is
not
a
super
high
impact
screen.
Arguably
not
a
lot
of
people
see
it
and
those
who
do
or
are
typically
not
seeing
it
very
often
and
then
once
they
do
see
it
and
get
through
it
or
move
past
it.
A
They
don't
need
to
to
be
reminded
of
all
of
these
different
options
so
much
in
the
future.
Typically,
I
had
some
really
good
feedback
from
this
group
in
the
last
six
session,
and
also
from
some
other
developers
throughout
the
community
that
have
reached
out
to
you
since
then,
and
have
an
update
on
this
layout.
So
this
is
still
very
much
a
work
in
progress,
but
a
couple
of
changes
to
share
and,
of
course
feedback
is
welcome
here.
A
So
this
is
where
we
were
before,
and
here's
how
it
has
evolved
since
then,
so
I'm
going
to
be
toggling
back
and
forth
a
few
times
here,
so
that
we
can
look
at
some
of
the
some
of
the
differences.
Actually,
I
wonder
if
I
should
you
know
what
bear
with
me:
everyone,
I'm
sorry,
I'm
just
going
to
open
this
guy.
A
There
we
go
cool
all
right,
so
here
on
the
left
is
what
we
had
last
last
session.
You
can
see
that
a
lot
of
the
elements
are
pretty
much
the
same
here
right.
Of
course,
the
goal
is
not
to
to
change
fundamentally
how
this
this
part
of
the
experience
works.
It's
more
about
updating
the
style
and
then
sort
of
behind
the
scenes,
also
trying
to
create
something
that
is
reusable
in
the
future
that
is
extensible
and
something
that
we
might
be
able
to
leverage
to
solve
for
information
density
on
different
screens
throughout
the
ui.
A
So
we're
starting
with
this
relatively
low
impact
screen,
but
we
want
to
create
something
that
is
really
useful
for
other
areas
throughout
jenkins,
so
on
the
left
is
where
we
were
you'll
see
that
on
the
right
we
have
removed
the
title,
the
title
prompt
and
the
detail
here-
and
this
is
all
no
longer
contained
inside
of
a
single
card.
What
this?
A
These
are
these
different
elements
can
be
grouped
differently.
For
example,
the
first
two
items
here
are
a
lot
more
relevant
to
one
another
and
don't
really
belong
at
the
same
level
of
prominence
as
this
third
item,
and
we
also
have
an
extensibility
issue
here
with
this
resource
link
at
the
bottom,
where
it
can
be
really
difficult
to
determine
which
option
this
particular
documentation
link
refers
to
imagine
having
two
three
five
or
seven
of
them
here.
A
A
So
we
have
a
couple
of
groupings
here.
We
have
set
up
a
distributed,
build
and
create
a
job.
Now
the
exact
hierarchy
of
of
the
elements
in
this
screen
can
still
be
changed.
Certainly
this
is
still
a
work
in
progress,
but
you'll
see
that
we've
adjusted
the
design
so
that
we
can
associate
particular
documentation
links
with
with
each
option,
as
that
may
not
be
necessary
here.
A
B
A
A
A
B
A
So
what
we've
done
here
is
we've
moved
away
from
from
a
single
card
approach
right,
technically
you
can
call
these
these
different
elements
cards
and
the
exact
terminology
that
we
want
to
label
them.
You
know
we
get
to
decide
that
but
yeah
but
yeah.
The
idea
is
that
these
stacks
of
elements
essentially
would
be
reconfigurable
for
other
other
bits
of
information
throughout
the
ui
yeah.
D
A
Yeah
without
so
I'm
working
on
a
couple
of
concepts
here
that
we'll
share
in
the
next
sig
meeting
that
are
not
quite
mature
enough.
Frankly
for
for
my
own
notification,
I'm
still
thinking
through
them,
but
I
think
that
something
roughly
similar
to
this
not
exactly
like
this-
can
be
done
to
help
organized
build
status
pages.
A
For
example,
pipeline
pages,
there's
a
there's,
a
lot
of
possibilities
there
and
I'm
kind
of
working
through
some
of
those
ideas
right
now.
It's
still
very
rough,
okay.
Nice.
Thank
you
sure,
on
a
fundamental
level.
We
want
to
see
if,
if
we
can
make
this
an
opportunity
to
to
organize
things,
because
right
now,
there's
a
lot
of
stacked
stuff
that
plug-ins
contribute
to
the
ui.
As
we
all
know,
and
better
hierarchy,
more
clarity
would
be,
would
be
awesome.
A
All
right,
this
is
something
we
have
tinkered
with
in
the
past,
but
it
has
not
made
its
way
to
open
source
jenkins.
So
on
the
left
here
we
have
our
current
login
screen.
It's
very
similar
to
the
jenkins
is
preparing
to
africa,
with
the
exact
phrases
jenkins
is
preparing
to
work
or
jenkins
is
getting
ready
that
screen,
but
the
instance
has
been
config.
A
I
forget
the
exact
phrase,
but
there's
some
very
minimal
screens
here
that
get
the
job
done,
but
I
think,
as
we
have
been
creating
all
of
our
baseline
styles,
we
have
an
opportunity
to
modernize
the
screen
a
little
bit,
make
it
a
little
nicer,
make
it
a
little
more
usable
again.
These
are
primarily
just
styling
changes.
B
B
A
I
thought
it
was
yeah
yeah,
so
this
is
where
it
is
today,
and
this
is
the
exact
same
thing
styled
styled
more
nicely,
but
the
key
thing
is,
we
wouldn't
want
to
come
in
and
throw
styles
of
the
screen
like
this
prematurely
like
two
months
ago.
It
wouldn't
have.
It
would
not
have
made
as
much
sense,
because
we
didn't
have
the
typography
where
it
is
today
we
didn't
have
the
colors
where
they
are
today.
Now
we
have
those
styles
and
we
can
feed
them
right
into
this
and
there's
more,
we
can
do
with
this.
A
B
A
D
A
I
think
there.
This
is
probably
a
rare
opportunity
to
do
something
relatively
low
friction
for
a
relatively
nice
payoff,
because
the
screen
for
folks
who
use
the
ui
is
seen
relatively
it's
a
you
see
this.
Certainly
I
see
this
a
good
amount
of
times,
because
I
forget
to
keep
myself
signed
in
it's
just
more
of
a
branding
exercise
using
our
baseline
styles
than
anything
else.
A
A
E
E
A
E
Yeah
yeah,
we
talked
about
that
last
week,
a
quick
reminder.
We
are
looking
into
stuff
what
to
do.
Next,
we
are
doing
discovery.
We
we
will
finish
css
only
work
in
a
and
aesthetic
only
changes,
rather
than
we
get
done
with
icons
and
these
nice
empty
states
that
joe
has
shared,
and
after
that
we
will
probably
be
looking
into
deeper
changes.
C
Cool
and
you've
got
to
see
my
screen,
so
this
is
the
backstage
website.
It's
just
a
quick
intro
into
backstage.
If
you
haven't
seen
it
before
it's.
It's
mostly
used
as
like
a
developer
portal
just
to
centralize
all
your
developer,
tooling.
In
one
place,
just
integrating
all
of
your,
so
you've
got
a
lot
of
services.
C
C
So
I've
just
done
a
proof
of
concept
or
an
alpha
jenkins
plugin
for
this,
which
brings
the
jenkins
build
results
into
it.
I'll
just
give
a
quick
view
through
what
the
what
you
saw
on
that
website
is
the
spotify
internal
version.
They
open
sourced
it
back
in
march
and
it
looks
a
bit
different.
It's
got
the
same
goals,
but
it
just
doesn't
quite
look
the
same.
C
C
C
So
I've
said
add
some
jenkins,
specific
configuration
which
basically
says
what
github
organization
and
repo
it's
in,
because
it's
using
github
organization,
folders
you'll,
see
other
things
here.
Like
the
documentation
that's
been
published,
you
can
create
github
repo.
So
I
can
go
in
here
and
choose
fill
out,
fill
out
a
small
form
and
say
where
it's
going
to
go
and
then
it
will
create
github
repo
based
on
a
template
and
then
there's
some
other
plugins
as
well.
So
I'm
just
going
to
show
you
the
jenkins
plugin.
C
So
it's
got
the
status.
A
lot
of
them
are
failed,
but
you've
got
down
here.
We've
got
some
different
test
results,
showing
a
test
report
and
that
links
through
to
the
jenkins
test
report
as
well,
and
you
can
link-
and
then
it's
all
linked
in
to
get
this
all
into
creative
github.
For,
like
you,
get
our
pull
request
or
the
carhart
branch
and
there's
also
a
a
build
details
view
as
well.
B
C
Just
looking
here
back
at
the
video,
so
this
is
basically
the
hot
they've
got
their
squad,
metrics,
which
is
all
the
metrics
for
their
team.
So
it's
a
central
view
of
all
of
your
applications
in
one
place
built
off
live
data.
So
one
problem
in
organizations
is
you
just
get
so
many
applications
that
you
lose
them?
You
don't
know
who
owns
them.
You
don't
know
who
to
contact
things
like
api
docs.
C
Your
api
talks
might
be
in
a
different
system
so
than
this
you
can
embed
your
api
documentation
for
the
service
in
one
place
and
the
other
thing
is
yeah
creating
so
onboarding
a
new
team
is
like
creating
all
the
repos
that
they
need
creating,
maybe
a
gcp
project.
So
in
here
there's
a
gcp
plugin
where
you
can
create
a
gcp
project.
You
just
fill
out
the
fields
and
it
automatically
does
it
for
you.
C
C
Your
libraries
all
pre-baked
with
all
the
organization
specific
configuration
so
rather
than
using
like
different
templating
engines
for
each
library.
Just
for
the
user,
it
doesn't
matter,
they
don't
need
to
worry
about
it.
It's
basically
trying
to
just
bring
all
of
the
different
tools
into
one
place.
Yeah.
C
C
B
B
A
A
C
A
C
It
was
just
a
brief
update,
so
I
got
all
the
f
tests
that
are
reported
by
felix
they're,
all
passing
now,
not
quite
all
of
them
emerge,
but
most
of
them
emerged.
So
I
think
it
was
about
about
five,
so
those
felix
reported
about
60
70
issues,
but
only
about
five
or
six
of
them
were
ath
tests,
so
those
are
the
ones
that
are
easy
to
fix
and
reproduce
and
out
of
those,
I
think
two
of
them
were
actual
issues
and
the
other
four
of
them
were
well.
C
Two
of
them
were
unrelated
breakages
and
that
were
mostly
done
by
this
by
this
project
by
the
css
refresh
broke
a
lot
of
our
selectors
and
then
two
of
them
were
tables
to
divs
selectors
broken.
But
that's
so
that's
all
sorted
now.
I
think
there's
a
pct
one
decl
in
the
declarative
pipeline
to
take
a
look
at,
but
apart
from
that,
those
are
all
the
null
and
breakages
left,
I'm
sure
there's
more
breakages,
but
I'm
not
sure
what
the
plan
was
taking
it
forward.
C
E
C
I
think
we
really
just
need
matrix
auth
released
really
so
because
matrix
or
matrix
auth
is
quite
a
major
plug-in.
I
think
I
gave
a
list
of
the
pending
pull
requests,
olek
merged
and
released
his.
I
think,
there's
a
thing
there's
a
pipeline
plug-in
that
needs
releasing.
So
I
think
it
was
merged
a
couple
of
months
ago,
but
it
wasn't
released.
C
So
I
think
that
needs
releasing,
but
I
think
I
think
we've
done
all
the
all
the
major
ones
that
we're
aware
of
it's
a
bit
of
a
pain,
because
all
because
a
lot
of
our
tests
are
broken
anyway,
it'd
be
nice
to
have
like
a
green
ath
run,
but
there's
so
many
broken
up
broken
ath
tests
that
you
can't
really
do
that.
Can
you
repeat
that
the
last
thing
please
that's
a
quite
a
few
ath
tests
are
already
failing
for
unrelated
and
unrelated
reasons.
E
C
E
C
C
It's
less
effort
to
maintain
it
now:
we've
mainlined,
so
we've
mainlined,
all
the
javascript
changes
and
all
the
css
changes
are
all
main
lines.
So
we've
we've
had
those
in
for
about
the
last
three
weeks.
Please,
I
think
we
had
a
couple
of
we
had
a
couple
of
very
minor
issues.
I
think,
but
nothing
serious.