►
From YouTube: Jenkins UX SIG Meeting 16 Feb 2022
Description
User Experience Special Interest Group February 16, 2022.
00:00 - Introduction
01:57 - Image removal breaking existing plugins
09:20 - Source code highlighting with prism plugin
16:08 - Icons and images from font awesome 6 plugin
18:40 - Code coverage plugin column presentation
24:07 - UI improvements
30:15 - UI samples plugin
34:14 - Theme manager live reload
45:20 - Buttons and breadcrumbs improvements
47:20 - Sidebar simplification discussion and alternatives
A
A
A
A
Okay,
next
topic,
then
was
there
was
a
concern
I
saw
from
daniel
beck
in
terms
of
the
image
removal,
the
the
removal
of
icons
may
break
some
long
existing
plugins.
I
wanted
to
get
get
input
from
people
in
the
ux
sig.
Is
there
something
we
should
do
about
this?
How
would
how
would
we
approach
it,
etc?.
B
A
A
E
A
E
A
D
D
There
are
a
lot
of
users
of
jenkins
that
are
implementing
their
own
plugins,
and
in
that
case
they
do
not
have
the
knowledge
about
what
you
know
in
terms
of
what
is
easy,
what
they
have
to
do,
and
this
kind
of
thing,
so
it
could
be
a
bit
more
painful
to
do
for
them
the
different
update
that
are
required
there.
So
is
it
possible
to
have
a
separate
plugin
with
the
legacy
icon
with
the
good
links
and
this
kind
of
thing
so
that
they
can
keep
using
their
own
private
plugin
with
that
legacy?
D
In
the
sense
that,
if
I
imagine
I
have
a
private
plugin,
I'm
using
some
links
that
are
no
longer
available
in
the
new
version
of
jenkins,
will
I
get
the
information
that
there
is
immigration
gate
somewhere
like
some
404
page
with
information?
Hey,
you
can
look
at
that
immigration
path,
this
kind
of
thing
or
just
you
have
to
guess.
You
have
to
create
an
issue
to
look
for
the
things
in
the
website.
A
E
E
F
D
A
Okay,
so
so
good
insight,
so
I
think
I'm
back
to
the
consensus
being.
We
would
prefer
to
have
plug-in
maintainers
repair
it
make
the
changes
and
use
use
the
migration
guide
as
their
as
their
guidance
on
how
to
do
it
is
there
a
way
that
I
could
search
through
the
jenkins,
open
source
code
base
and
see
the
plugins
that
need
migration.
I
assume
there
is
right
that
we
could
that
that's
a
searchable
thing.
E
E
E
A
C
C
So
last
year
I
think
I
introduced
the
new
plugin
that
can
yeah
highlight
source
code
and,
basically
sorry,
I'm
using
it
in
the
warnings
plugin
to
render
the
source
code.
So
here
is
one
example
in
in
one
of
my
warnings,
plugin
views
where
you
will
see
the
source
code
of
a
yeah
of
an
warning,
and
you
see
here
the
warning
highlighted
and
what
I'm
using
here
in
the
background
is
the
prism
plugin
now,
which
is
rendering
the
source
code
using
yeah
javascript.
C
What
I
this
was
part
of
the
warnings
plug-in
and
now
I
created
from
this
part
of
the
warnings
plug-in
a
new
plug-in
where
other
plugins
can
use
it.
So,
for
instance,
I
would
like
to
use
it
in
the
code
coverage
plug-in
and
maybe
some
other
plugins
can
use
it
as
well.
What
I
created
now
is,
I
extracted
all
of
these
colorings
into
this
plug-in,
so
it
depends
on
the
language
you're
using.
C
C
C
Maybe
there
are
some
additional
ones
available,
but
these
are
the
ones
I
found
on
the
plug-in
repository
of
prism
and
you
can
select
the
plugin,
and
if
you
choose
a
different
theme,
then
the
rendering
will
look
different,
so
you
can
use.
If
you
have
a
dark
theme,
you
can
use
this
one.
If
you
have
a
light
theme,
you
can
this
one,
that
it
depends
what
you
prefer.
C
Currently,
it
is
only
possible
to
configure
it
in
the
system
configuration.
What
I'm
going
to
add
is
to
make
it
customizable
per
user,
so
a
user
can
say.
Okay,
I
have
a
dark
theme
or
a
light
theme
yeah.
That
would
be
easier
if
it
can
be
changed
per
user
and
it
would
even
be
not
much
easier
if
we
can
change
it
automatically,
but
I'm
not
sure
how
to
do
this
to
get
an
event.
If
the
you
know
system
is
using
a
light
theme
so
in
on
mac
os,
you
can
switch
and
toggle.
C
G
E
E
C
A
C
Actually,
it
provides
this
view,
so
the
idea
is,
if
you
change
well
yeah,
if
a
lot
of
plugins
are
using
the
same
view,
I
don't
need
to
reprogram
these
views
and
if
I
want
to
change
it,
I
needed
to
change
it
only
in
one
place.
So
the
idea
is
like
the
bootstrap
plug-in.
We
have
the
javascripting
library
and
some
add-ons
we
can
already
use
in
java,
so
yeah.
C
C
C
They
have
now
a
release
6
with
a
lot
of
new
icons
and
a
lot
of
new
designs,
and
I
included
these
new
icons
now
in
the
yeah
corresponding
jenkins
plugin.
So
if
someone
would
like
to
use
icons
which
are
not
the
tango
icons,
but
some
looking
better
ones,
yeah,
everybody
can
use
the
new
ones
of
the
6.0
version
of
a
font.
Awesome.
A
C
C
C
So
as
a
plugin
author,
I
just
want
to
use
icons.
I
don't
want
to
search
in
the
internet
for
an
icon
and
don't
want
to
upload
it
in
my
plugin.
I
just
want
to
use
them,
so
this
is
the
idea
behind
this
plug-in
and
yeah.
Maybe
we
can.
We
have
a
similar
concept
in
core.
Sometimes
then,
this
plug-in
is
not
needed
anymore.
C
C
So
currently
we
are
using
the
percentage
here
of
the
code
coverage
and
a
color,
and
the
color
has
a
yeah,
a
shading,
or
how
do
you
say
it
in
english,
a
gradient
where
it
you're
more?
It's
more
green.
If
you
have
a
higher
coverage
and
it
will
go
sometimes
too
red
so,
but
it
doesn't
really
look
like
a
nice
with
a
new
table.
So
I'm
not
sure
if
someone
has
an
idea
how
we
can
improve
such
fuse
or
some
cells
here.
D
D
Some
labels
tags
the
things
that
are
just
around
with
the
background
around
the
number
like
you
can
see
on
the
notification
pills
in
general
with
the
exactly
the
same
kind
of
color.
You
have
there
with
some
red
thing
if
it's
below
20
or
things
like
that,
you
have
the
information
about
the
color.
You
have
the
number,
but
you
are
not
fully
feeling
the
the
cell
completely
in
terms
of
background.
D
E
C
E
C
C
Yeah
what
I've
seen
is-
maybe
this
is
a
totally
different
example.
On
the
sorry,
let's
see
when
you
look
at
code
cuff,
who
have
there
is
a
tool
which
which
showed
the
coverage.
Sorry,
I
thought
that
we
can
see
it
here.
Okay,
it
doesn't
work
now.
Okay,
sorry,
so
they
provide
a
background,
which
is
a
kind
of
yeah.
50
of
the
background
is
filled
and
50
is
not
filled,
and
this
shows
a
coverage
of
50.
C
A
C
Yes,
of
course-
and
this
is
yeah
the
label-
still
it
doesn't
it's
okay,
that's.
I
already
commented
that
on
the
pull
request,
but
I'm
just
wondering
how
to
the
cells
should
look
like
because
in
the
static
analysis
plugins,
I
have
the
same
thing
so
yeah,
okay,
this
is
a
different
thing,
that
our
tooltips
don't
good
and
how
yeah
show.
How
can
I
show
that
a
project
has
too
much
warnings
or
if
the
warnings
are
okay,
it's
something
like
that.
C
C
A
B
So
things
are
a
little
bit
more
consistent.
Now
they
have
the
same
kind
of
focus,
states
and
colors
and
whatnot.
So
this
was
this
is
quite
a
pain
getting
in.
So
thanks
everyone
for
the
help.
It
is
really
appreciated.
So
that's
that's
now
merged,
there's
gonna,
be
a
fair.
Few
follow-up.
Merge
requests
to
this
just
to
update
the
odd
thing
such
as
the
draggable
cards,
they'll,
probably
change,
eventually
and
stuff
like
that.
B
Very
recently,
the
new
icons
have
been
merged
in
so
users
can
now
use
the
symbols
across
jenkins,
as
seen
on
the
settings
page
everything's
using
the
same
kind
of
simple
icon.
Basically,
it's
quite
flat,
and
so
on,
looks
like
so
and
then
recently
I've
been
working
updating
the
rest
of
the
icons
across
jenkins,
so
you'll
see
in
the
sidebar,
using
the
same
style
of
icons
and
the
rss
icons
updated
the
little
pencil
but
also
recently
updated
the
kind
of
status
and
lever
icons.
B
A
A
B
D
D
E
D
E
B
H
E
B
Kind
of
somewhat
on
that
topic
as
well,
I've
recently
very
recently,
just
forked,
the
ui
samples
project
just
to
try
and
update
that
a
little
bit.
Nice
kind
of
looks
like
it's
completely
very,
very
rough,
but
the
idea
is
that
we'll
have
a
kind
of
page
for
every
component
and
just
developers
can
kind
of
pop
on
here
and
copy
code
and
so
on
and
get
the
right
of
templates,
yeah
and
so
on.
We.
C
A
E
A
B
B
B
E
A
A
And
now,
for
as
guidance
for
me,
I
think
most
people
are
preferring
to
write
jelly.
Is
there
a?
Is
there
a
reason
we
should
be
pushing
more
and
more
people
should
the
git
plug
in,
for
instance,
switch
from
the
things
where
it's
using
groovy
now
in
its
ui
to
use
jelly?
Is
there
a
is
there?
Are
there
weaknesses
in
using
groovy
that
I
should
be
aware
of.
D
When
we
are
looking
for
things
in
jenkins,
if
you
are
using
a
completely
different
language,
it's
just
completely
different
for
us
to
look
for
your
thing
in
general.
So
if
I
can,
with
a
magic
wand,
to
change
all
the
groovy
view
to
jelly,
I
will
do
it
in
an
instance
because
for
us
it's
just
doubling
the
size
in
term
of
a
result,
a
whole
stove
varieties,
kind
of
thing.
So.
E
A
A
E
E
So
yeah
yarn
started
this
a
while
back,
but
it
kind
of
just
left
it
because
it
depended
on
the
form
rework.
But
so
you
might
have
seen
this
before.
You
will
have
seen
that
he's
changed
the
built-in
themes
from
just
little
radio
buttons
on
the
side
here
to
actually
separate
them
out
into
a
theme
and
then
he's
got
like
pulled
in
the
colors
from
each
theme
and
then
it
shows
you
which
theme
it
is
and
then,
if
you
click
on
it,
it
will
actually
change.
E
E
A
E
That
wasn't
done
nothing
to
do
that.
I
just
I
just
changed
the
css
class,
not
even
css
a
data
set,
so
it's
based
on
this
value
up
here,
themes
in
our
namespace,
so
it's
a
bit
of
a
design
change.
So,
instead
of
only
serving
one
css
file,
it
serves
all
the
css
files
on
the
pages
and
then
based
on
this
value.
Here,
it's
which
theme
it's
going
to
show.
A
E
E
The
sold
authorized
ones
are
under
a
kilobyte
and
the
dark
theme
ones
are
about
11
kilobytes,
each
and
they'll
be
cached
heavily
once
I
fix
the
dark
theme,
not
catching
stuff,
whereas
I
see
that
daniel
use
stapler
in
a
better
way,
yeah
there's
one
bug
to
fix
on
the
solarize
system.
As
you
see,
cellular
system
isn't
working
and
I
need
to
change
something
in
core
just
integrate
with
this,
so
that
it
gets
the
default
color
instead
of
the
currently
selected
one.
But
it's
pretty
much
there.
E
E
E
I've
done
a
bit
of
a
hack
in
the
dark
theme
when
I
load
the
file.
I
add
this
prefers
colors,
then
dark,
rather
than
how
the
other
mechanism
was
before.
So
there's
a
couple
of
places
in
automatic,
and
so
it
just
does
a
finer
replacement
of
that
as
well
changes
to
dark
systems.
I've
only
got
one
css
file,
it's
a
bit
hacky,
but
you
see
all
these.
This
data
theme
equals
dark,
selectors,
that's
selecting
the
root
elements,
theme
and
you'll
also
see
the
theme.
E
E
And
I'll
also
try
fix
up
solarize
to
work
on
system
as
well
and
probably
update
material
theme
and
core,
but
I
think
it's
pretty
much
there.
It's
pretty
close
to
ready.
I
pushed
so.
I
updated
yarn's
progression
theme
manager.
There's
one
thing
that
is
failing
is
the
injector
test.
Fails
because
it
doesn't
allow
you
to
do
four
equals
on
the
label.
The
yarn
switched
from
attached
previous
to
four
equals,
but
I
think
jenkins
corals
are
switched
from
that
which.
C
A
G
E
Yeah,
so
it
associates
a
label
to
an
input
using
the
id
you
weren't
allowed
to
do
it
before
because
of
well.
It
was
discouraging
to
do
it
because
repeatable
elements
and
and
guessable
ids
wasn't
so
easy,
but
that's
all
handled
for
you
inside
of
the
jelly
fragments
so
inside
of
radio,
if
radio
or
whatever
it
is
it
generates
the
id
for
you
and
does
the
association,
whereas
before
there
was
a
javascript
function
called
which
attached,
which
would
try
and
find
these
and
attach
them.
E
B
C
And
for
me
I
have
a
question
about
for
plugins.
So
what
I'm
using
my
plugins
is
a
kind
of
color
palette
to
show
the
warnings
or
to
show
the
coverage,
and
I
think
that
it
would
be
perfectly
if
we
integrate
an
extension
point.
So
plugins
can
provide
a
themeable
thing
and
then
I
can
have
different
colors
if
we
have,
for
instance,
a
black
theme,
and
currently
the
colors
are
look
a
little
bit
weird
on
the
charts.
If
we
use
the
same
colors
in
a
dark
theme,
so
we
can
automatically
switch
them.
E
G
E
C
So
because
the
unit
plugin
needs
something
to
represent
a
green
thing
and
a
red
thing,
the
warnings
plug-in
needs
it.
The
coverage
plug-in
needs
it
and
maybe
a
different
plug-in
needs
it
as
well.
So
it
makes
no
sense
to
have
10
different
theme
at
different
color
palettes.
It
makes
maybe
sense
to
have
one
system
color
palette.
B
E
B
B
A
F
A
E
B
B
E
H
B
C
C
H
I
mean
to
to
some
extent
this
is
a
problem
with
the
extensible
nature
right,
because
if
we
say
well,
we
only
display
things
by
default.
If
they
are
an
important
action
or
something,
then
obviously
every
plugin
maintainer
will
say.
Yes,
my
plugin
is
definitely
going
to
implement
important
action
because
it
is
very
extremely
important
and
we
have
the
same
problem
all
over
again
like
for
years
down
the
road.
E
C
B
And
one
of
the
things
I
was
kind
of
thinking
of
was
kind
of
having
plug-ins
displays
cards
kind
of
on
the
build
page.
So
for
the
static
analysis,
warning
have
a
card
for
that.
So,
instead
of
having
an
action,
you
just
can
see
the
card
straight
away,
for
example,
so
there's
less
clicking
involved
and
hopefully
showing
more
on
the
build
page,
because
right
now
it
can
be
a
bit
empty
at
times.
E
E
H
Something
we
could
look
into
could
be
that
we
show
only
some
of
the
items
now.
There
are
a
few
ways
we
could
do
that.
I
just
mentioned
the
prominent
or
important
action
that
would
always
be
be
displayed
and
the
others
are.
You
know,
kind
of
have
to
click
on
an
element
first
before
they
are
visible
or
something
like
that.
The
other
option
would
be
that
users
can
configure
the
stuff
they
want
to
see,
which
obviously
means
it's
still
a
mess
unless
a
user
goes
through.
H
The
work
of
you
know
customizing
their
thing,
which
is
probably
not
a
great
default,
and
another
might
be
that
we
could
look
into
like.
Can
we
track
the
actions
actually
used
by
a
user
in
some
manner,
because
we
know
when
you
click
the,
we
can
probably
determine
when
you
click
the
link
to
see
an
action
and
navigate
there.
H
Can
we
track
that
in
your
user
profile,
obviously
difficult
impossible
with
the
anonymous
user
and
feels
a
bit
like
brittle
magic
when
people
don't
understand
what's
happening,
but
just
off
the
top
of
my
head?
These
might
be
strategies
we
could
employ
without
entirely
throwing
away
this
part
of
the
ui.
C
I
think
we
presented
a
couple
of
months
ago,
one
of
the
bachelor
thesis
work
for
one
of
my
students,
where
we
had
this
pull
request:
monitoring
plugin,
which
showed
how
we
can
use
some
kind
of
you
know,
drag
and
drop
things
to
configure
the
screen.
Maybe
this
is
an
approach
as
well,
so
maybe
I
show
you
the
details.
Maybe
it's
easy,
so
this
is
where
the
idea
was
that
we
have
these
things
where
we
can
put
these
elements
here
and
we
can.