►
From YouTube: Jenkins UX SIG Meeting - Feb 5 2020
Description
Fifth meeting of the Jenkins UX SIG. An update on the progress of the UI revamp was given by Felix Queiruga and some full screen mockups showing the future direction were given by Joe Brueggen amongst other agenda items.
A
A
B
E
A
A
Then
we
I
will
give
him
quick
update
on
the
UI
progress.
After
that,
Joe
will
show
his
will
show
the
design
deck
featuring
the
full
page
mocks
that
were
requested
a
while
ago,
and
also
talking
about
wait.
What's
next,
with
typography
I
will
follow
up
on
the
typography
visual.
We
will
talk
about
basically
results
of
the
poll
of
slack
versus
Keter
and
the
follow
up
actions
needed
and
then
Olli
will
raise.
A
point
raise
concern
about
would
start
three
grief.
How
boots
up
for
version
well
woody
would
expand
Baker
and
we
missing
any
agenda
item.
A
Okay,
well,
if,
since
we
can
start
okay,
so
starting
with
I
have
created
a
an
epic
on
the
open
source
data
tracker
which
we
can
change
all
of
the
all
of
the
tasks
and
user
stories
basically
related
to
this
project,
to
the
project
to
the
project.
Under
the
scope
of
this
sick
right
now,
I
read
rapidly
Ritter
actively
added.
A
A
Okay:
let's
go
ahead,
then
next
item
you
a
work,
Progress,
okay,
so
basically
this
this
sprint
well
and
this
since
last
meeting
we
have
created
the
header
on
breadcrumbs
PR
into
being.
There
were
lots
of
comments.
We
did
some
work.
Addressing
those
I'd
see
it's
a
work
in
progress,
but
little
works
left
before
we.
It
can
go
to
a
full
review
status.
A
Just
one
thing,
for
example,
that
we
saw
that
we
will
increase,
really
do
a
little
increase
to
the
scope
of
it.
For
example,
we
notice
that
the
footer
is
the
same
color
as
this
brethren
bars,
so
we
are
related
to
going
gonna
go
ahead
and
also
change
the
color
of
the
footer,
because
again
it
doesn't
make
much
sense
still
have
videos
this
footer
being
of
this
color.
It
looks
off.
A
A
Okay,
good
after
on
a
separate
PR,
we
we're
considering
to
enable
right
now,
right
now
the
UI.
The
new
UI
is
toggled
on
Java
property
at
Jenkins
start
time,
so
we
are
considering
that
it
having
a
run
time
toggle,
probably
in
the
admin
panel
to
to
enable
or
disable
the
UI.
So
we
are
considering
it
doing
in
the
manage
Jenkins
section
so
that
on
the
system,
administrators
could
enable
the
flag
for
for
the
whole
system.
A
B
What
is
the
long
goal
objective
there?
Because
if
you
look
at
the
geo,
for
example,
they
are
proposing
the
old
UI
and
the
new
UI,
currently
I'm,
still
using
the
old
UI,
because
I
can.
The
new
us
is
a
quote
for
some
of
the
things
and
I
don't
want
to
use
it.
So
I
still
have
the
possibility
to
use
the
previous
view.
I.
Do
you
expect
the
same
thing
for
Jenkins
yeah.
A
Just
to
confirm
I
just
to
confirm
again
this,
the
new
UI,
the
things
that
are
enabled
through
the
UI
for
this
deliverable
for
per
gram.
Breadcrumbs
are
just
this
logo
section
on
header
product,
the
rest
of
the
layout
and
markup
will
we
are
going
to
go
ahead
and
be
in
the
baseline
in
the
product
placement?
So
that's.
What's.
A
B
Under
way
between
the
the
full
of
a
warmth,
innocence
and
just
the
would
come
the
ADA
on
the
boy,
Crump
Sarika
news,
because
at
the
moment
you
are
using
the
system
property
to
enable
or
disable
only
do
either.
But
you
expect
in
the
next
or
next
next
PR.
So
we
want
to
do
the
full
UI
innocence
or
to
force
do
CSS.
We
want
to
everybody
if
I
understand,
Kochi
yeah.
A
A
We
are
only
hiding
the
theming
behind
the
feature
flying
because,
although
it
was
requested
that
they
all
presented
a
full
breach
vision
through
full-page
mocks
before
considering
changing
the
default
theme
of
Jenkins.
So
that's
why
we
keep
the
old-school
view,
but
it's
mostly
a
theme.
The
all
UI
folder
is
just
a
theme.
A
B
Okay,
just
that
I'm
not
seeing
the
advantage
to
a
real
switch
in
the
UI
if
it
just
a
quick,
CSS
rectus,
because
the
thing
is
that
what
you
are
adding
to
the
UI,
it's
a
bit
difficult
to
remove
afterwards,
due
to
the
compatibility,
we
want
to
keep
anything
like
that.
If
you
just
a
feature
flag,
you
add
the
feature
flag,
you
keep
it
for
six
month
and
then
you
remove
it.
There
is
no
impact
yeah.
A
That's
I
think
everybody
we
want
to
avoid
having
a
two
code
bases
in
the
long
term.
So
that's
why
we
are
a
bit
for
actively
trying
to
to
make
any
and
all
changes.
Final
easiest
I
just
think.
We
just
think
it's
a
bit
more
usable
for
users
to
test
the
new
UI
without
just
going
to
the
admin
panel
and
double
check
books
on
instead
of
having
to
go
through
all
the
steps.
Rebooting
videogame
systems.
D
Yeah
this
this,
even
though
it's
it's
technically
just
CSS,
but
it's
obviously
a
really
big
shift
in
the
interface
for
Jenkins.
So
we
want
to
have.
We
want
to
offer
that
versatility
in
the
short
medium
term
to
be
able
to
switch
it
off
or
certain
things
that
might
be
more
questionable,
might
be
more
braking
adjustments
and-
and
it
won't
be
there
forever
missing,
10.
A
D
The
intent
is
not
to
have
a
variety
of
themes.
Obviously
there
are
solutions
out
there
for
for
applying
themes
to
your
Jenkins
right
now
and
those
are
widely
loved.
But
the
intent
here
is
to
redesign
the
aesthetics.
You
do
a
visual
refresh
of
Jenkins
for
everyone.
It
will
look
the
same
essentially
between
those
two
options.
It's
that
it's
that
latter
one.
It's
one
one
redesign:
it's
not
the
ability
to
choose
from
different
themes.
That's
not
the
goal
did
I
answer
a
question.
Maybe.
C
I,
misunderstood
yes,
but
no!
No!
No!
It's
because
I
Patrick's
question
I
was
thinking
about
the
possibility
of
having
the
check
instead
of
in
the
manager
Jenkins
page
in
the
configuration
page
for
each
user,
so
each
user
can
enter
and
decide
if
they
if
they
want
one
of
our
styles,
but
if
not
intended.
It
is
just
a
temporary
solution
just
to
make
easier
to
switch
between
one,
the
DP,
all
styles
and
anyone's
just
make
most
more
sense
to
what
they
check
in
the
manage
Jenkins,
a
page
as
Felix
proposed
at
the
beginning.
A
F
A
D
So
we
won't
went
through
them
right
now,
but
or
the
first
four
slides
there,
but
what
I
can
for
any
of
you
after
this
call
I
always
share
in
the
slick
slip.
This
sink
slack
channel
this
this
deck,
whatever
it
looks
like
and
from
that
call,
and
those
three
slides
are
always
there
and
they
give
a
little
bit
more
context
for
the
project
at
large.
D
If
you
want
to
check
those
out
well,
yeah
thinking
into
this
one,
so
this
is
not
from
our
previous
sick
meeting
well
from
our
previous
admitting,
but
from
also
also
from
the
one
before
that
we
had
conversation
around
getting
a
better
idea
of
the
goal.
Actually,
could
you
go
back
one
step
EULEX
or
one
slide,
one
more,
please
mm-hmm
of
getting
a
better
idea
of
where
this
is
going
right.
D
So
we
started
off
with
our
first
component
and
naturally
the
design
process
was
a
bit
slow
there,
just
because
this
was
our
first,
our
first
time
figuring
out
how
we
can
do
this.
As
a
group
last
last
cig
meeting,
we
took
a
look
at
the
impact
of
these
sorts
of
conversations
and
of
this
group,
because
the
design
acts
change
really
dramatically
with
everyone's
input,
and
it
was
way
better
off.
So
that
was
great,
but
we,
as
a
group
we've
been
wanting
to
see
what
could
it
look
like?
D
You
know,
instead
of
just
looking
at
a
component
by
component,
so
there
are
some
pros
and
some
cons
to
to
designing
a
fullscreen
mug
like
this
at
this
stage
in
the
process,
essentially,
the
only
danger
for
lack
of
a
better
word
around
that
is
that
I
can
sent
the
wrong
the
wrong
intention
potentially
right.
So
we
want
to
make
it
real
clear
with
these
mocks
that
these
are
not
set
in
stone.
These
designs
are
going
to
change,
and
so
that's
what
I'm
kind
of
mentioning
on
this
side
there.
D
The
goal
is
to
communicate
a
long-term
vision
for
the
impact
of
this
visual
refresh
the
CSS
phase,
but
things
are
going
to
change
right,
just
like
with
the
just
like
with
the
header
bar,
we
encountered
some
technical
limitations
that
impacted
the
design.
I
got
feedback
from
all
of
you
that
impacted
the
design,
which
is
great
the
same
things
gonna
happen
for
everything
on
the
screen
and
the
other
screen
we'll
look
at
in
a
second,
so
take
it
with
a
grain
of
salt,
but
this
is
what
we
were.
D
What
this
nav
panel
could
look
like.
So
in
that
regard,
this
is
a
really
great
exercise
too,
and
this
is
to
give
an
idea.
Now
we
can
go
to
the
next
slide
looks
this
is
the
same
screen
a
little
larger
and
then,
if
we
go
one
more
slide,
this
is
what
you
know
again.
Asterisk
marks
asterisk
marks.
Take
it
take
it
all
with
a
grain
of
salt,
but
this
is
what
we
could
achieve,
potentially
with
with
a
build
view,
for
example,
so
I'll
stop
there
and
obviously
we
keep
our
conversation
pretty
freeform
here.
G
You
think
it
wouldn't
better
if
we
have
some
more
user
interaction
in
these
pages,
so
these
pages
are
quite
aesthetic.
So
what
a
lot
of
people
ask
me
is
why
can't
I
rearrange
these
items
on
the
screen,
for
instance,
so
this
would
be
one
of
the
most
valuable
features
if
these
pages
have
a
concept
of
dashboard
thing
where
you
can
put
in
things
and
move
things
off,
and
things
like
that,
that
put.
D
You
know
it
does
make
perfect
sense,
I,
totally
agree
and,
frankly,
taking
a
step
back
if
if
this
were
the
the
right
phase
of
this,
this
long
term
Jenkins
project
to
think
through
that
sort
of
thing
this
this
part,
these
smocks,
would
look
very
different
right
in
in
a
perfect
world
and
if
timelines
weren't,
a
factor
I
would
love
to
just
reconsider
a
lot
about
the
user
experience
here,
because
you're
right,
there's
so
much
opportunity
for
improvement.
That
said,
right
now,
and
the
scope
here
is
for
these
Marx's
is
just
this
visual
refresh
right.
D
F
D
I
think
that's
a
that's
a
great
point,
so
some
that
come
back
packaged
within
Jenkins
would
would
definitely
need
to
be
revisited.
Some
that
are
contributed
via
plugins.
Would
you
know
I
wouldn't
have
a
very
much
ability
to
change
those
and
that's
okay
too,
but
yes
in
short,
yeah.
So
one
example
of
how
this
will
change
there.
You
go.
D
Cool,
maybe
we
can
tell
go
back
a
slide.
Obviously
you
know
we
have
our
Sigma
teams
one
every
other
week,
but
conversation
is
going
and
slack
and
soon
getter
we'll
talk
about
that
in
a
second.
So
anytime
we
reach
out-
and
let's
let's
talk
about
these
and
then,
if
we
go
to
the
next
section
of
the
deck.
D
So
in
our
last
meeting
we
took
a
look
at
a
new
color
palette
for
the
Jenkins
UI,
something
that
is
informing
the
design
of
individual
components
and
that
also
inform
the
design
of
those
fullscreen
monks.
It's
something
that
a
lot
like
a
lot
like
a
lot
of
the
content
we
look
at
in
this
meeting
will
continue
to
evolve
right.
It's
not
perfect
at
it
will
change,
but
it
was
created
with
accessibility
in
mind
for
for
high
contrast,
UI
and
the
other
item
we
looked
at
was
interactive.
D
States
today
we're
going
to
take
a
quick
look
at
typographic
hierarchy.
These
are
the
elements
of
interface
design
that
come
together
and
will
inform
all
of
these
additional
components
that
we
kind
of
saw
early
representations
of
in
those
fullscreen
mocks
like
table
Styles
buttons
nav.
That
sort
of
stuff,
so
the
intended
outcome
with
this,
is
to
establish
a
formal
type
of
graphic
higher
hierarchy
for
the
Jenkins
UI
that
improves
legibility
and
that
results
in
a
more
consistent
experience
throughout
so
still
being
defined.
D
D
This
is
something
we'll
talk
about
in
just
a
second,
but
we
know
that
Jenkins
has
very
important
internationalization
needs
and-
and
therefore
you
know,
we
can't
just
go
about
picking
picking
fonts,
just
based
on
on
legibility
alone,
that
they
have
to
have
a
certain
degree
of
compatibility
with
like
other
languages
besides
English
for
sure.
So
we'll
talk
about
that
in
a
second
and
that's
actually
it
for
this
deck
I
think.
Does
anyone
want
to
comment
on
this
or
have
any
questions
just.
B
One
comment
about
the
adding:
in
general:
we
have
some
trouble
when
we
have
something
like
that.
That
is
separated
into
multiple
here,
because
often
the
h5
is
it
in
the
same
size
of
smaller
than
the
regular
text,
and
it
seems
to
be
the
case
here
with
sixteen
and
I.
Think,
eighteen
for
the
part
of
body-
and
in
this
case
the
title
or
the
sub
sub
sub
sub
title-
is
smaller
than
the
text
inside
the
paragraph.
B
G
One
thing
I
want
to
mention
is
what
is
currently
done
by
a
lot
of
plugin
developers.
Is
they
choose
h1,
h2
or
h3?
So
they
choose
is
one
thing
that
they,
like
so
I,
think
it
would
make
sense
that
everybody
starts
with
h1
and
then
H,
2
and
so
on.
But
currently
one
does
not
select
the
semantics.
It's
someone
selects
the
font
size
and
that's
a
little
bit
strange
I
think
so.
It
makes
sense
that
we
defined
that
if
you
have
a
new
page,
then
you
need
to
start
with
h1
and
so
on.
A
What
I
always
like
to
do
in
all
my
projects?
One
approach
that
I
found
works
really
well
is,
for
example,
I
I
want
the
h1
back,
but
I
will
also
create
an
h1
CSS
class
that
I
can
apply
everywhere
with
the
same
styles,
so
I
think
that
approach
works
really
well.
So
if
semantically
somebody
wants
to
put
an
h3,
but
they
want
it
to
look
like
an
h1,
they
could
use
the
h1
class.
A
Than
that,
my
recommendation
is
to
always
use
their
headers,
also
read
a
having
elements:
plane,
no
classes,
just
the
proper
margins,
the
prepare
the
default
styles,
because
it's
more
modulus.
But
for
that
it
is
your
right.
We
did
include
a
plug-in
authors.
Needs
need
to
have
available
actual
typographic
classes.
D
A
A
A
We
are
also
aware
that
a
huge
part
of
the
Jenkins
use
ways,
for
example,
is
located
in
China,
so
we,
what
we
are
probably
going
to
to
try,
is
to
get
in
touch
with
Janey's
localization
see
to
get
collector
feedback
or
whether
there
are
good
for
font
for
box,
for
Chinese,
for
Chinese
characters
or
other
know-nothing
alphabets,
and
and
if
not,
maybe
they
can
recommend
a
font
such
as
Noto,
for
example,
which
is
pretty
vague
or
I
think
this
is
yeah.
This
is
just
to
mention
that
we
are
aware
of
this
and.
F
D
Awesome
I
think
we
have
reached
item
number,
seven
and
I
want
to
make
sure
we
leave
time
for
item
number.
Eight,
so
I'll
be
quick
in
the
last
say
meeting
we
talked
about
whether
or
not
we
should
be
having
our
discussions
in
slack
or
somebody
someplace
that,
for
some
people
is
more
central,
which
is
gooder
lots
of
pros
and
cons
which
I
don't
have
to
go
through
here,
but
one
of
the
most
important
ones
being
that
slack
is
in
the
CDF
organization.
D
So
it's
it's
unpaid
and
therefore
we
have
to
kind
of
manually
archive
our
valuable
technical
conversations.
Another
thing
is
that
all
the
other
SIG's
are
using
dinner
and
it
makes
more
sense
for
more
people.
So
I
put
a
poll
up
in
our
slack
and
it
turns
out
that
git
er
is
the
preference,
so
I'll
follow
up
for
now.
D
In
slack
after
this
call
and
and
we'll
get
it
sorted,
we'll
get
the
group
created,
I'll
be
new
together,
so
I'll
figure
it
out
and
we'll
get
that
going,
but
before
the
next
meeting
I
think
we
should
be
able
to
transition
over
and
then
all
of
our
conversation
should
be
more
public
and
that's
it
for
that
one.
So,
thanks
everyone
for
voting
in
the
Pope.
A
G
Yeah,
actually,
this
point
is
mostly
a
question
if
I
should
do
something
here,
because
I'm
currently
extracting
the
UI
components
that
I'm,
using
in
the
warnings
plugin
into
separate
UI
modules.
I
already
wrote
a
mail
about
that
and
we
had
a
discussion
and
we
both
on
on
the
pre
request,
where
I
noticed
that
bootstrap
for
is
not
compatible
with
bootstrap
3,
which
we
are
using
in
champions
and
I
try
to
get
it
fixed.
But
I
came
from
one
back
to
the
next
part,
because
we
are
using
lots:
plain-vanilla
bootstrap
3.
G
We
are
using
24
columns,
and
so
everything
is
breaking
in
my
plugin.
If
we,
if
I
use
this
old
grid,
so
I'm
wondering
if
it
makes
sense
if
I
create
a
pull
request
for
Jenkins
color.
That
replaces
this
grid
with
a
good
strip
for
version,
so
I'm
not
sure
if
I
should
make
it,
because
UI
changes
in
core
are
somewhat
complicated
because
we
have
no
tests
etc.
So
I
just
wanted
to
know
if
it
makes
sense,
because
we're
currently
maybe
breaking
other
things
as
well
with
the
new
I
changes.
A
A
That's
a
that's
an
issue.
Definitely
that's
something,
because
there
I
also
looked
that
there
are
many
plugins
which
use
column,
13,
column
20.
Thank
you.
So
that
would
break
also
I
think
replacing
the
column.
The
grid
system
is
not
viable
and
you
we
couldn't
with
deprecated
it,
but
it's
not
file.
My
recommendation
here
would
be
to
create
a
new
grid
and
maybe
a
new
grid
file
and
I
would
namespace
it.
It's
rather
easy.
A
For
example,
you
would
have
Jenkins
Cole
dot
Excel,
but
one
something
like
that:
jinkies
not
Jenkins,
bro,
yes
container,
but
actually,
by
the
way
that
she
should
be
doing
plugins
should
be
namespace
in
their
own
CSS
Jenkins
core
should
name
space
its
own
it
space
components.
So
only
what
I
am
going
to
try
to
do
is
I'm
going
to
try
to
boots
top
boots
are
provide
several
mixes
to
generate
agreed,
write
several
such
abilities
to
generate
agreed
with
little
modification.
You
could
create
custom
mixes
based
on
those
to
create
a
greater
namespace
grid.
A
B
G
G
G
A
Okay,
okay,
any
other
questions,
just
one
mention
only
on
the
topic
of
the
quadlings
and
applauding
I
will
try
to
do
my
best
I
try
to
to
make
the
base
layout
for
the
bonus
and
you
planning
to
not
break
as
much
as
possible.
I'll
have
the
base
styles
and
the
layout
comments
in
the
repple
not
deleted,
so
that
you're
planning
the
plugin
can
make
use
of
those
files
so
I.