►
From YouTube: UX Showcase: All the small solutions
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Well,
I'm,
sorry,
okay,
so
I
am
going
to
be
talking
about
all
the
small
solutions,
so
a
little
bit
of
context
on
that
back
in
I
think
it
was
January.
February
I
moved
over
from
defend
to
secure
and
in
that
process
I
identified
a
number
of
dormant
issues
and
issues
that
needed
to
be
open
in
light
of
research
findings.
Customer
pain
points
things
like
that
that
I
came
across
as
part
of
that
onboarding
process.
So
there
were
a
lot
of
small
solutions
that
came
out
of
that.
A
At
the
same
time,
we
in
static
analysis,
which
is
the
group
that
I'm
in
and
under
secure,
we
had
a
newer
product
manager
who
is
getting
our
roadmap
in
place,
and
so
we
are
now
focused
on
more
larger
efforts.
So
that's
coming
very
soon,
but
for
for
this,
we'll
just
be
talking
about
the
small
improvements
that
we've
making
over
the
last
couple
of
months.
A
So
where
does
secure
live
it
lives
in
many
places?
There's
some
not
even
pointed
to
here.
There's
a
it
lives
in
the
pipeline's
page,
because
there
are
jobs
that
run.
They
live
in
the
merge
request
that
comes
from
that
pipeline
run
and
then
there
is
a
dedicated
security
and
compliance
section
of
the
nav.
So
within
there
we
have
a
security,
dashboard,
vulnerability
list,
dependency,
lists
and
so
forth.
A
In
addition
to
a
configuration
age
where
you
can
look
at
all
of
your
scanner
types
across
across
sass
dust,
container
scanning
dependency
scanning,
all
of
those
things
license
compliance,
but
for
the
purpose
of
this
showcase,
we'll
be
looking
at
the
merge
requests,
as
well
as
the
project
security,
dashboard
and
the
configuration
page.
There's
also
a
group
level,
security,
dashboard
and
an
instance
level.
Security
dashboard,
as
well
as
the
yellow
file,
which
holds
the
configuration
that
obviously
lives
in
the
repository.
A
Ok,
so
just
a
quick
overview,
so
security
scans
run
as
jobs
in
the
pipeline
and
then
the
results
which
are
potential
vulnerabilities
are
displayed
in
the
M
R
and
as
also
on
the
security
dashboard.
So
there's
kind
of
two
personas
at
play
here,
depending
on
the
company
size,
larger
companies
will
have
developers
looking
at
the
M
R
when
they're
trying
to
push
code.
They'll,
look
at
the
findings
that
came
from
the
jobs
that
ran
the
pipeline.
A
A
A
Researcher
Holly
did
a
study
back
in
late
2019
that
revealed
that
some
users
were
confused,
why
TMR
was
able
to
be
merged
if
the
security
jobs
found
potential
vulnerabilities,
so
many
users
aren't
aware
that
they
can
enable
something
called
security
approvals
which
require
approval
from
it
does
designated
member
of
their
team
if
the
MRO
introduced
certain
vulnerabilities
or
a
license
compliance
violation.
So
until
we
can
look
at
more
holistic
explorations
for
improving
teacher
awareness,
we
went
for
an
MVC
that
was
easy
to
implement
and
wasn't
going
to
break
anything.
A
This
will
hopefully
bring
more
awareness
to
the
security
approval
functionality,
as
well
as
instructions
on
how
to
an
equal
security
of
approvals.
So
we
hope
that
this
MVC
will
solve
the
problem
of
not
understanding
how
the
M
R
can
be
merged
if
security
vulnerabilities
were
found
and
how
to
prevent
this
from
happening.
If
the
users
organization
has
a
structure
security
paradigm.
A
They
quickly
skim.
It
see
some
green
and
black
icons,
other
loading
indicators
and
think
they're,
okay,
without
necessarily
drilling
into
the
results,
keep
in
keeping
in
mind
that
their
primary
goal
here,
their
primary
task
is
getting
their
code
merged,
and
so
some
of
these
things
can
seem
like
roadblocks
along
the
way.
A
But
if
it's
important
enough,
we
won't
definitely
want
to
call
attention
to
that
and
encourage
them
to
to
take
note
and
to
look
into
it
further.
So
we
wondered
if
we
could
somehow
draw
more
attention
to
the
security
widget
findings
without
necessarily
implying
priority
over
other
findings
identified
from
other
jobs
in
the
pipeline.
So
yeah
I've
worked
with
some
other
UX
designers
across
stage
to
try
to
find
a
happy
medium
between.
A
A
The
security
dashboard
shows
vulnerability.
Findings
from
all
scanner
types
asked
a
stet
cetera
by
default,
but
if
some
scanners
are
enabled
and
others
aren't,
we
show
the
vulnerability
findings
from
the
enabled
scanner
type,
but
we
currently
have
no
way
of
telling
the
user
that
one
or
more
of
those
scanner
types
have
not
been
a
nail
and
enabled
if
they
want
to
enable
them.
A
If
there
are
some
that
are
not
enabled,
how
might
we
help
them
to
enable
it
if
that's
what
they
want
to
do
so
the
small
solution
we
came
up
with
here
was
a
warning
alert
in
the
table
that
will
inform
a
user
if
they
don't
have
one
or
more
of
the
scanner
types
enabled,
but
they
are
set
in
the
filter.
So
also
this
solution
will
be
able
to
provide
a
link
that
gives
them
more
information
on
how
to
enable
it
if
they
so
choose.
A
So
the
benefit
of
this
solution
is
that
it
will
be
stored
locally
on
a
user's
machine.
So
if
dismissed,
it
won't
show
up
again.
We
know
that
there
are
some
use
cases
where
users
intentionally
don't
want
some
scanner
types
enabled
for
a
project.
So
we
don't
want
to
have
something
persist
more
permanently
and
have
them
have
something
on
the
page
that
they
have
to
then
ignore
all
the
time.
A
A
Okay
and
then
problem
to
solve
number
four
is
empty
states.
So
currently
we
have
very
vague,
empty
states
that
don't
really
communicate.
Why
there's
no
content
so,
for
example,
the
empty
state
shown
here
is
in
the
tone
of
what
the
user
can
do
and
use
this
copy
proposition
as
a
value
add
for
the
feature,
so
it
says,
monitor
vulnerabilities
in
your
code.
The
security
dashboard
displays
the
latest
security
report.
You
use
it
to
find
and
fix
vulnerabilities.
A
A
It's
it's
a
bit
ambiguous,
so
this
is
an
ongoing
project,
we're
looking
at
empty
states
across
the
projects,
security
dashboard,
as
well
as
the
group
and
instance,
security,
dashboard
and
the
use
cases
are
a
little
bit
different.
So
it's
very,
very
complex.
So,
for
example,
in
groups
you
can
have
multiple
projects,
some
of
which
some
of
those
projects
may
have
some
scans
enabled
and
some
not
and
then,
with
the
instance,
security
dashboard.
The
user
manually
adds
projects
into
that
view,
and
so
again
you
may
have
some
scanners
not
turning
up
any
vulnerabilities.
A
A
A
It's
gonna
be
something
different
altogether
and
then
finally,
I
was
looking
at
terms
that
we're
using,
and
so
there
were
two
small
winds
here
so
on
the
security
dashboard,
which
is
the
screenshot
on
the
top
and
then
the
configuration
page,
which
is
the
one
on
the
bottom.
We
have
some
outdated
terms,
so
I
opened
up
some
issues
to
propose
getting
these
updated.
So,
firstly,
on
the
security
dashboard,
we
have
been
using
the
term
report
type
for
what
are
more
widely
referred
to
across
the
industry
as
scanners
or
scan
types
scanner
types.
A
So
I
think
all
of
the
the
groups
are
or
most
of
them,
anyways
I
know
for
sassed
we're
looking
at
being
able
to
configure
each
scanner
in
the
UI,
and
so
we're
going
to
need
that
that
word
configure
for
configuring.
The
scanner
where,
as
it's
currently
being
used
now
to
basically
mean
enable
and
that's
all
I
have
for
today,
just
wanted
to
have
a
special
thanks
to
Taylor
McCaskill
and
the
senior
product
manager
for
secure,
focused
on
sass
for
your
awesome,
transparency,
collaboration
and
approachability.